Hello!
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.
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.
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.
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'm interested to hear your thoughts on this.
Thanks!
--Robbie