Protocol Action: 'GSSAPI Authentication and Key Exchange for the Secure Shell Protocol' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'GSSAPI Authentication and Key Exchange for the Secure Shell Protocol '
   <draft-ietf-secsh-gsskeyex-10.txt> as a Proposed Standard

This document is the product of the Secure Shell Working Group. 

The IESG contact persons are Sam Hartman and Russ Housley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-10.txt

Technical Summary
 
   This document describes an extension to the Secure Shell protocol
   allowing the use of GSSAPI security services for authentication and
   key exchange. It also defines a null hostkey algorithm to allow ssh
   to be used by systems that do not have a host key.
 
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.
   This document has been reviewed by Sam Hartman for the IESG.


Note to RFC Editor

Insert in section 3.2 just before the last paragraph which begins "The client
may at any time.":
   Note that the 'username' value is encoded in ISO-10646 UTF-8.  It
   is up to the server how it interprets the username and determines
   whether the client is authorized based on his GSSAPI credentials
   In particular, the encoding used by the system for user names is
   a matter for the ssh server implementation.  However, if the client
   reads the username in some other encoding (e.g., ISO 8859-1 - ISO
   Latin1), it MUST convert the username to ISO-10646 UTF-8 before
   transmitting, and the server MUST convert the username to the
   encoding used on that system for user names.

   Any normalization or other preparation of names is done by the ssh
   server based on the requirements of the system, and is outside the
   scope of SSH.  SSH implementations which maintain private user
   databases SHOULD prepare user names as described by [RFC4013].

Add to the end of section 7.1:
new:   Because the GSSAPI mechanism uses the targ_name to authenticate the
  server's identity, it is important that it be determined in a secure
  fashion.  One common way to do this is to construct the targ_name
  from the hostname as typed by the user; unfortunately, because some
  GSSAPI mechanisms do not canonicalize hostnames, it is likely that
  this technique will fail if the user has not typed a fully-qualified,
  canonical hostname.  Thus, implementors may wish to use other methods,
  but should take care to insure they are secure.  For example, one
  should not rely on an unprotected DNS record to map a host alias to
  the primary name of a server, or an IP address to a hostname, since
  an attacker can modify the mapping and impersonate the server.

  Implementations of mechanisms conforming to this document MUST NOT use
  the results of insecure DNS queries to construct the targ_name.  Clients
  MAY make use of a mapping provided by local configuration or use
  other secure means to determine the targ_name to be used.  If a client
  system is unable to securely determine which targ_name to use, then it
  SHOULD NOT use this mechanism.


_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce