Subject: RE: [mobile-ip] MIPv4: MN-AAA authenticator and challenges

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 8 May 2003 08:02:39 -0500

> 
> On Wed, May 07 2003, at 17:24:57 -0500, Ahmad Muhanna wrote:
> > > On Wed, May 07 2003, at 13:47:32 -0500, Jayshree Bharatia wrote:
> > > > I didn't see specific reason of your objection other 
> than the fact
> > > > that the MN with co-located CoA won't be using 
> challenge-response 
> > > > protocol. Appreciate if you can further clarify on: why ID 
> > > generated
> > > > by the MN is better compare to Challenge?
> > > 
> > > Because the ID field _is_ a challenge by the HA;
> > 
> > Who said that and where?
> > 
> > > it can't be arbitrarily chosen.
> > 
> > Why it can not by randomly chosen?
> 
> See section 5.7 in RFC3344. Of course you can choose a replay 
> protection method that allows the MN select any random number 
> and have the HA accept that. For a reason, neither of the 
> methods mentioned in the RFC lets you do that.
>

According to RFC3344 section 5.7, The only Mandatory replay protection
scheme is
TimeStamp. All MN I saw thus far uses timestamp. Nothing against using
nonce.

"
   Two methods are described in this section:  timestamps (mandatory) and
   "nonces" (optional).  All mobile nodes and home agents MUST implement
   timestamp-based replay protection.  These nodes MAY also implement
   nonce-based replay protection (but see Appendix A).
"

On the other hand, section 5.7.1, it reads:
"
   If timestamps are used, the mobile node MUST set the Identification
   field to a 64-bit value formatted as specified by the Network Time
   Protocol [26].  The low-order 32 bits of the NTP format represent
   fractional seconds, and those bits which are not available from a
   time source SHOULD be generated from a good source of randomness.
"

My understanding, this is very close to a RANDOM Number generated by MN.
It is the MN which generates this number Not the HA.

In section 5.7.2, it reads:
"
   The mobile node is responsible for generating the low-order 32 bits
   of the Identification in each Registration Request.  Ideally it
   should generate its own random nonces.  However it may use any
   expedient method, including duplication of the random value sent by
   the home agent.  The method chosen is of concern only to the mobile
   node, because it is the node that checks for valid values in the
   Registration Reply.  
"

Basically the low-order 32 bits of the ID is randomly generated by the MN.

My point here is: The RR ID is not a challenge generated by the HA.
As a matter of fact it is not anywhere close when TimeStamp, the most
popular 
and mandated by RFC3344 replay protection mechanism is used.

Regards,
Ahmad
> 
> -- 
> Bjorn Andersson <[email-masked]>
> PGP id 5AFC144B
> Mobile +358 40 7723074
>

---

From: Bjorn Andersson <[email-masked]>
Date: Thu, 8 May 2003 16:28:28 +0300

> It is the MN which generates this number Not the HA.

Yes, the MN generates the timestamp, but the HA only accepts a
limited number of timestamps. The range depends on how much the HA
allows the timestamp to differ. How would you prevent replay if
any random timestamp was accepted by the HA? The timestamp is an
implicit challenge by the HA to avoid an extra message roundtrip as
with nonces. The whole idea behind challenge/response protocols are
to prevent replay, right?

  Bjorn