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

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 8 Sep 2003 12:24:55 -0500

Hi, Pete,
I thought that there was another proposal by Jayshree to accept mandating
FAC in RRP with no conditional text attached. Since I have not seen any one
complaining about backward compatibility by mandating this behavior, I would
support mandating the inclusion of FAC in RRP without additional text. At
the end someone's code is going to change.

Regards,
Ahmad

> -----Original Message-----
> From: Pete McCann [mailto:[email-masked]]
> Sent: Monday, September 08, 2003 10: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,
> 
> 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
> 
> 
> Ahmad Muhanna writes:
>  > 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: Charlie Perkins <[email-masked]>
Date: Mon, 08 Sep 2003 10:34:36 -0700

Hello Ahmad,

In some previous e-mails, I thought it was concluded that no
such mandate was required.  I haven't read through all the
recent and seemingly tangled threads, but I didn't see anything
to suddenly make the mandate.  And, surely it is the case that
not every Mobile IP RRP needs the challenge, so some
conditioning text is guaranteed.  Why insert more mandates
than are neede?

Regards,
Charlie P.

Ahmad Muhanna wrote:

> Hi, Pete,
> I thought that there was another proposal by Jayshree to accept 
> mandating FAC in RRP with no conditional text attached. Since I have 
> not seen any one complaining about backward compatibility by mandating 
> this behavior, I would support mandating the inclusion of FAC in RRP 
> without additional text. At the end someone's code is going to change.
>
> Regards,
> Ahmad
>
>

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

---

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

Hi, Ahmad,

Sure, that's also a valid approach.  Any comments from others on which
of the three we should adopt?

-Pete