Fwd: [PATCHES] Preliminary GSSAPI Patches

Excuse me for replying to myself, but maybe it would be clearer if I
said this the other way around:

The existing Kerberos support uses a C API that is not supported in
Java or on Windows, and probably never will be. If we want to
support Kerberos on *all* platforms (and if we want expandability to
non-Kerberos, non-password authentication methods) then Postgres
should use the GSSAPI instead. The submitted patches allow that.

I tend to regard this as a comparable migration to the Kerb4 -> Kerb5
one. In time it should be a complete replacement. In time we will
be able to rip out the existing Kerb5 code.

On Apr 30, 2007, at 3:23 PM, Henry B. Hotz wrote:

"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:

I tend to regard this as a comparable migration to the Kerb4 -> Kerb5
one. In time it should be a complete replacement. In time we will
be able to rip out the existing Kerb5 code.

Why "in time" and not immediately? Are there platforms that don't
support the GSSAPI interface? If so, how would we ever retire the
old code?

regards, tom lane

Don't you want to maintain some interoperability between 8.2 client/
server and 8.3 server/client at least? If you put my patches in 8.3,
and they work as well as I hope, then "in time" could be as soon as
8.4, I suppose.

To answer the question more directly: I do not know of any platform
that supports the "native" Kerb5 API that doesn't also support GSSAPI
for the simple reason that a Kerberos-only version of GSSAPI has been
bundled with both the MIT and Heimdal distributions for as long as I
can remember.

On Apr 30, 2007, at 4:48 PM, Tom Lane wrote:

"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:

I tend to regard this as a comparable migration to the Kerb4 -> Kerb5
one. In time it should be a complete replacement. In time we will
be able to rip out the existing Kerb5 code.

Why "in time" and not immediately? Are there platforms that don't
support the GSSAPI interface? If so, how would we ever retire the
old code?

regards, tom lane

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

"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:

Don't you want to maintain some interoperability between 8.2 client/
server and 8.3 server/client at least?

Hm, you mean that what you called a C API change actually
break^H^H^H^H^Hchanges the on-the-wire protocol as well?
That sounds not very nice :-(

regards, tom lane

Yes, the wire protocol is different. Sorry. I can't help that.

As I said, I'm not adding any new functionality yet, just lots of
potential compatibility that isn't possible with the Kerberos API now
used. While there's no significant new functionality yet, at least
there's no regression either.

On Apr 30, 2007, at 5:56 PM, Tom Lane wrote:

"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:

Don't you want to maintain some interoperability between 8.2 client/
server and 8.3 server/client at least?

Hm, you mean that what you called a C API change actually
break^H^H^H^H^Hchanges the on-the-wire protocol as well?
That sounds not very nice :-(

regards, tom lane

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

Tom Lane wrote:

"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:

Don't you want to maintain some interoperability between 8.2 client/
server and 8.3 server/client at least?

Hm, you mean that what you called a C API change actually
break^H^H^H^H^Hchanges the on-the-wire protocol as well?
That sounds not very nice :-(

It's a completely new authentication method, that just happens to use
Kerberos underneath it. And it uses the API/wireprotocol that's
recommended by the Kerberos folks. And in fact when talking to the MIT
folks back when I found that security issue two years back it seems
we're more or less the only ones other than sample apps taht use the
"native api".

Fact is that the way we do it now is not very "pretty". The GSSAPI way
lets PostgreSQL handle sending/receiving and wrapping in whatever we
want, whereas the current method we just pass in the socket. I think in
a lot of ways it's just pure luck that it works reasonably well
alongside OpenSSL for example.

I think the correct path is to put it in GSSAPI and deprecate krb5 for
at least one release, and then get rid of krb5 completely.

Oh, and I do think putting in GSSAPI authentication only (and not
encryption) is the way to go for now, since we can do encryption with
OpenSSL. It'll make the changes localized to just the authentication.

//Magnus

Henry B. Hotz wrote:

OK, so posted. ;-)

<snip>

Would you like a new version of the patch with the incomplete
functionality commented out (or otherwise removed)?

Yes please :-) I was going to try to do one of those myself, but since
you already know your way around the code, please do it. And please go
for removing it alltogether instead of just commenting it out - it's in
the list archives and can be referred to there if/when we want to add it
back in.

I'd also vote for changing the name of the "non encrypted" version to
just "gss" instead of "gss-np".

//Magnus

On May 1, 2007, at 1:16 AM, Magnus Hagander wrote:

Henry B. Hotz wrote:

OK, so posted. ;-)

<snip>

Would you like a new version of the patch with the incomplete
functionality commented out (or otherwise removed)?

Yes please :-) I was going to try to do one of those myself, but since
you already know your way around the code, please do it. And please go
for removing it alltogether instead of just commenting it out -
it's in
the list archives and can be referred to there if/when we want to
add it
back in.

I can do that.

Could I ask you, or someone else, to look at what needs to happen to
configure? The way you capture `krb5-config --libs gssapi` into a
variable is completely different in BSD and GNU make, and I don't
know how to deal with that. (The configure logic for mod_auth_kerb
suffers from that problem, too.) The README.GSSAPI file in the patch
has reasonable notes, and it should be pretty simple otherwise.

I'd also vote for changing the name of the "non encrypted" version to
just "gss" instead of "gss-np".

I happen to disagree on this point. There are a whole class of
attacks that become possible if the encryption from the original
authentication exchange isn't used for the on-going channel
encryption/integrity. They may be impossible in practice, but how
many cans of worms do you want to deal with when you recommend a
"secure" configuration to an average admin? I would rather not hide
the distinction by changing the name that way.

Also, if I *do* get the buffering disentangled and create a working
"gss" mechanism, what would I call it if the name is already taken?
At that point it would become the recommended mechanism unless high-
volume performance made it impractical.

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

Magnus,

I'd also vote for changing the name of the "non encrypted" version to
just "gss" instead of "gss-np".

I don't. We'll want to support GSS encryption once we have the code, so we
should leave the namespace open to address that.

Oh, and I do think putting in GSSAPI authentication only (and not
encryption) is the way to go for now, since we can do encryption with
OpenSSL. It'll make the changes localized to just the authentication.

For now, yes. In the long run, we want to provide users with other methods
of encrypted connections than the rather flaky and
not-available-on-every-platform OpenSSL.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

Henry B. Hotz wrote:

On May 1, 2007, at 1:16 AM, Magnus Hagander wrote:

Henry B. Hotz wrote:

Would you like a new version of the patch with the incomplete
functionality commented out (or otherwise removed)?

Yes please :-) I was going to try to do one of those myself, but since
you already know your way around the code, please do it. And please go
for removing it alltogether instead of just commenting it out - it's in
the list archives and can be referred to there if/when we want to add it
back in.

I can do that.

Thanks!

Could I ask you, or someone else, to look at what needs to happen to
configure? The way you capture `krb5-config --libs gssapi` into a
variable is completely different in BSD and GNU make, and I don't know
how to deal with that. (The configure logic for mod_auth_kerb suffers
from that problem, too.) The README.GSSAPI file in the patch has
reasonable notes, and it should be pretty simple otherwise.

I'll leave the autoconf-fu to someone else if possible, but I can look
at it later if nobody does (will look at the rest too).

The docs need to be moved from README into the proper docs as well, but
I can take care of that once the code is settled.

I'd also vote for changing the name of the "non encrypted" version to
just "gss" instead of "gss-np".

I happen to disagree on this point. There are a whole class of attacks
that become possible if the encryption from the original authentication
exchange isn't used for the on-going channel encryption/integrity. They
may be impossible in practice, but how many cans of worms do you want to
deal with when you recommend a "secure" configuration to an average
admin? I would rather not hide the distinction by changing the name
that way.

Also, if I *do* get the buffering disentangled and create a working
"gss" mechanism, what would I call it if the name is already taken? At
that point it would become the recommended mechanism unless high-volume
performance made it impractical.

I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think
that's a lot more clear than "gss-np" (something ending with -sec is a
giveaway)

But I won't fight for it, it's not that important to me :-)

(And whether it's recommended or not depends on the environment - there
are a cases where it's just unnecessary to add it. Say if you're
employing ipsec across your network, adding a second layer of encryption
will just make things slower for no gain - and it makes things more
complex. Even if you're not talking high volume.)

//Magnus

Josh Berkus wrote:

Magnus,

I'd also vote for changing the name of the "non encrypted" version to
just "gss" instead of "gss-np".

I don't. We'll want to support GSS encryption once we have the code, so we
should leave the namespace open to address that.

I agree that we should do this, I'm just suggesting different names,
namely "gss" and "gss-sec".

Oh, and I do think putting in GSSAPI authentication only (and not
encryption) is the way to go for now, since we can do encryption with
OpenSSL. It'll make the changes localized to just the authentication.

For now, yes. In the long run, we want to provide users with other methods
of encrypted connections than the rather flaky and
not-available-on-every-platform OpenSSL.

Certainly. I'm talking short-term when I say that.

When we eventually do -sec, it might be worthwhile to consider that in
the context of the GnuTLS patches that were thrown around earlier -
maybe something can be done for both of them, so we don't get a hugely
expanded codebase.

//Magnus

Josh Berkus wrote:

Magnus,

I'd also vote for changing the name of the "non encrypted" version to
just "gss" instead of "gss-np".

I don't. We'll want to support GSS encryption once we have the code, so we
should leave the namespace open to address that.

Oh, and I do think putting in GSSAPI authentication only (and not
encryption) is the way to go for now, since we can do encryption with
OpenSSL. It'll make the changes localized to just the authentication.

For now, yes. In the long run, we want to provide users with other methods
of encrypted connections than the rather flaky and
not-available-on-every-platform OpenSSL.

I'm curious - on what platform is OpenSSL NOT available ?

Stefan

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:

Josh Berkus wrote:

For now, yes. In the long run, we want to provide users with other methods
of encrypted connections than the rather flaky and
not-available-on-every-platform OpenSSL.

I'm curious - on what platform is OpenSSL NOT available ?

And even more curious to see you defend that offhanded bashing of OpenSSL,
a tool a whole lot of people (including me) depend on all day every day.
If Postgres had the market penetration of OpenSSL, our lives would be a
lot different. Have you got even a shred of evidence that GSSAPI is
more stable than OpenSSL?

regards, tom lane

Magnus Hagander <magnus@hagander.net> writes:

I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think
that's a lot more clear than "gss-np" (something ending with -sec is a
giveaway)

+1

regards, tom lane

Tom,

And even more curious to see you defend that offhanded bashing of
OpenSSL, a tool a whole lot of people (including me) depend on all day
every day. If Postgres had the market penetration of OpenSSL, our lives
would be a lot different. Have you got even a shred of evidence that
GSSAPI is more stable than OpenSSL?

Short answer:
Existing Kerberos libs with GSSAPI may have the same issues; I don't know.
What I was speaking in favor of was having several encryption mechanisms
available so that at least one of them would be available on the user's
system at installation time. For that matter, I think we should support
Gnu-TLS if someone offers us a patch.

Long Answer:
I've been dealing with OpenSSL binary incompatibility issues for the last
few Solaris builds and it's made me very unhappy with the
upgrade/versioning/linking of OpenSSL, and explained a lot of issues I've
had around using OpenSSL with PostgreSQL and Apache previously. That is,
0.9.8 isn't always backwards compatible to 0.9.7 or 0.9.6, making
applications built against one version of OpenSSL not necessarily portable
or easily upgraded, and causing a lot of installation-related pain.

(yes, I know this describes PostgreSQL as well. People complain about it
all the time to us, and they're right)

When you combine that with the platform providers (like Novell, Sun and RH)
treating OpenSSL as if there were no upgrade issues (even though there
are), or being version-specific but not providing packages for other
versions, you end up with a situation where a lot of users can't actually
use OpenSSL on their system without ripping out a bunch of libraries and
replacing them with compatible versions. I've had this issue on SuSE,
Solaris, and OSX at different times.

The OpenSSL team appears to be is very aware of these issues, which is why
Richard Levitte started the OpenTLS project (www.opentls.org) as a
successor to OpenSSL, where the issues are apparently insoluable
9http://marc.info/?l=openssl-dev&amp;m=113042556401979&amp;w=2). OpenSSL has also
added a stronger EVP_API and some versioning of symbols in the most recent
release, but that won't help most of our users for a while until 0.9.6 and
0.9.7 dissapear from userspace.

Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

On May 1, 2007, at 1:33 PM, Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> writes:

I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think
that's a lot more clear than "gss-np" (something ending with -sec
is a
giveaway)

+1

If we settle on gss-np and gss-sec is that a good compromise?

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

Josh Berkus wrote:

Tom,

And even more curious to see you defend that offhanded bashing of
OpenSSL, a tool a whole lot of people (including me) depend on all day
every day. If Postgres had the market penetration of OpenSSL, our lives
would be a lot different. Have you got even a shred of evidence that
GSSAPI is more stable than OpenSSL?

Short answer:
Existing Kerberos libs with GSSAPI may have the same issues; I don't know.
What I was speaking in favor of was having several encryption mechanisms
available so that at least one of them would be available on the user's
system at installation time. For that matter, I think we should support
Gnu-TLS if someone offers us a patch.

IIRC we had a gnutls patch offered, but rejected.

Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.

How long ago did you check? I've been using OpenSSL on windows for many
years. Actually, it was supported just fine on Windows back when it was
added to PostgreSQL *at least*.

//Magnus

Henry B. Hotz wrote:

On May 1, 2007, at 1:33 PM, Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> writes:

I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think
that's a lot more clear than "gss-np" (something ending with -sec is a
giveaway)

+1

If we settle on gss-np and gss-sec is that a good compromise?

I still think the "-np" part is unclear - it's not "easily guessable
without reading the documentation", unless you're already familiar with it.

//Magnus

On May 1, 2007, at 2:30 PM, Magnus Hagander wrote:

Henry B. Hotz wrote:

On May 1, 2007, at 1:33 PM, Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> writes:

I would call them "gss" and "gss-sec". Or possibly "gss-enc". I
think
that's a lot more clear than "gss-np" (something ending with -
sec is a
giveaway)

+1

If we settle on gss-np and gss-sec is that a good compromise?

I still think the "-np" part is unclear - it's not "easily guessable
without reading the documentation", unless you're already familiar
with it.

//Magnus

gss-noprot and gss-prot

gss-noenc and gss-enc

??

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

On May 1, 2007, at 1:32 PM, Tom Lane wrote:

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:

Josh Berkus wrote:

For now, yes. In the long run, we want to provide users with
other methods
of encrypted connections than the rather flaky and
not-available-on-every-platform OpenSSL.

I'm curious - on what platform is OpenSSL NOT available ?

And even more curious to see you defend that offhanded bashing of
OpenSSL,
a tool a whole lot of people (including me) depend on all day every
day.
If Postgres had the market penetration of OpenSSL, our lives would
be a
lot different. Have you got even a shred of evidence that GSSAPI is
more stable than OpenSSL?

regards, tom lane

Windows? I don't do Windows, so I'm guessing.

If you accept that Microsoft's SSPI is a flavor of GSSAPI, then
GSSAPI is more widely supported and probably more stable on Windows
machines than OpenSSL is.

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

Josh Berkus <josh@agliodbs.com> writes:

Long Answer:
I've been dealing with OpenSSL binary incompatibility issues for the last
few Solaris builds and it's made me very unhappy with the
upgrade/versioning/linking of OpenSSL, and explained a lot of issues I've
had around using OpenSSL with PostgreSQL and Apache previously. That is,
0.9.8 isn't always backwards compatible to 0.9.7 or 0.9.6, making
applications built against one version of OpenSSL not necessarily portable
or easily upgraded, and causing a lot of installation-related pain.

(yes, I know this describes PostgreSQL as well. People complain about it
all the time to us, and they're right)

Indeed, but I dunno why you think things will be all magically better
in GSSAPI-land. What I foresee as more likely is that we'll just be
opening up another front in the versioning war.

regards, tom lane

Henry B. Hotz wrote:

I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think
that's a lot more clear than "gss-np" (something ending with -sec is a
giveaway)

+1

If we settle on gss-np and gss-sec is that a good compromise?

I still think the "-np" part is unclear - it's not "easily guessable
without reading the documentation", unless you're already familiar
with it.

//Magnus

gss-noprot and gss-prot

gss-noenc and gss-enc

Those I like better. I still think it's unnecessary, but I won't object
to those :-)

//Magnus

Short answer:
Existing Kerberos libs with GSSAPI may have the same issues; I don't know.
What I was speaking in favor of was having several encryption mechanisms
available so that at least one of them would be available on the user's
system at installation time. For that matter, I think we should support
Gnu-TLS if someone offers us a patch.

IIRC we had a gnutls patch offered, but rejected.

That is correct. THere is a very long thread on it here:

http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php
http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php

Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.

How long ago did you check? I've been using OpenSSL on windows for many
years. Actually, it was supported just fine on Windows back when it was
added to PostgreSQL *at least*.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:

Windows? I don't do Windows, so I'm guessing.

If you accept that Microsoft's SSPI is a flavor of GSSAPI, then
GSSAPI is more widely supported and probably more stable on Windows
machines than OpenSSL is.

I can't speak to the situation on Windows either; if OpenSSL isn't
commonly used on Windows that may be a sufficient reason for supporting
GSSAPI too. I'm just unconvinced by any argument that suggests we'll
replace our SSL support with it.

regards, tom lane

Tom, Josh, Magnus.

I can't speak to the situation on Windows either; if OpenSSL isn't
commonly used on Windows that may be a sufficient reason for supporting
GSSAPI too. I'm just unconvinced by any argument that suggests we'll
replace our SSL support with it.

I can't imagine we will either. I think we should offer users choices,
within reason.

IIRC we had a gnutls patch offered, but rejected.

Darn, this happened while I was offline. I would have supported it. I
still think it's a good idea, pending patch quality.

Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.

How long ago did you check? I've been using OpenSSL on windows for many
years. Actually, it was supported just fine on Windows back when it was
added to PostgreSQL *at least*.

I didn't say *available for download*, I said *ship with*. That is, does a
Windows Vista Pro box from the factory come with OpenSSL on it? It does
come with Microsoft SSPI, although I don't know compatibility issues.

--
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.

How long ago did you check? I've been using OpenSSL on windows for many
years. Actually, it was supported just fine on Windows back when it was
added to PostgreSQL *at least*.

I didn't say *available for download*, I said *ship with*. That is, does a
Windows Vista Pro box from the factory come with OpenSSL on it? It does
come with Microsoft SSPI, although I don't know compatibility issues.

No, of course not. Microsoft OSes don't ship with *any* third party
software. So yeah, didn't get what you meant, and you do have a point
there. Provided the SSPI stuff actually does gssapi encryption - but
I'll trust the people who say it does. I've only ever used the
authentication parts myself.

//Magnus

On May 1, 2007, at 3:11 PM, Magnus Hagander wrote:

Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.

How long ago did you check? I've been using OpenSSL on windows
for many
years. Actually, it was supported just fine on Windows back when
it was
added to PostgreSQL *at least*.

I didn't say *available for download*, I said *ship with*. That
is, does a
Windows Vista Pro box from the factory come with OpenSSL on it?
It does
come with Microsoft SSPI, although I don't know compatibility issues.

No, of course not. Microsoft OSes don't ship with *any* third party
software. So yeah, didn't get what you meant, and you do have a point
there. Provided the SSPI stuff actually does gssapi encryption - but
I'll trust the people who say it does. I've only ever used the
authentication parts myself.

The SSPI has encryption and integrity functions, just like the
GSSAPI. I don't remember Jeffrey Altman's interop example code well
enough to say if he demonstrates that they interoperate as well.
Spending 5 seconds looking at it, the SSPI appears to make a
distinction between message and stream encryption that the GSSAPI
does not make, so there is at least some profiling needed to identify
what's common. I suspect that interoperability was intended. If we
find bugs and tell the right people Microsoft might even fix them
someday.

As to the question of GSSAPI vs SSL, I would never argue we don't
want both.

Part of what made the GSSAPI encryption mods difficult was my intent
to insert them "above" the SSL encryption/buffering layer. That way
you could double-encrypt the channel. Since GSSAPI and SSL are
(probably, not necessarily) referenced to completely different ID
infrastructure there are scenarios where that's beneficial.

(The other thing that made it hard is that I needed to make changes
in different places in the FE and the BE versions of libpq in order
to get the same effect.)

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

Magnus Hagander wrote:

Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.

How long ago did you check? I've been using OpenSSL on windows for many
years. Actually, it was supported just fine on Windows back when it was
added to PostgreSQL *at least*.

I didn't say *available for download*, I said *ship with*. That is, does a
Windows Vista Pro box from the factory come with OpenSSL on it? It does
come with Microsoft SSPI, although I don't know compatibility issues.

No, of course not. Microsoft OSes don't ship with *any* third party
software. So yeah, didn't get what you meant, and you do have a point
there. Provided the SSPI stuff actually does gssapi encryption - but
I'll trust the people who say it does. I've only ever used the
authentication parts myself.

I think it's largely irrelevant though - I can't see us shipping a
non-ssl enabled build now (thats not to say we wouldn't add SSPI support
of course).

/D

On Tue, May 01, 2007 at 04:26:13PM -0700, Henry B. Hotz wrote:

On May 1, 2007, at 3:11 PM, Magnus Hagander wrote:

Also, last I checked OpenSSL didn't ship with Windows and Kerberos
encryption did.

How long ago did you check? I've been using OpenSSL on windows
for many
years. Actually, it was supported just fine on Windows back when
it was
added to PostgreSQL *at least*.

I didn't say *available for download*, I said *ship with*. That
is, does a
Windows Vista Pro box from the factory come with OpenSSL on it?
It does
come with Microsoft SSPI, although I don't know compatibility issues.

No, of course not. Microsoft OSes don't ship with *any* third party
software. So yeah, didn't get what you meant, and you do have a point
there. Provided the SSPI stuff actually does gssapi encryption - but
I'll trust the people who say it does. I've only ever used the
authentication parts myself.

The SSPI has encryption and integrity functions, just like the
GSSAPI. I don't remember Jeffrey Altman's interop example code well
enough to say if he demonstrates that they interoperate as well.
Spending 5 seconds looking at it, the SSPI appears to make a
distinction between message and stream encryption that the GSSAPI
does not make, so there is at least some profiling needed to identify
what's common. I suspect that interoperability was intended. If we
find bugs and tell the right people Microsoft might even fix them
someday.

Ok. Well, that's for later.

As to the question of GSSAPI vs SSL, I would never argue we don't
want both.

Part of what made the GSSAPI encryption mods difficult was my intent
to insert them "above" the SSL encryption/buffering layer. That way
you could double-encrypt the channel. Since GSSAPI and SSL are
(probably, not necessarily) referenced to completely different ID
infrastructure there are scenarios where that's beneficial.

We might want to consider restructuring how SSL works when we do, that
might make it easier. The way it is now with #ifdefs all around can lead to
a horrible mess if there are too many different things to choose from.
Something like "transport filters" or whatever might be a way to do it. I
recall having looked at that at some point, but it was too long ago to
remember any details..

//Magnus

On May 2, 2007, at 3:11 AM, Magnus Hagander wrote:

As to the question of GSSAPI vs SSL, I would never argue we don't
want both.

Part of what made the GSSAPI encryption mods difficult was my intent
to insert them "above" the SSL encryption/buffering layer. That way
you could double-encrypt the channel. Since GSSAPI and SSL are
(probably, not necessarily) referenced to completely different ID
infrastructure there are scenarios where that's beneficial.

We might want to consider restructuring how SSL works when we do, that
might make it easier. The way it is now with #ifdefs all around can
lead to
a horrible mess if there are too many different things to choose from.
Something like "transport filters" or whatever might be a way to do
it. I
recall having looked at that at some point, but it was too long ago to
remember any details..

//Magnus

If someone wants to make it easier, that would be nice, I'm not up
for it, I don't think.

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