RE: gss userauth

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

I'm still not sure I've understood the MITM attacks you've described.
But, as long as the GSSAPI client is using mutual authentication (and
the underlying mechanism is using reasonably strong encryption), I
don't think it's possible to hijack the user's GSSAPI credentials by
sniffing the wire, no matter how much of the GSSAPI traffic has been
intercepted (and even if none of it is protected by SSH encryption).

As far as I can tell, the worst danger you face is that the GSSAPI
authentication would be to some other service running on the same
server that also used the "host@" service name.  But this kind of
ambiguity could (presumably) be eliminated by changing how the other
service was set up.  (I assume that if someone had rooted the server
and replaced the "other" service with a malicious copy, he/she could
have done the same with sshd.)

That said, I see the point of having gss userauth "bind" the SSH
session id:  It seems like there's a way to do this ("sending the
Session ID in the MIC") that won't "cost" much and can preserve
backwards compatiblity.  And, though perhaps redundant, it will help
ensure against weaknesses in SSH or GSSAPI that haven't yet been
discovered.

But I don't think there's a "hole" that those who maintain current
implementations of draft-ietf-secsh-gsskeyex (Simon Wilkinson's patch
to OpenSSH, SecureCRT) need to scramble to "patch".  Nor do I think
that the OpenSSH maintainers, who are currently considering adding a
partial implementation of Simon's patch (one that includes gss
userauth but not gss key exchange), need to postpone this addition.
(That isn't up to me, but I'm trying to convince the OpenSSH folks.
I'm a big fan of Simon Wilkinson's patch and think adding even parts
of it to standard OpenSSH would make GSSAPI authentication for SSH
more widely available.)

What I say above is based on the assumption that the GSSAPI protocol
will do what it's supposed to -- most importantly, that its mutual
authentation of client and server will really work, and that this will
guarantee that the "wrong" "host@" service must be running on the same
server as the "true" sshd (not on some other computer, with a spoofed
ip address, running a malicious replacement for sshd).

The only GSSAPI mechanism that I know reasonably well is Kerberos 5.
It does (of course) support mutual authentication.  And (if you're
using strong encryption) it seems to guarantee that neither the
client's secret key (derived from the "Kerberos password") nor his/her
(short-lived) credentials (what's in the ticket cache) can be captured
by network-sniffing alone (even if the attacker replays captured
network traffic).  Furthermore, because Kerberos 5's service
principals take the form "servicename/fdqn@realm", the "host@" service
to which the ssh client might mistakenly authenticate would have to be
running on a server whose "true" name is "fdqn" (not a machine that
was spoofing that address, because otherwise mutual authentication
would fail) -- which presumably (if the admins were doing their job)
would have to be the server on which the "true" sshd was also running.

Very few other GSSAPI mechanisms exist.  I know of the GSI mechanism
that (I think) was developed by Douglas Engert, though I'm not very
familiar with it.  But I do believe it also supports mutual
authentication.  And I'd be surprised to find _any_ GSSAPI mechanism
whose service principals don't include the host name.

Slightly off topic:  Would it be reasonable to make gss userauth fail
if mutual authentication isn't available?

On Mon, 25 Aug 2003, Steven Michaud wrote:

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