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

From: "Jayshree Bharatia" <[email-masked]>
Date: Fri, 30 Jan 2004 12:42:42 -0600

Hello Charlie,

Looks like there is no change shown in the "Existing Text" and "New Text"
for section 3.8.2.1. We need changes in this paragraph to allow multiple
authorization-enabling extensions in the Registration Request. 

I believe there was some text proposed earlier on the mailing list for this.

Regards,
Jayshree

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Wednesday, January 28, 2004 5:52 PM
> To: [email-masked]
> Subject: [Mip4] [issue 19] Multiple authorization-enabling 
> extensions should be permitted
> 
> 
[...]
> ==============================================================
> ===============
> 
> 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.
> 
[...]

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 30 Jan 2004 11:07:09 -0800

Hello Jayshree,

Yes, as it turns out it was a cut and paste error.
The text I labeled as the "new text" was NOT the
new text.  Here is the actual new text that should
have been pasted in:

      a)   The home agent MUST check for the presence of at least
           one authorization-enabling extension, and ensure that
           all indicated authentications are carried out.  At least
           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 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.  If the home agent receives a
           Registration Request without a Mobile-Home Authentication
           extension from a Mobile Node that has a security association
           with this home agent, the home agent MUST discard the Mobile
           Node's Registration Request.

      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
           that the home agent used to authenticate the Mobile Node's
           Registration Request.  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.

And, for convenience, here is the old text again:

      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.

Thanks again for pointing out the mistake; please let me know if
you think it serves the intended purpose.  Because of discussion
at the last IETF, I thought that some of the changes from the earlier
proposed text needed to be reformulated, so I didn't use it verbatim.

Regards,
Charlie P.

> I believe there was some text proposed earlier on the mailing list for this.

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