Network Working Group Chunqiang. Li Internet-Draft Fuyou. Miao Intended status: Standards Track Huawei Technologies Expires: August 19, 2007 Madjid. Nakhjiri Huawei USA February 15, 2007 An enhancement of Mobile IPv6 Return Routability Procedure using Elliptic Curve Cryptography Key agreement Protocol draft-li-mipshop-mip6rrp-ecc-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 19, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Li, et al. Expires August 19, 2007 [Page 1] Internet-Draft ECC Return Routability Procedure February 2007 Abstract Mobile IPv6 Return Routability Procedure (RRP) is used to secure the Binding Updates between a Mobile Node and a Correspondent Node where there is no pre-established security relationship between the two parties. This document puts forward a mechanism called ECC RRP, which enhances the key management for Return Routability Procedure with anonymous Elliptic Curve Cryptography (ECC) Key Agreement Protocol. The proposed procedure is not prone to attacks by nodes on the route from correspondent node to home agent in way that the RRP process described in RFC3775 is. It also reduces the latency related to handovers that require new binding updates. Li, et al. Expires August 19, 2007 [Page 2] Internet-Draft ECC Return Routability Procedure February 2007 1. Introduction Mobile IPv6 document [RFC3775] specifies the Return Routability Procedure (RRP) for protection of the Binding Update and Binding Acknowledgement between Mobile Node (MN) and Correspondent Node (CN), even in scenarios where there is no pre-established security relationship between the MN and the CN. The Return Routability Procedure provides a good level of security in certain circumstances; however, this procedure cannot defend against the attacker that can eavesdrop on the two messages of HoT and CoT simultaneously. Especially, when the attacker eavesdrops on the HoT message, he also can easily calculate the Binding Management Key and personate the MN to launch the Binding Update cancellation that leads to the return- to-home spoofing attacks. This specification introduces the improvement to RRP using Elliptic Curve Key agreement protocol. The improvement reduces the vulnerabilities to the attacks mentioned above, while it manages to preserve the performance advantages of RRP. The key agreement protocol based on Elliptic Curve can provide good security with relatively small key size, thus it is suitable for mobile ip application in mobile wireless environments. This key agreement protocol enables the MN to securely establish shared key with CN without requiring the two involved parties to have any pre- established relationship. The document [RFC4449] specifies a static shared key mechanism to protect the Route Optimization. This mechanism requires the configuration of a shared secret between Mobile Node and its Correspondent Node. The applicability of this mechanism is limited due to the need for pre-configuration. This mechanism is also limited to use only in scenarios where mobile nodes can be trusted not to misbehave, as the validity of the claimed care-of addresses is not verified. The mechanism introduced in this document can be seen as using the dynamic shared key that is generated by key agreement protocol to protect the Route Optimization without pre-configuration. The ECC RRP, although benefitting from the strength of public key cryptography, can be deployed in an infrastructure-less manner and without adding to signaling latency or roundtrips; the public keys and domain parameters are simply carried through new mobility options, included in the existing RRP messaging. Li, et al. Expires August 19, 2007 [Page 3] Internet-Draft ECC Return Routability Procedure February 2007 2. Terminology 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]. RRP: Return Routability Procedure, The Return Routability procedure is a procedure defined in RFC 3775. It is performed prior to the Route Optimization, where a mobile node instructs a correspondent node to direct the mobile node's data traffic to its claimed care-of address. The Return Routability procedure provides some security assurance and prevents the misuse of Mobile IPv6 signaling to maliciously redirect the traffic or to launch other attacks. Other Mobile IPv6 terminologies are copied from RFC3775. This document uses the following abbreviations: MN: Mobile Node CN: Correspondent Node RO: Route Optimization HoTI: Home of Test Init CoTI: Care-of Test Init HoT: Home of Test CoT: Care of Test BU: Binding Update MITM: Man-In-The-Middle attacks DoS attacks: Denial of Service attacks CR: correspondent registration RRP: Return Routability Procedure Li, et al. Expires August 19, 2007 [Page 4] Internet-Draft ECC Return Routability Procedure February 2007 3. Design goals and Principles The design philosophy is that the protection mechanisms of Routing Optimization should deal with the security threats as discussed in [RFC4225], without introducing new significant security problems to the operation of Mobile IPv6. For instance, the design ought to avoid the reflection and amplification attacks and be resilient to resource exhaustion DoS attacks. The Return Routability Procedure provides less than strong authentication between IPv6 Mobile Nodes and Correspondent Nodes in the global Internet. It is necessary to accept less than perfect security in this situation, because strong authentication between previously unknown peers would require a pre-shared key configurations of massive scales or a global Public Key Infrastructure (PKI), neither of which is desirable today. The proposed mechanism also conforms to the infrastructureless features of RRP and builds upon the idea of checking that a MN is indeed reachable through both its home address and its care-of address. To avoid additional latency, ECC RRP uses the same two basic message exchanges as those in return routability procedure (RRP) [RFC3775], but is stronger or at least as secure as RRP in terms of dealing with the security threats described in RFC4225. In order to make sure the same level of resiliency to reflection and amplification attacks, care is taken so that the CN responds to messages from MN with packets of approximately the same size. It should still be noted that the solution still relies on the assumption of an uncorrupted routing infrastructure. Compared with RRP proposed by RFC3775,this new mechanism provides a good security,low handoff latency and high robustness. This mechanism uses the following principles depicted in [RFC3775]: - Verification of HoA and CoA: i.e., the mobile node is reachable through both its Home address and its care-of address. - The eventual Binding Update is cryptographically bound to the tokens and key supplied in the exchanged messages. - Symmetric exchanges are employed to to extent possible to avoid the use of this protocol in reflection attacks. - The correspondent node operates in a stateless manner until it receives a fully authorized Binding Update for avoiding state exhaustion DoS attacks. Li, et al. Expires August 19, 2007 [Page 5] Internet-Draft ECC Return Routability Procedure February 2007 - Some additional protection is provided by encrypting the tunnels between the mobile node and home agent with IPSec ESP. - Cookies check for alleviate the DOS attack. Further information about the design fundamentals of the mechanism used have been adopted from these documents [RFC3775, RFC4225]. Li, et al. Expires August 19, 2007 [Page 6] Internet-Draft ECC Return Routability Procedure February 2007 4. Binding Updates to Correspondent Nodes MN and CN establish shared master secret by Elliptic Curve Diffie- Hellman key agreement protocol, and the Binding Management Key is derived from the shared master secret. The key agreement protocol data are carried in the RRP and BU messages. In the first correspondent registration, the CN and MN perform the full RRP that contains HoTI/HoT and CoTI/CoT, however, the subsequent RRP (for subsequent binding updates, e.g. as a result of a handover) just launch the CoTI/CoT. And the generation of new Binding Management Key partly relies on the last Kbm. 4.1. Establishing shared secret between CN and MN Elliptic Curve Cryptography [ECC] is emerging as an excellent public- key cryptosystem that provides security equivalent to currently popular public-key mechanisms based on IFP (Integer Factorization Problem) or DLP (Discrete Logarithm Problem) such as RSA and DSA with smaller key sizes. Smaller key sizes result in savings for power, memory, bandwidth, and computational cost that make ECC especially attractive for mobile environments. Elliptic Curve Diffie-Hellman (ECDH) is a key agreement protocol that allows two parties to establish a shared secret key over an unsecured channel. The protocol is secure because no secrecy is disclosed (except for the public keys, which are not secret), and no party can deduce the private key of the other unless it can solve the Elliptic Curve Discrete Logarithm Problem. The simplest sort of Elliptic Curve used in cryptography is defined by an equation of the form: y^2 = x^3 + ax + b. The first stage of the ECDH key agreement protocol is the exchange of elliptic curve cryptosystem domain parameters [ECCDP]. Generally, the CN generates the domain parameters and pre-computed its key pair. At the first step, MN sends the CoTI message to query the domain parameters (p,a,b,G,n,h) prepared by CN, and sends the HoTI message to get CN's public key. Once CN receives the CoTI message, it will send the CoT message which carries the domain parameters; on receiving the HoTI message, CN sends the HoT messages that carries its public key. Once the MN receives the CoT message from CN, MN selects a random number/integer as private key according to the domain parameters and calculates the public key. MN sends the BU messages carried its public key to CN. Using its own key pair and the other's public key both the MN and the CN derive the same shared secret. MN and CN have a key pair of elliptic curve cryptography, consisting of a private key SK(a randomly selected integer in the interval [1,n-1]) and a public key PK(where PK = SK*G).Let CN's key pair be (SKc,PKc) and MN's key pair be (SKm,PKm).After receiving the Li, et al. Expires August 19, 2007 [Page 7] Internet-Draft ECC Return Routability Procedure February 2007 BU message from MN, CN and MN have the other party's public key. MN computes (Kx,Ky) = SKm*PKc, CN computes SKc*PKm. The shared secret is Kx(the x coordinate of the point). The number calculated by both parties is equal, because SKm*PKc = SKm*(SKc*G) = SKc*(SKm*G) = SKc*PKm. 4.2. New Mobility Options Mobility options use a type-length-value (TLV) format as described in [RFC3775] Section 6.2.1. Tow new mobility option are introduced in this document. 4.2.1. Public Key Option 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Public Key + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type IANA is requested to assign a new type Option Length The Option Length field contains the length of the public key in octets. Public Key The CN's public key or MN's public key This option is carried in BU or HoT/CoT message. The BU message carries the MN's public key, and the HoT message carries the CN's public key. Li, et al. Expires August 19, 2007 [Page 8] Internet-Draft ECC Return Routability Procedure February 2007 4.2.2. Elliptic Curve domain parameters Option The EC domain parameters option is carried in CoT messages. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + / Elliptic Curve Domain Parameters / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type IANA is requested to assign a new type Option Length The Option Length field contains the length of the public key in octets. Elliptic Curve domain parameters (p,a,b,G,n,h) The finite field based on the Elliptic Curve is defined by p in the prime case. The elliptic curve is defined by the constants b and a used in its defining equation. Finally, the cyclic subgroup is defined by its generator (aka. Base point)G. For cryptographic application the order of G, that is the smallest non-negative number n such that n*G = O, must be prime. 4.3. Message Flow The figure below shows the message flow for the improved return routability procedure that how to protect the Route Optimization between MN and CN. Li, et al. Expires August 19, 2007 [Page 9] Internet-Draft ECC Return Routability Procedure February 2007 Mobile node Home agent Correspondent node | | | HoTI | | |------------------------>|------------------------>| | | | | CoTI | First |-------------------------------------------------->| Correspondent | | Registration | |HoT(CN's Public Key) | Messages |<------------------------|<------------------------| | | | | CoT(EC Domain Parameters) | |<--------------------------------------------------| | | | BU(MN's Public Key) | |-------------------------------------------------->| | | / / ----------------------------------------------------------- / / | CoTI | |-------------------------------------------------->| Subsequent | | Correspondent | CoT | Registration |<--------------------------------------------------| Messages | | | BU | |-------------------------------------------------->| The Home and Care-of Test Init messages are sent simultaneously.A mobile node sends a Home Test Init message to the correspondent node (via the home agent) to acquire the CN's public key. 4.3.1. The first Correspondent registration In the first correspondent registration, the Return Routability test messages need to carry the key agreement protocol data. Home Test (from the Correspondent Node): Upon receiving HoTI message forwarded by the Home Agent of mobile node, the CN replies in the following form: * Source address = correspondent node address * Destination address = home address Li, et al. Expires August 19, 2007 [Page 10] Internet-Draft ECC Return Routability Procedure February 2007 * Parameters: + home init cookie + home keygen token + home nonce index + CN's public key In fact, the home keygen token and home nonce index are not used and set to be null. Care-of Test: This message is sent in response to a Care-of Test Init message. it is sent directly to the mobile node. The contents of the message are: * Source address = correspondent node address * Destination address = care-of address * Parameters: + care-of init cookie + care-of keygen token + care-of nonce index + EC domain parameters When the mobile node has received both the Home and Care-of Test messages, the return routability procedure is complete. As a result of the procedure, the mobile node has the data it needs to send a Binding Update to the correspondent node.Firstly,the mobile node uses the private key of its own and the CN's public key to compute the shared secret. If the size of shared secret is 160 bits, using shared secret as the master secret, otherwise hashing the shared secret by SHA1 as the master secret. CN and MN calculate the binding management key (Kbm) as follows: Kbm = HMAC_SHA-1(master secret, care-of keygen token |CN address | CoA | HoA). Authorizing Binding Management messages: Li, et al. Expires August 19, 2007 [Page 11] Internet-Draft ECC Return Routability Procedure February 2007 After the mobile node has created the binding management key (Kbm), which can supply a verifiable Binding Update to the correspondent node. Binding update To authorize a Binding Update, the mobile node creates a binding management key (Kbm) as described in the previous section. The contents of the Binding Update include the following: * Source address = care-of address * Destination address = correspondent node address * Parameters: + Home address(within the Home Address destination option) + Sequence number (within the Binding update message header) + home nonce index (not used) + care-of nonce index (within the nonce indices option) + MN's public key (within the public key option) + First (96, HMAC_SHA1 (Kbm, care-of address | correspondent |BU)) The Binding Update contains MN's public key that is used to generate the shared secret with CN. The Binding Update also contains a Nonce Indices option, indicating to the correspondent node which care-of nonces to use to recompute the binding management key. Note that the correspondent node does not create any state specific to the mobile node, until it receives the first Binding Update from that mobile node. Once the correspondent node has verified the MAC, it can create a Binding Cache entry for the mobile and maintain the value for the binding management key that can be indexed by HoA in the cache. 4.3.2. Subsequent Correspondent registration Once the MN's CoA is altered or receiving the Binding refresh request from the correspondent code, the MN needn't perform the Full RR Test, it merely sends Care-of Test init message to the correspondent. On receiving the HoTI message, correspondent node responds CoT message. Using the following method to calculate the Kbm: Kbm = HMAC_SHA-1(prev_Kbm, care-of keygen token| CoA | CN Address | HoA). A Binding Update may also be used to delete a previously established binding. In this case, the binding management key is generated as Li, et al. Expires August 19, 2007 [Page 12] Internet-Draft ECC Return Routability Procedure February 2007 follows: Kbm = HMAC_SHA-1(prev_Kbm, CN Address | HoA). The contents of Binding Update message are same as the BU message described in [RFC3775] and need not include the MN's public key option. Li, et al. Expires August 19, 2007 [Page 13] Internet-Draft ECC Return Routability Procedure February 2007 5. Security Considerations The first consideration is that, the proposed solution relies on the assumption of an uncorrupted routing infrastructure and builds upon the idea of checking that an alleged mobile node is indeed reachable through both its home address and its care-of address. [RFC3552] classifies attacks into two main categories: passive attacks and active attacks. Passive attacks are ones where an attacker simply reads information off the network and obtains confidential and/or private information which can be used to compromise network systems. Active attacks are ones where the attacker writes data to the network and can include replay attacks,message insertion, message deletion, message modification and man-in-the-middle attacks. Often, passive and active attacks are combined. Generally, if an attacker wants to launch active attacks,it collects the information of target by passive attacks firstly. Once an attacker has gained sufficient information from the passive attack, it can initiate active attacks against the target. Passive attacks on wireless networks are extremely common. Passive attacks are by their nature very difficult to detect, so it is necessary to secure Mobile IPv6 route optimization against passive attack. The RRP integrated with anonymous key agreement protocols, i.e. improved RRP can defend against the passive attacks of eavesdropping the CoT/HoT messages. However, without authentication, key agreement protocol may be vulnerable to MITM attack. 5.1. MITM attack This improved RRP can protect against the eavesdropping attacks but not defend against certain man-in-the-middle attacks, when the attacker resides along the routing path between the correspondent node and the mobile node's home agent. However, it should be noted that such attackers are capable of performing the similar attacks even without Mobile IPv6. Thus this proposal does not introduce any new threats in that sense. For instance, when launching MITM attack, an attacker would not only need to observe the packets passing by but would instead need to inject modified packets in both directions. Owing to the property of IP, an attacker in the middle between MN and CN tries to fool both entities as above described, but it can not prevent the original packet from CN, the MN will receive two different public key values for the CN, and thus be aware that a malicious node is trying to lead some attacks. So the MN can send warning message to the CN or take other measures. MN also has ways to detect the attacks. In order not to be readily detected the attacks by the CN and MN, the attacker also is able to prevent the original packets intercepted are not Li, et al. Expires August 19, 2007 [Page 14] Internet-Draft ECC Return Routability Procedure February 2007 delivered, which requires the attacker has a strong capabilities of control the network traffic. So if attacker wants to launch the MITM attack without being detected, it can control the communication channel between the both sides. In fact, if an attacker can perform the MITM attack between MN and CN, well then it also can launch attacks that not by the forged Binding Update messages. Without authentication mechanism, the node at its home link still can not avoid this kind of attack. 5.2. Denial of service attack (DOS) attack Creating state safely and Limitation the rate of Mobility Header message make the improved RRP have well immunity to DOS attacks. The improved return routability procedure also has protection against resource exhaustion Denial-of-Service attacks. The correspondent nodes do not retain any state about individual mobile nodes until an authentic Binding Update arrives. This is achieved through the construct of keygen tokens from the nonces and node keys that are not specific to individual mobile nodes. The keygen tokens can be reconstructed by the correspondent node, based on the care-of address information that arrives with the Binding Update. This means that the correspondent nodes are safe against memory exhaustion attacks. Due to the use of same public/private key pair with all MNs, correspondent node does not compute the master secret until receiving the binding update message, so the correspondent nodes are relatively safe against CPU resource exhaustion attacks as well. The mobile node MUST NOT send Mobility Header messages of a particular type to a particular correspondent node more than MAX_UPDATE_RATE(=3) times within a second. These limitation the rate of sending/receiving Mobility Header messages also prevents or mitigates denial of service attacks. A correspondent node can protect itself against some of these resource exhaustion attacks as follows. If the correspondent node is flooded with a large number of Binding Updates that fail the cryptographic integrity checks, it can stop processing Binding Updates. If a correspondent node finds that it is spending more resources on checking bogus Binding Updates than it is likely to save by accepting genuine Binding Updates, then it may silently discard some or all Binding Updates without performing any cryptographic operations. 5.3. Replay attacks The generation of Kbm is protected by the Care-of Nonce and can defend against replay attack.The improved return routability procedure also protects the participants against replayed Binding Li, et al. Expires August 19, 2007 [Page 15] Internet-Draft ECC Return Routability Procedure February 2007 Updates. The attacker is unable replay the same message due to the sequence number which is a part of the Binding Update. It is also unable to modify the Binding Update since the MAC verification would fail after such a modification Li, et al. Expires August 19, 2007 [Page 16] Internet-Draft ECC Return Routability Procedure February 2007 6. IANA Considerations This document defines two new mobility options, whose values are to be assigned from the option numbering space. The Option Type values of Public key and Domain Parameters Option require to be assigned by IANA. Li, et al. Expires August 19, 2007 [Page 17] Internet-Draft ECC Return Routability Procedure February 2007 7. References [1] Bradner, S, "Key words for use in RFCs to Indicate Requirement Levels", March 1997. Li, et al. Expires August 19, 2007 [Page 18] Internet-Draft ECC Return Routability Procedure February 2007 Authors' Addresses Huawei Technologies Email: li.chunqiang@huawei.com Huawei Technologies Email: miaofy@huawei.com Huawei USA Fax: Email: mnakhjiri@huawei.com Li, et al. Expires August 19, 2007 [Page 19] Internet-Draft ECC Return Routability Procedure February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Li, et al. Expires August 19, 2007 [Page 20]