[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Design] Re: Wes Hardaker: opportunistic encryption deploymen t problems
At 10:32 AM -0700 8/15/01, Michael Thomas wrote:
>Chris Trobridge writes:
> > I think the problem is not specifically "global PKI" but "global trust
> > infrastructure".
>
> Yes, my sloppy.
>
> > It would be useful if IKE could use different trust models, including
> > delegation this to another protocol.
> >
> > However, I think in most cases, binding up your key to an IP address
> > probably isn't that useful, due to ephemeral nature of IP addresses - my
> > impression is that this just gets worse with IPv6.
>
> I agree, it not very optimal. It's quite possible that
> I don't understand this very well, but do the two
> use modes -- tunnel/transport -- really have the same
> identity semantics? For tunnel mode, you are essentially
> authenticating/authorizing an incoming interface to be
> built on the security gateway. That is, a route is
> established for a prefix. There really aren't any
> possible consumers (normally, at least, unless you're
> talking about a degenerate host-host tunnel).
> I'm not as sure with transport mode. I guess I
> view this as not so much affecting the routing
> subsystem so much as affecting the IP datagrams
> themselves; it may be implemented using the same
> mechanisms as are used for tunnels, but I don't
> think it *needs* to be thought of that way. In
> fact, since transport is a host-host mode, it
> sort of begs what the identity is used for at
> all. I've brought up on the list before that
> it would be nice to have the L3 credentials
> available for higher layers when in transport
> mode, (which I still think would be quite
> useful), but I guess I don't know what the
> transport identity is providing other than
> a reliable way of saying, "yes, this is
> mat@cisco.com". If there's not a policy module
> which can take action based on that knowledge,
> it seems like it's just providing a way to keep
> outsiders out. Maybe this is a useful enough
> service, but it seems sort of limited...
>
>
> Mike
Mike,
Your understanding is not quite right. First, tunnel mode, while
required for an SG, is also applicable to two hosts communicating.
Second, IPsec supports authentication of symbolic names, not just IP
addresses, which are dynamically bound to IP addresses for the
duration of an SA. This is how we support connections from mobile
users, for example.
The access control model that underlies IPsec is that one uses some
means of authenticating a peer, e.g., via binding a signature key to
an ID, traceable to a trust anchor, and that the traffic sent from
and sent to the authenticated peer is subject to access controls
expressed in the SPD. These controls apply not only to allowed IP
addresses to/from which traffic may flow, but also protocols and port
fields. The motivation for these other selectors is the same as in
firewalls, i.e., we can control access to services based on access to
well know ports.
Once the SA is established, we look at the IP source address(es)
asserted by the peer to ensure that it does not try to spoof traffic
from other peers with whom we are communicating (especially relevant
at an SG).
Steve
Follow-Ups:
References: