Subject: Re: [xmpp] SASL preference order

From: Jehan Pagès <[email-masked]>
Date: Tue, 22 Mar 2011 04:11:55 +0900

Hi,

On Thu, Feb 3, 2011 at 12:12 AM, Peter Saint-Andre <[email-masked]> wrote:
> I suggest this...
>
> from:
>
>   A server MUST offer
>   and a client MUST try SASL mechanisms in preference order.
>
> to:
>
>   A client MUST try SASL mechanisms in its preference order.
>
> The rest of the paragraph can stay the same.

I would like to come back on this text, not exactly on the topic which
was raised here but something related. I only thought about this just
a moment ago.
So right now the updated text is:
«
   A client MUST try
   SASL mechanisms in its preference order.  For example, if the server
   offers the ordered list "PLAIN SCRAM-SHA-1 GSSAPI" or "SCRAM-SHA-1
   GSSAPI PLAIN" but the client's ordered list is "GSSAPI SCRAM-SHA-1",
   the client MUST try GSSAPI first and then SCRAM-SHA-1 but MUST NOT
   try PLAIN (since PLAIN is not on its list).
»

Which annoys me here is the more or less implicit idea that we say
that a client should go through all its common mechanisms with the
server (in the client's order but that's not my point here) until the
authentication succeeds.
But in the above RFC example for instance, if the client tries to
authenticate via GSSAPI, then it fails, I don't see why it should now
try SCRAM-SHA1! It may try again GSSAPI but not downgrade its security
choice. That's a security issue. If the server says it understand
GSSAPI and the client does too, but it fails, we should be even more
cautious as there is something strange here, whereas the current text
implies that we should go lighter on security.

That could actually be a downgrade attack which works-around the fact
a secure client would check that subsequent connections to a server do
not propose a weaker authentication list: a rogue server could propose
the same list than the real server but fail on purpose any mechanism
until the client goes on a PLAIN mechanism in order to obtain the
password.
So I would propose a change to the text like this:

«
A client MUST try only the SASL mechanism which has the higher
preference in its own list and is on the server list. For example, if
the server offers the ordered list "PLAIN SCRAM-SHA-1 GSSAPI" or
"SCRAM-SHA-1 GSSAPI PLAIN" but the client's ordered list is "GSSAPI
SCRAM-SHA-1",
the client MUST try GSSAPI only and MUST NOT try SCRAM-SHA1, nor
PLAIN. In particular a client MUST NOT downgrade the SASL mechanism if
the authentication with its preferred SASL mechanism failed.
»

Also maybe a security note could also be added to propose keeping a
server's mechanism list in a client's memory and alert the user when
the SASL mechanisms proposed changed in what seem a weaker list (in
particular when the mechanism the client usually negotiates is
removed). Right now in the security considerations, "13.9.4. Use of
SASL", the use of TLS is the only protection proposed for such
downgrade attack. I think this could be an additional layer of
security.

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Mar 2011 13:33:18 -0600

> was raised here but something related. I only thought about this just

I'm sorry, but it is too late. The documents have completed AUTH48 and
the changes discussed on this list and at the interim meeting have been
specifically approved by our Area Director (Gonzalo Camarillo).

Any further suggestions for improvement will need to be discussed in the
future when we work on 3920ter / 6120bis (I would expect that to happen
in a year or two).

Peter

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

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 22 Mar 2011 04:59:59 +0900

Hi,

> specifically approved by our Area Director (Gonzalo Camarillo).

Argh! I should have seen this earlier.

> future when we work on 3920ter / 6120bis (I would expect that to happen

Ok. :-) That's not as though it was the end of the world though.
Anyway my remark still holds, at least for general discussion until it
can be included in 6120 bis. :-)

Maybe I can propose this as an errata for now, then.

Jehan

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 21 Mar 2011 13:01:53 -0700

>   try PLAIN (since PLAIN is not on its list).

I note that what the server provides is likely not an ordered by strength.  The client should treat it as the set of mechanisms the server supports (implements).  The client must rely on it own knowledge of security strength of the mechanisms (including inner mechanism options) it's supports.

> server (in the client's order but that's not my point here) until the

I dislike the implicit assumption that negotiation of mechanisms is done repeatedly.  For most clients, they should it as part of configuration of the service profile, remember what was best and remember how the best was determined.  Then if the client subsequently notices a better mechanism might be available, it can then ask the user to reestablish the service profile (and hence redetermine the best mechanism).

> choice.

What if GSSAPI passes with less security than what SCRAM-SHA-1 provides?

The answer here is more that the client should be careful not to trust the list provided by the server until it authenticated the server, such as by using TLS with full server cert checking or uses a SASL mechanism that supports channel bindings.

> That's a security issue.

While there is a downgrade attack in absence of integrity protection, this is mitigated by having the client not continue using a session if the security achieved by the mechanism (in conjunction with TLS, etc.) does not met the minimum requirements.

So, for instance, if the minimum requirement was 'require mechanisms that provide transport integrity (with authentication of server)', then SCRAM-SHA-1 should not be tried or, if tried, should not be used, in absence of TLS with full cert checking.   And likewise, only allow GSSAPI if there is integrity protection.

> If the server says it understand

First, there's lots of not so strange reasons why a particular mechanism exchange might fail.

And second, I don't it implies we are going lighter on security.  SASL mechanism in XMPP and in general only ensures, if properly implemented, that the mechanism selected and used mets the minimum requirements of both the client and server.

The security threat here is that the security of SASL negotiation will be over sold as negotiating something better than the minimum requirements of both client and server.

> until the client goes on a PLAIN mechanism in order to obtain the

See my suggestion above about doing mechanism selection at configuration of service profile time instead of at each connection.

> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Mar 2011 14:03:45 -0600

> Maybe I can propose this as an errata for now, then.

I think this is a good topic to discuss, but I don't see specific text
for an erratum yet. Please keep this in mind for the 6120bis work,
though. :)

Peter

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

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 21 Mar 2011 13:09:11 -0700

On Mar 21, 2011, at 12:11 PM, Jehan Pagès wrote:

> implies that we should go lighter on security

And, I should have noted in my first post, that the attacker here, if it wanted to downgrade the client to SCRAM-SHA-1, it would have just listed that as the only available mechanism.  Hence, your suggestion hinders more to hinder useful downgrade by the client than it does to hinder downgrade attack.

-- Kurt