Tobias Heer | 2 Dec 17:14 2010
Picon
Picon

Re: Host ID Parameter in RFC5201-bis

Hello Henrik, 

thanks for the input. Short version: I think you comments are good and the HI parameter should be
self-contained. I agree with removing the DNSKEY format.

More comments in line.

Am 30.11.2010 um 19:01 schrieb Henrik Ziegeldorf:

> Hi,
> 
> I'm currently implementing basic elliptic curve cryptography for HIP according to RFC5201-bis,
> and have some suggestions concerning the Host ID parameter (Sect. 5.2.8).
> 
> I'd like to discuss the following points:
> 
> 1) Self-containment of the host_id parameter: For RSA/DSA identities an algorithm field is specified,
for ECDSA identities there is none.
> 
> For RSA and DSA the format of the host identity field is defined as the DNSKEY format.
> 
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |             flags             |    protocol   |   algorithm   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               /
>    /                          public key                           /
>    /                                                               /
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
(Continue reading)

Gonzalo Camarillo | 5 Dec 16:51 2010
Picon

WGLC: draft-ietf-hip-cert-06

Folks,

we hereby start the WGLC on the following draft. This WGLC will end on
December 20th.

https://datatracker.ietf.org/doc/draft-ietf-hip-cert/

Please, send your comments to this list.

Thanks,

Gonzalo
HIP co-chair
Tobias Heer | 7 Dec 18:01 2010
Picon
Picon

Re: Host ID Parameter in RFC5201-bis

Hello Henrik,

I implemented your comments in RFC5201-bis. Do you think your comments are addressed adequately?

The new text on the HI looks like this:

5.2.8.  HOST_ID

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          HI Length            |DI-type|      DI Length        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Algorithm             |         Host Identity         /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                               |         Domain Identifier     /
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     /                                               |    Padding    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type              705
     Length            length in octets, excluding Type, Length, and
                       Padding
     HI Length         length of the Host Identity in octets
     DI-type           type of the following Domain Identifier field
     Algorithm         index to the employed algorithm
     DI Length         length of the FQDN or NAI in octets
     Host Identity     actual Host Identity
(Continue reading)

Tobias Heer | 9 Dec 11:26 2010
Picon
Picon

HIT Suites and algorithms used in RFC5201-bis

Hello,

we have consolidated the set of algorithms to be used in RFC5201 and would like
to present it to the list and ask for feedback.

We have three HIT Suites.  The HIT Suites define the algorithms that are used
for generating a HIT/Orchid.  It also defines which HMAC flavor will be used in
HIP control packets.

     HIT Suite              ID
     RESERVED                0
     RSA,DSA/SHA-1           1    (REQUIRED)
     ECDSA/SHA-384           2    (RECOMMENDED)
     ECDSA_LOW/SHA-1         3    (RECOMMENDED)

RSA,DSA/SHA-1 represent the class of HITs we have today with HIP version 1.  All
contained Algorithms (RSA and DSA) must be supported by hosts that implement
this suite.

ECDSA/SHA-384 bundles two ECC curves (NIST P-256 and P-384) with SHA-384.  Both
curves must be implemented by hosts that implement HIT this HIT suite.

ECDSA_LOW/SHA-1 is meant for devices with limited computation capabilities.  It
uses the SECP160R curve from SECG.

If we want to make a bold move towards ECC cryptography (and make packet
fragmentation, etc.  less likely) we could change the REQUIRED and RECOMMENDED
tags so that we REQUIRE the ECDSA/SHA-384 HIT SUITE and make the other two
recommended.  Any comments on this?

(Continue reading)

Miika Komu | 9 Dec 14:31 2010
Picon
Picon

Re: HIT Suites and algorithms used in RFC5201-bis

Hi,

On 12/09/2010 12:26 PM, Tobias Heer wrote:
> Hello,
>
> we have consolidated the set of algorithms to be used in RFC5201 and would like
> to present it to the list and ask for feedback.
>
> We have three HIT Suites.  The HIT Suites define the algorithms that are used
> for generating a HIT/Orchid.  It also defines which HMAC flavor will be used in
> HIP control packets.
>
>
>       HIT Suite              ID
>       RESERVED                0
>       RSA,DSA/SHA-1           1    (REQUIRED)
>       ECDSA/SHA-384           2    (RECOMMENDED)
>       ECDSA_LOW/SHA-1         3    (RECOMMENDED)
>
> RSA,DSA/SHA-1 represent the class of HITs we have today with HIP version 1.  All
> contained Algorithms (RSA and DSA) must be supported by hosts that implement
> this suite.
>
> ECDSA/SHA-384 bundles two ECC curves (NIST P-256 and P-384) with SHA-384.  Both
> curves must be implemented by hosts that implement HIT this HIT suite.
>
> ECDSA_LOW/SHA-1 is meant for devices with limited computation capabilities.  It
> uses the SECP160R curve from SECG.
>
> If we want to make a bold move towards ECC cryptography (and make packet
(Continue reading)

Henrik Ziegeldorf | 9 Dec 15:12 2010
Picon
Picon

Re: HIT Suites and algorithms used in RFC5201-bis

Hello,

On 9 December 2010 11:26, Tobias Heer <heer <at> cs.rwth-aachen.de> wrote:
Hello,

we have consolidated the set of algorithms to be used in RFC5201 and would like
to present it to the list and ask for feedback.

We have three HIT Suites.  The HIT Suites define the algorithms that are used
for generating a HIT/Orchid.  It also defines which HMAC flavor will be used in
HIP control packets.


    HIT Suite              ID
    RESERVED                0
    RSA,DSA/SHA-1           1    (REQUIRED)
    ECDSA/SHA-384           2    (RECOMMENDED)
    ECDSA_LOW/SHA-1         3    (RECOMMENDED)

RSA,DSA/SHA-1 represent the class of HITs we have today with HIP version 1.  All
contained Algorithms (RSA and DSA) must be supported by hosts that implement
this suite.

ECDSA/SHA-384 bundles two ECC curves (NIST P-256 and P-384) with SHA-384.  Both
curves must be implemented by hosts that implement HIT this HIT suite.

ECDSA_LOW/SHA-1 is meant for devices with limited computation capabilities.  It
uses the SECP160R curve from SECG.

These comments are quite helpful to clarify and justify the use of ECDSA_LOW as a seperate algorithm identifier.
I think it would make sense to include them in the RFC, too.

But what about an implementation that implements the ECDSA/SHA-384 suite? It should implement the ECDSA_LOW profile, too, I think.
 

If we want to make a bold move towards ECC cryptography (and make packet
fragmentation, etc.  less likely) we could change the REQUIRED and RECOMMENDED
tags so that we REQUIRE the ECDSA/SHA-384 HIT SUITE and make the other two
recommended.  Any comments on this?


The ECDH groups look similar:

 Group                Value
 Reserved             0
 DEPRECATED           1
 DEPRECATED           2
 1536-bit MODP group  3 [RFC3526]
 3072-bit MODP group  4 [RFC3526]
 DEPRECATED           5
 DEPRECATED           6
 NIST P-256           7 [RFC4753]
 NIST P-384           8 [RFC4753]
 NIST P-521           9 [RFC4753]
 SECP160R1           10 [SECG]

Groups 7 to 10 are new in RFC5201-bis.  Again, group 10 is meant for devices
with low computation capabilities and should be used only if long-term
confidentiality is not required.

The DEPRECATED values are groups present in RFC5201 but have been removed in
RFC5201-bis.  They have to be removed before we finish the document.

Are there any comments regarding the selection of algorithms?  With the selected
ECC curves, we tried to stay as close to other Internet standards IKE, TLS that
use ECC already.

Best regards,

Tobias





--
Dipl.-Inform. Tobias Heer, Ph.D. Student

Best regards,
Henrik
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi

_______________________________________________
Hipsec mailing list
Hipsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

_______________________________________________
Hipsec mailing list
Hipsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/hipsec
Henderson, Thomas R | 9 Dec 17:31 2010
Picon

Re: HIT Suites and algorithms used in RFC5201-bis


> -----Original Message-----
> From: hipsec-bounces <at> ietf.org
> [mailto:hipsec-bounces <at> ietf.org] On Behalf Of Tobias Heer
> Sent: Thursday, December 09, 2010 2:27 AM
> To: hipsec <at> ietf.org
> Subject: [Hipsec] HIT Suites and algorithms used in RFC5201-bis
>
> Hello,
>
> we have consolidated the set of algorithms to be used in
> RFC5201 and would like
> to present it to the list and ask for feedback.
>
> We have three HIT Suites.  The HIT Suites define the
> algorithms that are used
> for generating a HIT/Orchid.  It also defines which HMAC
> flavor will be used in
> HIP control packets.
>
>
>      HIT Suite              ID
>      RESERVED                0
>      RSA,DSA/SHA-1           1    (REQUIRED)
>      ECDSA/SHA-384           2    (RECOMMENDED)
>      ECDSA_LOW/SHA-1         3    (RECOMMENDED)
>
> RSA,DSA/SHA-1 represent the class of HITs we have today with
> HIP version 1.  All
> contained Algorithms (RSA and DSA) must be supported by hosts
> that implement
> this suite.
>
> ECDSA/SHA-384 bundles two ECC curves (NIST P-256 and P-384)
> with SHA-384.  Both
> curves must be implemented by hosts that implement HIT this HIT suite.
>
> ECDSA_LOW/SHA-1 is meant for devices with limited computation
> capabilities.  It
> uses the SECP160R curve from SECG.
>
> If we want to make a bold move towards ECC cryptography (and
> make packet
> fragmentation, etc.  less likely) we could change the
> REQUIRED and RECOMMENDED
> tags so that we REQUIRE the ECDSA/SHA-384 HIT SUITE and make
> the other two
> recommended.  Any comments on this?

Has anyone checked into the availability of these suites in cryptographic libraries and hardware?

Can you clarify what you believe are the implications that you hint at ("packet fragmentation, etc.")?

>
>
> The ECDH groups look similar:
>
>  Group                Value
>  Reserved             0
>  DEPRECATED           1
>  DEPRECATED           2
>  1536-bit MODP group  3 [RFC3526]
>  3072-bit MODP group  4 [RFC3526]
>  DEPRECATED           5
>  DEPRECATED           6
>  NIST P-256           7 [RFC4753]
>  NIST P-384           8 [RFC4753]
>  NIST P-521           9 [RFC4753]
>  SECP160R1           10 [SECG]
>
> Groups 7 to 10 are new in RFC5201-bis.  Again, group 10 is
> meant for devices
> with low computation capabilities and should be used only if long-term
> confidentiality is not required.
>
> The DEPRECATED values are groups present in RFC5201 but have
> been removed in
> RFC5201-bis.  They have to be removed before we finish the document.
>
> Are there any comments regarding the selection of algorithms?
>  With the selected
> ECC curves, we tried to stay as close to other Internet
> standards IKE, TLS that
> use ECC already.
>

I don't have other comments and agree with trying to stay close to the predecessors.

- Tom
Tobias Heer | 9 Dec 20:00 2010
Picon
Picon

Re: HIT Suites and algorithms used in RFC5201-bis

Hello Tom,

Am 09.12.2010 um 17:31 schrieb Henderson, Thomas R:

> 
> 
>> -----Original Message-----
>> From: hipsec-bounces <at> ietf.org
>> [mailto:hipsec-bounces <at> ietf.org] On Behalf Of Tobias Heer
>> Sent: Thursday, December 09, 2010 2:27 AM
>> To: hipsec <at> ietf.org
>> Subject: [Hipsec] HIT Suites and algorithms used in RFC5201-bis
>> 
>> Hello,
>> 

[...]
>> 
>> 
>> ECDSA/SHA-384 bundles two ECC curves (NIST P-256 and P-384)
>> with SHA-384.  Both
>> curves must be implemented by hosts that implement HIT this HIT suite.
>> 
>> ECDSA_LOW/SHA-1 is meant for devices with limited computation
>> capabilities.  It
>> uses the SECP160R curve from SECG.
>> 
>> If we want to make a bold move towards ECC cryptography (and
>> make packet
>> fragmentation, etc.  less likely) we could change the
>> REQUIRED and RECOMMENDED
>> tags so that we REQUIRE the ECDSA/SHA-384 HIT SUITE and make
>> the other two
>> recommended.  Any comments on this?
> 
> Has anyone checked into the availability of these suites in cryptographic libraries and hardware?
> 
I have checked that these are available in the widely used openssl library. They all are.

> Can you clarify what you believe are the implications that you hint at ("packet fragmentation, etc.")?

Large RSA/DSA Keys, large RSA signatures and certificates may add up to a considerable amount of data in HIP
control packets. Reducing the size of the keys (compared to RSA/DSA) and the size of the signatures
(compared to RSA) may reduce the probability of packet fragmentation for HIP control packets - that was my
train of thought. Sorry for not making it more obvious.

Tobias

> 
>> 
>> 
>> The ECDH groups look similar:
>> 
>> Group                Value
>> Reserved             0
>> DEPRECATED           1
>> DEPRECATED           2
>> 1536-bit MODP group  3 [RFC3526]
>> 3072-bit MODP group  4 [RFC3526]
>> DEPRECATED           5
>> DEPRECATED           6
>> NIST P-256           7 [RFC4753]
>> NIST P-384           8 [RFC4753]
>> NIST P-521           9 [RFC4753]
>> SECP160R1           10 [SECG]
>> 
>> Groups 7 to 10 are new in RFC5201-bis.  Again, group 10 is
>> meant for devices
>> with low computation capabilities and should be used only if long-term
>> confidentiality is not required.
>> 
>> The DEPRECATED values are groups present in RFC5201 but have
>> been removed in
>> RFC5201-bis.  They have to be removed before we finish the document.
>> 
>> Are there any comments regarding the selection of algorithms?
>> With the selected
>> ECC curves, we tried to stay as close to other Internet
>> standards IKE, TLS that
>> use ECC already.
>> 
> 
> I don't have other comments and agree with trying to stay close to the predecessors.
> 
> - Tom

--

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi
Tobias Heer | 9 Dec 20:06 2010
Picon
Picon

Re: HIT Suites and algorithms used in RFC5201-bis

Hello Tom,

one more thing I forgot to answer....

Am 09.12.2010 um 17:31 schrieb Henderson, Thomas R:

[...]
> 
> Has anyone checked into the availability of these suites in cryptographic libraries and hardware?

I cannot say much about hardware acceleration for ECC but I know that software support for SECP160R1 is even
available in sensor node platforms (TinyECC for TinyOS).

BR,

Tobias

--

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi
Internet-Drafts | 16 Dec 15:00 2010
Picon

I-D Action:draft-ietf-hip-over-hip-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Host Identity Protocol Working Group of the IETF.

	Title           : Host Identity Protocol Signaling Message Transport Modes
	Author(s)       : A. Keranen
	Filename        : draft-ietf-hip-over-hip-04.txt
	Pages           : 12
	Date            : 2010-12-16

This document specifies two transport modes for Host Identity
Protocol (HIP) signaling messages that allow conveying them over
encrypted connections initiated with the Host Identity Protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hip-over-hip-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-hip-over-hip-04.txt): message/external-body, 70 bytes
_______________________________________________
Hipsec mailing list
Hipsec <at> ietf.org
https://www.ietf.org/mailman/listinfo/hipsec

Gmane