Subject: Re: identifiers and security

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jun 2004 04:52:19 -0700 (PDT)

[Still catching up on older mail]

> As I've said before, I think it would be useful to allow for 
> multihoming solutions that add a new identifier space, and also for 
> multihoming solutions that don't. (The new identifier space may or may 
> not be expressible as something that looks like an IPv6 address, but if 
> it is, it's not a routable IPv6 address.)

Agreed.

> The advantages of not having identifiers are that it's easier to be 
> backward compatible and less new stuff to worry about.

This is a terminology nit, but I think all approaches to multihoming
support have some identifier - whether it is a FQDN, or a list of locators.
What is interesting is whether there is a new ID name space, as you said in
the first paragraph, and whether those IDs are visible to the applications.

> The irony of explicit identifiers is that they are so insecure, that 
> they must be protected using strong security, so they effectively 
> become more secure than any identifierless solution. The reason 
> explicit identifiers are insecure to start with is that without a 
> secure mapping mechanism of some sort, a correspondent is unable to 
> determine whether someone claiming to hold an identifier is the 
> legitimate owner of this identifier.

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. 
So I think it is inevitable that providing "do no harm" security for
the multihoming will accidentally improve security a bit in some cases.

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.
But perhaps it is time to writeup something like that and subject it
to wider scruteny, combined with your suggestion below.

> I think it's important to recognize that "regular" IP operation without 
> the benefit of IPsec, TLS or similar authentication and what comes with 
> it (such as SSH) is very often insecure, and in most cases this isn't a 
> problematic situation. So mandating strong security in all situations 
> is probably a mistake. However, IPsec/TLS and the like are in wide use 
> for communication that must remain confidential. In those cases, the 
> key management problem is solved in some way or another. It would be 
> very beneficial to take advantage of this situation and leverage IPsec 
> or TLS mechanisms that are already in operation towards securing 
> multihoming. One way to do this is taking the IPsec or TLS "identifier" 
> and use it as the multihoming identifier. Architecturally this is a 
> nice approach, but in practice it will be hard to get off the ground, 
> especially with TLS as it's not always possible to determine the 
> authenticity of a single packet with TLS. Another approach would be to 
> exchange a session key that's protected using the IPsec or TLS that's 
> already there and protect the multihoming exchanges using this session 
> key.

I've been trying to layer things so that IPsec and TLS benefit from
the multihoming support by sitting above the layer that handles the
multiple locators, and HIP essentially is layered in the same place.
So perhaps one should explore, taking into account IKEv2 and MOBIKE work,
an approach which layers the multihoming support above IPsec when IPsec
is used?

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?

  Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Jun 2004 17:23:19 +0200

> support have some identifier - whether it is a FQDN, or a list of 

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?)

> the first paragraph,

Yes.

> 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. There are other values that 
may not be visible to the application and relevant, though. (And some 
of you may prefer to call those identifiers, but then we need another 
term for the application-visible values.) There are many places in the 
stack where (currently) the same bit string performs different 
functions. If we make the identifier/locator split this immediately 
begs the question whether that's enough, maybe we need to dig deeper. I 
tried to look at this a while ago in my "9 steps" (or similar) message.

> will also result in stronger association between FQDNs and locators

Even if we assume DNSSEC?

> the multihoming will accidentally improve security a bit in some cases.

Beware of stuff you get for free...

> 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?

> to wider scruteny, combined with your suggestion below.

Right.

> an approach which layers the multihoming support above IPsec when IPsec

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.

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...

> Is anybody interested in exploring these ideas further?

Apart from me, you mean?  (-:

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 28 Jun 2004 17:46:51 +0200

> 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?
>

 From a security POV, how different do you think that this solution 
would be from a solution based in mipv6 with infinite BCE lifetimes?

i mean, a RR solution would likely be very similar to the HoTI/HoT and 
CoTI/CoT exchange of mipv6, right?

regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jun 2004 05:04:24 -0700 (PDT)

> than one identity) is a very bad idea. (X.400 anyone?)

Fair enough. 

> 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.

> 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.

> before. But why would this be too weak for talking to Google over 

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.

> 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. 

> 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.

> 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.

> 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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Jun 2004 10:43:54 +0200

> but that wasn't the point I was trying to make.

Ok.

> Assume DNSSEC for the baseline (current Internet), for NOID, or for 

Compare NOID without DNSSEC with DNSSEC without NOID. I think the 
latter provides stronger FQDN -> address and address -> FQDN 
information although you are right that this isn't the same as FQDN <-> 
address.

>>> I've received pushback from folks that I wouldn't characterize as

>> for

> as a way to preserve it's on-path'ness forever, then folks are 

And justifyably so. But wouldn't it be possible to address this in 
other ways? Such as having per-direction or even per-session state 
rather than per-address?

> redirected by an attacker. So security-wise we'd gain some and loose 

I think if the redirection problem by attackers that are on-path 
temporarily is limited to individual unprotected sessions, we are not 
materially worse off than today as the same attacker could break the 
sessions today also, and redirecting an unprotected session presumably 
isn't worse than breaking it as the contents aren't secret.

>> I'm thinking more along the line of violating layers and modify 
>> IPsec/TLS

> This sounds tricky.

:-)

> I guess I don't know enough how the TLS keys (and which

I don't know the specs by heart but the way I understand it is that you 
have a public/private keypair for at least one end of the connection. 
This key pair is used to create a session key which is subsequently 
used for encryption. The same key or maybe a different one is used for 
authentication. TLS works with blocks that may span several TCP 
segments. Since there is significant housekeeping, I'm assuming it 
would be possible to define a new message type that can be exchanged 
between the two hosts without getting in the way of existing operation 
(negotiation or data transfer). All that would need to happen here is 
for each side to announce a session key that can be used for 
multihoming to the other side. Since this information is encrypted, 
signed and delivered over reliable transport, there isn't much more to 
it. It would of course also be possible to use TLS's own session key, 
but that's probably dangerous as it may more easily leak and that key 
is subject to renegotiation.

> is exploring the interaction with IPsec and IKE, as well as TLS.

Right. What did you think about my IPsec/TLS/DNS musings? This would 
provide pretty much the above using unmodified NOID. The IPsec/TLS 
stuff doesn't get easier this way but it's more modular and it also has 
other benefits (can do TLS when the DNS is down, at least in theory) so 
it may be easier to get off the ground.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jun 2004 07:52:16 -0700 (PDT)

> other ways? Such as having per-direction or even per-session state 

If you assume that there is an upper timelimit on how long a (TCP)
connection can last one could take such an approach.
But as far as I know the designers of TCP didn't envision such
an upper limit, thus some connections might last forever.

> isn't worse than breaking it as the contents aren't secret.

I think there is a difference between
 - someone breaking into to office looking at the pieces of paper on
   my desk
 - someone breaking into my office and installing a device which allows
   them to look at all future pieces of paper I will place on my desk

Thus there is a difference between looking at unprotected communication
while being on the path, and looking at unprotected communication
long after having left the path.
But this might be a case where we can make things be slightly worse than
in today's Internet since this communication was unprotected in any case.

  Erik