Re: gss userauth

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

On Tue, 2 Sep 2003, Markus Friedl wrote:

> On Tue, Sep 02, 2003 at 11:41:23AM -0400, Jeffrey Hutzelman wrote:
> > On Tue, 2 Sep 2003, Markus Friedl wrote:
> >
> > > why not negotiate the 'mic' capatibility within the user
> > > authentication method instead of requiring chained methods?
> >
> > I had a proposal for doing that, but it was pointed out to me by a couple
> > of people that relying on a server sending SSH_MSG_UNIMPLEMENTED when it
>
> why do you need this for negotiating?

My approach was to have new clients just send a new message containing the
MIC, in place of the empty "exchange complete" message that current
clients send.  An old server receiving this new message would send
SSH_MSG_UNIMPLEMENTED, and the new client would reply with the old
completion message.

I don't see any way to introduce up-front negotiation into an existing
mechanism that doesn't already have it, without breaking interoperability
with the existing implementations.  If you have a suggestion that will
work, please let me know.

> > gets a message it doesn't understand is not safe, since some
> > implementations don't always do so (last I heard, OpenSSH gets this wrong
> > between the end of initial key exchange and the start of user
>
> i don't see this bug.

The specific problem I'm talking about was in relation to a new transport
message which would be used to allow a client to request and a server to
send additional host keys.  In this way, a client could obtain and store
information about all of a host's keys, instead of just the one used for
key exchange.

The original intent was to specify that this exchange could happen any
time after the first SSH_MSG_NEWKEYS.  Unfortunately, from what I've been
led to believe, at least some versions of the openssh server will react
badly to getting a message they're not expecting immediately after
SSH_MSG_NEWKEYS.  I'll freely admit to not having read the code or tested
this myself, but this possibility was enough to warrant recommending that
clients defer sending the new message until later in the session.

I don't remember who told me this, but I'm pretty sure it's someone who
reads this list.  It is, of course, also possible that this is an old bug
which has been fixed.

> password authentication always allow 'replay' attacks.

If the attacker can see the original password.
There are certainly challenge-response password protocols which are not
subject to replay attacks but also don't provide any means of insuring
the integrity of additional messages.

-- Jeff