Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
draft-ietf-secsh-gsskeyex-10
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.