Re: [secdir] [xmpp] SecDir review of draft-ietf-xmpp-3920bis-17

[Kurt Zeilenga <[e-mail]>]

On Nov 3, 2010, at 11:10 AM, Matthew Wild wrote:

> On 3 November 2010 17:31, Peter Saint-Andre <[e-mail]> wrote:
>> 
> 
>>      as described under Section 13.7.2.1 (however, the lack of channel
>>      binding in the PLAIN mechanism implies that even authenticated TLS
>>      cannot fully protect the SASL negotiation and subsequent
>>      communications when PLAIN is used).
>> 
> 
> I'm no expert on this, but is this text technically true? I thought
> channel binding would only be beneficial where there is not full TLS
> authentication.

Channel binding is beneficial regardless of whether there the client performed TLS server cert/subject checks.  Note that the server has no clue what checks, if any, the client (or its user) performed.  With channel bindings, it becomes irrelevant to the server whether the client performed these checks or not.  That is, (amongst other things) channel bindings provide a means for the server itself to protect against MITM attacks.

I do agree, however, that he wording of the however comment is confusing and seems should either be removed or replaced.

My main concern is that Unauthenticated TLS is subject to downgrade to PLAIN by two vectors, spoofing mechanisms and spoofing transition required.

Removing <transition-needed/> (in favor of a yet to be specified extension) addresses one vector.

There seems no good way to address the other vector at this time.  I do suggest however that the 13.9.4 text:
   To help prevent this attack, the parties
   SHOULD protect the channel using TLS before attempting SASL
   negotiation.
be replaced with:
   To mitigate this attack, the partied SHOULD protect the channel using TLS before attempting SASL negotiation and either
   perform full certificate validation as described in Section 13.7.2.1 or utilize a mechanism which provides channel bindings,
   such as SCRAM-SHA-1-PLUS. 

-- Kurt