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.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu