MIPSHOP Working Group W. Haddad Internet-Draft S. Krishnan Expires: March 25, 2007 Ericsson Research September 21, 2006 Authenticating FMIPv6 Handovers draft-haddad-mipshop-fmipv6-auth-02 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 March 25, 2007. 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 authenticate the signaling messages. Haddad & Krishnan Expires March 25, 2007 [Page 1] Internet-Draft FMIPv6 Authentication September 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. Hash Extension Option (HEO) . . . . . . . . . . . . . . . 9 5.3. Handoff Vector Option (HVO) . . . . . . . . . . . . . . . 10 5.4. Handoff Option (HO) . . . . . . . . . . . . . . . . . . . 11 5.5. Hash Chain Option (HCO) . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Haddad & Krishnan Expires March 25, 2007 [Page 2] Internet-Draft FMIPv6 Authentication September 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 chain technique to authenticate the handoff signaling messages without the burden of generating one "handoff key" by using public keys, per handoff procedure. Values generated in a OWHC will be used one at a time during each handoff to authenticate the signaling messages. Haddad & Krishnan Expires March 25, 2007 [Page 3] Internet-Draft FMIPv6 Authentication September 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 March 25, 2007 [Page 4] Internet-Draft FMIPv6 Authentication September 2006 3. Glossary One Way Hash Chain (OWHC) A one way chain (Vo...Vn) is a collection 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 (FBU) A message from the MN instructing its PAR to redirect its traffic towards the nAR. Previous Access Router (pAR) The MN's default router prior to its handover. New Access Router (nAR) The MN's default router subsequent to its handover. Fast Binding Acknowledgment (FBA) A message from the pAR in response to an FBU. Haddad & Krishnan Expires March 25, 2007 [Page 5] Internet-Draft FMIPv6 Authentication September 2006 4. Protocol Operation In order to avoid using heavy cryptographic operations and redundant signaling messages to generate a handoff key each time the MN switches to a new AR, the MN should be able to use simpler mechanisms such as OWHC technique 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. 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. 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 128 bits and SHOULD be used together with another parameter to generate each nCoA interface identifier (IID). In order to minimize using expensive processing power operations, the MN SHOULD use the SEND procedure only at the beginning, i.e., when switching for the first time 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 MUST encrypt the HV with the MN's CGA public key and inserts it in a unicast RtAdv message before sending 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, the HV will be used to hide any correlation between the MN's nCoA and the previous CoA (pCoA). This Haddad & Krishnan Expires March 25, 2007 [Page 6] Internet-Draft FMIPv6 Authentication September 2006 is achieved by using a simple computation involving the HV and the MN's CoAs. In addition, upon receiving a valid FBU message from the MN, the AR SHOULD hash the current HV value then forward the first 64-bit value of the resulting hash, i.e., new HV, to the MN's nAR. The new HV (nHV) is inserted in a new option carried by the Handoff Initiate (HI) message. Note that we assume that all links between ARs are secure and the network access infrastructure can be trusted. When the MN performs a fast handoff procedure (other than the first one), it starts by autoconfiguring a new CoA. For this purpose, it has to compute the nCoA IID. This is done in the following way: nCoA (IID) = First [64, OWHC(NV)) XOR First(64, nHV)] The rule to generate the nHV is the following: nHV = First[64, SHA1((n-1)HV)] Where: - OWHC(NV) is the next 128-bit undisclosed value from the MN's OWHC. - First(x,y) is a function which extracts the first "x" bits from "y". - nHV is the new HV value received by the MN's nAR and (n-1) is the previous value used by the MN's pAR to check the validity of the FBU message. After generating the nCoA's IID, the MN generates another 64-bit value from XORing the remaining 64-bit of the OWHC(NV) with nHV. The resulting value is called "Hash Extension" (HE) value and is sent in a new option carried by the FBU message. The last step is to authenticate the FBU message with the 128-bit OWHC(NV) and insert the result in the BAD. 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 the MN's pCoA is found, then the pAR decodes the nCoA IID by using its nHV then it decodes the HE value and concatenates the result with the nCoA's IID. The next step consists on hashing the concatenation of the two decoded values and comparing the first 128 bits of the resulting hash to the 128-bit OWHC disclosed value stored in the MN's corresponding entry. If the two values are equal, then the pAR proceeds to check the authenticity of the BU message and sends an FBA message to the MN. Haddad & Krishnan Expires March 25, 2007 [Page 7] Internet-Draft FMIPv6 Authentication September 2006 The FBA message MUST be authenticated with the same key, i.e., OWHC(NV), in order for 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. Note that the 128-bit OWHC value SHOULD be forwarded by the pAR to the nAR in the HI message. For this purpose, a new option called "Hash Chain" Option (HCO) is defined to carry the OWHC value in the HI message. When the nAR gets an HI message carrying an HV, it SHOULD store it together with the MN's nCoA in its cache memory for future use. As mentioned earlier, after using SEND protocol with the first AR, any subsequent AR visited by the MN MUST NOT use the same HV value used by the previous one. The same requirement applies also to the MN, which has to hash again its current HV value before using it to compute the nCoA IID. Haddad & Krishnan Expires March 25, 2007 [Page 8] Internet-Draft FMIPv6 Authentication September 2006 5. New Options This proposal defines 5 new options described in the following: 5.1. Hash Handoff Option (HHO) This option is used to carry a 128-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 | 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Vi | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length 16 Option Data This contains the value at the tip of the hash chain. 5.2. Hash Extension Option (HEO) This option is used to carry the 64-bit value, which is generated from XORing the leftmost 64 bits extracted from the 128-bit OWHC(NV) with the first 64 bits resulting from hashing HV (or re-hashing). The HEO is carried by the FBU message sent by the MN to the pAR. The format of the option is the following: Haddad & Krishnan Expires March 25, 2007 [Page 9] Internet-Draft FMIPv6 Authentication September 2006 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HE | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length 8 Option Data Contains the 64-bit HE, which is used by the MN to provide the pAR the ability to discover the entire OWHC(NV), i.e., the new shared secret, in order to check the authenticity of the FBU message and to authenticate the FBA 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, Haddad & Krishnan Expires March 25, 2007 [Page 10] Internet-Draft FMIPv6 Authentication September 2006 and by the AR to decode the MN's CoA(s) and the HE value prior to hashing the combination and checking the validity of the FBU message. Note that the HV value is hashed by the MN at each handoff and by each nAR before storing it in the corresponding MCE. 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 HO carries the 64-bit HV 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. 5.5. Hash Chain Option (HCO) This option is carried by the HI message sent by the pAR to the nAR upon receiving a valid FBU message. The HCO carries the 128-bit OWHC value computed by the MN's pAR from data received in the FBU message sent by the MN. The format of the option is the following: Haddad & Krishnan Expires March 25, 2007 [Page 11] Internet-Draft FMIPv6 Authentication September 2006 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 | 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HC | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length 16 Option Data Contains the last disclosed 128-bit value from the MN's OWHC. Haddad & Krishnan Expires March 25, 2007 [Page 12] Internet-Draft FMIPv6 Authentication September 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 [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 March 25, 2007 [Page 13] Internet-Draft FMIPv6 Authentication September 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 March 25, 2007 [Page 14] Internet-Draft FMIPv6 Authentication September 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 March 25, 2007 [Page 15]