Cryptographic Suites for IPsec
Note: This ballot was opened for revision 06 and is now closed.
(Steven Bellovin) Yes
(Russ Housley) (was Discuss) Yes
(Jon Peterson) Yes
(Harald Alvestrand) No Objection
Comment (2004-04-01 for -)
draft-ietf-ipsec-ui-suites was reviewed by John Loughney, Gen-ART. He pointed out that this document does NOT define an IANA registry for suite names, and that it's extremely unclear how (or if) suite names should be "registered" in the future. Given the amount of "reservation" of the strings "VPN-A" and "VPN-B" the document tries to do, that's odd. Complete review entered as a document comment.
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ted Hardie) No Objection
Comment (2004-03-31 for -)
The comment below on MUST- and SHOULD- was discussed further with Paul Hoffman, and my comment has been addressed; being left in the record for completeness. In algorithms, MUST- and SHOULD- are defined but not used. I can see the need for completeness with SHOULD+, but given the unwieldy nature of these terms, it's a bit unfortunate. Could these be defined when needed, after some experience with whether SHOULD+ helps? I believe it would be useful the suites document to suggest a name for the IANA registry. NITS: In UI suites, section 2: This section lists optional, non-mandatory suites that be presented to -->may be presented? In UI suites, Section 2.2 This suite is what many people expect the commonly-used corporate VPN security that will be used within a few years of the time this document is being written. -->This suite is what many people expect the commonly-used coporate VPN security profile wil be within a few years of the time of this document's publication?
(Scott Hollenbeck) No Objection
Comment (2004-03-25 for -)
I would suggest expanding the UI acronym on first use in draft-ietf-ipsec-ui-suites.
(David Kessens) No Objection
(Allison Mankin) No Objection
(Thomas Narten) (was Discuss) No Objection
In draft-ietf-ipsec-ikev2-algorithms-04.txt The scope of this document could be a bit clearer, i.e, that the transforms are about IKE, and not IPsec. Rewording suggestion. Change: > The Internet Key Exchange protocol provides for the negotiation of > cryptographic algorithms between both end points of a cryptographic > association. Different implementations of IPSec and IKE may provide > different algorithms. However the IETF desires that all implementations > should have some way to interoperate. This requires that some set of > algorithms be specified as "mandatory to implement." To something like: The Internet Key Exchange protocol provides for the negotiation of cryptographic algorithms between both end points of a cryptographic association. Different implementations of IPSec and IKE may provide different algorithms. However the IETF desires that all implementations should have some way to interoperate. In particular, this requires that IKE define a set of mandatory-to-implement algorithms, since IKE itself uses such algorithms as part of its own negotiations. This requires that some set of algorithms be specified as "mandatory to implement" for IKE. > Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to > negotiate which algorithms should be used in any even association. what does "in any even association" mean? > is necessary to specify a set of mandatory to implement algorithms to mandatory-to-implement (multiple places) > available. This document defines the current set of mandatory to > implement algorithms for use of IKEv2 as well as specifying algorithms > that should be implemented because they made be promoted to mandatory > at some future time. what does it mean "for use of"? to allow IKEv2 itself to negotiate phase II? Suggested reword: This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time. > There are several MODP groups that are defined for use in IKEv2. They expand/define MODP?