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

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

> >
> >   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.
> 
> 
> In the context of MIPV6 you don't need to send the public key securely.
> The home address is binded to the MN's public key and the msg2 (that
> included the
> BU) is signed by the MN's private key...
> 
> An intruder-in-the-middle could intercepts msg2 and send a fake one to the
> CN. But this "fake" BU can
> not use the MN's home address because the intruder won't be able to sign it
> (because it does not
> know the private key)....so it won't be able to redirect the trafic destined
> to the MN.... the only think it could
> do is to send a BU with a fake home address ....this won't be very
> harmfull...
> 
I am assuming that the HIP cookie is newly generated for every
transaction and this should help prevent replay attacks when msg3
is replayed with an invalid signature. I could not verify
this anywhere.

In section 6.1, you are allowing the possiblity of configuring
a new coA with a new identifier. If you really have
to prove that the CoA is not stolen, the identifiier should
match that of the home address. So, i don't understand this
part.

This protocol solves the address ownership problem of the MN.
But it does not really do any verification of the CN itself.
It can be easily done by CN signing the message and sending
the public key as part of msg2. But this is more work for
the CN even before it can verify that the MN is a valid
one or not.

-mohan

> did I answer your question?
> 
> regards,
> 
> Claude.
> >
> >
>

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 16 Apr 2001 09:44:01 -0400

At 02:32 PM 4/12/2001 -0700, Mohan Parthasarathy wrote:

Back from the holidays...

>is replayed with an invalid signature. I could not verify

I have not built a state machine for the SUCV draft, but in HIP....

It is easy for an implementation to handle an apparent replay attack of I2 
packets.  After receipt of the I2, the state machine moves forward to at 
least state:

I1o,Ro1

Since I2 has the HIT in the clear, if the responder laready has state for 
that HIT, it MUST treat any I2 packets as a replay attack.

The rewrite of HIP will have clear text instructing developers on handling 
attacks like this.

>the CN even before it can verify that the MN is a valid

that is all true.  There is a fair amount of discussion of this in the HIP 
architecture.  This is part of why I had to go with 4 packets in HIP.  I 
have the R1 packet totally independent of any information in the I1 
packet.  This allows the responder (in this case the CN) to off-line 
prepare the R1 packets and to use them for multiple initiators.  Thus R1 
can be signed and the initiator can establish trust of R's existance.

This also means that the responder does not have any meaningful information 
about initiator until I2 and requiring an R2 packet in response to this 
information.

The SUCV ID avoids MOST of the overhead (but not all!) of initial state 
management by only needing to track the SUCV, cookie, and SPI.  It must not 
support signing of msg2, as this will allow for a serious resource attack 
on the CN.

All engineering is a trade-off.  You might look at the SUCV ID as a 
stepping stone to HIP in this regard.