RE: gssapi-with-mic

["Joseph Salowey" <jsalowey%cisco.com@localhost>]

Hi Jeffrey,

I think this looks reasonable. Just one nit, I assume integ_avail would
have to be checked when GSS_S_COMPLETE is returned since some mechanisms
may not have integrity services available until then.

I don't want to document or encourage "gssapi", but I don't see anything
wrong with reusing the message format to make the transition easier.

Joe

> 
> * In section 3 of the -06 document, which describes "gssapi" userauth:
> - Rename the mechanism from "gssapi" to "gssapi-with-mic"
> - When calling GSS_Init_sec_context, the client MUST set 
> integ_req_flag
> - If integ_avail is false, send 
> SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE
> - If integ_avail is true, send SSH_MSG_USERAUTH_GSSAPI_MIC 
> (see below).
> - The server MUST reject the authentication if it gets the 
> wrong message.
> - The server MAY reject authentication anyway if integ_avail is false.
> 
> The SSH_MSG_USERAUTH_GSSAPI_MIC message looks like this:
> 
>            byte        SSH_MSG_USERAUTH_GSSAPI_MIC
>            string      MIC
> 
> The MIC is the result of calling GSS_GetMIC on the following:
> 
>            string      session identifier
>            byte        SSH_MSG_USERAUTH_REQUEST
>            string      user name
>            string      service
>            string      "gssapi-with-mic"
> 
> The message number for SSH_MSG_USERAUTH_GSSAPI_MIC is 66.
> I know this is a little different from what Joseph proposed -- what I 
> describe actually involves using a different message 
> depending on whether 
> integrity is available, rather than sending the same message with a 
> possibly empty MIC string.  I did this to try to make life easier for 
> people who are also implementing "gssapi" -- except for the 
> method name, 
> the exchange for "gssapi" is exactly the same as for 
> "gssapi-with-mic" when 
> integrity is not supported.  That should make it easier to 
> implement both 
> with common code, if desired, and it also retains some semblance of 
> documentation of the old method in the document.  If people 
> would rather 
> see SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE go away 
> completely, we can 
> use the empty-MIC-string approach instead.
> 
> 
> * Section 4, describing external-keyx, is replaced entirely.  The new 
> mechanism is called "gssapi-keyex", and consists of a single message:
> 
>            byte        SSH_MSG_USERAUTH_REQUEST
>            string      user name
>            string      service
>            string      "gssapi-keyex"
>            string      MIC
> 
> The MIC is computed by calling GSS_GetMIC using the context 
> from _initial_ 
> key exchange.  The context from a rekey is never used; if the 
> initial key 
> exchange was not GSSAPI-based, then this method cannot be 
> used.  The MIC is 
> computed over the following:
> 
>            string      session identifier
>            byte        SSH_MSG_USERAUTH_REQUEST
>            string      user name
>            string      service
>            string      "gssapi-keyex"
> 
> 
> 
> Reasonable?
> 
> -- Jeff
>