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 9:21 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:
> 
> > > -----Original Message-----
> > > From: owner-ietf-sasl@mail.imc.org
> > > [mailto:owner-ietf-sasl@mail.imc.org] On Behalf Of Eric Rescorla
> > > Sent: Wednesday, October 08, 2003 1:28 PM
> > > To: xmppwg@jabber.org
> > > Cc: iesg@ietf.org; SASL WG
> > > Subject: Re: [xmppwg] Last Call: 'XMPP Core' to Proposed Standard
> > > 
> > > 
> > > 
> > > "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> writes:
> > > > I concur with Alexey's recent comments regarding XMPP's
> > > SASL Profile.
> > > > I have a few addition concerns regarding this profile. The
> > > scope of my
> > > > review was, due to time constraints, was limited to the profile.
> > > > 
> > > > I not sure why the documents says that SASL and TLS security 
> > > > layers
> > > > SHOULD NOT be enabled simultaneously (Section 6.2, rule 2), 
> > > but this
> > > > recommendation is, I believe, flawed.  There are numerous use 
> > > > cases
> > > > where implementations SHOULD establish additional layers. 
> > > For example,
> > > > establishing additional SASL layers may prevent certain kinds of
> > > > tunneling man-in-the-middle attacks.
> > > Could you describe some of them?
> > > 
> > 
> > If the TLS tunnel is only server authenticated and the 
> client supports 
> > a particular SASL method (perhaps even in a different protocol)that 
> > provides mutual authentication both inside and outside a TLS tunnel 
> > there is a vulnerability.  In this case if only the message 
> protection 
> > of TLS is used you cannot be sure that the client endpoint 
> of the TLS 
> > tunnel is the same client endpoint that the server 
> authenticated with 
> > SASL.
> 
> 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. 

Joe