Thread: Design Considerations for New Authentication Methods
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.
When you do one of the above, an authentication is not (necessarily)
a simple one-packet exchange. In fact the exchange may involve
trying several different authentication mechanisms before you find
one that works.
The question is how do I handle the multiple round-trips where one
trip is now assumed?
The simple approach is for me to just put the loop inside the
relevant fe-auth.c and auth.c sections, corresponding to where the
pg_krb5_{send,recv}auth() calls are. However the comments in the
code make it sound like people are very concerned about the number of
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.
Is this behavior important during startup? Or is it only important
once the connection is fully established?
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.
------------------------------------------------------------------------
----
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:
> 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
* 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 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
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 hooksin 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: >>> * 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
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/ > From each according to his ability. To each according to his ability to litigate.
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
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:
> 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
> 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/
* 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
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/ > From each according to his ability. To each according to his ability to litigate.
On Thu, Nov 02, 2006 at 10:48:29PM +0100, Magnus Hagander wrote:
> 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.
Why would you need to unlock it? SSL certificate is effectively a password
stored in a file of length 1024 bits or whatever.
> This is both a convenience for the user, and a requirement if you use
> OTPs.
I don't understand the OTP part. Single signon is only a convenience.
Ability to resume a session (provided by SSL) or ability to login using
a smaller authentication token than a certificate can be used to provide
performance improvement.
If the requirement is that no password is provided, password + SSL
certificate is not an improvement. Any token based authentication system
should allow for the token to become invalid at any time, and require
re-authentication using the primary mechanism.
The benefit to kerberos, from my perspective, is that it already exists,
and is widely used.
I prefer SSL certificates alone myself. All of my db passwords are randomly
generated anyways, and a 1024-bit randomly generated password is better than
a 64-bit password picked by a person at a keyboard. Having both isn't an
improvement I think. My own system at home uses RSA keys or SSH entry. I
don't bother with passwords anymore. If they can access my password, they
can access my certificate. If they can access my certificate, they can access
my password. Dual authentication models work better with very different
systems. For example, a USB key or digital display that I possess, and a
password that I know or have stored in a file.
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness
bindthem...
http://mark.mielke.cc/
All, > 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. I'll also add that there are an increasing number of apps and authentication environments which use SASL or GSSAPI. Supporting these means that we are no longer locked out of those companies. I know that the Solaris folks would prefer us to use GSSAPI. And if there is some reasonably large number of people using a particular athentication method, we should support it if someone is offering us the code. Why would we reject a piece of useful functionality based on a published standard? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
Josh Berkus <josh@agliodbs.com> writes:
> ... Why would we reject a piece of useful functionality based on a
> published standard?
Well, size and maintainability of the proposed patch are certainly
factors in any such decision. As a closely related example, I bet
we'd have rejected the original Kerberos-support patch if we'd known
then what we know now. It's been a constant source of bugs ever since
it went in, and with so few users of the feature, it takes a long time
to find the problems.
regards, tom lane
Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>> ... Why would we reject a piece of useful functionality based on a
>> published standard?
>
> Well, size and maintainability of the proposed patch are certainly
> factors in any such decision. As a closely related example, I bet
> we'd have rejected the original Kerberos-support patch if we'd known
> then what we know now. It's been a constant source of bugs ever since
> it went in, and with so few users of the feature, it takes a long time
> to find the problems.
To be honest, I have often wondered *why* we support kerberos outside of
the uber l33t geek factor. I have not once in a commercial deployment
had a business requirement for the beast. LDAP? Now that is a whole
other issue :)
Joshua D. Drake
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
--
=== 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
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Josh Berkus <josh@agliodbs.com> writes:
> > ... Why would we reject a piece of useful functionality based on a
> > published standard?
>
> Well, size and maintainability of the proposed patch are certainly
> factors in any such decision. As a closely related example, I bet
> we'd have rejected the original Kerberos-support patch if we'd known
> then what we know now. It's been a constant source of bugs ever since
> it went in, and with so few users of the feature, it takes a long time
> to find the problems.
Funny, I really wonder why you feel there's few users of it. I use
kerberos auth on quite a few hosts and I've heard of at least a couple
others on this (not all that frequented) list. Kerberos is really
rather popular, made more so through SSPI and GSSAPI...
Thanks
Stephen
On Thu, Nov 02, 2006 at 07:49:01PM -0800, Joshua D. Drake wrote:
> To be honest, I have often wondered *why* we support kerberos outside of
> the uber l33t geek factor. I have not once in a commercial deployment
> had a business requirement for the beast. LDAP? Now that is a whole
> other issue :)
Isn't NFSv4 a big application that uses Kerberos? I seem to recall that
AFS may have been a large user as well.
The only reason it isn't widely used is because companies are slow to
change. We still use NIS for host names in too many places!
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness
bindthem...
http://mark.mielke.cc/
> > 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. > > Why would you need to unlock it? SSL certificate is > effectively a password stored in a file of length 1024 bits > or whatever. Because if someone can access this file, I don't want them to automticlly "be me". Say this file is on my smartcard - I most certainly want a PIN code before it logs me in. Now, if I trust my local machine reasonably well, this "unlock" can equal the "local login". But there's still an unlock sequence. > > This is both a convenience for the user, and a requirement > if you use > > OTPs. > > I don't understand the OTP part. Single signon is only a convenience. > Ability to resume a session (provided by SSL) or ability to > login using a smaller authentication token than a certificate > can be used to provide performance improvement. OTP can certainly be a *lot* more secure, when used in the right way. This of course rquires you use a two-factor system such as a token based key or challenge/response system. And it's not just a convenience. SSL reusme session doesn't work if the first login is to my fileserver, the second to my maliserver and the third to my database server. I would then require three separate OTP logins. Since they would normally have a time-window, it will also noticably slow down the process since I'd have to wait for a new key before accessing each resource. > The benefit to kerberos, from my perspective, is that it > already exists, and is widely used. Yes, that is a huge benefit. > My own system at home uses RSA keys or > SSH entry. I don't bother with passwords anymore. If they can > access my password, they can access my certificate. If they > can access my certificate, they can access my password. Dual > authentication models work better with very different > systems. For example, a USB key or digital display that I > possess, and a password that I know or have stored in a file. Well, you know how to deal with passwords and authentication. Most users don't. Therefor using things like smartcard+PIN can *both* increase security *and* make things easier for them. To make it work in reality, that means you need to support whatever infrastructure standard other systems use, and that's most commonly Kerberos today. And second most common I would beleive is SSL/TLS certs. //Magnus
> >> ... Why would we reject a piece of useful functionality based on a > >> published standard? > > > > Well, size and maintainability of the proposed patch are certainly > > factors in any such decision. As a closely related example, I bet > > we'd have rejected the original Kerberos-support patch if > we'd known > > then what we know now. It's been a constant source of bugs > ever since > > it went in, and with so few users of the feature, it takes > a long time > > to find the problems. > > To be honest, I have often wondered *why* we support kerberos > outside of the uber l33t geek factor. I have not once in a > commercial deployment had a business requirement for the > beast. LDAP? Now that is a whole other issue :) Single sign-on in a Windows/AD environment (I'm talking clients on windows, servers on linux here - at least in my case). I know several people who use it, most just don't post here ;-) Now, it would likely be a lot *easier* to do this with GSSAPI than the pure kerberos stuff we have now, given that the Windows native APIs support GSSAPI compatible stuff, but not the stuff we have now. //Magnus
> > To be honest, I have often wondered *why* we support > kerberos outside > > of the uber l33t geek factor. I have not once in a commercial > > deployment had a business requirement for the beast. LDAP? > Now that is > > a whole other issue :) > > Isn't NFSv4 a big application that uses Kerberos? I seem to > recall that AFS may have been a large user as well. AFS definitly used it. But if you're looking for a "big application" that uses Kerberos, there's that pesky thing called Windows. Every single Windows machine in an active directory domain environment is a Kerberos client, and uses Kerberos for authentication to all network services. So Kerberos is definitly big. And more and more apps do support GSSAPI for authentication. Not that many apps support "raw kerberos" as pgsql does, probably because it does have some compatibility issues and such things. //Magnus
On Fri, Nov 03, 2006 at 08:05:05AM +0100, Magnus Hagander wrote:
> > > 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.
> > Why would you need to unlock it? SSL certificate is
> > effectively a password stored in a file of length 1024 bits
> > or whatever.
> Because if someone can access this file, I don't want them to
> automticlly "be me". Say this file is on my smartcard - I most certainly
> want a PIN code before it logs me in.
> Now, if I trust my local machine reasonably well, this "unlock" can
> equal the "local login". But there's still an unlock sequence.
Yes - local login. I didn't think of it in that context, as I think
more of batch processes, or servers accessing the database. A person
accessing just doesn't seem significant to me. It's more of a special
case. :-)
I prefer to use PostgreSQL with a local socket, and passing of UNIX
credentials over the socket. If you can login to the account, you
can access all of the scripts owned by that account that have a
PostgreSQL username/password embedded within them anyways - so why
embed at all? Obviously, for remote database access, or for any system
with load sharing across systems accessing the same database, this
doesn't work too well and an alternative such as SSL certificates
becomes desirables. The effect is the same, though.
> > I don't understand the OTP part. Single signon is only a convenience.
> > Ability to resume a session (provided by SSL) or ability to
> > login using a smaller authentication token than a certificate
> > can be used to provide performance improvement.
> OTP can certainly be a *lot* more secure, when used in the right way.
> This of course rquires you use a two-factor system such as a token based
> key or challenge/response system.
Not sure why it would be more secure by using a smaller key on second
entry. Sure the smaller key times out, but effectively you now have
two or more keys instead of one. :-)
> And it's not just a convenience. SSL reusme session doesn't work if the
> first login is to my fileserver, the second to my maliserver and the
> third to my database server. I would then require three separate OTP
> logins.
*nod*
> Since they would normally have a time-window, it will also
> noticably slow down the process since I'd have to wait for a new key
> before accessing each resource.
This presumes that you use a key system. SSL certificate is adequate
on its own for many uses... :-)
> > The benefit to kerberos, from my perspective, is that it
> > already exists, and is widely used.
> Yes, that is a huge benefit.
Ignoring my liking of SSL certificates, and my defense of them, I agree
it is a huge benefit to support Kerberos for these reasons.
> > My own system at home uses RSA keys or
> > SSH entry. I don't bother with passwords anymore. If they can
> > access my password, they can access my certificate. If they
> > can access my certificate, they can access my password. Dual
> > authentication models work better with very different
> > systems. For example, a USB key or digital display that I
> > possess, and a password that I know or have stored in a file.
> Well, you know how to deal with passwords and authentication. Most users
> don't. Therefor using things like smartcard+PIN can *both* increase
> security *and* make things easier for them. To make it work in reality,
> that means you need to support whatever infrastructure standard other
> systems use, and that's most commonly Kerberos today. And second most
> common I would beleive is SSL/TLS certs.
*nod*
I agree.
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness
bindthem...
http://mark.mielke.cc/
> > > > 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. > > > Why would you need to unlock it? SSL certificate is effectively a > > > password stored in a file of length 1024 bits or whatever. > > Because if someone can access this file, I don't want them to > > automticlly "be me". Say this file is on my smartcard - I most > > certainly want a PIN code before it logs me in. > > Now, if I trust my local machine reasonably well, this "unlock" can > > equal the "local login". But there's still an unlock sequence. > > Yes - local login. I didn't think of it in that context, as I > think more of batch processes, or servers accessing the > database. A person accessing just doesn't seem significant to > me. It's more of a special case. :-) Heh. Depends on your scenario, I suppose. There are loads of legacy apps out there that are just fat-client-directly-to-database, and we like to run those on pg as well... > I prefer to use PostgreSQL with a local socket, and passing > of UNIX credentials over the socket. If you can login to the > account, you can access all of the scripts owned by that > account that have a PostgreSQL username/password embedded > within them anyways - so why embed at all? When it's a local user, that's what I use as well. (Except it does prove troublesome with interfaces that don't support UNIX sockets (for example, the mono provider doesn't. I don't think the JDBC one does either)) > > > I don't understand the OTP part. Single signon is only a > convenience. > > > Ability to resume a session (provided by SSL) or ability to login > > > using a smaller authentication token than a certificate > can be used > > > to provide performance improvement. > > OTP can certainly be a *lot* more secure, when used in the > right way. > > This of course rquires you use a two-factor system such as a token > > based key or challenge/response system. > > Not sure why it would be more secure by using a smaller key > on second entry. Sure the smaller key times out, but > effectively you now have two or more keys instead of one. :-) You use the smaller key *the first time*, not the second one. Why? Because it's easier. Sure, if you can stick a cert on a smartcard, then you can have the big key *and* proper two-factor. And in fact in at least Windows, if you do smartcard login it will integrate fine with both SChanenl (SSL) and Kerberos. The SSL cert needs to be in a trusted store of some kind. It can be a smartcard (easy), or it can be a password protected store (not so easy, at least not if you want to have a good password). > > Since they would normally have a time-window, it will also > noticably > > slow down the process since I'd have to wait for a new key before > > accessing each resource. > > This presumes that you use a key system. SSL certificate is > adequate on its own for many uses... :-) Sure, but it's not two-factor unless you use smartcards. If you do smartcards, SSL certificates are very good. //Magnus
>> To be honest, I have often wondered *why* we support kerberos
>> outside of the uber l33t geek factor. I have not once in a
>> commercial deployment had a business requirement for the
>> beast. LDAP? Now that is a whole other issue :)
>
> Single sign-on in a Windows/AD environment (I'm talking clients on
> windows, servers on linux here - at least in my case). I know several
> people who use it, most just don't post here ;-)
Wouldn't the LDAP auth in 8.2 resolve that?
>
> Now, it would likely be a lot *easier* to do this with GSSAPI than the
> pure kerberos stuff we have now, given that the Windows native APIs
> support GSSAPI compatible stuff, but not the stuff we have now.
Nod.
Sincerely,
Joshua D. Drake
>
> //Magnus
>
--
=== 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
> >> To be honest, I have often wondered *why* we support > kerberos outside > >> of the uber l33t geek factor. I have not once in a commercial > >> deployment had a business requirement for the beast. LDAP? > Now that > >> is a whole other issue :) > > > > Single sign-on in a Windows/AD environment (I'm talking clients on > > windows, servers on linux here - at least in my case). I > know several > > people who use it, most just don't post here ;-) > > Wouldn't the LDAP auth in 8.2 resolve that? No. LDAP gives me single credentials, but not single sign-on. I still have to enter my password every time I connect. //Magnus
Tom, Josh, etc.: > But if you're looking for a "big application" that uses Kerberos, > there's that pesky thing called Windows. Every single Windows machine in > an active directory domain environment is a Kerberos client, and uses > Kerberos for authentication to all network services. Kerberos with GSSAPI is also widely used for Solaris, so supporting it helps a lot in getting a large proportion of Solaris users to adopt PostgreSQL. > So Kerberos is definitly big. And more and more apps do support GSSAPI > for authentication. Not that many apps support "raw kerberos" as pgsql > does, probably because it does have some compatibility issues and such > things. Yes ... if we were looking to cut down on both code and dependency bugs, we might consider desupporting "raw Kerberos". At this point, I think that everyone who supports Kerberos supports GSSAPI, unless we're still committed to supporting users of Red Hat 7.0 (Tom?). -- Josh Berkus PostgreSQL @ Sun San Francisco
Josh Berkus <josh@agliodbs.com> writes:
> Yes ... if we were looking to cut down on both code and dependency bugs, we
> might consider desupporting "raw Kerberos". At this point, I think that
> everyone who supports Kerberos supports GSSAPI, unless we're still committed
> to supporting users of Red Hat 7.0 (Tom?).
I have no corporate commitment to make PG 8.3+ work on ancient Red Hat
versions, if that's what you mean.
regards, tom lane
Tom, > I have no corporate commitment to make PG 8.3+ work on ancient Red Hat > versions, if that's what you mean. Well, in that case my suggestion is that we plan to transition to GSSAPI and drop support for raw Kerberos as soon as Henry is ready with a patch (plus I'm going to try to get the Solaris security folks to kick in on this). GSSAPI is the official API of Kerberos5, and in theory supporting it should reduce the number of specific-library-version dependancy bugs we get with Kerberos in the future. -- Josh Berkus PostgreSQL @ Sun San Francisco