Network Working Group W. Haddad Internet-Draft S. Krishnan Expires: April 26, 2007 Ericsson Research J. Choi Samsung AIT October 23, 2006 Secure Neighbor Discovery (SEND) Optimization and Adaptation for Mobility: The OptiSEND Protocol draft-haddad-mipshop-optisend-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 April 26, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo describes a new set of mechanisms, which aims to increase the Secure Neighbor Discovery (SEND) protocol usability by reducing the required processing power on small devices and adapting it to mobile environment requirements while maintaining its efficiency. Haddad, et al. Expires April 26, 2007 [Page 1] Internet-Draft OptiSEND October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Problem and Motivation . . . . . . . . . . . . . . . . . . . . 4 5. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 6 6. Overview of One-Way Hash Chain . . . . . . . . . . . . . . . . 6 7. Overview of OptiSEND . . . . . . . . . . . . . . . . . . . . . 6 8. New Options and Messages Formats . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 11. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Haddad, et al. Expires April 26, 2007 [Page 2] Internet-Draft OptiSEND October 2006 1. Introduction Securing Neighbor Protocol (SEND) has been designed to mitigate potential threats against the IPv6 Neighbor Discovery Protocol (NDP). [SEND] protocol is based uniquely on the Cryptographically Generated Address (CGA). Consequently, SEND relies heavily on using RSA signature, which in turn may severely limit its usability and deployment in the wireless world, due to the fact that the majority of small mobile devices are very limited in terms of processing power and battery consumption. This memo describes a new protocol (OptiSEND), which aims to optimize SEND by reducing the required processing power on small devices and adapting it to mobile environment while maintaining its efficiency. OptiSEND is built on top of the SEND protocol. 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. Glossary Access Router (AR) The Access Router is the mobile node's default router. Oustide Node (ON) An outside node (ON) is a node, which is already attached to the infrastructure via one or many Access Router(s). An ON can be static or mobile. Selected Access Router (sAR) A selected AR is the AR chosen by the MN as the destination node for its RtSol message signed with CGA technology. Soliciting Node (SN) A soliciting node is a node, which has started the procedure to attach itself to the infrastructure by sending a RtSol message signed with CGA technology to a selected AR (sAR). Haddad, et al. Expires April 26, 2007 [Page 3] Internet-Draft OptiSEND October 2006 One-Way Chain 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... Neighbors Nodes attached to the same link. For more details about the one-way chain, please refer to [OWHC]. 4. Problem and Motivation SEND protocol has been designed to secure the exchange of the IP address(es) and routing information between different nodes as described in the Neighbor Discovery [ND] and the IPv6 Stateless Address Autoconfiguration [STAT] Protocols. Such exchange is required in two different scenarios. The first one is when a mobile/ static node requests routing, network parameters and IP layer address configuration(s) information from the infrastructure. This is done via sending and/or receiving information from one or many access router(s) (AR). The second scenario occurs when different nodes located on the same link exchange their IP and MAC addresses between themselves. [ND_T] describes different threats, which may appear if/when NDP is applied without any protection (e.g., in a public network). These threats cover both scenarios and may severely disrupt the exchange of information on one particular link, e.g., by launching DoS attacks against one or many nodes. In order to address these issues, SEND relies solely on the Cryptographically Generated Addresses technology (described in [CGA]) to provide a proof of ownership, and consequently to build a form of trust relationship betweeen different nodes. For this purpose, SEND is highly recommended when outside nodes (ONs) are using NDP to talk to the infrastructure and between themselves (i.e., if they are neighbors). When the SEND protocol is used between the nodes and the infrastructure, an AR is expected to use the CGA technology in all messages sent to any node trying to attach itself to the infrastructure. As already mentioned, CGA technology allows the AR to provide a proof of ownership of its claimed IP address(es) and Haddad, et al. Expires April 26, 2007 [Page 4] Internet-Draft OptiSEND October 2006 enables the receiving node(s), i.e., ON(s), to validate all information carried in these messages. Note that in this particular scenario, the ON is not required to use SEND when sending a router solicitation (RtSol) message to the AR(s). Similarly, applying SEND protocol between a set of nodes attached to the same AR(s), enables each node and by always relying on the CGA technology, to provide a proof of ownership of its newly configured IP address(es) and to defend its uniqueness on one particular link, during a duplicate address detection (DAD) procedure. However, SEND reliance on the RSA signature (as inherent part of the CGA technology) is raising questions concerning the cost and scale of its usability and deployment. These questions become more pertinent when the mobility aspect is added to the original problem related to limited processing and battery power devices. In fact, each time the MN switches to a new access point (AP), i.e., perform a link layer handoff, it has to check if it is still attached to the infrastructure via the same AR(s) or if it needs to attach to another part or simply a new one. Consequently, a fast moving node will have to dedicate a considerable amount of its power processing cycles to process RSA signatures in order to validate RtAdv messages sent by previous and new AR(s). Similarly, after configuring a new IP address, the mobile node (MN) has to use SEND to exchange NDP messages with other nodes. Note that the presence of at least one malicious node on the same link can strongly and easily contribute in exhausting the processing power of the targeted MN and may add significant delay during handoff procedures. In order to enable seamless mobility while running time sensitive applications, a new protocol Fast Mobile IPv6 ([FMIPv6]), has been standardized and is currently under review. FMIPv6 relies on involving the infrastructure in the handoff process by requiring from the previous AR (pAR) and new AR (nAR) to exchange signaling information upon receiving a trigger message from the MN (i.e., when starting the handoff procedure). Consequently, using RSA signature during this critical phase may add significant delay to the handoff procedure (note that the situation gets quickly worse in the presence of malicious node(s)). The main goal of this document is to provide an alternative solution to the RSA signature, which optimizes the use of SEND by reducing the power processing cost, increasing the scale of deployability and addressing mobility requirements from an early design stage by providing a simple way to forward shared secrets between pAR and nAR(s). However, our current design is limited to the exchange of ND messages between ON and the infrastructure and does not cover yet the exchange of ND messages between neighbors only. Our future work will address these particular scenarios. Haddad, et al. Expires April 26, 2007 [Page 5] Internet-Draft OptiSEND October 2006 5. Protocol Requirements OptiSEND does not require major change in the ND protocol. But it requires that all AR(s) rely on the one-way hash chains and shared secrets to authenticate the RtAdv messages. Moreover, OptiSEND requires that ONs authenticate a special set of messages by using a shared secret obtained from using CGA technology when exchanging one particular message with AR. Finally, OptiSEND requires also that ON auto-configures additional IPv6 addresses (if/when needed) by using the shared secret and other parameters to compute the new interface identifier(s) (IID(s)). OptiSEND protocol introduces new messages in addition to the existing set of messages defined in the ND protocol. The new messages are required to distribute identification and security parameters between different ARs. 6. Overview of One-Way Hash Chain When the one way function H() is a cryptographic hash function, then the chain is called one-way hash chain (OWHC). For the setup of the one-way hash chain, the generator chooses randomly the root or seed of the chain, i.e., the value V[n] (i.e., Vn), and derives all previous values V[i] by iteratively applying the hash function H(). The value V[0], which is considered the end-value, is normally made public, and potentially linked to the identity of the user processing the corresponding root value. In order to verify a one way hash chain values, we assume that the ONs attached to the infrastructure know an authentic value of the generator's one-way chain (which can be the end-value V[0] or the last "disclosed value" V[d]). To verify an input value V[i] of a hash chain, the verifier iteratively applies the one-way function H() i times and compares the result to the trusted value V[0], i.e., verify that H(V[i]) if applied i times is equal to V[0]. If the computed and known values are equal, then the input value is said to be authentic. Note that if another value V[j], for j < i, is already known, then it suffices to iteratively apply the one-way function some i-k times to the input value, and compare the result to this intermediate value. 7. Overview of OptiSEND The main goal behind designing OptiSEND protocol is to eliminate the use of RSA signature whenever possible and/or significantly reduce its use, without amplifying existing threats nor introducing new ones Haddad, et al. Expires April 26, 2007 [Page 6] Internet-Draft OptiSEND October 2006 nor reducing the level of security introduced by the SEND protocol. Another important futur goal is to reduce as much as possible the use of any authentication mechanism(s) between an ON and its neighbors. In addition, OptiSEND protocol incorporates a solution, which enables the MN to perform secure and fast mobility. In order to achieve its purposes, OptiSEND protocol addresses separately the issue of an outside node talking to the infrastructure and the one where an ON is talking with its neighbors. The current proposal deals only with the first scenario. For the first case, OptiSEND uses the one way hash chain to allow the AR(s) to authenticate their RtAdv messages. By relying on such technique, OptiSEND enables all ONs attached to the infrastructure to continue validating the RtAdv messages without having to use extensive processing power on validating RSA signature(s). In order to achieve such goal, OptiSEND requires that the ON uses CGA technology to send its first RtSol message only. When a particular AR gets a RtSol message signed with CGA, i.e., thus becoming a selected AR (sAR), it generates a neighbor shared secret (Ks) and sends it to the SN along with the hash of the next value (i.e., yet undisclosed) in its one way chain in a unicast RtAdv message. For clarity purpose, we call the next value to be disclosed in the next multicast RtAdv message V[i+1]. Consequently, the sAR MUST send in the unicast RtAdv message Hash(V[i+1]) = V[i] (where V[i] is the last disclosed value). The goal behind inserting the hash of the next one way hash chain value in the unicast RtAdv message sent to an SN is to enable it to hook itself to the different one-way hash chains used by ARs thus enabling it to follow and authenticate new values sent by different ARs in subsequent multicast RtAdv messages. Note that after sending a RtSol message signed with CGA, the SN may receive more than one RtAdv message from multiple ARs attached to the same link. However, the SN may also receive RtAdv messages before sending its RtSol message. In the first scenario, and in order to avoid having each AR generating one shared secret and sending it to the node in a unicast RtAdv message, ARs SHOULD be able to select one AR to generate Ks and then distribute it to them along with the SN data. In the latter case, a node SHOULD select one particular AR and sends it a RtSol message signed with CGA. In such case, the selected AR (sAR) will generate the neighbor shared secret (Ks) and sends it to SN in a unicast RtAdv message. The neighbor shared secret MUST be encrypted with the MN's CGA public key and the unicast RtAdv message MUST be signed with CGA. In addition, the sAR MUST insert in the unicast RtAdv message the set of the last disclosed OWHC values used by other ARs attached to the same link. For these purposes, the sAR MUST insert new options in the RtAdv message. Haddad, et al. Expires April 26, 2007 [Page 7] Internet-Draft OptiSEND October 2006 After receiving the unicast RtAdv message, the ON decrypts Ks and uses the one-way hash chain to check the authenticity of subsequent multicast RtAdv messages via authenticating the OWHC value carried in the RtAdv message. In fact, each multicast RtAdv message MUST carry one new value from the AR's one-way hash chain. Consequently, upon receiving a multicast RtAdv message, the ON should check first the authenticity of the value carried in the multicast RtAdv message before processing or dropping the message. For this purpose the ON should hash the value carried in the RtAdv message and compares it to the one disclosed in the last RtAdv message received by the ON. Note that in case the ON misses one RtAdv message and before it re-sends a new RtSol message signed with CGA to request a fresh value, it SHOULD hash the value disclosed in the latest RtAdv message a maximum X times and compares each value to the one stored in its cache entry. If after X attempts, the obtained value does not match the stored one, then the ON SHOULD re-send a RtSol message signed with CGA in order to request a new value and re-synchronize itself. The ON SHOULD silently discard any RtAdv message carrying a value, which has already been disclosed in a previous RtAdv message or which is simply not authentic. The ON SHOULD also authenticate any unicast message sent to an AR with its Ks and the AR SHOULD authenticate any unicast message sent to one particular ON with its corresponding Ks. The ON will also use Ks for other purposes, e.g., obtaining new end value(s) for new one- way hash chain(s), generate new 64-bit interface identifiers (IIDs). Another goal is the fast mobility (described below). Other goals will be described in a futur work. Note that the lifetime for Ks is set to 24 hours, after which the ON SHOULD repeat the procedure described above in order to refresh its Ks. Note that when all values of a particular OWHC have been disclosed, the corresponding AR can signal to its visitors (i.e., ONs) the availability of a new OWHC by sending a multicast RtAdv message signed with CGA and without any value. Upon receiving such message, each ON SHOULD send a unicast RtSol message to the AR to request one value (e.g., the end value) in order to hook itself to the new OWHC. Note that the ON MUST authenticate the unicast RtSol message with its Ks. When an AR receives a RtSol message signed with one Ks, it MUST send back a unicast RtAdv message, which carries the last disclosed value (Vi) of its OWHC. The sAR MUST encrypt Vi and authenticate the RtAdv message. In parallel to sending a unicast RtAdv message to the SN, the sAR MUST update all other ARs attached to the same link with the new ON parameters, which MUST include its MAC address, the shared secret (Ks), the IPv6 64-bit interface identifier (IID) and its lifetime. For this purpose, the sAR SHOULD send a multicast Binding Haddad, et al. Expires April 26, 2007 [Page 8] Internet-Draft OptiSEND October 2006 Advertisement (BdAdv) message to the ARs to request creating a visitor cache entry (VCE) for the new ON. Upon receiving a BdAdv message, each AR checks its VCE for an existing entry, which contains the corresponding ON's MAC address(es). If a VCE exists, then the AR updates it with the new Ks and its lifetime. Otherwise, the AR SHOULD create a new one. Note that the BdAdv message MUST be encrypted with the AR's CGA private key. For the fast mobility, e.g., [FMIPv6] protocol, OptiSEND protocol delegates additional responsibilities to the infrastructure in order to address security requirements related to FMIPv6. For this purpose, OptiSEND enables the infrastructure to provide security assistance to the MN when switching to a new AR by enabling the infrastructure to seamlessly forward security credentials to new AR(s), in parallel with the moving node, thus enabling the MN to keep authenticating its mobility signaling messages with the same key as long as such key remains valid. In the FMIPv6 scenario, this is achieved by allowing the previous AR (pAR) to send the MN's Ks, MAC address and other parameters to the new Access Router (nAR), upon receiving a hint from the MN, e.g., a Fast Binding Update (FBU) message signaling an imminent handoff. The pAR may also send a multicast BdAdv message to nAR(s) without waiting for such hint to be send by the MN, e.g., case of network triggered handover. By seamlessly forwarding Ks to new AR(s), the MN will be able to secure its critical mobility signaling messages by using the same key. Moreover, using symetric cryptography allows the MN to keep using FMIPv6 procedure even if the nAR/pAR does not recognize the identity of one particular AP, e.g., case of a malicious AP(s). 8. New Options and Messages Formats TBD 9. Security Considerations This memo introduces a new protocol, which is built on top of SEND. There are two main goals behind the OptiSEND design. The first one is to alleviate the processing power required to validate RSA signature without amplifying existing threats nor adding new ones. The second goal is to widen the usability scope to include other features, which impact the neighbor discovery and the fast mobility protocols by fully exploiting the form of trust built between the infrastructure and the ON upon attaching to the sAR. To achieve the first goal, OptiSEND protocol is built on the fundamental assumption that when an operator cares about providing Haddad, et al. Expires April 26, 2007 [Page 9] Internet-Draft OptiSEND October 2006 both secure access and secure fast mobility, then the operator's infrastructure itself should be already secure. This means that it is assumed in this memo that all links between AR(s) are secure and all links between AR(s) and AP(s) are secure. Consequently, the vulnerability to man-in-the-middle attacks is eliminated or significantly reduced since using man-in-the middle rogue AP(s) must not be possible. The second goal is achieved as a direct result from the first one as long as the foreign infrastructure(s) remains secure. In such case, OptiSEND does not introduce nor amplify new/existing threats. 10. Acknowledgments Authors would like to thank Pekka Nikander for his valuable input at the early stage of this work. 11. Normative References [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3792, March 2005. [FMIPv6] Koodli, R., "Fast Handovers for Mobile IPv6", Internet Draft, draft-koodli-mipshop-rfc4068bis-00.txt, October 2005. [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)", Internet Draft, draft-ietf-ipv6-2461bis-08.txt, September 2006. [ND_T] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Model and Threats", RFC 3756, May 2004. [OWHC] Hu, Y., Jakobsson, M., and A. Perrig, "Efficient Constructions for One-Way Hash Chains", ACNS Conference, June 2005. [SEND] Arkko, J., Kempf, J., Sommerfield, B., Zill, B., and P. Nikander, "Secure Neighbor Discovery (SEND)", RFC 3971, March 2005. [STAT] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", Internet Draft, draft-ietf-ipv6-rfc2462bis-08.txt, May 2005. [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate Haddad, et al. Expires April 26, 2007 [Page 10] Internet-Draft OptiSEND October 2006 Requirement Levels", RFC 2119, BCP , March 1997. Haddad, et al. Expires April 26, 2007 [Page 11] Internet-Draft OptiSEND October 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 345 7900 Email: Suresh.Krishnan@ericsson.com JinHyeock Choi Samsung AIT Communication & N/W Lab Suwon 440-600 P.O. Box 111 KOREA Phone: +82 31 280 9233 Email: jinchoe@samsung.com Haddad, et al. Expires April 26, 2007 [Page 12] Internet-Draft OptiSEND October 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, et al. Expires April 26, 2007 [Page 13]