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

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 4 Sep 2003 16:00:51 -0500

> 
> 
> On Thursday,  4 Sep 2003, Ahmad wrote:
> 
> > Hi, Pete,
> ...
> > >  > >  > >
> > >  > >  > > 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?
> 
> I guess there is a rather large conceptual difference in 
> expressing that a challenge is copied from a received 
> request, and to say that it is taken from an internally 
> generated, stored value. In the first case, if this wording 
> is followed by the implementers, it may open up for buffer 
> overrun attacks, which would be unfortunate.
> 
> (There may be other issues with this too, but I'll leave that to Pete)
> 

I agree. Since we are talking about MN-AAA authentication RRQ; challenge is
verified later.

> 	Henrik

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 5 Sep 2003 09:46:12 -0500

Hi, Pete,

Agreed.

Regards,
Ahmad

> -----Original Message-----
> From: Pete McCann [mailto:[email-masked]] 
> Sent: Friday, September 05, 2003 9:43 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:
>  > > If we remove the restriction, then it would be legal to 
>  > > implement an FA that created a new challenge whenever it 
>  > > received an un-authenticated RRQ or Agent Solicitation, and 
>  > > that allocated new storage for each challenge.  This would 
>  > > have the property of not invalidating old challenges (because 
>  > > they would still be kept in
>  > > storage) but would allow unauthenticated messages to exhaust 
>  > > the resources of the FA, which would be bad.
>  > 
>  > Well, what is the problem with that. 
>  > Are we here proposing an HLD for FA or a standard.
>  > Those things MUST be left out for implementations. If some 
> one have a super  > jet machine and an unlimited memory, why 
> we need to restrict them.  > I feel that we need to keep this 
> out of the standard. It is not related to  > the protocol we 
> are proposing here.
> 
> 
> On the contrary, I think it is quite appropriate to call out 
> such restrictions in a standard.  See section 1.7.1 from RFC 2408:
> 
> 
>  1.7 ISAKMP Protection
> 
>  1.7.1 Anti-Clogging (Denial of Service)
> 
>     Of the numerous security services available, protection against
>     denial of service always seems to be one of the most difficult to
>     address.  A "cookie" or anti-clogging token (ACT) is aimed at
>     protecting the computing resources from attack without spending
>     excessive CPU resources to determine its authenticity.  
> An exchange
>     prior to CPU-intensive public key operations can thwart 
> some denial
>     of service attempts (e.g.  simple flooding with bogus IP source
>     addresses).  Absolute protection against denial of service is
>     impossible, but this anti-clogging token provides a technique for
>     making it easier to handle.  The use of an anti-clogging token was
>     introduced by Karn and Simpson in [Karn].
> 
>     It should be noted that in the exchanges shown in section 4, the
>     anticlogging mechanism should be used in conjuction with 
> a garbage-
>     state collection mechanism; an attacker can still flood a server
>     using packets with bogus IP addresses and cause state to 
> be created.
>     Such aggressive memory management techniques SHOULD be employed by
>     protocols using ISAKMP that do not go through an initial, anti-
>     clogging only phase, as was done in [Karn].
> 
> 
> So, this text calls out some specific requirements for memory 
> management and its impact on security.  I think it is 
> important that we do the same in 3012bis, so that we will 
> have implementations that are not vulnerable to state 
> exhaustion attacks.  Otherwise, we could end up with an 
> embarassing situation that gives the standard a poor reputation.
> 
> -Pete
> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 8 Sep 2003 13:44:46 -0500

Hello Charlie,

No problem, I am fine with the consensus on the mailing list.

Regards,
Ahmad

> From: Charlie Perkins [mailto:[email-masked]] 
> Sent: Monday, September 08, 2003 12:35 PM
> Cc: [email-masked]'
> Subject: Re: [Mip4] RFC3012bis: Proposal for Issue2-Change5
> 
> 
> 
> 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
> >
> >
> > > Sent: Monday, September 08, 2003 10:57 AM
> > > 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
> > >  >
> > >  >
> > >  > > Sent: Friday, September 05, 2003 9:57 AM
> > >  > > 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: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 8 Sep 2003 14:39:58 -0500

Hi, Pete,

Regards,
Ahmad

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

I probably missed this one. I am OK with this one.
 
> 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 
> [email-masked]'  > > Subject: RE: [Mip4] RFC3012bis: Proposal 
> for Issue2-Change5  > > 
>  > > 
>  > > 
>  > > Hi, Ahmad,
>  > > 
>  > > Ahmad Muhanna writes:
>  > >  > > Ah, very good question.  I think we had some text to cover