Re: [PATCH v12] GSSAPI encryption support

Robbie, all,

* Robbie Harwood (rharwood(at)redhat(dot)com) wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> > On Wed, Jul 27, 2016 at 12:22 AM, Robbie Harwood <rharwood(at)redhat(dot)com> wrote:
> >> Michael Paquier <michael(dot)paquier(at)gmail(dot)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.
>
> 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