FW: Ciphersuites for IKEv2

[Black_David@emc.com]

The ipsec WG is in the process of defining a new version of
the IKE protocol for IPsec authentication, key exchange, SA
creation and the like.

A major change from the current IKE is that all cryptographic
aspects of SA creation are bundled into suites for negotiation
rather than being independently negotiable, as fewer combinations
to implement and test increases the likelihood of interoperability
and reduces the opportunities for things to go worng in peculiar
combinations that are unlikely to be useful.  This is part of
a radical change to IKE/ISAKMP negotiation to fix a number of
problems with the way it currently works.

The proposal forwarded below has just been floated to define
the initial suites.  The most important aspect of it is that
the proposed AES suite definitions bind encryption mode and
integrity algorithm (MAC) together, specifically:

- AES-CBC suites are only defined with HMAC-SHA1
	(cannot use AES-CBC MAC w/XCBC)
- AES-CTR suites are only defined with AES-CBC MAC w/XCBC
	(cannot use HMAC-SHA1)

If this is a problem for anyone, they need to comment on the
ipsec mailing list (ipsec@lists.tislabs.com) ASAP.  Please
read the entire message forwarded below (including the "Possible
issues:" section at its end) before commenting.  Also, please
note that 3DES-CBC and HMAC-SHA1 will be "MUST implement", so
hence there's not as much implementation advantage as might
initially appear to AES-CBC + AES-CBC MAC w/XCBC as HMAC-SHA1
has to be there anyhow.

Further discussion of this should be on the ipsec WG mailing
list (ipsec@lists.tislabs.com) - this is just an FYI for IPS
folks working with IPsec.  None of this affects any requirements
in the current IPS protocol specifications - this is an FYI
about where this area of technology is headed.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

-----Original Message-----
From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
Sent: Tuesday, January 21, 2003 6:42 PM
To: ipsec@lists.tislabs.com
Subject: 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