On Tue, Sep 12, 2017 at 11:38 PM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > It seems we should start by sorting out the mechanism by which the > client can control what authentication mechanisms it accepts. In your > patch set you introduce a connection parameter saslname. I think we > should expand that to non-SASL mechanisms and have it be some kind of > whitelist or blacklist. It might be reasonable for a client to require > "gssapi" or "cert" for example or do an exclusion like "!password !md5 > !ldap". > > Thoughts?
That looks like a sensible approach to begin with at the end: there have been complains that a client can be tricked into using MD5 by a rogue server even if it was willing to use SCRAM. So what about a parameter called pgauthfilter, which uses a comma-separated list of keywords. As you say, using an exclamation point to negate an authentication method is fine for me. For SCRAM, we could just use "scram-sha-256" as keyword. Once channel binding is involved though.. This needs to be extended and this needs careful thoughts: * "scram-sha-256" means that the version without channel binding is accepted. "!scram-sha-256" means that scram without channel binding is refused. * "scram-sha-256-plus" means that all channel bindings are accepted. "!scram-sha-256-plus" means that no channel binding are accepted. After that there is some filtering per channel binding name. Do we want a separate parameter or just filter with longer names like "scram-sha-256-plus-tls-unique" and "scram-sha-256-plus-tls-server-end-point"? The last one gets particularly long, this does not help users with typos :) -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
