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

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 6 Aug 2003 10:36:58 -0500

Hi Pete,
Comments inline.

Regards,
Ahmad

> 
> Isn't this open to a similar denial of service attack, 
> assuming that link layer spoofing is possible?  That is, an 
> attacker can send spoofed solicitations at a very high rate, 
> causing the FA to repeatedly (unicast) the agent 
> advertisements with fresh challenges to the victim's mobile 
> node.  It could happen that the mobile is never able to 
> register because a new solicitation arrives at the FA before 
> the victim's RRQ.  The solicitation/advertisement effectively 
> pushes the last unicast challenge out of the 1 slot.
> 

I Agree.

> Perhaps it should be possible to return the same challenge 
> value in successive unicast solicited agent advertisements, 
> as long as it was not previously used (recall "previously 
> used" means used with a valid MN-AAA or MN-FA authentication 
> extension).  

I Agree.

>I think the same procedure (returning the same 
> challenge) should be followed for unsuccessful Registration 
> Requests where the MN-AAA (or MN-FA) authentication did not 
> check out.  If desired, we could change the challenge value 
> after some fairly long period of time (like, 1 minute would 
> easily be long enough to avoid this DoS) if we are really 
> worried about robustness.
>

I think we need to leave this flexible with the condition above.
FA can not send a previously used challenge to a specific MN.
I believe this is quite enough.

>  > > Option 3: Provides guideline to implementers on probable 
> security threat.  > > This was my earlier proposal.  > 
>  > Ok. I don't think guidelines is sufficient, I believe we 
> need requirements  > to avoid the exact interoperability 
> problems we recently experienced.
> 
>  > > I would suggest we can have opinions/suggestions from 
> others as well. I  > > don't have any issue in incorporating 
> the option agreed by all. 
>  >
>  > Right.
> 
> I think some changes to the draft are in order to avoid the 
> DoS attacks pointed out by Henrik.
>
 
I thought Henrik concern was about the consequences of FA does not include a
fresh challenge in the RRP.

>  > We also should have some text to clarify the handling of 
> unicast  > solicited advertisements. I guess we agree on the 
> handling of those?  > (i.e. a new challenge should be 
> generated, and treated analogous to  > a challenge returned 
> with a registration reply?)  > 
>  > There is one further change we maybe should review as part 
> of this: To  > change the requirement on returning a 
> challenge with any registration  > response from a SHOULD to 
> a MUST. Any viewpoints on that?
> 
> Sounds like a good idea, although see above about returning the same
> (unused) challenge in successive (unsuccessful) responses.
>

I think we need to leave this for implementation with the standard
restriction of
Previously unused challenge. 

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

---

From: Pete McCann <[email-masked]>
Date: Wed, 6 Aug 2003 11:11:41 -0500

Hi, Ahmad,

 > I believe this is quite enough.

How about a note in the security considerations section?  See below
for some suggested text...

 > fresh challenge in the RRP.

I'll let Henrik speak for himself, but I think his comments were
directed specifically at how the FA responds to solicitations and
which challenges will be valid for use after it does so.

 > Previously unused challenge. 

Ok, so the main body of the text can say that the FA always sends a
previously unused challenge, with the understanding that "previously
used" is defined as we have agreed (i.e., includes FA validity
checks).

How about this for the security considerations:

  Note that an active attacker may try to prevent successful
  registrations by sending a large number of Agent Solicitations or
  bogus Registration Requests, each of which could cause the FA to
  respond with a fresh challenge, invalidating the challenge that the
  MN is currently trying to use.  To prevent such attacks, the FA
  SHOULD repeat the same challenge value in successive unicast
  responses to Agent Solicitations or in Registration Replies to
  Requests that did not contain valid MN-AAA or MN-FA authentication
  extensions for some limited period of time.  Note that each
  challenge returned to an MN MUST be previously unused by that MN.

-Pete

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 6 Aug 2003 19:50:27 +0200

Wednesday  6 August 2003, Pete wrote a proposal for an addition to the
security considerations in response to various comments:

[...]

>  > > unicast solicited advertisements. I guess we agree on the 
>  > > handling of those? (i.e. a new challenge should be 
>  > > generated, and treated analogous to a challenge returned 
>  > > with a registration reply?) 
>  > >
>  > > of this: To change the requirement on returning a 
>  > > challenge with any registration response from a SHOULD to 
>  > > Sounds like a good idea, although see above about returning the
>  > > same(unused) challenge in successive (unsuccessful) responses.
>  > >
>  > 
>  > restriction of Previously unused challenge. 
> 

This sounds good to me.

	Henrik