Re: Security requirements for identification

[Dave Crocker <dhc@dcrocker.net>]

Pekka,

I think I said this last time, but just in case:  thanks for working on
cohesive discussion about needs and issues for identification.  It makes it so
much easier to debate specifics...

My comments, below, are tuned for multiaddressing, since that it the
motivation du jour. If the scope of this discussion is meant to be broader
than dealing with mobility and multihoming, please forgive my error.


PN> a) identification for mobility and multi-homing
PN> As I wrote earlier, here we are only interested in gaining
PN> assurance that the peer remains the *same*.

yes.


PN> There are two basic dangers related identification in mobility
PN> and multi-homing.  One is connection hijacking,

yes.

PN> being noticed.  The other, less obvious one, is flooding.

I am only now finally understanding why this is a problem "created" by
multiaddressing.   Hijacking is directing traffic to oneself.  Flooding is
directing traffic to someone else.  One is to intercept data and the other is
to overload a victim.  Both problems are created by being able to ... redirect
traffic to a new address.

Thank you!


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.

At most, I suspect you really mean that there must be a "useful" confirmation
when a new target address is used for the first time. For example, if there
are nonce-based association identifiers,

    1) the initiator using the target address for the first includes the
    target's nonce in some sort of "hello again" packet, and

    2) the target responds with a packet containing the initiator's nonce.

This goes beyond the safety provided in current, mono-addressing IP, but
certainly is focused on problems caused (or exacerbated) by the introduction
of multiaddressing.

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

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

I believe the two terms can, and should, refer to two different things (unless
there is already an established practise of using them synonymously)

Rendezvous is a means of one endpoint finding another. It often uses a
third-party intermediary. It may or may not occur when there already is
context between the two endpoints.

Referral is a means by which one host in an association can replace itself
with another host.  That is, it transfers the association context to a third
host.


PN> If we assumed that everybody is honest, any unique bit
PN> string would serve well as an identifier.  The initiating
PN> party just sends the bit string to the target party, and
PN> asks the target party to verify that the bit string really
PN> is its identifier.  The problem is that we cannot necessarily
PN> assume everybody to be honest.

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.

However validly, we trust DNS entries and IP routing.  As soon as you worry
about whether to send an identifier in the clear, you are considering
something far broader than problems caused by multiaddressing.


PN> In the first case, the only secure way of performing
PN> identification seem to be public key cryptography (or any of
PN> its variants, like zero knowledge protocol).  The reason for
PN> this is the following.  Since the identifier is public
PN> knowledge, we cannot use the identifier directly.

Today, we use domain names and IP addresses in the clear.  And things work
pretty well.

To use Marcelo's phrasing, we do not "prove we own" the domain names are IP
addresses we use.

So, why must we start encrypting identifiers?

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>