Subject: RE: [Mip4] Re: rfc3012bis draft review

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 16 Oct 2003 09:28:52 -0500

Hi Henrik,

Let us look at the following scenario which easily cause a DOS; 
1. MN send a RRQ message RRQ1 with Challenge C1. 
2. FA process the message and relay it to HA1. 
3. A nice man is listening and as soon as RRQ1 is relayed, IT builds a RRP
(code=00) with bogus MN-HA authentication extension and challenge C2. 
4. FA process the RRP message and since challenge value is different than
what in RRQ1, FA change code to (MISSING CHALLENGE) and relay RRP to MN. 
5. let us remember, this middle man can be nasty and include some
information for this MN in RRP. 
6. MN has nothing to do other than retry or quit. If it uses the extra
information, MN in real trouble. 7. If MN retries our friend listening
repeats the same scenario.

I believe the most appropriate action the FA should take, is to discard the
message to avoid such a scenario. I was thinking that the challenge between
FA and HA provides some sort of replay protection! What do you think?

Regards,
Ahmad

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]]
> Sent: Wednesday, October 15, 2003 5:45 PM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; [email-masked]'; 
> [email-masked]'; [email-masked]
> Subject: Re: [Mip4] Re: rfc3012bis draft review
> 
> 
> Ahmad,
> 
> 	I think it's up to you to show that the mechanism in
> rfc 3012 Section 3.2 is broken. I don't think it is, and you 
> haven't shown why 3.2 is bad.
> 
> Until we get a clear case description of why and how 3.2 is
> broken, it should stay as it is, and so should the security 
> considerations.
> 
> 	Henrik
> 
> Wednesday 15 October 2003, Ahmad wrote:
> > BUT if the reply is unauthentic, how the MN would be able
> to use any
> > information in this RRP. I am really surprised that we even discuss
> > this. On the other hand, MN may receive two different type 
> of replies
> > with the same error code (MISSING CHALLENGE). One RRP is
> initiated by
> > FA in response to RRQ with a real missing challenge and
> another from
> > the HA. How the MN would know which is which. I believe that error
> > code which is a FA error code should continue to be used by the FA 
> > with RRP issued by the FA.
> > 
> > According to RFC3012bis section 3.4. Home Agent Processing for the
> > Challenge
> > Extensions:
> > The HA has two options:
> > 1. If it recognizes the Challenge extension, It must 
> include the MN-FA
> > challenge back in the RRP.
> > 2. If does not recognizes the Challenge, it MUST process
> the RRQ anyway
> > without including a challenge in the reply.
> > 
> > The question now is:
> > When the FA will ever receive a RRP from a HA with a
> Challenge different
> > than the one sent in RRQ?
> > 
> > 1. bogus RRP "we do not need to worry about it"
> > 2. a NON standard HA. "We do not need to worry about it either"`
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 16 Oct 2003 16:58:42 +0200

> FA and HA provides some sort of replay protection! What do you think?

Ok, I'll buy this for now, but that immediately begs the question: Why does
3012 Section 3.2 explicitly specify something different:

   "If the Foreign Agent does not remove the Challenge extension, then
   the Foreign Agent SHOULD store the Challenge value as part of the
   pending registration request list [8].  Also in this case, the
   Foreign Agent MUST reject any Registration Reply message coming from
   the Home Agent that does not also include the Challenge Extension
   with the same Challenge Value that was included in the Registration
   Request.  The Foreign Agent MUST send the rejected Registration
   message to the mobile node, and change the status in the Registration
   Reply to the value MISSING_CHALLENGE (see section 10)."

I don't want to change this unless we understand the reason for specifying
this in the first place.

	Henrik