RE: Ciphersuites for IKEv2, revised

[Gregory Lebovitz <Gregory@netscreen.com>]

I am also fine with the regrouping Charlie propsed. However, I should say
that we see no big requirement for AH today, so I'm not itching for its
inclusion.

Given that Charlie hasn't yet proposed new suites (per above) I'll comment
on thoughts wrt SHOULDS/MUSTS w/ Paul's last list. Label and thought follow
each:

> 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

MUST - interop w/ what most implementations have today.
 
> 1         Covers: ESP
>            3DES encryption with three keys
>            HMAC-SHA1 integrity

MUST - interop w/ what most implementations have today.
 
> 2         Covers: AH
>            HMAC-SHA1 integrity

MAY - very few deployments actually use AH today.
 
> 3         Covers: IKE
>            168-bit 3DES CBC encryption
>            Diffie-Hellman group 5 (1536-bit), defined in Appendix B.5
>            HMAC-SHA1 integrity and prf

SHOULD - interop w/ what many implementations have today.
 
> 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

MUST - A contentious move, I know. I think that from a pure
security/performance perspective we should all be moving to AES. Making this
a MUST will press that point. It may take some a while to get there. And
that is fine. People can claim RFC compliance with a "*" and a footnote
saying, "AES coming in [DATE]". as for interop, If you don't have it, say so
and we'll move on to another interop test until you get it, but at least
everyone will know they have to get there ASAP.
 
> 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

MAY - Beyond DH5 everything else is still pretty new and shifting. Believe
we ought to update the RFC later once this space settles down a bit, and a
majority have implemented.

> 6         Covers: ESP
>            AES encryption in CBC mode with 128-bit keys
>            HMAC-SHA1 integrity

MUST - same justification as #4 above.

> 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

MAY - WRT AES-CTR, agree w/ others' previous comments that these can be
MUSTS in iSCSI RFC. WRT DH14, see #5.
 
> 8         Covers: ESP
>            AES encryption in CTR mode with 128-bit keys
>            AES-CBC MAC + XCBC integrity

MAY - 

Gregory.

> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org]
> Sent: Sunday, February 02, 2003 11:17 AM
> To: ipsec@lists.tislabs.com
> Subject: Re: Ciphersuites for IKEv2, revised
> 
> 
> At 6:38 PM -0500 2/1/03, Charlie_Kaufman@notesdev.ibm.com wrote:
> >I believe it would be more confusing than clarifying to
> >pretend that the algorithm negotiation is independent of
> >whether we're talking IKE, ESP, or AH.
> 
> I fully agree with Charlie here.
> 
> >
> >That said, I do think it would be a good idea to group
> >the IKE, ESP, and AH suites both in their numbering
> >ranges and as ordered in the specification. Would anyone
> >object to my changing Paul's numbers?
> 
> I think it is a good idea as well. Go for it. However, please do 
> *not* do anything that indicates that the private-use space has any 
> such breakdown, since some of the private-use uses will do things 
> that we probably don't expect (or want to know about...)
> 
> --Paul Hoffman, Director
> --VPN Consortium
>