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.
[EMAIL PROTECTED]
"Internet Cryptography" at http://www.visi.com/crypto/
