--- 1/draft-ietf-ecrit-security-threats-04.txt 2007-08-24 19:12:06.000000000 +0200 +++ 2/draft-ietf-ecrit-security-threats-05.txt 2007-08-24 19:12:06.000000000 +0200 @@ -1,23 +1,23 @@ -ECRIT T. Taylor -Internet-Draft (Editor) Nortel -Expires: October 18, 2007 H. Tschofenig - Siemens +ECRIT T. Taylor, Ed. +Internet-Draft Nortel +Expires: February 22, 2008 H. Tschofenig + Nokia Siemens Networks H. Schulzrinne - Columbia U. + Columbia University M. Shanmugam - Siemens - April 16, 2007 + Detecon + August 21, 2007 Security Threats and Requirements for Emergency Call Marking and Mapping - draft-ietf-ecrit-security-threats-04.txt + draft-ietf-ecrit-security-threats-05.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 @@ -28,37 +28,34 @@ 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 October 18, 2007. + This Internet-Draft will expire on February 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract - This document reviews the security threats associated with: - - 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. + This document reviews the security threats associated with the + marking of signalling messages to indicate that they are related to + an emergency, and 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 @@ -99,42 +96,45 @@ 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. + marking. Verification of the truthfulness of a reported incident by + the PSAP operator and various other attacks against the PSAP + infrastructure related to the usage of faked location information are + outside the scope of the document. 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. 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]. + [I-D.ietf-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. @@ -150,22 +150,23 @@ an emergency call. Signalling containing the emergency identifier may be given priority treatment, special processing, and/or special routing. 3.2. Mapping An important 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. + call to the right PSAP. As described in + [I-D.ietf-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. @@ -189,23 +190,25 @@ 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. + o to divert emergency calls to non-emergency sites. This is a form + of denial of service attack similar to the first item but quite + likely more confusing for the caller itself since it expects to + talk to a PSAP operator but instead gets connected to someone + else. 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. 5. Potential Attacks @@ -429,21 +432,21 @@ 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 A8: snooping of location and other information. - Requirement R9: the protocol or the system within which it is + Requirement R9: the protocol and the system within which it is implemented MUST maintain confidentiality of the request and response. 7. Security Considerations This document addresses security threats and security requirements. Therefore, security is considered throughout this document. 8. IANA Considerations @@ -457,73 +460,82 @@ 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. + We would like to thank the Donald Eastlake for his review on behalf + of the Security Area Directorate and Christian Vogt for his review as + part of the General Area Review Team. + + Finally, we would like to think Jari Arkko, Jon Peterson, and Russ + Housley for their IETF Last Call comments. + 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. 10.2. Informative References - [I-D.ecrit-requirements] + [I-D.ietf-ecrit-requirements] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", - March 2006. + draft-ietf-ecrit-requirements-13 (work in progress), + March 2007. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. Authors' Addresses - Tom Taylor + Tom Taylor (editor) Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada - Email: taylor@nortel.com + Email: tom.taylor@rogers.com Hannes Tschofenig - Siemens + Nokia Siemens Networks Otto-Hahn-Ring 6 - Munich, Bayern 81739 + Munich, Bavaria 81739 Germany - Email: Hannes.Tschofenig@siemens.com + Email: Hannes.Tschofenig@nsn.com + URI: http://www.tschofenig.com Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 - USA + US - Phone: +1 212 939 7042 - Email: schulzrinne@cs.columbia.edu - URI: http://www.cs.columbia.edu/~hgs + Phone: +1 212 939 7004 + Email: hgs+ecrit@cs.columbia.edu + URI: http://www.cs.columbia.edu Murugaraj Shanmugam - Siemens - Otto-Hahn-Ring 6 - Munich, Bayern 81739 + Detecon International GmbH + Oberkasseler str 2 + Bonn, NRW 53227 Germany - Email: murugaraj.shanmugam@siemens.com + Email: murugaraj.shanmugam@detecon.com 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