doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc4462.txt b/doc/rfc/rfc4462.txt
new file mode 100644
index 0000000..07dc591
--- /dev/null
+++ b/doc/rfc/rfc4462.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group                                       J. Hutzelman
+Request for Comments: 4462                                           CMU
+Category: Standards Track                                     J. Salowey
+                                                           Cisco Systems
+                                                            J. Galbraith
+                                             Van Dyke Technologies, Inc.
+                                                                V. Welch
+                                                         U Chicago / ANL
+                                                                May 2006
+
+
+    Generic Security Service Application Program Interface (GSS-API)
+  Authentication and Key Exchange for the Secure Shell (SSH) Protocol
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Secure Shell protocol (SSH) is a protocol for secure remote login
+   and other secure network services over an insecure network.
+
+   The Generic Security Service Application Program Interface (GSS-API)
+   provides security services to callers in a mechanism-independent
+   fashion.
+
+   This memo describes methods for using the GSS-API for authentication
+   and key exchange in SSH.  It defines an SSH user authentication
+   method that uses a specified GSS-API mechanism to authenticate a
+   user, and a family of SSH key exchange methods that use GSS-API to
+   authenticate a Diffie-Hellman key exchange.
+
+   This memo also defines a new host public key algorithm that can be
+   used when no operations are needed using a host's public key, and a
+   new user authentication method that allows an authorization name to
+   be used in conjunction with any authentication that has already
+   occurred as a side-effect of GSS-API-based key exchange.
+
+
+
+
+
+Hutzelman, et al.           Standards Track                     [Page 1]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. SSH Terminology ............................................3
+      1.2. Key Words ..................................................3
+   2. GSS-API-Authenticated Diffie-Hellman Key Exchange ...............3
+      2.1. Generic GSS-API Key Exchange ...............................4
+      2.2. Group Exchange ............................................10
+      2.3. gss-group1-sha1-* .........................................11
+      2.4. gss-group14-sha1-* ........................................12
+      2.5. gss-gex-sha1-* ............................................12
+      2.6. Other GSS-API Key Exchange Methods ........................12
+   3. GSS-API User Authentication ....................................13
+      3.1. GSS-API Authentication Overview ...........................13
+      3.2. Initiating GSS-API Authentication .........................13
+      3.3. Initial Server Response ...................................14
+      3.4. GSS-API Session ...........................................15
+      3.5. Binding Encryption Keys ...................................16
+      3.6. Client Acknowledgement ....................................16
+      3.7. Completion ................................................17
+      3.8. Error Status ..............................................17
+      3.9. Error Token ...............................................18
+   4. Authentication Using GSS-API Key Exchange ......................19
+   5. Null Host Key Algorithm ........................................20
+   6. Summary of Message Numbers .....................................21
+   7. GSS-API Considerations .........................................22
+      7.1. Naming Conventions ........................................22
+      7.2. Channel Bindings ..........................................22
+      7.3. SPNEGO ....................................................23
+   8. IANA Considerations ............................................24
+   9. Security Considerations ........................................24
+   10. Acknowledgements ..............................................25
+   11. References ....................................................26
+      11.1. Normative References .....................................26
+      11.2. Informative References ...................................27
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hutzelman, et al.           Standards Track                     [Page 2]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+1.  Introduction
+
+   This document describes the methods used to perform key exchange and
+   user authentication in the Secure Shell protocol using the GSS-API.
+   To do this, it defines a family of key exchange methods, two user
+   authentication methods, and a new host key algorithm.  These
+   definitions allow any GSS-API mechanism to be used with the Secure
+   Shell protocol.
+
+   This document should be read only after reading the documents
+   describing the SSH protocol architecture [SSH-ARCH], transport layer
+   protocol [SSH-TRANSPORT], and user authentication protocol
+   [SSH-USERAUTH].  This document freely uses terminology and notation
+   from the architecture document without reference or further
+   explanation.
+
+1.1.  SSH Terminology
+
+   The data types used in the packets are defined in the SSH
+   architecture document [SSH-ARCH].  It is particularly important to
+   note the definition of string allows binary content.
+
+   The SSH_MSG_USERAUTH_REQUEST packet refers to a service; this service
+   name is an SSH service name and has no relationship to GSS-API
+   service names.  Currently, the only defined service name is
+   "ssh-connection", which refers to the SSH connection protocol
+   [SSH-CONNECT].
+
+1.2.  Key Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [KEYWORDS].
+
+2.  GSS-API-Authenticated Diffie-Hellman Key Exchange
+
+   This section defines a class of key exchange methods that combine the
+   Diffie-Hellman key exchange from Section 8 of [SSH-TRANSPORT] with
+   mutual authentication using GSS-API.
+
+   Since the GSS-API key exchange methods described in this section do
+   not require the use of public key signature or encryption algorithms,
+   they MAY be used with any host key algorithm, including the "null"
+   algorithm described in Section 5.
+
+
+
+
+
+
+
+Hutzelman, et al.           Standards Track                     [Page 3]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+2.1.  Generic GSS-API Key Exchange
+
+   The following symbols are used in this description:
+
+   o  C is the client, and S is the server
+
+   o  p is a large safe prime, g is a generator for a subgroup of GF(p),
+      and q is the order of the subgroup
+
+   o  V_S is S's version string, and V_C is C's version string
+
+   o  I_C is C's KEXINIT message, and I_S is S's KEXINIT message
+
+   1.  C generates a random number x (1 < x < q) and computes e = g^x
+       mod p.
+
+   2.  C calls GSS_Init_sec_context(), using the most recent reply token
+       received from S during this exchange, if any.  For this call, the
+       client MUST set mutual_req_flag to "true" to request that mutual
+       authentication be performed.  It also MUST set integ_req_flag to
+       "true" to request that per-message integrity protection be
+       supported for this context.  In addition, deleg_req_flag MAY be
+       set to "true" to request access delegation, if requested by the
+       user.  Since the key exchange process authenticates only the
+       host, the setting of anon_req_flag is immaterial to this process.
+       If the client does not support the "gssapi-keyex" user
+       authentication method described in Section 4, or does not intend
+       to use that method in conjunction with the GSS-API context
+       established during key exchange, then anon_req_flag SHOULD be set
+       to "true".  Otherwise, this flag MAY be set to true if the client
+       wishes to hide its identity.  Since the key exchange process will
+       involve the exchange of only a single token once the context has
+       been established, it is not necessary that the GSS-API context
+       support detection of replayed or out-of-sequence tokens.  Thus,
+       replay_det_req_flag and sequence_req_flag need not be set for
+       this process.  These flags SHOULD be set to "false".
+
+       *  If the resulting major_status code is GSS_S_COMPLETE and the
+          mutual_state flag is not true, then mutual authentication has
+          not been established, and the key exchange MUST fail.
+
+       *  If the resulting major_status code is GSS_S_COMPLETE and the
+          integ_avail flag is not true, then per-message integrity
+          protection is not available, and the key exchange MUST fail.
+
+       *  If the resulting major_status code is GSS_S_COMPLETE and both
+          the mutual_state and integ_avail flags are true, the resulting
+          output token is sent to S.
+
+
+
+Hutzelman, et al.           Standards Track                     [Page 4]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+       *  If the resulting major_status code is GSS_S_CONTINUE_NEEDED,
+          the output_token is sent to S, which will reply with a new
+          token to be provided to GSS_Init_sec_context().
+
+       *  The client MUST also include "e" with the first message it
+          sends to the server during this process; if the server
+          receives more than one "e" or none at all, the key exchange
+          fails.
+
+       *  It is an error if the call does not produce a token of non-
+          zero length to be sent to the server.  In this case, the key
+          exchange MUST fail.
+
+   3.  S calls GSS_Accept_sec_context(), using the token received from
+       C.
+
+       *  If the resulting major_status code is GSS_S_COMPLETE and the
+          mutual_state flag is not true, then mutual authentication has
+          not been established, and the key exchange MUST fail.
+
+       *  If the resulting major_status code is GSS_S_COMPLETE and the
+          integ_avail flag is not true, then per-message integrity
+          protection is not available, and the key exchange MUST fail.
+
+       *  If the resulting major_status code is GSS_S_COMPLETE and both
+          the mutual_state and integ_avail flags are true, then the
+          security context has been established, and processing
+          continues with step 4.
+
+       *  If the resulting major_status code is GSS_S_CONTINUE_NEEDED,
+          then the output token is sent to C, and processing continues
+          with step 2.
+
+       *  If the resulting major_status code is GSS_S_COMPLETE, but a
+          non-zero-length reply token is returned, then that token is
+          sent to the client.
+
+   4.  S generates a random number y (0 < y < q) and computes f = g^y
+       mod p.  It computes K = e ^ y mod p, and H = hash(V_C || V_S ||
+       I_C || I_S || K_S || e || f || K).  It then calls GSS_GetMIC() to
+       obtain a GSS-API message integrity code for H.  S then sends f
+       and the message integrity code (MIC) to C.
+
+   5.  This step is performed only (1) if the server's final call to
+       GSS_Accept_sec_context() produced a non-zero-length final reply
+       token to be sent to the client and (2) if no previous call by the
+       client to GSS_Init_sec_context() has resulted in a major_status
+       of GSS_S_COMPLETE.  Under these conditions, the client makes an
+
+
+
+Hutzelman, et al.           Standards Track                     [Page 5]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+       additional call to GSS_Init_sec_context() to process the final
+       reply token.  This call is made exactly as described above.
+       However, if the resulting major_status is anything other than
+       GSS_S_COMPLETE, or a non-zero-length token is returned, it is an
+       error and the key exchange MUST fail.
+
+   6.  C computes K = f^x mod p, and H = hash(V_C || V_S || I_C || I_S
+       || K_S || e || f || K).  It then calls GSS_VerifyMIC() to verify
+       that the MIC sent by S matches H.  If the MIC is not successfully
+       verified, the key exchange MUST fail.
+
+   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
+   fails.
+
+   If any call to GSS_Init_sec_context() or GSS_Accept_sec_context()
+   returns a major_status other than GSS_S_COMPLETE or
+   GSS_S_CONTINUE_NEEDED, or any other GSS-API call returns a
+   major_status other than GSS_S_COMPLETE, the key exchange fails.  In
+   this case, several mechanisms are available for communicating error
+   information to the peer before terminating the connection as required
+   by [SSH-TRANSPORT]:
+
+   o  If the key exchange fails due to any GSS-API 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 GSS-API 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 GSS-API 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
+   for computing the exchange hash is defined by the method name, and is
+   called HASH.  The group used for Diffie-Hellman key exchange and the
+   underlying GSS-API mechanism are also defined by the method name.
+
+
+
+Hutzelman, et al.           Standards Track                     [Page 6]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+   After the client's first call to GSS_Init_sec_context(), it sends the
+   following:
+
+           byte      SSH_MSG_KEXGSS_INIT
+           string    output_token (from GSS_Init_sec_context())
+           mpint     e
+
+   Upon receiving the SSH_MSG_KEXGSS_INIT message, the server MAY send
+   the following message, prior to any other messages, to inform the
+   client of its host key.
+
+           byte      SSH_MSG_KEXGSS_HOSTKEY
+           string    server public host key and certificates (K_S)
+
+   Since this key exchange method does not require the host key to be
+   used for any encryption operations, this message is OPTIONAL.  If the
+   "null" host key algorithm described in Section 5 is used, this
+   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 as a
+   single string, in the format specified by the public key type in use
+   (see [SSH-TRANSPORT], Section 6.6).
+
+   In traditional SSH deployments, host keys are normally expected to
+   change infrequently, and there is often no mechanism for validating
+   host keys not already known to the client.  As a result, the use of a
+   new host key by an already-known host is usually considered an
+   indication of a possible man-in-the-middle attack, and clients often
+   present strong warnings and/or abort the connection in such cases.
+
+   By contrast, when GSS-API-based key exchange is used, host keys sent
+   via the SSH_MSG_KEXGSS_HOSTKEY message are authenticated as part of
+   the GSS-API key exchange, even when previously unknown to the client.
+   Further, in environments in which GSS-API-based key exchange is used
+   heavily, it is possible and even likely that host keys will change
+   much more frequently and/or without advance warning.
+
+   Therefore, when a new key for an already-known host is received via
+   the SSH_MSG_KEXGSS_HOSTKEY message, clients SHOULD NOT issue strong
+   warnings or abort the connection, provided the GSS-API-based key
+   exchange succeeds.
+
+   In order to facilitate key re-exchange after the user's GSS-API
+   credentials have expired, client implementations SHOULD store host
+   keys received via SSH_MSG_KEXGSS_HOSTKEY for the duration of the
+   session, even when such keys are not stored for long-term use.
+
+
+
+
+
+
+Hutzelman, et al.           Standards Track                     [Page 7]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+   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
+   reply to the client:
+
+           byte      SSH_MSG_KEXGSS_CONTINUE
+           string    output_token (from GSS_Accept_sec_context())
+
+   If the client receives this message after a call to
+   GSS_Init_sec_context() has returned a major_status code of
+   GSS_S_COMPLETE, a protocol error has occurred and the key exchange
+   MUST fail.
+
+   Each time the client receives the message described above, it makes
+   another call to GSS_Init_sec_context().  It then sends the following:
+
+           byte      SSH_MSG_KEXGSS_CONTINUE
+           string    output_token (from GSS_Init_sec_context())
+
+   The server and client continue to trade these two messages as long as
+   the server's calls to GSS_Accept_sec_context() result in major_status
+   codes of GSS_S_CONTINUE_NEEDED.  When a call results in a
+   major_status code of GSS_S_COMPLETE, it sends one of two final
+   messages.
+
+   If the server's final call to GSS_Accept_sec_context() (resulting in
+   a major_status code of GSS_S_COMPLETE) returns a non-zero-length
+   token to be sent to the client, it sends the following:
+
+           byte      SSH_MSG_KEXGSS_COMPLETE
+           mpint     f
+           string    per_msg_token (MIC of H)
+           boolean   TRUE
+           string    output_token (from GSS_Accept_sec_context())
+
+   If the client receives this message after a call to
+   GSS_Init_sec_context() has returned a major_status code of
+   GSS_S_COMPLETE, a protocol error has occurred and the key exchange
+   MUST fail.
+
+   If the server's final call to GSS_Accept_sec_context() (resulting in
+   a major_status code of GSS_S_COMPLETE) returns a zero-length token or
+   no token at all, it sends the following:
+
+           byte      SSH_MSG_KEXGSS_COMPLETE
+           mpint     f
+           string    per_msg_token (MIC of H)
+           boolean   FALSE
+
+
+
+
+Hutzelman, et al.           Standards Track                     [Page 8]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+   If the client receives this message when no call to
+   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
+   MUST fail.
+
+   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 GSS-API error on the server, the server MAY send
+   the following message before terminating the connection:
+
+           byte      SSH_MSG_KEXGSS_ERROR
+           uint32    major_status
+           uint32    minor_status
+           string    message
+           string    language tag
+
+   The message text MUST be encoded in the UTF-8 encoding described in
+   [UTF8].  Language tags are those described in [LANGTAG].  Note that
+   the message text may contain multiple lines separated by carriage
+   return-line feed (CRLF) sequences.  Application developers should
+   take this into account when displaying these messages.
+
+   The hash H is computed as the HASH hash of the concatenation of the
+   following:
+
+           string    V_C, the client's version string (CR, NL excluded)
+           string    V_S, the server's version string (CR, NL excluded)
+           string    I_C, the payload of the client's SSH_MSG_KEXINIT
+           string    I_S, the payload of the server's SSH_MSG_KEXINIT
+           string    K_S, the host key
+           mpint     e, exchange value sent by the client
+           mpint     f, exchange value sent by the server
+           mpint     K, the shared secret
+
+
+
+
+
+Hutzelman, et al.           Standards Track                     [Page 9]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+   This value is called the exchange hash, and it is used to
+   authenticate the key exchange.  The exchange hash SHOULD be kept
+   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
+   place of K_S when computing the exchange hash.
+
+   The GSS_GetMIC call MUST be applied over H, not the original data.
+
+2.2.  Group Exchange
+
+   This section describes a modification to the generic GSS-API-
+   authenticated Diffie-Hellman key exchange to allow the negotiation of
+   the group to be used, using a method based on that described in
+   [GROUP-EXCHANGE].
+
+   The server keeps a list of safe primes and corresponding generators
+   that it can select from.  These are chosen as described in Section 3
+   of [GROUP-EXCHANGE].  The client requests a modulus from the server,
+   indicating the minimum, maximum, and preferred sizes; the server
+   responds with a suitable modulus and generator.  The exchange then
+   proceeds as described in Section 2.1 above.
+
+   This description uses the following symbols, in addition to those
+   defined above:
+
+   o  n is the size of the modulus p in bits that the client would like
+      to receive from the server
+
+   o  min and max are the minimal and maximal sizes of p in bits that
+      are acceptable to the client
+
+   1.  C sends "min || n || max" to S, indicating the minimal acceptable
+       group size, the preferred size of the group, and the maximal
+       group size in bits the client will accept.
+
+   2.  S finds a group that best matches the client's request, and sends
+       "p || g" to C.
+
+   3.  The exchange proceeds as described in Section 2.1 above,
+       beginning with step 1, except that the exchange hash is computed
+       as described below.
+
+   Servers and clients SHOULD support groups with a modulus length of k
+   bits, where 1024 <= k <= 8192.  The recommended values for min and
+   max are 1024 and 8192, respectively.
+
+   This is implemented using the following messages, in addition to
+   those described above:
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 10]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+   First, the client sends:
+
+           byte      SSH_MSG_KEXGSS_GROUPREQ
+           uint32    min, minimal size in bits of an acceptable group
+           uint32    n, preferred size in bits of the group the server
+                     should send
+           uint32    max, maximal size in bits of an acceptable group
+
+   The server responds with:
+
+           byte      SSH_MSG_KEXGSS_GROUP
+           mpint     p, safe prime
+           mpint     g, generator for subgroup in GF(p)
+
+   This is followed by the message exchange described above in
+   Section 2.1, except that the exchange hash H is computed as the HASH
+   hash of the concatenation of the following:
+
+           string    V_C, the client's version string (CR, NL excluded)
+           string    V_S, the server's version string (CR, NL excluded)
+           string    I_C, the payload of the client's SSH_MSG_KEXINIT
+           string    I_S, the payload of the server's SSH_MSG_KEXINIT
+           string    K_S, the host key
+           uint32    min, minimal size in bits of an acceptable group
+           uint32    n, preferred size in bits of the group the server
+                     should send
+           uint32    max, maximal size in bits of an acceptable group
+           mpint     p, safe prime
+           mpint     g, generator for subgroup in GF(p)
+           mpint     e, exchange value sent by the client
+           mpint     f, exchange value sent by the server
+           mpint     K, the shared secret
+
+2.3.  gss-group1-sha1-*
+
+   Each of these methods specifies GSS-API-authenticated Diffie-Hellman
+   key exchange as described in Section 2.1 with SHA-1 as HASH, and the
+   group defined in Section 8.1 of [SSH-TRANSPORT].  The method name for
+   each method is the concatenation of the string "gss-group1-sha1-"
+   with the Base64 encoding of the MD5 hash [MD5] of the ASN.1
+   Distinguished Encoding Rules (DER) encoding [ASN1] of the underlying
+   GSS-API mechanism's Object Identifier (OID).  Base64 encoding is
+   described in Section 6.8 of [MIME].
+
+   Each and every such key exchange method is implicitly registered by
+   this specification.  The IESG is considered to be the owner of all
+   such key exchange methods; this does NOT imply that the IESG is
+   considered to be the owner of the underlying GSS-API mechanism.
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 11]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+2.4.  gss-group14-sha1-*
+
+   Each of these methods specifies GSS-API authenticated Diffie-Hellman
+   key exchange as described in Section 2.1 with SHA-1 as HASH, and the
+   group defined in Section 8.2 of [SSH-TRANSPORT].  The method name for
+   each method is the concatenation of the string "gss-group14-sha1-"
+   with the Base64 encoding of the MD5 hash [MD5] of the ASN.1 DER
+   encoding [ASN1] of the underlying GSS-API mechanism's OID.  Base64
+   encoding is described in Section 6.8 of [MIME].
+
+   Each and every such key exchange method is implicitly registered by
+   this specification.  The IESG is considered to be the owner of all
+   such key exchange methods; this does NOT imply that the IESG is
+   considered to be the owner of the underlying GSS-API mechanism.
+
+2.5.  gss-gex-sha1-*
+
+   Each of these methods specifies GSS-API-authenticated Diffie-Hellman
+   key exchange as described in Section 2.2 with SHA-1 as HASH.  The
+   method name for each method is the concatenation of the string "gss-
+   gex-sha1-" with the Base64 encoding of the MD5 hash [MD5] of the
+   ASN.1 DER encoding [ASN1] of the underlying GSS-API mechanism's OID.
+   Base64 encoding is described in Section 6.8 of [MIME].
+
+   Each and every such key exchange method is implicitly registered by
+   this specification.  The IESG is considered to be the owner of all
+   such key exchange methods; this does NOT imply that the IESG is
+   considered to be the owner of the underlying GSS-API mechanism.
+
+2.6.  Other GSS-API Key Exchange Methods
+
+   Key exchange method names starting with "gss-" are reserved for key
+   exchange methods that conform to this document; in particular, for
+   those methods that use the GSS-API-authenticated Diffie-Hellman key
+   exchange algorithm described in Section 2.1, including any future
+   methods that use different groups and/or hash functions.  The intent
+   is that the names for any such future methods be defined in a similar
+   manner to that used in Section 2.3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 12]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+3.  GSS-API User Authentication
+
+   This section describes a general-purpose user authentication method
+   based on [GSSAPI].  It is intended to be run over the SSH user
+   authentication protocol [SSH-USERAUTH].
+
+   The authentication method name for this protocol is "gssapi-with-
+   mic".
+
+3.1.  GSS-API Authentication Overview
+
+   GSS-API authentication must maintain a context.  Authentication
+   begins when the client sends an SSH_MSG_USERAUTH_REQUEST, which
+   specifies the mechanism OIDs the client supports.
+
+   If the server supports any of the requested mechanism OIDs, the
+   server sends an SSH_MSG_USERAUTH_GSSAPI_RESPONSE message containing
+   the mechanism OID.
+
+   After the client receives SSH_MSG_USERAUTH_GSSAPI_RESPONSE, the
+   client and server exchange SSH_MSG_USERAUTH_GSSAPI_TOKEN packets
+   until the authentication mechanism either succeeds or fails.
+
+   If at any time during the exchange the client sends a new
+   SSH_MSG_USERAUTH_REQUEST packet, the GSS-API context is completely
+   discarded and destroyed, and any further GSS-API authentication MUST
+   restart from the beginning.
+
+   If the authentication succeeds and a non-empty user name is presented
+   by the client, the SSH server implementation verifies that the user
+   name is authorized based on the credentials exchanged in the GSS-API
+   exchange.  If the user name is not authorized, then the
+   authentication MUST fail.
+
+3.2.  Initiating GSS-API Authentication
+
+   The GSS-API authentication method is initiated when the client sends
+   an SSH_MSG_USERAUTH_REQUEST:
+
+           byte      SSH_MSG_USERAUTH_REQUEST
+           string    user name (in ISO-10646 UTF-8 encoding)
+           string    service name (in US-ASCII)
+           string    "gssapi-with-mic" (US-ASCII method name)
+           uint32    n, the number of mechanism OIDs client supports
+           string[n] mechanism OIDs
+
+   Mechanism OIDs are encoded according to the ASN.1 Distinguished
+   Encoding Rules (DER), as described in [ASN1] and in Section 3.1 of
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 13]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+   [GSSAPI].  The mechanism OIDs MUST be listed in order of preference,
+   and the server must choose the first mechanism OID on the list that
+   it supports.
+
+   The client SHOULD send GSS-API mechanism OIDs only for mechanisms
+   that are of the same priority, compared to non-GSS-API authentication
+   methods.  Otherwise, authentication methods may be executed out of
+   order.  Thus, the client could first send an SSH_MSG_USERAUTH_REQUEST
+   for one GSS-API mechanism, then try public key authentication, and
+   then try another GSS-API mechanism.
+
+   If the server does not support any of the specified OIDs, the server
+   MUST fail the request by sending an SSH_MSG_USERAUTH_FAILURE packet.
+
+   The user name may be an empty string if it can be deduced from the
+   results of the GSS-API authentication.  If the user name is not
+   empty, and the requested user does not exist, the server MAY
+   disconnect or MAY send a bogus list of acceptable authentications but
+   never accept any.  This makes it possible for the server to avoid
+   disclosing information about which accounts exist.  In any case, if
+   the user does not exist, the authentication request MUST NOT be
+   accepted.
+
+   Note that the 'user name' value is encoded in ISO-10646 UTF-8.  It is
+   up to the server how it interprets the user name and determines
+   whether the client is authorized based on his GSS-API 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 user name in some other encoding (e.g., ISO 8859-1 - ISO
+   Latin1), it MUST convert the user name to ISO-10646 UTF-8 before
+   transmitting, and the server MUST convert the user name 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 [SASLPREP].
+
+   The client MAY at any time continue with a new
+   SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST
+   abandon the previous authentication attempt and continue with the new
+   one.
+
+3.3.  Initial Server Response
+
+   The server responds to the SSH_MSG_USERAUTH_REQUEST with either an
+   SSH_MSG_USERAUTH_FAILURE if none of the mechanisms are supported or
+   with an SSH_MSG_USERAUTH_GSSAPI_RESPONSE as follows:
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 14]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+           byte        SSH_MSG_USERAUTH_GSSAPI_RESPONSE
+           string      selected mechanism OID
+
+   The mechanism OID must be one of the OIDs sent by the client in the
+   SSH_MSG_USERAUTH_REQUEST packet.
+
+3.4.  GSS-API Session
+
+   Once the mechanism OID has been selected, the client will then
+   initiate an exchange of one or more pairs of
+   SSH_MSG_USERAUTH_GSSAPI_TOKEN packets.  These packets contain the
+   tokens produced from the 'GSS_Init_sec_context()' and
+   'GSS_Accept_sec_context()' calls.  The actual number of packets
+   exchanged is determined by the underlying GSS-API mechanism.
+
+           byte        SSH_MSG_USERAUTH_GSSAPI_TOKEN
+           string      data returned from either GSS_Init_sec_context()
+                       or GSS_Accept_sec_context()
+
+   If an error occurs during this exchange on server side, the server
+   can terminate the method by sending an SSH_MSG_USERAUTH_FAILURE
+   packet.  If an error occurs on client side, the client can terminate
+   the method by sending a new SSH_MSG_USERAUTH_REQUEST packet.
+
+   When calling GSS_Init_sec_context(), the client MUST set
+   integ_req_flag to "true" to request that per-message integrity
+   protection be supported for this context.  In addition,
+   deleg_req_flag MAY be set to "true" to request access delegation, if
+   requested by the user.
+
+   Since the user authentication process by its nature authenticates
+   only the client, the setting of mutual_req_flag is not needed for
+   this process.  This flag SHOULD be set to "false".
+
+   Since the user authentication process will involve the exchange of
+   only a single token once the context has been established, it is not
+   necessary that the context support detection of replayed or out-of-
+   sequence tokens.  Thus, the setting of replay_det_req_flag and
+   sequence_req_flag are not needed for this process.  These flags
+   SHOULD be set to "false".
+
+   Additional SSH_MSG_USERAUTH_GSSAPI_TOKEN messages are sent if and
+   only if the calls to the GSS-API routines produce send tokens of non-
+   zero length.
+
+   Any major status code other than GSS_S_COMPLETE or
+   GSS_S_CONTINUE_NEEDED SHOULD be a failure.
+
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 15]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+3.5.  Binding Encryption Keys
+
+   In some cases, it is possible to obtain improved security by allowing
+   access only if the client sends a valid message integrity code (MIC)
+   binding the GSS-API context to the keys used for encryption and
+   integrity protection of the SSH session.  With this extra level of
+   protection, a "man-in-the-middle" attacker who has convinced a client
+   of his authenticity cannot then relay user authentication messages
+   between the real client and server, thus gaining access to the real
+   server.  This additional protection is available when the negotiated
+   GSS-API context supports per-message integrity protection, as
+   indicated by the setting of the integ_avail flag on successful return
+   from GSS_Init_sec_context() or GSS_Accept_sec_context().
+
+   When the client's call to GSS_Init_sec_context() returns
+   GSS_S_COMPLETE with the integ_avail flag set, the client MUST
+   conclude the user authentication exchange by sending the following
+   message:
+
+           byte      SSH_MSG_USERAUTH_GSSAPI_MIC
+           string    MIC
+
+   This message MUST be sent only if GSS_Init_sec_context() returned
+   GSS_S_COMPLETE.  If a token is also returned, then the
+   SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one.
+
+   The contents of the MIC field are obtained by calling GSS_GetMIC()
+   over the following, using the GSS-API context that was just
+   established:
+
+           string    session identifier
+           byte      SSH_MSG_USERAUTH_REQUEST
+           string    user name
+           string    service
+           string    "gssapi-with-mic"
+
+   If this message is received by the server before the GSS-API context
+   is fully established, the server MUST fail the authentication.
+
+   If this message is received by the server when the negotiated GSS-API
+   context does not support per-message integrity protection, the server
+   MUST fail the authentication.
+
+3.6.  Client Acknowledgement
+
+   Some servers may wish to permit user authentication to proceed even
+   when the negotiated GSS-API context does not support per-message
+   integrity protection.  In such cases, it is possible for the server
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 16]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+   to successfully complete the GSS-API method, while the client's last
+   call to GSS_Init_sec_context() fails.  If the server simply assumed
+   success on the part of the client and completed the authentication
+   service, it is possible that the client would fail to complete the
+   authentication method, but not be able to retry other methods because
+   the server had already moved on.  To protect against this, a final
+   message is sent by the client to indicate it has completed
+   authentication.
+
+   When the client's call to GSS_Init_sec_context() returns
+   GSS_S_COMPLETE with the integ_avail flag not set, the client MUST
+   conclude the user authentication exchange by sending the following
+   message:
+
+           byte      SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE
+
+   This message MUST be sent only if GSS_Init_sec_context() returned
+   GSS_S_COMPLETE.  If a token is also returned, then the
+   SSH_MSG_USERAUTH_GSSAPI_TOKEN message MUST be sent before this one.
+
+   If this message is received by the server before the GSS-API context
+   is fully established, the server MUST fail the authentication.
+
+   If this message is received by the server when the negotiated GSS-API
+   context supports per-message integrity protection, the server MUST
+   fail the authentication.
+
+   It is a site policy decision for the server whether or not to permit
+   authentication using GSS-API mechanisms and/or contexts that do not
+   support per-message integrity protection.  The server MAY fail the
+   otherwise valid gssapi-with-mic authentication if per-message
+   integrity protection is not supported.
+
+3.7.  Completion
+
+   As with all SSH authentication methods, successful completion is
+   indicated by an SSH_MSG_USERAUTH_SUCCESS if no other authentication
+   is required, or an SSH_MSG_USERAUTH_FAILURE with the partial success
+   flag set if the server requires further authentication.  This packet
+   SHOULD be sent immediately following receipt of the
+   SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE packet.
+
+3.8.  Error Status
+
+   In the event that a GSS-API error occurs on the server during context
+   establishment, the server MAY send the following message to inform
+   the client of the details of the error before sending an
+   SSH_MSG_USERAUTH_FAILURE message:
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 17]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+           byte      SSH_MSG_USERAUTH_GSSAPI_ERROR
+           uint32    major_status
+           uint32    minor_status
+           string    message
+           string    language tag
+
+   The message text MUST be encoded in the UTF-8 encoding described in
+   [UTF8].  Language tags are those described in [LANGTAG].  Note that
+   the message text may contain multiple lines separated by carriage
+   return-line feed (CRLF) sequences.  Application developers should
+   take this into account when displaying these messages.
+
+   Clients receiving this message MAY log the error details and/or
+   report them to the user.  Any server sending this message MUST ignore
+   any SSH_MSG_UNIMPLEMENTED sent by the client in response.
+
+3.9.  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 an
+   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 an 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.
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 18]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+4.  Authentication Using GSS-API Key Exchange
+
+   This section describes a user authentication method building on the
+   framework described in [SSH-USERAUTH].  This method performs user
+   authentication by making use of an existing GSS-API context
+   established during key exchange.
+
+   The authentication method name for this protocol is "gssapi-keyex".
+
+   This method may be used only if the initial key exchange was
+   performed using a GSS-API-based key exchange method defined in
+   accordance with Section 2.  The GSS-API context used with this method
+   is always that established during an initial GSS-API-based key
+   exchange.  Any context established during key exchange for the
+   purpose of rekeying MUST NOT be used with this method.
+
+   The server SHOULD include this user authentication method in the list
+   of methods that can continue (in an SSH_MSG_USERAUTH_FAILURE) if the
+   initial key exchange was performed using a GSS-API-based key exchange
+   method and provides information about the user's identity that is
+   useful to the server.  It MUST NOT include this method if the initial
+   key exchange was not performed using a GSS-API-based key exchange
+   method defined in accordance with Section 2.
+
+   The client SHOULD attempt to use this method if it is advertised by
+   the server, initial key exchange was performed using a GSS-API-based
+   key exchange method, and this method has not already been tried.  The
+   client SHOULD NOT try this method more than once per session.  It
+   MUST NOT try this method if initial key exchange was not performed
+   using a GSS-API-based key exchange method defined in accordance with
+   Section 2.
+
+   If a server receives a request for this method when initial key
+   exchange was not performed using a GSS-API-based key exchange method
+   defined in accordance with Section 2, it MUST return
+   SSH_MSG_USERAUTH_FAILURE.
+
+   This method is defined as a single message:
+
+           byte        SSH_MSG_USERAUTH_REQUEST
+           string      user name
+           string      service
+           string      "gssapi-keyex"
+           string      MIC
+
+   The contents of the MIC field are obtained by calling GSS_GetMIC over
+   the following, using the GSS-API context that was established during
+   initial key exchange:
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 19]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+           string      session identifier
+           byte        SSH_MSG_USERAUTH_REQUEST
+           string      user name
+           string      service
+           string      "gssapi-keyex"
+
+   Upon receiving this message when initial key exchange was performed
+   using a GSS-API-based key exchange method, the server uses
+   GSS_VerifyMIC() to verify that the MIC received is valid.  If the MIC
+   is not valid, the user authentication fails, and the server MUST
+   return SSH_MSG_USERAUTH_FAILURE.
+
+   If the MIC is valid and the server is satisfied as to the user's
+   credentials, it MAY return either SSH_MSG_USERAUTH_SUCCESS or
+   SSH_MSG_USERAUTH_FAILURE with the partial success flag set, depending
+   on whether additional authentications are needed.
+
+5.  Null Host Key Algorithm
+
+   The "null" host key algorithm has no associated host key material and
+   provides neither signature nor encryption algorithms.  Thus, it 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
+   material.  The key exchange methods described in Section 2 are
+   examples of such methods.
+
+   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
+   can be used when the administrator has decided as a matter of policy
+   to require that all key exchanges be authenticated using Kerberos
+   [KRB5], and thus the only permitted key exchange method is the
+   GSS-API-authenticated Diffie-Hellman exchange described above, with
+   Kerberos V5 as the underlying GSS-API mechanism.  In such a
+   configuration, the server implementation supports the "ssh-dss" key
+   algorithm (as required by [SSH-TRANSPORT]), but could be prohibited
+   by configuration from using it.  In this situation, the server needs
+   some key exchange algorithm to advertise; the "null" algorithm fills
+   this purpose.
+
+   Note that the use of the "null" algorithm in this way means that the
+   server will not be able to interoperate with clients that do not
+   support this algorithm.  This is not a significant problem, since in
+   the configuration described, it will also be unable to interoperate
+   with implementations that do not support the GSS-API-authenticated
+   key exchange and Kerberos.
+
+
+
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 20]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+   Any implementation supporting at least one key exchange method that
+   conforms to Section 2 MUST also support the "null" host key
+   algorithm.  Servers MUST NOT advertise the "null" host key algorithm
+   unless it is the only algorithm advertised.
+
+6.  Summary of Message Numbers
+
+   The following message numbers have been defined for use with GSS-
+   API-based key exchange methods:
+
+          #define SSH_MSG_KEXGSS_INIT                       30
+          #define SSH_MSG_KEXGSS_CONTINUE                   31
+          #define SSH_MSG_KEXGSS_COMPLETE                   32
+          #define SSH_MSG_KEXGSS_HOSTKEY                    33
+          #define SSH_MSG_KEXGSS_ERROR                      34
+          #define SSH_MSG_KEXGSS_GROUPREQ                   40
+          #define SSH_MSG_KEXGSS_GROUP                      41
+
+   The numbers 30-49 are specific to key exchange and may be redefined
+   by other kex methods.
+
+   The following message numbers have been defined for use with the
+   'gssapi-with-mic' user authentication method:
+
+          #define SSH_MSG_USERAUTH_GSSAPI_RESPONSE          60
+          #define SSH_MSG_USERAUTH_GSSAPI_TOKEN             61
+          #define SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE 63
+          #define SSH_MSG_USERAUTH_GSSAPI_ERROR             64
+          #define SSH_MSG_USERAUTH_GSSAPI_ERRTOK            65
+          #define SSH_MSG_USERAUTH_GSSAPI_MIC               66
+
+   The numbers 60-79 are specific to user authentication and may be
+   redefined by other user auth methods.  Note that in the method
+   described in this document, message number 62 is unused.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 21]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+7.  GSS-API Considerations
+
+7.1.  Naming Conventions
+
+   In order to establish a GSS-API security context, the SSH client
+   needs to determine the appropriate targ_name to use in identifying
+   the server when calling GSS_Init_sec_context().  For this purpose,
+   the GSS-API mechanism-independent name form for host-based services
+   is used, as described in Section 4.1 of [GSSAPI].
+
+   In particular, the targ_name to pass to GSS_Init_sec_context() is
+   obtained by calling GSS_Import_name() with an input_name_type of
+   GSS_C_NT_HOSTBASED_SERVICE, and an input_name_string consisting of
+   the string "host@" concatenated with the hostname of the SSH server.
+
+   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.
+
+
+
+
+
+
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 22]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+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].
+
+
+
+
+
+
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 23]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+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.
+
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 24]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 25]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+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.
+
+
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 26]
+
+RFC 4462                  SSH GSS-API Methods                   May 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 27]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+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
+
+
+
+
+
+
+
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 28]
+
+RFC 4462                  SSH GSS-API Methods                   May 2006
+
+
+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).
+
+
+
+
+
+
+
+Hutzelman, et al.           Standards Track                    [Page 29]
+