A few comments from my side in line.

On 27.06.2012, at 06:10, Henderson, Thomas R wrote:

Regarding this open issue, which I posted about on June 18 [*], I propose the following changes to the RFC 5201-bis text:

1) Section 3

OLD TEXT:

  HIP implementations MUST support the Rivest Shamir Adelman (RSA)
  [RFC3110] public key algorithm, and SHOULD support the Digital
  Signature Algorithm (DSA) [RFC2536] algorithms, and Elliptic Curve
  Digital Signature Algorithm (ECDSA) for generating the HI as defined
  in Section 5.2.9.  Additional algorithms MAY be supported.

NEW TEXT:

  HIP implementations MUST support the Rivest Shamir Adelman (RSA)
  [RFC3110] public key algorithm and Elliptic Curve
  Digital Signature Algorithm (ECDSA) for generating the HI as defined
  in Section 5.2.9.  Additional algorithms MAY be supported.

ECC libraries are available for most consumer-targeting platforms nowadays. Examples are the relic-toolkit [1] and OpenSSL. Hence, I don't see requiring both algorithms as a major concern. However:

1) What exactly are the practical implications of requiring both RSA and ECDSA?

2) Resource-constrained devices may only support ECC crypto. Would it make sense to move away from RSA as REQUIRED (seeing that ECC for PC-grade platforms is widely available) or is this perceived as too drastical of a measure?

[1] http://code.google.com/p/relic-toolkit/

2) Section 5.2.8, HIP cipher

OLD TEXT:

  The following Cipher IDs are defined:

       Suite ID           Value

       RESERVED           0
       NULL-ENCRYPT       1     ([RFC2410])
       AES-128-CBC        2     ([RFC3602])
       3DES-CBC           3     ([RFC2451])
       AES-256-CBC        4     ([RFC3602])

NEW TEXT:

  The following Cipher IDs are defined:

       Suite ID           Value

       RESERVED           0
       NULL-ENCRYPT       1     ([RFC2410])
       AES-128-CBC        2     ([RFC3602])
       DEPRECATED         3     
       AES-256-CBC        4     ([RFC3602])

I agree.

3) Section 5.2.9, Host Id:

OLD TEXT:  

  The following HI Algorithms have been defined:

       Algorithm
       profiles         Values

       RESERVED         0
       DSA              3 [RFC2536] (RECOMMENDED)
       RSA              5 [RFC3110] (REQUIRED)
       ECDSA            7 [RFC4754] (RECOMMENDED)
       ECDSA_LOW        9 [SECG]    (RECOMMENDED)

NEW TEXT:

  The following HI Algorithms have been defined:

       Algorithm
       profiles         Values

       RESERVED         0
       DSA              3 [FIPS 186-3] (OPTIONAL)
       RSA              5 [RFC3447]    (REQUIRED)
       ECDSA            7 [RFC4754]    (REQUIRED)
       ECDSA_LOW        9 [SECG]       (RECOMMENDED)

 For DSA, RSA, and ECDSA key types, profiles containing at least 112
 bits of security strength (as defined by [NIST SP 800-131A]) should
 be used.  For RSA signature padding, the PSS method of padding
 [RFC3447] MUST be used.

------------

Note, I decided not to bother with adding OEAP or ECIES to the cipher list, since we already have symmetric keys available and the ENCRYPTED parameter is lightly used.  If someone would like to support it in addition to AES-CBC, please propose a specific text proposal.

The only use case for OEAP that I can see is if the I1 or R1 should contain confidential information for some reason.

Further ahead in the handshake, I also don't see the need to use PK crypto for the ENCRYPTED parameter as symmetric keys are already available at this point. However, if an extension of HIP should need confidential information in I1 or R1, it can specify this CIPHER_ID itself.