Network Working Group Feng BAO INTERNET-DRAFT Robert DENG Expires: April 15, 2006 Ying QIU Network Working Group Jianying ZHOU October 16, 2005 A Scheme for the Security between Mobile Node and Mobility Anchor Point in Hierarchical Mobile IPv6 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 15, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Expires: April 15, 2006 [Page 1] Internet Draft MN-MAP Security October 16, 2005 Abstract The document proposes the solution for the security between mobile nodes and MAPs. According to the requirements of the security statement in the working group, two modes for two scenarios are considered in the draft: authentication-only mode and authentication and authorization mode. Table of Contents 1. INTRODUCTION ................................................. 2 2. NOTATIONS .................................................... 4 3. AUTHENTICATION-ONLY MODE ..................................... 4 4. AUTHENTICATION AND AUTHORIZATION MODE ........................ 6 5. SECURITY CONSIDERATIONS ...................................... 9 6. CONCLUSION ................................................... 9 7. ACKNOWLEDGEMENTS ............................................. 9 8. REFERENCES ................................................... 9 9. AUTHORS' ADDRESSES .......................................... 10 Intellectual Property and Copyright Statements .................. 10 1. INTRODUCTION In the protocol of HMIPv6 [1], the concept of Mobility Anchor Point (MAP) is introduced. MAP is a router located in a domain visited by the mobile nodes. MAP provides the localized mobility management for the visiting mobile nodes. Every mobile node bundles three addresses: Home Address (HoA), Regional Care-of-Address (RCoA), and On-Link Care-of-Address (LCoA). RCoA is an address on the MAP subnet, and obtained by the mobile Node (MN) from the visited domain. LCoA is configured on a MN's interface based on the prefix advertised by its default router. In fact, it is a care-of-address in normal MIPv6. Figure 1 shows the architecture of HMIPv6. Expires: April 15, 2006 [Page 2] Internet Draft MN-MAP Security October 16, 2005 +----+ +----+ | HA | | CN | +----+ +----+ | | +---+ +---+ | | +-------+ | MAP | RCoA +-------+ | | +---+ +---+ | | +-----+ +-----+ LCoA1 | AR1 | | AR2 | LCoA2 +-----+ +-----+ +----+ | MN | movement +----+ ---------> Figure 1. Hierarchical MIPv6 domain. In HMIPv6, when CN sends packets to MN's RCoA, MAP intercepts the packets and forwards the packets to MN's LCoA. However, as the binding update (BU) message from MN to MAP is not authenticated when MN changes its Access Router (AR), attackers can easily launch "Redirect Attacks", i.e., the attacks which redirect the traffic from MAP to fake destinations chosen by the attackers. On the other hand, in some scenarios, the MAP is only open to the authorized users. Two security models are described in the email discussion [2]: (1) Authentication-only model: In this model, a MAP only need to ensure that the same MN is sending the BUs to the MAP. It is not necessary for the MN to prove that it is authorized to use a MAP to manage its mobility. (2) Authentication and Authorization model: In this model, the MAP and the MN need to know that the other end is "trusted". The MAP also needs to know if the MN is authorized for using it. In this document, we propose a protocol to protect the BU messages from MN to MAP as well as the method of authenticating MN's identification without the global PKI. Expires: April 15, 2006 [Page 3] Internet Draft MN-MAP Security October 16, 2005 2. NOTATIONS The notations used throughout this paper are listed below for easy reference: h(): a one-way hash function, such as MD5 or SHA. prf(k, m): a keyed pseudo random function -- often a keyed hash function. It accepts a secret key k and a message m, and generates a pseudo random output. This function is used for both message authentication and cryptographic key derivations. e(k ,m): encryption of message m with a secret key k. Px/Sx: a public and private key pair of node X in a digital signature scheme such as RSA or DSS. Sig(Sx, m): node X's digital signature on a message m using a private key Sx. m|n: concatenation of two messages m and n. 3. AUTHENTICATION-ONLY MODE In many scenarios the managers of MAP would like to provide free connection for their customers, such as in conferences, hotels, coffee bars, etc. In these scenarios, the MAP only needs to ensure any binding update messages (BU) are from the claimed mobile nodes (MN). The MAP not needs to check if the MNs have the right to connect the MAP [2]. Figure 2 shows message exchange between a MN and a MAP in the Authentication-only mode. Below is a detailed description of the protocol. MN MAP | | |==COOKIE0====>| | | |<===COOKIE1===| long term | | messages |====BU_1=====>| | | |<=====BA_1====| | | ------------------------------------------ | | |=====BU_i====>| | | short term |<=====BA_i====| message for BU | | | | Figure 2. Message exchange in Authentication-only mode Expires: April 15, 2006 [Page 4] Internet Draft MN-MAP Security October 16, 2005 When a mobile node MN roams and enters to the domain of MAP, MN creates a cookie C0 and sends COOKIE0 = {Src=LCoA, Des= MAP, Opt=HoA, C0} to MAP. In reply, MAP generates a nonce N1 and a cookie C1, and sends to MN the message COOKIE1 = {Src=MAP, Des=LCoA, Opt=HoA, C0, C1, N1}. The use of cookies during the key exchange is a weak form of protection against an attacker who generates a series of request packets, each with a different spoofed source IP address, and sends them to a protocol party. For each request, the protocol party will first validate cookies before performing computational expensive public key cryptographic operations and memory allocation. Upon receiving COOKIE1, MN checks on the validity of C0, generates a nonce N2 and replies MAP with BU_1 = {Src=LCoA, Des=MAP, Opt=HoA, C0, C1, N1, N2, TS, SIG_MN, Cert_MN}, where SIG_MN is MN¡¯s signature signed by its private key SK_MN SIG_MN = Sig(SK_MN, LCoA|HoA|MAP|N1|N2|TS). Note that the values of N1 and N2 are included in the signature SIG_MN in order to counter replay of old signatures and to resist chosen message attacks to the signature scheme, respectively. TS is a time stamp. This time stamp does not have to be checked by the recipient during the message exchange. It will be used to trace back the culprit should a malicious mobile node flooding attack have occurred. The Cert_MN is the public key certificate of the mobile node that is issued by the MN¡¯s home agent and is not necessary to be verified in this scenario. When MAP receives BU_1, it validates the cookies, extract MN¡¯s public key from the certificate Cert_MN, and verify the signature. If all the validations and checking are positive, MAP assigns the RCoA to the MN and creates an entry for the MN, which includes HoA, RCoA, LCoA, TS, certificate, etc. Then MAP adds the entry to its BU cache. Finally, MAP sends to MN the binding acknowledgement BA_1 = {Src=MAP, Des=LCoA, Opt=HoA, RCoA, C0, C1, N1, N2}, Since the binding acknowledgement is not important to MN in the scenarios, the BA message is not necessary to do any secure process. The process for the following binding updates in the same domain is simple. When MN moves to a new AR and gets a new LCoA, MN just needs to send MAP the binding update message Expires: April 15, 2006 [Page 5] Internet Draft MN-MAP Security October 16, 2005 BU_i = {Src=LCoA, Des=MAP, Opt=HoA, old_LCoA, TS, SIG_MN_i} where SIG_MN_i = Sig(SK_MN, LCoA|MAP|HoA|old_LCoA|TS). The reason of binding the old LCoA is to avoid the reply attack. After receiving the BU_i, MAP retrieves the entry based on HoA from its binding cache and gets the Cert_MN. If the verification of the signature is positive, MAP accepts the new LCoA and updates its binding cache. Meanwhile MAP replies MN BA_i = {Src=MAP, Des=LCoA, Opt=HoA} 4. AUTHENTICATION AND AUTHORIZATION MODE In some scenarios, the MAP and MN need to know the other end is ¡°trusted¡± and the MAP also need to know if the MN is authorized for using it [2]. Figure 3 shows message exchange among a MN, a MAP and MN¡¯s HA in the Authentication-Authorization mode. Below is a detailed description of the protocol. MN MAP HA | | | |===COOKIE0===>| | | | | |<===COOKIE1===| | long term | | | messages |====BU_1=====>| | | |==REQ_Cert===>| | | | | | |<===REP_Cert==| |<====BA_1=====| | | | | ------------------------------------------------------ | | | |====BU_i=====>| | | | | short term |<=====BA_i====| | message for BU | | | | | | Figure 3. Message exchange in Authentication and Authorization mode When a mobile node MN roams and enters to the domain of MAP, MN creates a cookie C0 and sends Expires: April 15, 2006 [Page 6] Internet Draft MN-MAP Security October 16, 2005 COOKIE0 = {Src=LCoA, Des= MAP, Opt=HoA, C0} to MAP. In reply, MAP generates a nonce N1 and a cookie C1, and sends COOKIE1 = {Src=MAP, Des=LCoA, Opt=HoA, C0, C1, N1} to MN. The use of cookies during the key exchange is a weak form of protection against an attacker who generates a series of request packets, each with a different spoofed source IP address, and sends them to a protocol party. For each request, the protocol party will first validate cookies before performing computational expensive public key cryptographic operations and memory allocation. These two messages are similar to the authentication-only mode. Upon receiving COOKIE1, MN checks on the validity of C0, generates a nonce N2 and a Diffie-Hellman secret value x < p, computes its Diffie-Hellman public value g^x and its signature SIG_MN = Sig(SK_MN, LCoA|HoA|MAP|g^x|N1|N2|TS) using MN¡¯s private key SK_MN, where TS is a time stamp. This time stamp does not have to be checked by the recipient during the message exchange. It will be used to trace back the culprit should a malicious mobile node flooding attack have occurred. Note that the values of N1 and N2 are included in the signature SIG_MN in order to counter replay of old signatures and to resist chosen message attacks to the signature scheme, respectively. Finally, MN replies MAP with the first binding update message BU_1 = {Src=LCoA, Des=MAP, Opt=HoA, C0, C1, N1, N2, g^x, TS, SIG_MN, Cert_MN}, where Cert_MN = {HoA, PK_MN, Valid_Iinterval, SIG_HA}. is the public key certificate of the mobile node which is issued by its home agent. SK_MN and PK_MN are the private and public key pair for MN. When MAP receives BU_1, if the validation of the cookies is positive, MAP then begins to verify the MN's public key certificate Cert_MN by public key of MN¡¯s home agent. If MAP does not have the HA¡¯s certificate in its cache, MAP will send a requesting message for certificate to HA, REQ_Cert = {Src=MAP, Des=HA, request_cert}. Expires: April 15, 2006 [Page 7] Internet Draft MN-MAP Security October 16, 2005 Then, HA will return to MAP its public key certificate issued by a trusted CA, REP_Cert = {Src=HA, Des=MAP, Cert_HA}. Upon getting HA's public key certificate and verifying the certificate through the trusted CA, MAP can verify HA's signature SIG_HA and then trust the MN's public key certificate Cert_MN. With the Cert_MN, MAP can further verify MN's signature. After double checking the equality of home link's subnet prefix string embedded in both Cert_HA and HoA, MAP can finally trust the first MN's new binding update message BU_1 and create an entry for the MN and add the entry to MAP¡¯s binding cache. MAP next generates its Diffie-Hellman secret value y < p. It then computes its Diffie-Hellman public value g^y, the Diffie-Hellman master key k_DH = (g^x)^y, and a session secret k_secret = prf(k_DH, N1|N2 ) for future security purpose. Then MAP assigns a RCoA to MN and sends to MN the binding acknowledgement BA_1 = {Src=MAP, Des=LCoA, Opt=HoA, RCoA, C0, C1, g^y, SIG_MAP, Cert_MAP}, where SIG_MAP = Sig(SK_MAP, MAP|LCoA|HoA|RCoA|g^y|BU_1) and Cert_MAP = {MAP, PK_MAP, Valid_Interval, SIG_CA} is MAP's certificate from a trusted CA, SK_MAP and PK_MAP is the security key pair of MAP. Therefore, both parties MN and MAP could identify each other. After getting this message, MN first validates the cookies, calculates the Diffie-Hellman master key k_DH = (g^y)^x and the session secret k_master = prf(k_DH, N1|N2) for future security purpose. Then MN also creates an entry for this channel and stores the entry into its binding cache. The process for following binding update in the same domain is simple. When MN moves to a new AR and gets a new LCoA, MN just needs to send MAP the binding update message Expires: April 15, 2006 [Page 8] Internet Draft MN-MAP Security October 16, 2005 BU_i = {Src=LCoA, Des=MAP, Opt=HoA, old_LCoA, TS, SIG_MN_i} where SIG_MN_i = Sig(SK_MN, LCoA|MAP|HoA|old_LCoA|TS). The reason of binding the old LCoA is to avoid the reply attack. After receiving the BU_i, MAP retrieves the entry based on HoA from its binding cache and gets the Cert_MN. If the verification of the signature is positive, MAP accepts the new LCoA and updates its binding cache. Meanwhile MAP replies MN BA_i = {Src=MAP, Des=LCoA, Opt=HoA, SIG_MAP_i} where SIG_MAP_i = Sig(SK_MAP, MAP|LCoA|HoA|BU_i). 5. SECURITY CONSIDERATIONS The proposal consider the security binding update between mobile nodes and the mobility anchor points. 6. CONCLUSION The document proposes the solution for the security between mobile nodes and MAPs as well as the method of authenticating MN¡¯s identification without the global PKI. In the proposal, two security modes are considered for different scenarios. 7. ACKNOWLEDGEMENTS 8. REFERENCES [1] H. Soliman, C. Castelluccia, K. El Malki, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, Aug. 2005. [2] Discussions in MIPSHOP working group, July 2005. [3] D. B. Johson and C. Perkins, "Mobility Support in IPv6", RFC 3775, June 2004. [4] F. Bao, R.Deng, Y. Qiu, J.y Zhou, "Certificate-based Binding Update Protocol (CBU)", draft-qiu-mip6-certificated-binding- update-03.txt, March 2005 Expires: April 15, 2006 [Page 9] Internet Draft MN-MAP Security October 16, 2005 9. AUTHORS' ADDRESSES Feng BAO Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-8456 EMail: baofeng@i2r.a-star.edu.sg Robert DENG Singapore Management University 469 Bukit Timah Road Singapore 259756 Phone: +65-6822-0920 EMail: robertdeng@smu.edu.sg Ying QIU Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-6742 EMail: qiuying@i2r.a-star.edu.sg Jianying ZHOU Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65-6874-6668 EMail: jyzhou@i2r.a-star.edu.sg 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. Expires: April 15, 2006 [Page 10] Internet Draft MN-MAP Security October 16, 2005 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. Expires: April 15, 2006 [Page 11]