Subject: Re: Add "password_protocol" connection parameter to libpq
To: Jeff Davis <pgsql@j-davis.com>, Heikki Linnakangas <hlinnaka@iki.fi>,
 Stephen Frost <sfrost@snowman.net>, Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@postgresql.org
References: <227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel@j-davis.com>
 <20190809030021.GG3194@paquier.xyz>
 <3bbf5968ea705700a2605d6db74d8510bea7940b.camel@j-davis.com>
 <20190809100922.GI3194@paquier.xyz>
 <20190809132850.GL16436@tamriel.snowman.net>
 <609482826475e0063c7d71b2449ae31c0d61b232.camel@j-davis.com>
 <071e45a6-97f7-1614-371c-98ecb03aed65@postgresql.org>
 <dc2c84d5-92d3-acbc-4f39-2846d0c5a72d@iki.fi>
 <a977da04af60668c487a7a21abbcbb87b9ea8344.camel@j-davis.com>
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: <e370dce7-9471-2dcc-41e7-f334389ecdfd@postgresql.org>
Date: Sat, 10 Aug 2019 11:08:46 -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: <a977da04af60668c487a7a21abbcbb87b9ea8344.camel@j-davis.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="j3RyZC8uyeN8YrXOtkx9uRlf9typ2fWI0"
Precedence: bulk

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--j3RyZC8uyeN8YrXOtkx9uRlf9typ2fWI0
Content-Type: multipart/mixed; boundary="Mw2Hwpufp09fje0KdA2OJWsh5lzSB5NS4";
 protected-headers="v1"
From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Jeff Davis <pgsql@j-davis.com>, Heikki Linnakangas <hlinnaka@iki.fi>,
 Stephen Frost <sfrost@snowman.net>, Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@postgresql.org
Message-ID: <e370dce7-9471-2dcc-41e7-f334389ecdfd@postgresql.org>
Subject: Re: Add "password_protocol" connection parameter to libpq
References: <227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel@j-davis.com>
 <20190809030021.GG3194@paquier.xyz>
 <3bbf5968ea705700a2605d6db74d8510bea7940b.camel@j-davis.com>
 <20190809100922.GI3194@paquier.xyz>
 <20190809132850.GL16436@tamriel.snowman.net>
 <609482826475e0063c7d71b2449ae31c0d61b232.camel@j-davis.com>
 <071e45a6-97f7-1614-371c-98ecb03aed65@postgresql.org>
 <dc2c84d5-92d3-acbc-4f39-2846d0c5a72d@iki.fi>
 <a977da04af60668c487a7a21abbcbb87b9ea8344.camel@j-davis.com>
In-Reply-To: <a977da04af60668c487a7a21abbcbb87b9ea8344.camel@j-davis.com>

--Mw2Hwpufp09fje0KdA2OJWsh5lzSB5NS4
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

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=3Drequire" is
>> one=20
>> way to prevent MITM attacks, but sslmode=3Dverify-ca is another. (Does=
=20
>> Kerberos also prevent MITM?) Or you might want to enable plaintext=20
>> passwords over SSL, but not without SSL.
>>
>> I think we'll need something like the 'ssl_ciphers' GUC, where you
>> can=20
>> choose from a few reasonable default rules, but also enable/disable=20
>> specific methods:
>=20
> ..
>=20
>> auth_methods =3D 'MITM, -password, -md5'
>=20
> Keep in mind this is client configuration, so something reasonable in
> postgresql.conf might not be so reasonable in the form:
>=20
> postgresql://foo:secret@myhost/mydb?auth_methods=3DMITM%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


--Mw2Hwpufp09fje0KdA2OJWsh5lzSB5NS4--

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

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

iQIzBAEBCAAdFiEE+oS2la8r95ogZD/x8QSccp8cZScFAl1O3f4ACgkQ8QSccp8c
ZSd98BAAqJm1da82/7RuWnUlkimEfAC/FkXlM8YU0KtD9BOF13b5BkD2+Paj/uBT
kUl8LLmznwMXVBW6HnttNVxJvFSFthpi++WmGQ29x0d/OHULTVW1pj5jc2eEUmkn
xMTEt9QDJg3y3QBoi3ojTM++VgbghC63E/vA09aC9LbMjQljB6spro3HdBvRAn13
RXrh9F7oQME7LT9Spbvmqe67IAV8p0fuidxPxfX19f6VZtZvd+mqPgWOfcCjmBrX
np+hvG/tTn5CyH1FARwV+luRim8liG+0g++/Y6TpwaJ0GpAhfSE0nqlRsgn3ENdN
cbDQF6iZAcIrSFiq7FbHbqVGgZlI/iHGoANlLHhMZy3FUWNKWc68BZIyzbheaeoa
zThOXDK06VtTJ0Wyq85U5zHE5ZDCW3F6wcmlIJwQETM4plJXJnKFkdnsk7y/32zx
NS2UOpCgvtuWfKIP5YjmO0PHbABS76SNEwbyANR1z2qgM+lC5L6skoOiFevQcqCX
cyOdFvKGaEDiiwzNAsfcs6fzCrw2DGEOPpqeE7zdaDydfUf0s9XGUMjCHSyjjk+D
OCNaVNKFs1HYXt5CPiRMJTQXcDEC2QDGBttMrY0yLYShG0HXWQg6a0wnoTVVOv7F
p+sIU3ErShZNQKBbjauOm+91Ol9D9fa32AhXogQLsKy0Fu5acPI=
=j9MP
-----END PGP SIGNATURE-----

--j3RyZC8uyeN8YrXOtkx9uRlf9typ2fWI0--