On Sat, Apr 8, 2017 at 9:28 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Apr 7, 2017 at 6:32 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Sat, Apr 8, 2017 at 1:59 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Fri, Apr 7, 2017 at 3:59 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>>> I think the "SCRAM" part is more important than "SHA-256", so -1 on that.
>>>
>>> I agree. The point here isn't that we're using a better hashing
>>> method, even if a lot of people *think* that's the point. The point
>>> is we're using a modern algorithm that has nice properties like "you
>>> can't impersonate the client by steeling the verifier, or even by
>>> snooping the exchange".
>>>
>>> But "sasl" might be even better.
>>
>> FWIW, my opinion has not changed much on the matter, I would still
>> favor "sasl" as the keyword used in pg_hba.conf. What has changed in
>> my mind though is that defining no mechanisms with an additional
>> option mean that all possible choices are sent to the client. But if
>> you define a list of mechanisms, then we'll just send back to the
>> client the specified list as a possible choice of exchange mechanism:
>> host all all blah.com sasl mechanism=scram-sha-256-plus
>> Here for example the user would not be allowed to use SCRAM-SHA-256,
>> just SCRAM with channel binding.
>>
>> Such an option makes sense once we add support for one more mechanism
>> in SASL, like channel binding, but that's by far a generic approach
>> that can serve us for years to come, and by admitting that nothing
>> listed means all possible options we don't need any immediate action.
>
> Yes, that all seems quite sensible. What exactly is the counter-argument?
I am unsure what that argument is either by reading the thread again.
Attached is a patch to hopefully make the discussion progress. I
simply propose to use sasl as a keyword for pg_hba.conf, on the basis
that SASL is the protocol used, and scram is a mechanism used to
achieve the SASL exchange. We can always come up with a set of options
and aliases later, I am actually open to have more fancy extra options
in pg_hba.conf.
Here is my original proposal:
sasl mechanism=scram-sha-256-plus,scram-sha-256
But we could have something like that as well:
sasl mechanism=scram-plus,scram
sasl mechanism=scram channel_binding=on/off
A problem with the last one is that it is not possible to control
channel binding per mechanism, but that could be discussed later on
once support for channel binding is added. For now I would just favor
the most extensive approach. No need to work later on with some
aliases in pg_hba.conf either.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
