Subject: Ciphersuites for IKEv2, revised

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 30 Jan 2003 08:50:57 -0800

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

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 30 Jan 2003 11:01:42 -0800

At 10:38 AM -0800 1/30/03, Eric Rescorla wrote:
>So, you're saying that the cipher suites for IKE
>encryption share the same namespace with those for
>ESP/AH?

Correct. There is only one class of Suite-ID specified in the IKEv2 -04 draft.

>That seems kind of confusing.

Maybe. But I think that having three different flavors of Suite-ID 
(one for IKE, one for ESP, one for AH) will be just as confusing to 
typical users. I assume that any GUI will have an IKE list that only 
contains Suite-IDs that pertain to IKE, and a ESP list that only 
contains Suite-IDs that pertain to ESP, and (if they even do AH) an 
AH list that only contains Suite-IDs that pertain to AH.

What you are asking for would cause us to have to change the proposal 
structure given in section 5.3.1 to split out "area of coverage" from 
the Suite-ID. Is that really worth it?

--Paul Hoffman, Director
--VPN Consortium

---

From: Eric Rescorla <[email-masked]>
Date: 30 Jan 2003 10:38:41 -0800

Paul,

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Eric Rescorla <[email-masked]>
Date: 30 Jan 2003 12:25:52 -0800

Paul Hoffman / VPNC <[email-masked]> writes:

> typical users.
Well, there are three different flavors of suite, regardless
of how the ID space is partitioned. I'm just saying that
the two structures should match.

> the Suite-ID.
I want three tables and three separate sections.

> Is that really worth it?
I think so. 

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Thu, 30 Jan 2003 15:39:50 -0500

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:
>[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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2003 15:59:33 -0500

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

>>>>> "Eric" == Eric Rescorla <[email-masked]> writes:
    Eric> Paul,

    Eric> So, you're saying that the cipher suites for IKE encryption share
    Eric> the same namespace with those for ESP/AH?

    Eric> That seems kind of confusing.

  Yeah, maybe.

  People also seem to occasionally argue that X is too slow, and I ask, "but
this is for IKE!" and they say "no, I'm talking ESP.".

  So this is really a question of economies of a single list vs some minor
confusion. The magic value in this case goes into a proposal in the same
place. There is some niceties in having it demux'ed once.

]       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: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2003 16:03:11 -0500

>>>>> "VPNC" == VPNC  <Paul> writes:
    >> So, you're saying that the cipher suites for IKE encryption share the
    >> same namespace with those for ESP/AH?

    VPNC> Correct. There is only one class of Suite-ID specified in the IKEv2
    VPNC> -04 draft.

    >> That seems kind of confusing.

    VPNC> Maybe. But I think that having three different flavors of Suite-ID
    VPNC> (one for IKE, one for ESP, one for AH) will be just as confusing to
    VPNC> typical users. I assume that any GUI will have an IKE list that
    VPNC> only contains Suite-IDs that pertain to IKE, and a ESP list that
    VPNC> only contains Suite-IDs that pertain to ESP, and (if they even do
    VPNC> AH) an AH list that only contains Suite-IDs that pertain to AH.

  How about a compromise.
  A single number space, as we have now.

  But, 
       0-8K	for IKE
       8K-16K	for ESP
       16K-24K	for AH
       32K-48K	for private use

  rest is IANA reserved.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jan 2003 16:42:49 -0500

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

    >> (one for IKE, one for ESP, one for AH) will be just as confusing to

    Eric> Well, there are three different flavors of suite, regardless of how
    Eric> the ID space is partitioned. I'm just saying that the two
    Eric> structures should match.

    >> structure given in section 5.3.1 to split out "area of coverage" from

    Eric> I want three tables and three separate sections.

  So, we have to have three different proposal structures, which are
identical, except that they negotiate the same things for the different uses?

---

From: Eric Rescorla <[email-masked]>
Date: 30 Jan 2003 15:38:44 -0800

> identical, except that they negotiate the same things for the different uses?
My bad. I'd forgotten that "proposal structure" was a technical term.

I'd prefer to see the proposal structure explicitly modified to
represent the fact that there are three different things
being negotiated.

-Ekr

---

From: Dan McDonald <[email-masked]>
Date: Fri, 31 Jan 2003 12:50:26 -0500 (EST)

Thanks for this most recent update.

I'm still not convinced of the goodness of suites in general, but if the WG
insists, I have to fall in with Michael that you should cordon off sections
for IKE, AH, and ESP.

Also, what happened to HMAC-MD5?!?  I know people have some issues with MD5,
but the HMAC transformation is supposed to address most of that, no?

Dan