On Tue, Aug 13, 2019 at 04:51:57PM -0400, Jonathan S. Katz wrote:
> On 8/13/19 12:25 PM, Jeff Davis wrote:
>> On Tue, 2019-08-13 at 11:56 +0900, Michael Paquier wrote:
>>> I tend to prefer #2 as well and that's the kind of approach we were
>>> tending to agree on when we discussed this issue during the v11 beta
>>> for the downgrade issues with libpq. And as you say extend it so as
>>> we can apply filtering of more AUTH_REQ requests, inclusing GSS and
>>> krb5.
>>
>> Can you please offer a concrete proposal? I know the proposals I've put
>> out aren't perfect (otherwise there wouldn't be three of them), so if
>> you have something better, please share.
>
> I think all of them get at the same thing, i.e. specifying which
> password protocol you want to use, and a lot of it is a matter of how
> much onus we want to put on the user.
What I got in mind was a comma-separated list of authorized protocols
which can be specified as a connection parameter, which extends to all
the types of AUTH_REQ requests that libpq can understand, plus an
extra for channel binding. I also liked the idea mentioned upthread
of "any" to be an alias to authorize everything, which should be the
default. So you basically get at that:
auth_protocol = {any,password,md5,scram-sha-256,scram-sha-256-plus,krb5,gss,sspi}
So from an implementation point of view, just using bit flags would
make things rather clean.
> Back to the thee proposals[1], I've warmed up to #3 a bit. I do think it
> puts more onus on the client to set the correct knobs to get the desired
> outcome, but what I like is the specific `channel_binding=require`
> attribute.
I could see a point in separating the channel binding part into a
second parameter though. We don't have (at least yet) an hba option
to allow only channel binding with scram, so a one-one mapping with
the elements of the connection parameter brings some consistency.
> If the client selects "channel_binding=require" but does not include a
> protocol that supports it, we should error.
Yep.
> Likewise, if the client does
> something like "channel_binding=require" and
> "password_protocol=scram-sha-256,scram-sha-256-plus" but the server
> refuses to do channel binding, we should error.
If using a second parameter to control channel binding requirement, I
don't think that there is any point in keeping scram-sha-256-plus in
password_protocol.
> I would not be opposed to extending "password_protocol" to read
> "auth_protocol" or the like and work for everything covered in AUTH_REQ,
> but I would need to think about it some more.
And for this one I would like to push for not only having
password-based methods considered.
--
Michael