Subject: gssapi-with-mic

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 05 Sep 2003 12:12:53 -0400

OK; I _think_ we may actually have concensus this time.  So, here's a 
concrete proposal for what the changes to the spec should look like. 
Hopefully this will be enough for people to comment on and implement from, 
until I can post some real text and submit a draft...

* 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

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 5 Sep 2003 09:51:10 -0700

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

> - If integ_avail is false, send 
> SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 05 Sep 2003 13:18:08 -0400

> may not have integrity services available until then.

Yes, that's the idea.  The text will be clear on this, as it is for key 
exchange.

---

From: Joseph Galbraith <[email-masked]>
Date: Fri, 05 Sep 2003 11:21:18 -0600

Looks good to me.

- Joseph

Jeffrey Hutzelman wrote:

> Hopefully this will be enough for people to comment on and implement 
> from, until I can post some real text and submit a draft...
> 
> 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.
> 
> 
> 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:
>

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 5 Sep 2003 15:42:46 -0700

> Yes, that's the idea.  The text will be clear on this, as it is for key

There's always PROT_READY w/ partially established contexts - that can
save a 1/2 round-trip.  I'm not sure that I'd actually recommend this
though.  We have to work out some things about this in the KRB WG wrt
the new Kerberos V GSS-API mechanism.

Nico
--

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 09 Sep 2003 14:22:35 -0600

Do we have any implementors of this yet?

I'm looking for someone to do interop testing
with-- it'd be nice to validate my reading of
Jeffrey's notes against someone elses.

Thanks,

Joseph

>> 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 
>> SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE go away completely, we can 
>> _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:
>>