Re: Design Considerations for New Authentication Methods

Поиск
Список
Период
Сортировка
От Henry B. Hotz
Тема Re: Design Considerations for New Authentication Methods
Дата
Msg-id 09F83C94-DEC5-4EF4-9199-F277F48C0631@jpl.nasa.gov
обсуждение исходный текст
Ответ на Re: Design Considerations for New Authentication Methods  ("Magnus Hagander" <mha@sollentuna.net>)
Ответы Re: Design Considerations for New Authentication Methods  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
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




В списке pgsql-hackers по дате отправления:

Предыдущее
От:
Дата:
Сообщение: Coding style question
Следующее
От: imad
Дата:
Сообщение: Re: Coding style question