Re: gss userauth

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

Jeffrey Hutzelman wrote:

> On Monday, August 25, 2003 09:00:54 -0600 Joseph Galbraith 
> <galb-list%vandyke.com@localhost> wrote:
>
> > 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.
>
> What we're talking about now is similar, but different.  The current 
> proposal is to require the _client_ to send the _server_ a MIC of the 
> session ID.  This proves to the server that the client which has just 
> authenticated to it is the same client that started the ssh connection, 
> and not some intermediate attacker.  I believe this is a real problem 
> and worth solving; I also believe there is a solution which is quite 
> trivial and does not break backward compatibility.

Ah.  I see the difference.

> > 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 don't think it should actually be necessary to do this; it should be 
> sufficient to use a new final message in place of the existing one.  A 
> new client would always send the new message, and fall back to sending 
> the old one if it gets a SSH_MSG_UNIMPLEMENTED.  This isn't really a 
> "downgrade" as far as the client is concerned, since the only difference 
> is that the "old" version causes the client to send _less_ data.  A new 
> server can choose to accept the old message or not, depending on a local 
> policy decision about a tradeoff between security and compatibility with 
> old clients.  This approach gives us complete interoperability between 
> old and new implementations, except in the case where a new server 
> chooses not to support old clients for security reasons.

Hmmm...

I would still prefer to see a new auth method-- I think
it is cleaner.

SSH_MSG_UNIMPLEMENTED is clearly doable, but it is messy.
Because SSH_MSG_UNIMPLEMENTED only includes the packet
sequence number, telling exactly what was unimplemented
is difficult at best.  In retrospect, it would have been nice
to include the packet type that was unimplemented in
the UNIMPLEMENTED message.

As long as all UNIMPLEMENTED messages are sent at
mutually exclusive times, things aren't too bad, but...
what if we do the kex init extension that has
been kicked around.  It isn't technically impossible
for re-key to occur during user auth.

Now, to support both of these, I have to start keeping
a map of sequence-number to packet types sent so I
can map back and figure out which packet I sent was
unimplemented, so I know what to do about it.

Now, the scenerio I've painted (re-key during userauth)
is unlikely.  But every time we depend on
SSH_MSG_UNIMPLEMENTED, we increase the risk that we
will run into a case where it will be unclear to
the receiver of SSH_MSG_UNIMPLEMENTED which packet
they sent was unimplemented.

I think using SSH_MSG_UNIMPLEMENTED should be a last ditch
solution.

So I still prefer a new method name; we can define
this method, and then include a note that "gssapi"
is an obsolete method that differs only in it's
last packet.  I'm not sure about a name though.
"gssapi-2" or "gssapi-mic" come to mind, but there
might be better choices.

- Joseph