[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "user" and "network layer" security mechanisms.
> From: Charles Watt <watt@sware.com>
>
> Pick at the specifics all you want, the basic point remains valid. The
> Internet stack was designed to permit multiplexing above IP. There are
> several things out there that do this. User-level authentication within
> IPSEC cannot work for these products unless they are substantially
> modified.
That point is not specific to IP, and no "additional restrictions" you
could place on IP or IPX or any other layer 3 protocol can prevent
tunnelling (and therefore multiplexing) through it - all communication
channels are equivalent. If you have a hypothetical "secure" system
that permits only bidirectional SMTP email, you can still establish
IP dataflow through it, and (with appropriate adjustment of timeouts),
TCP connections as well :-). Stick a PPP connection on top of that, and
you've got a layer 2 link running over a layer 7 protocol. The nesting
could continue ad infinitum.
So what?
The discussion seems to be motivated from two different viewpoints:
Mitch and Charlie say that there is no way to attach contexts or SPIs
to IP packets in a manner that will guarantee 100% MAC-grade
cryptographic separation based on anything other than IP addresses.
This is correct - there is only one SPI per IP packet, and if data
from two different "users" is placed into the packet, it must be separated
using some other mechanism.
They then argue that because IP-layer mechanisms cannot in general do MAC
based on anything other than IP addresses (a correct assertion), that the
IP protocol should not be permitted to use SPIs based on "users" or
"authenticated entities" or anything other than src and dst IP addresses.
That is the bottom-up view: design IP so that it advertises a simple
capability, and provides near-100% assurance that it does what it claims
to do.
The other viewpoint is top-down: there is a huge universe of applications
running on real customer networks that need to be "secured". We could do
it by modifying every single application and every application protocol to
provide security services at the highest layer, or we could recognize that
application protocols fall into classes, and that for some classes (those
that don't multiplex services for multiple "users" through a single
connection or process), a common IP-layer mechanism can be used without
modifying the higher layer protocols. Therefore it is reasonable to
provide the mechanism (an SPI field in the IP packet) that can in some
cases be used to achieve separation between "users" at the network layer.
There is a unique window of opportunity where the entire industry will
replace their IP stacks and kernel code to accommodate IPv4/IPsec or IPv6.
It makes sense to make the kernel-level code as general as possible while
that window is open. If we later find that nearly all applications
have become RPC-based and subject to RPC security mechanisms, and
user-based IP keying is not worth the effort, then the key management
daemons can be yanked and replaced with something trivial that does
keying based on IP addresses. In that case the SPI becomes redundant
but harmless (and it still provides an efficiency benefit over using IP
addresses directly to look up SAs for each packet).