MIPSHOP Working Group W. Haddad Internet-Draft S. Krishnan Expires: December 28, 2006 Ericsson Research H. Soliman Qualcomm-Flarion June 26, 2006 Using Cryptographically Generated Addresses (CGA) to secure HMIPv6 Protocol (HMIPv6sec) draft-haddad-mipshop-hmipv6-security-04 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 December 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 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 using the cryptographically generated address technology. Haddad, et al. Expires December 28, 2006 [Page 1] Internet-Draft HMIPv6sec June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6 5. New Messages and Options Format . . . . . . . . . . . . . . . 9 5.1. The Pre-Binding Update (PBU) Message Format . . . . . . . 9 5.2. Third Party Shared Key (TPSK) Option . . . . . . . . . . . 10 5.3. The MAP Session Mobility Secret (MSMS) Option . . . . . . 10 5.4. Third Party Hash Secret (TPHS) Option . . . . . . . . . . 11 5.5. The Session Mobility Secret (SMS) Option . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Haddad, et al. Expires December 28, 2006 [Page 2] Internet-Draft HMIPv6sec June 2006 1. Introduction The Hierarchical 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, which allows the MN to establish an SA with the selected MAP. The suggested solution is based on using the Cryptographically Generated Address technology (described in [CGA]). Haddad, et al. Expires December 28, 2006 [Page 3] Internet-Draft HMIPv6sec June 2006 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, et al. Expires December 28, 2006 [Page 4] Internet-Draft HMIPv6sec June 2006 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 Router Solicitation (RtSol) message signed with CGA technology as described in the secure neighbor discovery protocol [SEND]. Cryptographically Generated Address (CGA) A technique described in [CGA] whereby an IPv6 address of a node is cryptographically generated by using a one-way hash function from the node's public key (Kp) and some other parameters. Binding Acknowledgment (BA) Message The MAP sends a binding acknowledgment message to the MN in response to an LBU message. Haddad, et al. Expires December 28, 2006 [Page 5] Internet-Draft HMIPv6sec June 2006 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 SEND protocol. Such assumption has also been made in [FMIPkey], which aims to provide a security mechanism for [FMIPv6] protocol, and in the [OptiSEND] protocol, which aims to optimize SEND protocol. In addition, we assume that the MN can discover the presence of an HMIPv6 domain before sending a RtSol message, e.g., by using technologies described in [FRD]. However, the proposed solution works with the same performance without such assumption. In fact, our motivation behind suggesting the FRD protocol aims above all to reduce the handoff latency. The suggested solution introduces a new signaling message, i.e., the Pre-Binding Update (PBU) message, which is sent by the AR to the MAP upon receiving a RtSol message from the MN carrying a valid signature (i.e., the message is signed with the MN's CGA private key). The following figure shows the signaling diagram for establishing a bidirectional SA between the MN and the MAP: 1. MN to AR: Router Solicitation [CGA Signature] (RtSol) 2a. AR to MN: Router Acknowledgement [Ks] (RtAdv) 2b. AR to MAP: Pre-Binding Update [Ks + LCoA] (PBU) 3. MN to MAP: Local Binding Update [DH value (X)] (LBU) 4. MAP to MN: Binding Acknowledgment [HKs + DH value (Y)] (BA) The suggested solution is described in the following steps: o the MN configures a 64-bit interface identifier (IID) from using CGA technology then use it to send a RtSol message signed with CGA, according to the SEND protocol. Note that at this stage, the MN may not be aware that it has entered an HMIPv6 domain. o Upon receiving a valid unicast RtSol message, the AR replies immediately by sending back a unicast RtAdv message to the MN and in parallel, a PBU 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 unicast RtAdv message. The shared secret is inserted in a new option (Third Party Shared Key (TSPK)), which is carried by the unicast RtAdv message. The AR MUST also compute the LCoA and RCoA that the MN is supposed to autoconfigure. For this purpose, the LCoA is computed by appending the 64-bit IID used in the RtSol message to the 64-bit prefix advertised by the AR and the RCoA is computed by appending the 64-bit prefix advertised by the MAP with the 64-bit IID Haddad, et al. Expires December 28, 2006 [Page 6] Internet-Draft HMIPv6sec June 2006 computed in the following way: RCoA (IID) = First (64, SHA1(Ks | LCoA)) Where First(x,y) is a function, which extracts the first x bits from y and LCoA is the MN's on link care-of address. After computing the MN's LCoA and RCoA, the AR inserts the two IPv6 addresses and Ks in the PBU message and sends it to the MAP. Note that it is assumed that the PBU messages are signed by the ARs and the paths between the ARs and the MAP are secure. o After receiving the PBU message, the MAP creates a binding cache entry (BCE) for the MN, in which it stores the MN's LCoA, RCoA and Ks carried by the PBU message. Once the BCE is created, the MAP waits for a limited amount of time for the owner of the two addresses to send the LBU message. If no valid LBU message is received during the BCE preconfigured lifetime then the MAP SHOULD delete it. o When the MN gets a valid RtAdv message, it discovers that it has entered an HMIPv6 domain. The following is based on the assumption that the MN decides to use the MAP as its local Home Agent, which means that the MN has to configure an RCoA then request the MAP to create a BCE. For this purpose, the MN SHOULD use the same method as the AR (described earlier) to autoconfigure its RCoA and LCoA. After that, the MN initiates a Diffie-Hellman (DH) procedure with the MAP by sending its DH public value (X) in a new option (Session Mobility Secret (SMS)), which is carried by the first LBU message sent to the MAP. The first LBU message is also used to request the MAP to bind its LCoA to its new RCoA. 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 computes the RCoA IID in the same way as described above, and compares it to the one claimed by the MN in the LBU message. If the two addresses are the same, then the MAP completes the DH exchange by sending its own DH public value (Y) in a new option (MAP Session Mobility Secret (MSMS)), which is carried by the BA message sent to the MN. In addition, the MAP MUST send in the BA message the hash of Ks (i.e., hash(Ks) = HKs), which will be carried in another new option (Third Party Hash Secret (TPHS)). By sending (Y) to the MN, both nodes will be able to compute the session mobility key (Ksm) (i.e., from values (X) and (Y)). Note that if the two IPv6 addresses are not identical then the MAP MUST simply discard the LBU message. Haddad, et al. Expires December 28, 2006 [Page 7] Internet-Draft HMIPv6sec June 2006 o When the MN gets a BA message, it searches first if it carries HKs. If the correct HKs is found, then the MN computes Ksm and establishes a bidirectional SA with the MAP. o By completing the DH procedure, both nodes will be able to compute the session mobility key (Ksm) (i.e., from values (X) and (Y)) and use it 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, et al. Expires December 28, 2006 [Page 8] Internet-Draft HMIPv6sec June 2006 5. New Messages and Options Format In the following, we describe the PBU message structure and the format of the four new options. 5.1. The Pre-Binding Update (PBU) Message Format When the AR receives a valid RtSol message signed with CGA, it sends a PBU message to the MAP, which carries the MN's LCoA, RCoA and Ks. The format of the PBU message is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + LCoA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + RCoA + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Ks . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Code 0 Checksum The ICMP checksum. For more details see [ICMPv6]. Haddad, et al. Expires December 28, 2006 [Page 9] Internet-Draft HMIPv6sec June 2006 Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. LCoA This field contains the MN's LCoA. RCoA This field contains the MN's RCoA. Ks The shared secret sent by the AR to the MN and to the MAP. 5.2. Third Party Shared Key (TPSK) Option The Third Party Shared Key Option is carried by the unicast RtAdv message sent by the AR to the MN, in response to a RtSol message carrying a valid signature. The TPSK option MUST carry the shared secret Ks. When used, the TPSK option has the following format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Option Data = Ks . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length Length of the option. Option Data This field contains the shared secret Ks. 5.3. The MAP Session Mobility Secret (MSMS) Option The MSS Option is used by the MAP to carry the DH public value (Y) sent in the BA message, in response to the first LBU message carrying an SMS option sent by the MN to the MAP. Haddad, et al. Expires December 28, 2006 [Page 10] Internet-Draft HMIPv6sec June 2006 Note that the first BA message sent by the MAP to the MN MUST be authenticated with Ks. The MSMS option has the following format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Option Data = (Y) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length Length of the option. Option Data The Option Data field contains the DH public value (Y) sent by the MAP to the MN in the BA message. 5.4. Third Party Hash Secret (TPHS) Option When sending a BA message carrying an MSS option, the MAP MUST insert the hash of Ks (HKs) in the BA message. For this purpose, the TPHS option is used to carry the HKs in the BA message. The TPHS option has the following format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Option Data = HKs . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Haddad, et al. Expires December 28, 2006 [Page 11] Internet-Draft HMIPv6sec June 2006 Option Length Length of the option. Option Data The Option Data field contains the hash of Ks. 5.5. The Session Mobility Secret (SMS) Option The SMS option is carried by the first LBU message sent by the MN to the MAP after receiving an unicast RtAdv message carrying a TPSK option. The SMS option contains the DH public value (X) sent by the MN to the MAP to initiate a DH exchange, which will allow both nodes to compute a shared secret (Ksm). Note that the first LBU message sent by the MN to the MAP MUST be authenticated with Ks. The SMS option has the following format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Option Data = (X) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length Length of the option. Option Data The Option Data field contains the DH public value (X) sent by the MN to the MAP in the first LBU message. Haddad, et al. Expires December 28, 2006 [Page 12] Internet-Draft HMIPv6sec June 2006 6. IANA Considerations This document introduces 4 new types of options and one new type of message. The values of these types are 8-bit unsigned integers. These values are allocated according to the Standards Actions or IESG approval policies defined in [IANA]. Haddad, et al. Expires December 28, 2006 [Page 13] Internet-Draft HMIPv6sec June 2006 7. Security Considerations This proposal suggests using the CGA technology to secure the exchange between the MN and the AR as described in the SEND protocol, to derive a first shared secret between the two entities and to use it later to authenticate mobility signaling messages exchanged between the MN and the MAP. 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 Ks. In addition, launching a denial of service (DoS) attack against the MAP or the MN is mitigated due to the fact that both nodes can quickly scan incoming messages for a partial authenticity before processing the entire message. Haddad, et al. Expires December 28, 2006 [Page 14] Internet-Draft HMIPv6sec June 2006 8. Change Log This document introduces the following changes from previous versions: - Remove the reliance on the crypto-based identifier (CBID) in order to further simplify the protocol. - Remove any new option from the RtSol message and adopt the same format as used in SEND. - Reduce the size of the PBU message by eliminating the need to send the MN's CGA public key. - Change the document title to reflect the new modifications. - Correct few typos. Haddad, et al. Expires December 28, 2006 [Page 15] Internet-Draft HMIPv6sec June 2006 9. References 9.1. Normative References [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [HMIPv6] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6)", Internet Draft, draft-soliman-mipshop-4140bis-00.txt, June 2006. [IANA] Narten, T. and H. Alverstrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, BCP 26, October 1998. [ICMPv6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol version 6 (IPv6) Specification", RFC 2463, July 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 [FMIPkey] Kempf, J. and R. Koodli, "Bootstrapping a Symmetric IPv6 Key Handover Key from SEND", Internet Draft, draft-kempf-mipshop-handover-key-00.txt, June 2006. [FMIPv6] Koodli, R., "Fast Handovers for Mobile IPv6", Internet Draft, draft-ietf-mipshop-fmipv6-rev-00.txt, April 2006. [FRD] Choi, J., Chin, D., and W. Haddad, "Fast Router Discovery with L2 Support", Internet Draft, draft-ietf-dna-frd-01.txt, June 2006. [OptiSEND] Haddad, W., Krishnan, S., and J. Choi, "Secure Neighbor Discovery (SEND) Optimization and Adaptation for Mobility: The OptiSEND Protocol", Internet Draft, draft-haddad-mipshop-optisend-01.txt, March 2006. Haddad, et al. Expires December 28, 2006 [Page 16] Internet-Draft HMIPv6sec June 2006 Authors' Addresses Wassim Haddad Ericsson Research Torshamnsgatan 23 SE-164 80 Stockholm Sweden Phone: +46 8 4044079 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 Hesham Soliman Qualcomm-Flarion Phone: +1 908 997 9775 Email: hsoliman@qualcomm.com Haddad, et al. Expires December 28, 2006 [Page 17] Internet-Draft HMIPv6sec June 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. Haddad, et al. Expires December 28, 2006 [Page 18]