Sorry about the premature send.

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

* Henry B. Hotz ([EMAIL PROTECTED]) 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

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.


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.

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?


Reply via email to