Network Working Group V. Narayanan Internet-Draft Qualcomm, Inc. Intended status: Best Current L. Dondeti Practice QUALCOMM, Inc. Expires: January 10, 2008 C. Vogt Ericsson T. Clancy LTS July 9, 2007 Security Requirements for IP Mobility Protocols draft-vidya-ip-mobility-sec-reqs-01 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 January 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes security requirements to take into account in designing IP mobility protocols and deploying IP mobility services. We consider threat models applicable to different service models and Narayanan, et al. Expires January 10, 2008 [Page 1] Internet-Draft Requirements for Secure Mobility July 2007 deployment scenarios and provide guidance on prioritizing the security requirements. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Functional Goals of IP Mobility . . . . . . . . . . . . . . . 5 4. Brief Summary of the Threat and Vulnerability Analysis . . . . 5 5. Security Requirements and Recommendations . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Narayanan, et al. Expires January 10, 2008 [Page 2] Internet-Draft Requirements for Secure Mobility July 2007 1. Introduction Mobile users desire to run their communication sessions undisturbed while moving between points of Internet attachment. At the same time, they want to stay reachable so as to be able to receive communication requests from other users. IP mobility protocols satisfy these desires with two, conceptually independent services: Session continuity is provided by an "indirection function", which maps the IP addresses used at protocol layers above IP onto the IP addresses at which the mobile node and its correspondent node are currently reachable. Reachability is provided by a "localization function", which tracks a roaming mobile node's current IP address and brokers session establishment for correspondent nodes that attempt to contact the mobile node. The indirection and localization functions could become a target of attack if the mobility protocol failed to protect them appropriately. Potential attacks range from impersonation and unauthorized access to services, to flooding and denial of service [1]. Most of these attacks endanger stationary and mobile nodes alike. This document provides guidelines for protocol engineers to design secure mobility protocols. The document consists of two parts. The first is a list of security requirements that protocol engineers must address. The second discusses the applicability of these requirements for different deployment scenarios. 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 RFC 2119 [2]. In addition, this document uses the following terms (these terms are specified in the threats document also and perhaps elsewhere; the definitions will eventually be removed from all but one of the documents to avoid duplication): IP Mobility IP mobility refers to changes in the IP point of attachment of a node. As a consequence of this change, a node may obtain a different (topologically meaningful) address. The result is that a mobile node or network, as it moves, may obtain different topologically meaningful IP addresses that it can use for IP-based communications. Some protocols allow the nodes to maintain the same IP address as they move across different IP points of attachment. Narayanan, et al. Expires January 10, 2008 [Page 3] Internet-Draft Requirements for Secure Mobility July 2007 IP Mobility Protocol An IP mobility protocol provides transparency to layers above IP from the changes in the IP addresses resulting from IP mobility. In particular, such protocols allow nodes to continue IP communications independent of the current IP point of attachment and to preserve established communications across any corresponding IP address changes. A key element of an IP mobility protocol is to detect movement and do what is needed to allow communication continuity. Mobility Agent A mobility agent is an entity maintaining state about the location of the mobile nodes. Examples of mobility agents include the Mobile IP Home Agent (HA), the HMIP MAP, the FMIP PAR, NetLMM LMA, MIP6 RO-enabled CN, etc. Mobility Facilitator This refers to an entity other than a mobility agent that may play a role in facilitating the mobility management of the MN. Examples of such mobility facilitators include the NetLMM MAG, MIP4 FA, HMIP AR, etc. Mobility Provider Mobility provider collectively refers to the mobility agent and facilitators. Mobility Recipient The mobility recipient is the entity receiving the IP mobility service. The MN is always the mobility recipient and hence these terms may be used interchangeably. Anchor Address This is used to refer to the relatively unchanging IP address of the MN. Examples of anchor addresses are the MIP HoA, HMIP RCoA, FMIP PCoA, NetLMM RHoA, etc. This is usually the address corresponding to which state is maintained in the mobility agent. The permanence and scope of the address may vary depending on the protocol. Narayanan, et al. Expires January 10, 2008 [Page 4] Internet-Draft Requirements for Secure Mobility July 2007 Transient Address This is used to refer to the relatively frequently changing IP address of the MN. Examples of transient addresses are the MIP CoA, HMIP RCoA, FMIP NCoA, NetLMM PLCoA, etc. This is usually the address that points to the present location of the MN. 3. Functional Goals of IP Mobility The mobility provider is generally interested in ensuring that the service is only provided to authorized entities. It is also in the interest of the mobility provider to ensure that the service is provided as intended. Providing IP mobility service entails the maintenance of state for all mobile nodes served, in order to maintain the mapping of the anchor and transient addresses of those nodes. The mobile nodes, as recipients of the mobility service, are interested in having undisrupted and correct IP mobility service. In other words, the mobile node must be able to obtain the service as long as it can reach the mobility agent. Reachability between the mobile node and the mobility agent is generally available as long as all the critical resources and a subset of non-critical resources are available. Critical and non- critical assets are described in the threats document and briefly documented below. Hence, the one of the most important functional goals of IP mobility is to ensure that as long as the mobile node and mobility agent may communicate, mobility service is available. 4. Brief Summary of the Threat and Vulnerability Analysis The mobility threat and vulnerability analysis of "IP Mobility - Threat Analysis" can be summarized as follows: Asset Classification Mobility agents, mobile nodes, security infrastructure entities are classified as critical assets; mobility facilitators, network infrastructure entities such as routers and links are classified as non-critical assets. The idea is that as long as a subset of uncompromised non-critical assets is available to facilitate communication between a mobile node and a mobility agent, the mobile node can signal its new transient address to the mobility agent. Narayanan, et al. Expires January 10, 2008 [Page 5] Internet-Draft Requirements for Secure Mobility July 2007 Equivalence of Off-path Attacks to On-path Attacks While there are some types of DoS attacks feasible by an on-path attacker such as dropping, modification or replay of packets, the same effect can be realized by an off-path attacker that can create incorrect state at the mobility agent. Attacks on Mobility Agents Creation of state by unauthenticated nodes or creation of incorrect state by authenticated nodes at a mobility agent consumes address binding state and more importantly, possibly creates large amounts of spurious traffic through the mobility agent. Attacks on Mobile Nodes An assortment of attacks are possible on mobile nodes including redirection of traffic, DDoS attacks, or a combination of those attacks. Attacks on Other Nodes The threats to mobile nodes are also applicable to other nodes which are reachable through the mobility domain. 5. Security Requirements and Recommendations Domino Effect Mitigation Following the functional goals of IP mobility, the mobility service must be available as long as the critical resources are available and there is reachability between the mobile node and mobility agent. As such, non-critical resources are expected to be independent of each other. Compromise of one or more non- critical entities MUST NOT compromise the other non-critical entities or the mobility session via other non-critical entities. In particular, it must not be possible for a compromised non- critical entity to impersonate the mobile node or cause redirection or DDoS attacks on it. Protection of Signaling Messages Signaling messages between a mobile node and a mobility agent MUST be integrity and replay protected; the mobility agent MUST also be able to verify the origin of the signaling message unambiguously. Narayanan, et al. Expires January 10, 2008 [Page 6] Internet-Draft Requirements for Secure Mobility July 2007 Channel protection as specified above is necessary to mitigate any on-path attackers modifying the signaling between the mobile node and the mobility agent. The data origin authentication protection property of the secure channel may be used to ensure that the entity that created a binding entry is the entity that may modify that entry. Authorization to Signal Mobility A mobility agent MUST only accept mobility signaling for a mobile node from authorized nodes. For node-based mobility, this authorization translates to allowing only the mobile node to be capable of creating or modifying mobility bindings. For network- based mobility, this is applicable to nodes that act as proxies to mobile nodes in maintaining address binding at mobility agents. There are two components to such entity authorization - one part is to ensure that a given entity is allowed to signal mobility and the other part is to ensure that the mobile node is actually present at the location. For node-based mobility, these two aspects are tied to authorizing the mobile node. For network- based mobility, these are different aspects. The mobility agent MUST be able to verify whether the node signaling mobility is authorized to signal mobility. Authorizing the mobility signaling using the appropriate security association ensures that the entity performing the signaling is allowed to do so for a node in the mobility domain. However, the mobility agent SHOULD also be able to verify whether the mobile node is in fact present in the corresponding mobility domain. In some cases, the mobility agent may be able to determine if the mobile node is actually associated with the actual entity that performed the mobility signaling. In some other cases, only a domain-level check can be performed. Without entity authorization, compromise of the entity leads to compromise of any mobility session in the domain. IP Address Authorization IP Mobility deals with two addresses, the anchor address that remains the same within the mobility domain and the transient address that corresponds to the current location of the mobile node. Narayanan, et al. Expires January 10, 2008 [Page 7] Internet-Draft Requirements for Secure Mobility July 2007 Anchor IP Address Authorization Without anchor IP address authorization, an entity will be able to redirect traffic belonging to some other node. Due to such redirection, a legitimate node (mobile or fixed) will be denied IP (and IP mobility) service. Authorization for "anchor" address, e.g., MIP HoA, FMIP pCoA, HMIP RCoA, NETLMM RHoA, etc., ensures IP mobility service is only available for authorized nodes and protects against redirection, MiTM, and DoS attacks. A mobility agent receiving a address binding request MUST be able to verify whether the anchor address in the request belongs to the mobile node for which the request was sent. Transient IP Address Authorization By registering an invalid transient address, an attacker will be able to direct its traffic on to other nodes. Authorization for "transient" address, e.g., MIP CoA, FMIP nCoA, HMIP LCoA, NETLMM PLCoA, etc., prevents such DDoS attacks. A mobility agent receiving a address binding request SHOULD be able to verify whether the transient address in the request corresponds to the current location of the mobile node for which the request was sent. Requirements on Key Management and Key Managers Key management protocols may be used to setup the security associations (SA) required to protect signaling messages. These protocols MUST authenticate the parties to the authentication and tie the SA to the identities of the parties. Key managers or distributors and trust anchors are critical assets; they must be protected as such since the failure or compromise of a key distributor or trust anchor may result in disrupting the mobility service irreparably. Keys MUST be scoped for a given purpose; the same key MUST NOT be used for different purposes. Narayanan, et al. Expires January 10, 2008 [Page 8] Internet-Draft Requirements for Secure Mobility July 2007 Keys MUST be scoped to the signaling endpoints; in other words, the keys MUST NOT be known to non-critical assets or other entities that do not need it to perform their role. Privacy Requirements Privacy of nodes can be provided at several levels. The goal of an IP mobility protocol should be tied to being able to provide privacy at the IP level for a mobile node. A mobile node SHOULD be able to move across IP points of attachment without entities in the home, visited or other networks being able to track it. This includes being able to hide the actual transient address changes from correspondent or other nodes and being able to hide the anchor to transient address changes from entities in the home or visited domains. Note that the mobility agent is an entity that always needs to be trusted to know the mapping of the anchor and transient addresses . 6. Security Considerations This document specifies the security requirements for IP mobility service and protocol design. The requirements are based on a threat and vulnerability analysis. The eventual goal is to identify various operational scenarios and provide guidance on the order of the requirements listed in this document. 7. IANA Considerations This document has no actions for IANA. 8. Acknowledgments 9. Normative References [1] Narayanan, V. and L. Dondeti, "IP Mobility Protocols - Threat Analysis", draft-vidya-ip-mobility-threats-00 (work in progress), February 2007. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Narayanan, et al. Expires January 10, 2008 [Page 9] Internet-Draft Requirements for Secure Mobility July 2007 Authors' Addresses Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Lakshminath Dondeti QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Christian Vogt Ericsson Research, NomadicLab Hirsalantie 11 02420 Jorvas Finland Email: christian.vogt@ericsson.com T. Charles Clancy DoD Laboratory for Telecommunications Sciences 8080 Greenmead Drive College Park, MD 20740 USA Email: clancy@LTSnet.net Narayanan, et al. Expires January 10, 2008 [Page 10] Internet-Draft Requirements for Secure Mobility July 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). Narayanan, et al. Expires January 10, 2008 [Page 11]