Group Security Policy Token v1
Note: This ballot was opened for revision 06 and is now closed.
(Russ Housley) Yes
(Brian Carpenter) (was Discuss) No Objection
The extra words in the introduction in -06 sort-of take care of the protocol problem (3) but I can foresee difficulties if this ever comes up for consideration as Draft Standard. I think the changes in the -06 version are at the absolute minimum level to deal with the ASN.1 extensibility problems (1) and (2). I'm sure Sam is correct that there may be future scenarios where the ASN.1 parse fails in some implementations attempting to join a group. However, my expertise in this area is fairly limited, so I will switch to no-objection and wish the implementors and users the best of luck.
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ted Hardie) No Objection
(Scott Hollenbeck) No Objection
(Allison Mankin) No Objection
(Jon Peterson) No Objection
(Mark Townsley) No Objection
(Bert Wijnen) No Objection
(Alex Zinin) No Objection
(Sam Hartman) Abstain
Comment (2006-01-17 for -** No value found for 'p.get_dochistory.rev' **)
I'm abstaining on this draft because I believe that the mechanism described is fundamentally too complicated for reasonable implementation. I think this mechanism embodies an extension of a design philosophy we tried with the first version of IPsec: very extensible. Implementation experience has caused us to back off from that design philosophy significantly with RFC 3401 and surrounding documents. I believe that multicast security is more complicated and thus requires more effort spent avoiding unnecessary complexity and testing all the options not less. The following are issues that would probably justify a discuss. At least at this point I'm not going to hold a discuss on these issues because I think the document would still be a incorrect approach if these issues are fixed and because I do not want to spend the time fixing these issues. Other ADs may wish to consider whether they wish to file a discuss on these issues. 1) Misuse of ASN.1. The document cites the 1997 ASN.1, but has a number of choices and structures that seem like they are intended to be extended in the future. Without extensibility markers, a conforming implementation will reject a sequence or choice with elements not permitted by the abstract syntax. 2) There is no extensibility or versioning strategy described in the document. How do we add fields? What should recipients of a token do if they do not understand part of it? 3) It's not clear that the GSAKMP document combined with this document provides enough mandatory to implement features that any two implementations of this specification will work together. The GSAKMP document specifies mandatory to implement mechanisms for GSAKMP. However the policy token allows for a wide variety of combinations of protocols. For example, a policy token could specify one protocol for registration, one protocol for rekey, and a completely different protocol for de-registration. If only one of these is GSAKMP, what happens? Where is it specified what combinations a GM, a GC/KS etc must support in terms of policy token contents? However my concern with the document is deeper than these actionable discuss issues. It seems that there are too many options for this system to be reasonably configured by operators or users. Here are some questions to guide thought about where there might be too many options. Why do you need the ability to use completely different registration, de-registration and rekey protocols? Wouldn't it be sufficient to say that you use GSAKMP (or some other protocol) for all the operations. Possibly you would have a way to say that some operations are not needed. Why do you need to specify separate signing algorithms and hashes for every operation? Why would you want the ability to have a different signature for parts of de-registration than for registration? Why are there so many different points at which a single trust anchor CA is specified yet no mechanism is provided to get the key corresponding to the key identifier? Why do you need different CA trust anchors at every point? What's wrong with using a single trust infrastructure for registration and de-registration? Why does the policy token need to be so generic; would we not be better off making it GSAKMP specific? Is the naming architecture and authorization architecture the right balance of flexible and easy to use?