Thread: [HACKERS] SCRAM protocol documentation
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? 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? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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? > > 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? > Hi Peter. You are absolutely right, I was also surprised by this when I was doing the JDBC implementation. Actually I chose to send an asterisk ("*"), see https://github.com/pgjdbc/pgjdbc/pull/842/files#diff-c52128420a3882543ffa20a48964abe4R88, as it is shorter than the username (likely). I don't like the empty string either, and actually the library built for the JDBC and used in pgjdbc does explicitly disallow the use of an empty username. 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... Álvaro -- Álvaro Hernández Tortosa ----------- <8K>data
On Fri, Aug 11, 2017 at 3:50 PM, Álvaro Hernández Tortosa <aht@8kdata.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
On 11/08/17 13:18, Michael Paquier wrote: > On Fri, Aug 11, 2017 at 3:50 PM, Álvaro Hernández Tortosa > <aht@8kdata.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. But it already says so the documentation: "The username that was already sent in the startup message is used instead." > >>> 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. The reason why the username is ignored, unless I'm wrong, is not exactly that it is already sent. It is that Postgres does not restrict usernames to be UTF-8 only, while SCRAM does. As such, if a username would not be UTF-8, it will not be sent reliably over SCRAM. > >> 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. But we really don't need to send the username, since Postgres already knows it (and that accommodates for non UTF-8 usernames). So why bother? Just sending something like "*" (which is UTF-8 and produces the same value under Saslprep) should be enough. I think the idea of ignoring the username is pretty neat, but maybe a "standard" like "send me an asterisk here" could be even better than leaving it empty. Álvaro -- Álvaro Hernández Tortosa ----------- <8K>data
On Fri, Aug 11, 2017 at 9:31 PM, Álvaro Hernández Tortosa <aht@8kdata.com> wrote: > On 11/08/17 13:18, Michael Paquier wrote: >> On Fri, Aug 11, 2017 at 3:50 PM, Álvaro Hernández Tortosa >> <aht@8kdata.com> wrote: >>>> 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. > > The reason why the username is ignored, unless I'm wrong, is not exactly > that it is already sent. It is that Postgres does not restrict usernames to > be UTF-8 only, while SCRAM does. As such, if a username would not be UTF-8, > it will not be sent reliably over SCRAM. That's basically the point I was making. Note that I would not be against Postgres forcing strings to be in UTF-8. Now things are fuzzy because of the lack of restrictions. >>> 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. > > But we really don't need to send the username, since Postgres already > knows it (and that accommodates for non UTF-8 usernames). So why bother? > Just sending something like "*" (which is UTF-8 and produces the same value > under Saslprep) should be enough. I think the idea of ignoring the username > is pretty neat, but maybe a "standard" like "send me an asterisk here" could > be even better than leaving it empty. Personally I don't see much difference between both, so I'd rather leave things as they are now. -- Michael
On 11/08/17 15:00, Michael Paquier wrote:
> On Fri, Aug 11, 2017 at 9:31 PM, Álvaro Hernández Tortosa
> <aht@8kdata.com> wrote:
>> On 11/08/17 13:18, Michael Paquier wrote:
>>> On Fri, Aug 11, 2017 at 3:50 PM, Álvaro Hernández Tortosa
>>> <aht@8kdata.com> wrote:
>>>>> 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.
>> The reason why the username is ignored, unless I'm wrong, is not exactly
>> that it is already sent. It is that Postgres does not restrict usernames to
>> be UTF-8 only, while SCRAM does. As such, if a username would not be UTF-8,
>> it will not be sent reliably over SCRAM.
> That's basically the point I was making. Note that I would not be
> against Postgres forcing strings to be in UTF-8. Now things are fuzzy
> because of the lack of restrictions.
I'm +10000 for that. But I guess that involves a protocol change,
and that's a completely different can of worms....
>
>>>> 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.
>> But we really don't need to send the username, since Postgres already
>> knows it (and that accommodates for non UTF-8 usernames). So why bother?
>> Just sending something like "*" (which is UTF-8 and produces the same value
>> under Saslprep) should be enough. I think the idea of ignoring the username
>> is pretty neat, but maybe a "standard" like "send me an asterisk here" could
>> be even better than leaving it empty.
> Personally I don't see much difference between both, so I'd rather
> leave things as they are now.
Strictly speaking the RFC assumes that the username is at least 1
character. I understand this was precisely Peter's original comment.
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data
On 8/11/17 07:18, Michael Paquier wrote: > 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. So we already handle passwords. Can't we handle user names the same way? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 8/11/17 09:06, Álvaro Hernández Tortosa wrote: > Strictly speaking the RFC assumes that the username is at least 1 > character. I understand this was precisely Peter's original comment. Well, my main point was that the documentation, the code, and the code comments all say slightly different things. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 8/11/17 09:27, Peter Eisentraut wrote: > On 8/11/17 09:06, Álvaro Hernández Tortosa wrote: >> Strictly speaking the RFC assumes that the username is at least 1 >> character. I understand this was precisely Peter's original comment. > > Well, my main point was that the documentation, the code, and the code > comments all say slightly different things. To conclude this thread for now, I have removed the offending sentence from the documentation. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers