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

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 21 Jun 2006 13:05:10 -0400

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

-- 
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: "Tsirtsis, George" <[email-masked]>
Date: Wed, 21 Jun 2006 10:50:40 -0700

Usually it is not a good idea to be responding to messages that fail
authentication because that can be used to mound DoS attacks. It is
better to silently discard such messages.

The RFC also talks about authorization-enabling extensions and it is a
bit unclear on which extensions qualify for that. Most people think of
the MN-HA Authenticator to be an authentication-enabling extension.
Others think that the MN-AAA Authenticator or even an FA-HA
authenticator could play this role in some scenarios.

It would be nice not to loose this flexibility while clarifying the
text.

George
> From: Chowdhury, Kuntal [mailto:[email-masked]]
> Sent: Wednesday, June 21, 2006 1:05 PM
> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List
fails

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 21 Jun 2006 13:53:57 -0700

Hello George,

> better to silently discard such messages.
I definitely do not agree with this, because the registration process is
already rate limited.   This was put in exactly to avoid DoS.

> authenticator could play this role in some scenarios.
MN-AAA was explicitly designed to be authorization-enabling, and I did not
think this was unclear.  In fact, the entire process of inserting the 
new terminology
about "authorization-enabling" was aimed exactly at having another kind of
authorizing extension -- namely, the MN-AAA extension.

FA-HA was never designed to be authorization-enabling,  but if sufficiently
large amount of control is removed from the mobile node I can see where
operators would like that.
> It would be nice not to loose this flexibility while clarifying the
I'll have to try to catch up on the rest of this thread while
watching the fires burn out of control elsewhere, sigh.

Regards,
Charlie P.

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 21 Jun 2006 14:02:13 -0700

> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Wednesday, June 21, 2006 4:54 PM
> To: Tsirtsis, George
> Cc: Chowdhury, Kuntal; Kent Leung (kleung); Avi Lior; Mobile IPv4
Mailing
> List
> Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator
fails
> operators would like that.

GT> There is value in the FA-HA auth extension being an
authentication-enabling extension in scenarios other than netlmm. In
some scenarios for example where the access control is done at the FA
and the FA and HA are in the same domain, a "chain of trust" model can
be used i.e, MN-FA Auth and FA-HA Auth. 

George

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 21 Jun 2006 17:55:12 -0400

Hi guys, 

I agree with Kuntal, except a MUST for reject should be accompanied by a
MUST for sending the RRP with the code, not a SHOULD as Kuntal's text
suggest, otherwise how would the MN know about the rejection. However,
the MN-HA-AE filled with 0 worries me a bit, since anybody could send
such an unsigned rejection to the MN and in a sense do a DoS for HA!!

-----Original Message-----
From: Chowdhury, Kuntal [mailto:[email-masked]] 
Sent: Wednesday, June 21, 2006 12:05 PM
To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator
fails

Kent/Avi,

What do you think?

-Kuntal

fails
able
to
fails
any
mobile

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 21 Jun 2006 17:58:39 -0400

Great, I see that George and I feel the same way about the security
threat of sending unsigned RRP. I was going to suggest use of MN-AAA
authenticator, but that means RRP has to go to the AAA server and hence
the use of RFCs other than 3344 for key bootstrapping, so it might cause
extra implementation burdens for people who only want to implement 3344.

-----Original Message-----
From: Tsirtsis, George [mailto:[email-masked]] 
Sent: Wednesday, June 21, 2006 12:51 PM
To: Chowdhury, Kuntal; Kent Leung (kleung); Avi Lior; Mobile IPv4
Mailing List

George
fails

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 21 Jun 2006 19:46:06 -0400

I 
Ignoring the security issues with that "chain of trust" and how it is
practically done, are you envisioning a case where MN has an SA with FA
but not with HA?? I am curious on what scenario that is.
The scenario I can think of is a case where FA is part of some access
network edge device and MN-FA SA is established through authentication.

Scalability-wise it would make sense to use AAA and the MN-AAA AE to
bootstrap the MN-HA, but as I said earlier, it would require other RFCs
such as 3957.

Madjid

George