[3593] in cryptography@c2.net mail archive
Re: dbts: Lions and TEMPESTs and Black Helicopters (Oh, My!)
daemon@ATHENA.MIT.EDU (Rick Smith)
Thu Nov 5 14:41:44 1998
Date: Thu, 05 Nov 1998 10:07:09 -0600
To: Robert Hettinga <rah@shipwright.com>, cryptography@c2.net
From: Rick Smith <rick_smith@securecomputing.com>
In-Reply-To: <v04020a1bb2669f7c6946@[139.167.130.246]>
I wrote:
>> Let me raise another possible problem with substituting IPSEC for SSL --
>> does anyone *really* have an IPSEC implementation that interfaces as
>> effectively with secure applications? ...
And Robert Hettinga replied:
>IPsec happens at the network layer, SSL between the transport layer and
>the application layer.
Yep.
> That means SSL provides a secure channel between
>_processes_ and IPsec provides a secure channel between _network nodes_
>(really, between network interfaces). IPsec doesn't really have anything
>to do with applications--it's for encrypting and/or authenticating
>_datagrams_ (aka _packets_).
Technically, you *can* tie specific IPSEC security associations to specific
processes, and to some extent you have to do this to make a sophisticated
VPN environment work. You also need it to tie IKE/ISAKMP packets to the
proper key management process. In theory a vendor could provide binding
between processes and security associations as a general service available
to applications developers.
Fortunately (IMHO) this isn't something I've seen in real products, or in
secure applications. Practical IPSEC products tend to work as you said --
establishing distinct associations between pairs of hosts, not between
pairs of processes that might be on the same host. I agree that IPSEC's
place in the protocol stack predisposes it towards certain types of uses
and makes it a bad choice for other uses.
Rick.
smith@securecomputing.com
"Internet Cryptography" at http://www.visi.com/crypto/
