--- 1/draft-ietf-ecrit-security-threats-02.txt 2006-07-12 22:12:30.000000000 +0200 +++ 2/draft-ietf-ecrit-security-threats-03.txt 2006-07-12 22:12:30.000000000 +0200 @@ -1,23 +1,23 @@ ECRIT T. Taylor Internet-Draft (Editor) Nortel -Expires: December 27, 2006 H. Tschofenig +Expires: January 13, 2007 H. Tschofenig Siemens H. Schulzrinne Columbia U. M. Shanmugam Siemens - June 25, 2006 + July 12, 2006 Security Threats and Requirements for Emergency Call Marking and Mapping - draft-ietf-ecrit-security-threats-02.txt + 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 @@ -28,41 +28,41 @@ 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 December 27, 2006. + 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: 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 idnetified threats, this document establishes a set of - security requirements for the the mapping protocol and for the - handling of emergency-marked calls. + 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 @@ -84,23 +84,23 @@ 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 must be defined that can + 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 must be developed allowing a + 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 @@ -179,33 +179,33 @@ 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. + 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; + profit of the attacker. 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: @@ -222,21 +222,21 @@ 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. + 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 @@ -403,26 +403,25 @@ 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: to provide an audit trail, the protocol SHOULD allow the - inclusion of an identifier in its response that indicates which - database records were used in preparing the response. This - identifier SHOULD be encrypted along with randomizing information - such as date/time, to minimize the information provided to an - attacker in mapping responses. + 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. @@ -436,23 +435,23 @@ 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 and - Kmaran Aquil have also provided detailed reviews of this document at - various stages. The authors thank them. + 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. 9. IANA Considerations This document does not require actions by the IANA. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate