Date: Wed, 12 Aug 2015 21:50:06 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Josh Berkus <josh@agliodbs.com>, Robert Haas <robertmhaas@gmail.com>,
 Peter Eisentraut <peter_e@gmx.net>, Heikki Linnakangas <hlinnaka@iki.fi>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: WIP: SCRAM authentication
Message-ID: <20150813015006.GU3685@tamriel.snowman.net>
References: <55CB5D38.5090503@gmx.net>
 <CA+TgmoZq6T=jsEr5sAW5Q3_63E4zaoim918e5fkb187AVmhr2g@mail.gmail.com>
 <55CBA425.5070803@gmx.net>
 <20150812200938.GM3685@tamriel.snowman.net>
 <CA+TgmoYRkGAYC8XAz91qiwDK=wEqXgUbCoaPgiZDnde0cMSj5Q@mail.gmail.com>
 <20150812203732.GN3685@tamriel.snowman.net>
 <WM!23d4ca1d7810ef17da5bfb2bff2b30680a248a83e6156f0e4af5f37678c7a95b80c95c7478b39152f75efb8a862787fb!@asav-2.01.com>
 <55CBB8D5.7040501@agliodbs.com>
 <20150813012259.GQ3685@tamriel.snowman.net>
 <CAB7nPqQxdSFfaeJK=RRfhnHQQ-7MCnMh6PXJJkRXPJAoNPR_1g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="TdDkFkGUMNACHLaO"
Content-Disposition: inline
In-Reply-To: 
 <CAB7nPqQxdSFfaeJK=RRfhnHQQ-7MCnMh6PXJJkRXPJAoNPR_1g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


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

* Michael Paquier (michael.paquier@gmail.com) wrote:
> On Thu, Aug 13, 2015 at 10:22 AM, Stephen Frost wrote:
> >> The only case where I can see multiple verifiers per role making a real
> >> difference in migrations is for PGAAS hosting.  But the folks from
> >> Heroku and AWS have been notably silent on this; lemme ping them.
> >
> > While their insight is certainly valuable, they are certainly not the
> > only cases of one-user-to-rule-them-all environments.  Further, there's
> > going to be cases where multiple applications from different languages
> > are accessing the database through the same account because there's only
> > one account.
> >
> > I'd rather not punt on those cases and, further, assume that we'll
> > always be able to keep it to only one password verifier per account.  As
> > I tried to outline up-thread, there are a set of features which would be
> > very nice for us to have which require further information to be saved
> > beyond even these different password verifiers for each.
>=20
> While looking at this stuff, I have been wondering as well about
> moving the validutil field into the verifier catalog as well for
> example. That's one.

Agreed.

> > As mentioned elsewhere, even SCRAM is possible of having multiple
> > password verifiers based on the various algorithms used.  In other
> > words, I doubt the 'only one password verifier per role' approach is
> > going to work out for us long term in any case.
>=20
> SCRAM is a definition for an authorization protocol which includes
> many verifiers, and the minimal requirement to consider that SCRAM is
> implemented in a system is to have SCRAM-SHA1, per here:
> http://tools.ietf.org/html/rfc5802
> For example we may want to have in parallel one verifier for
> SCRAM-SHA1 and one for SCRAM-SHA256 for the same user, and I think
> that we cannot close the door either to other SASL protocols, which is
> why it may make sense to split the SCRAM patch into two with the basic
> message protocol infrastructure in place.

and further agreed here.  In addition, I'd point out that this is not a
novel area in secure applications- Kerberos/GSSAPI have long been doing
this, with both MIT Kerberos and Heimdal providing multiple algorithms
and supporting multiple password verifiers per user.  Active Directory
also, actually.  When it comes to enterprise authentication systems and
administrators who work with them, this is not overly complex nor
suprising.

	Thanks!

		Stephen

--TdDkFkGUMNACHLaO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

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

iQIcBAEBCgAGBQJVy/fOAAoJEO1sijiDR2RVeAoP/3ZU1+es0NqCsbWO5/rvn6eV
uUrYhJXb01ikJgMviDcKa4g03TcgUNQb6FitGjRC+GQtUoljlIYFIovGPlA6RXnI
4Xmf9wPwinsEVLUvdgynSjrlVqBcBfe0wqkiF84wRsc6kJa9wMBRjQS0OOVpm8h5
QzUh/0FHFf/t+8MJMt23Osozx/A1RuVdG8CJWW5LgkX9cOvjFGeu+L+sebEAbzSJ
UjrxxWUZ0Iw2KaxrYZQk2xu2/Z5oSFd6D6WYTZUecMG2JQepyTF8LkDMV7+hzzyu
+O0oqHgBrSisfTNeFhTDCP63tiOXIK/NNvb03KYYK2O5olSKPYWbmXzWEVJLgrPF
pRFPlM8Tmm8UB1fTAblACUkT56C5hh3nEm1i2zMoW5YbTEJvV3/IS1LLTwe67/UJ
87Vik2tV8HO6zXYKVAh2uluqVvoal1ftJmuoeD0qNCNFcgXfMzjwljdZMYyvierP
1EFFLUguWE4wtIiNreTmAtIPkYPTEeS1FI7vfo2Tvk0Ne5bDwzb9WsXWPtxPuGmv
x8MVkAIkZdF+TOMJPWAcZ/SWBEn03HKAAId9xdTBCyGssl0utPPFsfSY8VpX6hWc
KHSEg+K9abSmX75/LCH2sRptjrux9KqF0EUCDS7rS2OqXI0+1vz80F0t3hya9iJX
pIx+LnAcNsywJLClDTne
=jm+u
-----END PGP SIGNATURE-----

--TdDkFkGUMNACHLaO--