RE: gss userauth

[Steven Michaud <smichaud%pobox.com@localhost>]

> It is a type of MITM attack, but the problem [possible hijacking of
> GSSAPI credentials] occurs before encryption is established.

I'm still trying to wrap my head around the MITM attack(s) you
describe ... so I still can't discuss the whole issue intelligently.

But I think your statement above is false with respect to gss userauth
(as described in section 3 of draft-ietf-secsh-gsskeyex).  Though it
does seem to be true of gss key exchange (as described in section 2).

In gss key exchange, GSSAPI authentication occurs at the beginning of
the key exchange process, while the transport layer is being
negotiated.  So yes, it will take place while the SSH conversation is
still in the clear.

But gss userauth is part of the authentication protocol.  A standard
key exchange (possibly a DH one) has already taken place, and the
secure transport layer has already been negotiated.

Now, of course, during the GSSAPI authentication process the ssh
client may (from inside the Kerberos 5 mechanism) talk with the KDC
(to get a TGT and/or a service ticket), and these conversations can't
take place over SSH encryption, no matter when they occur.  But the
opaque tokens that are explicitly passed between the ssh client and
the ssh server (as they repeatedly call gss_init_sec_context() and
gss_accept_sec_context()) certainly _can_ travel over an SSH-encrypted
pipe.

Or have I completely misunderstood what you said? :-)

On Mon, 25 Aug 2003, Joseph Salowey wrote:

>
>
> > -----Original Message-----
> > From: Steven Michaud [mailto:smichaud%pobox.com@localhost]
> > Sent: Monday, August 25, 2003 2:55 PM
> > To: jsalowey%cisco.com@localhost
> > Cc: galb-list%vandyke.com@localhost; jhutz%cmu.edu@localhost; lha%stacken.kth.se@localhost;
> > ietf-ssh%NetBSD.org@localhost
> > Subject: Re: gss userauth
> >
> >
> > > [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.
> >
> > Are you talking about some kind of man-in-the-middle attack?
> > If so, wouldn't the MITM have to break in after the key
> > exchange had taken place, the session id had been negotiated,
> > and encryption was already in effect?  (Which is when gss
> > userauth happens.)  And wouldn't this be impossible?
> >
>
> [Joe] It is a type of MITM attack, but the problem occurs before
> encryption is established.  If the GSSAPI credentials are usable with
> another service besides SSH then an attacker intercepting this
> credential exchange which is not protected by SSH can then use it within
> an SSH exchange as if they were the valid client.  As a further
> extension if a client is tricked into participating into an exchange
> with an invalid SSH server (ie. Fails to validate the host key properly)
> then the receiver of the invalid credential may be able to use it to
> authenticate to the valid server as the client.   Binding the session ID
> into the GSSAPI exchange can help prevent these problems.
>
> > Or are you talking about the server somehow misunderstanding
> > what the client was after?
> > In this case wouldn't it be up to
> > the client to leave no room for doubt?
>
>
>
>