Subject: RE: Notes about identifier - locator separator

From: "Christian Huitema" <[email-masked]>
Date: Fri, 8 Nov 2002 10:13:09 -0800

> > There are a couple of issues with any proposal of that nature, and
the
> > main one is privacy. Having a unique identifier exposed to the
network
> > means that anybody on the path can track the presence and location
of
> > users, with consequence ranging from annoying (e.g. variations of
> > telemarketing) to downright dramatic (e.g. missile auto-aining to a
cell
> > phone). To meet the privacy requirement, you would want addresses
(as
> > incorporated in the header) to disclose as little as possible about
> > their owner. In a mobility or multi-homing situation, you may well
want
> > to hide from the network any correlation between addresses that
happen
> > to be used by the same entity.
> 
> Indeed.  I've been engaged in a heated discussion about this
> off-line for some time now.  Some people seem to be so worried
> about terrorism that they don't acknowledge the privacy concerns,
> and don't believe in the possibilities of cryptography at the
> same time.
> 
> The current HIP design sends the identifiers in clear text
> only in the first four packets (the HIP handshake).  It
> also includes the possibility of using pseudonyms (i.e. multiple
> identifiers).  Furthermore, we are considering schemes where
> it would be possible to hide (cryptographically "blind") the
> identifiers even in the first four packets iff the parties know
> each other beforehand, i.e., have communicated before and have
> the peer's ID stored.

The obvious blinding is to perform an end to end Diffie-Hellman exchange
before disclosing any identity, as is performed in IKE.

> What's the other issue(s) (the other half of the "couple of issues")?

The other obvious issue is that 64 bit is, for any cryptographic
purpose, a relatively small number size. It may be OK now, when the
average processor clock is a few GHz, but 64 bit hashes will be
trivially broken in 5 to 10 years. This implies that a strict 64+64
split is probably not a very good idea.

My main point is that if we want to use end point identifiers
independent of the locations, these identifiers should be strictly "end
to end", and should not be exposed to network elements.

-- Christian Huitema

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 08 Nov 2002 21:48:00 +0200

>> ....  Furthermore, we are considering schemes where

But of course.  However, D-H has its problems, too.  Firstly,
it hides the identifiers also from legitimite middle boxes.
Secondly, it is computationally expensive; sometimes (but not always)
too expensive.  Thirdly, the obvious ways of performing D-H
still require that one of the ends reveals its identity before
the other one does.

Thus, there is space for looking at alternative schemes.

> split is probably not a very good idea.

I couldn't agree more.  HIP uses 126 (or 127) bit hashes as its
public IDs, and there is no reason why it couldn't use longer ones
in the wire format.

What comes to CGA, you are probably aware of the later developments
by Tuomas Aura that effectively lengthen the hash length, on the
cost of longer address generation time.

> to end", and should not be exposed to network elements.

Again, I couldn't agree more in principle.  However, I also
think that there are cases where some middle boxes do have legitimite
access to the identifiers.  Corporate firewalls come to my mind.
Firewalls may not be the architecturally ideal way of doing
perimeter defence, but I don't think that they are going away.
Instead, I think that they are just going to adapt to the changing
conditions, and that security protocols should be developed with
them in mind.

To be more precise, I think that some it is acceptable that iff
a middle box can reliably predict the identifiers, it can check
if a (initializing) packet indeed carries that ID in a blinded
form.  On the other hand, if the middle box does not have such
a priori information, it should be computationally infeasible
for it to learn the ID.

--Pekka Nikander