[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Security requirements for identification

Marcelo,

a) identification for mobility and multi-homing
-----------------------------------------------

As I wrote earlier, here we are only interested in gaining
assurance that the peer remains the *same*.  That is, we
do not really care *whom* we are communicating with, but
only that the peer end-point is not changed in mid-
communication.  (We probably did care the "real identity"
of the peer when we first initiated the communication, but
that is a different issue, with different security
requirements.)


I am not sure if i understand this...
I mean, we do care about recognizing the other end of a communication,
right?


Yes, we do care.  But we do not care for the very specific
purpose of "mobility and multi-homing", as I write.

A very important point in the analysis is to make a distinction
between identification in the beginning of a session,
and subsequent identifications that are needed during the
session, for various purposes.

Hence, the point is that _solely_ for *mobility* or *multi-homing*
you don't care about who, or any application level identity.
You only care about that the peer is not changed in mid communications.
Other parts of the system probably have other concerns, but not
the mobility / multi-homing mechanism.

Usually, when a host establish a communication, the host wants to establish
the communications with a certain host, it is not the case that we want to
communicate with any host available. So this is expressed by the ip address
of the target host. This means that we do care who the other end is.In other
words, IP addresses are used today for recognizing the other end.


Yes.  What you describe is what I called in the previous
analysis as "initial rendezvous".  Things do get mixed in
real life.  However, when you try to understand the roots
of phenomena, you have to make distinctions and draw lines,
even if sometimes they first seem bizarre.

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


I guess we always care with who we are communicating with i.e. we always
need a permanent identifier -


That may well be the case in most communications.  But _only_,
_solely_, _exclusively_ for mobility and multi-homing, you
do not *need* to care.

This may be deep, but this is one of the very points of the
analysis.  Make distinctions.

If you use a transient identifier, actually you are using two identifiers:
first the IP address as a permanent identifier to recognize the host and
then the transient identifier to recongnize the host when it changes its
address.


Now, that might be perfectly reasonable.  You are using the
permanent IP address for initial rendezvous, and then you use
a transient identifier to secure mobility.  In fact, that is
exactly what happens in Mobile IPv6 RO today.  You have the
home address, and you have Kbm, which is a kind of transient
identifier.

So i guess that what is needed is:
- a permanent identifier (so you can talk with who you really want to talk)

You need that for identification in the rendezvous sense.

- A locator (so you can reach it)

You need that for reachability, not for identification.

- something to bind them (which can be a transient identifier, but you can
use some other stuff)

Yes. But I haven't got that far yet :-)

So i would say that ephemeral identifiers are not enough to provide
identification support for multi-homing and mobility support, we need more,
i.e. permanent identifiers.


I think that we are not (yet) on the same baseline with respect
to understanding the various components in the game.

--Pekka Nikander