Re: SCRAM protocol documentation

On Fri, Aug 11, 2017 at 3:50 PM, Álvaro Hernández Tortosa
<aht(at)8kdata(dot)com> wrote:
> On 11/08/17 03:57, Peter Eisentraut wrote:
>> The SCRAM protocol documentation
>> (https://www.postgresql.org/docs/devel/static/sasl-authentication.html)
>> states
>>
>> "To avoid confusion, the client should use pg_same_as_startup_message as
>> the username in the client-first-message."
>>
>> However, the client implementation in libpq doesn't actually do that, it
>> sends an empty string for the user name. I find no other reference to
>> "pg_same_as_startup_message" in the sources. Should the documentation
>> be updated?

Yes, definitely. I think that we should mention that the server uses
the username of the startup packet and ignores the data sent by the
frontend potentially provided in client-first-message.

>> Relatedly, the SCRAM specification doesn't appear to allow omitting the
>> user name in this manner. Why don't we just send the actual user name,
>> even though it's redundant with the startup message?

The problem is where a username includes characters as a comma or '=',
which can be avoided if the string is in UTF-8 as the username is
prepared with SASLprep before being used in the SASL exchange, but we
have no way now to be sure now that the string is actually in UTF-8.
If at some point we decide that only things using UTF-8 are good to be
used during authentication, using the username in the exchange
messages instead of the one in the startup packet would be fine and
actually better IMO in the long term. Please note that the
specification says that both the username and the password must be
encoded in UTF-8, so we are not completely compliant here. If there is
something to address, that would be this part.

> If there's a clear meaning about ignoring the user here, why not settle
> on something like the "*"? It's not going to change the world sending a few
> bytes less on initialization, but I guess it doesn't hurt either...

I am not sure either that '*' would be that much helpful. Requiring
that things are in UTF-8 would be more compliant with the original
RFC.
--
Michael