MIPSHOP Working Group W. Haddad Internet-Draft S. Krishnan Expires: April 19, 2006 Ericsson Research October 16, 2005 Combining Cryptographically Generated Address and Crypto-Based Identifiers to Secure HMIPv6 draft-haddad-mipshop-hmipv6-security-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 April 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo describes a method for establishing a security association between the mobile node and the selected mobility anchor point in an hierarchical mobile IPv6 domain. The suggested solution is based on combining the cryptographically generated address (CGA) and crypto- based identifiers (CBID) technologies. Haddad & Krishnan Expires April 19, 2006 [Page 1] Internet-Draft HMIPv6sec October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 7 5. New Messages and Options Format . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Haddad & Krishnan Expires April 19, 2006 [Page 2] Internet-Draft HMIPv6sec October 2005 1. Introduction The Hirarchical Mobile IPv6 Mobility Management [HMIPv6] did not specify nor favor any particular mechanism for establishing a Security Association (SA) between the Mobile Node (MN) and the Mobility Anchor Point (MAP) located within an HMIPv6 domain. This memo describes a method allowing to establish an SA between the MN and the selected MAP. The suggested solution is based on combining the Cyptographically Generated Addresses [CGA] and Crypto- Based Identifiers [CBID]. Haddad & Krishnan Expires April 19, 2006 [Page 3] Internet-Draft HMIPv6sec October 2005 2. Conventions used in this document 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 [TERM]. Haddad & Krishnan Expires April 19, 2006 [Page 4] Internet-Draft HMIPv6sec October 2005 3. Glossary Access Router The Access Router is the Mobile Node's default router. The AR aggregates the outband traffic of mobile nodes. Mobility Anchor Point (MAP) A Mobility Anchor Point is a router located in a network visited by the mobile node, which is used by the MN as a local Home Agent (HA). Regional Care-of Address (RCoA) A Regional Care-of Address is an address obtained by the MN from the visited network. An RCoA is an address on the MAP's subnet and is auto-configured by the MN when receiving the MAP option. On-link Care-of Address (LCoA) The LCoA is the on-link CoA configured on a mobile node's interface based on the prefix advertised by its default router. Local Binding Update (LBU) Message The MN sends a Local Binding Update message to the MAP in order to establish a binding between the RCoA and the LCoA. Pre-Binding Update (PBU) Message The MN's default router sends a Pre-Binding Update message to the MAP upon receiving a valid CGA signature carried by the Route Sollicitation message sent by the MN. Cryptographically Generated Address (CGA) A technique [CGA] whereby an IPv6 address of a node is cryptographically generated by using a one-way hash function from the node's public key and some other parameters. Crypto-Based Identifier (CBID) A technique [CBID] whereby a non-routable identifier is cryptographically generated by using a one-way hash function from the node's public key and an imprint. Binding Acknowledgment (BA) Message Haddad & Krishnan Expires April 19, 2006 [Page 5] Internet-Draft HMIPv6sec October 2005 The MAP sends a binding acknowledgment message to the MN in response to an LBU message. Haddad & Krishnan Expires April 19, 2006 [Page 6] Internet-Draft HMIPv6sec October 2005 4. Proposed Solution We assume that the MN's LCoA is always computed based on the CGA technology, in order to allow the MN to run the secure neighbor discovery procedure described in [SEND]. Such assumption has also been made to provide a security mechanism for the [FMIPv6]. Based on that, the first MN's LCoA will always be a CGA address. In addition, we assume that the MN can discover the presence of an HMIPv6 domain before sending a RtSol message. One way to implement such discovery mechanism is described in the [FRD] proposal. In the following, we suppose that the FRD technology is implemented in all Access Points (APs) (note that the solution is also applicable in other scenarios). The suggested solution introduces a new signaling message, i.e., Pre- Binding Update (PBU) message, which is sent by the AR to the MAP, and on using the Crypto-based ID (CBID) to provide the MAP with sufficient proof of ownership of the suggested RCoA. The PBU message is sent by the AR to the MAP upon receiving a valid RtSol message from the MN and signed with its CGA public key. Finally, the suggested solution is also applicable to the optimized micro-mobility management proposal described in [OMM]. The suggested solution is described in the following steps: o When the MN discovers that it has entered an HMIPv6 domain, it computes an LCoA address by using its CGA key pair and a CBID by hashing the CGA public key together with a 64-bit imprint. o The MN inserts the CBID in the RtSol message, then signs the message as described in SEND and sends it to the AR. o Upon receiving a valid RtSol message carrying a CBID, the AR replies immediately by sending a unicast RtAdv message to the MN and in parallel, a PBT message to the MAP. For this purpose, the AR MUST compute a secret (Ks), encrypts it with the MN's CGA public key and sends it in the RtAdv message. The AR MUST send Ks to the MAP in the PBT message, in addition to the MN's CGA public key, its LCoA and CBID. Note that it is assumed that the PBT messages are signed by the ARs. o After receiving the PBT, the MAP creates a BCE for the MN, which will contain all parameters sent by the AR. Once the BCE is created, the MAP will wait for the owner of the LCoA to send the LBU message. Haddad & Krishnan Expires April 19, 2006 [Page 7] Internet-Draft HMIPv6sec October 2005 o When the MN gets a valid RtAdv message, it sends an LBU message to request the MAP to bind its LCoA to its new RCoA. However, the MN will configure its RCoA by using as interface identifier (iid), the 64 bits, which have been used as imprint to generate the CBID. o Upon receiving an LBU message, the MAP searches its BCEs table for an LCoA, which matches the one sent in the LBU message. If the same LCoA is found, then the MAP hashes the RCoA iid with the stored CGA public key and compares it to the CBID. If, the two hash values are the same, then the MAP generates a long term shared secret, Km, encrypts it with Ks and inserts it in the BA message. o In addition, the MAP MUST insert in the BA message the result obtained from hashing Ks (i.e., hash(Ks) = HKs). However, if the two hash values are not equal then the MAP simply discards the LBU message. o When the MN gets a BA message, it searches first if it carries the HKs. If HKs is correct, then the MN decrypts the shared secret and establishes a bidirectional security association (SA) with the MAP. o Finally, both nodes MUST use Ks to authenticate all subsequent LBU/BA messages exchanged between them. Note that the SA lifetime is set to 24 hours, after which the MN has to request the MAP to renew it. Haddad & Krishnan Expires April 19, 2006 [Page 8] Internet-Draft HMIPv6sec October 2005 5. New Messages and Options Format TBD Haddad & Krishnan Expires April 19, 2006 [Page 9] Internet-Draft HMIPv6sec October 2005 6. IANA Considerations TBD Haddad & Krishnan Expires April 19, 2006 [Page 10] Internet-Draft HMIPv6sec October 2005 7. Security Considerations This proposal suggests using the CBID and CGA technologies in order to avoid increasing the number of messages that need to be signed with an RSA key beyond the SEND procedure. This is recommended due to the fact that public key signature is a computationally expensive and lengthy procedure. The suggested proposal does not create nor enhance any new and/or existing threats. In particular, launching a man-in the middle attack against the MN is not possible because the attacker is not aware of the shared secret. In addition, launching a denial of service attack against the MAP or the MN is not easy due to the fact that both nodes can scan incoming messages for a partial authenticity before validating the authenticity and decrypting the shared secret. Haddad & Krishnan Expires April 19, 2006 [Page 11] Internet-Draft HMIPv6sec October 2005 8. Acknowledgments Authors would like to thank James Kempf for constantly raising security issues in HMIPv6. Haddad & Krishnan Expires April 19, 2006 [Page 12] Internet-Draft HMIPv6sec October 2005 9. References 9.1. Normative References [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3792, March 2005. [FMIPv6] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [HMIPv6] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6)", RFC 4140, August 2005. [SEND] Arkko, J., Kempf, J., Nikander, P., and B. Zill, "Secure Neighbor Discovery (SEND)", RFC 3971, March 2005. [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, BCP , March 1997. 9.2. Informative References [CBID] Montenegro, G. and C. Castelluccia, "Crypto-Based Identifiers (CBID): Concepts and Applications", ACM Transaction on Information and System Security (TISSEC), February 2004. [FRD] Choi, J., Chin, D., and W. Haddad, "Fast Router Discovery with L2 Support", Internet Draft, draft-ietf-dna-frd-00.txt, October 2005. [OMM] Haddad, W., Krishnan, S., Soliman, H., Daley, G., and H. Tschofenig, "Optimized Micro-Mobility Management (OMM)", Internet Draft, draft-haddad-mipshop-omm-00.txt, July 2005. Haddad & Krishnan Expires April 19, 2006 [Page 13] Internet-Draft HMIPv6sec October 2005 Authors' Addresses Wassim Haddad Ericsson Research 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 #2334 Email: Wassim.Haddad@ericsson.com Suresh Krishnan Ericsson Research 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 Email: Suresh.Krishnan@ericsson.com Haddad & Krishnan Expires April 19, 2006 [Page 14] Internet-Draft HMIPv6sec 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. Haddad & Krishnan Expires April 19, 2006 [Page 15]