MIPSHOP Working Group A. Yegin Internet-Draft Samsung Expires: January 29, 2007 K. Chowdhury Starent Networks July 28, 2006 HMIP Security Association draft-yegin-hmip-sa-00 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 January 29, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes a mechanism to dynamically generate a security association between the mobile node and the mobility anchor point to secure the HMIPv6 protocol messages. The mechanism relies on generating a local security association based on the network access authentication. Yegin & Chowdhury Expires January 29, 2007 [Page 1] Internet-Draft HMIP Security Association July 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. HMIP Security Association . . . . . . . . . . . . . . . . . . 4 2.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Key Distribution . . . . . . . . . . . . . . . . . . . . . 4 3. Using the SA . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Support for non-EAP-based Architectures . . . . . . . . . . . 6 5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Yegin & Chowdhury Expires January 29, 2007 [Page 2] Internet-Draft HMIP Security Association July 2006 1. Introduction The current Hierarchical Mobile IPv6 (HMIP) protocol [RFC4140] lacks a mechanism to secure the signaling between the mobile node (MN) and the mobility anchor point (MAP). At the core of this problem is the absence of a security association (SA) between the two nodes. When the SA is present, it can be utilized along with IKEv2/IPsec [I-D.ietf-mip6-ikev2-ipsec] or the mobility authentication option [RFC4285] to provide authentication and integrity protection for the protocol messages. EAP [RFC3748] is used in various mobile and wireless network architectures (e.g., WiFi, WiMAX, cdma2K). One important feature of EAP is its ability to dynamically generate a secret key shared by the EAP peer running on the MN and the authenticator running on the network access server (NAS). This shared secret key (MSK -- master session key [RFC3748]) can be utilized to derive another secret key (HMIP-key) to be shared by the MN and the MAP in the access network. This document describes how HMIP-key can be derived and used to secure HMIP protocol messages. Yegin & Chowdhury Expires January 29, 2007 [Page 3] Internet-Draft HMIP Security Association July 2006 2. HMIP Security Association HMIP security association (HMIP-SA) includes four parameters: The peer identifier (HMIP-PID), the shared secret key (HMIP-key), the SPI (HMIP-SPI), and the SA lifetime (HMIP-lifetime). HMIP-PID of the MN is the Identity used during the EAP authentication. HMIP-PID of the MAP is the IP address of the MAP. HMIP-key is generated according to the following subsections. HMIP-SPI value MUST be set to 1 upon initial EAP authentication with the authenticator, increased by 1 for each subsequent EAP re- authentication with the same authenticator, and set back to 1 after wrapping around. HMIP-lifetime is set to the lifetime of the MSK. 2.1. Key Derivation The following formula is used to generate HMIP-key. HMIP-key = HMAC-SHA1(MSK, "HMIPv6 key derivation" | MN-ID | MAP- IPaddr) MSK is the secret key generated by the EAP method execution and shared by the MN and the NAS [RFC3748]. MN-ID is the Indetity presented by the MN during the EAP authentication. MAP-IPaddr is the IP address of the MAP used for HMIPv6 protocol messaging. 2.2. Key Distribution Since the EAP peer and HMIPv6 mobile node implementations reside on the same MN, derivation and delivery of the HMIP-SA is internal to that node. There is no additional protocol needed to carry the SA parameters. In case the MAP and the NAS are not colocated in a given architecture or deployment, there needs to be a protocol to carry the SA parameters from the NAS to the MAP. There is always a protocol used for AAA purposes between the NAS and a service node like MAP in architectures where such separation is supported. Whether it is RADIUS, Diameter, or an architecture-specific proprietary protocol, the details are outside the scope of this document. Yegin & Chowdhury Expires January 29, 2007 [Page 4] Internet-Draft HMIP Security Association July 2006 3. Using the SA The dynamically generated SA can be directly used with either IKEv2/ IPsec [I-D.ietf-mip6-ikev2-ipsec] or the mobility authentication option [RFC4285]. Yegin & Chowdhury Expires January 29, 2007 [Page 5] Internet-Draft HMIP Security Association July 2006 4. Support for non-EAP-based Architectures The same mechanism can be used with any architecture as long as there is an equivalent of MSK shared between the MN and the NAS. Since such a key would be architecture specific, it is hard to define it in a generic but interoperable way in this document.[TBD: Give an example from 3GPP.] Yegin & Chowdhury Expires January 29, 2007 [Page 6] Internet-Draft HMIP Security Association July 2006 5. Future Work TBD: Cut another copy of the document for FMIPv6 security == s/HMIP/ FMIP + a bit of editing. Yegin & Chowdhury Expires January 29, 2007 [Page 7] Internet-Draft HMIP Security Association July 2006 6. Security Considerations TBD. Yegin & Chowdhury Expires January 29, 2007 [Page 8] Internet-Draft HMIP Security Association July 2006 7. IANA Considerations This document has no actions for IANA. Yegin & Chowdhury Expires January 29, 2007 [Page 9] Internet-Draft HMIP Security Association July 2006 8. References 8.1. Normative References [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005. 8.2. Informative References [I-D.ietf-mip6-ikev2-ipsec] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", draft-ietf-mip6-ikev2-ipsec-06 (work in progress), April 2006. [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006. Yegin & Chowdhury Expires January 29, 2007 [Page 10] Internet-Draft HMIP Security Association July 2006 Authors' Addresses Alper E. Yegin Samsung Advanced Institute of Technology Phone: Email: alper01.yegin@partner.samsung.com Kuntal Chowdhury Starent Networks Phone: Email: kchowdhury@starentnetworks.com Yegin & Chowdhury Expires January 29, 2007 [Page 11] Internet-Draft HMIP Security Association July 2006 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 (2006). 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. Yegin & Chowdhury Expires January 29, 2007 [Page 12]