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

[defanor]

Thanks for the detailed explanation!

> 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.

I see, this is what I missed. It does make sense to err on the side of
caution in this case. Below are my musings on how it could be made less
confusing, though possibly it would not have been as confusing if I was
more focused upon running into it.

Since it is handled rather implicitly, possibly a separate error code
with an error message explaining the situation (e.g., "possible
downgrade attempt detected: channel binding data is available, but a
non-PLUS SCRAM mechanism is used", rather than "Error authenticating
user") would make this clearer.

Another way to make this more explicit may be not to ask for channel
binding data, but to ask whether it is available, since apparently this
is what GSASL is actually interested in when non-PLUS mechanisms are
used. Though this would be redundant, and then it would be easy to miss
possible downgrades without allowing those explicitly, by implementing
handling of GSASL_CB_TLS_EXPORTER, but not of that additional
property. That would be similar to letting a library user to inspect the
combination of a selected mechanism and availability of channel binding
data on their own, even before calling gsasl_client_start. But possibly
this would also be akin to "logical properties", asking a library user
to make a decision.

My use case was simply a server not supporting "-PLUS" mechanisms, which
led to failures upon me setting channel binding data whenever GSASL
asked for it via a callback, and not looking at chosen mechanisms (so
that those are not hardcoded, and left up to a SASL implementation),
letting GSASL to pick one and run the authentication process. But now I
added a check for selected mechanisms, and probably will add a setting
for protection against such possible downgrades. Maybe this is what
GSASL can have as well? So that a library user would set that, keeping
mechanism names abstract, not inspecting those. Although the extent to
which it is possible to keep them abstract is limited anyway, since the
Gsasl_property properties define their rough shapes, and depend on
those.

Mentioning this explicitly in the manual's GSASL_CB_TLS_EXPORTER
description may also be helpful, though it might bloat the documentation
too much.