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

[Peter Saint-Andre <[e-mail]>]

On 11/3/10 9:02 AM, Kurt Zeilenga wrote:
> 
> On Nov 3, 2010, at 5:13 AM, Peter Saint-Andre wrote:
>> You make a compelling argument. I wish you had made that argument
>> months ago, but it is compelling.  Indeed, it leads in the
>> direction of two consensus calls within the XMPP WG:
>> 
>> (a) to remove the <transition-needed/> SASL error condition
>> 
>> (b) to remove TLS plus SASL PLAIN as MTI for confidentiality and 
>> authentication
>> 
>> Ideally, both of those changes would be accompanied by additional 
>> security-related text, and in case (b) an interoperability note.
> 
> First, I note that (b) is a no-op in practice.  Implementations are
> going to support SASL PLAIN regardless.  Hell, we could even MUST NOT
> it and folks would still implement it.  It's simply too damn
> necessary for integration with 'legacy' password stores.  (I still
> rather we not MTI PLAIN.)

This is true.

> Second, (a) only removes one of two significant downgrade attack
> vectors, the other vector being the mechanisms advertisement and its
> handling.  (I still rather we remove it.)

We're not about to get rid of mechanisms advertisement, given that it's
what enables us to do SASL authentication in the first place. :)

However, <transition-needed/> is new in 3920bis and it's better to
remove it now than to encourage software to implement it, only to remove
it in a few years.

> While we can well craft our security warnings and considerations and
> guidance on how to use unauthenticated v. authenticated TLS and hope
> that client developers get it right.  Basically that text would say
> "use authenticated TLS" to protect against downgrade attack.  

And we already say that.

> That
> sounds great but I doubt its going to have much effect (though I
> think it still should be said).  Clients are still going to offer
> user's security check bypasses and users are going to continue to
> take those bypasses.

Also true.

> Also as I noted previously, these problems are not unique to XMPP.
> Instead of slowing down the publication of XMPP, it might be better
> to spin a more general effort to explore ways to address security
> issues due to general assumption that TLS will be used with server
> authentication when it is often used without server authentication,
> and more generally, explore ways to address the "user click through"
> problem (that is, how to secure protocols such that bypasses are less
> needed).

That does sound like a worthy effort. It might intersect with the WEBSEC WG.

> Lastly, please note that I don't consider this issue 'critical' at
> this point.  It's not going to be critical until such attacks are far
> more common place.  The best way to currently mitigate such attacks
> is to restrict the set of usable mechanisms to those immune to the
> attack.  (For enterprises which provide 'client builds' to their
> users, they can do this for their users as part of those builds.
> But, in general, this requires user configuration and hence prone to
> failure.)

OK, so here is one path forward:

(a) Remove <transition-needed/> because it opens a hole that wasn't open
with RFC 3920 and doesn't need to be opened now.

(b) Remove TLS plus SASL PLAIN as mandatory-to-implement for the same
reason (note that it was not mandatory-to-implement in RFC 3920).

As previously mentioned, I think we also need to update the relevant
part of the security considerations -- here is proposed text:

###

13.8.3.  For Confidentiality and Authentication With Passwords

   For both confidentiality and authentication with passwords, servers
   and clients MUST implement TLS with the TLS_RSA_WITH_AES_128_CBC_SHA
   ciphersuite plus SASL SCRAM, in particular the SCRAM-SHA-1 and SCRAM-
   SHA-1-PLUS variants.

      Interoperability and Security Note: In practice, when SCRAM is not
      available, typically servers and clients use TLS plus SASL PLAIN.
      The SCRAM-SHA-1 and SCRAM-SHA-1-PLUS variants of the SCRAM
      mechanism are strongly preferred over the PLAIN mechanism because
      of their vastly superior security properties (including the
      ability to enforce channel binding as described under
      Section 13.9.4).  Although in certain deployment scenarios it can
      be difficult for a server to offer SCRAM-based mechanisms (e.g.,
      because the XMPP service depends for authentication purposes on a
      database or directory that is not under the control of the XMPP
      administrators), in general implementations SHOULD treat TLS plus
      SASL PLAIN as a technology of last resort when interacting with
      implementations that do not yet support SCRAM; in particular, a
      client MUST prefer more secure mechanisms (e.g., SCRAM-SHA-1,
      SCRAM-SHA-1-PLUS, and EXTERNAL) to the PLAIN mechanism and MUST
      NOT use the PLAIN mechanism without at a minimum confidentiality
      and integrity protection via TLS with full certificate validation
      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 have no great love for <transition-needed/> or SASL PLAIN, and given
that they were not mentioned or encouraged in RFC 3920 I see no strong
reason to add them in 3920bis. Yes, PLAIN will be used in the short run
and it is helpful to document that fact for interoperability purposes,
but hopefully we can move away from PLAIN with all due speed by
encouraging the use of SCRAM and of EXTERNAL with client certificates.

If the chairs are willing, I would like to request a consensus call on
(a) and (b), based on feedback received during the security review.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/