Date: Fri, 9 Aug 2019 09:28:50 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Michael Paquier <michael@paquier.xyz>
Cc: Jeff Davis <pgsql@j-davis.com>, pgsql-hackers@postgresql.org
Subject: Re: Add "password_protocol" connection parameter to libpq
Message-ID: <20190809132850.GL16436@tamriel.snowman.net>
References: <227015d8417f2b4fef03f8966dbfa5cbcc4f44da.camel@j-davis.com>
 <20190809030021.GG3194@paquier.xyz>
 <3bbf5968ea705700a2605d6db74d8510bea7940b.camel@j-davis.com>
 <20190809100922.GI3194@paquier.xyz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="HLsZ5Z1opAQvdr2J"
Content-Disposition: inline
In-Reply-To: <20190809100922.GI3194@paquier.xyz>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk


--HLsZ5Z1opAQvdr2J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greetings,

* Michael Paquier (michael@paquier.xyz) 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.
> >=20
> > 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.
>=20
> 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".

=46rom 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.
> >=20
> > We could expose it as an SASL option like:
> >=20
> >    saslmode =3D {disable|prefer|require-scram-sha-256|require-scram-sha-
> > 256-plus}
>=20
> 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

--HLsZ5Z1opAQvdr2J
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJdTXUSAAoJEO1sijiDR2RVHgIP/3/LTMyjO8WH5gdbFcmaWoaW
PXgcYDHuIBZ8LgYt1MN7LoiXqZTU2OHs2ZbDnvidcAIzK5OFrPj8xsPUspyZlhrI
yKyj7VfMh+YY8A5l/NSoeoA8T+R9M3AvWiwI+igSCk7mtOMtkzXRku7gO4xlHt+C
xCJJZFz2NADt6s5zPEwUwPkUvAUnmwp5OQFc8sRn9ue3QdJHXw89esU5B/xG0MPi
oOSxxyNnNUwCKUcoCNElUZxN/hHb079KPfaqAqaSHUkyHhynz4AOVpFunq/TSIg7
C8npuyYxYyr140hCqc6O7ao54zmOcv7K6FF6XcZjO4L93IXJzx8NFMdkyhI2OQjG
x/1a9Qt1xzUx9GTEiS4ey1Q3NFJo1YLZ6ioRKxz/WUBGGLBwbVU4UjymrlOSFX+y
mAZ+gUxJ3Z7PkqSnLr26pAWKUSqfUSh0OG4pEUlZVDtj/YP/RsUhNEc8CpMqT59E
gbebdJNMWnSj+9uglpjsT4o32moehngMt8YiKFqUx3jNCmgzTTtEXIYvwEOBKf0b
S9c6fFNqZA2g7G4wAecdv6qadxsN/FAsmuU2Shr3WU8LBUzb5mRKocEwTb1Fvjzb
PLFXv9mAYohl1IgesnYCvc2of8Fm7tal/J3BiiH4Sdz1Z/udvt3MMr2QGu1GSbg+
2Q7UN0bV+qQCW68t+MUe
=4xbt
-----END PGP SIGNATURE-----

--HLsZ5Z1opAQvdr2J--