Network Working Group Jari Arkko INTERNET-DRAFT Ericsson November 2001 Security Framework for Mobile IPv6 Route Optimization 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working docuí ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute workí ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete 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 may be found at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories may be found at http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as , and expires May 14, 2002. Please send comments to the author or to Mobile IP working group. 2. Abstract Without a security solution, Mobile IPv6 Route Optimization functioní ality exposes the involved nodes as well as other nodes in the Interí net to various security attacks. Recent work in the area has produced a number of proposals to solve these security issues. The proposals are, however, in many cases architecturally quite different from each other, and don't always describe more than a part of the solution. Due to the complexity of the problem, we feel that it is necessary to docí ument a higher level solution roadmap. We call this roadmap the "Secuí rity Framework for Route Optimization". It talks about the architecí ture that a complete solution has, and the components that are needed. We also discuss factors affecting the need for various components and particular technical solutions for them. 3. Contents 1. Status of this Memo..................................1 2. Abstract.............................................1 3. Contents.............................................1 4. Introduction.........................................2 5. Scenarios............................................3 5.1. General Internet.....................................3 J. Arkko Expires May 2002 [Page 1] INTERNET-DRAFT RO Sec Frame 14 November 2001 5.2. Closed Networks......................................3 5.3. Networks with a Trusted Party........................4 6. Main Requirements....................................4 7. Solution Architecture................................5 8. Components of The Solution...........................6 8.1. "Weak" Authentication Mechanism......................6 8.2. "Strong" Authentication Mechanism....................7 8.3. Binding Security Association.........................7 8.4. Home Agent Signaling Protection Mechanism............8 8.5. Binding Update Message...............................8 8.6. Home Address Option Check............................9 8.7. Protocol Details.....................................9 9. Example Solutions....................................10 10. Future Work..........................................10 11. Acknowledgments......................................11 12. References...........................................11 13. Author's Address.....................................12 4. Introduction The Mobile IP working group is currently searching for a security solution that enables sufficient authentication between IPv6 Mobile Nodes (MNs) and a Correspondent Nodes (CNs) in the the global Interí net. Without some form of authentication, Mobile IPv6 Route Optimizaí tion functionality exposes not just the involved MNs and CNs but also all other nodes of the Internet to serious security attacks. These include stealing or modifying traffic contents and preventing communií cations. Unfortunately, the authentication is a hard problem because, in gení eral, we can not assume the existence of a global security infrastrucí ture to strongly authenticate all nodes of the Internet. This rules out the use of traditional secret- or PKI-based authentication infrasí tructures. Another kind of authentication, however, suffices under certain cirí cumstances. For the purposes of this document, a "weak" authenticaí tion mechanism denotes any authentication mechanism that is not "strong" in the traditional sense of cryptographic protocols. All known strong authentication mechanisms require that the authenticating parties have some a priori information about each other. Requirements we will lay out later necessitate that this MUST NOT be assumed, therefore pointing to security mechanisms that are weaker than the traditional strong mechanisms. These are called "weak" authentication in this document. Recent work in the area has produced a number of new proposals [4, 5, 6, 9, 10] to solve the problem as well as discussion on some aspects of the problem [2, 11, 12, 13, 14]. The proposals are, however, in many cases architecturally quite different from each other. For instance, some proposals use persistent security associations while others do not. The foundations on which the security is based on also differ; some approaches rely on return routability while others look for relationships of public keys and IPv6 addresses. Furthermore, none J. Arkko Expires May 2002 [Page 2] INTERNET-DRAFT RO Sec Frame 14 November 2001 of the current proposals include everything needed for the final soluí tion. For instance, it is currently debated whether some relationship is needed with the Binding Update authentication before the Home Address Option can be used. A second example is that the use of "strong" authentication in certain closed networks (such as military networks) has been widely recognized as a requirement, though most proposals currently deal with just the "weak" authentication part. Due to the complexity of the problem, we feel that it is necessary to document a higher level solution roadmap. We call this roadmap the "Security Framework for Route Optimization". It talks about the archií tecture that a complete solution has, and the components that are needed. We also discuss factors affecting the need for various compoí nents and particular technical solutions for them. Section 5 describes typical network scenarios where Route Optimization is needed. Section 6 outlines the main requirements for the security solution for Route Optimization, Section 7 describes the architecture such solutions should have. Section 8 discusses the properties of the components. Finally, Section 9 gives a few examples of a complete solution. 5. Scenarios 5.1. General Internet In the general Internet case, any mobile or regular node may communií cate with any other node. The mobile nodes have no pre-established knowledge about the correspondent nodes, and there is no common secuí rity infrastructure that would hold both. Neither do the corresponí dent nodes have any information about the mobile nodes. Note that it would be inappropriate to suggest that a new security infrastructure should be built for the global Internet in order to allow any two nodes to establish establish enough trust to perform route optimization with each other. While it may be feasible to build large security infrastructures, one covering each and every node in the global Internet is not feasible. Any Route Optimization security method used in the general Internet MUST NOT require a global security infrastructure. 5.2. Closed Networks Some organizations require substantial trust on their network and security for their communications. The networks of these organizations typically use "strong" cryptographic protection for all or most commuí nications. These networks may not even be necessarily connected to the rest of the Internet. In these networks, it is essential that also the MIPv6 control signalí ing can take place in at least as secure manner as the regular commuí nications. While the signaling may not contain as sensitive informaí tion as regular communications, security vulnerabilities in "weak" J. Arkko Expires May 2002 [Page 3] INTERNET-DRAFT RO Sec Frame 14 November 2001 mechanisms may be used to launch Denial-of-Service attacks. Some implementations of Route Optimization MAY offer support for these Closed Networks with "strong" cryptographic protection of the MIPv6 control signaling. As discussed in [11], this "strong" protection can be either a replacement to the "weak" methods, or used simultaneously with the "weak" methods. It should be noted that the "strong" methods typically can not be employed for only a part of the communications; address spoofing, for instance, could be used to fool CNs into believing that a particular Binding Update does not need security because it belongs to the local network which is assumed secure even without "strong" cryptography. Therefore, the selection between using and not using the "stronger" mechanisms is typically an on/off selection for all nodes in a netí work. 5.3. Networks with a Trusted Party Certain networks, while open and a part of the Internet, may have a trusted third party that can offer assistance also in the Route Optií mization security case. For instance, cellular and wireless networks typically have an Authentication, Authorization, and Accounting (AAA) infrastructure that could potentially play such a role as well, if they start to act as Key Distribution Centers (KDCs) for Route Optií mization. A Public Key Infrastructure could also take on this role for a particular service provider. While in general two random nodes in the Internet may not belong under the same security infrastructure, it might still be feasible to offer an optimized service only to that subset of nodes that belongs under the same trusted third party. This scenario is similar to the closed network scenario, but typically the emphasis in this case is in the optional use of an optimized serí vice while the closed networks typically prevent all outside communií cations, and require not just Route Optimization but all IP traffic to be protected. Route Optimization security methods MAY allow the use of trusted third parties. If they do, they MUST be able to securely determine if the peer belongs to the same infrastructure, and allowing Route Optimizaí tion service if and only if it does. 6. Main Requirements Without security, Route Optimization may subject not just MNs and CNs but also other nodes in the Internet against various types of attacks. As discussed in [12], Route Optimization security methods MUST provide means to protect other nodes in the Internet, and they MUST be mandaí tory for all nodes participating in Route Optimization (R1). In the interest of keeping IPv6 small, it is also important that MIPv6 does not put extra requirements on all nodes regardless of their J. Arkko Expires May 2002 [Page 4] INTERNET-DRAFT RO Sec Frame 14 November 2001 willingness to participate in Route Optimization. Therefore, Route Optimization security methods MUST NOT require any actions from nodes that do not offer Route Optimization (R2). As all hosts in the Internet are potentially CNs, Route Optimization security mechanisms MUST provide means to protect the CNs (R3). As discussed in [12], the use of these means is, however, optional by the decision of a particular CN. Note that when we talk here about proí tecting a particular node, we refer to the nodes ability to continue communicating with peers relevant to it, and the ability of the node to withstand Denial-of-Service attacks. Given that the amount of mobile nodes in the Internet is expected to sharply increase, the protection of the MNs is also necessary. Thereí fore, Route Optimization security mechanisms MUST provide means to protect the MNs (R4). Again, the use of these means is, however, optional by the decision of a particular MN [12]. Any security solution MUST support the General Internet scenario as discussed in Section 5, and MAY support the Closed Network and Trusted Party scenarios. Therefore, the solution MUST work without a global trust infrastructure (R5) and MAY work with a local trust infrastrucí ture in certain networks (R6). If a MIPv6 implementation offers supí port for both types of situations, it MUST be possible to configure the node to accept exactly one type of situation (R7). The reachability of the MN depends heavily on the ability of the Home Agent (HA) to know what the current CoA of the MN is. It seems approí priate to require that "strong" mechanisms be used to protect signalí ing communication between the MN and the HA (R8). This is particularly relevant also because some of the current "weak" authentication proí posals rely on the security of these communications. Any security solution MUST define under which circumstances Home Address Option (HAO) may be accepted by CNs [14] (R9). The security solution MUST NOT itself have weaknesses e.g. against Denial-of-Service attacks (R10). As suggested in [12], this may not always be easy. Where full protection is not possible, the solution MAY use secondary measures such as gradually turning off Route Optií mization to save resources. 7. Solution Architecture The solution MUST contain the following components: - A mandatory "weak" authentication mechanism, capable of running in the global Internet. This will be used to protect Route Optimization signaling with any CNs. - An optional "strong" authentication mechanism. Networks that require this can configure this mechanism to be the only one that is accepted. This may be the same or a different mechanism that is used for the protection of the BUs towards the HA. J. Arkko Expires May 2002 [Page 5] INTERNET-DRAFT RO Sec Frame 14 November 2001 - An optional Binding Security Association (BSA) which is produced by the authentication mechanisms, and subsequently used to protect one or more Binding Updates. It is optional because the authentication mechaí nism could be rerun for each Binding Update [10]. - A mandatory protection mechanism to run between the MN and the Home Agent, to protect the signaling from the MN to the HA and back. (While this is not strictly a part of the Route Optimisation functionality, we feel that it is appropriate to discuss it here, given that the same kinds of Binding Updates are sent to both CNs and the HA, and because some of the proposed methods for "weak" authentication assume certain amount of protection from the HA - MN link.) - A Binding Update message. This is a message from the MN to the CN (or to the HA) that finally updates the tables necessary for Route Optimization (or basic mobility) to work. - A mechanism which CNs use to determine whether a packet with a Home Address Option can be accepted. 8. Components of The Solution 8.1. "Weak" Authentication Mechanism The "weak" authentication mechanism is the center of the RO security solution. It provides reasonable trust that the received BUs are legitimate. It is responsible for implementing the requirements R1, R3, R4, R5, and R10. Is a single "weak" authentication mechanism sufficient? A number of proposals for "weak" and "strong" authentication protocols have been proposed. These can roughly be divided to the following classes: - No authentication - Return routability and cookie-based mechanisms. - Mechanisms based on cryptographic properties of addresses. - "Strong" authentication mechanisms. These come in two variants: those based on general security mechanisms such as IPsec/IKE and PKIs, and those based on local AAA infrastructures. We argue that the 'no authentication' MUST NOT be an option under any circumstances. This is because the effects of allowing unauthenticated Binding Updates are not just related to the node itself, but also to other nodes in the Internet. We also argue that both "weak" and "strong" alternatives should be allowed, as long as they are used in an exclusive manner as explained in Section 5.2. The remaining quesí tion is if several levels of "weak" authentication should be allowed. Again, and as explained in [12], the effects of a low strength mechaí nism do not just apply to the nodes in question but also to their clients, and in some cases also allow Denial-of-Service attacks towards other nodes. Therefore, we recommend a single, "weak" but as J. Arkko Expires May 2002 [Page 6] INTERNET-DRAFT RO Sec Frame 14 November 2001 good as possible mechanism to be standardized for this purpose. However, even today's best "weak" authentication mechanism could be found inadequate in the future for some reason, and replaced by a betí ter protocol. For this reason, it may be necessary to understand how such transition could be achieved. 8.2. "Strong" Authentication Mechanism "Strong" authentication MAY be offered as an alternative to "weak" authentication for certain networks. It is responsible for implementí ing the requirements R1, R3, R4, R6, R7, and R10. As discussed in [11], this "strong" protection can be either a replacement to the "weak" methods, or is used simultaneously with the "weak" methods. As discussed in Section 5.2, the selection between using a "strong" method or not is typically an on/off selection for all nodes in a network. Typical security technologies allow users to define on which IP addresses or networks certain methods should be used. However, if the same kind of traffic is accepted from different sources using security and without security, this opens an attack where the source address is modified to claim no security is needed. A typical attack packet forges its source address to reside within the secure network, which can fool the destination if it relies on addresses in its security policies. Firewalls typically can prevent such packets to enter networks, however. In any case, we recommend that users SHOULD NOT simultaneously allow both "strong" and only "weak" security. Note that the true strength of the strong methods depends on the qualí ity and granularity of the underlying trust infrastructure. For instance, a PKI that gives certificates without stating any IP addresses in them (e.g. just an e-mail identity) doesn't really coní clusively prove address ownership. However, it may be sufficient in closed networks to prove that the peer is "one of the good guys" -- for instance an employee of the company. Secondly, the identities in certificates can be used a unforgeable log of events that took place. It is, however, possible that the PKI lists also IP addresses in the certificates, in which case the protocols can make more exact decií sions about the address ownership. 8.3. Binding Security Association The BSAs are produced by the authentication mechanisms, and subseí quently used to protect one or more Binding Updates. It is optional because the authentication mechanism could be rerun with each Binding Update [10]. It does not affect the requirements placed for the RO security solution, though its implementation affects the resulting characteristics. The various trade-offs related to this are touched upon in [10]. The main issues include the following: - The frequency of the Binding Updates and their locality towards a particular CN. Communications that last only a moment towards a parí ticular CN do not benefit from the BSAs. J. Arkko Expires May 2002 [Page 7] INTERNET-DRAFT RO Sec Frame 14 November 2001 - The cost of "weak" authentication in terms of roundtrips and compuí tation. Costlier methods such as SUCV and CAM need BSAs more than cheaper methods such as BAKE. - A BSA potentially opens up a wider range of replay attacks thus might need stronger mechanisms to prevent replays. The implementation alternatives for BSAs, if needed, are described in [11]. Note that "strong" and "weak" methods may use either the same Security Association concept and protection mechanism, or different ones. 8.4. Home Agent Signaling Protection Mechanism The purpose of this mechanism is to authenticate and protect signaling traffic between the MN and the HA, such as BUs from the MN or messages exchanged as a part of some "weak" authentication procedure with a CN. It is responsible for implementing the requirement R8. In its simplest form, this mechanism can be a shared secret configured both at the MN and the HA, and some kind of protocol that protects the integrity and possibly also confidentiality of the signaling packets. One solution for this is IPsec AH / ESP tunnels. It is also possible that whatever solution is used to implement the BSAs between CNs and MNs is also used between the MNs and HAs. A more complicated version of this mechanism would allow the HA and the MN to use something else than shared secrets to protect the trafí fic. For instance, a local PKI of an organization could be used to allow IKE to establish proper IPsec SAs. The mechanism MUST protect at least the BUs to the HA. It MUST also protect some packets that appear as payload traffic to the HA, given that the "weak" authentication protocols expect some protection for the messages that pass through the HA. 8.5. Binding Update Message This is a message from the MN to the CN that finally updates the tables necessary for Route Optimization to work. This message may either be a part of an authentication protocol or or a part of the MIPv6 protocol (such as a Binding Update Option as curí rently defined in MIPv6 [1]). The reason why it may be necessary to keep the BU in the authentication protocol is that if that protocol does not create any BSAs or keys, then it is impossible to show that the BU received within MIPv6 was somehow related to the successful authentication performed in another protocol. If a solution does not provide a BSA, then the Binding Update must be a part of the authentication protocol itself. J. Arkko Expires May 2002 [Page 8] INTERNET-DRAFT RO Sec Frame 14 November 2001 8.6. Home Address Option Check A mechanism is needed for CNs to determine whether a packet with a Home Address Option can be accepted [14]. The mechanism is responsible for implementing the requirement R9, and indirectly responsible for fullfilling requirement R2. Requirement R2 says that we should not demand any security support for non-RO nodes. The worry with HAO is circumventing ingress filtering. Given these facts, it seems that the only possible spoofing control mechanisms are the following: (a) Use of Home Address Option is always possible. (b) Use of Home Address Option is only possible in the conjunction of existing Binding Cache Entries (BCEs). Given R1 (protecting other nodes) implies that all CNs MUST use some form of authentication for Binding Updates. Given this, allowing the use of the HAO only with an existing BCEs limits the circumventing of ingress filtering to nodes that have performed this authentication. Whether (a) or (b) is appropriate depends largely on whether you believe Denial-of-Service attacks can be launched too easily if the HAO circumvents ingress filtering. 8.7. Protocol Details How should the "weak" authentication protocol look like in terms of actual representation? There are a number of issues to consider: - Should there be some common format that various solutions use? This seems like unnecessary complexity. Hopefully, we can agree on a single protocol that becomes standardized, and any external rules on how the protocols should look like would just add to the length and complexity of the protocol messages. However, it will be necessary to distinguish protocols from each other in case they have to updated later. This can be achieved by reserving a MIPv6 BU suboption number or an UDP port number for the protocol. - The protocol should not use a large amount of number space from the MIPv6 suboptions. This will also ensure that the protocol isn't too tightly coupled to other information MIPv6 uses in its messages. - Is the protocol a part of of MIPv6 BUs or not? Current "weak" authentication protocols are typically defined as suboptions in Bindí ing Updates. Public key mechanisms such as SUCV or CAM require passing a complete public key. Some methods use additionally Diffie-Hellman [15] in order to generate session keys, and Diffie-Hellman also requires passing a large integer. The maximum IPv6 option length, howí ever, limits passing such data as options or suboptions. The maximum length of an option is 255 bytes, or 2040 bits excluding any other data in the protocol. If both a public key and a Diffie-Hellman value needs to be passed, the limit is 1020 bits. These values are just about enough for current security, but seem low in view of future J. Arkko Expires May 2002 [Page 9] INTERNET-DRAFT RO Sec Frame 14 November 2001 developments. They also preclude the use of the same long key for both MIPv6 and other purposes. Therefore, it seems likely that at least some protocols will run independent of the MIPv6 options. - If the protocol is carried by something else than IPv6 options, should ICMP, UDP or TCP be used? It seems that UDP is an obvious choice. TCP isn't desired due to the number of extra roundtrips necesí sary for the handshaking. ICMP and UDP are still sufficient because the messages can't be long enough to require fragmentation. Finally, firewalls and IPsec policy engines can generally deal better with UDP port numbers than ICMP operations. 9. Example Solutions A minimal solution is given in [10]. It contains only the mandatory "weak" authentication mechanism, using the simplest method i.e. return routability and little else: no BSAs, no "strong" authentication, is a separate protocol from MIPv6, implements the Binding Update message as a part of the authentication protocol. This solution could be extended to support "strong" authentication either by setting IPsec policies to require PKI authentication on this separate protocol, or on all IPv6 traffic. Benefits of the minimal solution include simplicity, and ease of analysis. A more advanced solution is given in [16]. This provides a "weak" authentication mechanism using the "strongest weak" methods i.e. Denial-of-Service protection through return routability, authenticaí tion through the SUCV/CAM property, and session key generation through Diffie-Hellman. A BSA is desirable in this solution. The solution could be extended to support "strong" authentication either by using the IPSec SAs as BSAs and keying them also from IKE, or by requiring all IPv6 traffic to use IPsec. Benefits of this and other similar more advanced solutions are that stronger security guarantees can be given, and in some cases (but not in all!) less signaling messages are needed. An AAA-based solution could be used in a cellular network, for instance. In this solution, Route Optimization is not offered at all to the Global Internet. However, the nodes within the cellular network are allowed to communicate with each other in an optimized manner, using a "strong" mechanism based on a communication with the AAA infrastructure. 10. Future Work Obviously, the purpose of this draft is not to discuss the detailed technical solutions for e.g. "weak" authentication. Much work is needed on that area, as well as on security analysis of various soluí tions. The possible relationships of Binding Update protection on the MN - HA link versus protection on the MN - CN link haven't been sufficiently discussed yet. J. Arkko Expires May 2002 [Page 10] INTERNET-DRAFT RO Sec Frame 14 November 2001 The author of this draft is not very happy about the terminology for "weak" and "strong" authentication, and is searching for better terms. 11. Acknowledgments The author wishes to thank Tuomas Aura, Erik Nordmark, Pekka Nikander, Phil Roberts, Basavaraj Patil, Mike Roe, Greg O'Shea, Hesham Soliman, and Karim El-Malki for interesting discussions in this problem space. This document is largely in debt to Tuomas Aura and his work in [12], and Erik Nordmark and his work in [10]. 12. References [1] D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- mobileip-ipv6-14.txt. Work In Progress, IETF, July 2001. [2] P. Nikander, D. Harkins, B. Patil, P. Roberts, E. Nordmark, T. Narten, A. Mankin, "Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6", draft-team-mobileip- mipv6-sec-reqts-00.txt. Work In Progress, IETF, July 2001. [3] D. Harkins and D. Carrel, "The Internet Key Exchange", RFC 2409, November 1998. [4] P. Nikander, C. Perkins, "Binding Authentication Key Establishment Protocol for Mobile IPv6", draft-perkins-bake-01.txt. Work In Progress, IETF, July 2001. [5] G. Montenegro, C. Castelluccia, "SUCV Identifiers and Addresses", draft-montenegro-sucv-01.txt. Work In Progress, IETF, July 2001. [6] M. Thomas, D. Oran, "Home Agent Cookies for Binding Updates", draft-thomas-mobileip-ha-cookies-00.txt. Work In Progress, IETF, July 2001. [7] P. Nikander, "An Address Ownership Problem in IPv6", draft-nikaní der-ipng-address-ownership-00.txt. Work In Progress, IETF, February 2001. [8] S. Kent, R. Atkinson, "Security Architecture for the Internet Proí tocol" RFC 2401, BBN Corp, @Home Network, November 1998. [9] G. O'Shea, M. Roe, "Child-proof authentication for MIPv6 (CAM)". Computer Communications Review, April 2001. [10] E. Nordmark, "Securing MIPv6 BUs using return routability", draft-nordmark-mobileip-bu3way-00.txt. Work In Progress, IETF, Novemí ber 2001. [11] J. Arkko, "Issues in Protecting MIPv6 Binding Updates", draft- arkko-mipv6-bu-security-00.txt. Work In Progress, IETF, October 2001. [12] T. Aura, J. Arkko, "MIPv6 BU Attacks and Defenses", draft-aura- mipv6-bu-attacks-00.txt. Work In Progress, IETF, November 2001. J. Arkko Expires May 2002 [Page 11] INTERNET-DRAFT RO Sec Frame 14 November 2001 [13] G. Montenegro, "MIPv6 Security: Assessment of Proposals", draft- montenegro-mipv6-seceval-00.txt. Work In Progress, IETF, November 2001. [14] P. Savola, "Security of IPv6 Routing Header and Home Address Options", draft-savola-ipv6-rh-ha-security-00.txt. Work In Progress, IETF, October 2001. [15] Diffie, W., and Hellman M., "New Directions in Cryptography", IEEE Transactions on Information Theory, V. IT-22, n. 6, June 1977. [16] M. Roe, G. O'Shea, T. Aura, J. Arkko, "Authentication of Mobile IPv6 binding updates and acknowledgments", draft-roe-mobileip- updateauth-01.txt, November 2001. 13. Author's Address Jari Arkko Oy LM Ericsson Ab 02420 Jorvas Finland Phone: +358 40 5079256 (mobile) +358 9 2992480 (office) EMail: Jari.Arkko@ericsson.com J. Arkko Expires May 2002 [Page 12]