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

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

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

To mitigate this problem you can: 

- Use the protection from the inner SASL method
- Have the SASL authentication mechanism authenticate the TLS Session ID
or some similar parameter 
- Require different credentials be used by a SASL mechanism when
operating inside or outside a TLS tunnel.   

Joe


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