ECRIT H. Tschofenig Internet-Draft Siemens Expires: June 22, 2006 H. Schulzrinne Columbia U. M. Shanmugam Siemens T. Taylor Nortel December 19, 2005 Security Threats and Requirements for Emergency Calling draft-taylor-ecrit-security-threats-01.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 June 22, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document reviews the security threats to routing of emergency calls through the IP network to Public Safety Answering Points (PSAPs). It establishes a set of security requirements for the Tschofenig, et al. Expires June 22, 2006 [Page 1] Internet-Draft ECRIT Security Requirements December 2005 entities and processes involved in performing this call routing. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Emergency call routing system overview . . . . . . . . . . . . 5 4. Motivations of attackers . . . . . . . . . . . . . . . . . . . 8 5. Potential attacks . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Attacks to prevent a specific individual from receiving aid . . . . . . . . . . . . . . . . . . . . . . 9 5.1.1. Attacks against the Emergency Caller's device . . . . 9 5.1.2. Attacks against call signalling and the initial call routing entity . . . . . . . . . . . . . . . . . 10 5.1.3. Attacks against the process of location acquisition . 10 5.1.4. Attacks against the process of Mapping the location to an Emergency Address . . . . . . . . . . . 11 5.2. Attacks to gain information about an emergency . . . . . . 11 5.3. Attacks to gain fraudulent use of ASP/VSP services . . . . 12 5.4. Attacks against the emergency response system . . . . . . 12 6. Security requirements relating to emergency call routing . . . 14 6.1. Requirements for interface (1), self-provided Location Information . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Requirements for interface (2), configuration by Location Server . . . . . . . . . . . . . . . . . . . . . 14 6.3. Requirements for interface (3), Emergency Caller's Device as Mapping Client . . . . . . . . . . . . . . . . . 15 6.4. Requirements for interface (4), outbound call signalling to call routing entities . . . . . . . . . . . 16 6.5. Requirements for interface (5), call routing element as Mapping Client . . . . . . . . . . . . . . . . . . . . 16 6.6. Requirements for interface (6), between the final call routing entity and the PSAP . . . . . . . . . . . . . . . 16 6.7. Requirements for interface (7), direct routing to PSAP . . 17 6.8. Requirements for interface (8), acquisition of Location Information by a call routing entity . . . . . . 17 6.9. Additional requirements on the Directory . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Tschofenig, et al. Expires June 22, 2006 [Page 2] Internet-Draft ECRIT Security Requirements December 2005 1. Introduction PSTN users can summon help for emergency services such as ambulance, fire and police using a well known unique 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. In addition, the system must, whenever possible, deliver the caller's location and the calling number to the PSAP. With the introduction of IP-based telephony and multimedia services, support for emergency calling via the Internet also has to be provided. To achieve this, a number of protocols and protocol extensions need to interwork successfully. Attacks against the PSTN (many focussing on free calling) 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. In view of the mandate of the ECRIT Working Group, the present document restricts itself to attacks on the routing of emergency calls. The analysis assumes IP connectivity from the emergency caller's device all the way through to the PSAP. This document is organized as follows: Section 2 describes basic terminology. Section 3 describes the different components involved in routing an emergency call, how they may be organized, and how the system operates if fully secured from the attacks described in subsequent parts of the document. Section 4 describes some motivations of attackers in the context of ECRIT, 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. Tschofenig, et al. Expires June 22, 2006 [Page 3] Internet-Draft ECRIT Security Requirements December 2005 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]. Application (Voice) Service Provider (ASP/VSP), Call Taker, Directory Service, Emergency Address, Emergency Caller, Emergency Identifier, Emergency Services Routing Proxy (ESRP), Internet Attachment Provider (IAP), Mapping, Mapping Client, Mapping Server, and Public Safety Answering Point (PSAP) are taken from [I-D.ecrit-requirements]. Location Server and Location Information are 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 an access gateway controlled by a softswitch. The term "configuration time" refers to any point in time prior to the emergency when configuration data (in particular, Location Information and possibly the Emergency Address) is added to or updated within the Emergency Caller's Device. Tschofenig, et al. Expires June 22, 2006 [Page 4] Internet-Draft ECRIT Security Requirements December 2005 3. Emergency call routing system overview As described in [I-D.ecrit-requirements] and schematically shown in Figure 1, the system for routing an emergency call consists of the following components: o the Emergency Caller's Device; o a source of information regarding the location of the Emergency Caller's Device (the Location Server); o the emergency call routing support component, consisting of one or more call routing elements (e.g., SIP proxies, media gateway controllers, call signalling protocol interworking units) possibly including an Emergency Services Routing Proxy (ESRP); o a Directory Service capable of providing the emergency address corresponding to a given caller's location, one implementation of which uses mapping servers with associated mapping databases; o the Public Safety Answering Point (PSAP) having jurisdiction over the location associated with the call. The numbered interfaces shown in Figure 1 are the targets of our analysis. Some of these interfaces represent alternative architectures. For example, interface (1) comes into play if the Location Information is configured manually into the Emergency Caller's Device or the Emergency Caller's Device can provide location itself (e.g., because of built-in GPS). Interface (2) allows the Emergency Caller's Device to acquire Location Information from a Location Server. Finally, it may be one of the entities in the emergency call routing support component that acquires the location over interface (8). Figure 1 also illustrates the actors and thus the potential trust relationships involved in the call routing process. The actors consist of: o the emergency caller; o the Emergency Caller's Device, which may be configured by the Emergency Caller, by the Internet Attachment Provider (IAP), and/or by some third party, particularly the Application (Voice) Service Provider (ASP/VSP); o the Internet Attachment Provider, typically providing some of the configuration for the Emergency Caller's Device and potentially the operator of the Location Server; Tschofenig, et al. Expires June 22, 2006 [Page 5] Internet-Draft ECRIT Security Requirements December 2005 o one or more Internet Service Providers (not shown), providing IP connectivity from the internet access point to the PSAP; o one or more Application (Voice) Service Providers (ASPs/VSPs) providing the call routing and session setup services requested in the emergency call; o the Directory Service provider, potentially a separate entity; and o the PSAP, which passes calls to the Call Taker. Location Information +-----------------+ |(1) | Internet | +-----------+ v | Attachment | | | +-----------+ | Provider | | Directory | | | | | | | | Emergency |<---+-----------------+-->| | | Caller | | (3) | +-----------+ | |<---+-------+ | ^ +-----------+ (2)| +----|---------+------+ | ^ | | Location | | | | | | Server <-+ | | | +--+--------------+ |(8) | | (5) | | +-----------v+ | | | (4) | |Emergency | | | +--------------+--->|Call Routing|<--+---+ | | |Support | | | | +------------+ | | | ^ | | | (6) | +----+--+ | (7) | +------->| | +--------------+--------------->| PSAP | | | | |Application +----+--+ |(Voice) | |Service | |Provider | +---------------------+ Figure 1: Emergency call routing framework In the absence of an attack, any call for which the signalling is marked with an Emergency Identifier is successfully routed to a Call Taker in the PSAP having jurisdiction over the caller's location. For this to happen, the following individual steps must occur: Tschofenig, et al. Expires June 22, 2006 [Page 6] Internet-Draft ECRIT Security Requirements December 2005 1. The caller's location must be acquired. This may happen at configuration time or at the time of the call. The source of the Location Information may be the Emergency Caller's Device itself (e.g., from embedded GPS capability) or the Location Information may be manually configured into the device. However, this analysis concerns itself mostly with the case where the source of the Location Information is a Location Server as defined in RFC 3693 [RFC3693]. Based on that assumption, successful operation requires that the receiver of the Location Information (either the Emergency Caller's Device or a call routing element) acquire that data in timely fashion. The source of the Location Information received must be an authorized source and the integrity of the data must be assured in transit. 2. The location must be mapped to an Emergency Address. This will most likely happen at the time of the call, but may happen at configuration time if the receiver of the Location Information was the Emergency Caller's Device. This step again must happen in timely fashion. The Mapping Client must be able to ensure that it is receiving the information from a valid Mapping Server, that the address it receives is in response to its query and not some other one, and that the information has not been altered in transit. Moreover, the success of the operation requires that the integrity of the Mapping database from which the server drew its response must be maintained. 3. The timeliness, integrity and privacy of call signalling must be ensured as it passes between the emergency caller's device and the PSAP. NOTE - a confidentiality requirement applies to the association of a location with an emergency (e.g., within call signalling) or with an individual. The location data per se is not confidential. Tschofenig, et al. Expires June 22, 2006 [Page 7] Internet-Draft ECRIT Security Requirements December 2005 4. Motivations of attackers Attackers may direct their efforts either against an individual or against a portion of the emergency response system. Attacks against an individual fall into three 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; o attacks by the caller to gain fraudulent use of ASP/VSP services, by using an Emergency Identifier to bypass normal authentication, authorization, and accounting procedures. Attacks against the emergency response system are aimed either at denying system services to all users in a given area, or at diverting emergency responders to non-emergency sites. The latter motivation falls outside the scope of this analysis. Tschofenig, et al. Expires June 22, 2006 [Page 8] Internet-Draft ECRIT Security Requirements December 2005 5. Potential attacks This section describes classes of attacks that could be used to achieve the attacker goals described in the previous section. 5.1. Attacks to prevent a specific individual from receiving aid This section discusses blocking attacks directed at a specific individual. The more general blocking attacks described in Section 5.4 will also operate to the same effect. They are discussed separately because the separation may be useful when weighing the priority for implementing specific defenses. Blocking attacks against an individual can be directed against the Emergency Caller's device, against the call signalling, or against the initial call routing entity (e.g., SIP proxy or B2BUA) handling that signalling. They may also be directed against the process of acquisition of Location Information or Mapping of that Location Information to an Emergency Address, if done at call time. (Attacks could be directed further along in the call routing chain, closer to the PSAP, but such attacks are more likely to be deployed against all users within the area servued by the PSAP, rather than against an individual.) The possible attacks along all of these lines are spelled out in the remainder of this section. 5.1.1. Attacks against the Emergency Caller's device The definition of "Emergency Caller's Device" given in Section 2 covers a variety of cases. Clearly the vulnerability of the Emergency Caller's Device to specific attacks will vary with the particular case. What follows should be read with this reservation in mind. If the Emergency Caller's Device depends on configuration data to make an effective emergency call, and the relevant part of that configuration is acquired from the network, the device may be vulnerable to corrupting messages (e.g., viruses or worms) sent by the attacker. Examples of the sort of configuration data that could be corrupted are the address of the initial call routing entity (e.g., SIP outbound proxy), the location of the device (if this is acquired or configured beforehand), or a mapped Emergency Address (if that is also acquired or configured beforehand). Alternatively, the attacker might direct a large volume of traffic at the Emergency Caller's Device in an attempt to overload it. Tschofenig, et al. Expires June 22, 2006 [Page 9] Internet-Draft ECRIT Security Requirements December 2005 5.1.2. Attacks against call signalling and the initial call routing entity Sending a flood of messages to the Emergency Caller's device could also have the effect of blocking call signalling by overloading the link between the device and the network. The attacker may attempt to block or corrupt the call signalling along the path to the initial call routing entity by seizing control of a bridge or an IP router. The attacker may attempt to seize control of the initial call routing entity and cause it to ignore or mis-handle signalling from the Emergency Caller's device. The attacker could attempt to block the handling of the emergency call through a flooding attack on the initial call routing entity. This, of course, would likely affect many people, not just the Emergency Caller. Finally, the attacker could cause call signalling to be misdirected by impersonating the initial call routing entity. 5.1.3. Attacks against the process of location acquisition Location acquisition could be implemented in a number of ways. The phrasing of the attack descriptions provided below attempts to focus on the specific nature of the attacks without getting into the details of the implementation. Nevertheless, the list which follows describes several alternative approaches to implementation: o The Emergency Caller's Device acquires the Location Information at configuration time and includes it in subsequent call signalling. o The Emergency Caller's Device acquires the address of the Location Server at configuration time, acquires the actual Location Information at call time, and includes it in call signalling. o The caller's device acquires a reference pointing to the Location Server at configuration time and includes this reference in call signalling. The Emergency Service Routing Proxy (which could be the initial call routing entity) uses this reference to acquire the Location Information, which it then uses for Mapping and inserts into call signalling. o The initial call routing entity is configured with the address of the Location Server, acquires the Location Information at call time, and inserts it into call signalling. Tschofenig, et al. Expires June 22, 2006 [Page 10] Internet-Draft ECRIT Security Requirements December 2005 Bearing these possibilities in mind, here are some potential attacks: o If the Emergency Caller's Device receives its location from the network at configuration time (e.g., via DHCP), the attacker could try to compromise that process by attacking or impersonating the Location Server. In general this does not seem likely to be a very effective attack, since configuration time may come long before any emergency call, and failures in configuration have a good chance of being detected and remedied. o If location acquisition happens at call time, the attacker has similar choices to those listed against call signalling and the initial call routing entity. The attacker might intercept the location query or response, seize control of the Location Server, flood the Location Server, or impersonate the Location Server. o Upon detecting a query for location, the attacker can send a response from a different location query hoping that it will be received and accepted by the querying entity before the correct response. Alternatively it can modify the response. 5.1.4. Attacks against the process of Mapping the location to an Emergency Address The Mapping could be done at configuration time, and the Emergency Address configured in the Emergency Caller's device along with its location. It might be possible for an attacker to interfere with this process, but the objections are the same as those pertaining to attacks on the acquisition of location at configuration time. If Mapping occurs at call time, the attacker has similar choices to those for interfering with the acquisition of location. The attacker has one further option: to corrupt the Mapping database so that the wrong answer is given for the Emergency Caller's location. 5.2. 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). 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, "ambulance chaser"). The primary means of attack during call routing is capture of the Tschofenig, et al. Expires June 22, 2006 [Page 11] Internet-Draft ECRIT Security Requirements December 2005 content of signalling information. Depending on the specific motivation, the capture must happen close to the Emergency Caller or may happen anywhere along the call routing chain, particularly near or at the PSAP. In most cases, the attacker will have a greater interest in the content of the conversation following upon call setup than in the signalling itself. The exception is the first case cited above, where the attacker is trying to locate the Emergency Caller. In this case, the caller's location, any information identifying the caller, and the call-back address all need to be protected. It is possible that the Location Server transmits Location Information along with information (e.g., IP address) identifying the Emergency Caller's device. In this case, capture of the transmitted data may provide information that can be combined with information from other attacks, or the information may be used to carry out other attacks. 5.3. Attacks to gain fraudulent use of ASP/VSP services This section discusses attacks whereby the Emergency Caller is hoping to bypass normal procedures to achieve free use of ASP/VSP services. A simple example is where the call signalling carries an Emergency Identifier and thus is allowed to proceed without authentication for billing. To be attractive to an attacker, the call needs to be addressed (and connected) to a non-emergency destination of the attacker's choice. This is especially possible if the system assigns the responsibility for Mapping to the Emergency Caller's Device and it is located on subscriber premises. A more complicated attack would be to insert an entry into the Mapping database or tamper with the Mapping Server, so that a particular location gets mapped to a destination of the attacker's choosing. The attacker could then make unaccounted-for calls to that destination by including the location in call signalling. 5.4. Attacks against the emergency response system This section considers attacks intended to reduce the effectiveness of the emergency response system for all callers in a given area. The motivation may range from thoughtless vandalism, to wide-scale criminality, to terrorism. The attacks listed here cover the "mechanical" possibilities. In addition, one can easily imagine attacks whereby callers exhaust response resources by describing non- existent emergencies. Perhaps the most obvious attack in support of this goal is a flooding attack directed at the PSAP. The attacker may also impersonate a PSAP, causing emergency calls to be misdirected, without immediate Tschofenig, et al. Expires June 22, 2006 [Page 12] Internet-Draft ECRIT Security Requirements December 2005 detection. Another effective attack would be to deny the use of the Directory. This could be done in several ways: by a flooding attack on the Mapping Servers for the region, by corruption of the Mapping Database, or by impersonation of a Mapping Server. Tschofenig, et al. Expires June 22, 2006 [Page 13] Internet-Draft ECRIT Security Requirements December 2005 6. Security requirements relating to emergency call routing This section describes the security requirements which must be fulfilled to prevent or blunt the effectiveness of the attacks described in the previous chapter. The scope of these requirements is limited to those specific to emergency calls, that is, the scope of the ECRIT Working Group. Thus the focus will be on requirements concerning the Location Information, the Mapping process, the Mapping database, prevention of disclosure, and prevention of fraud. Moreover, the focus is on requirements for security mechanisms as opposed to policies. Other documents may address appropriate policies for elements of the emergency response system once the mechanisms are in place. The organization of this section is based on Figure 1. The requirements are identified for each successive interface shown in that figure. This will make for some repetition in the details, but lead to a more precise analysis of alternative architectures. 6.1. Requirements for interface (1), self-provided Location Information Interface (1) pertains to the supply of Location Information either by equipment (e.g., GPS) built directly into the Emergency Caller's Device, or by manual entry. The security requirements specified for this interface are those needed to help ensure the the validity of the Location Information as a basis for emergency call routing. 1. If the Location Information is configured into the Emergency Caller's Device by manual entry, such entry SHOULD require authentication and authorization of the person providing the entry. This helps to deter a class of fraudulent attacks discussed in Section 5.3. 6.2. Requirements for interface (2), configuration by Location Server This section considers requirements when Location Information is acquired by the Emergency Caller's Device from a Location Server. This could happen either at configuration time or at call time. OPEN ISSUE: How does the Emergency Caller's Device acquire the address of the Location Server, and what requirements attend that acquisition process? 1. The protocol for obtaining the Location Information from the Location Server MUST offer authentication of the Location Server entity, integrity protection of the Location Information, and protection against replay. These requirements address attacks described in Section 5.1.3. Tschofenig, et al. Expires June 22, 2006 [Page 14] Internet-Draft ECRIT Security Requirements December 2005 2. If Location Information is transmitted in conjunction with information which would allow a third party to identify the caller's device, the transmission of that data MUST offer confidentiality. This requirement addresses an attack described in Section 5.1.3. 3. If the Location Information is acquired at configuration time, an automatic audit or refresh of that information SHOULD also be performed at regular intervals to prevent the corruption of the configured data (and to ensure that the device has up-to-date information). This requirement addresses the device data corruption attack in Section 5.1.1. 4. Particularly if Location Information is acquired at call time, the protocol used for location acquisition MUST NOT create new opportunities for flooding attacks associated with this application. This requirement addresses an attack mentioned in Section 5.1.3. 6.3. Requirements for interface (3), Emergency Caller's Device as Mapping Client This section considers requirements when the Emergency Caller's Device acts as a Mapping Client to map the Location Information to the corresponding Emergency Address. This could happen either at configuration time or at call time. OPEN ISSUE: How does the Emergency Caller's Device acquire the address of the Mapping Server, and what requirements attend that acquisition process? 1. The mapping protocol MUST include authentication of the Mapping Server entity, integrity protection of the mapping query and response, and protection against replay of the response. These requirements address attacks described in Section 5.1.4 and Section 5.4. 2. The Mapping protocol MUST NOT create new opportunities for flooding attacks. This addresses an attack mentioned in Section 5.1.4 and Section 5.4. 3. If the Mapping is done at configuration time, it SHOULD be repeated at regular intervals to prevent the corruption of the configured data (and to ensure that the device has up-to-date information). This requirement addresses the device data corruption attack in Section 5.1.1. Tschofenig, et al. Expires June 22, 2006 [Page 15] Internet-Draft ECRIT Security Requirements December 2005 6.4. Requirements for interface (4), outbound call signalling to call routing entities This section considers the requirements for the transfer of call signalling between the Emergency Caller's Device and a call routing element as opposed to the PSAP directly. 1. Emergency call signalling on this interface MUST be provided with confidentiality. This addresses attacks described in Section 5.2. 2. Emergency call signalling on this interface MUST be provided with integrity protection. This addresses an attack described in Section 5.1.2. 6.5. Requirements for interface (5), call routing element as Mapping Client This section considers the requirements when a call routing element between the Emergency Caller's Device and the PSAP invokes the Mapping service. The requirements are very similar to those where Mapping is done at the Emergency Caller's Device. 1. The mapping protocol MUST include authentication of the Mapping Server entity, integrity protection of the mapping query and response, and protection against replay of the response. These requirements address attacks described in Section 5.1.4 and Section 5.4. 2. The Mapping protocol MUST NOT create new opportunities for flooding attacks. This addresses an attack mentioned in Section 5.1.4 and Section 5.4. 6.6. Requirements for interface (6), between the final call routing entity and the PSAP This section considers requirements on the final call signalling hop, between a call routing entity and the PSAP. It also includes requirements that, strictly speaking, may apply to intermediate call routing entities preceding the final one before the PSAP. 1. Emergency call signalling on this interface MUST be provided with confidentiality. This addresses attacks described in Section 5.2. 2. It MUST be possible for the final call routing entity to authenticate the PSAP entity. This addresses an impersonation attack described in Section 5.4. Tschofenig, et al. Expires June 22, 2006 [Page 16] Internet-Draft ECRIT Security Requirements December 2005 3. If any call routing entity would normally authenticate the call for billing or authorization but does not do so because the Emergency Identifier is present in the signalling, the call routing entity MUST ensure that the call is routed to a PSAP. This requirement is already captured in [I-D.ecrit-requirements]. It addresses attacks described in Section 5.3. 6.7. Requirements for interface (7), direct routing to PSAP This section considers requirements on the call signalling interface when the Emergency Caller's Device routes the call directly to the PSAP. These requirements are a blend of the requirements for interfaces (3) and (5). 1. Emergency call signalling on this interface MUST be provided with confidentiality. This addresses attacks described in Section 5.2. 2. Emergency call signalling on this interface MUST be provided with integrity protection. This addresses an attack described in Section 5.1.2. 3. It MUST be possible for the Emergency Caller's Device to authenticate the PSAP entity. This addresses an impersonation attack described in Section 5.4. 6.8. Requirements for interface (8), acquisition of Location Information by a call routing entity This section considers the requirements when a call routing entity in the emergency call routing support acquires the Location Information, rather than the Emergency Caller's Device. The requirements are similar to those on interface (2). 1. The protocol for obtaining the Location Information from the Location Server MUST offer authentication of the Location Server entity, integrity protection of the Location Information, and protection against replay. These requirements address attacks described in Section 5.1.3. 2. If Location Information is transmitted in conjunction with information which would allow a third party to identify the caller's device, the transmission of that data MUST offer confidentiality. This requirement addresses an attack described in Section 5.1.3. 3. The protocol used for location acquisition MUST NOT create new opportunities for flooding attacks associated with this Tschofenig, et al. Expires June 22, 2006 [Page 17] Internet-Draft ECRIT Security Requirements December 2005 application. This requirement addresses an attack mentioned in Section 5.1.3. 6.9. Additional requirements on the Directory This section addresses requirements on the "back-end" interface into the directory, by means of which the Mapping Database is populated and updated. The interface is not shown separately in Figure 1. 1. If a protocol is specified for performing updates to the Mapping Database, that protocol MUST include integrity protection, MUST permit authentication and authorization of the source of the update, and MUST NOT create new opportunities for flooding attacks. These requirements address attacks on the Mapping Database described in Section 5.1.4, Section 5.3 and Section 5.4. Tschofenig, et al. Expires June 22, 2006 [Page 18] Internet-Draft ECRIT Security Requirements December 2005 7. Security Considerations This document addresses security threats and security requirements. Therefore, security is considered throughout this document. Tschofenig, et al. Expires June 22, 2006 [Page 19] Internet-Draft ECRIT Security Requirements December 2005 8. Acknowledgements Hannes Tschofenig performed the initial security analysis for ECRIT. The authors would like to thank Stephen Kent for his extensive comments on the previous issue of this document, which led to a complete rewriting of it. Tschofenig, et al. Expires June 22, 2006 [Page 20] Internet-Draft ECRIT Security Requirements December 2005 9. IANA Considerations This document does not require actions by the IANA. Tschofenig, et al. Expires June 22, 2006 [Page 21] Internet-Draft ECRIT Security Requirements December 2005 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] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", October 2005. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. Tschofenig, et al. Expires June 22, 2006 [Page 22] Internet-Draft ECRIT Security Requirements December 2005 Authors' Addresses 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 Tom Taylor Nortel 1852 Lorraine Ave Ottawa, Ontario K1H 6Z8 Canada Email: taylor@nortel.com Tschofenig, et al. Expires June 22, 2006 [Page 23] Internet-Draft ECRIT Security Requirements December 2005 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 (2005). 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. Tschofenig, et al. Expires June 22, 2006 [Page 24]