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
signature.asc
Description: PGP signature