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

[Eric Rescorla <ekr@rtfm.com>]

"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. 

-Ekr


-- 
[Eric Rescorla                                   ekr@rtfm.com]
                http://www.rtfm.com/