Re: Postgres GSSAPI Encryption

Stephen Frost <sfrost(at)snowman(dot)net> writes:

> Robbie,
>
> * Robbie Harwood (rharwood(at)redhat(dot)com) wrote:
>
>> 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?

That's a good point. I don't see GSSAPI encryption without GSSAPI
authentication as a particularly compelling use case, so a setting like
that (with default presumably to request for backward compatibility)
seems perfect.

As for fall-through on failure, I don't really know what's reasonable
here. My understanding of the way it works currently suggests that it
would be *expected* to fall-through based on the way other things
behave, though it's certainly less effort on my part if it does not.

>> 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.

So if we go with the "encryption" option, we might not need a specific
entry for GSS hosts. For the SSL encryption/GSS auth case, we'd want it
to work the way it does now where you specify "hostssl" and then "gss"
as the method. Then for the GSS for auth and encryption, one would use
a normal "host" entry, then specify gss as the method, and then set
encryption=require.

One consequence of this would be that you can do "double encryption" by
specifying "hostssl", then "gss" with "encrypt = require". I don't
think this is something more desirable than just one or the other, but
unless it's actually a problem (and I don't think it is) to have around,
I think the setup would work nicely. We could also default "encrypt" to
"none" when hostssl is specified if it is a problem.

Thanks!
--Robbie