Add "password_protocol" connection parameter to libpq

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Add "password_protocol" connection parameter to libpq

Jeff Davis-8
Libpq doesn't have a way to control which password protocols are used.
For example, the client might expect the server to be using SCRAM, but
it actually ends up using plain password authentication instead.

This patch adds:

  password_protocol = {plaintext|md5|scram-sha-256|scram-sha-256-plus}

as a connection parameter. Libpq will then reject any authentication
request from the server that is less secure than this setting. Setting
it to "plaintext" (default) will answer to any kind of authentication
request.

I'm not 100% happy with the name "password_protocol", but other names I
could think of seemed likely to cause confusion.

Regards,
        Jeff Davis


0001-Add-password_protocol-connection-parameter-to-libpq.patch (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Michael Paquier-2
On Thu, Aug 08, 2019 at 03:38:20PM -0700, Jeff Davis wrote:
> Libpq doesn't have a way to control which password protocols are used.
> For example, the client might expect the server to be using SCRAM, but
> it actually ends up using plain password authentication instead.

Thanks for working on this!

> I'm not 100% happy with the name "password_protocol", but other names I
> could think of seemed likely to cause confusion.

What about auth_protocol then?  It seems to me that it could be useful
to have the restriction on AUTH_REQ_MD5 as well.

> Sets the least-secure password protocol allowable when using password
> authentication. Options are: "plaintext", "md5", "scram-sha-256", or
> "scram-sha-256-plus".

This makes it sound like there is a linear hierarchy among all those
protocols, which is true in this case, but if the list of supported
protocols is extended in the future it may be not.

I think that this should have TAP tests in src/test/authentication/ so
as we make sure of the semantics.  For the channel-binding part, the
logic path for the test would be src/test/ssl.

+#define DefaultPasswordProtocol "plaintext"
I think that we are going to need another default value for that, like
"all" to reduce the confusion that SCRAM, MD5 and co are still
included in the authorized set in this case.

Another thing that was discussed on the topic would be to allow a list
of authorized protocols instead.  I personally don't think that we
need to go necessarily this way, but it could make the integration of
things line scram-sha-256,scram-sha-256-plus easier to integrate in
application flows.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Jeff Davis-8
On Fri, 2019-08-09 at 12:00 +0900, Michael Paquier wrote:
> What about auth_protocol then?  It seems to me that it could be
> useful
> to have the restriction on AUTH_REQ_MD5 as well.

auth_protocol does sound like a good name. I'm not sure what you mean
regarding MD5 though.

> This makes it sound like there is a linear hierarchy among all those
> protocols, which is true in this case, but if the list of supported
> protocols is extended in the future it may be not.

We already have that concept to a lesser extent, with the md5
authentication method also permitting scram-sha-256.

Also note that the server chooses what kind of authentication request
to send, which imposes a hierarchy of password < md5 < sasl. Within the
sasl authentication request the server can advertise multiple supported
mechanisms, though, so there doesn't need to be a hierarchy among sasl
mechanisms.

> I think that this should have TAP tests in src/test/authentication/
> so
> as we make sure of the semantics.  For the channel-binding part, the
> logic path for the test would be src/test/ssl.

Will do.

> Another thing that was discussed on the topic would be to allow a
> list
> of authorized protocols instead.  I personally don't think that we
> need to go necessarily this way, but it could make the integration of
> things line scram-sha-256,scram-sha-256-plus easier to integrate in
> application flows.

That sounds good, but there are a lot of possibilities and I can't
quite decide which way to go.

We could expose it as an SASL option like:

   saslmode = {disable|prefer|require-scram-sha-256|require-scram-sha-
256-plus}

But that doesn't allow for multiple acceptable mechanisms, which could
make migration a pain. We try to use a comma-list like:

   saslmode = {disable|prefer|require}
   saslmech = all | {scram-hash-256|scram-hash-256-plus}[,...]

Or we could over-engineer it to do something like:

   saslmode = {disable|prefer|require}
   saslmech = all | {scram|future_mech}[,...]
   scramhash = all | {sha-256|future_hash}[,...]
   scram_channel_binding = {disable|prefer|require}

(Aside: is the channel binding only a SCRAM concept, or also a SASL
concept?)

Also, working with libpq I found myself wondering why everything is
based on strings instead of enums or some other structure. Do you know
why it's done that way?

Regards,
        Jeff Davis




Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Michael Paquier-2
On Thu, Aug 08, 2019 at 11:16:24PM -0700, Jeff Davis wrote:
> On Fri, 2019-08-09 at 12:00 +0900, Michael Paquier wrote:
> > What about auth_protocol then?  It seems to me that it could be
> > useful
> > to have the restriction on AUTH_REQ_MD5 as well.
>
> auth_protocol does sound like a good name. I'm not sure what you mean
> regarding MD5 though.

Sorry, I meant krb5 here.

> We already have that concept to a lesser extent, with the md5
> authentication method also permitting scram-sha-256.

That's present to ease upgrades, and once the AUTH_REQ part is
received the client knows what it needs to go through.

> That sounds good, but there are a lot of possibilities and I can't
> quite decide which way to go.
>
> We could expose it as an SASL option like:
>
>    saslmode = {disable|prefer|require-scram-sha-256|require-scram-sha-
> 256-plus}

Or we could shape password_protocol so as it takes a list of
protocols, as a white list of authorized things in short.
--
Michael

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Stephen Frost
Greetings,

* Michael Paquier ([hidden email]) wrote:
> On Thu, Aug 08, 2019 at 11:16:24PM -0700, Jeff Davis wrote:
> > On Fri, 2019-08-09 at 12:00 +0900, Michael Paquier wrote:
> > > What about auth_protocol then?  It seems to me that it could be
> > > useful
> > > to have the restriction on AUTH_REQ_MD5 as well.
> >
> > auth_protocol does sound like a good name. I'm not sure what you mean
> > regarding MD5 though.

I don't really care for auth_protocol as that's pretty close to
"auth_method" and that isn't what we're talking about here- this isn't
the user picking the auth method, per se, but rather saying which of the
password-based mechanisms for communicating that the user knows the
password is acceptable.  Letting users choose which auth methods are
allowed might also be interesting (as in- we are in a Kerberized
environment and therefore no client should ever be using any auth method
except GSS, could be a reasonable ask) but it's not the same thing.

> Sorry, I meant krb5 here.

What restriction are you suggesting here wrt krb5..?

> > We already have that concept to a lesser extent, with the md5
> > authentication method also permitting scram-sha-256.
>
> That's present to ease upgrades, and once the AUTH_REQ part is
> received the client knows what it needs to go through.

I don't think there's any question that, of the methods available to
prove that you know what the password is, simply sending the password to
the server as cleartext is the least secure.  If I, as a user, decide
that I don't really care what method is used, it's certainly simpler to
just say 'plaintext' than to have to list out every possible option.

Having an 'any' option, as mentioned before, could be an alternative
though.

I agree with the point that there isn't any guarantee that it'll always
be clear-cut as to which of two methods is "better".

From a user perspective, it seems like the main things are "don't send
my password in the clear to the server", and "require channel binding to
prove there isn't a MITM".  I have to admit that I like the idea of
requiring scram to be used and not allowing md5 though.

> > That sounds good, but there are a lot of possibilities and I can't
> > quite decide which way to go.
> >
> > We could expose it as an SASL option like:
> >
> >    saslmode = {disable|prefer|require-scram-sha-256|require-scram-sha-
> > 256-plus}
>
> Or we could shape password_protocol so as it takes a list of
> protocols, as a white list of authorized things in short.
I'm not really a fan of "saslmode" or anything else involving SASL
for this because we don't *really* do SASL- if we did, we'd have that as
an auth method and we'd have our Kerberos support be through SASL along
with potentially everything else...  I'm not against going there but I
don't think that's what you were suggesting here.

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Jeff Davis-8
On Fri, 2019-08-09 at 09:28 -0400, Stephen Frost wrote:
> Having an 'any' option, as mentioned before, could be an alternative
> though.

...

> I agree with the point that there isn't any guarantee that it'll
> always
> be clear-cut as to which of two methods is "better".
>
> From a user perspective, it seems like the main things are "don't
> send
> my password in the clear to the server", and "require channel binding
> to
> prove there isn't a MITM".  I have to admit that I like the idea of
> requiring scram to be used and not allowing md5 though.

So it seems like we are leaning toward:

   password_protocol = any | {plaintext,md5,scram-sha-256,scram-sha-
256-plus}[,...]

Or maybe:

   channel_binding = {disable|prefer|require}
   password_plaintext = {disable|enable}
   password_md5 = {disable|enable}

That seems reasonable. It's three options, but no normal use case would
need to set more than two, because channel binding forces scram-sha-
256-plus.

Regards,
        Jeff Davis




Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Jonathan S. Katz-3
On 8/9/19 11:51 AM, Jeff Davis wrote:

> On Fri, 2019-08-09 at 09:28 -0400, Stephen Frost wrote:
>> Having an 'any' option, as mentioned before, could be an alternative
>> though.
>
> ...
>
>> I agree with the point that there isn't any guarantee that it'll
>> always
>> be clear-cut as to which of two methods is "better".
>>
>> From a user perspective, it seems like the main things are "don't
>> send
>> my password in the clear to the server", and "require channel binding
>> to
>> prove there isn't a MITM".  I have to admit that I like the idea of
>> requiring scram to be used and not allowing md5 though.
>
> So it seems like we are leaning toward:
>
>    password_protocol = any | {plaintext,md5,scram-sha-256,scram-sha-
> 256-plus}[,...]
First, thanks for proposing / working on this, I like the idea! :) Happy
to test/review.

As long as this one can handle the current upgrade path that's in place
for going from md5 to SCRAM (which AIUI it should) this makes sense to
me. As stated above, there is a clear hierarchy.

I would almost argue that "plaintext" shouldn't even be an option...if
you have "any" set (arguably default?) then plaintext is available. With
our currently supported versions + driver ecosystem, I hope no one needs
to support a forced plaintext setup.

>
> Or maybe:
>
>    channel_binding = {disable|prefer|require}
>    password_plaintext = {disable|enable}
>    password_md5 = {disable|enable}
>
> That seems reasonable. It's three options, but no normal use case would
> need to set more than two, because channel binding forces scram-sha-
> 256-plus.
Seems to be a lot to configure. I'm more of a fan of the previous
method; it'd work nicely with how we've presently defined things and
should be easy to put into a DSN/URI/env variable.

Thanks,

Jonathan


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Heikki Linnakangas
On 09/08/2019 23:27, Jonathan S. Katz wrote:

> On 8/9/19 11:51 AM, Jeff Davis wrote:
>> On Fri, 2019-08-09 at 09:28 -0400, Stephen Frost wrote:
>>> Having an 'any' option, as mentioned before, could be an alternative
>>> though.
>>
>> ...
>>
>>> I agree with the point that there isn't any guarantee that it'll
>>> always
>>> be clear-cut as to which of two methods is "better".
>>>
>>>  From a user perspective, it seems like the main things are "don't
>>> send
>>> my password in the clear to the server", and "require channel binding
>>> to
>>> prove there isn't a MITM".  I have to admit that I like the idea of
>>> requiring scram to be used and not allowing md5 though.
>>
>> So it seems like we are leaning toward:
>>
>>     password_protocol = any | {plaintext,md5,scram-sha-256,scram-sha-
>> 256-plus}[,...]
>
> First, thanks for proposing / working on this, I like the idea! :) Happy
> to test/review.
>
> As long as this one can handle the current upgrade path that's in place
> for going from md5 to SCRAM (which AIUI it should) this makes sense to
> me. As stated above, there is a clear hierarchy.
>
> I would almost argue that "plaintext" shouldn't even be an option...if
> you have "any" set (arguably default?) then plaintext is available. With
> our currently supported versions + driver ecosystem, I hope no one needs
> to support a forced plaintext setup.

Keep in mind that RADIUS, LDAP and PAM authentication methods are
'plaintext' over the wire. It's not that bad, when used with
sslmode=verify-ca/full.

>> Or maybe:
>>
>>     channel_binding = {disable|prefer|require}
>>     password_plaintext = {disable|enable}
>>     password_md5 = {disable|enable}
>>
>> That seems reasonable. It's three options, but no normal use case would
>> need to set more than two, because channel binding forces scram-sha-
>> 256-plus.
>
> Seems to be a lot to configure. I'm more of a fan of the previous
> method; it'd work nicely with how we've presently defined things and
> should be easy to put into a DSN/URI/env variable.

This is a multi-dimensional problem. "channel_binding=require" is one
way to prevent MITM attacks, but sslmode=verify-ca is another. (Does
Kerberos also prevent MITM?) Or you might want to enable plaintext
passwords over SSL, but not without SSL.

I think we'll need something like the 'ssl_ciphers' GUC, where you can
choose from a few reasonable default rules, but also enable/disable
specific methods:

# anything goes (the default)
auth_methods = 'ANY'

# Disable plaintext password authentication. Anything else is accepted.
auth_methods = '-password'

# Only authentication methods that protect from
# Man-in-the-Middle attacks. This allows anything if the server's SSL
# certificate can be verified, and otherwise only SCRAM with
# channel binding
auth_methods = 'MITM'

# The same, but disable plaintext passwords and md5 altogether
auth_methods = 'MITM, -password, -md5'


I'm tempted to also allow 'SSL' and 'SSL-verify-full' as part of the
same string, so that you could configure everything related to
connection security in the same option. Not sure if that would make
things simpler for users, or create more confusion.

- Heikki


Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Jeff Davis-8
In reply to this post by Jonathan S. Katz-3
On Fri, 2019-08-09 at 16:27 -0400, Jonathan S. Katz wrote:
> Seems to be a lot to configure. I'm more of a fan of the previous
> method; it'd work nicely with how we've presently defined things and
> should be easy to put into a DSN/URI/env variable.

Proposals on the table:

1. Hierarchical semantics, where you specify the least-secure
acceptable method:

  password_protocol = {any,md5,scram-sha-256,scram-sha-256-plus}

2. Comma-list approach, where you specify exactly which protocols are
acceptable, or "any" to mean that we don't care.

3. three-setting approach:

  channel_binding = {disable|prefer|require}
  password_plaintext = {disable|enable}
  password_md5 = {disable|enable}

It looks like Jonathan prefers #1.

#1 seems direct and clearly applies today, and corresponds to auth
methods on the server side.

I'm not a fan of #2, it seems likely to result in a bunch of clients
with overly-specific lists of things with long names that can never
really go away.

#3 is a little more abstract, but also seems more future-proof, and may
tie in to what Stephen is talking about with respect to controlling
auth methods from the client, or moving more protocols within SASL.

Regards,
        Jeff Davis




Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Jeff Davis-8
In reply to this post by Heikki Linnakangas
On Sat, 2019-08-10 at 00:17 +0300, Heikki Linnakangas wrote:

> This is a multi-dimensional problem. "channel_binding=require" is
> one
> way to prevent MITM attacks, but sslmode=verify-ca is another. (Does
> Kerberos also prevent MITM?) Or you might want to enable plaintext
> passwords over SSL, but not without SSL.
>
> I think we'll need something like the 'ssl_ciphers' GUC, where you
> can
> choose from a few reasonable default rules, but also enable/disable
> specific methods:

..

> auth_methods = 'MITM, -password, -md5'

Keep in mind this is client configuration, so something reasonable in
postgresql.conf might not be so reasonable in the form:

postgresql://foo:secret@myhost/mydb?auth_methods=MITM%2C%20-
password%2C%20-md5

Another thing to consider is that there's less control configuring on
the client than on the server. The server will send at most one
authentication request based on its own rules, and all the client can
do is either answer it, or disconnect. And the SSL stuff all happens
before that, and won't use an authentication request message at all.

Some protocols allow negotiation within them, like SASL, which gives
the client a bit more freedom. But FE/BE doesn't allow for arbitrary
subsets of authentication methods to be negoitated between client and
server, so I'm worried trying to express it that way will just lead to
clients that break when you upgrade your server.

Regards,
        Jeff Davis




Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Stephen Frost
Greetings,

* Jeff Davis ([hidden email]) wrote:
> On Sat, 2019-08-10 at 00:17 +0300, Heikki Linnakangas wrote:
> > auth_methods = 'MITM, -password, -md5'
>
> Keep in mind this is client configuration, so something reasonable in
> postgresql.conf might not be so reasonable in the form:

Yeah, that's a really good point.

> postgresql://foo:secret@myhost/mydb?auth_methods=MITM%2C%20-
> password%2C%20-md5
>
> Another thing to consider is that there's less control configuring on
> the client than on the server. The server will send at most one
> authentication request based on its own rules, and all the client can
> do is either answer it, or disconnect. And the SSL stuff all happens
> before that, and won't use an authentication request message at all.

Note that GSSAPI Encryption works the same as SSL in this regard.

Thanks,

Stephen

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Craig Ringer-3
In reply to this post by Michael Paquier-2
On Fri, 9 Aug 2019 at 11:00, Michael Paquier <[hidden email]> wrote:
On Thu, Aug 08, 2019 at 03:38:20PM -0700, Jeff Davis wrote:
> Libpq doesn't have a way to control which password protocols are used.
> For example, the client might expect the server to be using SCRAM, but
> it actually ends up using plain password authentication instead.

Thanks for working on this!

> I'm not 100% happy with the name "password_protocol", but other names I
> could think of seemed likely to cause confusion.

What about auth_protocol then?  It seems to me that it could be useful
to have the restriction on AUTH_REQ_MD5 as well.

> Sets the least-secure password protocol allowable when using password
> authentication. Options are: "plaintext", "md5", "scram-sha-256", or
> "scram-sha-256-plus".

This makes it sound like there is a linear hierarchy among all those
protocols, which is true in this case, but if the list of supported
protocols is extended in the future it may be not.

Before we go too far along with this, lets look at how other established protocols do things and the flaws that've been discovered in their approaches. If this isn't done with extreme care then there's a large risk of negating the benefits offered by adopting recent things like SCRAM. Frankly I kind of wish we could just use SASL, but there are many (many) reasons no to. 

Off the top of my head I can think of these risks:

* Protocols that allow naïve pre-auth client/server auth negotiation (e.g. by finding the overlap in exchanged supported auth-mode lists) are subject to MiTM downgrade attacks where the attacker filters out protocols it cannot intercept and break from the proposed alternatives.

* Protocols that specify a hierarchy tend to be inflexible and result in hard to predict auth mode selections as the options grow. If my app wants GSSAPI or SuperStrongAuth but doesn't accept SSPI, and the hierarchy is  GSSAPI > SSPI > SuperStrongAuth, it has to fall back to a disconnect and retry model like now.

* Protocols that announce supported auth methods before any kind of trust is established make life easier for vulnerability scanners and worms

and I'm sure there are more when it comes to auth handshakes.


--
 Craig Ringer                   http://www.2ndQuadrant.com/
 2ndQuadrant - PostgreSQL Solutions for the Enterprise
Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Jeff Davis-8
On Sat, 2019-08-10 at 10:24 +0800, Craig Ringer wrote:
> Before we go too far along with this, lets look at how other
> established protocols do things and the flaws that've been discovered
> in their approaches. If this isn't done with extreme care then
> there's a large risk of negating the benefits offered by adopting
> recent things like SCRAM.

Agreed. I'm happy to hear any proposals better informed by history.

> Frankly I kind of wish we could just use SASL, but there are many
> (many) reasons no to.

I'm curious what the reasons are not to use SASL; do you have a
reference?

> Off the top of my head I can think of these risks:
>
> * Protocols that allow naïve pre-auth client/server auth negotiation
> (e.g. by finding the overlap in exchanged supported auth-mode lists)
> are subject to MiTM downgrade attacks where the attacker filters out
> protocols it cannot intercept and break from the proposed
> alternatives.

We already have the downgrade problem. That's what I'm trying to solve.

> * Protocols that specify a hierarchy tend to be inflexible and result
> in hard to predict auth mode selections as the options grow. If my
> app wants GSSAPI or SuperStrongAuth but doesn't accept SSPI, and the
> hierarchy is  GSSAPI > SSPI > SuperStrongAuth, it has to fall back to
> a disconnect and retry model like now.

What do you mean "disconnect and retry model"?

I agree that hierarchies are unweildly as the options grow. Then again,
as options grow, we need new versions of the client to support them,
and those new versions might offer more flexible ways to choose between
them.

Of course, we should try to think ahead to avoid needing to constantly
change client connection syntax, but I'm just pointing out that it's
not a one-way door.

> * Protocols that announce supported auth methods before any kind of
> trust is established make life easier for vulnerability scanners and
> worms

This discussion is about the client so I don't see how vulnerability
scanners are relevant.

Regards,
        Jeff Davis





Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Jonathan S. Katz-3
In reply to this post by Jeff Davis-8
On 8/9/19 7:54 PM, Jeff Davis wrote:

> On Sat, 2019-08-10 at 00:17 +0300, Heikki Linnakangas wrote:
>> This is a multi-dimensional problem. "channel_binding=require" is
>> one
>> way to prevent MITM attacks, but sslmode=verify-ca is another. (Does
>> Kerberos also prevent MITM?) Or you might want to enable plaintext
>> passwords over SSL, but not without SSL.
>>
>> I think we'll need something like the 'ssl_ciphers' GUC, where you
>> can
>> choose from a few reasonable default rules, but also enable/disable
>> specific methods:
>
> ..
>
>> auth_methods = 'MITM, -password, -md5'
>
> Keep in mind this is client configuration, so something reasonable in
> postgresql.conf might not be so reasonable in the form:
>
> postgresql://foo:secret@myhost/mydb?auth_methods=MITM%2C%20-
> password%2C%20-md5
Yeah, and I do agree it is a multi-dimensional problem, but the context
in which I gave my opinion was for the password authentication methods
that PostgreSQL supports natively, i.e. not requiring a 3rd party to
arbitrate via GSSAPI, LDAP etc.

That said, I dove into the code a bit more to look at the behavior
specifically with LDAP, which as described does send back a request for
"AuthenticationCleartextPassword"

If we go with the client sending up a "password_protocol" that is not
plaintext, and the server only provides LDAP authentication, does the
client close the connection? I would say yes.

(And as such, I would also consider adding "plaintext" back to the list,
just to have the explicit option).

The other question I have is that do we have it occur in the
hierarchical manner, i.e. "md5 or better?" I would also say yes to that,
we would just need to clearly document that. Perhaps we adopt a similar
name to "sslmode" e.g. "password_protocol_mode" but that can be debated :)

> Another thing to consider is that there's less control configuring on
> the client than on the server. The server will send at most one
> authentication request based on its own rules, and all the client can
> do is either answer it, or disconnect. And the SSL stuff all happens
> before that, and won't use an authentication request message at all.

Yes. Using the LDAP example above, the client also needs some general
awareness of how it can connect to the server, e.g. "You may want
scram-sha-256 but authentication occurs over LDAP, so don't stop
requesting scram-sha-256!" That said, part of that is a human problem:
it's up to the server administrator to inform clients how they can
connect to PostgreSQL.

> Some protocols allow negotiation within them, like SASL, which gives
> the client a bit more freedom. But FE/BE doesn't allow for arbitrary
> subsets of authentication methods to be negoitated between client and
> server, so I'm worried trying to express it that way will just lead to
> clients that break when you upgrade your server.

Agreed. I see this as a way of a client saying "Hey, I really want to
authenticate with scram-sha-256 or better, so if you don't let me do
that, I'm out." In addition to ensuring it uses the client's desired
password protocol, this could be helpful for testing that the
appropriate authentication rules are set in a server, e.g. one that is
rolling out SCRAM authentication.

And as Heikki mentions, there are other protections a client can use,
e.g. verify-ca/full, to guard against eavesdropping, MITM etc.

Jonathan


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Peter Eisentraut-6
In reply to this post by Jeff Davis-8
On 2019-08-09 23:56, Jeff Davis wrote:
> 1. Hierarchical semantics, where you specify the least-secure
> acceptable method:
>
>   password_protocol = {any,md5,scram-sha-256,scram-sha-256-plus}

What would the hierarchy be if scram-sha-512 and scram-sha-512-plus are
added?

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Jonathan S. Katz-3
On 8/11/19 1:00 PM, Peter Eisentraut wrote:
> On 2019-08-09 23:56, Jeff Davis wrote:
>> 1. Hierarchical semantics, where you specify the least-secure
>> acceptable method:
>>
>>   password_protocol = {any,md5,scram-sha-256,scram-sha-256-plus}
>
> What would the hierarchy be if scram-sha-512 and scram-sha-512-plus are
> added?

password_protocol =
{any,md5,scram-sha-256,scram-sha-512,scram-sha-256-plus,scram-sha-512-plus}?

I'd put one length of digest over another, but I'd still rank a method
that uses channel binding has more protections than one that does not.

Jonathan


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Peter Eisentraut-6
On 2019-08-11 21:46, Jonathan S. Katz wrote:

> On 8/11/19 1:00 PM, Peter Eisentraut wrote:
>> On 2019-08-09 23:56, Jeff Davis wrote:
>>> 1. Hierarchical semantics, where you specify the least-secure
>>> acceptable method:
>>>
>>>   password_protocol = {any,md5,scram-sha-256,scram-sha-256-plus}
>>
>> What would the hierarchy be if scram-sha-512 and scram-sha-512-plus are
>> added?
>
> password_protocol =
> {any,md5,scram-sha-256,scram-sha-512,scram-sha-256-plus,scram-sha-512-plus}?
>
> I'd put one length of digest over another, but I'd still rank a method
> that uses channel binding has more protections than one that does not.

Sure, but the opposite opinion is also possible.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Jonathan S. Katz-3
On 8/11/19 3:56 PM, Peter Eisentraut wrote:

> On 2019-08-11 21:46, Jonathan S. Katz wrote:
>> On 8/11/19 1:00 PM, Peter Eisentraut wrote:
>>> On 2019-08-09 23:56, Jeff Davis wrote:
>>>> 1. Hierarchical semantics, where you specify the least-secure
>>>> acceptable method:
>>>>
>>>>   password_protocol = {any,md5,scram-sha-256,scram-sha-256-plus}
>>>
>>> What would the hierarchy be if scram-sha-512 and scram-sha-512-plus are
>>> added?
>>
>> password_protocol =
>> {any,md5,scram-sha-256,scram-sha-512,scram-sha-256-plus,scram-sha-512-plus}?
>>
>> I'd put one length of digest over another, but I'd still rank a method
>> that uses channel binding has more protections than one that does not.
>
> Sure, but the opposite opinion is also possible.
That's true, and when originally started composing my note I had it as
(256,512,256-plus,512-plus).

But upon further reflection, the reason I ranked the digest-plus methods
above the digest methods is that there is any additional requirement
imposed by them. The digest methods could be invoked either with/without
TLS, whereas the digest-plus methods *must* use TLS. As such, 256-plus
is explicitly asking for an additional security parameter over 512, i.e.
transmission over TLS, so even if it's a smaller digest, it has the
additional channel binding requirement.

Jonathan


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Jeff Davis-8
In reply to this post by Peter Eisentraut-6
On Sun, 2019-08-11 at 19:00 +0200, Peter Eisentraut wrote:
> On 2019-08-09 23:56, Jeff Davis wrote:
> > 1. Hierarchical semantics, where you specify the least-secure
> > acceptable method:
> >
> >   password_protocol = {any,md5,scram-sha-256,scram-sha-256-plus}
>
> What would the hierarchy be if scram-sha-512 and scram-sha-512-plus
> are
> added?


https://postgr.es/m/daf0017a1a5c2caabf88a4e00f66b4fcbdfeccad.camel%40j-davis.com

The weakness of proposal #1 is that it's not very "future-proof" and we
would likely need to change something about it later when we support
new methods. That wouldn't break clients, but it would be annoying to
need to support some old syntax and some new syntax for the connection
parameters.

Proposal #3 does not have this weakness. When we add sha-512, we could
also add a parameter to specify that the client requires a certain hash
algorithm for SCRAM.

Do you favor that existing proposal #3, or are you proposing a fourth
option?

Regards,
        Jeff Davis




Reply | Threaded
Open this post in threaded view
|

Re: Add "password_protocol" connection parameter to libpq

Peter Eisentraut-6
On 2019-08-12 18:02, Jeff Davis wrote:

> https://postgr.es/m/daf0017a1a5c2caabf88a4e00f66b4fcbdfeccad.camel%40j-davis.com
>
> The weakness of proposal #1 is that it's not very "future-proof" and we
> would likely need to change something about it later when we support
> new methods. That wouldn't break clients, but it would be annoying to
> need to support some old syntax and some new syntax for the connection
> parameters.
>
> Proposal #3 does not have this weakness. When we add sha-512, we could
> also add a parameter to specify that the client requires a certain hash
> algorithm for SCRAM.
>
> Do you favor that existing proposal #3, or are you proposing a fourth
> option?

In this context, I would prefer #2, but I would expand that to cover all
authentication methods, not only password methods.

--
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


123