Re: Security requirements for identification

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

Dave,

PN> Hence, for the purpose of mobility and multi-homing, the
PN> identification mechanism has to keep sure that the peer really
PN> remains the same, on all changes of locators.  Furthermore, the
PN> mechanism must not blindly trust what the peer claims about its
PN> locations, but must check that the same peer really *is*
PN> at all the claimed addresses.

> Hmmm. Carried to the extreme the requirement seems to specify would
> probably require having every packet be encrypted -- so it could only
> be decoded by the correct recipient -- and acknowledged with a
> signature.

Yes.  But going such extreme is probably silly.  See my previous
message on the same topic.

PN> b) identification for referral or rendezvous

PN> In the case of referral or rendezvous, an initiating party
PN> possesses an identifier that it wants to use as a means
PN> of identifying another party.
> In spite of the above language, you do not define rendezvous and
> referral. 

I tried in my previous message to ipv6 list, but apparently failed.
Especially, my definition for referral there and yours below
do not match:

> I have been assuming the latter means "moving an
> association from one endpoint to another". That is, "hand off" of one
> end of an association to a new endpoint.

We clearly need two different words for two different actions:

  1. Handing over an "identifier" from one end-point to another,
     with the intention of the receiving end-point being able to
     contact the "identified" end-point in the future.

  2. Handing over an end of an (active) association from one
     end-point to another.

I was using the term "referral" in the first sense, while you
seem to be using in the second sense.

> So, please clarify what you mean by both terms and how they relate to
> the distinction between identifying versus locating.

Maybe you want to reread my message to IPv6:
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg00056.html

I tried to give definitions there, but seem to have failed.

PN> If we assume dishonest parties, we get two sub cases.  In
PN> the first case, the initiating party must send the identifier
PN> in clear, for some reason, or the identifier is otherwise
PN> public and known by the dishonest parties.  In the second
PN> case, the initiating party is able to keep the identifier in
PN> secret.

> This line of thinking appears to go quite a bit beyond the current
> world of IP mon-addressing.  And I believe it involves concerns not
> created by multiaddressing.

Well, certainly I go well beyound the current architecture.
I am trying to figure out what we need to do if we really separate
identifiers and locators, and cannot rely on the routing infrastructure
to provide any kind of security for the identifiers.  In other
words, the current practise where IP address are also identifiers
is good from a security point of view.  It just doesn't work well
with multi-addressing.

I tried to outline four possibilities:

  - create another kind of an infrastructure to "secure" identifiers
  - use "self-securing" identifiers, i.e., public keys
  - use a PKI
  - go only half way, somehow still relying on the routing
    infrastructure

(Note that I am putting "secure" and "self-secure" in quotes since
I am using them here in a purposefully vague way.  We still don't know
what the real security goals are, other than this "no worse than
mono-addressing IPv4" statement.)

It may well be that I go beyound multi-addressing.  In fact, I don't
so much care just about multi-addressing, but really understanding
the consequences of the id/loc split.

--Pekka Nikander