Subject: [Mip4] Re: rfc3012bis draft review

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 14 Oct 2003 20:44:44 +0200

Hi Jayshree

	(I'm adding the mip4 list to the recipients. This should go on 
the list.)

Tuesday 14 October 2003, Jayshree wrote:
> > > > > Your proposal for section is to
> > > > > re-add the following text:
> > > > > 
> > > > > "Whenever a Foreign Agent updates a field of the Registration
> > > > > Reply (as suggested in section 3.2), it invalidates the
> > > > > authentication data supplied by the Home Agent in the MN-HA
> > > > > Authentication extension to the Registration Reply.  Thus,
> > > > > this opens up a security exposure whereby a node might try to
> > > > > supply a bogus Registration Reply to a mobile node that causes
> > > > > the mobile node to act as if its Registration Reply were
> > > > > rejected.  This might happen when, in fact, a Registration
> > > > > Reply showing acceptance of the registration might soon be
> > > > > received by the mobile node."
> > > > 
> > > > Yes.
> > > > 
> > > > > Based on the past email discussion we had, it was determined
> > > > > that the information supplied by the HA is not getting
> > > > > invalidated by the FA due to the order of MN-HA Auth extension
> > > > > in the Registration Reply. Hence, this whole paragraph was not
> > > > > applicable.
> > > > 
> > > > I don't see this at all. Section 3.2 suggests that the FA
> > > > change the response code value, which would definitely 
> > > > invalidate the MN-HA Auth extension from the HA. I don't see 
> > > > how we can eliminate the text above.
> > > > 
> > > [JB] Can you quote the exact text of interest in section 3.2? I
> > > will look at that and if necessary we can include the text.
> > 
> > The text I'm thinking of is the following:
> > 
> >                                        "... Also, the Foreign Agent
> >    SHOULD NOT reject any Registration Reply message coming from the
> >    Home Agent that does not include the Challenge Extension.  If the
> >    Challenge Extension is present in the Registration Reply, it MUST
> >    be the same Challenge value that was included in the Registration
> >    Request.  If the Challenge value differs in the Registration
> >    Reply received from the Home Agent, the Foreign Agent MUST reject
> >    the Registration Request and change the status in the
> >    Registration Reply to the Code value MISSING_CHALLENGE (see
> >    section 10)."
> > 
> [JB] I would think that the Registration Reply sent to the mobile node
> is generated by the FA with the appropriate error-code and not really
> relayed what it received from the HA as indicated in the current text.
> We can change the current text to reflect this point. What you think?

That seems to me to be essencially rejecting the Registration Reply
coming from the Home Agent, contrary to what section 3.2 currently says.
Your're then proposing to change the current mechanism in order to be
able to remove a warning text from the draft. I don't think that's a
good idea, necessarily. I'd be most comfortable with not changing the
mechanism and keeping the text from the original draft in there.

	Henrik

---

From: "Jayshree Bharatia" <[email-masked]>
Date: Tue, 14 Oct 2003 17:48:12 -0500

Hi henrik,

I have included my response below.

Thanks,
Jayshree

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Tuesday, October 14, 2003 4:24 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: [email-masked]'; [email-masked]'; [email-masked]
> Subject: Re: [Mip4] Re: rfc3012bis draft review
> 
> 
> > > That seems to me to be essencially rejecting the Registration
> > > Reply coming from the Home Agent, contrary to what section 
> > > 3.2 currently says. Your're then proposing to change the 
> > > current mechanism in order to be able to remove a warning 
> > > text from the draft. I don't think that's a good idea, 
> > > necessarily. I'd be most comfortable with not changing the 
> > [JB] I am not proposing to change the mechanism discussed 
> in section 
> > 3.2. The text pointed out by you basically deals with sending 
> > MISSING_CHALLENGE instead of relaying the Registration 
> Reply received 
> > from the HA. This is the case where the Registration Reply contains 
> > the challenge value different from the one sent in the Registration 
> > Request. I thought you see problem here since the status code is 
> > changed by the FA.
> 
> Well, currently the mechanism is to forward the reg. reply 
> from from the HA, but changing the response code. You propose 
> *not* to forward the reply from the HA, and instead generate 
> a new reply from the FA only.
> 
> That could potentially break a lot of current 
> implementations, where the MN relies on getting supplementary 
> information from the HA, possibly in vendor-specific extensions.
> 
[JB] Agree that this is problematic. Although, the current text has the side
effect anyway if those vendor-specific extensions are intended for
successful registration. Considering this as an agreement, I will include
this text in the document. 

> I don't think we should go down that road.
> 
> 	Henrik
> 
> 

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 16 Oct 2003 10:45:11 -0500

Hi Henrik,

I think Charlie would be the best person to comment on this.

Regards,
Ahmad

> Sent: Thursday, October 16, 2003 9:59 AM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; [email-masked]'; 
> [email-masked]'; [email-masked]
> On Thursday, 16 Oct 2003, Ahmad wrote:
> 
> > 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?
> 
> 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
>