draft-ietf-secsh-gsskeyex-05.txt   draft-ietf-secsh-gsskeyex-06.txt 
Network Working Group J. Hutzelman Network Working Group J. Hutzelman
Internet-Draft CMU Internet-Draft CMU
Expires: May 4, 2003 J. Salowey Expires: August 31, 2003 J. Salowey
Cisco Systems Cisco Systems
J. Galbraith J. Galbraith
Van Dyke Technologies, Inc. Van Dyke Technologies, Inc.
V. Welch V. Welch
U Chicago / ANL U Chicago / ANL
November 3, 2002 March 2, 2003
GSSAPI Authentication and Key Exchange for the Secure Shell Protocol GSSAPI Authentication and Key Exchange for the Secure Shell Protocol
draft-ietf-secsh-gsskeyex-05 draft-ietf-secsh-gsskeyex-06
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 4, 2003. This Internet-Draft will expire on August 31, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
The Secure Shell protocol (SSH) is a protocol for secure remote The Secure Shell protocol (SSH) is a protocol for secure remote
login and other secure network services over an insecure network. login and other secure network services over an insecure network.
The Generic Security Service Application Program Interface (GSS-API) The Generic Security Service Application Program Interface (GSS-API)
[2] provides security services to callers in a mechanism-independent [2] provides security services to callers in a mechanism-independent
fashion. fashion.
This memo describes methods for using the GSS-API for authentication This memo describes methods for using the GSS-API for authentication
and key exchange in SSH. It defines an SSH user authentication and key exchange in SSH. It defines an SSH user authentication
method which uses a specified GSSAPI mechanism to authenticate a method which uses a specified GSSAPI mechanism to authenticate a
user, and a family of SSH key exchange methods which use GSSAPI to user, and a family of SSH key exchange methods which use GSSAPI to
authenticate the Diffie-Hellman exchange described in [11]. authenticate the Diffie-Hellman exchange described in [8].
This memo also defines a new host public key algorithm which can be This memo also defines a new host public key algorithm which can be
used when no operations are needed using a host's public key, and a used when no operations are needed using a host's public key, and a
new user authentication method which allows an authorization name to new user authentication method which allows an authorization name to
be used in conjunction with any authentication which has already be used in conjunction with any authentication which has already
occurred as a side-effect of key exchange. occurred as a side-effect of key exchange.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [7]. document are to be interpreted as described in [5].
1. Introduction 1. Introduction
This document describes the methods used to perform key exchange and This document describes the methods used to perform key exchange and
user authentication in the Secure Shell protocol using the GSSAPI. user authentication in the Secure Shell protocol using the GSSAPI.
To do this, it defines a family of key exchange methods, two user To do this, it defines a family of key exchange methods, two user
authentication methods, and a new host key algorithm. These authentication methods, and a new host key algorithm. These
definitions allow any GSSAPI mechanism to be used with the Secure definitions allow any GSSAPI mechanism to be used with the Secure
Shell protocol. Shell protocol.
This document should be read only after reading the documents This document should be read only after reading the documents
describing the SSH protocol architecture [9], transport layer describing the SSH protocol architecture [6], transport layer
protocol [11], and user authentication protocol [12]. This document protocol [8], and user authentication protocol [9]. This document
freely uses terminology and notation from the architecture document freely uses terminology and notation from the architecture document
without reference or further explanation. without reference or further explanation.
1.1 SSH terminology 1.1 SSH terminology
The data types used in the packets are defined in the SSH The data types used in the packets are defined in the SSH
architecture document [9]. It is particularly important to note the architecture document [6]. It is particularly important to note the
definition of string allows binary content. definition of string allows binary content.
The SSH_MSG_USERAUTH_REQUEST packet refers to a service; this The SSH_MSG_USERAUTH_REQUEST packet refers to a service; this
service name is an SSH service name, and has no relationship to service name is an SSH service name, and has no relationship to
GSSAPI service names. Currently, the only defined service name is GSSAPI service names. Currently, the only defined service name is
"ssh-connection", which refers to the SSH connection protocol [10]. "ssh-connection", which refers to the SSH connection protocol [7].
2. GSSAPI Authenticated Diffie-Hellman Key Exchange 2. GSSAPI Authenticated Diffie-Hellman Key Exchange
This section defines a class of key exchange methods which combine This section defines a class of key exchange methods which combine
the Diffie-Hellman key exchange from section 6 of [11] with mutual the Diffie-Hellman key exchange from section 6 of [8] with mutual
authentication using GSSAPI. authentication using GSSAPI.
Since the GSSAPI key exchange methods described in this section do Since the GSSAPI key exchange methods described in this section do
not require the use of public key signature or encryption not require the use of public key signature or encryption
algorithms, they MAY be used with any host key algorithm, including algorithms, they MAY be used with any host key algorithm, including
the "null" algorithm described in Section 5. the "null" algorithm described in Section 5.
2.1 Generic GSSAPI Key Exchange 2.1 Generic GSSAPI Key Exchange
The following symbols are used in this description: The following symbols are used in this description:
skipping to change at page 6, line 25 skipping to change at page 6, line 25
|| K_S || e || f || K). It then calls GSS_VerifyMIC to verify || K_S || e || f || K). It then calls GSS_VerifyMIC to verify
that the MIC sent by S matches H. that the MIC sent by S matches H.
Either side MUST NOT send or accept e or f values that are not in Either side MUST NOT send or accept e or f values that are not in
the range [1, p-1]. If this condition is violated, the key exchange the range [1, p-1]. If this condition is violated, the key exchange
fails. fails.
If any call to GSS_Init_sec_context or GSS_Accept_sec_context If any call to GSS_Init_sec_context or GSS_Accept_sec_context
returns a major_status other than GSS_S_COMPLETE or returns a major_status other than GSS_S_COMPLETE or
GSS_S_CONTINUE_NEEDED, or any other GSSAPI call returns a GSS_S_CONTINUE_NEEDED, or any other GSSAPI call returns a
major_status other than GSS_S_COMPLETE, the key exchange fails. If major_status other than GSS_S_COMPLETE, the key exchange fails. In
the key exchange fails due to a GSSAPI error on the server, the this case, several mechanisms are available for communicating error
server SHOULD send a message informing the client of the details of information to the peer before terminating the connection as
the error before terminating the connection as required by [11]. required by [8]:
o If the key exchange fails due to any GSSAPI error on the server
(including errors returned by GSS_Accept_sec_context), the server
MAY send a message informing the client of the details of the
error. In this case, if an error token is also sent (see below),
then this message MUST be sent before the error token.
o If the key exchange fails due to a GSSAPI error returned from the
server's call to GSS_Accept_sec_context, and an "error token" is
also returned, then the server SHOULD send the error token to the
client to allow completion of the GSS security exchange.
o If the key exchange fails due to a GSSAPI error returned from the
client's call to GSS_Init_sec_context, and an "error token" is
also returned, then the client SHOULD send the error token to the
server to allow completion of the GSS security exchange.
As noted in Section 9, it may be desirable under site security
policy to obscure information about the precise nature of the error;
thus, it is RECOMMENDED that implementations provide a method to
suppress these messages as a matter of policy.
This is implemented with the following messages. The hash algorithm This is implemented with the following messages. The hash algorithm
for computing the exchange hash is defined by the method name, and for computing the exchange hash is defined by the method name, and
is called HASH. The group used for Diffie-Hellman key exchange and is called HASH. The group used for Diffie-Hellman key exchange and
the underlying GSSAPI mechanism are also defined by the method name. the underlying GSSAPI mechanism are also defined by the method name.
After the client's first call to GSS_Init_sec_context, it sends the After the client's first call to GSS_Init_sec_context, it sends the
following: following:
byte SSH_MSG_KEXGSS_INIT byte SSH_MSG_KEXGSS_INIT
skipping to change at page 7, line 6 skipping to change at page 7, line 27
byte SSH_MSG_KEXGSS_HOSTKEY byte SSH_MSG_KEXGSS_HOSTKEY
string server public host key and certificates (K_S) string server public host key and certificates (K_S)
Since this key exchange method does not require the host key to be Since this key exchange method does not require the host key to be
used for any encryption operations, this message is OPTIONAL. If used for any encryption operations, this message is OPTIONAL. If
the "null" host key algorithm described in Section 5 is used, this the "null" host key algorithm described in Section 5 is used, this
message MUST NOT be sent. If this message is sent, the server message MUST NOT be sent. If this message is sent, the server
public host key(s) and/or certificate(s) in this message are encoded public host key(s) and/or certificate(s) in this message are encoded
as a single string, in the format specified by the public key type as a single string, in the format specified by the public key type
in use (see [11], section 4.6). in use (see [8], section 4.6).
Each time the server's call to GSS_Accept_sec_context returns a Each time the server's call to GSS_Accept_sec_context returns a
major_status code of GSS_S_CONTINUE_NEEDED, it sends the following major_status code of GSS_S_CONTINUE_NEEDED, it sends the following
reply to the client: reply to the client:
byte SSH_MSG_KEXGSS_CONTINUE byte SSH_MSG_KEXGSS_CONTINUE
string output_token (from GSS_Accept_sec_context) string output_token (from GSS_Accept_sec_context)
If the client receives this message after a call to If the client receives this message after a call to
GSS_Init_sec_context has returned a major_status code of GSS_Init_sec_context has returned a major_status code of
skipping to change at page 8, line 19 skipping to change at page 8, line 34
byte SSH_MSG_KEXGSS_COMPLETE byte SSH_MSG_KEXGSS_COMPLETE
mpint f mpint f
string per_msg_token (MIC of H) string per_msg_token (MIC of H)
boolean FALSE boolean FALSE
If the client receives this message when no call to If the client receives this message when no call to
GSS_Init_sec_context has yet resulted in a major_status code of GSS_Init_sec_context has yet resulted in a major_status code of
GSS_S_COMPLETE, a protocol error has occurred and the key exchange GSS_S_COMPLETE, a protocol error has occurred and the key exchange
MUST fail. MUST fail.
In the event of a GSSAPI error on the server, the server may send If either the client's call to GSS_Init_sec_context or the server's
call to GSS_Accept_sec_context returns an error status and produces
an output token (called an "error token"), then the following SHOULD
be sent to convey the error information to the peer:
byte SSH_MSG_KEXGSS_CONTINUE
string error_token
If a server sends both this message and an SSH_MSG_KEXGSS_ERROR
message, the SSH_MSG_KEXGSS_ERROR message MUST be sent first, to
allow clients to record and/or display the error information before
processing the error token. This is important because a client
processing an error token will likely disconnect without reading any
further messages.
In the event of a GSSAPI error on the server, the server MAY send
the following message before terminating the connection: the following message before terminating the connection:
byte SSH_MSG_KEXGSS_ERROR byte SSH_MSG_KEXGSS_ERROR
uint32 major_status uint32 major_status
uint32 minor_status uint32 minor_status
string message string message
string language tag string language tag
The message text MUST be encoded in the UTF-8 encoding described in The message text MUST be encoded in the UTF-8 encoding described in
[13]. Language tags are those described in [14]. Note that the [10]. Language tags are those described in [11]. Note that the
message text may contain multiple lines separated by carriage message text may contain multiple lines separated by carriage
return-line feed (CRLF) sequences. Application developers should return-line feed (CRLF) sequences. Application developers should
take this into account when displaying these messages. take this into account when displaying these messages.
The hash H is computed as the HASH hash of the concatenation of the The hash H is computed as the HASH hash of the concatenation of the
following: following:
string V_C, the client's version string (CR and NL excluded) string V_C, the client's version string (CR and NL excluded)
string V_S, the server's version string (CR and NL excluded) string V_S, the server's version string (CR and NL excluded)
string I_C, the payload of the client's SSH_MSG_KEXINIT string I_C, the payload of the client's SSH_MSG_KEXINIT
skipping to change at page 9, line 9 skipping to change at page 9, line 44
secret. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the secret. If no SSH_MSG_KEXGSS_HOSTKEY message has been sent by the
server or received by the client, then the empty string is used in server or received by the client, then the empty string is used in
place of K_S when computing the exchange hash. place of K_S when computing the exchange hash.
The GSS_GetMIC call MUST be applied over H, not the original data. The GSS_GetMIC call MUST be applied over H, not the original data.
2.2 gss-group1-sha1-* 2.2 gss-group1-sha1-*
Each of these methods specifies GSSAPI authenticated Diffie-Hellman Each of these methods specifies GSSAPI authenticated Diffie-Hellman
key exchange as described in Section 2.1 with SHA-1 as HASH, and the key exchange as described in Section 2.1 with SHA-1 as HASH, and the
group defined in section 6.1 of [11]. The method name for each group defined in section 6.1 of [8]. The method name for each
method is the concatenation of the string "gss-group1-sha1-" with method is the concatenation of the string "gss-group1-sha1-" with
the Base64 encoding of the MD5 hash [5] of the ASN.1 DER encoding the Base64 encoding of the MD5 hash [3] of the ASN.1 DER encoding
[1] of the underlying GSSAPI mechanism's OID. Base64 encoding is [1] of the underlying GSSAPI mechanism's OID. Base64 encoding is
described in section 6.8 of [6]. described in section 6.8 of [4].
Each and every such key exchange method is implicitly registered by Each and every such key exchange method is implicitly registered by
this specification. The IESG is considered to be the owner of all this specification. The IESG is considered to be the owner of all
such key exchange methods; this does NOT imply that the IESG is such key exchange methods; this does NOT imply that the IESG is
considered to be the owner of the underlying GSSAPI mechanism. considered to be the owner of the underlying GSSAPI mechanism.
2.3 Other GSSAPI key exchange methods 2.3 Other GSSAPI key exchange methods
Key exchange method names starting with "gss-" are reserved for key Key exchange method names starting with "gss-" are reserved for key
exchange methods which conform to this document; in particular, for exchange methods which conform to this document; in particular, for
those methods which use the GSSAPI authenticated Diffie-Hellman key those methods which use the GSSAPI authenticated Diffie-Hellman key
exchange algorithm described in Section 2.1, including any future exchange algorithm described in Section 2.1, including any future
methods which use different groups and/or hash functions. The methods which use different groups and/or hash functions. The
intent is that the names for any such future methods methods be intent is that the names for any such future methods methods be
defined in a similar manner to that used in Section 2.2. defined in a similar manner to that used in Section 2.2.
3. GSSAPI User Authentication 3. GSSAPI User Authentication
This section describes a general-purpose user authentication method This section describes a general-purpose user authentication method
based on [2]. It is intended to be run over the SSH user based on [2]. It is intended to be run over the SSH user
authentication protocol [12]. authentication protocol [9].
The authentication method name for this protocol is "gssapi". The authentication method name for this protocol is "gssapi".
3.1 GSSAPI Authentication Overview 3.1 GSSAPI Authentication Overview
GSSAPI authentication must maintain a context. Authentication GSSAPI authentication must maintain a context. Authentication
begins when the client sends a SSH_MSG_USERAUTH_REQUEST, which begins when the client sends a SSH_MSG_USERAUTH_REQUEST, which
specifies the mechanism OIDs the client supports. specifies the mechanism OIDs the client supports.
If the server supports any of the requested mechanism OIDs, the If the server supports any of the requested mechanism OIDs, the
skipping to change at page 12, line 31 skipping to change at page 13, line 31
Therefore, the client MUST send the following message when it has Therefore, the client MUST send the following message when it has
successfully called GSS_Init_sec_context() and gotten GSS_S_COMPLETE: successfully called GSS_Init_sec_context() and gotten GSS_S_COMPLETE:
byte SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE byte SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE
This message MUST be sent if and only if GSS_Init_sec_context() This message MUST be sent if and only if GSS_Init_sec_context()
returned GSS_S_COMPLETE. If a token is returned then the returned GSS_S_COMPLETE. If a token is returned then the
SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one. SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one.
If GSS_Init_sec_context() failed, the client MUST terminate the If GSS_Init_sec_context() failed, the client MUST terminate the
method by sending a new SSH_MSG_USERAUTH_REQUEST. method by sending a new SSH_MSG_USERAUTH_REQUEST. or by closing the
connection
3.6 Completion 3.6 Completion
As with all SSH authentication methods, successful completion is As with all SSH authentication methods, successful completion is
indicated by a SSH_MSG_USERAUTH_SUCCESS if no other authentication indicated by a SSH_MSG_USERAUTH_SUCCESS if no other authentication
is required, or a SSH_MSG_USERAUTH_FAILURE with the partial success is required, or a SSH_MSG_USERAUTH_FAILURE with the partial success
flag set if the server requires further authentication. flag set if the server requires further authentication.
This packet should be sent immediately following receipt of the the This packet should be sent immediately following receipt of the the
SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE packet. SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE packet.
3.7 Error Status 3.7 Error Status
In the event a GSSAPI error occurs on the server during context In the event a GSSAPI error occurs on the server during context
establishment, the server SHOULD send the following message to establishment, the server MAY send the following message to inform
inform the client of the details of the error before sending a the client of the details of the error before sending a
SSH_MSG_USERAUTH_FAILURE message: SSH_MSG_USERAUTH_FAILURE message:
byte SSH_MSG_USERAUTH_GSSAPI_ERROR byte SSH_MSG_USERAUTH_GSSAPI_ERROR
uint32 major_status uint32 major_status
uint32 minor_status uint32 minor_status
string message string message
string language tag string language tag
The message text MUST be encoded in the UTF-8 encoding described in The message text MUST be encoded in the UTF-8 encoding described in
[13]. Language tags are those described in [14]. Note that the [10]. Language tags are those described in [11]. Note that the
message text may contain multiple lines separated by carriage message text may contain multiple lines separated by carriage
return-line feed (CRLF) sequences. Application developers should return-line feed (CRLF) sequences. Application developers should
take this into account when displaying these messages. take this into account when displaying these messages.
Clients receiving this message MAY log the error details and/or Clients receiving this message MAY log the error details and/or
report them to the user. Any server sending this message MUST report them to the user. Any server sending this message MUST
ignore any SSH_MSG_UNIMPLEMENTED sent by the client in response. ignore any SSH_MSG_UNIMPLEMENTED sent by the client in response.
3.8 Error Token
In the event that, during context establishment, a client's call to
GSS_Init_sec_context or a server's call to GSS_Accept_sec_context
returns a token along with an error status, the resulting "error
token" SHOULD be sent to the peer using the following message:
byte SSH_MSG_USERAUTH_GSSAPI_ERRTOK
string error token
This message implies that the authentication is about to fail, and
is defined to allow the error token to be communicated without
losing synchronization.
When a server sends this message, it MUST be followed by a
SSH_MSG_USERAUTH_FAILURE message, which is to be interpreted as
applying to the same authentication request. A client receiving
this message SHOULD wait for the following SSH_MSG_USERAUTH_FAILURE
message before beginning another authentication attempt.
When a client sends this message, it MUST be followed by a new
authentication request or by terminating the connection. A server
receiving this message MUST NOT send a SSH_MSG_USERAUTH_FAILURE in
reply, since such a message might otherwise be interpreted by a
client as a response to the following authentication sequence.
Any server sending this message MUST ignore any
SSH_MSG_UNIMPLEMENTED sent by the client in response. If a server
sends both this message and an SSH_MSG_USERAUTH_GSSAPI_ERROR
message, the SSH_MSG_USERAUTH_GSSAPI_ERROR message MUST be sent
first, to allow the client to store and/or display the error status
before processing the error token.
4. External Key Exchange User Authentication 4. External Key Exchange User Authentication
This section describes a user authentication method building on the This section describes a user authentication method building on the
framework described in [12]. This method relies upon the key framework described in [9]. This method relies upon the key
exchange to authenticate both the client and the server. If the key exchange to authenticate both the client and the server. If the key
exchange did not successfully perform these functions then the exchange did not successfully perform these functions then the
server MUST always respond to this request with server MUST always respond to this request with
SSH_MSG_USERAUTH_FAILURE with partial success set to false. SSH_MSG_USERAUTH_FAILURE with partial success set to false.
The new mechanism is defined as follows: The new mechanism is defined as follows:
byte SSH_MSG_USERAUTH_REQUEST byte SSH_MSG_USERAUTH_REQUEST
string user name (in ISO-10646 UTF-8 encoding) string user name (in ISO-10646 UTF-8 encoding)
string service name (in US-ASCII) string service name (in US-ASCII)
skipping to change at page 15, line 18 skipping to change at page 17, line 18
and provides neither signature nor encryption algorithms. Thus, it and provides neither signature nor encryption algorithms. Thus, it
can be used only with key exchange methods that do not require any can be used only with key exchange methods that do not require any
public-key operations and do not require the use of host public key public-key operations and do not require the use of host public key
material. The key exchange methods described in section 1 of this material. The key exchange methods described in section 1 of this
document are examples of such methods. document are examples of such methods.
This algorithm is used when, as a matter of configuration, the host This algorithm is used when, as a matter of configuration, the host
does not have or does not wish to use a public key. For example, it does not have or does not wish to use a public key. For example, it
can be used when the administrator has decided as a matter of policy can be used when the administrator has decided as a matter of policy
to require that all key exchanges be authenticated using Kerberos to require that all key exchanges be authenticated using Kerberos
[3], and thus the only permitted key exchange method is the [12], and thus the only permitted key exchange method is the
GSSAPI-authenticated Diffie-Hellman exchange described above, with GSSAPI-authenticated Diffie-Hellman exchange described above, with
Kerberos V5 as the underlying GSSAPI mechanism. In such a Kerberos V5 as the underlying GSSAPI mechanism. In such a
configuration, the server implementation supports the "ssh-dss" key configuration, the server implementation supports the "ssh-dss" key
algorithm (as required by [11]), but could be prohibited by algorithm (as required by [8]), but could be prohibited by
configuration from using it. In this situation, the server needs configuration from using it. In this situation, the server needs
some key exchange algorithm to advertise; the "null" algorithm fills some key exchange algorithm to advertise; the "null" algorithm fills
this purpose. this purpose.
Note that the use of the "null" algorithm in this way means that the Note that the use of the "null" algorithm in this way means that the
server will not be able to interoperate with clients which do not server will not be able to interoperate with clients which do not
support this algorithm. This is not a significant problem, since in support this algorithm. This is not a significant problem, since in
the configuration described, it will also be unable to interoperate the configuration described, it will also be unable to interoperate
with implementations that do not support the GSSAPI-authenticated with implementations that do not support the GSSAPI-authenticated
key exchange and Kerberos. key exchange and Kerberos.
skipping to change at page 17, line 31 skipping to change at page 19, line 31
This document recommends that channel bindings SHOULD NOT be This document recommends that channel bindings SHOULD NOT be
specified in the calls during context establishment. This document specified in the calls during context establishment. This document
does not specify any standard data to be used as channel bindings does not specify any standard data to be used as channel bindings
and the use of network addresses as channel bindings may break SSH and the use of network addresses as channel bindings may break SSH
in environments where it is most useful. in environments where it is most useful.
7.3 SPNEGO 7.3 SPNEGO
The use of the Simple and Protected GSS-API Negotiation Mechanism The use of the Simple and Protected GSS-API Negotiation Mechanism
[8] in conjunction with the authentication and key exchange methods [14] in conjunction with the authentication and key exchange methods
described in this document is both unnecessary and undesirable. As described in this document is both unnecessary and undesirable. As
a result, mechanisms conforming to this document MUST NOT use SPNEGO a result, mechanisms conforming to this document MUST NOT use SPNEGO
as the underlying GSSAPI mechanism. as the underlying GSSAPI mechanism.
Since SSH performs its own negotiation of authentication and key Since SSH performs its own negotiation of authentication and key
exchange methods, the negotiation capability of SPNEGO alone does exchange methods, the negotiation capability of SPNEGO alone does
not provide any added benefit. In fact, as described below, it has 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. the potential to result in the use of a weaker method than desired.
Normally, SPNEGO provides the added benefit of protecting the GSSAPI Normally, SPNEGO provides the added benefit of protecting the GSSAPI
skipping to change at page 18, line 6 skipping to change at page 20, line 6
described here already perform an equivalent operation; namely, they described here already perform an equivalent operation; namely, they
generate a MIC of the SSH exchange hash, which is a hash of several generate a MIC of the SSH exchange hash, which is a hash of several
items including the lists of key exchange mechanisms supported by items including the lists of key exchange mechanisms supported by
both sides. In the case of user authentication, the protection is both sides. In the case of user authentication, the protection is
not needed because the negotiation occurs over a secure channel, and not needed because the negotiation occurs over a secure channel, and
the host's identity has already been proved to the user. the host's identity has already been proved to the user.
The use of SPNEGO combined with GSSAPI mechanisms used without The use of SPNEGO combined with GSSAPI mechanisms used without
SPNEGO can lead to interoperability problems. For example, a client SPNEGO can lead to interoperability problems. For example, a client
which supports key exchange using the Kerberos V5 GSSAPI mechanism which supports key exchange using the Kerberos V5 GSSAPI mechanism
[4] only underneath SPNEGO will not interoperate with a server which [13] only underneath SPNEGO will not interoperate with a server
supports key exchange only using the Kerberos V5 GSSAPI mechanism which supports key exchange only using the Kerberos V5 GSSAPI
directly. As a result, allowing GSSAPI mechanisms to be used both mechanism directly. As a result, allowing GSSAPI mechanisms to be
with and without SPNEGO is undesirable. used both with and without SPNEGO is undesirable.
If a client's policy is to first prefer GSSAPI-based key exchange If a client's policy is to first prefer GSSAPI-based key exchange
method X, then non-GSSAPI method Y, then GSSAPI-based method Z, and method X, then non-GSSAPI method Y, then GSSAPI-based method Z, and
if a server supports mechanisms Y and Z but not X, then an attempt if a server supports mechanisms Y and Z but not X, then an attempt
to use SPNEGO to negotiate a GSSAPI mechanism might result in the to use SPNEGO to negotiate a GSSAPI mechanism might result in the
use of method Z when method Y would have been preferable. As a 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 result, the use of SPNEGO could result in the subversion of the
negotiation algorithm for key exchange methods as described in negotiation algorithm for key exchange methods as described in
section 5.1 of [11] and/or the negotiation algorithm for user section 5.1 of [8] and/or the negotiation algorithm for user
authentication methods as described in [12]. authentication methods as described in [9].
8. Security Considerations 8. IANA Considerations
Consistent with section 7 of [6], the IANA is directed to make 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.2.
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.3.
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", to name the
GSSAPI user authentication method defined in Section 3.
The SSH user authentication method name "external-keyx", to name
the "external key-exchange" user authentication method defined in
Section 4.
This document creates no new registries.
9. Security Considerations
This document describes authentication and key-exchange protocols. This document describes authentication and key-exchange protocols.
As such, security considerations are discussed throughout. As such, security considerations are discussed throughout.
This protocol depends on the SSH protocol itself, the GSSAPI, any This protocol depends on the SSH protocol itself, the GSSAPI, any
underlying GSSAPI mechanisms which are used, and any protocols on underlying GSSAPI mechanisms which are used, and any protocols on
which such mechanisms might depend. Each of these components plays which such mechanisms might depend. Each of these components plays
a part in the security of the resulting connection, and each will a part in the security of the resulting connection, and each will
have its own security considerations. have its own security considerations.
skipping to change at page 19, line 33 skipping to change at page 22, line 33
In order for the "external-keyx" user authentication method to be In order for the "external-keyx" user authentication method to be
used, it MUST have access to user authentication information used, it MUST have access to user authentication information
obtained as a side-effect of the key exchange. If this information obtained as a side-effect of the key exchange. If this information
is unavailable, the authentication MUST fail. is unavailable, the authentication MUST fail.
Revealing information about the reason for an authentication failure Revealing information about the reason for an authentication failure
may be considered by some sites to be an unacceptable security risk may be considered by some sites to be an unacceptable security risk
for a production environment. However, having that information for a production environment. However, having that information
available can be invaluable for debugging purposes. Thus, it is available can be invaluable for debugging purposes. Thus, it is
RECOMMENDED that implementations provide a means for controlling, as RECOMMENDED that implementations provide a means for controlling, as
a matter of policy, whether the SSH_MSG_KEXGSS_ERROR and/or a matter of policy, whether to send SSH_MSG_USERAUTH_GSSAPI_ERROR,
SSH_MGS_USERAUTH_GGSAPI_ERROR messages are sent. SSH_MSG_USERAUTH_GSSAPI_ERRTOK, and SSH_MSG_KEXGSS_ERROR messages,
and SSH_MSG_KEXGEE_CONTINUE messages containing a GSSAPI error token.
9. Acknowledgements 10. Acknowledgements
The authors would like to thank Sam Hartman and Simon Wilkinson for The authors would like to thank Sam Hartman, Simon Wilkinson, and
their invaluable assistance with this document. Nicolas Williams for their invaluable assistance with this document.
10. Changes the last version 11. Changes the last version
This section lists important changes since the previous version of This section lists important changes since the previous version of
this internet-draft. This section should be removed at the time of this internet-draft. This section should be removed at the time of
publication of this document as an RFC. publication of this document as an RFC.
o Updated the description of SSH_MSG_USERAUTH_REQUEST to require o Improved the description of error handling during key exchange.
that GSSAPI mechanism OID's be encoded per DER rather than BER.
o Updated contact information for one of the authors. o Specified that SSH_MSG_GSSKEX_CONTINUE SHOULD be used to send
error tokens in the event of a failure of GSS_Init_sec_context or
GSS_Accept_sec_context during key exchange.
o Corrected errors in some of the references. o Made SSH_MSG_GSSKEX_ERROR be OPTIONAL instead of RECOMMENDED.
References o Specified a new SSH_MSG_USERAUTH_GSSAPI_ERRTOK message which
SHOULD be used to send error tokens in the event of a failure of
GSS_Init_sec_context or GSS_Accept_sec_context during user
authentication.
o Made SSH_MSG_USERAUTH_GSSAPI_ERROR be OPTIONAL instead of
RECOMMENDED.
o Added IANA considerations section.
Normative References
[1] ISO/IEC, "ASN.1 Encoding Rules: Specification of Basic [1] ISO/IEC, "ASN.1 Encoding Rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690 (1997), ISO/IEC 8825-1:1998, November 1998. X.690 (1997), ISO/IEC 8825-1:1998, November 1998.
[2] Linn, J., "Generic Security Service Application Program [2] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[3] Kohl, J. and C. Neuman, "The Kerberos Network Authentication [3] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
Service (V5)", RFC 1510, September 1993.
[4] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
1964, June 1996.
[5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[7] Bradner, S., "Key words for use in RFCs to Indicate [5] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[8] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API [6] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Negotiation Mechanism", RFC 2478, December 1998.
[9] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Lehtinen, "SSH Protocol Architecture", Lehtinen, "SSH Protocol Architecture",
draft-ietf-secsh-architecture-11.txt (work in progress), draft-ietf-secsh-architecture-11.txt (work in progress),
November 2001. November 2001.
[10] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. [7] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Lehtinen, "SSH Connection Protocol", Lehtinen, "SSH Connection Protocol",
draft-ietf-secsh-connect-14.txt (work in progress), November draft-ietf-secsh-connect-14.txt (work in progress), November
2001. 2001.
[11] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. [8] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Lehtinen, "SSH Transport Layer Protocol", Lehtinen, "SSH Transport Layer Protocol",
draft-ietf-secsh-transport-11.txt (work in progress), November draft-ietf-secsh-transport-11.txt (work in progress), November
2001. 2001.
[12] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. [9] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Lehtinen, "SSH Authentication Protocol", Lehtinen, "SSH Authentication Protocol",
draft-ietf-secsh-userauth-13.txt (work in progress), November draft-ietf-secsh-userauth-13.txt (work in progress), November
2001. 2001.
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [10] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998. RFC 2279, January 1998.
[14] Alvestrand, H., "Tags for the Identification of Languages", [11] Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995. RFC 1766, March 1995.
Non-normative References
[12] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[13] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
1964, June 1996.
[14] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998.
Authors' Addresses Authors' Addresses
Jeffrey Hutzelman Jeffrey Hutzelman
Carnegie Mellon University Carnegie Mellon University
5000 Forbes Ave 5000 Forbes Ave
Pittsburgh, PA 15213 Pittsburgh, PA 15213
US US
Phone: +1 412 268 7225 Phone: +1 412 268 7225
EMail: jhutz+@cmu.edu EMail: jhutz+@cmu.edu
skipping to change at page 24, line 7 skipping to change at page 27, line 7
University of Chicago & Argonne National Laboratory University of Chicago & Argonne National Laboratory
Distributed Systems Laboratory Distributed Systems Laboratory
701 E. Washington 701 E. Washington
Urbana, IL 61801 Urbana, IL 61801
US US
EMail: welch@mcs.anl.gov EMail: welch@mcs.anl.gov
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/