Subject: [Mip4] [issue 19] Multiple authorization-enabling extensions should be permitted

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Jan 2004 15:51:43 -0800

Hello folks,

Please refer to previous discussion at the following URL:
        http://www.mip4.org/issues/tracker/mip4/issue19
as necessary.

Discussion at IETF58 was not wholly conclusive.
I have taken the suggested wording changes, and
incorporated the mandate that the home agent must
insure that all verifications have taken place.
The home agent is sometimes unable to make the
verification directly, so some of the suggested
wording changes required slight additional modification.

=============================================================================

Section 3.5.2

Existing Text:
   Exactly one authorization-enabling extension MUST be present in all
   Registration Requests, and also in all Registration Replies generated
   by the Home Agent.  The Mobile-Home Authentication Extension is
   always an authorization-enabling for registration messages specified
   in this document.  This requirement is intended to eliminate problems
   [2] which result from the uncontrolled propagation of remote
   redirects in the Internet.  The location of the extension marks the
   end of the authenticated data. 

New Text:
   At least one authorization-enabling extension MUST be present in   
   all Registration Requests, and also in all Registration Replies
   generated by the Home Agent.  The Mobile-Home Authentication
   Extension is always an authorization-enabling for registration
   messages specified in this document.  This requirement is intended
   to eliminate problems [2] which result from the uncontrolled
   propagation of remote redirects in the Internet.  The location of
   the authorization-enabling extension marks the end of the data to
   be authenticated by the authorizing agent interpreting that
   authorization-enabling extension.

=============================================================================

Section 3.6.1.3

Note in the discussion about revised text
for section 3.6.1.3, that the Mobile-Foreign
authentication extension was never intended to
be an authorization-enabling extension.  The only
new extension, defined after RFC 2002, which is
specified to be an authorization-enabling extension
is the MN-AAA extension.

Finally, I did not see why item (c) in 3.6.1.3 was
changed back to be MN-HA, since that position in the
ordering of extensions was previously enabled to
contain the MN-AAA authentication extension.
Moreover, the previously suggested wording would
not allow the foreign agent to remove extensions
that were only meant for its own use, since
presumably the AAA or other authorizing agent
is somewhere external to the foreign agent.  If
the foreign agent is intended to be the authorizing
agent, then the new text below takes that into
account.

Existing Text:
   This section describes the ordering of any mandatory and any optional
   Extensions that a mobile node appends to a Registration Request.
   This following ordering MUST be followed:

      a) The IP header, followed by the UDP header, followed by the  
         fixed-length portion of the Registration Request, followed by
      
      b) If present, any non-authentication Extensions expected to be
         used by the home agent (which may or may not also be useful to
         the foreign agent), followed by

      c) An authorization-enabling extension, followed by

      d) If present, any non-authentication Extensions used only by the
         foreign agent, followed by

      e) The Mobile-Foreign Authentication Extension, if present.

   Note that items (a) and (c) MUST appear in every Registration Request
   sent by the mobile node.  Items (b), (d), and (e) are optional.
   However, item (e) MUST be included when the mobile node and the
   foreign agent share a mobility security association.

New text:

   This section describes the ordering of any mandatory and any optional
   Extensions that a mobile node appends to a Registration Request.
   This ordering is REQUIRED:

      a)   The IP header, followed by the UDP header, followed by the
           fixed-length portion of the Registration Request, followed by

      b)   If present, any non-authentication Extensions expected to be
           used by the home agent or other authorizing agent (which may
           or may not also be useful to the foreign agent), followed by

      c)   All authorization-enabling extensions, followed by

      d)   If present, any non-authentication Extensions used only by
           the foreign agent, followed by

      e)   The Mobile-Foreign Authentication Extension, if present.

   Note that items (a) and (c) MUST appear in every Registration Request
   sent by the mobile node.  Items (b), (d), and (e) are optional.
   However, item (e) MUST be included when the mobile node and the
   foreign agent share a mobility security association.

=============================================================================

section 3.8.2.1

Existing text:

      a) The home agent MUST check for the presence of an 
         authorization-enabling extension, and perform the indicated
         authentication.  Exactly one authorization-enabling extension
         MUST be present in the Registration Request; and the home agent
         MUST either check the Authenticator value in the extension or
         verify that the authenticator value has been checked by another
         agent with which it has a security association.  If no
         authorization-enabling extension is found, or if more than one
         authorization-enabling extension is found, or 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.  The home agent MUST then discard
         the Request and SHOULD log the error as a security exception.

      b) The home agent MUST check that the registration Identification
         field is correct using the context selected by the SPI within
         the authorization-enabling extension.  See Section 5.7 for a
         description of how this is performed.  If incorrect, the home
         agent MUST reject the Request and SHOULD send a Registration
         Reply to the mobile node with Code 133, including an
         Identification field computed in accordance with the rules
         specified in Section 5.7.  The home agent MUST do no further
         processing with such a Request, though it SHOULD log the error
         as a security exception.

New text:
      a)   The home agent MUST check for the presence of an
           authorization-enabling extension, and perform the indicated
           authentication.  Exactly one authorization-enabling extension
           MUST be present in the Registration Request; and the home
           agent MUST either check the Authenticator value in the
           extension or verify that the authenticator value has been
           checked by another agent with which it has a security
           association.  If no authorization-enabling extension is
           found, or if more than one authorization-enabling extension  
           is found, or 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.  The 
           home agent MUST then discard the Request and SHOULD log the 
           error as a security exception.

      b)   The home agent MUST check that the registration
           Identification field is correct using the context selected
           by the SPI within the authorization-enabling extension.  See
           Section 5.7 for a description of how this is performed.  If
           incorrect, the home agent MUST reject the Request and SHOULD
           send a Registration Reply to the mobile node with Code 133,
           including an Identification field computed in accordance with
           the rules specified in Section 5.7.  The home agent MUST do
           no further processing with such a Request, though it SHOULD
           log the error as a security exception.

=============================================================================

Section: 3.8.2.3.

I wonder how long this mistake has been sitting there unnoticed!!!

Existing text:
   If the Registration Reply does not satisfy all of the validity checks
   in Section 3.8.2.1  ........

New text:
   If the Registration Reply does not satisfy all of the validity checks
   in Section 3.8.2.1  ........

=============================================================================

Regards,
Charlie P.

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Jan 2004 16:11:33 -0800

Hello folks,

It was pointed out (thanks, Alan!) that I still didn't
properly illustrate the needed change in 3.8.2.3:

That new text should be:
   If the Registration Request does not satisfy all of the validity checks
   in Section 3.8.2.1  ........

It has been corrected in the revised document for sure now.

Regards,
Charlie P.