Re: GSASL_CB_TLS_EXPORTER leads to a failure with non-PLUS SCRAM methods

[Simon Josefsson]

defanor via "Discussion list for GNU Simple Authentication and Security
Layer (SASL)" <help-gsasl@gnu.org> writes:

> Hello,
>
> I noticed that GSASL reads the GSASL_CB_TLS_EXPORTER property even when
> a non-"PLUS" SCRAM method is used, and if it is provided, the
> authentication process fails at once. This does seem wrong: I think it
> would be nicer if it did not fail when unnecessary information is
> provided, and if it did not ask for that (e.g., via a callback), either.

Hi!  Thanks for using gsasl and SCRAM.  I'm not certain I understand
your use case fully, and the behaviour may be up for discussion, but
looking at your code example this behaviour is intentional.

I'm sure you have read the manual, but for other readers it may help to
follow along: https://www.gnu.org/software/gsasl/manual/gsasl.html#SCRAM

When the application has a TLS channel binding, a client should not be
using SCRAM-SHA-1 but instead the SCRAM-SHA-1-PLUS mechanism.  So gsasl
is protecting your client from being downgraded by the server from PLUS
to non-PLUS: that's why it fails and reject your authentication attempt.
This downgrade protection is built into the SCRAM protocol, see the RFC.

In the unusual situation where the client has a TLS channel binding and
wants to permit use of non-PLUS (and permit a server downgrade attack)
-- for example if the server does not support PLUS -- it should not set
the CB property, to signal that the application is okay with being
downgraded to non-PLUS protection when tricked by the server.

It is impossible to tell the case where the server does not support PLUS
from the case where the server is trying to downgrade the client into
non-PLUS.  Gsasl decided to protect the client in this situation.

Therefor, client applications should not set the TLS channel binding
when it intentionally wants to use the weaker SCRAM-SHA-1.  The property
should only be set for SCRAM-SHA-1-PLUS.

The reason for that somewhat surprising requirement is that the gsasl
SCRAM implementation doesn't know if your application supports 1) only
SCRAM-SHA-1 or 2) both of SCRAM-SHA-1 and SCRAM-SHA-1-PLUS.

The way gsasl learns if 1) or 2) is supported is from the application
setting GSASL_CB_TLS_UNIQUE/EXPORTER or not.  If the application set the
property, it signals to gsasl that it supports SCRAM-SHA-1-PLUS.  By not
setting it it signals that it does not support SCRAM-SHA-1-PLUS.

So in your example, you told gsasl that the application supports
SCRAM-SHA-1-PLUS but somehow the application chose SCRAM-SHA-1 anyway,
presumably tricked by the server not offering SCRAM-SHA-1-PLUS.  This is
an error case, and it doesn't proceed.

This may be a bit surprising: I think you have a case that setting
various optional properties shouldn't cause breakage like this -- gsasl
could use some other mechanism to differentiate between 1) and 2) than
to overload the CB property.  But this is not implemented today.

I hope this complicated explanation helps.  My view is that this
complexity of SCRAM is actually a problem because it is really difficult
to reason or explain the state machine of the protocol in a reasonable
way, and both me as library implementer and you as application developer
are often left puzzled about how to go about this.  See my rant that
lightly touches on the complexity side:
https://blog.josefsson.org/2021/06/08/whats-wrong-with-scram/

If you disagree, or even better; can think of some way to improve things
without weakening the implementation, please comment!

/Simon

signature.asc
Description: PGP signature