Re: Confirm decision on identity handling.

[Michael Thomas <mat@cisco.com>]

Eric Rescorla writes:
 > Michael Thomas <mat@cisco.com> writes:
 > > Or something like this. Note that this doesn't
 > > have anything to do with the *IKE* identity, it's
 > > completely a property of the SA and its filters
 > > that were derived from the policy which matched
 > > for the mode and identity. It does, however,
 > > enforce the property that you desired above,
 > > especially when combined with the fact that you
 > > need several round trips which establish that that
 > > entity is, in fact, reachable at the outgoing
 > > address.
 > You must be joking.
 > 
 > What, you've never heard of active attacks? IP spoofing?

Yeah, yeah, and the application starting the TCP
connection got that IP address from DNS which
isn't secure either. Them's the breaks when you
don't have tight binding between application layer
logic and the security layer. Is it better than
nothing? I'd say so. Thus we've already made our
peace with various active attacks and all kinds of
other insecure things that apps do in the global
scheme of things.

 > Much of the purpose of the exercise is to protect ourselves
 > from people who can arbitrarily manipulate the IP packet
 > delivery service.

IPsec is an authenticated ACL traversal mechanism
not a miracle worker. It raises the bar
substantially, but there's a security/convenience
tradeoff that needs to be allowed. Tying
identities to routing tags has a substantial
number of drawbacks and leads us down some rather
unfortunate paths taken to its logical ends. Like,
oh say, ICAAN doling out IP address ownership
certificates. Ick. We also need to account for
deployability and unintended consequences.

 > > Again, you seem to be conflating the IKE session
 > > identity and the packet filtering mechanism of
 > > IPsec. 
 > It's not that I'm conflating them but rather that they're
 > bound by the logic of the desired security service. 

You're not acknowledging the engineering tradeoffs
that need to be accounted for. Very secure but
undeployable isn't a solution. More secure and
deployable often is, depending on the risks. Note
that there are other routes that can be taken to
shore up the security while using IPsec. An API
down to the kernel IPsec as well as keying layer
that apps could use would be an even larger
improvement on the security front than IP
addresses being used as identifiers. Regardless of
what layer crypto is being done at, this is what
is ultimately needed (and one thing that TLS has a
large advantage over IPsec, IMO).

	Mike