Subject: Re: [mobile-ip] -New ID about Address owernship-

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 12 Apr 2001 14:37:53 -0700 (PDT)

> X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to 
[email-masked] using -f
> From: Francis Dupont <[email-masked]>
> To: [email-masked]
> Subject: Re: [mobile-ip] -New ID about Address owernship- 
> Date: Thu, 12 Apr 2001 02:22:09 +0200
> List-Archive: <http://playground.sun.com/mobile-ip/>
> List-Owner: <mailto:[email-masked]>
> List-Subscribe: <mailto:[email-masked]?body=subscribe>
> List-Unsubscribe: 
<mailto:[email-masked]?body=unsubscribe> If SUCV 
addresses are used in a very temporary way (RFC 3041
> 
> with a new address per connection for instance) the computation
> of the public/private key pairs can become very expensive...

But this implies that the identifier part of your home address
changes too. So, i don't understand how this would work.

-mohan

>  But the document does not specify what is the format of the
> public part (the argument of the hash function) so I suggest
> to add a random part in it:
>  - i.e. hash(public-part) becomes hash(public-part || random-value)
>  - the random part should large enough in order to avoid (hash) collision
>    with the same key pair (so 64 bits again?)
>  - the same argument proves that the random part should be really random
>    or an attacker can harm with collisions (*)
>  - short term new ID should be done with a new random value, long term
>    with a new key pair
>  - in case of a (real) collision to provide a new random value is
>    far cheaper than to compute a new key pair
>  - analysis (section 4.4) is based on the hash function strength and
>    result space so the introduction of a random part won't change this.
> 
> (*) weak attacks because if the bad guy can know the public key and
> can guess the random value he doesn't know the private key so the
> signature check will fail (i.e. there is room only for a DoS attack).
> 
> Regards
> 
> [email-masked]
> 
> PS: in 5.0 the IID should not have the 'u' bit set because the low HIT-64
> is not really *universally* unique. The 4.4 argument doesn't apply because
> there are/will be more than 3*10^9 MAC devices in the Universe...
> In fact this doesn't really matter because the low part of HIT-64 has
> no need to be universal?
> PPS: in 4.4 the argument about collisions is valid only in the Mobile IPv6
> context, i.e. you shan't bet one million dollars on it. The context should
> be recalled in the last statement (just in order to avoid misuse of your
> nice proposal in a very different context :-).

---

From: Francis Dupont <[email-masked]>
Date: Fri, 13 Apr 2001 11:33:50 +0200

=> if you want to use a temporary address and mobility you have
to get a temporary care-of address and home address pair and
to send a home registration (I assume we have a cheap way to
add secondary home registrations for an already established MN-HA SA).

Regards

PS: the only issue is that sending of BUs will reveal the current public
key so if the key is reused one can discover the node is the same but:
 - the key is only in one (or a little number of) packet(s)
 - to send BUs is optional (I assume home registrations are protected
   for confidentiality)

PS (about assumptions):
 - the first point works if a mechanism for secondary home registrations
   is added (a sub-option for secondary home address). Such a mechanism
   can be useful if we want to get better control on the home address set
   (today there is only the prefix length stuff: one address or all
   addresses according to home prefixes).
 - the second point works with a confidentiality protection of all
   parameters as provided by ESP on the MN-HA reverse tunnel.

PS (basic note): to use a temporary care-of address with a permanent
home address (or the opposite) gives no privacy at all. For a specific
discussion about mobility and privacy you can read (it will be updated ASAP)
draft-castelluccia-mobileip-privacy-00.txt