RPCSEC_GSS Version 2
RFC 5403
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Lars Eggert Yes
(Chris Newman; former steering group member) No Objection
Boilerplate: This is an IESG comment and should be treated in a similar fashion to an IETF last call comment from any IETF participant. This comment does not prevent advancement of your document through the IETF process. However, it may contain suggestions to improve the document, and it is polite to consider those suggestions. I support Pasi's Discuss. Section 3.3, second bullet: I suggest you also reference the IANA registry "Hash Function Textual Names" to help find new hash functions as they're defined. General Concern: A test vector or two would greatly improve this document. While I have an adequate understanding of XDR, hash functions, channel bindings, ASN.1 and Kerberos, I'm skeptical that I would correctly implement this protocol on the first try. There are a lot of important details in prose (such as hashing the channel bindings) that leave room for implementation errors. Protocols like this can gain a bad reputation from implementation errors unless there is a reference implementation or test vector that implementers can use for validation to catch errors before they're released in the wild.
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) (was Discuss) No Objection
The acrnym GSS is never expanded in the document. I suggest to expand it at the first occurence in the Abstract or Introduction section.
(David Ward; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
Review by Chris Vogt: This document describes updates to the RPCSEC_GSS protocol that enable channel binding between the RPCSEC_GSS protocol and secure channels at lower layers. The document assumes that the reader is very familiar with implementation-specific details of the RPCSEC_GSS protocol. The document is not understandable to a reader without such detailed knowledge. The reason is that the document specifies protocol updates mostly in terms of pseudo-code fragments. The pseudo-code fragments may make sense to an RPCSEC_GSS protocol implementor, but they bear little information to a reader unfamiliar with the RPCSEC_GSS protocol's implementation specifics. Making the document plausible for the average reader would require major rewriting of this document. To avoid such rewriting but still ensure that the document is unambiguous for implementation purposes, I suggest to have the document reviewed by implementers who have worked with the RPCSEC_GSS protocol. Based on such a review, an informed decision could be made on whether or not to publish this document in its current form.
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
There are no reference to XDR in the first occurrence in section 1.
(Mark Townsley; former steering group member) No Objection
(Pasi Eronen; former steering group member) (was Discuss, No Objection) No Objection
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
I support Pasi's discuss. I have no other objections to the document.