Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
draft-ietf-secsh-gsskeyex-10

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

(Sam Hartman; former steering group member) (was No Objection, Discuss, Yes) Yes

Yes ()
No email
send info

(Alex Zinin; former steering group member) No Objection

No Objection ()
No email
send info

(Allison Mankin; former steering group member) No Objection

No Objection ()
No email
send info

(Bert Wijnen; former steering group member) No Objection

No Objection ()
No email
send info

(Bill Fenner; former steering group member) No Objection

No Objection ()
No email
send info

(Brian Carpenter; former steering group member) No Objection

No Objection (2005-08-31)
No email
send info
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 steering group member) No Objection

No Objection ()
No email
send info

(Jon Peterson; former steering group member) No Objection

No Objection ()
No email
send info

(Margaret Cullen; former steering group member) No Objection

No Objection ()
No email
send info

(Mark Townsley; former steering group member) No Objection

No Objection ()
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection (2005-08-29)
No email
send info
  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 steering group member) No Objection

No Objection ()
No email
send info

(Ted Hardie; former steering group member) No Objection

No Objection ()
No email
send info