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

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 22 Jun 2006 14:52:48 -0400

Yep...same case for other access technologies as well.  That means,
rogue mobiles sending bogus RRQ packets to the HA is extremely slim.

-Kuntal

________________________________

From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Thursday, June 22, 2006 1:06 PM
To: Chowdhury, Kuntal; Kent Leung (kleung)
Cc: Mobile IPv4 Mailing List; Henrik Levkowetz
Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator
fails

Hi Kuntal
  In WiMAX, if MS fails EAP authentication, it is out, it cannot even
send an RREQ.

Regards,

Behcet

----- Original Message ----
From: "Chowdhury, Kuntal" <[email-masked]>
To: Kent Leung (kleung) <[email-masked]>
Cc: Mobile IPv4 Mailing List <[email-masked]>; Henrik Levkowetz
<[email-masked]>
Sent: Thursday, June 22, 2006 10:48:03 AM
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator
fails

> -----Original Message-----
> From: Kent Leung (kleung) [mailto:[email-masked]]
> Sent: Thursday, June 22, 2006 1:43 AM
> 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.
[KC>] If the HA does not send RRP back to the MN, as you initially
suggested, the MN will keep retrying. That is not good either.

Look at other protocols. For example EAP, if auth fails, the
authenticator MUST send back a failure packet to the peer. Same case for
other protocols over UNI. So, I am wondering why the paranoids are not
concerned about MiTM and DoS attacks in general!

Regarding your comment "mucking with the MN-HA AE is not good", if MN-HA
AE is not absolutely necessary in the RRP messages, I will be more than
happy to propose that when code 131 is included, the RRP contains no
MN-HA AE. However, MN-HA AE is a MUST in RRP. So, unless you have a
better suggestion that does not break current implementations, and does
not produce a new mip4 protocol, I don't think we have a choice here.

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

-- 
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: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Thu, 22 Jun 2006 16:25:16 -0400

I thought the issue was avoiding a rouge HA sending a fake RRP with
reject code, and no amount of access control can help that..

From: Chowdhury, Kuntal [mailto:[email-masked]] 
Sent: Thursday, June 22, 2006 1:53 PM
To: Behcet Sarikaya; Kent Leung (kleung)
Cc: Mobile IPv4 Mailing List; Henrik Levkowetz
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator
fails

-Kuntal

Hi Kuntal

Regards,

Behcet

----- Original Message ----
From: "Chowdhury, Kuntal" <[email-masked]>
To: Kent Leung (kleung) <[email-masked]>
Cc: Mobile IPv4 Mailing List <[email-masked]>; Henrik Levkowetz
<[email-masked]>

fails
the
3344
error
MN
have
already.

the
to
extension

---

From: "Avi Lior" <[email-masked]>
Date: Thu, 22 Jun 2006 17:31:13 -0400

A rogue mobile can gain network access and then send bogus MIP Reg
Request totally masquerading the UDP packet. Only specialized
consideration in the access network can thwart that attack, otherwise
the bogus MIP Reg Request is off to the HA. 
 
As well, compromise of a network element in the Access Network could
also send MIP Reg Request especially if Proxy MIP is being used.

	Sent: Thursday, June 22, 2006 2:53 PM

	Yep...same case for other access technologies as well.  That
means, rogue mobiles sending bogus RRQ packets to the HA is extremely
slim.

	-Kuntal

	Hi Kuntal
	  In WiMAX, if MS fails EAP authentication, it is out, it cannot
even send an RREQ.
	
	Regards,
	
	Behcet

	----- Original Message ----
	From: "Chowdhury, Kuntal" <[email-masked]>
	To: Kent Leung (kleung) <[email-masked]>
	Cc: Mobile IPv4 Mailing List <[email-masked]>; Henrik Levkowetz
<[email-masked]>

Authenticator
	fails
	the
	3344
	error
	MN
	have
	already.
	[KC>] If the HA does not send RRP back to the MN, as you
initially
	suggested, the MN will keep retrying. That is not good either.
	
	Look at other protocols. For example EAP, if auth fails, the
	authenticator MUST send back a failure packet to the peer. Same
case for
	other protocols over UNI. So, I am wondering why the paranoids
are not
	concerned about MiTM and DoS attacks in general!
	
	Regarding your comment "mucking with the MN-HA AE is not good",
if MN-HA
	AE is not absolutely necessary in the RRP messages, I will be
more than
	happy to propose that when code 131 is included, the RRP
contains no
	MN-HA AE. However, MN-HA AE is a MUST in RRP. So, unless you
have a
	better suggestion that does not break current implementations,
and does
	not produce a new mip4 protocol, I don't think we have a choice
here.

	the
	to
	extension