Subject: RE: feedback on algorithms-00

From: Gregory Lebovitz <[email-masked]>
Date: Thu, 15 May 2003 09:59:16 -0700

including the list...

> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:[email-masked]]
> Sent: Thursday, May 15, 2003 7:49 AM
> To: Gregory Lebovitz
> Subject: Re: feedback on ipsec-algorithms-00
> 
> 
> >- Makes perfect sense to have this separate from the actual 
> proto docs.
> >Thanks for getting it done.
> 
> Your welcome. See below.
> 
> >- Sect 2, first sentence, typo "used in IKEv2 for may security..."
> 
> Thanks, go it.
> 
> >- format help: would be nice in 2.1-2.4 to add a 4th column 
> to each chart
> >that holds MUST, SHOULD, etc. That way the reader can see 
> what's what very
> >quickly.
> 
> I didn't do that because of the difference between "MUST today" and 
> "MUST tomorrow". That is, I wanted to keep the wording below the 
> tables being definitive.

no argument about keeping the wording; I wouldn't have suggested removing
it. Adding the column will make ingestion easier on the reader.
Additionally, you could put a "*" by the SHOULD that calls to text below
highlighting the "MUST Later" stuff.
 
> >- 2.4 - the DH values for 1-5 are currently defined in 
> [IKEv2]. Since this
> >is the crypto doc, shouldn't we pull those definitions out 
> of the [IKEv2]
> >and into this doc, along with the definitions of values for 
> the others?
> 
> Yes, but no one had a strong opinion on this.

I'd say just do it and see if anyone screams. Probably no one will care, and
most will think its a good idea.

> 
> >   - second sentence says values 6-200. But really it is 
> 6-13, 19-200, right?
> >Because 14-18 are defined in [MODP]?
> 
> Correct; good catch.
> 
> 
> >- 3.0 1st para, last sentence, TYPO:  "Instead *they* give..."
> 
> Fixed.
> 
> >-3.x - I really like the idea of doing suites via 
> "profiling" that dictates
> >the suites we will all use in practice, while the actual 
> protocol should
> >call for "a la carte" method of SA proposal. It makes for 
> (a) a much more
> >powerful and flexible protocol, while (b) providing the ease 
> of use and
> >crypto sanity checking that are needed on both ends of the
> >security/convenience spectrum.  We can even name them the 
> same thing in our
> >UI's, which will make interop all that much easier.
> 
> Exactly.

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sat, 17 May 2003 09:18:18 -0700

Based on Gregory's comments and talking to Charlie, I revised my 
IKEv2 algorithms document. It's now at 
<ftp://ftp.ietf.org/internet-drafts/draft-hoffman-ipsec-algorithms-02.txt>. 
The major change was to move the MODP groups from the main IKEv2 
document into the algorithms document, but I also corrected the typos 
that Greogy pointed out and updated the reference to RFC 3526 and 
made the IANA considerations clearer.

>highlighting the "MUST Later" stuff.

I'm willing to do that if people want it, but I don't consider it all 
that hard for someone reading the document to look at the paragraph 
after the table to figure out the MUST and SHOULD requirements.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Yoav Nir" <[email-masked]>
Date: Sun, 18 May 2003 11:27:35 +0200

Hi Paul.

Sorry I didn't ask about this earlier.  With some vendors already offering
AES with larger keys (192- and 256-bit), why aren't there numbers assigned
for these transforms (section 2.1)

Also, in the same section, you have the following:
For IKEv2, ENCR_3DES (3) MUST be implemented and ENCR_AES_128_CBC (12)
SHOULD be implemented.

However, the number for ENCR_AES_128_CBC is 10, not 12.

Similarly, in section 2.3, the number of AUTH_AES_XCBC_96 is 4, not 5.

Yoav Nir

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Paul Hoffman / VPNC
Sent: Saturday, May 17, 2003 6:18 PM
To: [email-masked]
Subject: More on algorithms for IKEv2

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 23 May 2003 05:35:31 -0700

>for these transforms (section 2.1)

Thank you for highlighting a problem that the WG doesn't seem to have 
noticed before now. The WG needs to decide how to specify the key 
length for AES. We now have WG documents that do this in two 
different ways: with the Key Length attribute in IKEv1 and IKEv2, or 
with a different identifier for each of the three key lengths.

draft-ietf-ipsec-ciph-aes-cbc-05.txt for AES in CBC mode says:

    5.3 Key Length Attribute

    Since the AES allows variable key lengths, the Key Length attribute
    MUST be specified in both a Phase 1 exchange [IKE] and a Phase 2
    exchange [DOI].

draft-ietf-ipsec-ciph-aes-ctr-03.txt for AES in CTR mode says:

    9. IANA Considerations

    IANA has assigned three ESP transform numbers for use with AES-CTR
    with an explicit IV, one for each AES key size:

       <TBD1> for AES-CTR with a 128 bit key;
       <TBD2> for AES-CTR with a 192 bit key; and
       <TBD3> for AES-CTR with a 256 bit key.

I propose that the WG standardize on one method. Given that there are 
a fair number of deployed implementations of 
draft-ietf-ipsec-ciph-aes-cbc but few or none of 
draft-ietf-ipsec-ciph-aes-ctr, it seems like 
draft-ietf-ipsec-ciph-aes-ctr should be changed to use the method 
that has already been deployed.

Thoughts?

--Paul Hoffman, Director
--VPN Consortium