Design Considerations for New Authentication Methods

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

I notice that all the
authentication (pg_fe_sendauth()) is done inside PWConnectPoll(),
which sounds like something that isn't expected to block on network
access.

That's right.

Is this behavior important during startup?

You needn't bother to submit a patch that breaks it ;-). But I don't
really see that it's such a big deal. You just need some state data to
keep track of what to do the next time you receive a message. There's
no assumption anywhere that authentication only involves one message
exchange.

I haven't looked at the corresponding logic on the server side, but
I'd assume that it forks before we get to this point so it doesn't
matter.

Correct, we don't need to worry about multitasking apps there.

regards, tom lane

On Oct 31, 2006, at 8:34 PM, Tom Lane wrote:

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

I notice that all the
authentication (pg_fe_sendauth()) is done inside PWConnectPoll(),
which sounds like something that isn't expected to block on network
access.

That's right.

Is this behavior important during startup?

You needn't bother to submit a patch that breaks it ;-).

In other words I can't do the easy thing. OK.

But I don't
really see that it's such a big deal. You just need some state
data to
keep track of what to do the next time you receive a message. There's
no assumption anywhere that authentication only involves one message
exchange.

In a sense you're right. The API's are designed to support that.
Means I need to some more cases to the huge switch statement inside
PWConnectPoll() though.

I haven't looked at the corresponding logic on the server side, but
I'd assume that it forks before we get to this point so it doesn't
matter.

Correct, we don't need to worry about multitasking apps there.

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

I've been looking at adding SASL or GSSAPI as an auth method. I have
some questions about how to handle the flow of control changes.

Great! I'd love to see that implemented, personally, so if you're
looking for help, please let me know.

round trips and network accesses done. I notice that all the
authentication (pg_fe_sendauth()) is done inside PWConnectPoll(),
which sounds like something that isn't expected to block on network
access.

I think you're missing a bit about how the design works.
PGConnectPoll() is expected to be called multiple times until the
connection is established. Basically, you can return something to the
user that says "connection not done yet, but I'm returning because you
said to not block. Please call again when more data available or you
have the opportunity to". This is a pretty common arrangment when
non-blocking systems are implemented. As Tom said, you should just need
to have some state stored so that you know what's going on when you're
called again.

Thanks!

Stephen

On Nov 1, 2006, at 6:33 AM, Stephen Frost wrote:

* Henry B. Hotz (hotz@jpl.nasa.gov) wrote:

I've been looking at adding SASL or GSSAPI as an auth method. I have
some questions about how to handle the flow of control changes.

Great! I'd love to see that implemented, personally, so if you're
looking for help, please let me know.

Thank you. I will! ;-)

Do you know Java? I'm doing this ultimately because I want the JDBC
driver to support encrypted connections with Kerberos and without
needing SSL. As an added plus a Windows-native client should support
it.

My main hesitation between SASL and GSSAPI is that the Windows
equivalent APIs for SASL have not received the same degree of
interoperability testing as SSPI<-->GSSAPI. I don't have a published
example to crib from. For general information the relevant calls are
at the bottom of <http://msdn.microsoft.com/library/default.asp?url=/
library/en-us/secauthn/security/authentication_functions.asp>.

"I don't do windows (TM)." ;-)

round trips and network accesses done. I notice that all the
authentication (pg_fe_sendauth()) is done inside PWConnectPoll(),
which sounds like something that isn't expected to block on network
access.

I think you're missing a bit about how the design works.
PGConnectPoll() is expected to be called multiple times until the
connection is established.

I think I got it. I just didn't want to get it.

I'll probably do the simple, blocking-loop client anyway as a way to
debug the server side. Then worry about getting the clients up to
snuff.

Basically, you can return something to the
user that says "connection not done yet, but I'm returning because you
said to not block. Please call again when more data available or you
have the opportunity to". This is a pretty common arrangment when
non-blocking systems are implemented. As Tom said, you should just
need
to have some state stored so that you know what's going on when you're
called again.

Once I start adding connection state I can add a control for whether
data packets need to be wrapped as well. I'm not sure how hard the

8KB case will be to handle though. Probably some hooks in the

underlying library, and I hope they make it easier rather than harder.

Thanks!

Stephen

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

I've been looking at adding SASL or GSSAPI as an auth

method. I have

some questions about how to handle the flow of control changes.

Great! I'd love to see that implemented, personally, so if you're
looking for help, please let me know.

Thank you. I will! ;-)

Do you know Java? I'm doing this ultimately because I want
the JDBC driver to support encrypted connections with
Kerberos and without needing SSL. As an added plus a
Windows-native client should support it.

Interesting, I thought you were going for the authentication only.
What's the real gain in doing Kerberos encryption over SSL encryption?
Doesn't Java come with SSL support anyway these days?

My main hesitation between SASL and GSSAPI is that the
Windows equivalent APIs for SASL have not received the same
degree of interoperability testing as SSPI<-->GSSAPI. I
don't have a published example to crib from. For general
information the relevant calls are at the bottom of
<http://msdn.microsoft.com/library/default.asp?url=/
library/en-us/secauthn/security/authentication_functions.asp>.

One reason for this could be that they appear to be available only on
server platforms, and not on cilents, if you look at the documentation.
That said, I have the DLL file and the export functions on my XP
machine, so it's definitly present there - I'm unsure if it *works* or
is supported. My registry does indicate that I have the GSSAPI profile
for SASL, which would be an indication that it should.

//Magnus

On Nov 2, 2006, at 1:18 AM, Magnus Hagander wrote:

Sorry about the premature send.

On Nov 2, 2006, at 1:18 AM, Magnus Hagander wrote:

* Henry B. Hotz (hotz@jpl.nasa.gov) wrote:

I've been looking at adding SASL or GSSAPI as an auth

method. I have

some questions about how to handle the flow of control changes.

Great! I'd love to see that implemented, personally, so if you're
looking for help, please let me know.

Thank you. I will! ;-)

Do you know Java? I'm doing this ultimately because I want
the JDBC driver to support encrypted connections with
Kerberos and without needing SSL. As an added plus a
Windows-native client should support it.

Interesting, I thought you were going for the authentication only.
What's the real gain in doing Kerberos encryption over SSL encryption?
Doesn't Java come with SSL support anyway these days?

Well, unless you have an unusually good PKI infrastructure, SSL
doesn't provide any cryptographic connection between the client
identity and the data received by the server. (At least that's true
for the way it's used by Web browsers, I haven't looked at what PG
has now.) Likewise a client can be fooled into trusting a spoof, if
multiple CA's are trusted. It all depends on the policy enforcement
rules you implement, and your control of the cert's.

In my case I have good control over the Kerberos infrastructure, but
none over the Federal PKI infrastructure. I also want the data
channel encryption tied to the client identity so I don't have to
worry about Man In The Middle attacks.

SASL supports Kerberos, of course, but it's actually technology
neutral. You can configure it to be as strong or weak as you want.
You could e.g. support the SASL_PLAIN mechanism without requiring an
encrypted tunnel, and you would sent passwords in the clear. (Not
recommended of course.) SSL fans may want to use the SASL_EXTERNAL
mechanism, which picks up the client identity from the SSL tunnel
it's running in, or from the OS if it's a machine-local connection.
(LDAP servers do the latter.) In my case I want the GSSAPI/Kerberos5
mechanism.

These days Java comes with SASL, GSSAPI (via GAAS), and SSL/TLS
support. Neither Java, nor Windows support the specific MIT Kerberos
API functions used by PostgreSQL. This is largely because MIT itself
has been encouraging people to use the standardized GSSAPI and SASL
functions instead. The bad thing about these APIs is that they push
you an abstraction layer or two away from the Kerberos functionality,
which makes them a touch harder to learn and use.

My main hesitation between SASL and GSSAPI is that the
Windows equivalent APIs for SASL have not received the same
degree of interoperability testing as SSPI<-->GSSAPI. I
don't have a published example to crib from. For general
information the relevant calls are at the bottom of
<http://msdn.microsoft.com/library/default.asp?url=/
library/en-us/secauthn/security/authentication_functions.asp>.

One reason for this could be that they appear to be available only on
server platforms, and not on cilents, if you look at the
documentation.
That said, I have the DLL file and the export functions on my XP
machine, so it's definitly present there - I'm unsure if it *works* or
is supported. My registry does indicate that I have the GSSAPI profile
for SASL, which would be an indication that it should.

Since those functions are there to support email clients, I would
expect them to be widely available (at least on any machine that has
an email client installed). Likewise I would expect them to be
functional when talking to e.g. sendmail or postfix servers compiled
with the Cyrus SASL library. Since I would use the same SASL library
for the server side of the implementation, they're pretty likely to
work to some degree.

//Magnus

I guess this discussion makes it sound like I've convinced myself to
use SASL. I still need to resolve how to do name translation.
PostgreSQL wants a single unix-like name, and I haven't looked at how
to properly do that translation from SASL (or GSSAPI) names.
------------------------------------------------------------------------
----
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 Thu, Nov 02, 2006 at 10:45:24AM -0800, Henry B. Hotz wrote:

Well, unless you have an unusually good PKI infrastructure, SSL
doesn't provide any cryptographic connection between the client
identity and the data received by the server. (At least that's true
for the way it's used by Web browsers, I haven't looked at what PG
has now.) Likewise a client can be fooled into trusting a spoof, if
multiple CA's are trusted. It all depends on the policy enforcement
rules you implement, and your control of the cert's.

In postgresql the client and server can specify what certificates
thay'll accept, there are no default trusted CAs. You can require the
client to have a certain certificate, for example. The client can also
verify the server has the expected certificate. How much it's used I
don't know, but SSL does support it.

In my case I have good control over the Kerberos infrastructure, but
none over the Federal PKI infrastructure. I also want the data
channel encryption tied to the client identity so I don't have to
worry about Man In The Middle attacks.

The encryption of a channel has nothing to do with verifying the
client/server is who they say they are. They can be configured
independantly. You can block Man-in-the-middle attacks without
encrypting the channel, though it is unusual.

I guess this discussion makes it sound like I've convinced myself to
use SASL. I still need to resolve how to do name translation.
PostgreSQL wants a single unix-like name, and I haven't looked at how
to properly do that translation from SASL (or GSSAPI) names.

Usually a field in the certificate is the username postgresql wants,
which can be mapped via a table. For SASL I don't know.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

On Nov 2, 2006, at 11:04 AM, Martijn van Oosterhout wrote:

On Thu, Nov 02, 2006 at 10:45:24AM -0800, Henry B. Hotz wrote:

In my case I have good control over the Kerberos infrastructure, but
none over the Federal PKI infrastructure. I also want the data
channel encryption tied to the client identity so I don't have to
worry about Man In The Middle attacks.

The encryption of a channel has nothing to do with verifying the
client/server is who they say they are. They can be configured
independantly. You can block Man-in-the-middle attacks without
encrypting the channel, though it is unusual.

Not actually true, at least not in a provable, general sense.

There is no way to know that the other end of an encrypted channel is
connected where you want it unless you have done some kind of client/
server mutual authentication as part of establishing the channel.
TLS does (or can do) this. If PostgreSQL can pick up e.g. the UID
from the client cert, then this is a very secure setup. Cudos! (Now
if only TLS had something better than RFC 2712 to integrate with
Kerberos.)

You can do a client/server mutual auth exchange without later
encrypting the channel, but then there is nothing to prevent someone
from later doing a TCP hijack. This is what the current Kerberos
support does.
------------------------------------------------------------------------
----
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

* Martijn van Oosterhout (kleptog@svana.org) wrote:

In postgresql the client and server can specify what certificates
thay'll accept, there are no default trusted CAs. You can require the
client to have a certain certificate, for example. The client can also
verify the server has the expected certificate. How much it's used I
don't know, but SSL does support it.

I don't think you can tie the SSL certificate to a specific user
though... I certainly can't recall any way to do that today in PG.
That would be possible w/ SASL/EXTERNAL though, I believe.

The encryption of a channel has nothing to do with verifying the
client/server is who they say they are. They can be configured
independantly. You can block Man-in-the-middle attacks without
encrypting the channel, though it is unusual.

They don't have to be connected, that's true. In general I think it's
better when they can be though.

I guess this discussion makes it sound like I've convinced myself to
use SASL. I still need to resolve how to do name translation.
PostgreSQL wants a single unix-like name, and I haven't looked at how
to properly do that translation from SASL (or GSSAPI) names.

Usually a field in the certificate is the username postgresql wants,
which can be mapped via a table. For SASL I don't know.

I expect we'll need a mapping of some sort, or perhaps a sasl_regexp or
similar to what is done in OpenLDAP. I don't recall PG supporting using
the DN from a client cert in an SSL connection as a PG username but
perhaps I missed it somewhere...

Thanks,

Stephen

In postgresql the client and server can specify what certificates
thay'll accept, there are no default trusted CAs. You can

require the

client to have a certain certificate, for example. The

client can also

verify the server has the expected certificate. How much

it's used I

don't know, but SSL does support it.

I don't think you can tie the SSL certificate to a specific
user though... I certainly can't recall any way to do that
today in PG.

You can't. It's been talked about, but never done.

I guess this discussion makes it sound like I've

convinced myself to

use SASL. I still need to resolve how to do name translation.
PostgreSQL wants a single unix-like name, and I haven't looked at
how to properly do that translation from SASL (or GSSAPI) names.

Usually a field in the certificate is the username

postgresql wants,

which can be mapped via a table. For SASL I don't know.

I expect we'll need a mapping of some sort, or perhaps a
sasl_regexp or similar to what is done in OpenLDAP. I don't
recall PG supporting using the DN from a client cert in an
SSL connection as a PG username but perhaps I missed it somewhere...

You can't today.
If we want to add username mapping in SASL or whatever, it might be a
good idea to look at generalizing the authuser-to-dbuser mapping stuff
(like we have for identmap now) into something that can be used for all
external auth methods. Instead of inventing one for every method.

//Magnus

* Richard Troy (rtroy@ScienceTools.com) wrote:

Would signed certificates be preferred? Well, sure, they're nice. I don't
object, and in fact welcome some improvements here. For example, I'd love
the choice of taking an individual user's certificate and authenticating
completely based upon that. However, while this _seems_ to simplify
things, it really just trades off with the added cost of managing those
certs - username/password is slam-dunk simple and has the advantage that
users can share one authentication.

Username/password is not acceptable in a number of situations. This is
not intended to replace them. This would be in *addition* to supporting
the current auth methods. I don't understand at all how you feel it'd be
nice to have yet shouldn't be done.

Thanks,

Stephen

On Thu, 2 Nov 2006, Magnus Hagander wrote:

I expect we'll need a mapping of some sort, or perhaps a
sasl_regexp or similar to what is done in OpenLDAP. I don't
recall PG supporting using the DN from a client cert in an
SSL connection as a PG username but perhaps I missed it somewhere...

You can't today.
If we want to add username mapping in SASL or whatever, it might be a
good idea to look at generalizing the authuser-to-dbuser mapping stuff
(like we have for identmap now) into something that can be used for all
external auth methods. Instead of inventing one for every method.

//Magnus

Well, there's simply no need. While I can agree that more could be done,
I'm not convinced there's a need because what we have now works fine. Let
me support my view by stating first that I perceive that combining the
conception of encrypting a communications channel with user authentication
to be a very poor choice. I gather from the paragraph above that this is a
forgone conclusion. Appologies if I'm mistaken.

Just so my point - that another strategy is not needed - is understood,
let's agree that SSL is just preventing sniffers from capturing whatever
else goes on in "our conversation." Great. What's inside that
communication? Why, there's a perfectly workable username/password
authentication that happens! Sure, someone could steal that data somehow
and break in, but that requires one of the two systems to be breached, and
that's a security problem that's out of scope for Postgres.

Would signed certificates be preferred? Well, sure, they're nice. I don't
object, and in fact welcome some improvements here. For example, I'd love
the choice of taking an individual user's certificate and authenticating
completely based upon that. However, while this _seems_ to simplify
things, it really just trades off with the added cost of managing those
certs - username/password is slam-dunk simple and has the advantage that
users can share one authentication.

Unless I've really overlooked something basic, there's nothing lacking in
the existing scheme...

Richard

--
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
rtroy@ScienceTools.com, http://ScienceTools.com/

* Richard Troy (rtroy@ScienceTools.com) wrote:

...I thought you said this _needs_ to be done - by using words like
"unacceptible" and "required" - and I disagree. There's a difference
between what needs to be done and what is desired to be done. Further, I
never said "shouldn't."

For PG to be an option in certain environments, it *needs* to be done
because in those environments username/password are *unacceptable*.
Additionally, there's someone (actually, more than one it seems) who's
willing to spend the time and energy to implement it. If it's not
necessary for your environment, great! If you weren't suggesting it
shouldn't be implemented or accepted then I've truely got no idea what
the intent of your previous mail was.

Enjoy,

Stephen

Username/password is not acceptable in a number of situations. This is
not intended to replace them. This would be in *addition* to supporting
the current auth methods. I don't understand at all how you feel it'd
be nice to have yet shouldn't be done.

Thanks,

Stephen

...I thought you said this _needs_ to be done - by using words like
"unacceptible" and "required" - and I disagree. There's a difference
between what needs to be done and what is desired to be done. Further, I
never said "shouldn't."

Richard

--
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
rtroy@ScienceTools.com, http://ScienceTools.com/

On Nov 2, 2006, at 12:26 PM, Richard Troy wrote:

Well, there's simply no need. While I can agree that more could be
done,
I'm not convinced there's a need because what we have now works
fine. Let
me support my view by stating first that I perceive that combining the
conception of encrypting a communications channel with user
authentication
to be a very poor choice. I gather from the paragraph above that
this is a
forgone conclusion. Apologies if I'm mistaken.

Understand that I'm talking about *real* security here. There are
standard protocols and libraries that support real security: SASL
and GSSAPI in particular. You may for various reasons decide that
it's "too hard" to do real security. Most people don't, including
most people who use SSL. I'm not saying that's *wrong*, just that
some possible attack methods have not been prevented.

At the level of detail that's appropriate for this list, all I can do
is repeat myself.

Part of establishing a secure connection is establishing that the end
points are the intended ones and there is no Man In the Middle.
Establishing the end points means the server has identified the user
within the name space of the security mechanism.
------------------------------------------------------------------------
----
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

Would signed certificates be preferred? Well, sure, they're
nice. I don't object, and in fact welcome some improvements
here. For example, I'd love the choice of taking an
individual user's certificate and authenticating completely
based upon that. However, while this _seems_ to simplify
things, it really just trades off with the added cost of
managing those certs - username/password is slam-dunk simple
and has the advantage that users can share one authentication.

Unless I've really overlooked something basic, there's
nothing lacking in the existing scheme...

From my POV, yes, you are missing sometihng very basic - single signon.
This is what Kerberos gives me. No need for the user to type in his
password, becaus ehe is *already* logged in and authenticated by a
trusted KDC in the realm.

The same could apply to SSL cert based authentication, for users
connecting from machines outside of my realm. Once you have "unlocked"
the certificate, you can authenticate any number of times to any number
of services that will accept this certificate *without* having to
re-enter your password.

This is both a convenience for the user, and a requirement if you use
OTPs.

//Magnus

On Thu, Nov 02, 2006 at 01:10:14PM -0800, Henry B. Hotz wrote:

standard protocols and libraries that support real security: SASL
and GSSAPI in particular. You may for various reasons decide that

[. . .]

Part of establishing a secure connection is establishing that the end
points are the intended ones and there is no Man In the Middle.
Establishing the end points means the server has identified the user
within the name space of the security mechanism.

For what it's worth, I heartily support this effort. For most cases,
it probably isn't necessary, but I can think of several applications
for SASL/GSSAPI where something weaker will simply not do; in the
absence of the proposed functionality, I simply wouldn't be able to
use Postgres for those applications.

A

--
Andrew Sullivan | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
--Brad Holland

On Thu, Nov 02, 2006 at 08:58:37PM +0100, Magnus Hagander wrote:

I don't think you can tie the SSL certificate to a specific
user though... I certainly can't recall any way to do that
today in PG.

You can't. It's been talked about, but never done.

Oops, sorry. You can verify the user has a valid certificate, but you
can't use it for authentication. AFAIK it just needs to be coded
(certainly the code to get the relevent fields from the certificate is
there).

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/