Why is PLAIN prefered over SCRAM-SHA-1?

[brong]

From: Thijs Alkemade
Bugzilla-Id: 3793
Version: 2.1.25
Owner: Alexey Melnikov

[brong]

From: Thijs Alkemade

I'm trying to use Cyrus-SASL version 2.1.26 (previously we were using the library that is included in OS X, so version 2.1.22). Reason for me to update is SCRAM-SHA-1 support on XMPP.

However, I've noticed that when presented with "PLAIN SCRAM-SHA-1 DIGEST-MD5" (on a TLS-encrypted connection), Cyrus 2.1.26's first pick is PLAIN, even though I can confirm that for all three the plugin is available. That is not what I expect, as I consider it the weakest of those mechanisms.

In a debugger I figured out the following is happening:

• sasl_client_start() gets the list of mechanisms, and sorts them based on *-PLUS or not (which doesn't change the order, as none are PLUS).
• The for-loop on line 749 of client.c starts with PLAIN, finds the mechanism and stores it in the bestm variable, as it was still NULL.
• It comes to SCRAM-SHA-1, compares it to bestm, but rejects it on line 828 because SCRAM-SHA-1 does not have the SASL_SEC_PASS_CREDENTIALS 'security flag' that PLAIN does have.
• Same thing happens for DIGEST-MD5.

I do not fully undertand the meaning of SASL_SEC_PASS_CREDENTIALS, but if I'm correct that it means that the server can derive the credentials from the exchange... then I don't see how that is an advantage over mechanisms that do not have that property. In fact, I would say that the security flag should be inverted (never pick one with SASL_SEC_PASS_CREDENTIALS if the current bestm does not have SASL_SEC_PASS_CREDENTIALS).

[brong]

From: Alexey Melnikov

Initial fix: 26dcfb2

Further improvements to the logic will be needed to make the fix more generic.

[brong]

From: Thijs Alkemade

Sorry, it's been a while, but I've finally been able to test the changes in 26dcfb2.

The situation is somewhat different, but the basic problem is the same: given the possibilities PLAIN SCRAM-SHA-1 DIGEST-MD5, Cyrus SASL will now prefer DIGEST-MD5, then PLAIN, then SCRAM-SHA-1.

I think the reason it still happens is that SCRAM-SHA-1's max_ssf value is 0, so is PLAIN's, but DIGEST-MD5's value is at least 1 (depending on compile-time flags).

So PLAIN is selected first, it is then compared to SCRAM-SHA-1. The flags are not worse, so it is not rejected there anymore, but the check:

client.c:866:

if (bestm && m->m.plug->max_ssf <= bestssf) {

Will conclude that SCRAM-SHA-1 is not better than the mechanism we already have, so it is rejected. DIGEST-MD5 does succeed this test, so it is picked instead.

I don't know what max_ssf means exactly, but it looks wrong to me that SCRAM-SHA-1 has the same score as PLAIN.

[ksmurchison]

Hopefully fixed by 37ab5a8

[Neustradamus]

@brong, @ksmurchison: There is a problem of priority for SCRAM-SHA-256 and SCRAM-SHA-1:

• Prioritize SCRAM-SHA-256 over SCRAM-SHA-1 #577

Any news for other points?

• Add SCRAM-SHA-1-PLUS, SCRAM-SHA-224-PLUS, SCRAM-SHA-256-PLUS, SCRAM-SHA-384-PLUS, SCRAM-SHA-512-PLUS, SCRAM-SHA3-512(-PLUS) supports #552

It is easy to add -PLUS part, no?

Documentation problems:

• There is a problem in documentations, please update documentations #549