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

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 3 Oct 2003 13:44:39 +0200

This has been entered in the issue tracker as issue 19.

Submitted by Ahmad Muhanna/Pete McCann
category: Technical
draft: draft-ietf-mip4-rfc3344bis
priority: Should fix
status: No discussion
title: Multiple authorization-enabling extensions should be permitted

     Section 3.5.2 says that "Exactly one authorization-enabling extension
     MUST be present in all Registration Requests". This disallows both the
     MN-FA and the MN-HA authentication extensions in the same Registration
     Request.

     Proposed Solution: 
     Section 3.5.2

     Existing Text:
	 --------------
     Exactly one authorization-enabling extension MUST be present in all
     Registration Requests.

     New Text:
	 ---------
     At least one authorization-enabling extension MUST be present in all
     Registration Requests.

     section 3.6.1.3

     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: (Proposed by Pete McCain/Ahmad)
     ---------
	 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) A mobile-home authentication extension, if present, followed by

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

		 e) An authorization-enabling extension other than Mobile-Home 
			authentication, if present, followed by

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

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

    section 3.8.2.1
    Existing Text:
    --------------
    Registration Requests with an invalid, non-zero UDP checksum MUST be 
    silently discarded by the home agent. 

    The authentication in the Registration Request MUST be checked. 
    This involves the following operations:
 
	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: (Proposed by: Ahmad Muhanna/Pete McCain)
    ---------
	a) The home agent MUST check for the presence of at least one 
	authorization-enabling extension, and perform at least one of the indicated 
	authentication(s). 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 does not have a 
	security association with this home agent, the home agent MAY 
	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. 

	section 3.8.2.3
	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 Request does not satisfy all of the validity checks 
	in Section 3.8.2.1,..."

____________________________________________________________
Mip4 issue tracker <[email-masked]>
<http://ietf.levkowetz.com/ietf/issues/tracker/mip4/issue19>
____________________________________________________________

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