Re: Postgres GSSAPI Encryption

Robbie,

* Robbie Harwood (rharwood(at)redhat(dot)com) wrote:
> Today, there exists GSSAPI authentication support in Postgres. I plan
> to extend this work to include encryption as well, but wanted to get
> your input on that first since you've probably thought about this
> already.

Great!

> From what I can tell, the auth/encryption layer is very nicely designed
> for extensibility; adding an encryption mechanism should just involve
> adding another option to the read/write functions in {f,b}e-secure.c,
> and then creating {f,b}e-secure-gssapi.c (or similar) to populate from.

It was reworked recently thanks to Heikki.

> We'd I think also want a new kind of HBA entry (probably something along
> the lines of `hostgss` to contrast with `hostssl`), but I'm not sure
> what we'd want to do for the counterpart of `hostnossl` (`hostnogss`?
> But then do we need `hostnogssnossl`? Is this even a useful setting to
> have?), so that will probably require broader discussion.

Are you intending to support GSSAPI encryption *without* using the
GSSAPI authentication mechanism? If not, maybe we can come up with a
way to have an option to the GSSAPI auth mechanism that behaves the way
we want for GSSAPI encryption. Perhaps something like:

encryption = (none | request | require)

If you need an option for it to still be able to fall-thru to the next
pg_hba line, that'd be more difficult, but is that really a sensible
use-case?

> Finally, I think there are a couple different ways the protocol could
> look. I'd ideally like to opportunistically encrypt all
> GSSAPI-authenticated connections and fallback to non-encrypted when the
> other end doesn't support it (possibly dropping the connection if this
> causes it to not match HBA), but I'm not sure if this will work with the
> existing code. A (less-nice) option could be to add a new
> authentication method for gss->encryption, which feels aesthetically
> misplaced. The approach used for SSL today could probably be adopted as
> a third approach, but I don't really see a gain from doing it this way
> since encryption happens after authentication (opposite of SSL) in
> GSSAPI.

I'd definitely like to see us opportunistically encrypt all GSSAPI
authenticated connections also. The main case to consider is how to
support migrating users who are currently using GSSAPI + SSL to GSSAPI
auth+encryption, and how to support them if they want to continue to use
GSSAPI just for user auth and use SSL for encryption.

Thanks!

Stephen