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

[Eric Rescorla <ekr@rtfm.com>]

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

-Ekr

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