Re: Preliminary GSSAPI Patches

These patches have been reasonably tested (and cross-tested) on
Solaris 9 (SPARC) and MacOS 10.4 (both G4 and Intel) with the native
GSSAPI libraries. They implement the gss-np and (incompletely) the
gss authentication methods. Unlike the current krb5 method gssapi
has native support in Java and (with the SSPI) on Windows.

I still have bugs in the security layer for the gss method.
Hopefully will finish getting them ironed out today or tomorrow.

Documentation is in the README.GSSAPI file. Make sure you get it
created when you apply the patches.

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------

Henry B. Hotz wrote:
> These patches have been reasonably tested (and cross-tested) on
> Solaris 9 (SPARC) and MacOS 10.4 (both G4 and Intel) with the native
> GSSAPI libraries. They implement the gss-np and (incompletely) the
> gss authentication methods. Unlike the current krb5 method gssapi
> has native support in Java and (with the SSPI) on Windows.
>
> I still have bugs in the security layer for the gss method.
> Hopefully will finish getting them ironed out today or tomorrow.
>
> Documentation is in the README.GSSAPI file. Make sure you get it
> created when you apply the patches.
>

[ Attachment, skipping... ]

>
>
> ------------------------------------------------------------------------
> 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
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

These patches are updated as discussed to remove the incomplete
feature. Unfortunately I have a wedding to go to this weekend and
won't get them tested until next week. Will post when I've done so.

On Mar 31, 2007, at 3:41 PM, Henry B. Hotz wrote:

> These patches have been reasonably tested (and cross-tested) on
> Solaris 9 (SPARC) and MacOS 10.4 (both G4 and Intel) with the
> native GSSAPI libraries. They implement the gss-np and
> (incompletely) the gss authentication methods. Unlike the current
> krb5 method gssapi has native support in Java and (with the SSPI)
> on Windows.
>
> I still have bugs in the security layer for the gss method.
> Hopefully will finish getting them ironed out today or tomorrow.
>
> Documentation is in the README.GSSAPI file. Make sure you get it
> created when you apply the patches.
>
> <gss.patches.gz>

I finally got to testing that updated patch. It's fine per-se, but
was missing the updated README.GSSAPI file. Herewith fixed.

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------

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

[ Attachment, skipping... ]

>
> On May 12, 2007, at 9:53 AM, Henry B. Hotz wrote:
>
> > These patches are updated as discussed to remove the incomplete
> > feature. Unfortunately I have a wedding to go to this weekend and
> > won't get them tested until next week. Will post when I've done so.
> >
> > On Mar 31, 2007, at 3:41 PM, Henry B. Hotz wrote:
> >
> >> These patches have been reasonably tested (and cross-tested) on
> >> Solaris 9 (SPARC) and MacOS 10.4 (both G4 and Intel) with the
> >> native GSSAPI libraries. They implement the gss-np and
> >> (incompletely) the gss authentication methods. Unlike the current
> >> krb5 method gssapi has native support in Java and (with the SSPI)
> >> on Windows.
> >>
> >> I still have bugs in the security layer for the gss method.
> >> Hopefully will finish getting them ironed out today or tomorrow.
> >>
> >> Documentation is in the README.GSSAPI file. Make sure you get it
> >> created when you apply the patches.
> >>
> >> <gss.patches.gz>
> >
> > <gss.patch2.bz2>
> >
> >
> > Just to cover the legal bases: I don't consider these changes to
> > be significant enough to require the involvement of the JPL
> > clearance process. JPL has already ruled that they do not fall
> > afoul of any ITAR restrictions.
> >
> > I am not imposing any license restrictions myself either, but some
> > credit in the release notes, or wherever, would be appreciated.
> ------------------------------------------------------------------------
> 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
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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.

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.

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.

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 :)

//Magnus

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

On Tue, Jun 19, 2007 at 06:19:37PM -0700, Henry B. Hotz wrote:
> 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 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.

I've got a bit more cleanup to do, but I'm almost there.

Much of it is just cleanup. I've changed the structs arond to be more in
line with the other code around it, and such. Refacored some of the code to
cut down duplicate codes. Added some stuff to make it work on windows
(still just with MIT kerberos and not native though). Fixed two (I think it
was) small memory leaks.

Protocol-wise, it no longer piggybacks int eh AuthenticationOk message -
instead we send an extra continue message followed right away by an
AuthenticationOk one.

Oh, and I've added autoconf. Not complete yet, but getting there :-)

I'll post the updated patch shortly :-)

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

Not really ;-) I did check the code, and it certaily wasn't right the way
it was. I added some manual packet injection, and it ended up in the wrong
place. It looks right now, and I'll have to test that eventually (my test
packets end up in the right place now). But what I have now *seems* right.

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

The client side was much more complete, yes :) And with my other chanegs to
the protocol, it actually gets more than one packet.

As for the server-side fix, it was just moving a couple of lines of code
inside the loop...

//Magnus

Magnus Hagander wrote:
>> Be curious to see what you've done, but if you're actively changing
>> things I'll let them settle.
>
> I've got a bit more cleanup to do, but I'm almost there.
>
> Much of it is just cleanup. I've changed the structs arond to be more in
> line with the other code around it, and such. Refacored some of the code to
> cut down duplicate codes. Added some stuff to make it work on windows
> (still just with MIT kerberos and not native though). Fixed two (I think it
> was) small memory leaks.
>
> Protocol-wise, it no longer piggybacks int eh AuthenticationOk message -
> instead we send an extra continue message followed right away by an
> AuthenticationOk one.
>
> Oh, and I've added autoconf. Not complete yet, but getting there :-)
>
> I'll post the updated patch shortly :-)

Ok. Here's the version I have right now, sans autoconf (which I broke in
my attempts to make it work with mingw).

I have one major question remaining:
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.

Is this perhaps a leftover from the old gssapi-encryption code? In that
we need to use that parameter on the server in order to enable
encryption, but can remove it for now, until we have that? (Since the
parameter is around for krb5 anyway, it's just #ifdefing it back out, of
course, not actually removing it)

(Still working on the documentation part)

//Magnus

* 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). 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. :/

Thanks,

Stephen

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.

//Magnus

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

* 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

Stephen Frost wrote:
> * 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.

How about doing both, then? Set the principal name if it's specified in
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.

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

Yeah, that's how we do it today with Kerberos. But it *would* be handy
if this was easier ;-)

//Magnus

Magnus Hagander wrote:
> Stephen Frost wrote:
>> * 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.
>
> How about doing both, then? Set the principal name if it's specified in
> 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.

Here's an updated patch that does this.

//Magnus

On Jun 23, 2007, at 1:44 AM, Magnus Hagander wrote:

> Stephen Frost wrote:
>> * 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.
>
> How about doing both, then? Set the principal name if it's
> specified in
> 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
>> 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.
>
> 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.
Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu

> >>> 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.
> >
> > How about doing both, then? Set the principal name if it's
> > specified in
> > 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.

Ok. that's certainly a lot more narrow than I thought. you can see from my updated patch that it's not particularly lots of code. but if the gain is so little
and we end up recommending people not to use that part anyway for compatibility I'm more than happy to take it out again. You certainly know more about these
aspect of gss than me ;)

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

Ok. That makes a lot of sense then.

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

Do you know if this is documented somewhere? It's always nice with references.

/Magnus

On Jun 24, 2007, at 11:03 PM, Magnus Hagander wrote:

>> 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.
>
> Do you know if this is documented somewhere? It's always nice with
> references.

Not as far as I know, publicly.

I heard most of it from an Apple developer at the 2005 WWDC (and I
inferred the rest from things Sam Hartman has said). I guess that
technically puts it under NDA, except I think the code in question is
open source. I don't know which project it's in so I haven't been
able to locate it to verify what I said for sure.

What I can say for certain concerns the client side. Apple's Safari
browser went through at least two iterations before they got it
right: 1) in OSX 10.3 Safari would ask for a "server/
server.example.com" service ticket. 2) in early 10.4 Safari would
ask for a "http/server.example.com" service ticket (this actually
works fine if have Active Directory as your Kerberos server, and IIS,
or Apple as your web server). 3) in later 10.4 Safari asks for a
"HTTP/server.example.com" service ticket. This is the correct thing
to do.

Due to the numbers of people talking to Apple about the situation
(state 2) during that WWDC, they publicly acknowledged the problem
and promised to fix it during the same WWDC. If you have access to
the video recordings you can probably find the relevant session in
the latter half of the week.

The key technical point is that Kerberos is case sensitive, but
Windows Kerberos isn't. We can deal with that how we choose, but I
kind of like Apple's solution. It's annoying to have to put two
service principals in the keytab, but I personally prefer that to
going upper-case only just 'cause that's the only way Windows SSPI
clients can work with non-Windows servers.

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

On Mon, Jun 25, 2007 at 12:31:44AM -0700, Henry B. Hotz wrote:
>
> On Jun 24, 2007, at 11:03 PM, Magnus Hagander wrote:
>
> >>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.
> >
> >Do you know if this is documented somewhere? It's always nice with
> >references.
>
> Not as far as I know, publicly.
>
> I heard most of it from an Apple developer at the 2005 WWDC (and I
> inferred the rest from things Sam Hartman has said). I guess that
> technically puts it under NDA, except I think the code in question is
> open source. I don't know which project it's in so I haven't been
> able to locate it to verify what I said for sure.

Ok. no problem.

> What I can say for certain concerns the client side. Apple's Safari
> browser went through at least two iterations before they got it
> right: 1) in OSX 10.3 Safari would ask for a "server/
> server.example.com" service ticket. 2) in early 10.4 Safari would
> ask for a "http/server.example.com" service ticket (this actually
> works fine if have Active Directory as your Kerberos server, and IIS,
> or Apple as your web server). 3) in later 10.4 Safari asks for a
> "HTTP/server.example.com" service ticket. This is the correct thing
> to do.
>
> Due to the numbers of people talking to Apple about the situation
> (state 2) during that WWDC, they publicly acknowledged the problem
> and promised to fix it during the same WWDC. If you have access to
> the video recordings you can probably find the relevant session in
> the latter half of the week.
>
> The key technical point is that Kerberos is case sensitive, but
> Windows Kerberos isn't. We can deal with that how we choose, but I
> kind of like Apple's solution. It's annoying to have to put two
> service principals in the keytab, but I personally prefer that to
> going upper-case only just 'cause that's the only way Windows SSPI
> clients can work with non-Windows servers.

Interesting, indeed. I think gonig down the same approach they were using
is the best way to do, so I've changed my working copy back to that
version, and will update the documentation with that information.

//Magnus

You know, I don't know what I was thinking when I sent this. My
apologies for the late correction.

Anyone who has a copy of the "host" keys for a machine can
manufacture kerberos tickets for the "host" service on that machine
masquerading as absolutely anyone (including people who don't
exist). Same for the "postgres" keys, and if the postgres server can
steal the host keys (or vice versa) then it's even worse.

I don't know of any exploit code that is designed for this purpose,
but there is code that uses this property to (legitimately) provide
kerberos tickets for AFS in scenarios where the KDC can't.

On Jun 24, 2007, at 10:10 PM, Henry B. Hotz wrote:

> On Jun 23, 2007, at 1:44 AM, Magnus Hagander wrote:
>
>> Stephen Frost wrote:
>>> * 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.
>>
>> How about doing both, then? Set the principal name if it's
>> specified in
>> 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
>>> 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.
>>
>> 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.
> Henry(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu
>
>

"Henry B. Hotz" <hbhotz(at)oxy(dot)edu> writes:
> You know, I don't know what I was thinking when I sent this. My
> apologies for the late correction.
>
> Anyone who has a copy of the "host" keys for a machine can
> manufacture kerberos tickets for the "host" service on that machine
> masquerading as absolutely anyone (including people who don't
> exist). Same for the "postgres" keys, and if the postgres server can
> steal the host keys (or vice versa) then it's even worse.
> [snip...]

Maybe I'm too dense, but I don't see a conclusion here. Do we need to
change our code, our docs, both, or neither?

regards, tom lane

Tom Lane wrote:
> "Henry B. Hotz" <hbhotz(at)oxy(dot)edu> writes:
>> You know, I don't know what I was thinking when I sent this. My
>> apologies for the late correction.
>>
>> Anyone who has a copy of the "host" keys for a machine can
>> manufacture kerberos tickets for the "host" service on that machine
>> masquerading as absolutely anyone (including people who don't
>> exist). Same for the "postgres" keys, and if the postgres server can
>> steal the host keys (or vice versa) then it's even worse.
>> [snip...]
>
> Maybe I'm too dense, but I don't see a conclusion here. Do we need to
> change our code, our docs, both, or neither?

I don't think we do. If you use service keys per our documentation, you
should be fine. And if someone owns your host keys, you lost already.

//Magnus

I'm not suggesting any change. Merely correcting a misstatement I
made earlier.

I believe the documentation already recommends best practice.

On Oct 10, 2007, at 10:53 AM, Magnus Hagander wrote:

> Tom Lane wrote:
>> "Henry B. Hotz" <hbhotz(at)oxy(dot)edu> writes:
>>> You know, I don't know what I was thinking when I sent this. My
>>> apologies for the late correction.
>>>
>>> Anyone who has a copy of the "host" keys for a machine can
>>> manufacture kerberos tickets for the "host" service on that machine
>>> masquerading as absolutely anyone (including people who don't
>>> exist). Same for the "postgres" keys, and if the postgres server
>>> can
>>> steal the host keys (or vice versa) then it's even worse.
>>> [snip...]
>>
>> Maybe I'm too dense, but I don't see a conclusion here. Do we
>> need to
>> change our code, our docs, both, or neither?
>
> I don't think we do. If you use service keys per our documentation,
> you
> should be fine. And if someone owns your host keys, you lost already.
>
> //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