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

Search Discussions

  • Tom Lane at Nov 1, 2006 at 4:34 am

    "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 at Nov 1, 2006 at 7:32 pm

    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
  • Stephen Frost at Nov 1, 2006 at 7:03 pm

    * 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
  • Henry B. Hotz at Nov 1, 2006 at 8:09 pm

    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
  • Magnus Hagander at Nov 2, 2006 at 9:18 am

    * 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
  • Henry B. Hotz at Nov 2, 2006 at 6:18 pm
    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
  • Henry B. Hotz at Nov 2, 2006 at 6:45 pm
    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
  • Martijn van Oosterhout at Nov 2, 2006 at 7:04 pm

    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.
  • Henry B. Hotz at Nov 2, 2006 at 7:43 pm

    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
  • Stephen Frost at Nov 2, 2006 at 7:55 pm

    * 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
  • Magnus Hagander at Nov 2, 2006 at 7:58 pm

    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 at Nov 2, 2006 at 8:19 pm

    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/
  • Stephen Frost at Nov 2, 2006 at 8:25 pm

    * 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
  • Richard Troy at Nov 2, 2006 at 8:39 pm

    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/
  • Stephen Frost at Nov 2, 2006 at 8:43 pm

    * 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
  • Henry B. Hotz at Nov 2, 2006 at 9:10 pm

    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
  • Andrew Sullivan at Nov 2, 2006 at 9:52 pm

    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
  • Josh Berkus at Nov 3, 2006 at 1:00 am
    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
  • Tom Lane at Nov 3, 2006 at 2:46 am

    Josh Berkus 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
  • Joshua D. Drake at Nov 3, 2006 at 3:48 am

    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
  • Mark at Nov 3, 2006 at 4:18 am

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

    http://mark.mielke.cc/
  • Magnus Hagander at Nov 3, 2006 at 7:16 am

    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
  • Josh Berkus at Nov 4, 2006 at 8:03 pm

    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
  • Tom Lane at Nov 4, 2006 at 10:53 pm

    Josh Berkus 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
  • Josh Berkus at Nov 4, 2006 at 11:00 pm
    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
  • Magnus Hagander at Nov 3, 2006 at 7:13 am

    ... 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
  • Joshua D. Drake at Nov 3, 2006 at 4:26 pm

    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
  • Magnus Hagander at Nov 3, 2006 at 9:52 pm

    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
  • Stephen Frost at Nov 3, 2006 at 4:12 am

    * 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
  • Magnus Hagander at Nov 2, 2006 at 9:48 pm

    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
  • Mark at Nov 2, 2006 at 10:44 pm

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

    http://mark.mielke.cc/
  • Magnus Hagander at Nov 3, 2006 at 7:05 am

    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
  • Mark at Nov 3, 2006 at 7:56 am

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

    http://mark.mielke.cc/
  • Magnus Hagander at Nov 3, 2006 at 9:38 am

    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
  • Martijn van Oosterhout at Nov 2, 2006 at 9:58 pm

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedNov 1, '06 at 12:14a
activeNov 4, '06 at 11:00p
posts36
users10
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase