Skip to main content

RPCSEC_GSS Version 2
RFC 5403

Yes

Lars Eggert

No Objection

(Cullen Jennings)
(David Ward)
(Lisa Dusseault)
(Mark Townsley)
(Pasi Eronen)
(Ron Bonica)
(Ross Callon)
(Russ Housley)

Note: This ballot was opened for revision 06 and is now closed.

Lars Eggert
Yes
Chris Newman Former IESG member
No Objection
No Objection (2008-09-25)
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 IESG member
No Objection
No Objection ()

                            
Dan Romascanu Former IESG member
(was Discuss) No Objection
No Objection (2008-09-24)
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 IESG member
No Objection
No Objection ()

                            
Jari Arkko Former IESG member
No Objection
No Objection (2008-09-25)
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 IESG member
No Objection
No Objection ()

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (2008-09-23)
There are no reference to XDR in the first occurrence in section 1.
Mark Townsley Former IESG member
No Objection
No Objection ()

                            
Pasi Eronen Former IESG member
(was Discuss, No Objection) No Objection
No Objection ()

                            
Ron Bonica Former IESG member
No Objection
No Objection ()

                            
Ross Callon Former IESG member
No Objection
No Objection ()

                            
Russ Housley Former IESG member
No Objection
No Objection ()

                            
Tim Polk Former IESG member
No Objection
No Objection (2008-09-25)
I support Pasi's discuss.  I have no other objections to the document.