Subject: RE: [mobile-ip] RFC3012-bis: compatibility issues

From: "Ahmad Muhanna"<[email-masked]>
Date: Fri, 5 Apr 2002 11:08:52 -0600

Hello Luca;

Let us agree on the following:

1. The problem is of tracking the used challenges from the broadcast list
(visible to all Mobile Nodes).
2. Tracking all other per-mobile challenges (e.g. in RRP, in unicast
advertisement) is not a 
problem as long as we track a minimum of one challenge of these per mobile.

I believe that having a USED_CHALLENGE_WINDOW of a value of CHALLENGE_WINDOW
+ 1
will make this work perfectly, with one condition:

The USED_CHALLENGE_WINDOW have two types:
one of the size of the CHALLENGE_WINDOW for tracking the Broadcast
challenges 
and one of the size of 1 to track the used challenges of everything else.

This will eliminate the suggestion of preventing the Mobile from using
certain Challenges.

What do you think?

Regards;
Ahmad Muhanna

> -----Original Message-----
> From: Luca Salgarelli [mailto:[email-masked]]
> Sent: Thursday, April 04, 2002 5:09 PM
> To: [email-masked]
> Subject: RE: [mobile-ip] RFC3012-bis: compatibility issues
> 
> 
> Hello Ahmad.
> 
> > RFC3012-bis section 1.1 Terminology :
> > "
> >       previously used challenge
> >                Any challenge that has been used by the 
> mobile node in a
> >                Registration Request message and accepted by 
> the Foreign
> >                Agent as a valid challenge by relaying or 
> generating a
> >                corresponding Registration Reply message.
> > 
> >       stale challenge
> >                Same as "previously used challenge".  The 
> Foreign Agent
> >                may not be able to keep records for all 
> stale challenges.
> > "
> > It is clear that the FA has the option to track all stale 
> challenges or only
> > ONE. 
> > 
> 
> Well, I think that the last sentence is a problem in RFC3012-bis. I
> actually didn't notice it before, so thanks fore pointing that out. If
> we allow an FA not to keep track of all stale challenges, than I think
> we are opening a security hole.
> 
> Imagine this scenario: let's have an FA that keeps a 
> challenge-window of
> 3. It sends advertisements every 60 seconds. In the past 180 
> seconds it
> has sent challenges C1, C2 and C3, in that order.
> 
> Now legitimate Mobile Node MN sends sends registration request R1
> including challenge C2. It gets accepted. A little later MN sends
> registration request R2 including challenge C3.
> 
> Now, if the FA does not keep track of both C2 and C3 *per 
> mobile*, let's
> say it only keeps the last used value (C3), we have a problem. A
> malicious Mobile Node MAL can replay R1, and it will get 
> accepted, since
> it is in the valid window, and it is not stale, at least not to the
> knowledge of the FA.
> 
> So I think that we should either mandate that FAs MUST keep a 
> valid list
> of stale challenges, or we introduce the change that Charlie 
> suggested,
> i.e. if a client uses a challenge from an advertisement, it cannot use
> any challenges issued in previous advertisements, no matter 
> if they are
> in the valid window.
> 
> Cheers
> Luca
> 
> > 
> > Luca;
> > Please see one comment in line about the algorithm you presented.
> > 
> > 
> > Regards;
> > Ahmad Muhanna
> > 
> > 
> > > -----Original Message-----
> > > From: Luca Salgarelli [mailto:[email-masked]]
> > > Sent: Thursday, April 04, 2002 1:15 PM
> > > To: [email-masked]
> > > Subject: Re: [mobile-ip] RFC3012-bis: compatibility issues
> > > 
> > > 
> > > Charlie,
> > > 
> > > please see comments inline.
> > > 
> > > On Thu, 2002-04-04 at 12:46, Charles E. Perkins wrote:
> > > > Luca Salgarelli wrote:
> > > > > 
> > > > > Hello Charlie.
> > > > > 
> > > > > > My original conception of this operation was that 
> the foreign
> > > > > > agent would have a _short_ list of recent 
> acceptable challenges.
> > > > > > That is easily checked when a mobile node sends a 
> Registration
> > > > > > Request.  The challenges would be advertised, and 
> available for
> > > > > > use by multiple mobile nodes.
> > > > > 
> > > > > I think there is more to it than it appears.
> > > > > 
> > > > > The spec says, rightfully, that the FA should make sure 
> > > to check that a
> > > > > mobile does not reuse a previously used challenge. 
> And this is the
> > > > > sticky point. To satisfy it, it is not enough for the FA 
> > > to maintain a
> > > > > global list of "valid advertised challenges" only. It 
> has to keep:
> > > > > 
> > > > > 1) A global windowed list of valid advertised challenges
> > > > > 2) A per-mobile list of the last challenge sent in a reply
> > > > > 
> > > > > as you say, but also:
> > > > > 
> > > > > 3) A *per-mobile* list of recently used challenges from (1)
> > > > > 
> > > > > Now, (1) is not a problem because it should be short. 
> Same for (2)
> > > > > because it is always composed of one entry only -- as you 
> > > suggested, I
> > > > > agree that the window of the challenges sent in replies 
> > > should always be
> > > > > '1'.
> > > > > 
> > > > > I have problems with (3), if the window is larger 
> than one. As the
> > > > > mobile uses challenges from advertisements, we have to 
> > > add them to (3).
> > > > > But we don't want (3) to grow indefinitely, so we want to 
> > > delete the
> > > > > ones that were already there and that we don't possibly 
> > > need anymore.
> > > > 
> > > > What if we say that, if a mobile node uses a challenge from 
> > > (1), that
> > > > challenge _replaces_ the challenge (if any) from (3).  
> Thus, this
> > > > "invalidates" the option to use any challenge that was 
> supplied from
> > > > a Registration Request.
> > > > 
> > > > I don't think this would impose any hardship, and it 
> would seemingly
> > > > eliminate the problem that you have identified.
> > > 
> > > Hmmm, I am not sure you could do that. Let's analyze: (3) 
> contains a
> > > list of challenges successfully used by a client in the 
> recent past.
> > > (3), along with (1) and (2), are kept by the FA so that 
> it can run the
> > > following checks when it receives a challenge C in a registration
> > > request:
> > > 
> > > 1: if (C is not in (1)) and (C is not in (2))
> > > 2:    return UNKNOWN_CHALLENGE
> > > 3: else
> > > 4:    if (C is in (3))
> > > 5:        return STALE_CHALLENGE
> > 
> > No challenge will ever come here. Any challenge classified as
> > STALE_CHALLENGE is
> > a challenge which does not exist in (1) nor in (2). Then 
> you will always get
> > UNKNOWN_CHALLENGE.
> > 
> > you need to modify line 1 to:
> > if (C is not in (1)) and (C is not in (2)) and (C is not in (3))
> > 
> > and keep the rest as is.
> > 
> > > 6: else
> > > 7:    add C to (3)
> > > 8:    proceed with processing of registration request
> > > 
> > > Now, if I understand your suggestion correctly, you are 
> > > saying that the
> > > FA at line 7 should replace the challenge C' (if any) that is 
> > > already in
> > > (3).
> > > 
> > > But this wouldn't work: if the window is larger than one, 
> a malicious
> > > mobile could now replay the older request that contained C', 
> > > and the FA
> > > would let it through.
> > > 
> > > Am I misintrepreting your suggestion?
> > > 
> > > Luca
> > > 
> > > Charlie also wrote:
> > > > > Furthermore, we will probably also have to keep (3) alive 
> > > even after the
> > > > > mobile de-registers, to make sure that an attacker does 
> > > not replay a
> > > > > request that used one of the still valid challenges 
> > > values that this
> > > > > mobile recently used (and that therefore is in (3)).
> > > > 
> > > > After deregistration, from the above, this would not impose 
> > > very much
> > > > additional hardship.  In fact, even when there is 
> nothing from (3),
> > > > the foreign agent should keep this information around.
> > > > 
> > > > Regards,
> > > > Charlie P.
> > > 
> > > 
> > > 
> 
> 
>

---

From: Luca Salgarelli <[email-masked]>
Date: 08 Apr 2002 10:22:53 -0400

Hello Ahmad.

> problem as long as we track a minimum of one challenge of these per mobile.

I agree.

> This will eliminate the suggestion of preventing the Mobile from using

I don't think that this would work as expected. The problem is that this
way the FA does not have any means of tracking the *order* in which the
client uses the broadcast challenges, and this can lead to problems.

For example, let's assume the system that you describe above is in
place. Let's have a FA with challenge-window of 3. The FA issued
challenges [A, B, C] as its most recent past three challenges (A is the
oldest).

A mobile uses first C, then B, then A, all in registration requests very
close to each other. Its USE_CHALLENGE_WINDOW now looks like [C, B, A]:
'C' is going to be the first-out. 

Now the FA issues challenge 'D', and its valid window now looks like [B,
C, D]. Let's assume that now the mobile uses challenge 'D': its
USED_CHALLENGE_WINDOW now should look like [B, A, D]. And now you should
see the problem: a malicious mobile could replay the request that used
'C' as the challenge: since it is in the valid window, and NOT in the
USED_CHALLENGE_WINDOW of the mobile, the FA would accept it.

I hope I was able to convince you (or else tire you to exhaustion with
my complicated examples :-) that the way the draft is written now
becomes very complex and expensive to implement, unless we introduce
some sort of timing information together with the broadcast challenges
that mobiles use. In my opinion, the most (or only) scalable way of
doing this would be either to not send challenges in broadcast
advertisements (my original suggestion), or to have a 'cut-off'
challenge like Charlie suggested.

Regards
Luca