Subject: [Mip4] [Issue] Protection against bogus Registration Requests/Agent Soli citations

From: "Jayshree Bharatia" <[email-masked]>
Date: Wed, 8 Oct 2003 11:22:53 -0500

Hello all,

This email is regarding the current status of issue 2 based on the email
discussion on this mailing list. All agreed changes for this issue will soon
be included in the next version of RFC3012bis. 

Regards,
Jayshree
----------------------------
Change 1
Status: Agreed

Section 3.3
From:
The Foreign Agent SHOULD include a new Mobile-Foreign Challenge Extension in
any Registration Reply, successful or not.  If the foreign agent includes
this extension in a successful Registration Reply, the extension SHOULD
precede a Mobile-Foreign authentication extension.  Suppose the Registration
Reply includes a Challenge extension from the Home Agent, and the foreign
agent wishes to include another Challenge extension with the Registration
Reply for use by the mobile node.  In that case, the foreign agent MUST
delete the Challenge extension from the Home Agent from the Registration
Reply, along with any Foreign-Home authentication extension, before
appending the new Challenge extension to the Registration Reply.  

To: 
The Foreign Agent SHOULD include a previously unused challenge
Mobile-Foreign challenge Extension in any Registration Reply, successful or
not.  If the foreign agent includes this extension in a successful
Registration Reply, the extension SHOULD precede a Mobile-Foreign
authentication extension.  Suppose the Registration Reply includes a
Challenge extension from the Home Agent, and the foreign agent wishes to
include another Challenge extension with the Registration Reply for use by
the mobile node.  In that case, the foreign agent MUST delete the Challenge
extension from the Home Agent from the Registration Reply, along with any
Foreign-Home authentication extension, before appending the new Challenge
extension to the Registration Reply. 

One example of a situation where the Foreign Agent MAY omit the inclusion of
a Mobile-Foreign Challenge Extension in the Registration Reply would be when
a new challenge has been multicast recently. 
  
If a foreign agent has conditions in which it omits the inclusion of a
Mobile-Foreign Challenge Extension in the Registration Reply, it still MUST
respond with an agent advertisement containing a previously unused challenge
in response to a subsequent agent solicitation from the same mobile node.
Otherwise (when the said conditions are not met) the foreign agent MUST
include a previously unused challenge in any Registration Reply, successful
or not.
  
A mobile node MUST be prepared to use a challenge from a unicast or
multicast Agent Advertisement in lieu of one returned in a Registration
Reply, and MUST solicit for one if it has not already received one in a
Registration Reply.

------------------------------------------------
Change 2
Status: Rejected

(change 2.1-Section 3.2)
From:
If the registration message contains a Mobile-Foreign Authentication
extension with an incorrect authenticator that fails verification, the
Foreign Agent MAY send a Registration Reply to the mobile node with Code
value BAD_AUTHENTICATION (see Section 10). 

To: (Added last statement) 
If the registration message contains a Mobile-Foreign Authentication
extension with an incorrect authenticator that fails verification, the
Foreign Agent MAY send a Registration Reply to the mobile node with Code
value BAD_AUTHENTICATION
(see Section 10). In this case, if  the Mobile Node is currently registered,
the challenge included in the  Registration Reply by the Foreign Agent MUST
be the same as the one received in the Registration Request.

(change 2.2-Section 3.2)
From:
If the registration message contains a Mobile-AAA Authentication extension
with an incorrect authenticator that fails verification, the Foreign Agent
MAY send a Registration Reply to the mobile node with Code value
BAD_AAA_AUTHENTICATION_SET_BY_FA. 

To: (Added last statement)
If the registration message contains a Mobile-AAA Authentication extension
with an incorrect authenticator that fails verification, the Foreign Agent
MAY send a Registration Reply to the mobile node with Code value
BAD_AAA_AUTHENTICATION_SET_BY_FA. In this case, if  the Mobile Node is
currently registered, the challenge included in the Registration Reply by
the Foreign Agent MUST be the same as the one received in the Registration
Request.

(change 2.3-Section 3.5)
From:
BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by the Foreign Agent if
the Registration Request contains a Mobile-AAA Authentication extension with
an incorrect authenticator that fails verification.  A Mobile Node that
receives a BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a new Challenge value
in any new registration, obtained either from an Agent Advertisement, or
from a Challenge extension to the Registration Reply containing the error.

To: (Replaced "new Challenge" to "Challenge")
BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by the Foreign Agent if
the Registration Request contains a Mobile-AAA Authentication extension with
an incorrect authenticator that fails verification.  A Mobile Node that
receives a BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a Challenge value in
any new registration, obtained either from an Agent Advertisement, or from a
Challenge extension to the Registration Reply containing the error.

------------------------------------------------
Change 3
Status: Rejected

Section 3.3 (New text)
When responding to an unregistered MN with an unsuccessful Registration
Reply, the FA SHOULD include the same challenge that was last included in a
multicast Agent Advertisement.  When responding to a registered MN with a
successful or unsuccessful Registration Reply, the FA SHOULD include the
same challenge that was last included in a multicast Agent Advertisement,
when that challenge is previously unused by the MN.  Otherwise, the FA
SHOULD include the same challenge that was previously unicast to the MN in a
Registration Reply or Agent Advertisement, unless that challenge was
previously used.  In that case, the FA SHOULD create a new challenge and
return it to the MN, storing a copy of it with the visitor list entry for
that MN.

------------------------------------------------
Change 4
Status: Accepted

Section 12 (New text)
Note that an active attacker may try to prevent successful registrations by
sending a large number of Agent Solicitations or bogus Registration
Requests, each of which could cause the FA to respond with a fresh
challenge, invalidating the challenge that the MN is currently trying to
use.  To prevent such attacks, the FA MUST NOT invalidate previously unused
challenges when responding to unauthenticated Registration Requests or Agent
Solicitations.  In addition, the FA MUST NOT allocate new storage when
responding to such messages, because this would also create the possibility
of denial of service.

------------------------------------------------
Change 5
Status: Accepted

(change 5.1-Section 3.2)
From:
The Foreign Agent MUST NOT accept any Challenge in the Registration Request
unless it was offered in last Registration Reply issued to the Mobile Node,
or else advertised as one of the last CHALLENGE_WINDOW (see section 9)
Challenge values inserted into the immediately preceding Agent
advertisements.

To:
The Foreign Agent MUST NOT accept any Challenge in the Registration Request
unless it was offered in the last Registration Reply or unicast Agent
Advertisement sent to the Mobile Node, or else advertised as one of the last
CHALLENGE_WINDOW (see section 9) Challenge values inserted into the
immediately preceding Agent advertisements.

(change 5.2-Appendix E)
From:
In the program fragment, it is presumed that the foreign agent keeps an
array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record of the
last advertised challenge used by a mobile node, and also a record of the
last challenge provided to a mobile node in a Registration Reply.

To:
In the program fragment, it is presumed that the foreign agent keeps an
array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record of the
last advertised challenge used by a mobile node, and also a record of the
last challenge provided to a mobile node in a Registration Reply or unicast
Agent Advertisement.

To meet the security obligations outlined in Section 12, the FA SHOULD use
one of the already stored, previously unused challenges when responding to
an unauthenticated Registration Request or Agent Solicitation.  If none of
the already stored challenges are previously unused, the FA SHOULD generate
a new challenge, include it in the response, and store it in the per-MN data
structure.

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