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

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Wed, 21 Jun 2006 23:43:14 -0700

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/

---

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

Hi Kent,

> Hi Henrik.  I think the protocol can already handle authentication

Well, I'm not quite as convinced :-)

> other for authenticating RRP with error code 131.

But this assumes that you've actually managed to set things up correctly.
In which case I don't see why you couldn't manage with only one context.

No, the problem I'm concerned with is primarily with the case when you're
first rolling out a service, and haven't smoothed out all the wrinkles -
the case where something has gone wrong, and you either can get some
information through to the user device, or you can't.

>  So I believe RFC 3344

Yes, sure - but that's not the use case under consideration, as indicated
above.

> code 131 and invalid MN-HA AE to the MN immediately.

Oh, agreed!  I'm not suggesting that we should permit that - I'm trying
to point out that there actually is a problem here, and we should see if
we can solve it, rather than closing our eyes to it...

>  When the RRP is
> received, the MN will stop retrying.

Well, it shouldn't do that if it gets an un-authenticated reply.  That
doesn't mean that the reply shouldn't be sent; and it also doesn't mean
that some indication can't be made to a log-file and the user.

>  It's possible that the RRQ was

Yes.  So there are very good reasons not to accept an un-authenticated
reply.  Now, what can we do to alleviate the problem which exists when
there actually is a mismatch in authentication setup?

	Henrik

>> >> 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 
>> >> What we need is a proper description of the HA and the MN  behaviors 
>> >> MN-HA AE with all 0s. Upon receiving the RRP with error  code 131, the 
>> >> > 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 
>> >> > use that in the RRP.  Without an SA, the HA should drop  the  RRQ, IMHO.
>> >> > 
>> >> > Kent
>> >> > 
>> >> > > 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.
>> >> > >
>> >> > > authenticate because it can't obtain the MN-HA from  the AAA using the NAI.
>> >> > >
>> >> > > "if the Authenticator is invalid, the home agent MUST  reject the 
>> >> > > mobile node's registration and SHOULD send a  Registration  Reply 
>> >> > >    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
>> >> > > RFC3344 also states that Registration Reply MUST  include a MN-HA 
>> >> > > Section 3.8.3.3 says  " Note that items (a) and (c)  MUST  appear 
>> >> > > 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 
>> >> > > Furthermore, if the HA cant not obtain an MN-HA for  the  mobile, 
>> >> > > what should happen?
>> >> > >
>> >> > >
>> >> "This email message and any attachments are confidential  information 
>> >> 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