Subject: [Hipsec] RE: About identifiers, HITs, and security (was Re: A roadmap for end-point identifiers?)

From: [email-masked] (Michel Py)
Date: Tue Sep 16 00:18:01 2003

Pekka,

> Pekka Nikander wrote:
> I don't remember any more what might have been the reasons
> for having more bits.  Could you please remind me?

Darn, I was hoping _you_ could refresh my memory.
I think that there were two things: crypto and hints about the locators.

If my recollection is correct (which can be doubted) here it is:

- For HIP, one of the issues you have is latency with the initial
negotiation, and I think I remember you saying that you could use some
extra bits to embed some crypto in order to reduce the number of round
trips necessary. Or maybe that is what you wished you had if you were to
apply HIP security to MHAP, can't remember.

- For MHAP, there were two things I think: 1. I had wished at some point
that I could embed a part of the locator's address in the identifier in
order to provide enough clue to take a crapshoot at bypassing the loc/id
centralized mapping. 2. We discussed CGIs and came to the conclusion
that besides the Intellectual Property issues with them there was no way
to make them workable with the MHAP identifier being only 128 bits.

Michel.

From IPV6 WG <[email-masked]>,
 Pekka Nikander <[email-masked]>  Tue Sep 16 02:14:00 2003
From: IPV6 WG <[email-masked]>,
 Pekka Nikander <[email-masked]> (Pekka Nikander)
Date: Tue Sep 16 01:14:00 2003
Subject: [Hipsec] What end-point identifiers are needed for?
Message-ID: <[email-masked]>

[Cross-posting to hipsec since this analysis seems to
  be important for HIP, too.  CC:s appropriately, please.]

The recent discussion on the ML has led me to believe
that we have a fairly poor understanding on what we
are speaking about.  (Dave Crocker has also privately
pointed this out, thereby making my mind clearer.)
This is yet another strawman attempt to try to clarify
the  problem scope, or at least something.

After some thought, I think that we have at least
three main classes of needs for (loosely speaking)
end-point identifiers, and some subclasses:

   1) Identification

      1a) identification for the purpose of mobility and
          multi-homing

      1b) identification for the purpose of referral
          or rendezvous (related to 1a but slightly
          different)

      1c) identification for other, e.g. administrative,
          purposes

   2) Referral

   3) Rendezvous

      3a) initial rendezvous with no existing connection

      3b) subsequent rendezvous, e.g., after concurrent movement

There are probably others, but these are the ones that
my poor brains managed to (small pun) identify.

The *point* of this mail is that the different needs have
different requirements, and that it may be very difficult
or even impossible to design one class of identifiers that
would fulfil all of the primary needs plus the related
secondary needs, such as privacy and security.

Let me try to brefly analyze the above outlined needs
one by one, in reverse order.

3) Rendezvous
-------------

I haven't seen any good definition for rendezvous in the
meaning that we seem to be using it.  (If you have, please
post a reference).  So, here is an attempt:

   End-point rendezvous refers to the situation where
   one end-point makes a contact with an explicitly identified
   other end-point over the network.

To be able to perform rendezvous, the first end point seems
to need

   - a means to identify the second end-point (1a or 1b)
   - a means to reach the second end-point, i.e., locator

In the case of 3b), the end-points have been in contact
with each other and share explicit "fresh" state.  Hence,
they can identify each other just based on this state,
and they do not necessarily need any stable, long-living
end-point identifiers.  Due to mobility, they need a
service that gives the currently active locator for the
other end-point, i.e., the equivalent of mobile IP home
agent.

In the case of 3a), the end-points have not been in contact
with each other, and the only "state" that they share is
that the first end-point has an identifier that denotes
the second one.  The service giving locators does not seem
to be very fast or dynamic, as long as the given locator
will reach the given end-point.  That is, if we have the
equivalent of mobile ip home agent, the locator used for
3a) can be the equivalent of mobile ip home address.

2) Referral
-----------

Again, I haven't seen any good definitions (and again,
please post if you have).  Another attempt:

   Inter-end-point referral refers to a situation where one
   end-point hands over information about a second end-point
   to a third end-point, with the purpose of allowing the
   third end-point to make a rendezvous with the second end-point.

For referral to succeed, the transferred information must give
the receiving end-point

   - a means to identify the second end-point (1b)
   - a means to reach the second end-point

Note that in this case the "means to reach" does not need
to be a locator.  It can be a name that the rendezvous (3b)
service is able to convert to a locator.

1) Identification
-----------------

Now we get to the real business.  Just to refresh the mind,
here are again the suggested subclasses:

   1a) identification for mobility and multi-homing
   1b) identification for referral or rendezvous
   1c) identification for other, e.g. administrative, purposes

1a) To me, identification for mobility and multi-homing seems to
     be the easiest one.  There we are only interested in gaining
assurance that the peer remains the same.  That is, for the
sole purpose of mobility or multi-homing, we do not really
care with whom we are communicating with, but only that the
peer end-point is not changed in mid-communication due to
mobility, multi-homing, or attacks based on mobility or
multi-homing mechanisms.

[There is also the need of keeping the apparent identifier to
  TCP or UDP stable, but that is really a secondary need, created
  by the desire of backwards compatibility.]

For the purposes of 1a) it seems to be sufficient to create
an ephemeral identifier, only known to the participating end-points
(and a sufficiently limited class of potential attackers).
There is no need for long-lasting stable identifiers.

Identification at the mobility related rendezvous (3b) is
really a special case of the generic mobility related
identification, and therefore the argumentation above holds.

1b) For initial rendezvous and referral, we need something stable.
     That is, we need to have an identifier that allows us to
identify the peer end-point even if it does not share any state
(but the identifier/identity) with us.

Note that I have explicitly separated the function of locating
the end-point from the function of identifying the end-point.
For rendezvous and referral we naturally need both.  However,
they are distinct functions, and it is technically *possible*
to use different tokes for these purposes.  On the other hand,
if there is a need for two tokens, we can also define that the
end-point identifier (for referral or initial rendezvous)
consists of a *pair* of tokens, ones used for identification and
one used for finding the current address.

1c) The final class of needs for identification seems to have
     nothing to do with mobility, multi-homing or even referral
or even rendezvous.  There are other needs for identifying
end-points:
   - Human GUI needs: to allow humans to type in names that
     refer to end-points
   - Various administrative needs:
      - configuration management
      - inventory management
      - monitoring and intrusion detection
      - etc.
   - (running out of coffee....  can't think of others)

-------------------------------------------------------------

The next step is to analyse the security and privacy threats
associated with all of the above mentioned needs for identifiers.
However, that is a subject of another mail.

--Pekka Nikander

---

From: [email-masked] (Pekka Nikander)
Date: Tue Sep 16 01:34:00 2003

Michel,

[Removing ipv6 from CC: list]

> apply HIP security to MHAP, can't remember.

I don't think it is possible to redure round trips in HIP base
negotiation.  However, I really need to read Hugo's sigma paper
http://www.ee.technion.ac.il/~hugo/sigma.pdf
at some point of time.

> to make them workable with the MHAP identifier being only 128 bits.

I guess you mean CGAs.

What comes to embedding locators, that would work only for a limited
set of identification purposes (see my separate mail).  In general,
I think such embedding is a bad idea, and it would be better to use
structured identifiers, i.e. <security identifier, locator> pairs.

I vaguely remember our discussion about CGA vs. HIP, but I don't
remember any of the outcome.  Sorry.

--Pekka Nikander