RE: gss userauth

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

> -----Original Message-----
> From: Joseph Galbraith [mailto:galb-list%vandyke.com@localhost] 
> Sent: Monday, August 25, 2003 8:01 AM
> To: Jeffrey Hutzelman; Love
> Cc: Joseph Salowey; ietf-ssh%NetBSD.org@localhost
> Subject: Re: gss userauth
> 
> 
> > > 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.
> 
> I'm a little concerned about compatability at these
> point-- I've got a shipping version -- which perhaps
> wasn't wise as we hadn't completed last call, but, 
> never-the-less, I've got one.
> 
> When we originally wrote the draft we talked about
> something like this but elected not to do it so that
> userauth wouldn't require integrity and mutual auth
> as the kex method does.
> 
> I'm sure I'm being niave (or I just drove all night
> and my brain isn't working correctly yet), but, assuming
> the SSH layer is secure (and if you want to secure the
> SSH layer using gss, you can use the kex method), what
> attack does this prevent?
> 

[Joe] If the GSSAPI exchange is not bound to the session then you do not
have assurance that the client actually was performing the GSSAPI
exchange to authenticate itself to the SSH server.  The client may
actually be trying to authenticate to some other service in some other
context and his authentication may be proxied by a third party.  Part of
the problem is that the target name suggested is "host@" which can be
used by multiple services on a host.  


> Also, I don't think Microsoft supports channel bindings--
> so I would definitely prefer not to require these.
> 
> > > 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.
> 
> If this feature is required to prevent an attack, I
> would definitely prefer this solution.
> 
> In fact, to prevent downgrade attacks based on
> compatibility with old versions, we might want
> to define "gssapi-2", which is identical to
> "gssapi" in all ways, except that 
> SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE 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.
> 
> I definitely agree.  One of the major reasons for having
> a userauth method is that it isn't as demanding on the 
> capabilities of the gss mech as key exchange is.
> 
> - Joseph
>