Re: gss userauth

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Fri, 29 Aug 2003, Jeffrey Hutzelman wrote:

> Given that, I will work up some specific text describing this approach,
> send it to the list, and prepare the next version of the draft for
> submission over the weekend.

Well, I'm almost there.  Included below is the new text for section 4,
describing the "gssapi-mic" authentication method.  There are additional
changes in sections 2 and 3 to refer to the new method and call out places
where the eligible context changes, but I don't think there is any
information not duplicated in the new section.

Please send me and comments, implementation experience, etc.  I still have
a few other changes to make to the draft, but will likely submit a new
version containing this text tomorrow.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+%cmu.edu@localhost>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA


4. GSSAPI MIC Authentication

   This section describes a user-authentication method which binds an
   existing GSSAPI context to the keys used for encryption and integrity
   protection of an SSH session.  It is intended to be run over the SSH
   user authentication protocol [9], and used in conjunction with the
   key exchange methods described in Section 2 and with the user
   authentication methods described in Section 3.

   The authentication method name for this protocol is "gssapi-mic".

   This method makes use of an existing GSSAPI session established
   during a previous use of the "gssapi" user authentication method or
   of a key exchange method defined in accordance with Section 2. This
   method can improve the strength of user authentication when a GSSAPI
   mechainsm which provides integrity protection is used.  It can also
   be used to allow user authentication to be performed using a GSSAPI
   context established during key exchange.

   At any given time, at most one GSSAPI context is available for use
   with this method.  This is known as the "eligible context", and is
   selected as follows:

   o  When the SSH session begins, there is no eligible context.

   o  If the first key exchange is performed using a method defined in
      accordance with Section 2, and key exchange is successful, then
      the GSSAPI context established during key exchange becomes the
      eligible context.  A context established during key exchanges
      performed for the purpose of rekeying can never become the
      eligible context.

   o  Whenever a SSH_MSG_USERAUTH_GSSAPI_TOKEN message is sent or
      received during user authentication using the "gssapi" method,
      then the eligible context becomes unset (that is, after such a
      message there is no longer an eligible context).

   o  If user authentication using the "gssapi" method results in a
      response of SSH_MSG_USERAUTH_FAILURE with the partial success flag
      set, and the context just established supports integrity
      protection (that is, the result of the final call to
      GSS_Init_sec_context() or GSS_Accept_sec_context() included the
      integ_avail flag), then that context just established becomes the
      eligible context.

   o  If user authentication using this method ("gssapi-mic") results in
      a response of SSH_MSG_USERAUTH_FAILURE, then the eligible context
      becomes unset (that is, after such a message there is no longer an
      eligible context).

   o  This method works only with context which supports integrity
      protection via GSS_GetMIC(), and no context which does not have
      this capability may become the eligible context.

   The server SHOULD include this user authentication method in the list
   of methods that can continue (in a SSH_MSG_USERAUTH_FAILURE) if there
   is an eligible context.  It MUST NOT include this method if there is
   not an eligible context.

   The client SHOULD attempt to use this method if it is advertised by
   the server and there is an eligible context.  The client MUST NOT
   attempt to use this method if there is no eligible context, even if
   it is advertised by the server.

   If a server receives a request for this method when there is no
   eligible context, 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-mic"
           string      context id
           string      MIC

   The context id field contains the string "keyex" if the eligible
   context resulted from key exchange, or the string "userauth" if the
   eligible context resulted from user authentication.  This is done in
   order to insure that a MIC generated while using this method may be
   used only in the manner intended.

   The contents of the MIC field are obtained by calling GSS_GetMIC over
   the following, using the eligible context:

           string      session identifier
           byte        SSH_MSG_USERAUTH_REQUEST
           string      user name
           string      service
           string      "gssapi-mic"
           string      context id

   Upon receiving this message when there is an eligible context, 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.