Mipshop N. Venkitaraman Internet-Draft V. Narayanan Expires: April 17, 2006 Motorola October 14, 2005 Mobile Node-Access Router Authentication Option draft-narayanan-mipshop-mn-ar-auth-option-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 17, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract FMIPv6 [4] requires signalling messages to be exchanged between a mobile node and its access router. For secure interaction, these messages must be authenticated using a security association between the access router and the mobile node. To enable the mobile node and the access router unambiguously identify the correct security association this document extends the mobility header authentication option by defining a subtype to indicate a mobile node - access router SPI. Also, this option can be used in signaling messages used Venkitaraman & Narayanan Expires April 17, 2006 [Page 1] Internet-Draft MN-AR Auth Option October 2005 to derive handover keys between the MN and AR, as described in HK_AAA [5]. The idea here is to re-use the existing mobility option for authentication and only define an additional sub-type for MN-AR authentication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. MN-AR Authentication Mobility Option . . . . . . . . . . . . . 4 4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Processing Considerations . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Venkitaraman & Narayanan Expires April 17, 2006 [Page 2] Internet-Draft MN-AR Auth Option October 2005 1. Introduction Fast Handovers for MIPv6 [4] specifies a protocol to improve handover latency due to Mobile IPv6 procedures by enabling a mobile node bind its CoA with its previous Access Router via a Fast Binding Update (FBU) message. To enable the PAR determine that the FBU is generated by a genuine MN the FBU message must be protected. Mechanisms to create a shared key between the MN and the AR have been proposed in HK_AAA [5] and HK_SEND [6]. This document specifies a means of securing the FBU using shared keys that exist between the MN and PAR using a MN-AR authentication option. It extends the mobility message authentication option defined in [MIP6_Auth] by defining a subtype to indicate a mobile node - access router Security Association. The authentication option enables the mobile node and access router to transfer authentication data and utilize an SPI to index between multiple MN-AR security associations. The option defined in this document is also used in HK_AAA [5] to exchange the SPI and secure MN-AR communication as applicable. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC- 2119 [1]. In addition, this document uses the following terms: MN-AR Mobility Security Association Security relation between Mobile Node and its Access Router, used to authenticate the Mobile Node for mobility service. The MN-AR Security Association between Mobile Node and Access Router consists of a MN-AR mobility SPI, a shared-key, an authentication algorithm and the replay protection mechanism in use. MN-AR Mobility SPI A number in the range [0-4294967296] used to index into the shared-key based MN-AR security associations to protect mobility messages. 3. Applicability The MN-AR Authentication Mobility Option is expected to be used in FMIPv6 for securing the Fast Binding Update between the MN and the old AR. Also, this option is used in securing the MN-AR Handover Key Request/Response messages between the MN and AR in the proposed AAA- based handover key derivation model, as described in HK_AAA [5]. Venkitaraman & Narayanan Expires April 17, 2006 [Page 3] Internet-Draft MN-AR Auth Option October 2005 This document itself does not provide guidelines on the exact usage of this option in these protocols. The exact usage of this option for an applicable protocol is expected to be defined as part of the appropriate protocol specification. This document only defines the type and values for the option itself. 4. MN-AR Authentication Mobility Option This section defines a subtype for the message authentication mobility option defined in MIP6_AUTH [2]. The assumption is that Mobile Node has a shared-key based security association with the Access Router. 4.1. Format The format of the MN-AR authentication mobility option is as defined in Figure 2 in [MIP6_Auth]. It has been reproduced here only for ease of reference. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN-AR Mobility SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: MN-AR Authentication Option The MN-AR authentication mobility option uses the subtype value of 3. This option should be used to authenticate the Fast Binding Update and Fast Binding Acknowledgement messages in FMIPv6 [4] when a shared-key based security association exists between the Mobile Node and the Access Router. Also, this option should be used in securing the Handover Key Request and Response messages described in HK_AAA [5]. This MUST be the last option in a message with mobility header if it is the only authentication option in the message. The authentication data is calculated on the message starting from the mobility header up to and including the mobility SPI value of this option. Venkitaraman & Narayanan Expires April 17, 2006 [Page 4] Internet-Draft MN-AR Auth Option October 2005 Authentication Data = First (96, HMAC_SHA1(MN-AR Shared key, Mobility Data)) Mobility Data = care-of address | home address | Mobility Header(MH) Data MH Data is the content of the Mobility Header up to and including the mobility SPI field of this option. The Checksum field in Mobility Header MUST be set to 0 to calculate the Mobility Data. The first 96 bits from the MAC result are used as the Authentication Data field. 4.2. Processing Considerations The Mobile Node should include this option in to secure messages exchanged with an access router, if it has a shared-key based mobility security association with the Access Router. While including this option the Mobile Node SHOULD use the Mobile Node Identifier Option, specifically the MN-NAI mobility option as defined in MN_ID_OPT [3] to identify itself while authenticating with the Access Router. Mobile Node MAY use Message Identifier option as defined in MIP6_AUTH [2] for additional replay protection. The Access Router should include this option in to secure messages exchanged with a mobile node, if it has a shared-key based mobility security association with the Mobile Node. The Mobile Node or Access Router receiving this option MUST verify the authentication data in the option. If authentication fails, the Access Router MUST send an error to the other entity. The Access Router Agent MAY log such events. The detailed processing rules for messages that contain this option will be defined by the documents specifying the corresponding messages. For instance, the use of this option in FMIPv6 will be defined in the protocol specification for FMIPv6. 5. Security Considerations This document assumes the existence of a shared key between the Mobile Node and the Access Router. It proposes new authentication options to authenticate the control message between Mobile Node and an Access Router. Given that this option is based on the authentication protocol defined in MIP6_AUTH [2], any security Venkitaraman & Narayanan Expires April 17, 2006 [Page 5] Internet-Draft MN-AR Auth Option October 2005 considerations that apply to the authentication protocol also apply to this option. 6. IANA Considerations IANA services are required for this specification. The value for MN-AR authentication mobility option must be assigned. 7. Acknowledgments The authors would like to acknowledge that draft-perkins-mobileip-spi-00 described the use of an SPI option for Mobile IP. 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Patel, A., "Authentication Protocol for Mobile IPv6", draft-ietf-mip6-auth-protocol-07 (work in progress), September 2005. [3] Patel, A., "Mobile Node Identifier Option for MIPv6", draft-ietf-mip6-mn-ident-option-03 (work in progress), September 2005. 8.2. Informative References [4] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [5] Narayanan, V., "Handover Keys using AAA", draft-vidya-mipshop-handover-keys-aaa-01 (work in progress), October 2005. [6] Kempf, J., "Bootstrapping a Symmetric IPv6 Handover Key from SEND", draft-kempf-mobopts-handover-key-01 (work in progress), July 2005. Venkitaraman & Narayanan Expires April 17, 2006 [Page 6] Internet-Draft MN-AR Auth Option October 2005 Authors' Addresses Narayanan Venkitaraman Motorola 1301 E. Algonquin Road Schaumburg, IL 60196 US Email: narayanan.venkitaraman@motorola.com Vidya Narayanan Motorola 1301 E. Algonquin Road Schaumburg, IL 60196 US Email: vidya@motorola.com Venkitaraman & Narayanan Expires April 17, 2006 [Page 7] Internet-Draft MN-AR Auth Option October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Venkitaraman & Narayanan Expires April 17, 2006 [Page 8]