Subject: Re: Ciphersuites for IKEv2, revised

From: [email-masked]
Date: Sat, 1 Feb 2003 18:38:07 -0500

EKR <[email-masked]> wrote on 01/30/2003 06:38:44 PM:
> Michael Richardson <[email-masked]> writes:
> >   So, we have to have three different proposal structures, which are
> > 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.

The problem is that it's not just three things.

While IKE, ESP, and AH are the only protocols for which suites
are currently defined, negotiation of a tunnel protected by
both ESP and AH is explicitly allowed. We could add to the
proposal structure a protocol ID as well as a suite ID and
define values for IKE, ESP, AH, and AH w/ESP, and perhaps
leave some bits for future protocols negotiated with IKE, but
if we define AH w/ESP, someone is going to want to specify
a suite for it.

Further, the different protocols need different algorithms
specified. AH needs just a MAC. ESP needs MAC and Encryption.
(Or perhaps in the not too distant future a combined algorithm).
IKE needs MAC, Encryption, and PRF. All can optionally have
a Diffie-Hellman group.

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.

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?

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sun, 2 Feb 2003 11:17:14 -0800

>whether we're talking IKE, ESP, or AH.

I fully agree with Charlie here.

>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

---

From: Gregory Lebovitz <[email-masked]>
Date: Thu, 6 Feb 2003 17:33:38 -0800

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:[email-masked]]
> Sent: Sunday, February 02, 2003 11:17 AM
> To: [email-masked]
> Subject: Re: Ciphersuites for IKEv2, revised
> 
>

---

From: Derek Atkins <[email-masked]>
Date: 10 Feb 2003 14:33:57 -0500

Dan McDonald <[email-masked]> writes:

> Thanks for this most recent update.

Yes, thank you for the 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.

I, too, am not convinced of the goodness of suites _in the protocol_.
I completely agree that suites should be defined in the user interface
presented to the user, but on-the-wire I still believe that all the
algorithms should be negotiated a-la-carte.

I've been catching up on wg mail over the last few days, and this WG
seems to continually flip-flop between suites and a-la-carte.  I had
_THOUGHT_ that we had concensus on:

        1) the on-the-wire protocol would negotiate a-la-carte
        2) the UI would present suites to the user

What happened to this concensus that we had in December?

As an implementor, it's significantly easier to design plug-and-play
algorithms.  I see no reason to constrain an implementation to some
set of suites.  I don't believe it will hurt interoperability to
negotiate a-la-carte, and in fact I think it makes for a simpler
specification to do so.

But again, the user interface can lump these choices into named suites
for the user to choose.  I have no problem with creating a set of
known, named suites for users.

Can someone explain the benefit of forcing negotiation by suites?  The
only argument I've heard is hardware crypto -- but in that case it can
just make a set of a-la-carte proposals that meet its capabilities.

> Dan

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com