Re: Preliminary GSSAPI Patches

* Henry B. Hotz (hbhotz(at)oxy(dot)edu) wrote:
> On Jun 22, 2007, at 9:56 AM, Magnus Hagander wrote:
> >Most likely it's just checking the keytab to find a principal with the
> >same name as the one presented from the client. Since one is
> >present, it
> >loads it up automatically, and verifies against it.
>
> Bingo!
>
> The server uses the keytab to decrypt the token provided by the
> client. By using the GSS_C_NO_CREDENTIAL arg on the server anything
> put in the keytab is OK. (The server doesn't need to authenticate
> itself to Kerberos, it just accepts authentication. Mutual
> authentication is done using the same keys.) The documentation needs
> to reflect that.

I agree there's some disconnect there between the documentation and the
apparent implementation but I'm not sure I'm in favor of changing the
documentation on this one. Personally, I'd rather it return an error if
someone tries to use GSS_C_NO_CREDENTIAL when accepting a context than
to just be happy using anything in the keytab.

> The real question is whether we *need* to check anything. If the
> keytab is unique to PostgreSQL, as I think it should be, then I think
> the admin should put only the right stuff in the keytab, and no
> further checks are needed.

While I agree that in general it's best to have a keytab file for each
seperate service, there's no guarentee of that being done and using,
say, the 'host' service to allow authentication to PG when the PG
service is 'postgres' isn't right.

> Now it *might* make sense to check that the credential that's
> accepted actually has some correspondence to what ./configure said.

Or what's configured in the postgres.conf (as is done for Kerberos
now...).

> If we do do that, then we need to allow for the ways Microsoft mucks
> with the case of the name. (Kerberos is supposed to be case
> sensitive, but Microsoft work that way.) In particular I think we
> may need both postgres/<server> and POSTGRES/<server> in the keytab
> in order to support the to-be-written native Windows SSPI client at
> the same time as the current Kerberos 5 and GSSAPI Unix clients.

Supporting multiple, specific, keys might be an interesting challenge,
but I'm not too keen on worrying about it right now regardless. I'd
also much rather err on the side of "overly paranoid" than "if it works,
just let it in". If someone ends up having to support both windows SSPI
clients and unix Kerberos/GSSAPI clients it's entirely possible to
suggest they just make it POSTGRES and configure the clients
accordingly.

> Now what happens with non-Kerberos 5 mechansims like SPKM and
> SPNEGO? ;-) I'll have to see, even if it doesn't matter for Java, yet.

Err, SPNEGO's not really a full mechanism itself, it's got sub-mechs of
NTLM and Kerberos and from what I've seen it does the same thing SSPI
does and assumes uppercase. Again, it's ugly, but not unbearable. Such
fun things are probably also why mod-auth-kerb for Apache lets you
configure the service name, like most other Kerberos servers... I've
yet to run into one that will just use any key in the keytab it's given.

Thanks,

Stephen