GSAKMP: Group Secure Association Key Management Protocol
RFC 4535
Note: This ballot was opened for revision 10 and is now closed.
(Russ Housley) Yes
Comment (2005-01-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
send info
Section 7.7.2 says: > > Certificate Data - This Certificate Data MUST be processed according to > the certificate type specified. The type will define the format of the > data. Receipt of a root CA certificate in a Certificate payload causes > the payload to be discarded. This received certificate MUST NOT be used > to verify the message. The root CA certificate MUST be retrieved by > other means. > Please say "certificate of the trusted policy creation authority" instead of "root CA certificate."
(Brian Carpenter) No Objection
Comment (2005-03-31 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
send info
Lots or review comments from John Loughney, but none of them look like show-stoppers: Review of draft-ietf-msec-gsakmp-sec-08.txt Summary: This is generally ready for publication as a proposed standard. The Vendor ID Payload is my biggest open issue, however I am not sure how this should be resolved. Some nits were found, but these could be updated if the document is revised. The document was well written and I appreciated the list of figures and tables. Please note that this is an area outside of my area of expertise, so I assume that the terminology, etc. are well known within the documents target audience. One general request that I would have would be the expansion of acronyms in section titles, such as: 4.4.2 Creation of a PT - would become: 4.4.2 Creation of a Policy Token Just as there is a lot of acronyms and I found that I had to keep refering back to Chapter 2 Terminology (which doesn't contain all fo the acronyms, by the way). Questions: 1) Section "3.2.3 LKH" says: When group policy dictates that a recovery of the group security is necessary after the discovery of the compromise of a GM, then GSAKMP relies upon a rekey capability, i.e., LKH, to enable group recovery after a compromise [RFC 2627]. This is optional since in many instances it may be better to destroy the compromised group and rebuild a secure group. but then section "3.4 Rekey Availability" In addition to GSAKMP having the capability to do rekey operations, GSAKMP MUST also have the capability to make this rekey information highly available to GMs. The necessity of GMs receiving rekey messages, requires the use of methods to increase the likelihood of receipt of Rekey Messages. These methods MAY include multiple transmissions of the rekey message, posting of the rekey message on a bulletin board, etc. Compliant GSAKMP implementations MUST support retransmission of rekey messages. Section 3.2.3 seems to indicate that rekeying is optional but 3.4 has a MUST for the retransmission of rekey messaging. My question is, is the rekeying operation mandatory or optional? Or is it just that after a group is compromised, it is optional to rekey, as it may be preferable to destroy the group entirely? The current text is not so clear. 2) General question on Vendor-ID payload, secton 7.10: Writers of Internet-Drafts who wish to extend this protocol MUST define a Vendor ID payload to announce the ability to implement the extension in the Internet-Draft. It is expected that Internet-Drafts which gain acceptance and are standardized will be given assigned values out of the Reserved to IANA range and the requirement to use a Vendor ID payload will go away. I had a little trouble parsing this. Does this mean that Vendor-IDs should generally be written-up as Internet drafts? Should there be a registry for the vendor payloads? Additionally, the packet format doesn't say what the VID is. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Vendor ID (VID) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Should this be using the IANA assigned "SMI Network Management Private Enterprise Codes"? Small nits: 1) Shouldn't Abstract be left justified? 2) Text needs to be indented in most places. 3) Double spacing before and after section headings should be changed to single spacing. 4) CRL is used in section 3.1, item 8, but I couldn't find an expansion on what CRL is. 5) Expansion of some protocols like ISAKMP, FIPS Pub 196, LKH etc. would be helpful. 6) In many places, the ` is used, shouldn't ' be used instead? Also, `` and '' is used, but shouldn't " be used instead? Ran idnits script and found the following nits: idnits 1.61 Checking nits according to http://www.ietf.org/ID-Checklist.html : Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? * The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure Acknowledgement. * The document seems to lack an RFC 3979 Section 5, para 2 IPR Disclosure Acknowledgement. * The document seems to lack an RFC 3979 Section 5, para 3 IPR Disclosure Invitation. * There are 1222 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt : * The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Miscellaneous warnings: - The "Author's Address" (or "Authors' Addresses") section title is misspelled. Run idnits with the --verbose option for more detailed information.
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ted Hardie) No Objection
Comment (2005-01-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
send info
In 7.6.1, the draft says: DN Data (variable length) -- The actual UTF-8 DN value (Subject field) using the slash (/) character for field delimiters. (e.g., "/C=US/ST=MD/L=Somewhere/O=ACME, Inc./OU=DIV1/CN=user1/Email=user1@acme.com" without the surrounding quotes) Would it be beneficial to add a pointer to the specific DN format required here? I'm thinking, for example, of the discussion we just had relative to draft-ietf-ldapbis-dn-15.txt.
(Sam Hartman) (was Discuss) No Objection
Comment (2005-01-20)
No email
send info
send info
This protocol contains many optional out of band features like eviction of members. Similarly, finding subordinate GC/KS may be challenging. It will be difficult to get multiple interoperable implementations of all these features and advance the protocol to draft standard. I'm surprised that the protocol mandates neither AES nor RSA. The protocol does a good job of meeting its requirements and for relatively high security need/high infrastructure group management this protocol is a good fit. I think the IETF has need of a group SA management protocol that works in less rigorous environments. AS an example I don't think this protocol would be appropriate for OSPF v3 or for other routing/ops area needs. I think that the same pressures that required us to add EAP support to IKEV2 will require us to provide a group management protocol that supports whatever credentials the deployment environment happens to have. It's not a problem with this protocol that those needs are not met; we just have more work to do. Also, I realize that making a variant of this protocol that met those needs would be relatively easy.
(Scott Hollenbeck) No Objection
(David Kessens) No Objection
(Allison Mankin) (was Discuss) No Objection
Comment (2005-04-09)
No email
send info
send info
sent: Sent: Russ, Ran and Lakshminath, The new IANA rules make the extensibility much more appropriate to the protocol security. Thanks! I've copied IANA so that the change can be flagged, since I instigated it. Since you have specified Expert Review for some of the fields, I want to draw your attention to a suggestion: it's a good thing to appoint the Expert Reviewer (or two, a Primary and Secondary) now, before the approval goes out, and have it included in the IANA Note on the announcement, so this important step gets handled very transparently (and not forgotten). My clearing isn't gated on it (I'm done, bye :) I'm suggesting you guys and IANA get this done before Russ sends in the final approve... Not sent: I re-reviewed Vendor ID - it seems safe enough to me; it seems an unscrupulous extender would not exploit it very easily.