On 06/29/2012 05:02 AM, René Hummen wrote:
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.
Crypto in I1 is a clear resource attack. That is in large measure why
there IS an I1 packet. I have had to deal with proposals to put signed
objects into 802.11 BEACONs and PROBEs. But thinking.
R1 confidental information is an interesting thought. It would take a
bit to expand on it, but as you note in the end, if someone were to
propose this, then they can specify this cipher itself.
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.
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
