RE: Security requirements for identification

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

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

Not really. Current mono-addressing IP security relies on routing (id=loc so
if you trust the routing system then it will deliver the packet to the
correct IP==ID)
So current mono-address ip does perform a verification that the other end of
the communication remains the same in EVERY packet.
This scheme of nonce validation only verifies the id of the other end at the
begining of the communication (or when a new address is included). So, it is
stronger for the moment when this exchange occurs, but it opens the
possibility of attacks shifted in time, since this scheme does not verifies
the identity all the time.
So, the nonce based scheme it is stronger in one sense but it is weaker in
another sense

(To overcome this issue, mip demands a periodical exchange of nonces so that
the identity of the other end of the communication is verified periodically)

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

I don't completelly agree.
Today you can establish a communication using only an IP address (you can
avoid using the DNS for security reasons)
So i don't think is reasonable to say that all ip addresses are as weak as a
communication that involves a dns query (if we can say this, the security
problems would be greatly reduced).
I do agree with the routing part.

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

You do prove that you own the IP address, the routing system does it.
About the DNS, see my comment below i.e. you can establish a communication
without using the DNS today and i don't think it is reasonable to design a
solution imposing the dns security level to all possible communications.

(BTW I read the address ownership expression fro the first time in Pekka's
draft "An Address Ownership Problem in IPv6"
(<draft-nikander-ipng-address-ownership-00.txt>))

Regards, marcelo

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