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

[Philip Guenther <guenther+sasl@sendmail.com>]

"Joseph Salowey" <jsalowey@cisco.com> writes:
>> -----Original Message-----
>> From: ekr@romeo.rtfm.com [mailto:ekr@romeo.rtfm.com] On 
...
>> 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).  

For those who don't watch the ietf-announce list or didn't have
their interest perked by the announcement, a discussion of this
problem in the context of EAP can be found in:

http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-03.txt

            The Compound Authentication Binding Problem
...
Abstract

There are several motivations for using compound authentication methods
using tunnels, but man-in-the-middle attacks are possible in certain 
circumstances when they are used, without cryptographically binding the 
methods together. At the time of writing this document, several 
protocols being proposed within the IETF are vulnerable to these 
attacks, including IKE with XAUTH, PIC, PANA over TLS, EAP TTLS and 
PEAP. This document studies the problems and suggests potential 
solutions to mitigate them.


(I have nothing to do with this document; it just seems extremely
relevant and fairly thorough on the point under discussion.  Perhaps
SASL over TLS should be added to the list in the quoted abstract?)


Philip Guenther
guenther@sendmail.com