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

IANA Comments:
Upon approval of this document the IANA will proceed with the following actions:

REGISTER 2 Key Exchange Method Names
RESERVE 1 Key Exchange Method Name

REGSITER 1 Public Key Algorithm Name

REGSITER 2 Authentication Method Names
RESERVE 2 Authentication Method Names

These registrations will all go in the registries found at the following:
http://www.iana.org/assignments/ssh-parameters

[Ballot comment]
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.

[Ballot comment]
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.

During last call, one significant issue was raised.  There was a
concern that the spec is silent on what to do if the hostname is
unknown or cannot be determined.  After discussion on the working
group list, this issue is addressed with the included rfc-editor note.

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The document has been reviewed by implementors in the WG; members of the
IETF GSSAPI community have come to this WG to review the work.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The document is of interest to a subset of the WG and the ssh-using
community but that subset is solidly behind it.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

Some nits were discovered (references in the abstract and a typo); a -10
version should surface shortly to address them.

  1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

References are split.  All referenced ID's are either in the RFC Editor
Queue or before the IESG already.

  1.ijk) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

This document describes an extension to the Secure Shell protocol
allowing the use of GSSAPI security services for authentication and key
exchange.

        *    Working Group Summary

There was smooth consensus in the working group to publish this as a
Proposed Standard

        *    Protocol Quality

The WG chair is aware of multiple interoperable implementations.