On 06/04/17 22:05, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
>> How would we provide the list of protocols? Surely the protocol is
>> defined by pg_hba.conf, which makes it dependent upon username,
>> database and ip range. If the list were accurate, it would allow an
>> attacker to discover how best to attack. If the list were inaccurate
>> it would just be an annoyance.
>> At minimum, providing the list of protocols means an extra round trip
>> to the server.
> Yeah, that's a problem.
I don't see it. The message AuthenticationSASL.String could contain
a CSV of the SCRAM protocols supported. This is specially important to
support channel binding (which is just another protocol name for this
matter), which is the really enhanced security mechanism of SCRAM. Since
this message is sent regardless, and the client replies with
PasswordMessage, no extra round trip is required. However,
PasswordMessage needs to also include a field with the name of the
selected protocol (it is the client who picks). Or a different message
would need to be created, but no extra round-trips more than those
required by SCRAM itself (4 messages for SCRAM + 1 extra for the server
to tell the client it needs to use SCRAM).
>
>> ISTM that if you have a valid role to connect to then you'll also know
>> what authentication mechanism to use so you should be able to specify
>> the mechanism in your connection message and save the extra trip.
> I do not buy that in the least. It has never been the case before now
> that clients know in advance what the auth challenge method will be.
> If we put that requirement on them for SCRAM, we're just going to be
> exporting a lot of pain and end-user-visible inconsistency.
>
> Perhaps we could turn this around: have the client send (in the connection
> request packet) a list of auth protocols it thinks it is able to handle.
Per the SCRAM RFC, it is the server who advertises and the client
who picks.
Regards,
Álvaro
--
Álvaro Hernández Tortosa
-----------
<8K>data