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

From: Claude Castelluccia <[email-masked]>
Date: Wed, 11 Apr 2001 20:09:21 +0200

Hello,

We have just submitted a new draft that addresses the address owernship
(and the redirection authorization) problem of Mobile IPv6 using a "HIP
based solution".....

This draft is available at:
http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-00.txt

thanks in advance for your comments,
regards,
Claude.

Abstract
   This document addresses the identifier ownership problem.  It
   does so by using characteristics of Statistic Uniqueness and
   Cryptographic Verifiability (SUCV) of certain entities which
   this document calls SUCV Identifiers (SUCV ID's).  This note
   also proposes using these SUCV characteristics in related
   entities called SUCV Addresses in order to severely limit
   certain classes of denial of service attacks and hijacking
   attacks. SUCV addresses are particularly applicable to solve the
   'address ownership' problem that severely undermines confidence
   in mechanisms like Binding Updates in Mobile IP for IPv6.

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 11 Apr 2001 22:06:50 +0300

Claude,

>    this document calls SUCV Identifiers (SUCV ID's)....

Basically similar solutions have been coined already a few times so far.
First, Greg O'Shea and Michael Rose came to the same solution last
summer, and their work is now being published at this month's ACM CCR.
They call their solution Child-Proorf Authentication for MIPv6 (CAM).
(I learned about their work yesterday.)

Second, I came (independently) to the same solution in February this
year, and then went a little bit further than Greg and Mike went.
I still haven't had time to publish my results, but an informal
not-quite-ready draft has been available since Minneapolis at
http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-pbk-addresses-00.txt 

Furthermore, Gabriel Montenegro says that he's came to the same result
as well, but I haven't seen him putting his version of the idea into
a form where you could easily read it.

I think it might be worth to see if we could join our efforts.  What
do you think?  

--Pekka

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 11 Apr 2001 15:41:43 -0400

>a form where you could easily read it.

check the author name in the draft.  This IS Gabriel's ideas.  He and I 
discussed this at IETF.

---

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 11 Apr 2001 14:24:20 -0700 (PDT)

Hi Claude,

In section (2.2) where you discuss PBK :

   2. Generate an EID = hash(public component)

       a. the initiator sends EID to responder along with initial
          protocol exchanges.

       b. the initiator sends public component to responder along
          with subsequent exchanges.	

   Notice that the exchange at step 2 must be secure in order to
   avoid intruder-in-the-middle attacks, but it is an improvement
   over cookies.

Could you explain how you are communicating the public key securely
in your protocol ? I have not read all the details of HIP, so
i could be missing something.

And also what prevents from someone intercepting msg2 other than the
original MN and establish the secret ?

-thanks
mohan

---

From: Francis Dupont <[email-masked]>
Date: Thu, 12 Apr 2001 02:22:09 +0200

with a new address per connection for instance) the computation
of the public/private key pairs can become very expensive...
 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: Thu, 12 Apr 2001 19:37:06 +0200

Note I am not (yet) a member of the hipsec list so if
this mail bounces it should be reposted in the list...

I have a concern about to use the HIP stuff for the mobile IPv6 security
because HIP was designed to "rapidly establish an ESP Security Association"
so it is very powerful but expensive:
There is significant overhead associated with building HIP-based SAs
(both in terms of CPU cycles, but also in terms of required message flows)
This has negative implications for larger servers that process many 100s
of thousands of connections at a time or for smaller mobile nodes that
are short in processor and battery resources
(you have recognized the argument :-).
An illustration: HIP provides a good protection against DoS attacks,
in fact this is not really an advantage: HIP must provide this because
HIP mechanisms involve a lot of powerful/expensive crypto which could
make DoS attacks very prejudicial... The less drafty draft uses only
SHA-1 which is far less expensive: the exact requirements for mobile
IPv6 security are not yet available but HIP seems to overfulfill them.

BTW I like very much the SUCV address idea but section 6.1 should
be simplify/adapted (i.e. not cut&pasted from the HIP document).

Regards

---

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

>(you have recognized the argument :-).
   
   Similar to WTLS 1.2
   What kind of server maintains 100,000s of concurrent connections?

=> ask IESG (:-)!

   >make DoS attacks very prejudicial...
   
   Any key exchange mechanism adds to the risk of DoS attacks, but a well 
   worked out mechanism should also remove exposure to transport level attacks.
   
   For MIP's initial usage of HIP only being used for BUs, HIP's goal would be 
   to protect the BUs and give the CN's trust in them.
   
=> my concern is that HIP does too much. As soon as the exact requirements
will be available we'll see if HIP is above, below or just at the good level
of protection/complexity. I believe that it will be above like IKE is
according to IESG...
This is not about the merits of HIP but my concern is different: is HIP
the right tool for mobile IPv6 BUs with random CNs.

   >  The less drafty draft uses only SHA-1 which is far less expensive: the 
   > exact requirements for mobile IPv6 security are not yet available but HIP 
   > seems to overfulfill them.
   
   To the later, that it may.  SHA-1 is less expensive than any PK crypto, no 
   one can argue that.  Does 'drafty draft' meet reasonable security 
   requirements?

=> we need to get the requirements before judging...

   I offer HIP for a number of reasons:
   
   I am working on HIP for secure Internet model that understands 'addressing 
   realms' (like IPv4and v6 co-existing and NAT traversal) and flexible
   mobility.
   
=> but HIP itself doesn't support the mobile-to-mobile case (it lacks
a fallback mechanism or if you prefer HITs are not routable).

   It is HARD to get a trusted binding between two hosts.  Shortcuts tend to 
   be longcuts, in that they are later found to be flawed; 'good enough' (look 
   at WEP) can end up being no protection at all.  HIP has had a reasonable 
   peer review and is itself based on other mechanisms like SSL, IKE, SKIP, 
   and Photuris.
   
=> the issue is not that HIP is too weak, it is that HIP is too strong.
From the security point of view IKE can fulfill all the requirements
of Mobile IPv6 but it is incredible expensive to use (the first home
registration from a visited network (the first thing the mobile does)
works well, including between different implementations, but has
abyssal performances). It can rely on a global PKI too (like DNSsec).
All the arguments used against IPsec/IKE applies to HIP too...

   >be simplify/adapted (i.e. not cut&pasted from the HIP document).
   
   I do not know if SUCV will be secure, I am studying it.

=> I believe it is secure enough for temporary addresses (military
argument: short term informations need less protection than long term).
We have to see for permanent addresses in the mobile IPv6 BUs to random CNs
context.

   The opportunistic mode of HIP needs further development and I am doing that.

=> this is an important point because "a global PKI is not available and
perhaps not desirable" (quoting Jeff Schiller).

   Consider for a moment where a BU HELLO is equivalent 
   in HIP to the I1 HIP packet.  Also note that an optimization of HIP could 
   allow for a data payload INSIDE of I2 (but not appended after, as the 
   intiator does not get the responder's SPI until R2).
   
   The ESP transform used in MIP for BUs could be ESP NULL with 
   HMAC-SHA1-96.  Once the initial HIP exchange is completed, ESP is used for 
   all future exchanges until either a timeout (could be set fairly long here) 
   or loss of state (CN or MN boot).
   
=> I believe the divorce is complete between IPsec and Mobile IPv6 people,
i.e. the BUs auth* will be provided by an ad-hoc mechanism, not by an
IPsec transform...
But if you read the less drafty draft you can find an ESP protection
for the HA-MN tunnel. This is a VPN-like case so it is apparently readily
supported by the current generation of IPsec/IKE implementations (:-).
But the MN (by definition :-) can move so we have again the SA
rebuild/update issue: HIP can be very useful there and as the HA never
moves we don't fall in the mobile-to-mobile hard case.

   HIP as written in my 3 IDs is a full protocol.  There is much that others 
   can do to target it to particular opportunities.
   
=> even if HIP is not suitable for the random CN case there are some others:
 - not random CNs (same than the random CN case but with a common PKI
   or a common trusted third party)
 - permanent home registration (common PKI, trusted third party, AAA, ...,
   but as this is the principal mechanism (previous cases are optimizations)
   this is critical for both security and performances)
 - temporary home registration (the smooth hand-off case) (AAA credentials,
   all involved entities on the same link).

Thanks

PS: any mechanism which can reconcile IPsec (mainly ESP tunnel transform :-)
and mobility based on addresses is *wellcome*!

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 12 Apr 2001 15:58:40 -0400

>this mail bounces it should be reposted in the list...

it got through.

>(both in terms of CPU cycles, but also in terms of required message flows)

much less than IKE.
4 packets, as defined.
DSA/RSA and D-H operations in line with SSL/TLS

>(you have recognized the argument :-).

Similar to WTLS 1.2
What kind of server maintains 100,000s of concurrent connections?  These 
typically have hardware boosts of all kinds, particularly if they are doing 
things like SSL already.

To the later, that it may.  SHA-1 is less expensive than any PK crypto, no 
one can argue that.  Does 'drafty draft' meet reasonable security 
requirements?  There are others better than I to evaluate it; some of them 
evaluated HIP and help me get its security complete.

I am working on HIP for secure Internet model that understands 'addressing 
realms' (like IPv4and v6 co-existing and NAT traversal) and flexible mobility.

>be simplify/adapted (i.e. not cut&pasted from the HIP document).

I do not know if SUCV will be secure, I am studying it.  Allowing a HIT 
that is an SUCV is a no-brainer, and if it makes sense (as I told Gabriel) 
consider it done.  The opertunistic mode of HIP needs further development 
and I am doing that.  Consider for a moment where a BU HELLO is equivalent 
in HIP to the I1 HIP packet.  Also note that an optimization of HIP could 
allow for a data payload INSIDE of I2 (but not appended after, as the 
intiator does not get the responder's SPI until R2).

The ESP transform used im MIP for BUs could be ESP NULL with 
HMAC-SHA1-96.  Once the initial HIP exchange is completed, ESP is used for 
all future exchanges until either a timeout (could be set fairly long here) 
or loss of state (CN or MN boot).