Re: gss userauth

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

> > 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?

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