Re: Design Considerations for New Authentication Methods

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(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.