RE: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard

["Joseph Salowey" <jsalowey@cisco.com>]

> -----Original Message-----
> From: ekr@romeo.rtfm.com [mailto:ekr@romeo.rtfm.com] On 
> Behalf Of Eric Rescorla
> Sent: Wednesday, October 08, 2003 10:17 PM
> To: Joseph Salowey
> Cc: xmppwg@jabber.org; iesg@ietf.org; 'SASL WG'
> Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
> 
> 
> "Joseph Salowey" <jsalowey@cisco.com> writes:
> > > How's that again? Please explain the network topology you're
> > > considering here.
> > > 
> > 
> > Ok. I might be misunderstanding something, here is a summary:
> > 
> > A client C that is willing to use SASL mechanism X both inside and 
> > outside a TLS tunnel. A server S that supports a server 
> authenticated 
> > TLS tunnel and then authenticates the client using SASL mechanism X 
> > within the tunnel. An attacker M who can act as a TLS client and a 
> > SASL server for mechanism X.
> > 
> > The network topology/deployment must allow for M to trick C into 
> > trying to authenticate to him using SASL Mechanism X (without TLS) 
> > while M simultaneously establishes a TLS connection with S.
> > 
> > M establishes a TLS session with S
> > M tricks C into trying to authenticate to him using SASL mechanism X
> > without TLS protection (these first steps could happen in 
> the reverse
> > order)
> > M forwards the SASL exchange from C to S and vice versa.  
> > The SASL authentication will succeed and S will believe that the
> > endpoint of the TLS tunnel is C instead of M (For some 
> mechanisms M may
> > have to spoof S's address in order for the authentication 
> to complete).
> > M can disconnect from C and continue sending messages to S.  
> > S thinks the messages from M originate from C. 
> 
> Yes, this will work. But here's the thing:
> 
> This only works if the client would have been prepared to do 
> this weak mechanism over a non-TLS connection.  Generally the 
> client knows when it expects to do TLS and when it doesn't. 
> 

Agreed.  If the client only uses this mechanism over TLS then this is
not a problem. How easy this is to enforce depends upon the deployment
environment, it may be reasonable to assume for XMPP (I'm not very
familiar with XMPP).  I'm not completely sure, but with some mechanisms
using the same mechanism without TLS in a different protocol may lead to
the same problem (If the mechanism does not authenticate the
protocol/service context).  

Joe