Subject: Re: Add "password_protocol" connection parameter to libpq
To: Stephen Frost <sfrost@snowman.net>, Jeff Davis <pgsql@j-davis.com>
Cc: Michael Paquier <michael@paquier.xyz>,
 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
 pgsql-hackers@postgresql.org
References: <071e45a6-97f7-1614-371c-98ecb03aed65@postgresql.org>
 <daf0017a1a5c2caabf88a4e00f66b4fcbdfeccad.camel@j-davis.com>
 <7a7a2f07-d013-eb80-85ba-9edaaf845038@2ndquadrant.com>
 <95b40ddcb3897772f075e6891521ee3f06f443d1.camel@j-davis.com>
 <93653d2b-7cf7-6992-7d3e-600ffd461354@2ndquadrant.com>
 <20190813025634.GF2551@paquier.xyz>
 <67726b008fa31d00d9a38257b3d1673b8afff2dd.camel@j-davis.com>
 <1e34ce7a-9d4c-dd99-3781-e0a3203f5aef@postgresql.org>
 <20190814023857.GB14446@paquier.xyz>
 <54269124d50791eacb71f1fead40422185ae8ddc.camel@j-davis.com>
 <20190816012815.GW16436@tamriel.snowman.net>
From: "Jonathan S. Katz" <jkatz@postgresql.org>
Openpgp: preference=signencrypt
Autocrypt: addr=jkatz@postgresql.org; keydata=
 mQINBFtShwABEAC7PNHDUOTYuifpUCk23KqfxdQQkn4nkoxOXRK0+rAj36FiwqGB4TJFuOVZ
 sDFAEiSlC8Jt4y5Cs7B5tetT8JNd2cs6zp/udMJJDz9d65O9PDpdlMgAmIiTzpLlSdx8FG56
 DTksaDv1d8j3cTJPSE4/fWSxqzA7o3Y9UuL7atZPrzfImgpRKs0of7elIHwOa8GucjyhYqcR
 h60wFBJc2KXqQdDYRTZy43DSnY/0VNc0omiH355fustvpm+m5HjD3w7qZyfN3fpKJpnX1LCF
 f3MnPHaDGITIYGRCBXvf0UqUtD6OEVWPv2C2gyqWMIpWmZTOgDufltKyIByKBoS9x0PlFkij
 04X3KODCngt+N8Ssc9OICc6QSxhjoP48PYPdmiTmkrGuf0LX084wj1xeo1NX7XxZK39F6dTJ
 DhsIiW0sNS0xMxQHLHG9VLbPjx3SANQBh6BuryPz5ZupW9/TIDmkvprtU/oXfKgtfYm3fxmk
 EctxbWrEPsFTFPyuMqQu6l+xyQv0s1VLZfjNWaua6H1/gGoIt6kRnn5qMXDVVpijuWkHbv7G
 ngaQMd258UrrOEHnnjzhQ7jxMWV9D+emxbAtlIxnYvCWlV4IwAQhEHfvudqYaIY3hNWrvQ6H
 GB2KXoTZYN9g5djm14/5nj1IU5zOcovkjJnKhoo9iStnpFF2cwARAQABtCdKb25hdGhhbiBT
 LiBLYXR6IDxqa2F0ekBwb3N0Z3Jlc3FsLm9yZz6JAlQEEwEIAD4CGwMFCQeGH4AFCwkIBwIG
 FQoJCAsCBBYCAwECHgECF4AWIQT6hLaVryv3miBkP/HxBJxynxxlJwUCW1KJJQAKCRDxBJxy
 nxxlJwjrD/kBgqsW4QpNpTFw7ifRokZV08CCX4huPBJQ91rrv+UEWlEcotFBHVkYyHnpzARl
 tcZxhJ9CbFxjniH9cOTty5T/O1yolbOHtZSW8Z8aWV6BVEbjMb+BFxSSLm7RnvJdzQbGCZq2
 ZZvfVpB6z3EHYph4KDdVKvMFjoLskxmdS1DE0tE3zTxvoQsi24Q+HOS07kUjs6fsu/WICMfz
 mgO++AWG9Y0CvN0mm4TkujESzyKM9E5irD+leEMIcddl51Aa2c/VMfBXQbRmpHIgUFTmuHQD
 CnQih+9i3OJAksDg66SP8a7yiXv5mwvyDi1EfTGVKYR2j+pwyjwnC3oIbvDMmB3uTn2JIjnT
 iZKPVtAcAylXjubFltihQgNyuShdP4W+kBwZizhUFqUVL8Anx+KoytYmJPfMRFLGuK4obXKq
 a2ZS3k9KB+H+isOx2nFJOsc7V360Zp1DVaNmuiK10TT6QndShSPaqkJqFtCb6r92rZ9sZM/L
 3vtCI4Rrl3Pt1MgtENXupS8gZpJnAYS0j5A1PAZ09r6ANoaeMHspF+5J5fOHeEvqphXr36mm
 a83Vl1t4orPb0+QmmijmlpseDU63M88Aw5p3c4qj7t8Qr2EZ5zrn7/sFn5wOfbs8Nymxafif
 QCnlV2vg9p0m7vSk/yLJ4PFZvs52FgqAGRCdRn0s2EC99bkCDQRbUocAARAAv8ho/toQ9DG3
 j4f9h9n1aRHr2FlviN2Utpy6L8+dfDggO0geilmkGQOolZ2E60gGfye/kUtF9W3NByO4hxDR
 9u6qbOXcdqnuA+cc68EfqlWFJrVtYFxt0h4ElWYOYnIezKthriWch/FY70FGrxs3z8UHOHq5
 0wBW433eTvZm90WixBiXEt2v1DgW4Vr3ymfO7Aap/IYyPuE4JzgudAuAl0HKPyNEHWHG1dAb
 jX1RiCw9gknIDWQOF0B4UAaJctWGVcnZ3A2ULwNGMa1P9ZJlBWf1vcj01aiHMU0yQ7JjJiSp
 vfm9eM0uSLwRdDrJjyl5ZZqVumjdv2SMNQ8GvYRbEMys3GGDSt9zXgfCSUnPnJfYxjzBHRI6
 x44Wfsx8S6hWxepOogCJJ/g67Bk9mY8YV4klWIXDJVOL5jnBC09DbsZG81JaE2QxB8Y7W36Z
 Mroi9XMxg3s805hQAQUvdG/poU8hN8BWdrnTm/+4eQQp7gDY1ePDmGM6bJC+OHOSnFtR/f+7
 0zpKJ10cc7cBygGnl1yR3KjhFyAWUFvP4ZGziKCcpMwXZfe9PGuyA/YOubMphxIn3YsK2wrd
 faKZYX2GMZCZhMMcvx9IpQrxIJgU+VlwXu/O+Lk10VIPcxPJJwmpdI6HzcS8ZgG6IMcC444X
 XTuLaP8j2mgcMvYak3ScCykAEQEAAYkCPAQYAQgAJhYhBPqEtpWvK/eaIGQ/8fEEnHKfHGUn
 BQJbUocAAhsMBQkHhh+AAAoJEPEEnHKfHGUnReMP/RA2UhGQj+G4uBshkRLjpRysabdPqgQB
 dEBk6wYbio88Wg/2/hgY7UzmDDEwX3sZfQDcrI6+vIobI8uqstZID+WgAAa1JLfChMyVQnSy
 0zfWMOABXscc5tGuvFRZvJklTissMFjXUwaREEKp4ZikTvJ/62MCjSdtrUhnPLvoTsHTKRKD
 ichE+b5A54alwsubTijw12O6N22r5IjZiiSZV0u7dsShyKw+7wCSax9fuBoE43NMYf+dnjMK
 nerAQYUcZWYMnk+EC8RaqYAxv6XZ2tKx1AkGGktwkQIBwrz9IlDSvJ3LWJ2UIIuLRTdngNgg
 GIL4zzuUa2F56FqskQIuYMaNETk6LYfalBDQ6TVLAcgCPQxp4k4i/PRsZ3lZ2ZhRHRYciOvm
 kp+I6EfHwllQpYrWs1thluBGqlJSVJgKl0IOFvKLsQ6KKfqzAwh6FxrO5qajp4viNIgtWoFw
 O5Bp0jgFTbH2OrMWIRfUdUCH1Djbuo65svhNj7FNsQVYzHDI+Nd1I/LOBoPc3UorRMF2M4JV
 kUR7skOHWUbPTSNUr7qc14NSMY3PKjGeVGAsBVHBPvmRx/Ss2tW/TpJWpxg4pmquFQSXuaYh
 Yf4FN8Sxy320pcr+FqN8AhZkYJcNY82OTtR5VEKRC/mYcyq61qXIKqngydn79bJjGxHipxyF FmEC
Message-ID: <edaeee0d-5367-ad46-6a5a-1357ea595151@postgresql.org>
Date: Fri, 16 Aug 2019 14:11:57 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0)
 Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <20190816012815.GW16436@tamriel.snowman.net>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="YASCAVWhDgukoZzqYB2UQC6BzXkTru0DD"
Precedence: bulk

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--YASCAVWhDgukoZzqYB2UQC6BzXkTru0DD
Content-Type: multipart/mixed; boundary="DuG6xvHmNxt78cJTCoXdO7oZkmmJZXPm4";
 protected-headers="v1"
From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Stephen Frost <sfrost@snowman.net>, Jeff Davis <pgsql@j-davis.com>
Cc: Michael Paquier <michael@paquier.xyz>,
 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
 pgsql-hackers@postgresql.org
Message-ID: <edaeee0d-5367-ad46-6a5a-1357ea595151@postgresql.org>
Subject: Re: Add "password_protocol" connection parameter to libpq
References: <071e45a6-97f7-1614-371c-98ecb03aed65@postgresql.org>
 <daf0017a1a5c2caabf88a4e00f66b4fcbdfeccad.camel@j-davis.com>
 <7a7a2f07-d013-eb80-85ba-9edaaf845038@2ndquadrant.com>
 <95b40ddcb3897772f075e6891521ee3f06f443d1.camel@j-davis.com>
 <93653d2b-7cf7-6992-7d3e-600ffd461354@2ndquadrant.com>
 <20190813025634.GF2551@paquier.xyz>
 <67726b008fa31d00d9a38257b3d1673b8afff2dd.camel@j-davis.com>
 <1e34ce7a-9d4c-dd99-3781-e0a3203f5aef@postgresql.org>
 <20190814023857.GB14446@paquier.xyz>
 <54269124d50791eacb71f1fead40422185ae8ddc.camel@j-davis.com>
 <20190816012815.GW16436@tamriel.snowman.net>
In-Reply-To: <20190816012815.GW16436@tamriel.snowman.net>

--DuG6xvHmNxt78cJTCoXdO7oZkmmJZXPm4
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 8/15/19 9:28 PM, Stephen Frost wrote:
> Greetings,
>=20
> * Jeff Davis (pgsql@j-davis.com) wrote:
>> On Wed, 2019-08-14 at 11:38 +0900, Michael Paquier wrote:
>>> 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 =3D {any,password,md5,scram-sha-256,scram-sha-256-
>>> plus,krb5,gss,sspi}
>>
>> What about something corresponding to the auth methods "trust" and
>> "cert", where no authentication request is sent? That's a funny case,
>> because the server trusts the client; but that doesn't imply that the
>> client trusts the server.
>=20
> I agree that "trust" is odd.  If you want my 2c, we should have to
> explicitly *enable* that for psql, otherwise there's the potential that=

> a MITM could perform a downgrade attack to "trust" and while that might=

> not expose a user's password, it could expose other information that th=
e
> client ends up sending (INSERTs, UPDATEs, etc).
>=20
> When it comes to "cert"- there is certainly an authentication that
> happens and we already have options in psql/libpq to require validation=

> of the server.  If users want that, they should enable it (I wish we
> could make it the default too but that's a different discussion...).
>=20
>> This is another reason I don't really like the list. It's impossible t=
o
>> make it cleanly map to the auth methods, and there are a few ways it
>> could be confusing to the users.
>=20
> I agree with these concerns, just to be clear.

+1.

>=20
>> Given that we all pretty much agree on the need for the separate
>> channel_binding param, the question is whether we want to (a) address
>> additional use cases with specific parameters that also justify
>> themselves; or (b) have a generic list that is supposed to solve many
>> future use cases.
>>
>> I vote (a). With (b), the generic list is likely to cause more
>> confusion, ugliness, and clients that break needlessly in the future.
>=20
> Admittedly, one doesn't preclude the other, and so we could move forwar=
d
> with the channel binding param, and that's fine- but I seriously hope
> that someone finds time to work on further improving the ability for
> clients to control what happens during authentication as this, imv
> anyway, is an area that we are weak in and it'd be great to improve on
> it.

To be pedantic, +1 on the channel_binding param.

I do agree with option (a), but we should narrow down what that means
for this iteration.

I do see "password_protocol" making sense as a comma-separated list of
options e.g. {plaintext, md5, scram-sha-256}. I would ask if
scram-sha-256-plus makes the list if we have the channel_binding param?

If channel_binding =3D require, it would essentially ignore any non-plus
options in password_protocol and require scram-sha-256-plus. In a future
scram-sha-512 world, then having scram-sha-256-plus or
scram-sha-512-plus options in "password_protocol" then could be
necessary based on what the user would prefer or require in their
application.

So if we do add a "password_protocol" parameter, then we likely need to
include the -plus's.

I think this is also fairly easy for a user to configure. Some scenarios
scenarios I can see for this are:

1. The user requiring channel binding, so only "channel_binding=3Drequire=
"
 is set.

2. A PostgreSQL cluster transitioning between SCRAM + MD5, and the user
setting password_protocol=3D"scram-sha-256" to guarantee md5 auth does no=
t
take place.

3. A user wanting to ensure a stronger method is used, with some
combination of the scram methods or md5, i.e. ensuring plaintext is not
used.

We would need to provide documentation around the types of password
validation methods are used for the external validators (e.g. LDAP) so
the user's known what to expect if their server is using those methods.

Jonathan


--DuG6xvHmNxt78cJTCoXdO7oZkmmJZXPm4--

--YASCAVWhDgukoZzqYB2UQC6BzXkTru0DD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE+oS2la8r95ogZD/x8QSccp8cZScFAl1W8e0ACgkQ8QSccp8c
ZSevUg//SuFaW3EFSGoKthnYr6dWqUq4znb0invysA6I4O31rW6P8jr9VrofemX9
Ek2xql+3jJZgMZ8nUPUyw6cRZKDi5SDc5JsFQB+eZwM/yPev6KgM4gVhtVqekC17
O4Y1OpcYF09FWU/PzJvAObk3q/2s+meafcRwz+1bRTgiuW71srYL8UnRnPrpT0/U
kbkYPVTxStNdSXT2E96PIG0aGNbdC+N6ec8WNIMcnr6Y2SLK9WA0SN8FMsGeArRX
01dC7UDyY7J/kIBYmirHT+RaeLa/nRqFVQD1WkKH2QyQJvtLpWdkdLEPINwnAi3i
Q8AeHC9PGqlrhU7scfy6aGgOmb1dEUHiY7rCsDvTLfDq5NapefJatQfDExjL4uBh
/tVlDVND/MkFFXu9+UfMZK1QiLdvEEs57u4HQtbX/+KQuzddc2H1KlmX9e6azNGh
g3kc7Ce7ho/oQmpzo/bX70WyDO3kQ7Tj4joOEfS9sXoCOWoilwszKIIBtAVUg/sA
Bal3opt+2maLaCpPqyfacMiWAMIdEIkX6UZcVrmagWz+VITO2Bxa5qAVLXM/6UAl
W5NTNSwxO62Ypf7E+FehaW0IkcTmwQ10xfWLzQtSCpDF/SDvIsfJUOjUxGqwmhVO
IqjHld81hTIHjJq3S5fanclUZiKiC+08SAikm1n8DwPlSW9VZSI=
=C8Z8
-----END PGP SIGNATURE-----

--YASCAVWhDgukoZzqYB2UQC6BzXkTru0DD--