Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 3 Sep 2003 06:10:46 -0500

Hi, Pete,
Please see comments inline.

Regards,
Ahmad

> 
> Based on subsequent comments from Ahmad, maybe we can make 
> the requirement more generic here, and give a specific 
> example in Appendix E.  For here, how about:
> 
> 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 MUST NOT invalidate 
> previously unused challenges when responding to 
> unauthenticated Registration Requests or Agent Solicitations. 
>  In addition, the FA MUST NOT allocate new storage when 
> responding to such messages, because this would also create 
> the possibility of denial of service.
> 

I would like to propose the following:
"
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 MUST NOT invalidate 
previously unused challenges when responding to Agent Solicitations.
"

The reason I need to eliminate the unauthenticated RRQ is that we are
intentionally allowing the violation of replay protection between the MN and
FA. It is possible that the MN uses an old MN-AAA secret key (expired MN-AAA
key) which may generate MN-AAA authentication failure. The real MN is
allowed to correct itself in a way or another and try again for successful
registration. The drawback in the case of an attacker, the MN may generate
Stale Challenge at the FA. At that point, MN may solicit and receive an
unused challenge. In the case of the MN being registered; it is still
possible that the MN would have the MN-AAA key lifetime expired while still
registered. The bottom line, an attacker with unauthenticated RRQ would not
cause denial of Service as we may think. The process of generating a new
challenge is very small in comparison with the whole process of RRQ,
building a new RRP and send it back to the MN.
> 
> 
> 
> 
> 
> -Pete
> 
> 
> _______________________________________________
> Mip4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mip4
>

---

From: Pete McCann <[email-masked]>
Date: Wed, 3 Sep 2003 10:16:44 -0500

Hi, Ahmad,

Ahmad Muhanna writes:
 > unused challenge.

But then the attacker could immediately send another RRQ, invalidating
the new challenge.

 > In the case of the MN being registered; it is still
 > registered.

Sure, but in this case the FA validation will fail and the challenge
will not become "previously used."  I am not quite sure I understand
your point about "intentionally allowing the violation of replay
protection".  Could you explain this a bit more?  It seems to me that
as long as we do not accept as *valid* any message that re-uses a
challenge that was used in a previous *valid* message, then we are
secure.  It is ok to reject as many *invalid* attempts as you want,
there is no need to expire the challenge values contained therein.

 > The bottom line, an attacker with unauthenticated RRQ would not

I still see a possible denial of service attack if we allow the FA to
invalidate challenges based on unauthenticated RRQs.

I note that your proposal also deleted the text that prohibits
allocation of additional storage.  Do you have an argument against
this restriction?

-Pete