Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
Note: This ballot was opened for revision 10 and is now closed.
(Sam Hartman) (was No Objection, Discuss, Yes) Yes
(Brian Carpenter) No Objection
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.
(Margaret Cullen) No Objection
(Bill Fenner) No Objection
(Ted Hardie) No Objection
(Scott Hollenbeck) No Objection
(Russ Housley) No Objection
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.