Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 7 Aug 2003 12:11:01 -0500

Hi Pete,
Sorry for the late response. 

Regards,
Ahmad

> 
> 
> 
> Hi, Ahmad,
> 
> Ahmad Muhanna writes:
>  > > We should be writing a document that enables anyone to 
>  > > implement the specification in a robust way, even those that 
>  > > have not participated in or seen this e-mail thread.  We 
>  > > should not be hiding easter-eggs for deployments to trip over 
>  > > later.  Do you really object to the note that I suggested for 
>  > > the security considerations section?
>  > 
>  > Well, I do not see how the suggested comment provide a 
> solution for this  > problem.  > As I said, we have a 
> mechanism for recovery, which I believe enough. 
>  > Adding this comment is ONLY delaying the effect of the 
> attack for a period  > of time.  > Do not you agree?
> 
> No, I do not agree.  I do not think the existing 
> specification provides for recovery, and I think that the 
> mechanism I suggested completely defeats the attack, or at 
> least, restores the attacker to exactly the power he had 
> before with simple channel-flooding.  This is because new 
> solicitations or (invalid) registration requests do not 
> immediately push a valid challenge out of the currently valid 
> set of challenges.  This gives the MN time to receive the 
> challenge, compute an authenticator, and send it to the FA 
> even though many, many solicitations or (invalid) 
> registration requests may have been processed in the meantime.
> 
> Is that clear?
> 

After thinking this over and checking an old thread on similar issue with
Charlie and Luca, 
And checking Appendix E, I believe that the Challenge_Window meant to be for
the periodically 
sent Challenges in Agent Advertisement messages that are multicast. I do not
think that the 
Challenge-Window is related to the unicasted AA messages. (unicasted AA is
ONLY communicated to
One single MN)

Having this in mind and the FA periodically (time based) issuing these
multicast Agent Advertisement 
Messages, I believe that FA is supposed to continue sending the latest
challenge from the Challenge-Window 
in a unicast AA message until the next time a new advertised challenge is
generated. I do not think that 
it is possible to issue a new challenge via unicast AA message and consider
that as part of the Challenge-Window; 
since that Challenge is not available for all Mobile Nodes.
I believe this address the original concern of this thread. What do you
think?
 
I regard to the bogus Registration Request, If the MN receives the
successful Reply and an attacker sends
A bogus RRQ; YES this will invalidates the Challenge sent in the successful
RRP BUT the MN is already 
registered and will not need to re-register until some good time in the
future.

> -Pete

---

From: Pete McCann <[email-masked]>
Date: Thu, 7 Aug 2003 14:32:01 -0500

Hi, Ahmad,

 > Challenge-Window is related to the unicasted AA messages. (unicasted AA is

I technically agree with you here, but I think there is another per-MN
data structure you have forgotten about (see below).

 > I believe this address the original concern of this thread. What do you

But if that Challenge was "previously used" by the MN, it seems proper
to generate a new challenge, no?  And even though that challenge is
not in the global "Challenge-Window" list it should be remembered in a
data structure related to that particular mobile node, and should be
considered as a valid challenge for that MN.  This is reflected in the
very last clause of this paragraph from Appendix E:

   In the program fragment, it is presumed that the foreign agent
   keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a
   record of the last advertised challenge used by a mobile node, and
   also a record of the last challenge provided to a mobile node in a
   Registration Reply.

So, I think this should be modified to say "also a record of the last
challenge provided to a mobile node in a Registration Reply or unicast
Agent Advertisement."

 > registered and will not need to re-register until some good time in the

It's important to remember that the above data structure is kept only
for nodes that have a prior, valid registration.  This is to prevent
state-exhaustion attacks on the FA.  So, I agree with you that it is
proper to repeat the last value from the Challenge-Window record of
multicast advertisements if you are dealing with an MN of which you
have no record.  Otherwise, you should repeat the last challenge from
your per-MN data structure.  It is ok to change this challenge after a
longish-period of time (say 1 minute) and that might provide some
robustness/security benefit, but you shouldn't change it on every
bogus RRQ or un-authenticated solicitation.  You should of course
change it whenever that challenge becomes "previously used."

Perhaps you are saying here that the damage isn't so bad: at most an
attacker can prevent a re-registration, and eventually the visitor
list entry will timeout, causing the FA to forget all "previously
used" challenges for the MN.  Then the MN can re-register with any
challenge from the global Challenge-Window and re-enable service.
However, there could still be a fairly large gap between the timeout
of the visitor list entry and the successful re-registration,
especially because the MN will experience a long series of
STALE_CHALLENGE responses, and it may have backed off on its
registration attempts in the meantime.

-Pete

_______________________________________________
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4