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

From: "Ahmad Muhanna"<[email-masked]>
Date: Thu, 4 Apr 2002 15:48:48 -0600

Hello all;
I think this an implementation specific issue.

However, FA keeps track of the following challenges:
1. Broadcast & unicast with a default window of 2 - per Mobile.
2. Challenge in last Registration Reply message, ONLY one - per Mobile.
3. List of USED "STALE" challenges (minimum 1 & maximum is implementation
specific) - per Mobile.

Earlier, I suggested to introduce a USED_CHALLENGE_WINDOW but Charlie had a
better idea by leaving this open to implementation specific.

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. 

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: 04 Apr 2002 18:09:11 -0500

Hello Ahmad.

> It is clear that the FA has the option to track all stale challenges or only

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