Re: Security requirements for identification

[Dave Crocker <dhc@dcrocker.net>]

marcelo,

(I subscribe under different addresses, to multi6 vs. hipsec.  So my replies
are only making it to multi6. I think that that is the right venue for this
discussion. )


mb> Not really. Current mono-addressing IP security relies on routing (id=loc so
mb> if you trust the routing system then it will deliver the packet to the
mb> correct IP==ID)

The question is how the IP address is obtained. _Using_ an IP address when
there is multiaddressing also relies on the routing system to deliver the
packet to the correct IP address.

What is different is that multiaddressing introduces a way of _changing_ that
original IP address into another one. Although the sender still chooses which
IP address to use, the multiaddressing proposals all provide new, automated
ways of slipping those new addresses in.

So my point is that multiaddressing creates a security challenge not because
delivery is changed but because address selection is changed.  In the past,
address selection really was easy.  Somehow you decided on using one.  Then
you stayed with it.  Now you may not.


mb> So current mono-address ip does perform a verification that the other end of
mb> the communication remains the same in EVERY packet.
mb> This scheme of nonce validation only verifies the id of the other end at the
mb> begining of the communication (or when a new address is included).

With mono-addressing, the target gets a packet with a destination IP address
and validates that it -- the target -- is that IP address.  With multiaddress,
this does not change.

With mono-addressing, the target gets a packet with a source IP addresses.  It
might or might not "validate" it by sending a return packet.  With
multiaddressing, this does not change.

So, the per-packet validation that is created by adding a per-packet nonce
does a validation that is new. It well might be a useful validation, but it
really has nothing to do with multiaddressing.

I claim that the validation that needs to be performed, as a result of using
multiaddressing, is at the time of address _selection_. This is at the
initiator's side, prior to use. The only reasonable way to do that is for the
initiator to have a basis for trusting the pool of available addresses. Hence,
it is the process of building that pool that requires a serious validation
mechanism, not the process of using addresses from the pool.


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

Let's ask: What does the periodic exchange detect or fixe? It uses a secure ID
to ensure that the IP addresses being used are legitimately among the pool
associated with the endpoints belonging to their respective identifiers. More
importantly, it validates that things have not _changed_. What could have
changed between uses of the nonce?

Could the routing system have started sending packets with the same IP address
to a different place? If this is the concern, it certainly is legitimate, but
has nothing to do with multiaddressing.

Or is the concern that the IP address now being used for the target is not
valid? This is certainly a problem that already exists with monoaddressing,
but it is significantly exacerbated by multiaddressing, since multiaddressing
introduces an automated mechanism for adding new IP addresses to the pool.
However it is not the _use_ of the address that is the problem.

It is the event of adding a new target address to the initiator's pool of
addresses for the target. Regular use of the nonce in packets might detect a
failure condition. However, strongly protecting the mechanism for adding to
the pool will accomplish the same thing, and it will do it with lower packet
overhead. And it will do it as pre-hoc prevention, rather than post-hoc
detection.


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

My reference to DNS was simply not note that domain names serve as identifiers
and that the mapping to IP addresses is a process that is used with serious
expectations of validity. Yes, the packet service does not require you to use
it. But the application-level Internet really does rely on the validity of the
mapping.


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

mb> You do prove that you own the IP address, the routing system does it.

The routing system validates the association between the target (destination)
IP address as an address and the IP address as an identifier.

It does not validate the initiator (source) address. Any such validation is
performed by a return packet, using the larger context of the endpoint
association.


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

Sounds interesting, but I am not finding that in the I-D depository.


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