Subject: [Hipsec] HIT Suites and algorithms used in RFC5201-bis

From: Tobias Heer <[email-masked]>
Date: Thu, 09 Dec 2010 11:26:53 +0100

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?

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

---

From: Miika Komu <[email-masked]>
Date: Thu, 09 Dec 2010 15:31:26 +0200

Hi,

> ECC curves, we tried to stay as close to other Internet standards IKE, TLS that

seems fine to me.

---

From: Henrik Ziegeldorf <[email-masked]>
Date: Thu, 9 Dec 2010 15:12:33 +0100

Hello,

> 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.

> ECC curves, we tried to stay as close to other Internet standards IKE, TLS

Best regards,
Henrik

> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 9 Dec 2010 08:31:46 -0800

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Tobias Heer
> Sent: Thursday, December 09, 2010 2:27 AM
> To: [email-masked]
> Subject: [Hipsec] HIT Suites and algorithms used in RFC5201-bis
>
> Hello,
>

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.")?

> ECC curves, we tried to stay as close to other Internet

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

- Tom

---

From: Tobias Heer <[email-masked]>
Date: Thu, 09 Dec 2010 20:00:16 +0100

Hello Tom,

>> Subject: [Hipsec] HIT Suites and algorithms used in RFC5201-bis

[...]
> 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

---

From: Tobias Heer <[email-masked]>
Date: Thu, 09 Dec 2010 20:06:12 +0100

Hello Tom,

one more thing I forgot to answer....

[...]
> 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

---

From: René Hummen <[email-masked]>
Date: Mon, 27 Dec 2010 15:12:02 +0100

Hello Tobias,

> recommended.  Any comments on this?

With either RSA,DSA/SHA-1 or ECDSA/SHA-384 required, how could a HIP implementation for low resource devices (only supporting ECDSA_LOW/SHA-1) be standard compliant? In this respect, does it make sense to only have a a single ECDSA family instead of separating between ECDSA and ECDSA_LOW?

BR,
René

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/