Subject: Re: [mobile-ip] Comments on Draft 16

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 1 Apr 2002 17:48:04 -0800 (PST)

> > Vijay's description below clears concept for MN behavior in case it reboots.
> > As per Vijay's description on draft15, HA can accept BUs with any seq# after 
HA
> >  reboots as it does not keep the state upon reboot.
> 
> 
> Right, I believe what Vijay described does have a small vulnerability
> in that after a reboot replays are possible.
> 
> 
Agreed.

> > Although, it adds extra replay protection at HA, I'd think, the
> > home-agent usage of NV memory could be optional. I'd like to know
> > how big is the threat in this particular case (i,e if HA reboots).
> > If we somehow decide that HA should preserve the bindings accross reboot,
> > then obviously, it makes sense to have all the information intact. 
> 
> 
> Yes. Why don't we use the -15 scheme, describe the remaining threat and
> make the seqno-preservation through reboots a SHOULD (or a MAY).
> 
> 

OK.

> > Also this section mentions "The mobile node and homeagent MAY on a new key
> > for the security association before this many (2**31) BU have been sent if
> > this is an issue".
> > I wonder if we leave it as MAY, then there might be some interoperability 
issues
> > as MN and HA may have different expectations.
> 
> 
> I don't think so. There has to be a key management scheme to change the key,
> and I can only think of two: IKE and a manual change. In either case it will
> be apparent if the other side does not support this activity. For instance, if
> manual keying is used then the administrator either gets hold of the mobile 
node's
> owner and asks him to change the key, or he doesn't ;-)
> 

Ok. I got your point.

> But perhaps we should clarify in the draft that the mobile IP protocol as such
> will not start complaining about too old keys. So, as far as mobile IP 
concerned
> this wrapping over is ok, and does not result in any error codes.
> 
> 

Yes, clarification would be good, thanks.

> > 1. section 4.5.5, please clarify  in words how the Correspondent node
> >    secret key Kcn would be used. There is an example of MAC_Kcn in COT
> >    message processing, but that is not very clear.
> 
> 
> This key is used by the correspondent node to accept only the use of cookies
> which it has created itself. Adding some text...
> 
>

Ok.
 
> > 2. In HOTI and COTI messages we use "nonce" index. What is "nonce" index?
> >    Is it a random number ? IBM has IPR on nonces, how different or same
> >    is this nonce index from IBM's nonces ? 
> 
> 
> It is just an efficient way to find the right nonce. Adding some text..
> 
> As for the IPRs, please tell me more! Do you have a pointer to IBM's
> claim?
> 

Actually MobileIPv4 uses "nonces" as optional mechanism for replay protection.

I find the pointer for IBM patent in RFC2002 (appendix. A.2).

A.2. IBM Patent #5,148,479

   This patent, also assigned to IBM, may be relevant to those who
   implement nonce-based replay protection as described in Section
   5.6.2.  Note that nonce-based replay protection is an optional
   feature of this specification.  Timestamp-based replay protection, on
   the other hand, (Section 5.6.1) is a requirement of this
   specification.

However, I cannot see the reference anymore in latest version of MobileIPv4 
-RFC3220.

RFC3220, '5.7.2 Replay Protection using Nonces' has description how to
use nonces for replay protection. Here it refers to RFC1750.
Eastlake, D., Crocker, S. and J. Schiller, "Randomness
         Recommendations for Security", RFC 1750, December 1994.

 Since "nonces" are the default replay protection method in MIPv6
  HOTI/COTI messages, a clarification on it's usage will be quite useful.
  I am not sure whether the IPR issue still holds here-perhaps needs to be
   investigated?

 Thanks,
 -Samita

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 02 Apr 2002 11:39:56 +0200

> Actually MobileIPv4 uses "nonces" as optional mechanism for replay protection.

It used to be the other way around, with timestamps as optional. IBM liberated the IPR
on nonces for IPsec, but since the corresponding statement for Mobile IP was not produced,
the working group changed it to optional.

>   I am not sure whether the IPR issue still holds here-perhaps needs to be

Good question, I don't know.

-gabriel