ECRIT T. Taylor Internet-Draft (Editor) Nortel Expires: January 13, 2007 H. Tschofenig Siemens H. Schulzrinne Columbia U. M. Shanmugam Siemens July 12, 2006 Security Threats and Requirements for Emergency Call Marking and Mapping draft-ietf-ecrit-security-threats-03.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 January 13, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document reviews the security threats associated with: Taylor, et al. Expires January 13, 2007 [Page 1] Internet-Draft ECRIT Security Requirements July 2006 o the marking of signalling messages to indicate that they are related to an emergency; and o the process of mapping from locations to Universal Resource Identifiers (URIs) pointing to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Marking, Mapping, and the Emergency Call Routing Process . . . 5 4. Objectives of Attackers . . . . . . . . . . . . . . . . . . . 6 5. Potential Attacks . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Attacks Involving the Emergency Identifier . . . . . . . . 7 5.2. Attacks Against or Using the Mapping Process . . . . . . . 7 5.2.1. Attacks Against the Emergency Response System . . . . 7 5.2.2. Attacks To Prevent a Specific Individual From Receiving Aid . . . . . . . . . . . . . . . . . . . . 9 5.2.3. Attacks To Gain Information About an Emergency . . . . 9 6. Security Requirements Relating To Emergency Marking and Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Taylor, et al. Expires January 13, 2007 [Page 2] Internet-Draft ECRIT Security Requirements July 2006 1. Introduction Legacy telephone network users can summon help for emergency services such as ambulance, fire and police using a well known number (e.g., 911 in North America, 112 in Europe). A key factor in the handling of such calls is the ability of the system to determine caller location and to route the call to the appropriate Public Safety Answering Point (PSAP) based on that location. With the introduction of IP-based telephony and multimedia services, support for emergency calling via the Internet also has to be provided. As one of the steps to achieve this, an emergency marker is being defined that can be attached to call signalling to indicate that the call relates to an emergency. In addition, a protocol is being developed to allow a client entity to submit a location and receive a URI pointing to the applicable PSAP for that location. Attacks against the PSTN have taken place for decades. The Internet is seen as an even more hostile environment. Thus it is important to understand the types of attacks that might be mounted against the infrastructure providing emergency services, and to develop security mechanisms to counter those attacks. While this can be a broad topic, the present document restricts itself to attacks on the mapping of locations to PSAP URIs and attacks based on emergency marking. This document is organized as follows: Section 2 describes basic terminology. Section 3 briefly describes how emergency marking and mapping fit within the process of routing emergency calls. Section 4 describes some motivations of attackers in the context of emergency calling, Section 5 describes and illustrates the attacks that might be used, and Section 6 lists the security-related requirements that must be met if these attacks are to be mitigated. Taylor, et al. Expires January 13, 2007 [Page 3] Internet-Draft ECRIT Security Requirements July 2006 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], with the qualification that unless otherwise stated they apply to the design of the mapping protocol, not its implementation or application. The terms call taker, mapping service, emergency caller, emergency identifier, mapping, mapping client, mapping server, mapping protocol, and Public Safety Answering Point (PSAP) are taken from [I-D.ecrit-requirements]. The term "location information" is taken from RFC 3693 [RFC3693]. The term "emergency caller's device" designates the IP host closest to the emergency caller in the signalling path between the emergency caller and the PSAP. Examples include an IP phone running SIP, H.323, or a proprietary signalling protocol, a PC running a soft client, or an analogue terminal adapter or a residential gateway controlled by a softswitch. Taylor, et al. Expires January 13, 2007 [Page 4] Internet-Draft ECRIT Security Requirements July 2006 3. Marking, Mapping, and the Emergency Call Routing Process This memo deals with two topics relating to the routing of emergency calls to their proper destination. The first is the marking of call signalling to enable entities along the signalling path to recognize that a particular signalling message is associated with an emergency call. Signalling containing the emergency identifier may be given priority treatment, special processing, and/or special routing. The first goal of emergency call routing is to ensure that any emergency call is routed to a PSAP. Preferably the call is routed to the PSAP responsible for the caller's location, since misrouting consumes valuable time while the call taker locates and forwards the call to the right PSAP. As described in [I-D.ecrit-requirements], mapping is part of the process of achieving this preferable outcome. In brief, mapping involves a mapping client, a mapping server, and the protocol that passes between them. The protocol allows the client to pass location information to the mapping server and to receive back a URI which can be used to direct call signalling to a PSAP. Since mapping requires location information for input, when and where the location information is acquired imposes constraints upon when mapping can be done and which devices can act as mapping clients. The key distinction in "when" is before the emergency or during the emergency. The key distinction in "where" is at the emergency caller's device or at another device in the signalling path between the emergency caller and the PSAP. The mapping client can be the device that acquires the location information or any device downstream of that point. It is even possible for a PSAP itself to initiate mapping, to determine whether an arriving call should be handled by a call taker at that PSAP or should be proxied to another PSAP. Taylor, et al. Expires January 13, 2007 [Page 5] Internet-Draft ECRIT Security Requirements July 2006 4. Objectives of Attackers Attackers may direct their efforts either against a portion of the emergency response system or against an individual. Attacks against the emergency response system have three possible objectives: o to deny system services to all users in a given area. The motivation may range from thoughtless vandalism, to wide-scale criminality, to terrorism. One interesting variant on this motivation is the case where a victim of a large emergency hopes to gain faster service by blocking others' competing calls for help. o to gain fraudulent use of services, by using an emergency identifier to bypass normal authentication, authorization, and accounting procedures; o to divert emergency responders to non-emergency sites. This memo has not identified any attacks within its intended scope that achieve this objective, so it will not be mentioned further. Attacks against an individual fall into two classes: o attacks to prevent an individual from receiving aid; o attacks to gain information about an emergency that can be applied either against an individual involved in that emergency or to the profit of the attacker. Taylor, et al. Expires January 13, 2007 [Page 6] Internet-Draft ECRIT Security Requirements July 2006 5. Potential Attacks 5.1. Attacks Involving the Emergency Identifier The main attack possibility involving the emergency identifier is to use it to bypass normal procedures in order to achieve fraudulent use of services. An attack of this sort is possible only if the following conditions are true: a. The attacker is the emergency caller. b. The call routing system assumes that the emergency caller's device signals the correct PSAP URI for the caller's location. c. The call enters the domain of a service provider, which accepts it without applying normal procedures for authentication and authorization because the signalling carries the emergency identifier. d. The service provider routes it according to the called address (e.g., SIP Request-URI), without verifying that this is the address of a PSAP (noting that a URI by itself does not indicate the nature of the entity it is pointing to). If these conditions are satisfied, the attacker can bypass normal service provider authorization procedures for arbitrary destinations, simply by reprogramming the emergency caller's device to add the emergency identifier to non-emergency call signalling. Most probably in this case, the call signalling will not include any location information, or there could be location information, but it is false. An attacker wishing to disrupt the emergency call routing system may use a similar technique to target components of that system for a denial of service attack. The attacker will find this attractive to reach components that handle emergency calls only. Flooding attacks are the most likely application of the technique, but it may also be used to identify target components for other attacks by analyzing the content of responses to the original signalling messages. 5.2. Attacks Against or Using the Mapping Process This section describes classes of attacks involving the mapping process that could be used to achieve the attacker goals described in Section 4. 5.2.1. Attacks Against the Emergency Response System This section considers attacks intended to reduce the effectiveness Taylor, et al. Expires January 13, 2007 [Page 7] Internet-Draft ECRIT Security Requirements July 2006 of the emergency response system for all callers in a given area. If the mapping operation is disabled, then the emergency caller's device might not have the correct PSAP URI. As a consequence, the probability that emergency calls are routed to the wrong PSAP is increased. In the worst case the emergency caller's device might not be able to obtain a PSAP URI at all. Routing to the wrong PSAP has a double consequence: emergency response to the affected calls is delayed, and PSAP call taker resources outside the immediate area of the emergency are consumed due to the extra effort required to redirect the calls. Alternatively, attacks that cause the client to receive a URI that does not lead to a PSAP have the immediate effect of causing emergency calls to fail. Three basic attacks on the mapping process can be identified: denial of service, impersonation of the mapping server, or corruption of the mapping database. Denial of service can be achieved in several ways: o by a flooding attack on the mapping server; o by taking control of the mapping server and either preventing it from responding or causing it to send incorrect responses; or o by taking control of a router through which the mapping queries and responses pass and using that control to block them. An adversary may also attempt to modify the mapping protocol signaling messages. Additionally, the adversary may be able to replay past communication exchanges to fool an emergency caller by returning incorrect results. In an impersonation attack, the attacker induces the mapping client to direct its queries to a host under the attacker's control rather than the real mapping server. Impersonation itself is an issue for mapping server discovery rather than for the mapping protocol directly. However, the mapping protocol may allow impersonation to be detected, thereby preventing acceptance of responses from an impersonating entity and possibly triggering a more secure discovery procedure. Corruption of the mapping database cannot be mitigated directly by mapping protocol design. The mapping protocol may have a role to play in analysis of which records have been corrupted, once that corruption has been detected. Beyond these attacks on the mapping operation itself, it is possible to use mapping to attack other entities. One possibility is that mapping clients are misled into sending mapping queries to the target of the attack instead of the mapping server. Prevention of such an attack is an operational issue rather than one of protocol design. Taylor, et al. Expires January 13, 2007 [Page 8] Internet-Draft ECRIT Security Requirements July 2006 The other possible attack is one where the the mapping server is tricked into sending responses to the target of the attack through spoofing of the source address in the query. 5.2.2. Attacks To Prevent a Specific Individual From Receiving Aid If an attacker wishes to deny emergency service to a specific individual the mass attacks described in Section 5.2.1 will obviously work provided that the target individual is within the affected population. Except for the flooding attack on the mapping server, the attacker can in theory limit these attacks to the target, but this requires extra effort that the attacker is unlikely to expend. It is more likely, if the attacker is using a mass attack but does not wish it to have too broad an effect, that it is used for a carefully limited period of time. If the attacker wants to be selective, however, it may make more sense to attack the mapping client rather than the mapping server. This is particularly so if the mapping client is the emergency caller's device. The choices available to the attacker are similar to those for denial of service on the server side: o a flooding attack on the mapping client; o taking control of a router through which the mapping queries and responses pass and using that control to block or modify them. Taking control of the mapping client is also a logical possibility, but raises no issues for the mapping protocol. 5.2.3. Attacks To Gain Information About an Emergency This section discusses attacks used to gain information about an emergency. The attacker may be seeking the location of the caller (e.g., to effect a criminal attack). Alternatively, the attacker may be seeking information that could be used to link an individual (the caller or someone else involved in the emergency) with embarrassing information related to the emergency (e.g., "Who did the police take away just now?"). Finally, the attacker could be seeking to profit from the emergency, perhaps by offering his or her services (e.g., news reporter, lawyer aggressively seeking new business). The primary information that interceptions of mapping requests and responses will reveal are a location, a URI identifying a PSAP, and the addresses of the mapping client and server. The location information can be directly useful to an attacker if the attacker has high assurance that the observed query is related to an emergency involving the target. The other pieces of information may provide Taylor, et al. Expires January 13, 2007 [Page 9] Internet-Draft ECRIT Security Requirements July 2006 the basis for further attacks on emergency call routing, but because of the time factor, are unlikely to be applicable to the routing of the current call. However, if the mapping client is the emergency caller's device, the attacker may gain information that allows for interference with the call after it has been set up or for interception of the media stream between the caller and the PSAP. Taylor, et al. Expires January 13, 2007 [Page 10] Internet-Draft ECRIT Security Requirements July 2006 6. Security Requirements Relating To Emergency Marking and Mapping This section describes the security requirements which must be fulfilled to prevent or reduce the effectiveness of the attacks described in Section 5. The requirements are presented in the same order as the attacks. From Section 5.1: Attack: fraudulent calls. Requirement: for calls which meet conditions a) to c) of Section 5.1, the service provider's call routing entity MUST verify that the destination address (e.g., SIP Request-URI) presented in the call signalling is that of a PSAP. Attack: use of emergency identifier to probe in order to identify emergency call routing entities. Requirement: topology hiding SHOULD be applied to call signalling returned to the emergency caller, so that the identity of intermediate routing entities is not disclosed. The obvious exception is where these entities are already visible to the caller. Note that there is little point in hiding the PSAP itself. From Section 5.2.1: Attack: flooding attack on the mapping client, mapping server, or a third entity. Requirement: The mapping protocol MUST NOT create new opportunities for flooding attacks, including amplification attacks. Attack: insertion of interfering messages. Requirement: The protocol MUST permit the mapping client to verify that the response it receives is responding to the query it sent out. Attack: man-in-the-middle alteration of messages. Requirement: The protocol or the system within which it is implemented MUST maintain request and response integrity. Attack: impersonation of the mapping server. Requirement: the security considerations for any discussion of mapping server discovery MUST address measures to prevent impersonation of the mapping server. Taylor, et al. Expires January 13, 2007 [Page 11] Internet-Draft ECRIT Security Requirements July 2006 Requirement: the protocol or the system within which it is implemented MUST permit the mapping client to authenticate the source of mapping responses. Attack: corruption of the mapping database. Requirement: the security considerations for the mapping protocol MUST address measures to prevent database corruption by an attacker. Requirement: the protocol SHOULD include information in the response that allows subsequent correlation of that response with internal logs that may be kept on the mapping server, to allow debugging of mis-directed calls. One example of a way to meet this requirement would be by means of an opaque parameter in the returned URI. From Section 5.2.2: no new requirements. From Section 5.2.3: Attack: snooping of location and other information. Requirement: the protocol or the system within which it is implemented MUST maintain confidentiality of the request and response. Taylor, et al. Expires January 13, 2007 [Page 12] Internet-Draft ECRIT Security Requirements July 2006 7. Security Considerations This document addresses security threats and security requirements. Therefore, security is considered throughout this document. Taylor, et al. Expires January 13, 2007 [Page 13] Internet-Draft ECRIT Security Requirements July 2006 8. Acknowledgements The writing of this document has been a task made difficult by the temptation to consider the security concerns of the entire personal emergency calling system, not just the specific pieces of work within the scope of the ECRIT Working Group. Hannes Tschofenig performed the initial security analysis for ECRIT, but it has been shaped since then by the comments and judgement of the ECRIT WG at large. At an earlier stage in the evolution of this document, Stephen Kent of the Security Directorate was asked to review it and provided extensive comments which led to a complete rewriting of it. Brian Rosen, Roger Marshall, Andrew Newton, and most recently, Spencer Dawkins, Kamran Aquil, and Ron Watro have also provided detailed reviews of this document at various stages. The authors thank them. Taylor, et al. Expires January 13, 2007 [Page 14] Internet-Draft ECRIT Security Requirements July 2006 9. IANA Considerations This document does not require actions by the IANA. Taylor, et al. Expires January 13, 2007 [Page 15] Internet-Draft ECRIT Security Requirements July 2006 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 10.2. Informative References [I-D.ecrit-requirements] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", March 2006. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. Taylor, et al. Expires January 13, 2007 [Page 16] Internet-Draft ECRIT Security Requirements July 2006 Authors' Addresses Tom Taylor Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada Email: taylor@nortel.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany Email: Hannes.Tschofenig@siemens.com Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA Phone: +1 212 939 7042 Email: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs Murugaraj Shanmugam Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany Email: murugaraj.shanmugam@siemens.com Taylor, et al. Expires January 13, 2007 [Page 17] Internet-Draft ECRIT Security Requirements July 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. Taylor, et al. Expires January 13, 2007 [Page 18]