Network Working Group F. Dupont Internet-Draft CELAR Expires: August 21, 2006 W. Haddad Ericsson Research February 17, 2006 Optimizing Mobile IPv6 (OMIPv6) draft-dupont-mipshop-omipv6-00.txt 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 August 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes an optimization to the Mobile IPv6 (MIPv6) protocol, which uses the crypto-based identifier (CBID) technology to securely establish a long lifetime bidirectional security association (SA) between the mobile node (MN) and the correspondent node (CN) and to reduce the IP handoff latency as well as the amount of signaling messages. Dupont & Haddad Expires August 21, 2006 [Page 1] Internet-Draft OMIPv6 February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. Quick Overview of Crypto-based Identifiers (CBID) . . . . . . 4 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5 6. New Messages and Option Formats . . . . . . . . . . . . . . . 7 6.1. The Pre-Binding Update Message . . . . . . . . . . . . . . 7 6.2. The Pre-Binding Acknowledgment (PBA) Message . . . . . . . 8 6.3. The Pre-Binding Test (PBT) Message . . . . . . . . . . . . 10 6.4. The Imprint Option . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Dupont & Haddad Expires August 21, 2006 [Page 2] Internet-Draft OMIPv6 February 2006 1. Introduction Mobile IPv6 protocol as described in [MIPv6] introduces a new mode called route optimization (RO), which enables direct communication between the MN and the CN. However, the RO mode requires a considerable amount of redundant signaling messages, which in turn create a significant latency problem and raises many security concerns. These problems are seriously undermining the possibility of any wide deployment of the RO mode in its current design. This document describes an optimization to the Mobile IPv6 (MIPv6) protocol, which uses the crypto-based identifier [CBID] technology to securely establish a long lifetime bidirectional SA between the MN and the CN and to reduce the IP handoff latency as well as the amount of signaling messages. 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]. 3. Problem Statement MIPv6 RO mode security is based on the return routability (RR) procedure. The RR allows the CN to check the reachability of the MN's home address (HoA) and its new care-of address (CoA), and to enable both endpoints to share a secret, (Kbm), in order to authenticate the binding update and acknowledgment (BU/BA) messages exchanged between them. The RR consists on exchanging four signaling messages, i.e., the HoTI/HoT and CoTI/CoT, between the MN and the CN, prior to sending a BU message to the CN. However, the CoTI/CoT messages are exchanged in clear on the direct path between the MN and the CN, and the HoTI/ HoT messages are exchanged in clear between the MN's home agent (HA) and the CN. Consequently, such exchange raises many security concerns as it is open to many attacks. In addition, it is required according to [MIPv6-Sec] to repeat the RR procedure during each IP handoff and/or during a maximum of 420 seconds, even if the MN does not move. Such requirement boost significantly the amount of signaling messages as well as the handoff latency and makes the HA a single point of failure. Dupont & Haddad Expires August 21, 2006 [Page 3] Internet-Draft OMIPv6 February 2006 In order to address the RR issues, a new proposal based on using the cryptographically generated address [CGA] is under design. The new proposal, i.e., [OMIPv6-CGA], allows the MN to provide the CN with a proof of ownership of its HoA's Interface Identifier (IID) and enables both endpoints to share a long lifetime shared secret. However, the suggested proposal does not allow the MN to provide any proof of ownership of its CoA's IID and is open to session hijacking and DoS attacks at some critical stage. It should be noted that these attacks don't require the malicious node to be located simultaneously on the HA-CN path and on the direct path between the two endpoints. In fact, launching these attacks require the malicious node to be located only on the path between the MN's HA and the CN (i.e., HA-CN). OMIPv6-CGA requires the MN to perform one RR procedure (as defined in MIPv6) prior to establishing a long lifetime bidirectional security association (SA). For this purpose, when the MN moves for the first time to a foreign network or decide to switch to the RO mode from a foreign network, it MUST send a HoTI and CoTI messages to the CN. However, the fact that the (HoTI, HoT) pair of messages goes in clear between the HA-CN makes them visible to a malicious node located on the same path. Consequently, the malicious node can easily discover the home keygen token sent by the CN to the MN in the HoT message. In order to launch a successful attack against a MN using the OMIPv6- CGA procedure, the malicious node has to send the first BU message to the CN on behalf of the MN, i.e., before the MN sends its own BU message. For this purpose, the malicious node has to always keep at hand a fresh care-of keygen token. This can be easily done by using, for example its own IPv6 address to exchange at anytime a CoTI/CoT messages with the CN, in order to get a new care-of keygen token. Sending a first and valid BU message to the CN, on behalf of the MN, allows the malicious node to hijack the MN's ongoing session and prevents it from establishing a long lifetime bidirectional SA with the CN. OMIPv6-CGA protocol requires that the first BU message received by the CN from the MN be authenticated with the Kbm and signed with the MN's CGA public key. In this memo, we introduce an alternative solution to the CGA technology, which offers the same features described in [OMIPv6-CGA] and also prevents the attack described above. 4. Quick Overview of Crypto-based Identifiers (CBID) A CBID is a 128-bit opaque identifier, which has a strong cryptographic binding with its components, i.e., generated from the MN's key pair. Consequently, using identifiers that satisfy the CBID Dupont & Haddad Expires August 21, 2006 [Page 4] Internet-Draft OMIPv6 February 2006 structure offers the advantage that other nodes, e.g., CNs, can safely trust the node when it claims ownership of that identifier. A CBID is generated as follows: CBID = First(128,SHA1 (imprint | PK)) where: imprint is a 128-bit field, which is a random value. PK is the MN's public key formatted as a DER encoding of the SubjectPublicKeyInfo structure. SHA1 is a one way hash function. | denotes a concatenation. First(x,y) means that only the high order x bits are considered from the resulting hash value. This memo introduces some changes to the procedure used to generate a CBID, in order to further reduce the possibility of having a collision. The new suggested method to generate a CBID consists of the three following steps: 1. Input = 128-bit imprint | Public Key 2. Hash = SHA256 (Input) 3. CBID = Encode_128 (Hash) where Encode_128 is an extraction function, which output is obtained by extracting the first most significant 128-bit from the resulting hash, i.e., Encode_128 (Hash) = First (128, Hash). 5. Protocol Description The following diagram shows the mobility signaling exchange between the MN and the CN for the initial contact: 1. MN to CN (via HA): Pre-Binding Update (PBU) 2a. CN to MN (via HA): Pre-Binding Acknowledgment (PBA) 2b. CN to MN (directly): Pre-Binding Test (PBT) 3. MN to CN (directly): Binding Update (BU) 4. CN to MN (directly): Binding Acknowledgment (BA) The suggested protocol is described in the following steps: - When the MN moves for the first time to a foreign network, it sends a Pre-Binding Update (PBU) message to the CN via its HA, i.e., the PBU message is encrypted between the MN and the HA. The PBU message contains the MN's HoA and CoA. In addition, the 64- bit HoA and CoA's IIDs MUST be configured from equally splitting the 128-bit crypto-based identifier. For example, the HoA's IID SHOULD be equal to the 64 rightmost significant bits and the CoA's IID should be equal to the remaining 64 bits. Dupont & Haddad Expires August 21, 2006 [Page 5] Internet-Draft OMIPv6 February 2006 - After receiving a PBU message, the CN computes two keygen tokens and sends them in two different messages, i.e., the Pre-Binding Acknowledgment (PBA) is sent via the MN's HA and MUST carry the home keygen token, and the Pre-Binding Test (PBT) is sent on the direct path and MUST carry the care-of keygen token. In order to prevent a malicious node located on the path between the MN's HA and the CN from hijacking the MN's ongoing session, by exploiting the discovery of the home keygen token sent in clear in the HoT message (as described earlier), this memo suggests that the CN MUST compute the two keygen tokens by using the MN's CoA and the 128-bit CBID. For this purpose, the home keygen token MUST be computed in the following way: Home Keygen Token := First (64, HMAC_SHA1 (Kcn, (CBID | nonce | 0))) and the care-of Keygen token MUST be computed in the following way: Care-of Keygen Token:= First (64, HMAC_SHA1 (Kcn, (CoA | nonce | 1))) where HMAC_SHA1 is detailed in [HMAC], and Kcn and nonce are detailed in [MIPv6]. - When the MN gets the PBA and PBT messages, it combines the two tokens in the same way as described in [MIPv6], and uses the result to authenticate the BU message, which is sent on the direct path to the CN. In addition, the BU message MUST be signed with the MN's private key and MUST carry the 128-bit imprint and the MN's corresponding public key. For this purpose, this document defines a new option in the BU message to carry the imprint and use the same option defined in [OMIPv6-CGA] to carry the public key in the BU message. - When the CN gets the BU message, it starts by checking the validity of the CBID. This is done by repeating the three steps described above, and comparing the resulting value with the one obtained from combining the two IIDs used in configuring the HoA and CoA. If the two values are identical, then the CN re-computes the two tokens and checks the authenticity of the the BU message. After that, the CN checks the RSA signature. If the signature is valid, then the CN creates a Binding Cache Entry (BCE) for the MN, computes a shared secret (SK) and encrypts it with the MN's public key. The CN inserts the encrypted SK in the BA message and sends it to the MN. The BA message MUST be authenticated with the shared secret. - After checking the authenticity of the BA message, the MN decrypts SK with its private key and establishes the bidirectional SA. Note that the SA lifetime is by default 24 hours, after which the two nodes should re-key by repeating steps described above. - After establishing the SA, all subsequent BU/BA exchange MUST be authenticated only with SK until the expiration of the SA. The RR procedure SHOULD NOT be repeated before the SK lifetime expires. Dupont & Haddad Expires August 21, 2006 [Page 6] Internet-Draft OMIPv6 February 2006 - For any subsequent IP handoff, the MN MAY autoconfigure its CoA by using as IID the first 64 bits resulting from hashing SK, the new network prefix and the previous CoA (pCoA), i.e., CoA's IID:= First (64, SHA1 (SK | new network prefix | pCoA)) 6. New Messages and Option Formats Our proposal introduces 3 new messages and one new option, which are described in the following: 6.1. The Pre-Binding Update Message This message is similar to a Binding Update message, but does not yet establish any state at the correspondent node. The purpose of this operation is to initiate the sending of two address reachability tests. This message uses MH Type . The format of the message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Pre-Binding Update Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dupont & Haddad Expires August 21, 2006 [Page 7] Internet-Draft OMIPv6 February 2006 Reserved 16-bit field reserved for future use. This value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Care-of Address The current care-of address of the mobile node. Pre-Binding Update Cookie 64-bit field which contains a random value, a cookie used to ensure that the responses match to requests. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options which it does not understand. This specification does not define any options valid for this message. If no actual options are present in this message, no padding is necessary and the Header Length field will be set to 3. This message is tunneled through the home agent when the mobile node is away from home. Such tunneling SHOULD employ IPsec ESP in tunnel mode between the home agent and the mobile node. This protection is indicated by the IPsec security policy database, similarly to the protection provided for Home Test Init messages. 6.2. The Pre-Binding Acknowledgment (PBA) Message This message acknowledges a Pre-Binding Update message. The purpose of this acknowledgment is to provide a part of the key Kbm required in the initial phase of our mechanism. This message uses MH Type . The format of the message is the following: Dupont & Haddad Expires August 21, 2006 [Page 8] Internet-Draft OMIPv6 February 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Pre-Binding Update Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Home Keygen Token + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 16-bit field reserved for future use. This value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Pre-Binding Update Cookie This 64-bit field contains the value from the same field in the Pre-Binding Update message. Home Keygen Token This 64-bit field contains a Home Keygen Token, calculated as specified in RFC3775. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options which it does not understand. This specification does not define any options valid for this message. If no actual options are present in this message, no padding is necessary and the Header Length field will be set to 2. This message is tunneled through the home agent when the mobile node is away from home. Such tunneling SHOULD employ IPsec ESP in tunnel mode between the home agent and the mobile node. This Dupont & Haddad Expires August 21, 2006 [Page 9] Internet-Draft OMIPv6 February 2006 protection is indicated by the IPsec security policy database, similarly to the protection provided for Home Test messages. 6.3. The Pre-Binding Test (PBT) Message This message also acknowledges a Pre Binding Update message, and ensures that the mobile node is reachable at its claimed address. The purpose of this acknowledgment is to provide the second part of the key Kbm required in the initial phase of our mechanism. This message uses MH Type . The format of the message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Pre-Binding Update Cookie + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Care-of Keygen Token + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 16-bit filed reserved for future use. This value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Pre-Binding Update Cookie This 64-bit field contains the value from the same field in the Pre-Binding Update message. Dupont & Haddad Expires August 21, 2006 [Page 10] Internet-Draft OMIPv6 February 2006 Care-of Keygen Token This 64-bit field contains a Care-of Keygen Token, calculated as specified in RFC3775. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. The receiver MUST ignore and skip any options which it does not understand. This specification does not define any options valid for this message. If no actual options are present in this message, no padding is necessary and the Header Length field will be set to 2. 6.4. The Imprint Option This option is carried by the first BU message sent by the MN to the CN. The Imprint option allows the CN to check the ownership of the two IPv6 addresses, i.e., HoA and CoA, used in the BU message. This option is used in the BU message structure described in [OMIPv6- CGA]. The option format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Imprint + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type . Dupont & Haddad Expires August 21, 2006 [Page 11] Internet-Draft OMIPv6 February 2006 Option Length Length of the option = 16 Option Data This field contains the 128-bit imprint value used to compute the CBID. 7. Security Considerations This memo describes a solution, which addresses a particular security threat related to the presence of a static malicious node on the path between the HA and the CN. As described earlier, such threat can easily prevent the mobile node from establishing a long lifetime shared secret with the CN, and severely disrupts the other alternatives, which are limited to using the classic RO mode as defined in [MIPv6]. For this purpose, the suggested solution allows the MN to provide the CN with a double proof of ownership of its HoA and CoA IIDs and introduces a new way to compute the first home keygen token. Note that this document considers only the case of establishing a long lifetime security association. The suggested solution offers a simple protection against this particular threat, and hence increases the overall security of the return routability procedure. Finally, the suggested solution does not introduce nor enhance any new or existing threats to the return routability. 8. References 8.1. Normative References [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3792, March 2005. [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support for IPv6", RFC 3775, June 2004. [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, BCP , March 1997. Dupont & Haddad Expires August 21, 2006 [Page 12] Internet-Draft OMIPv6 February 2006 8.2. Informative References [CBID] Montenegro, G. and C. Castelluccia, "Crypto-Based Identifiers (CBID): Concepts and Applications", ACM Transaction on Information and System Security (TISSEC), February 2004. [MIPv6-Sec] Nikander, P., Arkko, J., Aura, T., and E. Nordmark, "Mobile IPv6 version 6 Route Optimization Security Design Background", Internet Draft, draft-ietf-mip6-ro-sec-03.txt, June 2005. [OMIPv6-CGA] Arkko, J., Vogt, C., and W. Haddad, "Applying Cryptographically Generated Addresses and Credit-Based Authorization to Optimize Mobile (OMIPv6)", Internet Draft, draft-arkko-mipshop-cga-cba-02.txt, October 2005. Dupont & Haddad Expires August 21, 2006 [Page 13] Internet-Draft OMIPv6 February 2006 Authors' Addresses Francis Dupont CELAR Email: Francis.Dupont@point6.net Wassim Haddad Ericsson Research 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 #2334 Email: Wassim.Haddad@ericsson.com Dupont & Haddad Expires August 21, 2006 [Page 14] Internet-Draft OMIPv6 February 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. Dupont & Haddad Expires August 21, 2006 [Page 15]