MIPSHOP Working Group W. Haddad Internet-Draft S. Krishnan Expires: October 12, 2006 Ericsson Research April 10, 2006 Authenticating FMIPv6 Handovers draft-haddad-mipshop-fmipv6-auth-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 October 12, 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 handover to secure the signaling. Haddad & Krishnan Expires October 12, 2006 [Page 1] Internet-Draft FMIPv6 Authentication April 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6 5. New Options . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Hash Handoff Option (HHO) . . . . . . . . . . . . . . . . 8 5.2. Hash Token Acknowledgement Option (HTAO) . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Haddad & Krishnan Expires October 12, 2006 [Page 2] Internet-Draft FMIPv6 Authentication April 2006 1. Introduction FMIPv6 [RFC4068] specifies a fast handoff procedure for IPv6 mobile nodes. It utilizes tunneling of packets from an old AR to the MN to achieve thus. The FMIPv6 protocol specification does not provide a method to establish a handoff key to secure the signaling between the MN and the AR. The current schemes proposed to come up with the handover require generation of a handoff key at each handover in order to secure the signaling. The scheme proposed in this draft aims to secure the handover signaling without generating one handover key per handover. 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 oder to authenticate the FBU message sent to its pAR. In addition, the MN should also be able to have enough assurance that the FBA message is coming from the same AR, which received the FBU message. Haddad & Krishnan Expires October 12, 2006 [Page 3] Internet-Draft FMIPv6 Authentication April 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 October 12, 2006 [Page 4] Internet-Draft FMIPv6 Authentication April 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 October 12, 2006 [Page 5] Internet-Draft FMIPv6 Authentication April 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 oder to authenticate the FBU message sent to its pAR. In addition, the MN should also be able to have enough assurance that the FBA message is coming from the same AR, which received the FBU message. For this purpose, the MN SHOULD 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 as interface identifier to configure the nCoA. An FMIPv6 enabled MN SHOULD use the SEND procedure only at the beginning, 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 store the sender's current IPv6 address and the OWHC value for a limited lifetime. The AR MUST also send a unicast RtAdv message, which SHOULD carry a 64-bit value called Acknowledgment Hash-Token (HTAck) computed in the following way: HTAck = First (64, SHA1(nCoA | nonce )) Note that the nonce SHOULD be a 128-bit value. Upon receiving an FBU message, the AR (i.e., pAR) checks its mobile cache entries (MCE). If an entry for the MN's pCoA is found, then the AR hashes the nCoA IID carried in the FBU and compares the resulting hash to the 64-bit OWHC disclosed value stored in the MN's corresponding entry. If the two values are equal, then the pAR sends back an FBA message. The FBA message MUST carry the Token Acknowledgment (TAck), which allows the MN to check its validity (i.e., HTAck = SHA1(TAck)). As mentioned in [FMIPv6], the MN MAY receive the FBA directly from the pAR or through the nAR. In the first case, the pAR MUST send an HI message to nAR, while in the second case, the FBA is tunneled through the nAR. In both cases, the nAR MUST send a unicast RtAdv message as described in the SEND protocol upon receiving an FNA message from the MN, which contains the HTAck value. After using SEND mechanism with the first AR, any subsequent AR Haddad & Krishnan Expires October 12, 2006 [Page 6] Internet-Draft FMIPv6 Authentication April 2006 visited by the MN (including the first one) MUST NOT accept any FBU message sent by the MN if the claimed nCoA is not a valid value from the MN's OWHC, i.e., SHA1(nCoA(IID)) = pCoA (IID). Haddad & Krishnan Expires October 12, 2006 [Page 7] Internet-Draft FMIPv6 Authentication April 2006 5. New Options OMM defines new bit and options to be carried by the RtSol message. The new bit and options are the following: 5.1. Hash Handoff Option (HHO) This option is used to carry a 64 bit value which is at the tip of the MN's one way hash chain. 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. Hash Token Acknowledgement Option (HTAO) This option is used to carry a 64 bit value which is the first 64 bits of the SHA1 hash of the MNs new Care of Address concatenated with a 128 bit nonce. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HTAck | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Haddad & Krishnan Expires October 12, 2006 [Page 8] Internet-Draft FMIPv6 Authentication April 2006 Option Type Option Length 8. Option Data 64 bit value which is the first 64 bits of the SHA1 hash of the MNs new Care of Address concatenated with a 128 bit nonce Haddad & Krishnan Expires October 12, 2006 [Page 9] Internet-Draft FMIPv6 Authentication April 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 signaling. 7. References [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", RFC 4068, July 2005. Haddad & Krishnan Expires October 12, 2006 [Page 10] Internet-Draft FMIPv6 Authentication April 2006 Authors' Addresses Wassim Haddad Ericsson Research 8400 Decarie Blvd. Town of Mount Royal, QC Canada Email: Wassim.Haddad@ericsson.com Suresh Krishnan Ericsson Research 8400 Decarie Blvd. Town of Mount Royal, QC Canada Email: Suresh.Krishnan@ericsson.com Haddad & Krishnan Expires October 12, 2006 [Page 11] Internet-Draft FMIPv6 Authentication April 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 October 12, 2006 [Page 12]