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

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 5 Sep 2003 16:10:35 -0500

Hi, Pete,

Regards,
Ahmad

> -----Original Message-----
> From: Pete McCann [mailto:[email-masked]] 
> Sent: Friday, September 05, 2003 9:57 AM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; [email-masked]'
> Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5
> 
> 
> 
> 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?

I absolutely not. To me I feel that it is already covered and any good
implementation would not need all of these SHOULDs.
However, I don't have an objection against it. If you read my comments:
" I believe there is probably no need for all of these .."

At the end, No problem.
> -Pete

---

From: Pete McCann <[email-masked]>
Date: Mon, 8 Sep 2003 10:56:36 -0500

Hi, Ahmad,

Ok, thanks.

Can we proceed with the last text that I suggested for the Security
Considerations, and for Appendix E?

On the topic of mandatory inclusion of a challenge in the RRP or Agent
Advertisement, there seem to be separate proposals from Henrik and
myself.  I would be ok with either one of these.  The main difference
seems to be that my text would require a challenge in any
reply/advertisement that did NOT have a multicast challenge sent
around the same time, while Henrik would leave unspecified exactly
what condition you can leave out the challenge from the reply, while
mandating inclusion of a challenge in subsequent solicited
advertisements if you "have conditions" under which the FA would leave
out the challenge from a reply.  Any preference from other folks among
these alternatives?

-Pete

 > " I believe there is probably no need for all of these .."

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