Re: Preliminary GSSAPI Patches

Such timing!

I just spent most of yesterday stepping though the gssapi sample
app's in Java 1.4 with someone here at work. Was thinking I needed
to get back to the JDBC client and do what I promised. Also finished
filtering the PG lists for stuff just before seeing this email.

On Jun 19, 2007, at 6:04 AM, Magnus Hagander wrote:

> On Sun, May 20, 2007 at 01:28:40AM -0700, Henry B. Hotz wrote:
>> I finally got to testing that updated patch. It's fine per-se, but
>> was missing the updated README.GSSAPI file. Herewith fixed.
>>
>
> I've been reviewing and updating this patch, for a while now.I've
> changed
> quite a bit around, and I have it working fine, but I have one
> question.

Be curious to see what you've done, but if you're actively changing
things I'll let them settle.

> Is there a way to provoke GSSAPI into sending multiple packets in the
> authentication? It doesn't seem to do that for me, and ISTM that
> the code
> as it stands is broken in that case - but I'd like to verify it.

Remember wondering about that myself. For SASL if you turn on all
the options you get an extra round trip. Not for GSSAPI/Krb5, which
is pretty efficient in that respect. The loop logic for SASL is just
different enough I can imagine messing up, but I would have thought
it would have made me get the logic right.

The only thing I can think of is to use a different GSSAPI
mechanism. That opens an interesting can of worms that has nothing
to do with Postgresql. First of all that means you need to use a
GSSAPI implementation that supports multiple mechanisms (which
precludes Java for now). That in turn means either Sun, or MIT 1.6+,
or Heimdal 0.8+. Second, you need another mechanism to install.
That means the commercial Entrust SPKM mechanism on Sun, or the UMICH
SPKM mechanism, or some SPNEGO mechanism.

Love says there are problems with the SPKM RFC and the UMICH
implementation won't interoperate with other implementations as a
result (but it works with itself). I also know he's been
experimenting with other mechanisms. Looking at the latest Heimdal
snapshot I have, it seems to have both SPNEGO and NTLM mechanism code
in it.

A configuration that used SPNEGO to negotiate Kerberos 5 ought to
take two round trips, at least. Feel like trying it?

I never tested my patches against a Heimdal gssapi library. My bad.
If you try the patches against Heimdal GSSAPI/SPNEGO/Krb5 that ought
to be a really good test case. It would be a good server case to try
with a native Windows client as well.

> Basically, pg_GSS_recvauth() is supposed to loop and read all
> "continuing
> exchange packets", right? But the reading of packets from the
> network sits
> *outside* the loop. So it basically just loops over and over on the
> same
> data, which ISTM is wrong. It does send a proper ask-for-continue
> message
> to the frontend inside the loop, but I can't figure out how it's
> supposed
> to read the response.

I remember having to stand on my head to get it (apparently) right on
the client side. I also remember the server side was a lot simpler,
but you're saying I may have oversimplified? I can't answer the
question about the server side without reviewing the code.

> It looks like the fix should be as simple as moving the packet
> reading into
> the loop, but again I'd like a way to test it :)

Well, probably, but that doesn't sound that simple to me (assuming I
really didn't do that to begin with).

> //Magnus

------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu