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

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 4 Sep 2003 12:22:21 -0500

Hi, Pete,

Regards,
Ahmad

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

Ahmad
 
> -Pete

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 4 Sep 2003 19:43:47 +0200

> Hi, Pete,
...
> 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)

	Henrik

---

From: Pete McCann <[email-masked]>
Date: Thu, 4 Sep 2003 12:49:22 -0500

Hi, Ahmad,

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

My view is that it should also be legal to return any of the other
previously unused challenges from the data structure.  This allows for
maximum implementation flexibility.  The DoS attack is prevented as
long as you don't invalidate existing previously unused challenges.

-Pete

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