On Tue, Sep 12, 2017 at 11:38 PM, Peter Eisentraut
<peter.eisentraut@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