On Sat, Sep 16, 2017 at 12:42 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Sep 14, 2017 at 12:58 PM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> Second thoughts, to make things simpler. All we need for channel
>> binding is a connection flag that says "I require channel binding". It
>> could be modeled after the sslmode parameter, e.g., cbind=disable (maybe
>> for debugging), cbind=prefer (default), cbind=require. If you specify
>> "require", then libpq would refuse to proceed unless scram-sha2-256-plus
>> (or future similar mechanisms) was offered for authentication.
>
> +1, although I think cbind is too brief. I'd spell it out.
I would like to point out that per the RFC, if the client attempts a
SSL connection with SCRAM and that the server supports channel
binding, then it has to publish the SASL mechanism for channel
binding, aka SCRAM-PLUS. If the client tries to force the use of SCRAM
even if SCRAM-PLUS is specified, this is seen as a downgrade attack by
the server which must reject the connection. So this parameter has
meaning only if you try to connect to a PG10 server using a PG11
client (assuming that channel binding gets into PG11). If you connect
with a PG11 client to a PG11 server with SSL, the server publishes
SCRAM-PLUS, the client has to use it, hence this turns out to make
cbind=disable and prefer meaningless in the long-term. If the client
does not use SSL, then there is no channel binding, and cbind=require
loses its value. So cbind's fate is actually linked to sslmode.
>> We don't even need a parameter that specifies which channel binding type
>> to use. If libpq implements tls-unique, it should always use that. We
>> might need a flag for testing other types, but that should not be an
>> in-the-user's-face option.
>
> I'm not so sure about this part. Why don't we want to let users control this?
That's at least useful for at least testing, tls-unique should be the
default, but we need as well end-point which we much likely would like
to be able to enforce from the client, and being able to enforce the
type of channel binding used does not betray the RFC.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers