[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Ciphersuites for IKEv2



Given the looming deadline for us to finish on IKEv2, we need to come to
some agreement on ciphersuites. The following comments are based on the
-04 draft.

In section 5.3.1, it says:

>For Suite-ID, the following values are defined:
>
>	  Name            Number   Algorithms
>	  IKE_CLASSIC       0       DH-Group #5 (1536 bits)
>					3DES encryption
>					HMAC-SHA1 integrity and prf
>
>	  ESP_CLASSIC       1       3DES encryption
>					HMAC-SHA1 integrity
>	  <some AES variants, AH (?))
>
>	  values 2-65000 are reserved to IANA. Values 65001-65533 are
>	  for private use among mutually consenting parties.

Later, in section 5.14, it says:

>  The mandatory to implement algorithms are AES-128-CBC and HMAC-SHA1.


So far, this list hasn't been able to agree on whether these are good
values, mostly due to people having different priorities. I propose that
the priority we choose for creating the MUST implement suite be that of
greatest interoperability. This means that we should not expect any
current IPsec vendor who has hardware acceleration to need to make
hardware upgrades to their IPsec devices.

Beyond that, we should also define suites that are expected to be used
in typical circumstances, but we should not attach a MUST or even a
SHOULD to those suites. We should also *not* name the suites because the
names will impart meaning in the future that may not be true. For
example, the name "IKE_CLASSIC" implies that the values are those used
by typical IKEv1 systems, but that is not true because many systems
don't even implement DH Group 5 (even though they obviously should).

Given those criteria, I propose that the following text be used in
section 5.3.1 (and the text noted above in section 5.14 be removed):

=====

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)
          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)
          HMAC-SHA1 integrity and prf

4         Covers: IKE
          AES encryption in CBC mode with 128-bit keys
          Diffie-Hellman group 5 (1536-bit)
          HMAC-SHA1 integrity and prf

5         Covers: IKE
          AES encryption in CBC mode with 128-bit keys
          Diffie-Hellman group 14 (2048-bit)
          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)
          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-65000 are reserved to IANA. Values 65001-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.

=====

Possible issues:

- Some people may want to have more suites as fallbacks in case of
a catastrophic failure of an algorithm. The WG seemed to want fewer
suites. This is why I had the IANA registry being updated with IESG
consultation instead of a standards-track RFC: we could get a number
easily for a non-compromised suite. Having a zillion suites defined
early won't cause implementers to handle them; note that TIGER was
a SHOULD in IKEv1 and almost no one implemented it at all.

- Should the ESP and AH MUST and SHOULDs be in the IKEv2 document or
in 2401bis? I think they should be in IKEv2, but others have said that
because they cover IPsec themselves, they should be in 2401bis.


--Paul Hoffman, Director
--VPN Consortium