Re: identifiers and security

[Erik Nordmark <Erik.Nordmark@sun.com>]

> Sure, there always is an identifier, obviously I was getting at the 
> situation where there isn't new/separate value that fulfills this 
> function. BTW, I don't consider a _set_ of locators _a_ identifier, as 
> membership of the set presumably isn't fixed and having more than one 
> way to express the same identity (not the same thing as having more 
> than one identity) is a very bad idea. (X.400 anyone?)

Fair enough. 


> > and whether those IDs are visible to the applications.
> 
> Ah, but that's a very different issue. I think by definition the 
> identifiers are visible to the application.

My choice of "visible" doesn't capture the distinction I wanted to make. Sorry.
 What I mean was whether the applications need to do something
different because there is an ID (versus there just being a plain-old IPv6
address). The IDs can be visible, either by being part of an IPv6 locator,
or by some new mechanism by which the application can ask the stack for the ID,
but that wasn't the point I was trying to make.

> > Taking NOID as an example of with no new ID namespace, the amount of
> > work (in the form of DNS lookups in forward and reverse maps)
> > will also result in stronger association between FQDNs and locators
> > than we have today.
> 
> Even if we assume DNSSEC?

Assume DNSSEC for the baseline (current Internet), for NOID, or for both
when comparing them?

In the case of "both" it is still the case that NOID as currently specified
performs extra checks; it would check the consistency between the
reverse and forward DNS trees. This provides combined with the return
routability checks implicit in establishing the context means that not only do
the locators used have to be routable to the node, but the reverse DNS tree
would also need to be delegated from the RIRs down to the person controlling
the address space.

DNSSEC only makes the delegations of the tree used be more secure; it does
not mandate consistency checks between the forward tree, the reverse tree,
and routing sending the packets to the node.

> > I've certainly entertained ideas that are a lot weaker than NOID,
> > for instance just have the peers exchange their sets of locators
> > plus a cleartext cookie/context tag when the setup the state,
> > and then do a RR check before sending packets to a new locator,
> > but I've received pushback from folks that I wouldn't characterize as
> > security geeks, that this would be too weak.
> 
> I don't think this is universally true. Certainly, this is too weak for 
> TLS or IPsec sessions that can now be broken by an attacker, unlike 
> before. But why would this be too weak for talking to Google over 
> unprotected TCP/IP?

If I recall correctly, the main concern is when attackers and nodes move
around.

In today's if an attacker is on the path it can cause damage to the
communication if the communication isn't protected with something like IPsec
or TLS. But this ability to cause damage is limited to the time period while
the attacker is on the path.

If we add some multihoming signaling whereby an attacker, which was on
the path (e.g., by being on the same WiFi subnet as the victim) for a short
time period, can cause damage by essentially using the state creation 
as a way to preserve it's on-path'ness forever, then folks are concerned.
And since we want legitimate hosts/sites to have their communcation proceed
after a failure of the locator they used when the communication was initiated,
we can't require that a host is reachable at the original locator.

This is why Marcelo correctly points out:
>  From a security POV, how different do you think that this solution 
> would be from a solution based in mipv6 with infinite BCE lifetimes?

since it would have much the same security properties as mipv6 with
infinite lifetimes.
Thus for unsecured traffic the result would be weaker than today.
The importance of this weakness can be debated - and we don't have much 
experience with attackers moving around so it is hard to have a firm basis
for the debate.

But what you brought to the table is that if we can ensure that secured traffic
can not be redirected, by reusing the keys or otherwise "layering" on top of
IPsec or TLS, then at least we would know that secured traffic could never be
redirected by an attacker. So security-wise we'd gain some and loose some. 



> I suppose this wouldn't be much of a problem for IPsec. This could even 
> be done today by piping packets through a multihoming mechanism and 
> then take the resulting packets and feed them through IPsec. Obviously 
> this means more IPsec negotiation and state as now there must be an SA 
> for every locator pair used rather than one for the identifier pair.

Yes. And with IKEv2 or MOBIKE this might be easier - I don't know.

> I wouldn't want to try something like this with TLS, though. I'm 
> thinking more along the line of violating layers and modify IPsec/TLS 
> such that the wedge or modified IP can obtain keys that are exchanged 
> by modified IPsec/TLS. Something like putting the secret instructions 
> for the messager in the locked briefcase he's carrying. This works well 
> except for the first trip of course...

This sounds tricky. I guess I don't know enough how the TLS keys (and which
keys; is there some master key used to generate the RC4 key?, etc)
can be exported from TLS.

> > Thus something which is quite insecure (weaker than NOID as above) when
> > IPsec isn't used, but when IPsec is used it is as strong as with IPsec 
> > in
> > today's Internet.
> > Is anybody interested in exploring these ideas further?
> 
> Apart from me, you mean?  (-:

FWIW Doing the insecure signaling protocol for managing the contexts
is something I can do; a version of such a spec can be created by taking the 
NOID spec and removing the places where it verifies things in the DNS.
Saying it is layered above IPsec is also easy to say, but the difficulty
is exploring the interaction with IPsec and IKE, as well as TLS.

  Erik