Subject: Ciphersuites for IKEv2

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 21 Jan 2003 15:41:55 -0800

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jan 2003 19:49:01 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "VPNC" == VPNC  <Paul> writes:
    VPNC> Given the looming deadline for us to finish on IKEv2, we need to come to
    VPNC> some agreement on ciphersuites. The following comments are based on the
    VPNC> -04 draft.

  I have reviewed the proposed items, and the 8 combinations make me
comfortable.

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

  I concur with this reasoning.

  I would prefer to label 3 as MUST and 0 as SHOULD, but as long as people
read 2026 for definition as SHOULD, I'm happy.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Jan 2003 15:56:53 -0500

I support Paul Hoffman's posting regarding MUST implement and SHOULD 
implement cipher suites.  The first thing that I really like is that it 
includes rationale.  Further, it allow the working group to tell 
implementors what the next set of algorithms that are likely to become MUST 
implement.  I categorize them as follows.

MUST implement algorithms -
    - widely deployed, secure against today's perceived threat, acceptable 
performance
    - support backward compatibility with previous generation

SHOULD implement algorithms -
    - best guess at the next generation of algorithms

MAY implement algorithms -
    - everything else

Paul's proposal supports this categorization.

Russ

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Jan 2003 12:30:10 -0500

Paul,

I like your analysis and suggestions for MUSTs and SHOULDs. I endorse 
your proposal.

>because they cover IPsec themselves, they should be in 2401bis.

I'm happy to include these ESP/AH suites in 2401 if the WG AGREES.

There is one other feature I would like to see in IKEv2 that is 
somewhat related to the suites (for IKE). As I noted earlier, some 
user groups are sophisticated enough to want to define their own 
groups, for local use. Your proposal allocates a reasonable number of 
values for private use, so there is no impediment there. But it seems 
that we still lack a MUST for IKEv2 that facilities private group 
management support, to ensure that users/admins (not just vendors) 
can define additional, private groups. Any suggestions of how to 
define that capability?

Steve