RE: Security requirements for identification

["marcelo bagnulo" <marcelo@it.uc3m.es>]

Pekka,

> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Pekka Nikander
> Enviado el: jueves, 25 de septiembre de 2003 9:29
> Para: mbagnulo@ing.uc3m.es
> CC: Multi6 WG; hipsec@honor.trusecure.com
> Asunto: 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.
>

Ok. I think i see what you mean.

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

Ok

> > - A locator (so you can reach it)
>
> You need that for reachability, not for identification.
>

Ok

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


Well, i been re-considering this point and i think i would like to re-state
it in the following way.

I guess that identifiers make sense if you can prove that you own them.
I mean i can tell you that i have identifier A but if i cannot prove that i
own it it isn't really useful.
So, usually we use IP addresses as identifiers, and the proof of ownership
is provided by the routing system.
Now the problem is that when we move or change the path to alternative
provider, we connot longer prove that we own our identifier.
So here is when a ephemeral identifier can help, since you can start using
the permanent idenfitifier (ip address) when you are capable of proving its
ownership, and at this moment create an ephemeral identifier, which you can
prove that you own by other means than the routing system i.e. crypto. And
then just forget about the permanent identifier and keep track of the
identity of the other end by just using the ephemeral identifier.
So, you don't need the ephemeral identifier to make a safe mapping to a
locator, but you need it to provide an alternative identifier whose
ownership can be proven when you cannot longer prove the ownership of the
permanent identifier.

Obviously, you could just solve the problem by using an identifier that
doesn't uses the routing system in order to prove its ownership, and it uses
a location idenpendent mean to prove it (just like public keys ;-)
However, the problem of initial rendezvous remains in this case.



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

I think that your postings are being really useful to understand these
issues.
Thanks, marcelo

> --Pekka Nikander
>
>
>
>
>