Re: [PATCH v3] GSSAPI encryption support

* Craig Ringer (craig(at)2ndquadrant(dot)com) wrote:
> On 16 October 2015 at 01:07, Robbie Harwood <rharwood(at)redhat(dot)com> wrote:
> > 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.
>
> It's a different auth request, but the handling in be-auth.c is
> co-mingled to handle the cases:

be-auth.c? You mean src/backend/libpq/auth.c?

> * We're compiled with Kerberos, handling SSPI from Windows
> * We're compiled with Kerberos, handling a GSSAPI request

Eh, *kerberos* was removed with 9.4.0. I'm guessing you mean GSSAPI
above.

> * We're compiled with SSPI, and we're using Windows SSPI to handle a
> GSSAPI auth request
> * We're compiled with SSPI, and we're using it to handle a SSP client request
>
> SSPI is a wrapper. For Windows Domain members it carries
> GSSAPI/Kerberos data with the spnego extension. (For local loopback it
> does NTLM, but you don't need to care about that).

I have to admit that I'm not following what you're getting at here.

src/backend/libpq/auth.c and src/interfaces/libpq/fe-auth.c have pretty
clearly independent paths for SSPI and GSSAPI and which is used
(server-side) is based on what the auth method in pg_hba.conf is. In a
properly set up environment, the client could be using either, but it's
not like we try to figure out (or care) which the client is using from
the server's perspective.

Now, if you set up GSSAPI on the client side and tell it to require
encryption and you're using SSPI on the server side (or the other way
around) it's not likely to work without changes to the SSPI code paths,
which we should be looking at doing. I've not looked at the patch in
much depth yet, but hopefully there's a straight-forward way to say
"we're using SSPI on (client/server) and that doesn't support
encryption yet, so don't try to require it" and throw an error if
someone does. I don't think we necessairly have to have encryption with
SSPI working initially (and that's assuming SSPI can actually do
encryption the way GSSAPI can, I don't know that it can).

> > There is no reason that using GSSAPI from, e.g., MIT Kerberos for
> > Windows, should not work here.
>
> Except that *nobody* does it. The EDB installer builds Pg with SSPI,
> and that's what the overwhelming majority of Windows users use.

Apparently *somebody* uses MIT KfW; I doubt MIT would have put out
KfW 4.0 if no one wanted it. I agree that it's clearly a small number
of environments (I don't know of any currently) and it's entirely
possible that none of them use PG with GSSAPI on Windows for
authentication.

> Personally I don't care if this patch doesn't add support for GSSAPI
> encryption for sspi connections, only that it doesn't break them.

Agreed and we should certainly test it, but I'm not seeing what you're
getting at as the concern.

> > 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.
>
> It's maintained enough that AFAIK it works, and Pg supports compiling
> with it. No idea if anyone tests it with Pg anymore.

The EDB installers were changed to use SSPI instead of MIT KfW (or
perhaps just dropped building with GSSAPI, Dave would probably remember
better than I do) because KfW wasn't being maintained or updated any
more and the latest version had known security issues. That was quite a
while ago and it looks like MIT has decided to revive KfW (note the
drought between about 2007 and 2012 or so though..) with KfW 4.0.

I doubt anyone's tried building or running PG with GSSAPI under Windows
though. I agree it'd be good to test and see and perhaps even the EDB
installers could be changed to add support for it back in (not sure if
Dave really wants to though as it was a bit of a pain..). However,
presumably MIT has updated KfW and contains to maintain it because
someone is using it.

Really, though, assuming that GSSAPI as provided by KfW works per the
spec-defined API, I don't see why it wouldn't work under Windows just
the same as it does under *nix, it's not like we have any
Windows-specific code in backend/libpq/auth.c or
interfaces/libpq/fe-auth.c for GSSAPI except a MingW-specific symbol
definition.

> > 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.
>
> Hope so.
>
> I'll put this on my "hope to test it at some stage" list, but I don't
> have a prebuilt environment for it and have a lot to get ready for the
> next CF, so it'll be a while...

Ditto.

Thanks!

Stephen