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                           /
>    /                                                               /
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

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

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

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?

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

Re: HIT Suites and algorithms used in RFC5201-bis

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

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

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

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

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.

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