Re: gss userauth

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

On Sat, 23 Aug 2003, Love wrote:

> I'm fine with that, using GSS_C_AF_NULLADDRs and stuff the session
> identifier in the application_data fields, the later is what CCM proposes,
> would work for all mechs that have working channel bindings would save you
> From the extra round trip. But then, channel bindings are useless (for ssh
> gssuserauth) because they are optional for the gss mechs.

Using channel bindings would also destroy backward-compatibility, in both
directions.  A client which sends channel bindings would not be able to
establish a security context with a server that is not expecting to accept
them.



> If the MIC is set with the last gss exchange packet, you would have 0 or 1
> extra packets. 0 in the case where the last exchange packets is from the
> client and 1 when the last exchange packet is from the server. So I would
> argue that its not a extra roundtrip, but rather none (with more data) or a
> half.

In the gssapi userauth method we have defined, the last message is always
sent by the client.  Thus, we can define an alternate version of this
message (currently always SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE) which
contains the MIC.

> I would very much like to see mutual auth in the gss userauth layer, but
> sending MIC from client to server is ok with me.

Why?  The userauth layer isn't about authenticating the server to the
client; we've already done that.  Performing mutual auth in the userauth
layer would restrict us to GSSAPI mechanisms that can _do_ mutual auth.
I don't see any gain that justifies that restriction.

-- Jeff