Subject: Re: [MOBILE-IP] Challenge Response issues

From: Patrice Calhoun <[email-masked]>
Date: Wed, 22 Dec 1999 04:34:02 -0800

>Hello, Pat,
>
> Thank you for your email;  my one more question is embedded in the following:
>
>At 05:02:07 -0800 Tue, 21 Dec 1999,  Patrice Calhoun wrote:
>>>
>>> >Hello, Pat:
>>> >
>>> >At 11:02:59 -0800 Mon, 20 Dec 1999,  Patrice Calhoun wrote:
>>> >>> All,
>>> >>>
>>> >>> Some comments were received some time back, and it seems like Charlie
>and
>>> >>> I missed them. The issue that was raised was that it would be nice to
>>> >>> enable the Mobile Node to receive the challenge from the Foreign Agent
>>> >without
>>> >>> having to constantly listen for Advertisements.
>>> >>>
>>> >>> Of course, the first time that the Mobile Node connects to the network,
>it
>>> >>> will need a challenge value, which can be used. The subsequent
>registrations
>>> >>> shouldn't require that the Mobile Node listen for advertisements.
>>> >>>
>>> >>> I believe that the conclusion that we came up with was that the Foreign
>>> >Agent
>>> >>> could include a new challenge in the Registration Reply, which the
>Mobile
>>> >>> Node needed to include in the subsequent registration. Further, should
>the
>>> >>> Mobile Node move to a new service area, the challenge could be
>authenticated
>>> >>> via the binding update.
>>> >>>
>>> >>> We are proposing to include this new text in a separate section entitled
>>> >>> "optimized approach".
>>> >>>
>>> >>> Does anyone have any issues with the above proposal?
>>> >>>
>>> >>> PatC
>>> >
>>> > For an MN's implementor, this will make much easier to implement the
>>> > Challenge/Response mechanisms on MNs.  I'd like to confirm the following
>>> > two more things:
>>> >
>>> > 1) The challenge value in the Registration Reply is the same one in the
>>> >    previous Advertisement ?
>>>
>>> Not necessarily. A Foreign Agent can keep track of the last challenge
>>> issued to a Mobile Node through a Reply, and the last two challenges issued
>>> through advertisements. They should all be diffent.
>
> I think, you are now assuming the window-size of Registration Reply
> as one.  Couldn't it be two, just like advertisement ?
>
> I often see there are two successive Registration Requests sent from
> an MN at the beginning, in case that the MN receives the first
> Registration Reply with Timestamp error(code 133).  The one request
> is a retrial from the above error, another from retry counter.
>
> If the window-size of Registration Reply sets to one, an additional
> error might be received.  But, it may only occur at the beginning...

Ah, but the *initial* challenge is retrieved from the advertisment. Otherwise,
you get a chicken and egg problem. All subsequent registrations can use the
challenge embedded in the reply.

PatC
>
>Thanks.
>-Yoshi
>
>
>>> > 2) For backward compatibility, the following scenario may work fine:
>>> >   - If a challenge value is included in the Registration Reply,
>>> >     an MN should use the value in the next Registration Request.
>>> yes
>>> >   - If not, use the challenge value in the previous Advertisement.
>>> yes, but the mobile node could use this EVEN if one was present in the
>>> reply.
>>>
>>> >    My question is your proposal is an approach or an additional requirement
>?
>>> It is a new approach, since the earlier version of the draft didn't allow
>the
>>> challenge to be present in the reply.
>>>
>>> PatC

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 22 Dec 1999 07:23:30 -0800

> challenge embedded in the reply.

I agree with you, and I think this should be explicitly spelled out
that a mobile node SHOULD use the challenge even when the registration
reply indicates failure 133.  But this is unauthenticated, and _could_
lead to a bizarre and stupid attack from a man-in-the-middle.  Thus it
has to be documented in the Security Considerations.

Regards,
Charlie P.