Re: Design Considerations for New Authentication Methods

Sorry about the premature send.

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

>>> * Henry B. Hotz (hotz(at)jpl(dot)nasa(dot)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(dot)B(dot)Hotz(at)jpl(dot)nasa(dot)gov, or hbhotz(at)oxy(dot)edu