Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
draft-ietf-secsh-gsskeyex-10
Yes
(Sam Hartman)
No Objection
(Alex Zinin)
(Allison Mankin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Mark Townsley)
(Scott Hollenbeck)
(Ted Hardie)
Note: This ballot was opened for revision 10 and is now closed.
Sam Hartman Former IESG member
(was No Objection, Discuss, Yes)
Yes
Yes
()
Unknown
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Allison Mankin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
(2005-08-31)
Unknown
Needs a sentence added in section 3.2 indicating that UTF-8 normalization of names occurs at the authorizing server and outside the scope of SSH. Original comment from review by David Black: I found one nit that needs attention. Section 3.2 of the draft uses UTF-8 for a "user name" string but doesn't say what the applicable Unicode character usage and normalization (stringprep) requirements are. I believe that this problem is already addressed via use of the SASL stringprep profile in the SSH-USERAUTH draft, so a sentence pointing out the (obvious) fact that "user name" is an SSH user name, and hence is subject to the SSH-USERAUTH draft's requirements on SSH user names, including appropriate use of stringprep should suffice. Clarification by Bill Sommerfeld: The client prepares the username in UTF-8 format without need for any normalization. The server (which is a client of the notional user account database) applies the stringprep or other canonicalization required to match the encoding conventions of that database. Comment by Jeff Hutzleman after dialogue with Sam: My main concern is that we not encourage ssh server implementations to normalize usernames passed to the OS in a way that is incompatible with how the OS treats usernames.
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2005-08-29)
Unknown
Since Base64 Encoding is used, but all of MIME is not used, it is probably better to replace [MIME] with a reference to RFC 3548. Please delete section 11 prior to publication as an RFC.
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
()
Unknown