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

[Kurt Zeilenga <[e-mail]>]

On Nov 2, 2010, at 1:17 PM, Peter Saint-Andre wrote:

> On 11/2/10 1:03 PM, Kurt Zeilenga wrote:
>> 
>> On Nov 2, 2010, at 9:37 AM, Peter Saint-Andre wrote:
>> 
>>>> 
>>>> I suspect I'm in the rough on both points.  Oh well.
>>>> 
>>>>> 2. The technology that the XMPP community uses for account 
>>>>> registration (XEP-0077) could benefit from an update, or even
>>>>> a replacement, and when that work is completed I'd like to
>>>>> include a method by which a client could register a key or cert
>>>>> with the server, thus smoothing the path toward password-less 
>>>>> authentication. IMHO that will be the best approach in the
>>>>> longer term, instead of continually tweaking the password-based
>>>>> methods. But that's a topic for another time...
>>>> 
>>>> I also think transition-needed needs to be deprecated in favor
>>>> of transition within the bound channel (e.g., today via XEP 77,
>>>> tomorrow ?).
>>> 
>>> I'm not sure exactly what "transition within the bound channel" is,
>>> but it sounds worthy of discussion when we work on 3920ter.
>> 
>> The problem with transition-needed is that the error is sent outside
>> the bound channel.
>> 
>> By "within the bound channel", I mean a transitioning method,
>> including any necessary signaling, would be performed inside the
>> bound channel, that is, within the new <stream:stream/> protected by
>> the SASL exchange.
>> 
>>> At this point I don't think the XMPP community has a great deal of
>>> experience with, or even understanding of, channel binding, so it's
>>> difficult for us to make strong recommendations that depend on
>>> channel binding.
>> 
>> It would be same issue of doing transition outside of a SASL
>> negotiated security layer.  It's prone to attack.  And the fix is the
>> same.
> 
> What is the attack?

> If the client required negotiation of TLS before
> moving on to SASL, the server has already authenticated to the client at
> the stage.

In the SASL negotiated security label case, assume no TLS is used.

In the channeling binding case, assume the user/client is relying on the SASL mechanism's mutual authentication capabilities to identify the server and is merely using TLS to provide stream security.   This is, I think, one of the most significant use case of channel binding, at least from the client's perspective. (From the server's perspective, I think the most significant aspect of channel binding is that server no longer needs to rely on the client and its user to verify the server's certificate and perform subject name checks, both of which are likely not to done well.)

> As I far as I understand, you are arguing that SASL negotiation could result
> in establishment of a further security layer
> that is bound to the TLS layer via channel binding, and that it is safe
> for the client to send plaintext credentials to the server only after
> channel binding has taken place. Correct?

I am assuming one either has a SASL negotiated security layer OR a securely bound lower-level channel (eg, TLS), not both.

In both cases, with the existing <transition-needed/> error, the SASL exchanged has failed, nothing is protected by the SASL exchange.  Which means there is no (new) SASL security layer and no channel binding.  So, if the user/client is relying on the SASL mechanism's mutual authentication, it needs to be extremely caution about what it does in response to that error.

By signaling the client that transition is needed in the new stream and performing the transition in that stream, we ensure that protections provided by any security layer or bound channel is in place.

While the attacker could just as well have attempted to get the client to do PLAIN by ensuring PLAIN is the only mechanism listed, a client might well caution that use of PLAIN is generally dangerous, most clients won't give a complain about the downgrade (because most clients don't remember last used mechanism).  By using <transition-needed/> error, the attacker likely can get the client to display specific noting the server has requested transition (hopefully with a warning about the possibility this could be spoofed, and PLAIN is dangerous.  Though I don't have a reference, I recall some claiming that users are more likely to click through the latter dialogs than the former. 

That is, <transition-needed/> spoofing may well be a more successful downgrade attack than SASL mechanism spoofing.

> If so, then we'd need to
> define a post-SASL protocol (that might include work on periodic
> re-authentication requests sent from server to client). But IMHO that
> work is out of scope for 3920bis. The question is: is it better to

> remove the <transition-needed/> SASL condition pending work on the
> future protocol extension?

I think the question can simple as simple as "Should <transition-needed/> be removed?".  I am fine with the question being viewed as "too late" to ask.

> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 
> _______________________________________________
> xmpp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xmpp