Re: Design Considerations for New Authentication Methods

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