Re: JAVA Support

It appears that the JDBC client doesn't include the Kerberos support
that the C clients do.

So, two questions:

1) Is there an alternative JDBC client that's just a glue layer
instead of a complete re-implementation?

2) If I were willing to add a GSSAPI or SASL layer as an alternative
to the bare Krb 5 support would anyone be willing to help with the
supporting mods to the pg_hba.conf parsing, and configure?
------------------------------------------------------------------------
----
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 Thu, 28 Sep 2006, Henry B. Hotz wrote:

> It appears that the JDBC client doesn't include the Kerberos support
> that the C clients do.

Java doesn't have accessible Kerberos support. It wraps Kerberos in
GSSAPI which requires the server to support GSSAPI instead of plain
Kerberos.

> So, two questions:
>
> 1) Is there an alternative JDBC client that's just a glue layer instead of a
> complete re-implementation?

No, there aren't any Type 2 drivers around. Requiring native code is a
giant pain.

Kris Jurka

On Sep 28, 2006, at 10:52 AM, Kris Jurka wrote:

>
>
> On Thu, 28 Sep 2006, Henry B. Hotz wrote:
>
>> It appears that the JDBC client doesn't include the Kerberos
>> support that the C clients do.
>
> Java doesn't have accessible Kerberos support. It wraps Kerberos
> in GSSAPI which requires the server to support GSSAPI instead of
> plain Kerberos.

Looks like Kerberos is the only GSSAPI mechanism supported in Java.
OK by me, but that's not the point of the standard (or the SASL
standard).

>> So, two questions:
>>
>> 1) Is there an alternative JDBC client that's just a glue layer
>> instead of a complete re-implementation?
>
> No, there aren't any Type 2 drivers around. Requiring native code
> is a giant pain.
>
> Kris Jurka

Requiring JAVA support for everything you can do with C is also a
pain, isn't it? (This incompatibility being an example.)

I take it you're not volunteering to help with my second request. ;-)

------------------------------------------------------------------------
----
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 Thu, 28 Sep 2006, Henry B. Hotz wrote:

> I take it you're not volunteering to help with my second request. ;-)
>

I would if we could get some -hackers buy in on the idea. Adding more and
more auth methods is something they're not excited about unless there's a
good reason (which I think this is).

Kris Jurka

> 2) If I were willing to add a GSSAPI or SASL layer as an
> alternative to the bare Krb 5 support would anyone be willing
> to help with the supporting mods to the pg_hba.conf parsing,
> and configure?

Sure, I can help out with that. I've done a bunch of work on the current
kerberos stuff (tohugh I'm by no means the author) in order to make it
work on win32, so I have a little bit of a clue around that code ATM.

As for the other part - will core accept this - I can't answer that. I
do beleive that there is a point to it, given that Java will then
support it natively, but I'm not core. I'm unsure if there is a clear
view on the merits of adding more authentication options..

//Magnus

On Sep 28, 2006, at 12:42 PM, Magnus Hagander wrote:

>> 2) If I were willing to add a GSSAPI or SASL layer as an
>> alternative to the bare Krb 5 support would anyone be willing
>> to help with the supporting mods to the pg_hba.conf parsing,
>> and configure?
>
> Sure, I can help out with that. I've done a bunch of work on the
> current
> kerberos stuff (tohugh I'm by no means the author) in order to make it
> work on win32, so I have a little bit of a clue around that code ATM.
>
> As for the other part - will core accept this - I can't answer that. I
> do beleive that there is a point to it, given that Java will then
> support it natively, but I'm not core. I'm unsure if there is a clear
> view on the merits of adding more authentication options..

From the lack of traffic on this list I gather that the core
developers no longer hang out here. I've been gone for a few years.

For the record here's the arguments:

SASL is a "standards track RFC" (I saw those snide comments in the
record, Mr. Lane ;-) which allows you to plug in authentication
mechanisms, much like PAM allows you to plug in password checkers.
It is well adopted, since it forms the basis of most email protocols'
authentication, as well as LDAP and Jabber.

SASL provides a unified way for code to support all the
authentication options you're likely to want.

a) In the absence of OS-provided SASL libraries a simple password-
checking mechanism could be implemented as a wire-compatible fallback
with less code than the framework would take. (I won't write this,
but you could probably steal code from jabberd.)

b) SASL includes simple password checking mechanisms. In principle
we could use these to check the local postgres passwords. Not sure
how much customization that would require.

c) If you are using SSL/TLS for client/server connections (or it's a
local on-machine connection) you can use the SASL_EXTERNAL mechanism
to pick up the identity from the connection, without imposing extra
overhead.

d) SASL includes enterprise-class authentication support, such as
GSSAPI (and Kerberos via GSSAPI). If an enterprise has some unique
authentication infrastructure it can be implemented as a SASL (or
GSSAPI) plug-in without the need to customize PostgreSQL.

e) After the initial connection, SASL can be configured to run the
connection fully encrypted, integrity protected, or unprotected.

f) SASL support is available in current Java as well as C. SASL
libraries are included (or at least loadable) on MacOS, Solaris 10+,
and Linux. (I don't do windows, so I can't say there.) While it has
a reputation for complexity, that complexity is in building the
libraries, not in using them.

It can be used to provide most (all?) of the functionality now
provided by the assortment of existing mechanisms. If provided as an
alternative, it could eventually allow decommissioning of a lot of
the other mechanisms. If the number of existing mechanisms is an
issue, then this could be a big long-term win.

I'll assume the ball is in my court now, unless someone wants to
claim I should just do GSSAPI and not bother with the higher level.
------------------------------------------------------------------------
----
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

> > As for the other part - will core accept this - I can't
> answer that. I
> > do beleive that there is a point to it, given that Java will then
> > support it natively, but I'm not core. I'm unsure if there
> is a clear
> > view on the merits of adding more authentication options..
>
> From the lack of traffic on this list I gather that the core
> developers no longer hang out here. I've been gone for a few years.

Oh, they most definitly do. Every one of them. They just don't write in
every single thread (though sometimes I wonder about Tom..)

I noticed you copied Tom Lockhart - he isn't core anymore, so don't
expect a response there. Tom Lane is, though, and I'm sure he'll
respond.

> For the record here's the arguments:
<snip a bunch of SASL arguments that I'm sure are perfectly valid>

> f) SASL support is available in current Java as well as C.
> SASL libraries are included (or at least loadable) on MacOS,
> Solaris 10+, and Linux. (I don't do windows, so I can't say
> there.) While it has a reputation for complexity, that
> complexity is in building the libraries, not in using them.
>
> It can be used to provide most (all?) of the functionality
> now provided by the assortment of existing mechanisms.

Well, it's still a complexity you need to deal with. Plus, just Java and
C is far from enough, if you are intending to suggest we replace some of
what we have now with it (like passwords and other such things). For
example, you need things like perl, python, ruby, C#, etc etc. not sure
how many of those would be fine with a C wrapper, I know for a fact that
C# (or other .net languages) wouldn't, they need it natively.

There also used to be some bad portability issues wrt at least some of
the SASL libraries (if there is more than one). I know I tried to make
it work on win32 once and failed miserably. (Then again, I've failed on
Linux as well, but not quite as bad. And it's not included in all Linux
distributions, at least it wasn't when I checked a while back)

And finally, there's backwards compatibility. We're still going to have
to support all the existing ones for the forseeable future unless you
want to prevent all older clients from connecting (hint: you don't).

> If provided as an alternative, it could eventually allow
> decommissioning of a lot of the other mechanisms. If the
> number of existing mechanisms is an issue, then this could be
> a big long-term win.

Me, I think providing it as an alternative is the path to go. Which also
means that I think implementing GSSAPI for that (probably in long-term
to *replace* our current Kerberos authentication, in short-term to
complement it) rather than SASL, because it's significantly simpler.

> I'll assume the ball is in my court now, unless someone wants
> to claim I should just do GSSAPI and not bother with the higher level.

That would be my suggestion - do GSSAPI only and leave the current
methods the way they are. This should be doable without a huge amount of
code, and without affecting the other well-working mechanisms.

//Magnus

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> As for the other part - will core accept this - I can't answer that.

It would depend in part on the size of the patch, and on whether there
are any arguments for supporting GSSAPI besides "Java can't do Kerberos".
What would it buy for a libpq user?

regards, tom lane

> > As for the other part - will core accept this - I can't answer that.
>
> It would depend in part on the size of the patch, and on
> whether there are any arguments for supporting GSSAPI besides
> "Java can't do Kerberos".
> What would it buy for a libpq user?

I don't know, really ;-) It seems we're fairly alone in *not* doing
GSSAPI (given for example the MIT Kerberos bug I uncovered when working
on it, that was at the very core of the codepath we're using, which
shows that others arne't using that). We'd be using a much better tested
code, I think.

It *may* be that life on win32 would be much easier, given that Windows
SSPI is supposed to be compatible with GSSAPI when used in the right
way. I don't know any details about this, though. If it does, it would
likely make life easier for .NET applications as well, not just Java.

I'll leave it to Henry to add some more arguments :-)

//Magnus

Kris,

> I would if we could get some -hackers buy in on the idea. Adding
> more and more auth methods is something they're not excited about
> unless there's a good reason (which I think this is).

Actually, I've been trying to get some of the Sun engineers to
contribute patches for Solaris authentication methods, of which GSSAPI
is one. So in theory someone from Sun should be looking at coding
this.

Josh Berkus
PostgreSQL @ Sun
San Francisco 415-752-2500

Tom,

> It would depend in part on the size of the patch, and on whether
> there
> are any arguments for supporting GSSAPI besides "Java can't do
> Kerberos".
> What would it buy for a libpq user?

According to the Solaris Security engineers, GSSAPI is more secure than
using the Kerberos headers. Also, in theory GSSAPI is supposed to
support multiple authentication back-ends (ldap, liberty, etc.), but I
personally have never seen support for anything but Kerberos.

Josh Berkus
PostgreSQL @ Sun
San Francisco 415-752-2500

On Sep 28, 2006, at 2:24 PM, Tom Lane wrote:

> "Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
>> As for the other part - will core accept this - I can't answer that.
>
> It would depend in part on the size of the patch, and on whether there
> are any arguments for supporting GSSAPI besides "Java can't do
> Kerberos".
> What would it buy for a libpq user?

Everything that the current Kerberos support provides plus Java.

Ability to encrypt or integrity protect the client/server connection
(without SSL/TLS tunnels).

In theory, you get to plug in other mechanisms than Kerberos. In
practice I think this only worked on Solaris, until very recently.
The free gssapi implementations in Java, Solaris, MIT Kerberos, and
Heimdal Kerberos only supported Kerberos. Sun open sourced their
mechanism glue code and it's being incorporated into both MIT (now)
and Heimdal (0.8). Entrust sells a PKI mechanism for Solaris.

Wire compatibility with a native Windows API (the SSPI), if it's used
correctly. (Google for posts by Jeffrey Altman for references to
example code.)
------------------------------------------------------------------------
----
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

I cc'ed Tom Lockhart because he *used* to be core, and I know where
he works. No response expected.

On Sep 28, 2006, at 2:11 PM, Magnus Hagander wrote:

>> f) SASL support is available in current Java as well as C.
>> SASL libraries are included (or at least loadable) on MacOS,
>> Solaris 10+, and Linux. (I don't do windows, so I can't say
>> there.) While it has a reputation for complexity, that
>> complexity is in building the libraries, not in using them.
>>
>> It can be used to provide most (all?) of the functionality
>> now provided by the assortment of existing mechanisms.
>
> Well, it's still a complexity you need to deal with. Plus, just
> Java and
> C is far from enough, if you are intending to suggest we replace
> some of
> what we have now with it (like passwords and other such things). For
> example, you need things like perl, python, ruby, C#, etc etc. not
> sure
> how many of those would be fine with a C wrapper, I know for a fact
> that
> C# (or other .net languages) wouldn't, they need it natively.

OK, point taken. OTOH how many of those have GSSAPI support? I
don't know, but I'd guess that only going as far as GSSAPI gets you
C# (and .net), and Java of course. Perl probably isn't a big deal
just using glue for either SASL or GSSAPI. Python and Ruby I don't
know.

> There also used to be some bad portability issues wrt at least some of
> the SASL libraries (if there is more than one).

There's more than one, since the Java one is different from Cyrus.
I've seen references to others, but I think they qualify as
"obscure". The Sun one is related to Cyrus.

> I know I tried to make
> it work on win32 once and failed miserably. (Then again, I've
> failed on
> Linux as well, but not quite as bad. And it's not included in all
> Linux
> distributions, at least it wasn't when I checked a while back)

Well, I know Redhat has RPM's that look reasonable. I'm not a big
Linux user myself. (More a BSD bigot, to be honest.)

> And finally, there's backwards compatibility. We're still going to
> have
> to support all the existing ones for the forseeable future unless you
> want to prevent all older clients from connecting (hint: you don't).

No question. Just a thought for the future.

------------------------------------------------------------------------
----
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 Sep 28, 2006, at 3:01 PM, Josh Berkus wrote:

> Kris,
>
>> I would if we could get some -hackers buy in on the idea. Adding
>> more and more auth methods is something they're not excited about
>> unless there's a good reason (which I think this is).
>
> Actually, I've been trying to get some of the Sun engineers to
> contribute patches for Solaris authentication methods, of which GSSAPI
> is one. So in theory someone from Sun should be looking at coding
> this.

Sun demonstrated that you could build the existing Kerberos support
with the current Solaris 11 beta's. They opened the "native" MIT
Kerberos API for outside use.

See posts on the [ports] list.
------------------------------------------------------------------------
----
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 Sep 28, 2006, at 3:03 PM, Josh Berkus wrote:

> Tom,
>
>> It would depend in part on the size of the patch, and on whether
>> there
>> are any arguments for supporting GSSAPI besides "Java can't do
>> Kerberos".
>> What would it buy for a libpq user?
>
> According to the Solaris Security engineers, GSSAPI is more secure
> than
> using the Kerberos headers. Also, in theory GSSAPI is supposed to
> support multiple authentication back-ends (ldap, liberty, etc.), but I
> personally have never seen support for anything but Kerberos.

I think that GSSAPI is more tolerant of connections through NAT's. I
think it's more robust to current network reality, but I'm not aware
it's actually more secure if you're using comparable verification
options.

As noted elsewhere on this thread it's more available.

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

> Sun demonstrated that you could build the existing Kerberos support
> with the current Solaris 11 beta's. They opened the "native" MIT
> Kerberos API for outside use.

Yes, and this will be available via the supported version in Solaris 10 Update
4.

However, that doesn't change that some people would like us to support GSSAPI,
and there may be some benefit (additional applications, better network
authentication, etc.) for doing so. If we can get additional programmers to
code the support (i.e. Sun, JPL) I don't see any reason not to support the
*additional* authentication methods.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> However, that doesn't change that some people would like us to support
> GSSAPI, and there may be some benefit (additional applications, better
> network authentication, etc.) for doing so. If we can get additional
> programmers to code the support (i.e. Sun, JPL) I don't see any reason
> not to support the *additional* authentication methods.

Well, as I said already, a lot depends on the size of the patch.
As a reductio ad absurdum, if they drop 100K lines of code on us,
it *will* get rejected, no matter how cool it is.

The current Kerberos support seems to require about 50 lines in
configure.in and circa 200 lines of C code in each of the backend
and libpq. Plus a dependency on an outside library that happens
to be readily available and compatibly licensed.

What amount of code are we talking about adding here, and what
dependencies exactly? What portability and license hazards will
be added?

regards, tom lane

Josh Berkus wrote:
> Henry,
>
>> Sun demonstrated that you could build the existing Kerberos support
>> with the current Solaris 11 beta's. They opened the "native" MIT
>> Kerberos API for outside use.
>
> Yes, and this will be available via the supported version in Solaris 10 Update
> 4.
>
> However, that doesn't change that some people would like us to support GSSAPI,
> and there may be some benefit (additional applications, better network
> authentication, etc.) for doing so. If we can get additional programmers to
> code the support (i.e. Sun, JPL) I don't see any reason not to support the
> *additional* authentication methods.

Is there any reason why we haven't built a generic authentication API?
Something like PAM, except cross platform?

Joshua D. Drake

--

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

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> Is there any reason why we haven't built a generic authentication API?
> Something like PAM, except cross platform?

We're database geeks, not security/crypto/authentication geeks. What
makes you think we have any particular competence to do the above?

Actually, the part of this proposal that raised my hackles the most was
the claim that GSSAPI provides a generic auth API, because that was
exactly the bill of goods we were sold in connection with PAM. (So why
is this our problem at all --- can't you make a PAM plugin for it??)
It didn't help any that that was shortly followed by the lame admission
that no one has ever implemented anything except Kerberos underneath it.
Word to the wise, guys: go *real* soft on vaporware claims for auth
stuff, because we've seen enough of those before.

regards, tom lane

Tom Lane wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>> Is there any reason why we haven't built a generic authentication API?
>> Something like PAM, except cross platform?
>
> We're database geeks, not security/crypto/authentication geeks. What
> makes you think we have any particular competence to do the above?

Well that is a valid point :). I was just asking.
Joshua D. Drake

>
> Actually, the part of this proposal that raised my hackles the most was
> the claim that GSSAPI provides a generic auth API, because that was
> exactly the bill of goods we were sold in connection with PAM. (So why
> is this our problem at all --- can't you make a PAM plugin for it??)
> It didn't help any that that was shortly followed by the lame admission
> that no one has ever implemented anything except Kerberos underneath it.
> Word to the wise, guys: go *real* soft on vaporware claims for auth
> stuff, because we've seen enough of those before.
>
> regards, tom lane
>

--

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

> > I would if we could get some -hackers buy in on the idea. Adding
> more
> > and more auth methods is something they're not excited about
> unless
> > there's a good reason (which I think this is).
>
> Actually, I've been trying to get some of the Sun engineers to
> contribute patches for Solaris authentication methods, of which
> GSSAPI is one. So in theory someone from Sun should be looking at
> coding this.

Well, if they are, I hope they would be speaking up now, so work isn't
duplicated... So if you're out there, please speak up! ;-)

//Magnus

> > However, that doesn't change that some people would like us to
> support
> > GSSAPI, and there may be some benefit (additional applications,
> better
> > network authentication, etc.) for doing so. If we can get
> additional
> > programmers to code the support (i.e. Sun, JPL) I don't see any
> reason
> > not to support the *additional* authentication methods.
>
> Well, as I said already, a lot depends on the size of the patch.
> As a reductio ad absurdum, if they drop 100K lines of code on us,
> it *will* get rejected, no matter how cool it is.

Oh, absolutely.

> The current Kerberos support seems to require about 50 lines in
> configure.in and circa 200 lines of C code in each of the backend
> and libpq. Plus a dependency on an outside library that happens to
> be readily available and compatibly licensed.

I would expect, without looking at the details of the API, GSSAPI to be
about the same amount of code if not less.

> What amount of code are we talking about adding here, and what
> dependencies exactly? What portability and license hazards will be
> added?

The Kerberos5 libraries that we rely on today provide GSSAPI. So it
would work with the same external library. Now, it could *also* work
with other libraries in some cases (for example, the Win32 SSPI
libraries), but with the same libraries it should work fine.

//Magnus

This being SASL:

> > I know I tried to make
> > it work on win32 once and failed miserably. (Then again, I've
> failed
> > on Linux as well, but not quite as bad. And it's not included in
> all
> > Linux distributions, at least it wasn't when I checked a while
> back)
>
> Well, I know Redhat has RPM's that look reasonable. I'm not a big
> Linux user myself. (More a BSD bigot, to be honest.)

Well, Redhat != Linux, really :P

Over to GSSAPI:

> In theory, you get to plug in other mechanisms than Kerberos. In
> practice I think this only worked on Solaris, until very recently.

FWIW, Microsoft have supported NTLM over GSSAPI since.. eh. Back in
1999, I guess, with the first pre-releases of Windows 2000.

> Wire compatibility with a native Windows API (the SSPI), if it's
> used correctly. (Google for posts by Jeffrey Altman for references
> to example code.)

This, IMHO, is a big win if we can pull it off. It would significantly
lower the barrier for getting Kerberos working properly in pg on Win32.

//Magnus

On Sep 28, 2006, at 9:35 PM, Tom Lane wrote:

> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>> Is there any reason why we haven't built a generic authentication
>> API?
>> Something like PAM, except cross platform?
>
> We're database geeks, not security/crypto/authentication geeks. What
> makes you think we have any particular competence to do the above?
>
> Actually, the part of this proposal that raised my hackles the most
> was
> the claim that GSSAPI provides a generic auth API, because that was
> exactly the bill of goods we were sold in connection with PAM. (So
> why
> is this our problem at all --- can't you make a PAM plugin for it??)
> It didn't help any that that was shortly followed by the lame
> admission
> that no one has ever implemented anything except Kerberos
> underneath it.
> Word to the wise, guys: go *real* soft on vaporware claims for auth
> stuff, because we've seen enough of those before.

Well, that's why I was pushing SASL instead of GSSAPI. There are
multiple mechanisms that are actually in use.

PAM turned out not to be sufficiently specified for cross-platform
behavioral compatibility, and it only does password checking anyway.
Calling it a security solution is a big overstatement IMO. I guess a
lot of people use PAM with SSL and don't worry about the gap between
the two (which SASL or GSSAPI close).

In defense of GSSAPI non-Kerberos mechanisms do exist. They just
cost money and they aren't very cross-platform. AFAIK GSSAPI has no
simple password mechanisms.

There's a Microsoft-compatible SPNEGO mechanism for GSSAPI that's
being implemented fairly widely now, but it's just a sub-negotiation
mech that lets you choose between a Kerberos 5 (that's practically
identical to the direct one), and NTLM. If you allow NTLM you'd
better limit it to NTLMv2!

------------------------------------------------------------------------
----
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 Sep 29, 2006, at 12:31 AM, Magnus Hagander wrote:

>>> However, that doesn't change that some people would like us to
>> support
>>> GSSAPI, and there may be some benefit (additional applications,
>> better
>>> network authentication, etc.) for doing so. If we can get
>> additional
>>> programmers to code the support (i.e. Sun, JPL) I don't see any
>> reason
>>> not to support the *additional* authentication methods.
>>
>> Well, as I said already, a lot depends on the size of the patch.
>> As a reductio ad absurdum, if they drop 100K lines of code on us,
>> it *will* get rejected, no matter how cool it is.
>
> Oh, absolutely.
>
>
>> The current Kerberos support seems to require about 50 lines in
>> configure.in and circa 200 lines of C code in each of the backend
>> and libpq. Plus a dependency on an outside library that happens to
>> be readily available and compatibly licensed.
>
> I would expect, without looking at the details of the API, GSSAPI
> to be
> about the same amount of code if not less.

Probably save some Kerberos bookkeeping. Probably loose it with
GSSAPI bookkeeping, including name translation (which is far less
obvious). Net, I would expect to lose, but not by very much.

>> What amount of code are we talking about adding here, and what
>> dependencies exactly? What portability and license hazards will be
>> added?
>
> The Kerberos5 libraries that we rely on today provide GSSAPI. So it
> would work with the same external library. Now, it could *also* work
> with other libraries in some cases (for example, the Win32 SSPI
> libraries), but with the same libraries it should work fine.
>
> //Magnus

If I had a lot of time to spend on this I would write a SASL-like
wrapper so it could be used on platforms with GSSAPI, but not SASL
support in the OS. As you may have noticed, I believe SASL is the
way to go. I'm not up for it though.

There's probably room in the world for a "SASL-lite" library though.
Cyrus is great, but if your OS doesn't supply it for you, it's
supposed to be really hard to build.

------------------------------------------------------------------------
----
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 wrote:
> Well, that's why I was pushing SASL instead of GSSAPI. There are
> multiple mechanisms that are actually in use.
>
> PAM turned out not to be sufficiently specified for cross-platform
> behavioral compatibility, and it only does password checking anyway.
> Calling it a security solution is a big overstatement IMO. I guess a
> lot of people use PAM with SSL and don't worry about the gap between
> the two (which SASL or GSSAPI close).
>
> In defense of GSSAPI non-Kerberos mechanisms do exist. They just
> cost money and they aren't very cross-platform. AFAIK GSSAPI has no
> simple password mechanisms.
>
> There's a Microsoft-compatible SPNEGO mechanism for GSSAPI that's
> being implemented fairly widely now, but it's just a sub-negotiation
> mech that lets you choose between a Kerberos 5 (that's practically
> identical to the direct one), and NTLM. If you allow NTLM you'd
> better limit it to NTLMv2!

As already mentioned, the limitations of PAM weren't clear until after
we implemented it, so I expect the same to happen here, and the number
of acronyms flying around in this discussion is a bad sign too.

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

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