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 16:18:25 -0500

Hi Pete,

Regards,
Ahmad

> -----Original Message-----
> From: Pete McCann [mailto:[email-masked]] 
> Sent: Thursday, August 07, 2003 2:32 PM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Henrik Levkowetz; [email-masked]; Bharatia, Jayshree 
> [RICH1:2H13:EXCH]; [email-masked]'; 'Luca Salgarelli'
> Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis 
> challenges in s olicited ag ent advertisements
> 
> 
> 
> Hi, Ahmad,
> 
> Ahmad Muhanna writes:
>  > > Ahmad Muhanna writes:
>  > > 
>  > > 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)
> 
> I technically agree with you here, but I think there is 
> another per-MN data structure you have forgotten about (see below).
> 
>  > 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?
> 
> But if that Challenge was "previously used" by the MN, it 
> seems proper to generate a new challenge, no?  And even

I absolutely agree with you here. BUT let us be frank.
This has to be taken in light of the whole mechanism offered By RFC3012bis.
When this was discussed about (April 2002) in another thread, we were very
much concerned to have the challenge mechanism work with an optimized
solution for scalability and storage requirement.
Achieving the most optimized storage requirement as mentioned in Appendix E
was done with some assumptions in mid.

1. Minimum Challenge-Window size of 2, as recommended.
2. FA includes a challenge in every RRP message to avoid Agent Solicitation
messages; since RRP is sent to the MN anyway.
3. FA needs to keep track of the latest challenge every MN used while from
the Challenge-Window.
4. Since the Challenge-Window has a value of 2, it is required that the MN
MUST use the latest advertised (multicast) Challenge. This will enable FA to
keep track with ONLY one used challenge from the Challenge-Window and NOT 2.
5. FA need to keep track with the latest Challenge sent in the latest RRP
message. Even in this one, FA does not need to keep track of the latest used
challenge from the RRP. Because FA would send either UNKNOWN or STALE
Challenge; respectively.

Now: all of this is the minimum the standard requires the FA to have to
maintain a robust solution.
E.g. 
1. some FA would track the challenges sent in unicast Agent Advertisement
message per MN because they do not send New challenge in every RRP, it is an
implementation issue.

2. Some FA would like to keep track of the last used challenge per MN from
RRP to send Stale Challenge, implementation specific.

3. Some FA would like to keep track with the last two used challenges from
the Challenge-Window; that is cool.
4. etc....

> 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."
> 
>  > 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.
> 
> 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.
>

Mostly true. BUT I meant two things:
1. MN has a plenty of time to pick one of the latest advertised challenges
(multicast) for re-registration.
2. If MN is not listening to these challenges, MN would solicit and receive
the latest challenge from the Window-challenge (multicast Advertised) and
use it for re-registration.

> -Pete

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 8 Aug 2003 00:20:36 +0200

Thursday  7 August 2003, Ahmad wrote in response to Pete McCann:

[...]

> >  > 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)

So far, we're in agreement.

> This has to be taken in light of the whole mechanism offered By
> RFC3012bis. When this was discussed about (April 2002) in another
> thread, we were very much concerned to have the challenge mechanism
> work with an optimized solution for scalability and storage
> requirement. Achieving the most optimized storage requirement as
> mentioned in Appendix E was done with some assumptions in mid.

That's fine. Now, as far as I can see, the proposed changes maintain the
data structures proposed in Appendix E, not adding additional storage
requirements, so we don't have a problem in this respect.

[...]

> >    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.
> > 

Yes, that makes sense.

> >  > In regard to the bogus Registration Request, If the MN 
> 1. MN has a plenty of time to pick one of the latest advertised
> challenges(multicast) for re-registration.
> 2. If MN is not listening to these challenges, MN would solicit and
> receive the latest challenge from the Window-challenge (multicast
> Advertised) and use it for re-registration.

Item 1. does not hold if the MN is newly arrived at the link, which
I hold is the predominant reason to solicit for an agent advertisement
in the first place. 

For item 2, we currently have no text stating that solicited agent
advertisements MUST be multicast nor do we have text stating that they
MUST be unicast. It seems you are proposing a solution where we state
that they must be multicast? In that case, we need text to this effect,
and we also need text to clearly express that the solicited multicast
agent advertisement should re-send the latest challenge from the 
Challenge Window. 

(However, I'm still not clear on your reason for wanting to exclude
unicast solicited agent advertisements.)

	Henrik

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