RE: More on algorithms for IKEv2
"Yoav Nir" <ynir@CheckPoint.com> Sun, 18 May 2003 10:17 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05887 for <ipsec-archive@lists.ietf.org>; Sun, 18 May 2003 06:17:00 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA27607 Sun, 18 May 2003 04:23:45 -0400 (EDT)
From: Yoav Nir <ynir@CheckPoint.com>
To: 'Paul Hoffman / VPNC' <paul.hoffman@vpnc.org>, ipsec@lists.tislabs.com
Subject: RE: More on algorithms for IKEv2
Date: Sun, 18 May 2003 11:27:35 +0200
Message-ID: <003201c31d1f$b825c2e0$292e1dc2@YnirNew>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <p0521060bbaec10159ead@[63.202.92.152]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit
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: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC Sent: Saturday, May 17, 2003 6:18 PM To: ipsec@lists.tislabs.com Subject: More on algorithms for IKEv2 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. On thing that Gregory asked for that I didn't do (yet) is: > > >- 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. 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
- RE: feedback on algorithms-00 Gregory Lebovitz
- More on algorithms for IKEv2 Paul Hoffman / VPNC
- RE: More on algorithms for IKEv2 Yoav Nir
- How will we specify AES key lengths? Paul Hoffman / VPNC