Subject: [xmpp] RFC3920: SCRAM is an incomplete mechanism name

From: Jehan Pagès <[email-masked]>
Date: Sun, 20 Jun 2010 05:01:26 +0900

Hi,

sorry I didn't take enough time lately for reviewing the whole lattest
draft. Still I have at least a remark about section "13.8.
Mandatory-to-Implement Technologies", the prefered mechanism « the
SASL Salted Challenge Response mechanism [SCRAM] » is not a full
mechanism name. It needs the underlying hash function.

Cf. section 4 of the SCRAM draft (
http://tools.ietf.org/html/draft-ietf-sasl-scram-11#section-4 ):
«
  A SCRAM mechanism name is a string "SCRAM-" followed by the
   uppercased name of the underlying hash function taken from the IANA
   "Hash Function Textual Names" registry (see http://www.iana.org),
   optionally followed by the suffix "-PLUS" (see below).
»

This is as though we had said that "DIGEST" was our preferred
mechanism at the time the DIGEST-MD5 was in the XMPP rfc. This is
inexact and too imprecise.

Of course we could say "any SCRAM mechanism", but if this is the case,
our text should be re-worded this way; because right now, it looks
like a XMPP server could advertise a mechanism simply named "SCRAM"
which does not exist by itself.

Yet I don't think such decision is the best option as it leaves too
much possibilities (there are like dozens of hash algorithm). We
should probably choose at least one preferred hash function to be used
inside SCRAM to make our preferred mechanism (eventually adding than
any additional SCRAM mechanism can be considered but not preferred).
What do you think of it? This point has never been raised on the list
(I must admit I don't read everything)?

Jehan

P.S.: note that the SCRAM draft asks all SCRAM implementations to
implement at least SCRAM-SHA1 for interoperability though we could
still decide for another one to be our "preferred" (like at least
using an algorithm of the SHA-2 family, or maybe SCRAM-MD5).

---

From: Waqas Hussain <[email-masked]>
Date: Sun, 20 Jun 2010 01:48:51 +0500

> using an algorithm of the SHA-2 family, or maybe SCRAM-MD5).

As you yourself noted, SCRAM mandates SCRAM-SHA-1 in pretty strong words (MUST):

   For interoperability, all SCRAM clients and servers MUST implement
   the SCRAM-SHA-1 authentication mechanism, i.e. an authentication
   mechanism from the SCRAM family that uses the SHA-1 hash function as
   defined in [RFC3174].

This by extension implies that the XMPP draft mandates SCRAM-SHA-1. I
was under the impression that the draft specifically mentioned
SCRAM-SHA-1. I'm neither for nor against that though.

By the way, the text I quoted was what kept me from arguing against
(SCRAM-)SHA-1 being MTI in XMPP, and for the SHA-2 family of hashes.
Seeing as how the SHA-2 set of hashes was published in 2001, three
years before the original XMPP RFC, and that there are known
weaknesses in SHA-1, it does make some sense.

--
Waqas Hussain

---

From: Jehan Pagès <[email-masked]>
Date: Sun, 20 Jun 2010 06:18:56 +0900

Hi,

>   mechanism from the SCRAM family that uses the SHA-1 hash function as

In the text you quote and that I indeed mentioned, I don't see at all
this like a MUST meaning "this is the secure algorithm we adviced".
The important keywords are "For interoperability" here. This is
probably the same reason why we still keep the PLAIN mechanism in our
"Mandatory-to-Implement Technologies". This is a MUST of
interoperability and we explicitely wrote between parentheses "not
preferred". But in our RFC, we are also suggesting a MUST of
preference (SCRAM, hence currently incomplete).

In fact in the SCRAM draft, they clearly don't give preference
(section 9, security considerations):

«
 This preference
   order is not specified here as it is a local matter.  The preference
   order should include objective and subjective notions of mechanism
   cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be
   preferred over SCRAM with SHA-1).
»

Whereas it is understandable for this draft which explains a generic
mechanism system, XMPP is a usage protocol and its rfc clearly takes
more implication as we clearly want to give a preference for
authentication mechanisms. And I think this is a good thing.

> weaknesses in SHA-1, it does make some sense.

Yes I am not an expert in cryptographic algorithms but from what I
seem to see in this area, one of the SHA-2 algorithm (but same, we
should choose one precisely, SHA-256 seems to be fairly well used and
spread, no?) are both common and pretty secure compared to SHA-1 or
MD5. Am I wrong?

Jehan

---

From: Florian Zeitz <[email-masked]>
Date: Sun, 20 Jun 2010 00:18:15 +0200

> authentication mechanisms. And I think this is a good thing.

I don't know if this is your point, but let's start with this:
We don't *have to* specify a preferred SCRAM mechanism. What we
currently do is mandate MTI SASL mechanisms. Our preferred one is SCRAM.
Every SCRAM implementation MUST support the SCRAM-SHA1 SCRAM mechanism.
Therefore what's currently specified is complete and gives us a
interoperable system.
Now we *can* choose to prefer (and require) another additional SCRAM
mechanism for usage in XMPP. Note that this will in any case be
additional to servers supporting SCRAM-SHA1, because this is already
required by SCRAM itself.
I don't personally have any strong opinion on this. Some hardening is
certainly a good thing to do though.

- --
Florian Zeitz

---

From: Jehan Pagès <[email-masked]>
Date: Sun, 20 Jun 2010 13:58:32 +0900

Hi,

> certainly a good thing to do though.

ok I see your point. My opinion is then that hardening is a good thing
as you stated.

Moreover it looks to me this was also the whole point of showing a
clear "preference" (as this is the word we use in the RFC 3920) which
enables to have at least one common strong authentication mechanism to
all XMPP's entity implementation. It does not prevent server's
implementations to advertise (and client's implementation to be able
to negotiate) other mechanisms and even to choose another first
preferred ones, but at least if the chosen implemented preferred
mechanisms between a client and a server have nothing in common, they
will always (as long as they followed the RFC of course) be able to
fall back on a mechanism that we considered secure enough.

But there may be matter to discuss.
Bye.

Jehan

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 20 Jun 2010 11:46:55 +0200

Further, a reference to "SCRAM" also needs to be qualified whether the
non-channel binding variant is OK or not.  The SCRAM specification says
that you ought to be using channel bindings.  So you may want to make
"SCRAM-SHA-1-PLUS" the mandatory-to-implement mechanism instead of just
"SCRAM".  Or say "SCRAM-SHA-1 or preferably SCRAM-SHA-1-PLUS when
possible".

/Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Jun 2010 20:02:42 -0600

On 6/20/10 3:46 AM, Simon Josefsson wrote:
> that you ought to be using channel bindings. 

That's good advice.

> So you may want to make
> "SCRAM". 

It's not clear to me if we need to specify MTI mechanisms at that level
of detail, given that the SCRAM spec says SCRAM-SHA-1[-PLUS] is MTI. But
see below.

> Or say "SCRAM-SHA-1 or preferably SCRAM-SHA-1-PLUS when
> possible".

I've added the following sentence to Section 13.9.4 (Use of SASL):

   If a SASL mechanism provides a channel binding (e.g., this
   is true of [SCRAM]), then XMPP entities using that mechanism
   SHOULD prefer the channel binding variant (e.g., preferring
   "SCRAM-SHA-1-PLUS" over "SCRAM-SHA-1").

BTW, this is related to an existing open issue we have about whether to
specify exact MTI ciphersuites for TLS:

http://trac.tools.ietf.org/wg/xmpp/trac/ticket/2

However, I'll start a separate thread about that.

Peter

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 24 Jun 2010 09:02:52 +0200

>    "SCRAM-SHA-1-PLUS" over "SCRAM-SHA-1").

Sounds good.

I'm equally uncertain how the best phrase this.  On the one side, you
want to give as precise details as possible to enable good interop, but
on the other hand you want to allow flexibility for implementers to
chose a mechanism that suites each environment.

Using SHOULD appears to be a reasonable trade-off; you enable good
interop to be tested, but implementers can chose other variants too if
they really need to.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 24 Jun 2010 09:56:24 +0100

Hi Peter,

>of detail, given that the SCRAM spec says SCRAM-SHA-1[-PLUS] is MTI. But
Well, the intent of the SCRAM document was to say that among SCRAM 
mechanisms, SCRAM-SHA-1 is mandatory to implement.
So, IMHO, 3920bis should specify the exact name.
I would say that SCRAM-SHA-1 is a MUST and SCRAM-SHA-1-PLUS is a SHOULD 
(this is just recognizing the fact that people are not going to 
necessarily implement channel bindings, even though they should), plus I 
would add the sentence suggested by Simon (below).

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 24 Jun 2010 16:44:14 -0600

>>   "SCRAM-SHA-1-PLUS" over "SCRAM-SHA-1").

Well it's not as easy as the text Simon sent, given how our document is
structured. Here is what I have now:

###

13.8.  Mandatory-to-Implement Technologies

   At a minimum, all implementations MUST support the following
   technologies:

   for authentication only:  the SASL Salted Challenge Response
      mechanism [SCRAM], in particular the SCRAM-SHA-1 variant
      (REQUIRED) and SCRAM-SHA-1-PLUS variant (RECOMMENDED if channel
      binding is possible); although the SASL PLAIN mechanism [PLAIN]
      can also be used for authentication only, such usage is strongly
      discouraged

   for confidentiality only:  TLS (using the
      TLS_RSA_WITH_AES_128_CBC_SHA cipher)

   for both confidentiality and authentication with passwords:  TLS plus
      SCRAM-SHA-1 (REQUIRED) or SCRAM-SHA-1-PLUS (RECOMMENDED);
      alternatively, TLS plus SASL PLAIN (but see further security
      considerations under Section 13.9.4)

   for both confidentiality and authentication without passwords:  TLS
      plus the SASL EXTERNAL mechanism (see Appendix A of [SASL]) using
      the TLS_RSA_WITH_AES_128_CBC_SHA cipher supporting peer
      certificates (clients SHOULD support this, and servers MUST)

   Naturally, implementations MAY support other ciphers with TLS and MAY
   support other SASL mechanisms.

      Interoperability Note: The use of the SCRAM-SHA-1 or SASL-SCRAM-
      SHA-1-PLUS mechanism replaces the SASL DIGEST-MD5 mechanism as
      XMPP's mandatory-to-implement password-based method for
      authentication only, and the use of TLS plus either of those SCRAM
      variants or TLS plus PLAIN replaces TLS plus DIGEST-MD5.  For
      backward-compatibility with existing deployed infrastructure,
      implementations are encouraged to continue supporting the DIGEST-
      MD5 mechanism as specified in [DIGEST-MD5], however there are
      known interoperability issues with DIGEST-MD5 that make it
      impractical in the long term.  The use of the SCRAM-SHA-1 and
      SCRAM-SHA-1-PLUS mechanisms is strongly preferred over the SASL
      PLAIN mechanism because of their superior security properties, and
      PLAIN is intended to be a fallback only for implementations that
      do not yet support SCRAM.  For important security considerations
      related to these SASL mechanisms, see Section 13.9.4 and also
      refer to [SCRAM] and [PLAIN].

###

And also some related text from later in the security considerations:

###

13.9.4.  Use of SASL

   Because the initiating entity chooses an acceptable SASL mechanism
   from the list presented by the receiving entity, the initiating
   entity depends on the receiving entity's list for authentication.
   This dependency introduces the possibility of a downgrade attack if
   an attacker can gain control of the channel and therefore present a
   weak list of mechanisms.  To help prevent this attack, the parties
   SHOULD protect the channel using TLS before attempting SASL
   negotiation.

   If the initiating entity (typically a client) is willing to use SASL
   PLAIN over TLS to authenticate to an XMPP server, it MUST verify the
   server certificate.  If the server has not provided any certificate,
   or if certificate validation fails (as described under
   Section 13.7.2), the initiating entity MUST NOT attempt to
   authenticate using the SASL PLAIN mechanism.  After a successful TLS
   negotiation, the initiating entity MUST check its understanding of
   the server hostname against the server's identity as presented in the
   TLS Certificate message, in order to prevent man-in-the-middle
   attacks.  If the match fails, the client MUST NOT attempt to
   authenticate using the SASL PLAIN mechanism.  Server identity
   matching MUST follow the rules specified in [TLS-CERTS].

   The SASL framework itself does not provide a method for binding SASL
   authentication to a security layer providing confidentiality and
   integrity protection that was negotiated at a lower layer.  Such a
   binding is known as a "channel binding" (see [CHANNEL]).  Some SASL
   mechanisms provide channel bindings, which in the case of XMPP would
   typically be a binding to TLS (see [CHANNEL-TLS]).  If a SASL
   mechanism provides a channel binding (e.g., this is true of [SCRAM]),
   then XMPP entities using that mechanism SHOULD prefer the channel
   binding variant (e.g., preferring "SCRAM-SHA-1-PLUS" over
   "SCRAM-SHA-1").  If a SASL mechanism does not provide a channel
   binding, then the mechanism cannot provide a way to verify that the
   source and destination end points to which the lower layer's security
   is bound are equivalent to the end points that SASL is
   authenticating; furthermore, if the end points are not identical,
   then the lower layer's security cannot be trusted to protect data
   transmitted between the SASL-authenticated entities.  In such a
   situation, a SASL security layer SHOULD be negotiated that
   effectively ignores the presence of the lower-layer security.

   Most XMPP servers authenticate account connections by means of
   passwords.  It is well-known that most human users choose relatively
   weak passwords.  Although service provisioning is out of scope for
   this document, XMPP servers that allow password-based authentication
   SHOULD enforce minimal criteria for password strength to help prevent
   dictionary attacks.

   Some SASL mechanisms (e.g., [ANONYMOUS]) do not provide strong peer
   entity authentication of the client to the server.  Service
   administrators are advised to enable such mechanisms with caution.
   Best practices for the use of the SASL ANONYMOUS mechanism in XMPP
   are described in [XEP-0175].

###

/psa