Re: Ciphersuites for IKEv2, revised

[Russ Housley <[e-mail]>]

I really like way Paul Hoffman has proposed.

One minor nit pick.  In the Appendix B.1 proposed text, we should change 
"prime values and generators" to "generator and prime modulus values"

Russ


At 08:50 AM 1/30/2003 -0800, Paul Hoffman / VPNC wrote:
>Greetings again. Based on feedback from the list and offline, here is
>revised wording for the ciphersuites in IKEv2. The changes are:
>
>- clarified where the various Diffie-Hellman groups are defined
>
>- changed the split between what is reserved for IANA and what is
>   for private use
>
>- added a paragraph to the end of the addition to 5.3.1 to specify
>   that users should be able to use future and private-use Suite-IDs
>
>- added a note in Appendix B and a new reference
>
>The following text be should be used in section 5.3.1:
>
>=====
>
>For Suite-ID, the following values are defined:
>
>Suite-ID  Meaning
>--------  -------
>0         Covers: IKE
>           168-bit 3DES CBC encryption
>           Diffie-Hellman group 2 (1024-bit), defined in Appendix B.2
>           HMAC-SHA1 integrity and prf
>
>1         Covers: ESP
>           3DES encryption with three keys
>           HMAC-SHA1 integrity
>
>2         Covers: AH
>           HMAC-SHA1 integrity
>
>3         Covers: IKE
>           168-bit 3DES CBC encryption
>           Diffie-Hellman group 5 (1536-bit), defined in Appendix B.5
>           HMAC-SHA1 integrity and prf
>
>4         Covers: IKE
>           AES encryption in CBC mode with 128-bit keys
>           Diffie-Hellman group 5 (1536-bit), defined in Appendix B.5
>           HMAC-SHA1 integrity and prf
>
>5         Covers: IKE
>           AES encryption in CBC mode with 128-bit keys
>           Diffie-Hellman group 14 (2048-bit), defined in [ADDGROUP]
>           HMAC-SHA1 integrity and prf
>
>6         Covers: ESP
>           AES encryption in CBC mode with 128-bit keys
>           HMAC-SHA1 integrity
>
>7         Covers: IKE
>           AES encryption in CTR mode with 128-bit keys
>           Diffie-Hellman group 14 (2048-bit), defined in [ADDGROUP]
>           AES-CBC MAC + XCBC integrity and prf
>
>8         Covers: ESP
>           AES encryption in CTR mode with 128-bit keys
>           AES-CBC MAC + XCBC integrity
>
>Values 9-32000 are reserved to IANA. Values 32001-65533 are for private
>use among mutually consenting parties. Additional Suite-ID values will
>be assigned by IANA based on consultation with the IESG.
>
>All implementations of IKEv2 MUST be able to negotiate Suite-ID 0 and
>Suite-ID 1. Implementations SHOULD be able to negotiate Suite-IDs 3, 4,
>5, and 6.
>
>The must-be-implemented ciphersuites (0 and 1) are based on
>currently-deployed hardware that meets the security requirements of the
>vast majority of current IPsec users, and should be useful for at least
>a decade according to cryptographic estimates from NIST for business
>user scenarios. The should-be-implemented ciphersuites (3, 4, 5, and 6)
>are based on expectations of where the security industry is moving
>(namely, to the AES encryption suite) and where more security-conscious
>users are moving as current key lengths become more attackable due to
>the steady lowering of cost to mount brute-force attacks.
>
>An important lesson learned from IKEv1 is that no system should only
>implement the mandatory algorithms and expect them to be the best choice
>for all customers. For example, at the time that this document was being
>written, many IKEv1 implementers are starting to migrate to AES in CBC
>mode for VPN applications. Many IPsec systems based on IKEv2 will
>implement AES, longer Diffie-Hellman keys, and additional hash
>algorithms, and some IPsec customers already require these algorithms in
>addition to the mandatory ones listed above.
>
>It is likely that IANA will add additional Suite-IDs in the future, and
>some security-conscious users will want to use private-use Suite-IDs.
>All implementations SHOULD be able to let users set policies that use
>Suite-IDs from the currently-unassigned IANA values and from the private
>use values. Of course, there is no standard way to handle all possible
>new algorithms, Diffie-Hellman groups, and combinations thereof. However,
>many IPsec users will want to base security policies on Suite-IDs that
>are not covered in this document and SHOULD be able to do so.
>
>=====
>
>Add the following to just before Appendix B.1:
>
>Additional Diffie-Hellman groups have been defined in [ADDGROUP]. Future
>IANA-registered and private use Suite-IDs MAY use Diffie-Hellman groups
>that have prime values and generators that are different than those in
>this document or in [ADDGROUP].
>
>Add to the non-normative references:
>
>[ADDGROUP] Kivinen, T. et. al., "More MODP Diffie-Hellman groups for IKE", 
>draft-ietf-ipsec-ike-modp-groups-05.txt, in RFC Editor's queue for 
>Proposed Standard.
>
>--Paul Hoffman, Director
>--VPN Consortium