Date: Mon, 1 Aug 2016 11:03:07 -0400
From: Stephen Frost <sfrost@snowman.net>
To: Robbie Harwood <rharwood@redhat.com>
Cc: Michael Paquier <michael.paquier@gmail.com>,
	PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
	Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [PATCH v12] GSSAPI encryption support
Message-ID: <20160801150307.GP4028@tamriel.snowman.net>
References: <1530.1459977031@sss.pgh.pa.us>
 <jlgy48qqt86.fsf@thriss.redhat.com>
 <5486.1459984857@sss.pgh.pa.us>
 <CAB7nPqRPK1f4oAStwsy_Ty_Cjjo8U50HF0bRZi86my7va4nVdg@mail.gmail.com>
 <jlgk2hq3uvr.fsf@thriss.redhat.com>
 <jlg7fc91lko.fsf@thriss.redhat.com>
 <CAB7nPqSmq1tuVGoVQXVb86y9SoaM-wcMDxHD1of9dGc54QYNSQ@mail.gmail.com>
 <jlg7fc8fmq7.fsf@thriss.redhat.com>
 <CAB7nPqQpNXMVLDX4XGjcoQPzRFF-Hj5MDse=ac9jZP91X0cYcw@mail.gmail.com>
 <jlgpopzhuo4.fsf@thriss.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="e7HAptx/nAeK3Wf0"
Content-Disposition: inline
In-Reply-To: <jlgpopzhuo4.fsf@thriss.redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


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

Robbie, all,

* Robbie Harwood (rharwood@redhat.com) wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
> > On Wed, Jul 27, 2016 at 12:22 AM, Robbie Harwood <rharwood@redhat.com> =
wrote:
> >> Michael Paquier <michael.paquier@gmail.com> writes:
> >>
> >> So there's a connection setting `sslmode` that we'll want something
> >> similar to here (`gssapimode` or so).  `sslmode` has six settings, but=
 I
> >> think we only need three for GSSAPI: "disable", "allow", and "prefer"
> >> (which presumably would be the default).
> >
> > Seeing the debate regarding sslmode these days, I would not say that
> > "prefer" would be the default, but that's an implementation detail.
> >
> >> Lets suppose we're working with "prefer".  GSSAPI will itself check two
> >> places for credentials: client keytab and ccache.  But if we don't find
> >> credentials there, we as the client have two options on how to proceed.
> >>
> >> - First, we could prompt for a password (and then call
> >>   gss_acquire_cred_with_password() to get credentials), presumably with
> >>   an empty password meaning to skip GSSAPI.  My memory is that the
> >>   current behavior for GSSAPI auth-only is to prompt for password if we
> >>   don't find credentials (and if it isn't, there's no reason not to
> >>   unless we're opposed to handling the password).
> >>
> >> - Second, we could skip GSSAPI and proceed with the next connection
> >>   method.  This might be confusing if the user is then prompted for a
> >>   password and expects it to be for GSSAPI, but we could probably make
> >>   it sensible.  I think I prefer the first option.
> >
> > Ah, right. I completely forgot that GSSAPI had its own handling of
> > passwords for users registered to it...
> >
> > Isn't this distinction a good point for not implementing "prefer",
> > "allow" or any equivalents? By that I mean that we should not have any
> > GSS connection mode that fallbacks to something else if the first one
> > fails. So we would live with the two following modes:
> > - "disable", to only try a non-GSS connection
> > - "enable", or "require", to only try a GSS connection.
> > That seems quite acceptable to me as a first implementation to just
> > have that.
>=20
> If it is the password management that is scary here, we could have a
> prefer-type mode which does not prompt, but only uses existing
> credentials.  Or we could opt to never prompt, which is totally valid.

For my 2c, at least, I'd like the "prefer" option when it comes to
encryption where we try to use encryption if we're doing GSSAPI
authentication.  I'm not a big fan of having the GSSAPI layer doing
password prompts, but as long as the *only* thing that does is go
through the Kerberos library to acquire the tickets and still completely
talks GSSAPI with the server, it seems reasonable.

If we end up having to fall back to a non-encrypted GSSAPI
authenticated session then we should make noise about that.  If the
authentication is handled through GSSAPI but the connection is not
encrypted, but the user is told that immediately (eg: in the psql
startup), it seems like there's relativly little sensitive information
which has been exposed at that point and the user could destroy the
session then, if they're concerned about it.

Of course, that only works for user sessions, such as with psql, and
doesn't help with application connections, but hopefully application
authors who are using GSSAPI will read the docs sufficiently to know
that they should require an encrypted connection, if their environment
demands it.

Thanks!

Stephen

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

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

iQIcBAEBCgAGBQJXn2SrAAoJEO1sijiDR2RVt9YP/2Ly6RAcuumNHAg5NH0WbgPZ
FDpI0b1hCzrldAxR2ggtUc2gtMBQFu3fsSfzhNJluDjDBWkRCD15r+NFiDP2eT99
LTdGBXoGqillK5vXFvT/HrjiDlOiAckYuPUb5pW2cKyxDmwxba/O/NNiVPTnCBIj
PspzsbaGPggRVuf044DiSCZuloRhXohUi6i/LTMdJOglRIXl0LFGbTkmKuu5nGwk
giJN2BkahPCOMDASfhIEzHoTMxMzHhJGvMoNaQmUnDK7dWRgaMkVjEsw2sU4QENf
XBC8kaNbrVEChxQ3oXzjx9IwFSblIAEnxyuGkF+7UPlMcCmAvXr91qKQzUIni5U0
qJxLEf4JUv0cHwrsrYriZK7a95OYl97OWGfe1uFLREzkwDY0SH/WbikKIdkCSujk
9ova/b81zy9la5PijubXgN8rxbP3L72ub755Q+8JYNCmOs68Ag96ZKxT2sqsqAk8
9csW05rdvNS+FraBDocxBZYKEGz0Kjn3vgx7z4n7ERFV5X58UkzHHk0CSnqBMmLZ
H3HtThkAVbOH26TqDbTTTkhgbmdHRSyDhHXfTNHu5QJKo1bX25lXfJuX+T7EypDR
ff352Z6k8/5W2sgnX62X8ibwUwF6ONrn0Pbh0uL05n0sTk4FF7LpeWO6NQYSBR6M
bE/M5OU+03PPfbnILUE+
=cGfM
-----END PGP SIGNATURE-----

--e7HAptx/nAeK3Wf0--