Ciphersuites for IKEv2, revised

[Paul Hoffman / VPNC <[e-mail]>]

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