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
signature.asc
Description: PGP signature