On Jun 23, 2007, at 1:44 AM, Magnus Hagander wrote:
Stephen Frost wrote:
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
On Jun 22, 2007, at 9:56 AM, Magnus Hagander wrote:
Most likely it's just checking the keytab to find a principal
same name as the one presented from the client. Since one is
loads it up automatically, and verifies against it.
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
to reflect that.
I agree there's some disconnect there between the documentation
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
someone tries to use GSS_C_NO_CREDENTIAL when accepting a context
to just be happy using anything in the keytab.
How about doing both, then? Set the principal name if it's
the config file. If it's explicitly set to an empty string, use
GSS_C_NO_CREDENTIAL. Seems straightforward enough to me, and shouldn't
be hard to implement.
I don't have a problem with that, but you'll want multiple service
names as soon as you want to support the SSPI.
Also don't get too bent out of shape about some client using the
wrong service name. The client *still* needs to prove who it
represents; there's no hole there. The only real security issue I
can think of is that someone who subverts the PostgreSQL server could
steal the "host" service keys and then (with a whole bunch of other
work) masquerade as the SSH daemon.
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
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
just let it in". If someone ends up having to support both
clients and unix Kerberos/GSSAPI clients it's entirely possible to
suggest they just make it POSTGRES and configure the clients
Yeah, that's how we do it today with Kerberos. But it *would* be handy
if this was easier ;-)
Don't read too much into the mod_auth_kerb situation. The main
reason it still takes a specific, configured service name is that
neither Russ Allbery nor I has gotten around to submitting a proper
patch to fix that. The only reason it was written the way it is in
the first place is that the ability to use GSS_C_NO_CREDENTIAL that
way is "obscure" and most people don't know it. I can say that with
some confidence because Russ and I had a long discussion with Sam
Hartman about how it ought to be done.
I'm told that the way Apple's equivalent to mod_auth_kerb works is it
uses GSS_C_NO_CREDENTIAL and then does a case-insensitive compare of
the resulting match to "HTTP". We could do the same thing, if you
think it's worth it.
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?