Re: Preliminary GSSAPI Patches

On Jun 22, 2007, at 9:56 AM, Magnus Hagander wrote:

> Stephen Frost wrote:
>> * Magnus Hagander (magnus(at)hagander(dot)net) wrote:
>>> We enable the setting of the service name in the server
>>> configuration
>>> file, but we never use that variable anywhere. We do, however,
>>> use the
>>> service name on the client, in order to pick the correct key (and
>>> turning this off makes GSSAPI no longer work).
>>>
>>> If this is correct, we should not enable that parameter on the
>>> server.
>>> If it's not correct, we should be using it somewhere.
>>
>> Uh, shouldn't you be acquiring the server credentials before
>> accepting
>> the context? That'd be done using gss_acquire_cred(), which takes
>> the
>> service name (in gss_name_t structure) as an argument. That would
>> then
>> be passed in to gss_accept_sec_context() instead of using
>> GSS_C_NO_CREDENTIAL (in port->gss->cred).
>
> That's the direction I was thinking in. I just wanted to have it
> confirmed. Henry, what's your take on this?
>
>> I'm kind of suprised it's
>> working without that and rather curious as to what it's doing
>> under the
>> hood to make that happen. :/
>
> 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.

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.

Now it *might* make sense to check that the credential that's
accepted actually has some correspondence to what ./configure said.
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.

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