Craig Ringer <craig@2ndquadrant.com> writes:
> On 14 October 2015 at 06:34, Robbie Harwood <rharwood@redhat.com> wrote:
>> Alright, here's v3. As requested, it's one patch now.
>
> I hate to ask, but have you looked at how this interacts with Windows?
>
> We support Windows SSPI (on a domain-member host) authenticating to a
> PostgreSQL server using gssapi with spnego.
>
> We also support a PostgreSQL client on *nix authenticating using
> gssapi with spnego to a PostgreSQL server that's requesting sspi mode.
>
> The relevant code is all a bit tangled, since there's support in there
> for using Kerberos libraries on Windows instead of SSPI too. I doubt
> anybody uses that last one, tests it, or cares about it, though, given
> the painful hoop-jumping, registry key permission changes, etc
> required to make it work.
>
> For bonus fun, RC4, DES, AES128 or AES256 are available/used for
> Kerberos encryption on Windows. See
>
http://blogs.msdn.com/b/openspecification/archive/2011/05/31/windows-configurations-for-kerberos-supported-encryption-type.aspx
> . Though given that Win7 defaults to AES256 it's probably reasonable
> to simply not care about anything else.
The short - and probably most important - answer is that no, I haven't
tested it, and it would be difficult for me to do so quickly.
In more depth:
Looking at
http://www.postgresql.org/docs/9.4/static/protocol-message-formats.html
suggests that SSPI follows a separate codepath from the GSS code;
certainly it's a different auth request, which means it shouldn't
trigger the encryption path.
There is no reason that using GSSAPI from, e.g., MIT Kerberos for
Windows, should not work here. Even more broadly than that, GSSAPI is a
RFC-standardized protocol with rigorously tested interop etc. etc.,
though whether anyone outside of MIT cares about MIT Kerberos for
Windows I have no idea. As for encryption types, MIT out-of-the-box
supports aes256 + aes128 (in several variants), rc4-hmac and friends,
camellia in several variants, and des3-cbc-sha1. A much wider selection
is available on setting the appropriately named "allow_weak_crypto" in
krb5.conf, though I would hope that would not be needed.
I think the important takeaway here is that I haven't actually changed
how *authentication* works; these changes only affect GSSAPI
post-authentication add encryption functions as defined by that
specification. So if the authentication was working before, and the
GSSAPI implementation is following RFC, I would hope that this would
work still.
Thanks,
--Robbie