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

[Pete McCann <mccap@lucent.com>]

Hi, Ahmad,

Ahmad Muhanna writes:
 > 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.

But then the attacker could immediately send another RRQ, invalidating
the new 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.

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

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


_______________________________________________
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4