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@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
