Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails

From: "Yoshi Tsuda \(yotsuda\)" <[email-masked]>
Date: Thu, 22 Jun 2006 15:26:38 +0800

Hi Henrik,

 I have the same opinion with Kent; the RFC3344 has already
 provided the method.

 And, I have another concern, if an HA or an FA should reply
 an RRP to an MN even without having an SA:
 - A malicious host could send an RRQ with any home address
   or NAI to an HA or an FA.  Then, you know, the HA or the FA
   needs to reply an RRP to the specified CoA, even if the host
   of the CoA isn't using Mobile IP service.  This could produce
   another kind of security problem. :(

Thanks.
-Yoshi

> -----Original Message-----
> From: Kent Leung (kleung) 
> Sent: Thursday, June 22, 2006 3:43 PM
> To: Henrik Levkowetz
> Cc: Mobile IPv4 Mailing List
> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the 
> Authenticator fails
> 
> Hi Henrik.  I think the protocol can already handle 
> authentication failures sufficiently.
> 
> It's possible for MN to have multiple security contexts 
> (indexed by different SPIs) with the HA.  One could be used 
> for registration and the other for authenticating RRP with 
> error code 131.  So I believe RFC 3344 provides the mechanism 
> already.  As long as HA has an SA that can be used to protect 
> the RRP with the MN-HA AE, it can inform the MN such event 
> happened in a secure manner.
> 
> I think mucking with the MN-HA AE is not good.  This can 
> create the situation when MN sends a valid RRQ, and MITM can 
> send a RRP with error code 131 and invalid MN-HA AE to the MN 
> immediately.  When the RRP is received, the MN will stop 
> retrying.  It's possible that the RRQ was lost in transit to 
> the HA.  And even if the valid RRP arrives later, MN may not 
> be able to associate with the any pending RRQ, which could 
> have been possibly removed since an associated RRP had been 
> received already.
> 
> Kent
> 
> > -----Original Message-----
> > From: Henrik Levkowetz [mailto:[email-masked]]
> > Sent: Wednesday, June 21, 2006 1:43 PM
> > To: Kent Leung (kleung)
> > Cc: Mobile IPv4 Mailing List
> > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator 
> > fails
> > 
> > Hi Kent,
> > 
> > on 2006-06-21 19:13 Kent Leung (kleung) said the following:
> > > If there is no SA, then I don't think HA should send a RRP. 
> > 
> > Maybe, but it leaves the MN and user with less information 
> than it/he 
> > could have.  I think that the best would be if we could find a 
> > standard way of handling this situation.
> > 
> > Fwiw, this has come up before, we discussed how to handle this at 
> > ipUnplugged some time ago - it's a real situation when 
> you're setting 
> > up and deploying a network.
> > 
> > Regards,
> > 
> > 	Henrik
> > 
> > > Kent
> > > 
> > >> -----Original Message-----
> > >> From: Chowdhury, Kuntal [mailto:[email-masked]]
> > >> Sent: Wednesday, June 21, 2006 10:05 AM
> > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List
> > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the
> > Authenticator
> > >> fails
> > >> 
> > >> Kent/Avi,
> > >> 
> > >> The current text does not say that the HA cannot send RRP
> > when auth
> > >> fails. Rather it says that the HA "SHOULD" send RRP back 
> to the MN:
> > >> 
> > >> > if the Authenticator is invalid, the home agent MUST 
> reject  the 
> > >> > mobile node's registration and SHOULD send a
> > Registration Reply to
> > >> > the mobile node with Code 131"
> > >> 
> > >> What we need is a proper description of the HA and the MN
> > behaviors
> > >> when the auth fails and the HA needs to send a RRP to 
> stop the MN 
> > >> from re-trying unnecessarily.
> > >> 
> > >> The clarification could be: 
> > >> 
> > >> If the Authenticator is invalid, the home agent MUST reject the 
> > >> mobile node's registration and SHOULD send a 
> Registration Reply to 
> > >> the mobile node with Code 131. In this case, the HA 
> populates the 
> > >> MN-HA AE with all 0s. Upon receiving the RRP with error
> > code 131, the
> > >> MN skips MN-HA AE validation and stops retrying registration 
> > >> attempts. The MN MAY log this event in its internal log.
> > >> 
> > >> What do you think?
> > >> 
> > >> -Kuntal
> > >> 
> > >> > -----Original Message-----
> > >> > From: Kent Leung (kleung) [mailto:[email-masked]]
> > >> > Sent: Wednesday, June 21, 2006 11:43 AM
> > >> > To: Avi Lior; Mobile IPv4 Mailing List
> > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the
> > Authenticator
> > >> > fails
> > >> > 
> > >> > Hi Avi.  My understanding is that in this case, the HA
> > will not be
> > >> > able to send an RRP if it does not have an SA with the
> > MN because
> > >> > this message requires MN-HA AE.  The text state that if HA has
> > >> an SA, then
> > >> to
> > >> > use that in the RRP.  Without an SA, the HA should drop
> > the  RRQ, IMHO.
> > >> > 
> > >> > Kent
> > >> > 
> > >> > > -----Original Message-----
> > >> > > From: Avi Lior [mailto:[email-masked]]
> > >> > > Sent: Wednesday, June 21, 2006 8:13 AM
> > >> > > To: Mobile IPv4 Mailing List
> > >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the
> > Authenticator
> > >> > > fails
> > >> > >
> > >> > > Hi,
> > >> > >
> > >> > > While working a scenario in WiMAX I have run into some
> >  ambiguity
> > >> > > in RFC3344.
> > >> > >
> > >> > > The HA receives a Reg Request with MN-HA-AE and NAI  
> extension 
> > >> > > which it fails to authenticate.  In particular the HA cant 
> > >> > > authenticate because it can't obtain the MN-HA from
> > the AAA using the NAI.
> > >> > >
> > >> > > >From section 3.8.2.1 RFC3344 states that a Registration
> > >> > > Reply should be
> > >> > > sent with code 131.
> > >> > >
> > >> > > "if the Authenticator is invalid, the home agent MUST
> > reject the
> > >> > > mobile node's registration and SHOULD send a
> > Registration  Reply
> > >> > > to the mobile node with Code 131"
> > >> > >
> > >> > > And from section 3.6.2.1 describing the MN behavior we have:
> > >> > >
> > >> > >    "If the Code field indicates an authentication  failure, 
> > >> > > either at the
> > >> > >    foreign agent or the home agent, then it is quite
> > possible that any
> > >> > >    authenticators in the Registration Reply will also
> > be  in error.  
> > >> > > This
> > >> > >    could happen, for example, if the shared secret
> > between the mobile
> > >> > >    node and home agent was erroneously configured.  
> > The  mobile node
> > >> > >    SHOULD log such errors as security exceptions."
> > >> > >
> > >> > > RFC3344 also states that Registration Reply MUST
> > include a MN-HA
> > >> > > authentication extension:
> > >> > >
> > >> > > Section 3.8.3.3 says  " Note that items (a) and (c)
> > MUST  appear
> > >> > > in every Registration Reply sent by the home agent."
> > >> > >
> > >> > > where  (c) is  The Mobile-Home Authentication Extension.
> > >> > >
> > >> > > The problem is that when MN-HA-AE fails at the HA
> > there isnt an
> > >> > > available MN-HA authentication extension to use.  So
> > how can one
> > >> > > send a registration reply?
> > >> > >
> > >> > > Furthermore, if the HA cant not obtain an MN-HA for
> > the  mobile,
> > >> > > what should happen?
> > >> > >
> > >> > >
> > >> > > Any help will be appreciated.
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > =3D=======================
> > >> > >
> > >> > > Avi Lior
> > >> > > Bridgewater Systems Corporation Phone :  +1 (613) 591-9104 
> > >> > > x6417
> > >> > > Cell    :  +1 (613) 796-4183
> > >> > > E-mail : mailto:[email-masked] 
> > >> > > <mailto:[email-masked]>
> > >> > > www.bridgewatersystems.com 
> <http://www.bridgewatersystems.com/>
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Mip4 mailing list: [email-masked]
> > >> > >     Web interface: 
> https://www1.ietf.org/mailman/listinfo/mip4
> > >> > >      Charter page: 
> > >> > > http://www.ietf.org/html.charters/mip4-charter.html
> > >> > > Supplemental site: http://www.mip4.org/
> > >> > >
> > >> > 
> > >> > --
> > >> > Mip4 mailing list: [email-masked]
> > >> >     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
> > >> >      Charter page:  
> > >> > http://www.ietf.org/html.charters/mip4-charter.html
> > >> > Supplemental site: http://www.mip4.org/
> > >> 
> > >> 
> > >> "This email message and any attachments are confidential
> > information
> > >> of Starent Networks, Corp. The information transmitted 
> may not be 
> > >> used to create or change any contractual obligations of Starent 
> > >> Networks, Corp.  Any review, retransmission, dissemination
> > or other
> > >> use of, or taking of any action in reliance upon this
> > e-mail and its
> > >> attachments by persons or entities other than the intended
> > recipient
> > >> is prohibited. If you are not the intended recipient,
> > please notify
> > >> the sender immediately -- by replying to this message or
> > by sending
> > >> an email to [email-masked] -- and destroy
> > all copies
> > >> of this message and any attachments without reading or 
> disclosing 
> > >> their contents. Thank you."
> > >> 
> > > 
> > 
> > 
> 
> --
> Mip4 mailing list: [email-masked]
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
> 

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 22 Jun 2006 10:11:55 +0200

Hi Yoshi,

>  I have the same opinion with Kent; the RFC3344 has already

Here we disagree.  See my recent mail to Kent and the list.

>    another kind of security problem. :(

Agreed.

This is a valid point, and has to be taken into consideration in any
proposed solution to the original problem.  Which still doesn't mean
that we can ignore that problem.

Regards,

	Henrik