IETF-SSH archive

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

RE: gss userauth




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




Home | Main Index | Thread Index | Old Index