IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: gss userauth



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.

Right. In a very early version of the userauth draft, before we merged userauth and keyex into one document, we had a requirement that the server send a MIC of the host key (or was it the session ID? I forget) to the client. The point of this was to "increase confidence" in the correctness of the host key. We dropped it because there was relatively little percieved gain, and we wanted not to have to require integrity and mutual auth from the underlying GSSAPI mechanism.

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.

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.

-- Jeff




Home | Main Index | Thread Index | Old Index