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

From: Pete McCann <[email-masked]>
Date: Fri, 5 Sep 2003 09:56:44 -0500

Hi, Ahmad,

Ahmad Muhanna writes:
 > >  > Is there any scenario that we may be missing and FA may no 
 > > longer having a  > valid unused challenges for a certain MN?
 > > 
 > > Ah, very good question.  I think we had some text to cover 
 > > this case in one of the proposals, but I subsequently deleted it.
 > > 
 > > How about:
 > > 
 > >   To meet the security obligations outlined in Section 12, the FA
 > >   SHOULD use one of the already stored, previously unused challenges
 > >   when responding to an unauthenticated Registration Request or Agent
 > >   Solicitation.  If none of the already stored challenges are
 > >   previously unused, the FA SHOULD generate a new challenge, include
 > >   it in the response, and store it in the per-MN data structure.
 > > 
 > > -Pete
 > >
 > 
 > Let me try to understand what we are trying to propose here:
 > If RRQ generates MN-AAA authentication, FA MUST not invalidate previously
 > unused challenges
 > 1. FA SHOULD include a previously unused challenge in RRP, if present; or
 > 2. FA SHOULD generate a new challenge., or
 > 3. FA does not send any of the above SHOULD's and send a new challenge
 > always.
 > 
 > Is not all of the above is already captured very nicely in section 2 of
 > RFC3012bis:
 > "
 >    The Challenge extension, illustrated in figure 1, is inserted in the
 >    Agent Advertisements by the Foreign Agent, in order to communicate
 >    the latest challenge value that can be used by the mobile node
 >    to compute an authentication for its next registration request
 >    message.  The challenge is selected by the foreign agent to provide
 >    local assurance that the mobile node is not replaying any earlier
 >    registration request.
 > "
 > 
 > I believe there is probably no need for all of these SHOULDs and let us
 > leave it as generic as it should be with the responsibility of the FA as
 > explained in the above paragraph.
 > 
 > Your thoughts, please.

No, it is not covered by that text.  We are trying to eliminate two
denial-of-service attacks.  This requires restricting the FA
implementation so that un-authenticated messages do not cause (a)
invalidation of previously unused challenges, nor (b) creation of
state at the FA.  The text you quote does not give enough guidance on
this.

We need the text that has been suggested in the Security
Considerations section 12.  I think we also need the text in this
Appendix E to clarify how the example pseudocode/data storage should
be handled to meet these security obligations.

I am having trouble understanding your objections to these text
suggestions.  Are you really so concerned about an existing
implementation, that violates this text?  Is it really that much
effort to make these (very sensible, in my opinion) changes?

-Pete

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 4 Sep 2003 19:29:57 -0500

Hi, Pete,

Regards,
Ahmad

> -----Original Message-----
> From: Pete McCann [mailto:[email-masked]] 
> Sent: Thursday, September 04, 2003 6:04 PM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: 'Pete McCann'; Bharatia, Jayshree [RICH1:2H13:EXCH]; 
> [email-masked]'
> Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5
> 
> 
> 
> Hi, Ahmad,
> 
> Ahmad Muhanna writes:
>  > > Ahmad Muhanna writes:
>  > >  > > -----Original Message-----
>  > >  > > From: Pete McCann [mailto:[email-masked]] 
>  > >  > > Sent: Wednesday, September 03, 2003 5:03 PM
>  > >  > > To: Bharatia, Jayshree [RICH1:2H13:EXCH]
>  > >  > > Cc: [email-masked]'
>  > >  > > Subject: RE: [Mip4] RFC3012bis: Proposal for 
> Issue2-Change5  > > 
>  > >  > >  > >  > > 
>  > >  > >  > >  > > After that, we could add, "To meet the 
>  > > security obligations 
>  > >  > >  > >  > > outlined in Section 12, the FA SHOULD use one 
>  > > of the already 
>  > >  > >  > >  > > stored, previously unused challenges when 
>  > > responding to an 
>  > >  > >  > >  > > unauthenticated Registration Request or Agent 
>  > > Solicitation."  > 
>  > >  > If we are trying to prevent such DOS attack by NOT 
>  > > INVALIDATING the  > challenge received in RRQ, why not 
>  > > sending that challenge (still valid) back  > in RRP. Is there 
>  > > a problem with that?
>  > > 
>  > > That behavior is allowed by the text above, assuming that the 
>  > > challenge received in the RRQ is stored in the data 
>  > > structures given in Appendix E.  If not, then what you 
>  > > describe would not be ok, because you would be forcing the FA 
>  > > to use a challenge that it didn't necessarily generate.
>  > > 
>  > 

Your thoughts, please.