MIPSHOP Working Group W. Haddad Internet-Draft S. Krishnan Expires: December 28, 2006 Ericsson Research June 26, 2006 Authenticating FMIPv6 Handovers draft-haddad-mipshop-fmipv6-auth-01 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 document specifies a scheme to secure the handover signaling in FMIPv6 using one way hash chains. The values generated in a one way hash chain will be used one at a time during each handoff to secure the signaling messages. Haddad & Krishnan Expires December 28, 2006 [Page 1] Internet-Draft FMIPv6 Authentication June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6 5. New Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Hash Handoff Option (HHO) . . . . . . . . . . . . . . . . 9 5.2. Token Achnowledgment Option (TAO) . . . . . . . . . . . . 9 5.3. Handoff Vector Option (HVO) . . . . . . . . . . . . . . . 10 5.4. Handoff Option (HO) . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Haddad & Krishnan Expires December 28, 2006 [Page 2] Internet-Draft FMIPv6 Authentication June 2006 1. Introduction FMIPv6 protocol (described in [RFC4068]) specifies a fast handoff procedure for IPv6 mobile nodes, which is based on tunneling data packets between the mobile node's previous and new access routers (ARs). The FMIPv6 protocol specification does not provide a method to establish a handoff key to secure the FMIPv6 signaling messages between the MN and the AR. Current proposed schemes require generation of a handoff key at each handover in order to secure the handoff signaling. This draft suggests a mechanism based on the one-way hash chains to authenticate the handoff signaling messages without the burden of generating one "handoff key" per handoff procedure. Values generated in a OWHC will be used one at a time during each handoff to secure the signaling messages. Haddad & Krishnan Expires December 28, 2006 [Page 3] Internet-Draft FMIPv6 Authentication 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 [RFC2119]. Haddad & Krishnan Expires December 28, 2006 [Page 4] Internet-Draft FMIPv6 Authentication June 2006 3. Glossary +---------------------+---------------------------------------------+ | Term | Definition | +---------------------+---------------------------------------------+ | One Way Hash Chain | A one way chain (Vo...Vn) is a collection | | (OWHC) | of values such that each value Vi (except | | | the last value Vn) is a one-way function of | | | the next value Vi+1. In particular, we | | | have Vi = H(Vi+1), for i belonging to | | | [0,n[. For clarity purpose and to avoid | | | confusion, we'll use in the rest of this | | | document the notation V[i] instead of Vi, | | | which means V[i+1] points to Vi+1... | | | | | Fast Binding Update | A message from the MN instructing its PAR | | (FBU) | to redirect its traffic towards the NAR. | | | | | Previous Access | The MN's default router prior to its | | Router (pAR) | handover. | | | | | New Access Router | The MN's default router subsequent to its | | (nAR) | handover. | | | | | Fast Binding | A message from the PAR in response to an | | Acknowledgment | FBU. | | (FBA) | | +---------------------+---------------------------------------------+ Table 1: Glossary Haddad & Krishnan Expires December 28, 2006 [Page 5] Internet-Draft FMIPv6 Authentication June 2006 4. Protocol Operation In order to avoid generating a handoff key each time the MN switches to a new AR, the MN should be able to use a OWHC in order to authenticate the FBU message sent to its pAR. On the other side, the network access infrastructure should also provide the MN enough assurance that the FBA message is coming from the same AR, which received the FBU message. Furthermore, it is important to mention that a fast growing class of mobile devices tend to have very limited battery and processing power. Thus the available energy must be meticulously controlled and consumed, i.e., not to be wasted on exchanging unnecessary redundant signaling messages nor on computing unnecessary RSA signatures. In fact, it has been shown that the wireless transmission of one bit can require over 1000 times more energy than a single 32-bit computation [EALDC]. Consequently, care should be taken to rely whenever possible on low processing power operations and to minimize the amount of signaling messages sent from the MN. Finally, it should be noted that using OWHC to authenticate the FBU messages should not increase nor create new vulnerabilities, which can be exploited by malicious nodes to violate the MN's privacy. For this purpose, the suggested proposal prevents a malicious node located on the direct path between the MN and the CN from correlating different CoAs sent in different binding updates (BU) messages with the same identity, especially that OWHC values can easily be correlated. The suggested protocol allows an FMIPv6 enabled MN to generate a OWHC (e.g., 20 values) prior to triggering the first fast handoff procedure (i.e., sending an FBU message following the receipt of a PrRtAdv message from its AR). The length of each value of the OWHC SHOULD be equal to 64 bits and SHOULD be used together with another parameter to generate the interface identifier (IID) to configure the nCoA. In order to minimize using expensive processing power operations, the MN SHOULD use the SEND procedure only at the beginning, i.e., when preparing its first fast handoff to another AR. In this case, the MN sends a RtSol message signed with CGA to its current AR, prior to triggering a fast handoff procedure. The RtSol message SHOULD carry the tip of the MN's OWHC in a new option called the hash handoff option (HHO). Upon receiving a RtSol message carrying an HHO, the AR SHOULD reply by sending confidentially a 64-bit unique parameter called Handoff Vector (HV). For this purpose, the AR encrypts the HV with the MN's Haddad & Krishnan Expires December 28, 2006 [Page 6] Internet-Draft FMIPv6 Authentication June 2006 CGA public key and inserts it in a unicast RtAdv message then sends it to the MN. The AR SHOULD also store the sender's current IPv6 address, the associated OWHC value and the corresponding HV in its mobile cache entries (MCE) for a limited lifetime. Note that an additional optimization would mainly target the use of CGA technology and would consist on using the Optimized SEND protocol (described in [OptiSEND]). In order to respect the MN's privacy as mentioned earlier, the HV will be used to hide any correlation between the MN's nCoA and the previous one (pCoA). This is achieved by using a simple computation involving the HV and the MN's CoAs. The HV should also be sent by the MN's current AR to the new one in a new option carried by the Handoff Initiate (HI) message and MUST remain unchanged as long as the MN is using the same OWHC. Note that we assume that all links between ARs are secure and the network access infrastructure can be trusted. Following the above, when the MN needs to autoconfigure a new CoA, it has to compute the correspondent IID in the following way: nCoA (IID) = OWHC(NV) XOR HV Where OWHC(NV) is the next 64-bit undisclosed value from the MN's OWHC. Procedures to exchange FBU/FBA messages between the MN and ARs are described in the following: Upon receiving an FBU message, the AR (i.e., the pAR which has generated the HV) checks its MCE for an entry containing the MN's pCoA. If an entry is found, then the pAR decodes the nCoA IID by using the corresponding HV, then hashes the resulting value and compares it to the 64-bit OWHC disclosed value stored in the MN's corresponding entry (i.e., the "tip" of the OWHC in case it is the first fast handoff). If the two values are equal, then the pAR SHOULD send an FBA message. The FBA message MUST carry a Token Acknowledgment (TAck) value, which allows the MN to check if the FBA message has been sent by the same entity, which has received the MN's corresponding HV and the FBU message. The TAck value SHOULD be equal to the first 64 bits generated from hashing the MN's nCoA sent in the FBU message, after decoding it (i.e., using the corresponding HV). The procedure to generate the TAck is the following: TAck = First[ 64, SHA1[ nCoA(prefix) | (nCoA(IID) XOR HV) ] ] When the nAR gets an HI message carrying an HV, it SHOULD store it Haddad & Krishnan Expires December 28, 2006 [Page 7] Internet-Draft FMIPv6 Authentication June 2006 together with the MN's nCoA in its cache memory for future use. In fact, after using SEND protocol with the first AR, any subsequent AR visited by the MN MUST NOT accept an FBU message sent by the MN if the claimed nCoA (IID) is not valid. In order to check the validity of the nCoA, the nAR MUST first decode the two MN's IPv6 addresses, i.e., it has to compute the following: - pCoA (IID) XOR HV (1) - nCoA (IID) XOR HV (2) After decoding the two addresses, the nAR hashes the value obtained in (2) and compares the result to (1). If the two values are equal then the FBU is accepted and an FBA message is sent. Otherwise, the nAR MUST discard the FBU message. Haddad & Krishnan Expires December 28, 2006 [Page 8] Internet-Draft FMIPv6 Authentication June 2006 5. New Options This proposal defines 4 new options described in the following: 5.1. Hash Handoff Option (HHO) This option is used to carry a 64 bit value, which is the tip of the MN's OWHC. The HHO is carried by the RtSol message sent by the MN to its current AR. The format of the option is the following: 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 | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vi | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length 8. Option Data This contains the value at the tip of the hash chain. 5.2. Token Achnowledgment Option (TAO) This option is used to carry the 128-bit value, which is generated from hashing the MN's nCoA after decoding its IID with the MN's corresponding HV then appending to it the 64-bit nCoA prefix. The TAO is carried by the FBA message sent by the MN's pAR upon receiving a valid FBU message. The format of the option is the following: 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 | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TA | Haddad & Krishnan Expires December 28, 2006 [Page 9] Internet-Draft FMIPv6 Authentication June 2006 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length 8 Option Data Contains the 64-bit TA, which is used by the MN as a proof that the FBA message has been sent by a node, which possesses its HV and has also received its valid FBU message. 5.3. Handoff Vector Option (HVO) This option is carried by the RtAdv message sent by the AR after receiving a RtSol message carrying an HHO. The HVO is used to carry the 64-bit handoff vector. The format of the option is the following: 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 | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length 8. Option Data Contains the 64-bit HV, which is the used by the MN to prevent correlation between its different CoAs generated from the same OWHC, and by the AR to decode the MN's CoA(s) prior to hashing it and checking the validity of the FBU message. 5.4. Handoff Option (HO) This option is carried by the HI message sent by the pAR to the nAR upon receiving a valid FBU message. The option carries the 64-bit HV Haddad & Krishnan Expires December 28, 2006 [Page 10] Internet-Draft FMIPv6 Authentication June 2006 in order to allow the nAR to check the validity of the FBU message sent by the MN to its nAR. The format of the option is the following: 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 | 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HV | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length 8. Option Data Contains the 64-bit HV. Haddad & Krishnan Expires December 28, 2006 [Page 11] Internet-Draft FMIPv6 Authentication June 2006 6. Security Considerations This document specifies a simple scheme to secure the handover signaling using one way hash chains. The values generated in a one way hash chain will be used one at a time during each handover to secure the fast mobility signaling. The suggested proposal relies also on the assumption that a trust relationship between the MN and the network access infrastructure exists in order to guarantee that the HV parameter won't be forwarded to a malicious node at a particular time. The suggested proposal fulfills the requirements dictated by low processing and battery power mobile devices regarding the number of signaling messages sent by the mobile node and the use of RSA signatures, without creating nor amplifying new and/or existing threats. 7. References [EALDC] Barr, K. and K. Asanovic, "Energy Aware Lossless Data Compression", ACM Proceedings of MobiSys, May 2003. [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, June 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", Internet Draft, draft-ietf-mipshop-fmipv6-rev-00.txt, April 2006. Haddad & Krishnan Expires December 28, 2006 [Page 12] Internet-Draft FMIPv6 Authentication 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 3457900 Email: Suresh.Krishnan@ericsson.com Haddad & Krishnan Expires December 28, 2006 [Page 13] Internet-Draft FMIPv6 Authentication 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 & Krishnan Expires December 28, 2006 [Page 14]