Because the GSS-API 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
GSS-API 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, implementers may wish to use other
methods, but should take care to ensure 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.
7.2. Channel Bindings
This document recommends that channel bindings SHOULD NOT be
specified in the calls during context establishment. This document
does not specify any standard data to be used as channel bindings,
and the use of network addresses as channel bindings may break SSH in
environments where it is most useful.
7.3. SPNEGO
The use of the Simple and Protected GSS-API Negotiation Mechanism
[SPNEGO] in conjunction with the authentication and key exchange
methods described in this document is both unnecessary and
undesirable. As a result, mechanisms conforming to this document
MUST NOT use SPNEGO as the underlying GSS-API mechanism.
Since SSH performs its own negotiation of authentication and key
exchange methods, the negotiation capability of SPNEGO alone does not
provide any added benefit. In fact, as described below, it has the
potential to result in the use of a weaker method than desired.
Normally, SPNEGO provides the added benefit of protecting the GSS-API
mechanism negotiation. It does this by having the server compute a
MIC of the list of mechanisms proposed by the client, and then
checking that value at the client. In the case of key exchange, this
protection is not needed because the key exchange methods described
here already perform an equivalent operation; namely, they generate a
MIC of the SSH exchange hash, which is a hash of several items
including the lists of key exchange mechanisms supported by both
sides. In the case of user authentication, the protection is not
needed because the negotiation occurs over a secure channel, and the
host’s identity has already been proved to the user.
The use of SPNEGO combined with GSS-API mechanisms used without
SPNEGO can lead to interoperability problems. For example, a client
that supports key exchange using the Kerberos V5 GSS-API mechanism
[KRB5-GSS] only underneath SPNEGO will not interoperate with a server
that supports key exchange only using the Kerberos V5 GSS-API
mechanism directly. As a result, allowing GSS-API mechanisms to be
used both with and without SPNEGO is undesirable.
If a client’s policy is to first prefer GSS-API-based key exchange
method X, then non-GSS-API method Y, then GSS-API-based method Z, and
if a server supports mechanisms Y and Z but not X, then an attempt to
use SPNEGO to negotiate a GSS-API mechanism might result in the use
of method Z when method Y would have been preferable. As a result,
the use of SPNEGO could result in the subversion of the negotiation
algorithm for key exchange methods as described in Section 7.1 of
[SSH-TRANSPORT] and/or the negotiation algorithm for user
authentication methods as described in [SSH-USERAUTH].
8. IANA Considerations
Consistent with Section 8 of [SSH-ARCH] and Section 4.6 of
[SSH-NUMBERS], this document makes the following registrations:
The family of SSH key exchange method names beginning with "gss-
group1-sha1-" and not containing the at-sign (’@’), to name the
key exchange methods defined in Section 2.3.
The family of SSH key exchange method names beginning with "gss-
gex-sha1-" and not containing the at-sign (’@’), to name the key
exchange methods defined in Section 2.5.
All other SSH key exchange method names beginning with "gss-" and
not containing the at-sign (’@’), to be reserved for future key
exchange methods defined in conformance with this document, as
noted in Section 2.6.
The SSH host public key algorithm name "null", to name the NULL
host key algorithm defined in Section 5.
The SSH user authentication method name "gssapi-with-mic", to name
the GSS-API user authentication method defined in Section 3.
The SSH user authentication method name "gssapi-keyex", to name
the GSS-API user authentication method defined in Section 4.
The SSH user authentication method name "gssapi" is to be
reserved, in order to avoid conflicts with implementations
supporting an earlier version of this specification.
The SSH user authentication method name "external-keyx" is to be
reserved, in order to avoid conflicts with implementations
supporting an earlier version of this specification.
This document creates no new registries.
9. Security Considerations
This document describes authentication and key-exchange protocols.
As such, security considerations are discussed throughout.
This protocol depends on the SSH protocol itself, the GSS-API, any
underlying GSS-API mechanisms that are used, and any protocols on
which such mechanisms might depend. Each of these components plays a
part in the security of the resulting connection, and each will have
its own security considerations.
The key exchange method described in Section 2 depends on the
underlying GSS-API mechanism to provide both mutual authentication
and per-message integrity services. If either of these features is
not supported by a particular GSS-API mechanism, or by a particular
implementation of a GSS-API mechanism, then the key exchange is not
secure and MUST fail.
In order for the "external-keyx" user authentication method to be
used, it MUST have access to user authentication information obtained
as a side-effect of the key exchange. If this information is
unavailable, the authentication MUST fail.
Revealing information about the reason for an authentication failure
may be considered by some sites to be an unacceptable security risk
for a production environment. However, having that information
available can be invaluable for debugging purposes. Thus, it is
RECOMMENDED that implementations provide a means for controlling, as
a matter of policy, whether to send SSH_MSG_USERAUTH_GSSAPI_ERROR,
SSH_MSG_USERAUTH_GSSAPI_ERRTOK, and SSH_MSG_KEXGSS_ERROR messages,
and SSH_MSG_KEXGSS_CONTINUE messages containing a GSS-API error
token.
10. Acknowledgements
The authors would like to thank the following individuals for their
invaluable assistance and contributions to this document:
o Sam Hartman
o Love Hornquist-Astrand
o Joel N. Weber II
o Simon Wilkinson
o Nicolas Williams
Much of the text describing DH group exchange was borrowed from
[GROUP-EXCHANGE], by Markus Friedl, Niels Provos, and William A.
Simpson.
11. References
11.1. Normative References
[ASN1] ISO/IEC, "ASN.1 Encoding Rules: Specification of
Basic Encoding Rules (BER), Canonical Encoding
Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690 (1997), ISO/
IEC 8825-1:1998, November 1998.
[GROUP-EXCHANGE] Friedl, M., Provos, N., and W. Simpson, "Diffie-
Hellman Group Exchange for the Secure Shell (SSH)
Transport Layer Protocol", RFC 4419, March 2006.
[GSSAPI] Linn, J., "Generic Security Service Application
Program Interface Version 2, Update 1", RFC 2743,
January 2000.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[LANGTAG] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[SSH-ARCH] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[SSH-CONNECT] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Connection Protocol", RFC 4254, January 2006.
[SSH-NUMBERS] Lehtinen, S. and C. Lonvick, "The Secure Shell
(SSH) Protocol Assigned Numbers", RFC 4250, January
2006.
[SSH-TRANSPORT] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, January 2006.
[SSH-USERAUTH] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
11.2. Informative References
[KRB5] Neuman, C., Yu, T., Hartman, S., and K. Raeburn,
"The Kerberos Network Authentication Service (V5)",
RFC 4120, July 2005.
[KRB5-GSS] Zhu, L., Jaganathan, K., and S. Hartman, "The
Kerberos Version 5 Generic Security Service
Application Program Interface (GSS-API) Mechanism:
Version 2", RFC 4121, July 2005.
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for
User Names and Passwords", RFC 4013, February 2005.
[SPNEGO] Zhu, L., Leach, P., Jaganathan, K., and W.
Ingersoll, "The Simple and Protected Generic
Security Service Application Program Interface
(GSS-API) Negotiation Mechanism", RFC 4178, October
2005.
Authors’ Addresses
Jeffrey Hutzelman
Carnegie Mellon University
5000 Forbes Ave
Pittsburgh, PA 15213
US
Phone: +1 412 268 7225
EMail: jhutz+@cmu.edu
URI: http://www.cs.cmu.edu/~jhutz/
Joseph Salowey
Cisco Systems
2901 Third Avenue
Seattle, WA 98121
US
Phone: +1 206 256 3380
EMail: jsalowey@cisco.com
Joseph Galbraith
Van Dyke Technologies, Inc.
4848 Tramway Ridge Dr. NE
Suite 101
Albuquerque, NM 87111
US
EMail: galb@vandyke.com
Von Welch
University of Chicago & Argonne National Laboratory
Distributed Systems Laboratory
701 E. Washington
Urbana, IL 61801
US
EMail: welch@mcs.anl.gov
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).