ECRIT H. Tschofenig Internet-Draft Siemens Expires: January 19, 2006 H. Schulzrinne Columbia U. M. Shanmugam TUHH July 18, 2005 Security Threats and Requirements for Emergency Calling draft-tschofenig-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 January 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract With the increasing interest to replace parts of the public switched telephone network (PSTN) with the IP-based network, the core functionality of PSTN such as emergency services, has to be offered when using IP-based technologies. Since the PSTN and the Internet follow different design principles their architecture is quite Tschofenig, et al. Expires January 19, 2006 [Page 1] Internet-Draft Threats and Req. for Emergency July 2005 different. This fact has to be considered and security threats for an IP-based emergency environment have to be re-evaluated. This document investigates the potential threats against the IP based emergency architecture. It focuses on some analysis of threats for both the end hosts and the infrastructure that aims to support emergency services. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivations of Attackers of ECRIT . . . . . . . . . . . . . 5 4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Threats . . . . . . . . . . . . . . . . . . . . . . 9 5.1 Denial of Service Attacks . . . . . . . . . . . . . . . . 9 5.2 Call Identity Spoofing . . . . . . . . . . . . . . . . . . 9 5.3 Location Spoofing . . . . . . . . . . . . . . . . . . . . 10 5.4 Impersonating a PSAP . . . . . . . . . . . . . . . . . . . 10 5.5 Signaling Message Modification . . . . . . . . . . . . . . 11 5.6 Modification of the Emergency Call . . . . . . . . . . . . 11 5.7 Loss of confidentiality . . . . . . . . . . . . . . . . . 11 5.8 Replay Attack . . . . . . . . . . . . . . . . . . . . . . 11 5.9 Corrupting Configuration Information . . . . . . . . . . . 12 5.10 Corrupting Database Information . . . . . . . . . . . . 12 6. Security Requirements . . . . . . . . . . . . . . . . . . . 13 6.1 Denial of Service Attacks . . . . . . . . . . . . . . . . 13 6.2 Call Identity Spoofing . . . . . . . . . . . . . . . . . . 14 6.3 Location Spoofing . . . . . . . . . . . . . . . . . . . . 14 6.4 Impersonating a PSAP . . . . . . . . . . . . . . . . . . . 16 6.5 Signaling Message Modification . . . . . . . . . . . . . . 16 6.6 Replay Attack . . . . . . . . . . . . . . . . . . . . . . 17 6.7 Loss of confidentiality . . . . . . . . . . . . . . . . . 17 6.8 Modification of the Emergency Call . . . . . . . . . . . . 17 6.9 Corrupting Configuration Information . . . . . . . . . . . 17 6.10 Corrupting Database Information . . . . . . . . . . . . 18 6.11 Location Validation and Verification . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1 Normative References . . . . . . . . . . . . . . . . . . . 22 9.2 Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . 23 Tschofenig, et al. Expires January 19, 2006 [Page 2] Internet-Draft Threats and Req. for Emergency July 2005 1. Introduction This document provides an overview of security mechanisms and motivations for using them in the VoIP-based emergency services. 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 in Europe). With the introduction of IP-based telephony support for emergency service also has to be provided. A number of protocols and protocol extensions need to interwork in order to provide emergency functionality. Since the Internet is hostile place, it is important to understand the security threats for emergency services. Otherwise, an adversary can use the infrastructure to place fraudulent calls, mount denial of service attacks, etc. This document focuses on the security threats and security requirements for the IP-based emergency service infrastructure only without interaction with PSTN infrastructure elements. A few discussions within this document are related to emergency handling but solutions will not be developed as part of the ECRIT working group. Hence, the are included mainly for completeness and to point to the need to investigate additional aspects. Depending on the chosen protocols (for the emergency call itself, for directory access related to emergency call routing, for obtaining location information from the network, etc.) various solutions might also already be available to fulfill these security requirements and to address the threats appropriately. This document is organized as follows: Section 2 describes basic terminology, Section 5 illustrates security threats and Section 6 lists security requirements. Tschofenig, et al. Expires January 19, 2006 [Page 3] Internet-Draft Threats and Req. for Emergency July 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]. Emergency Caller, Public Safety Answering Point (PSAP), Access Infrastructure Provider, Application (Voice) Service Provider, Emergency Call Taker, etc. is taken from [I-D.schulzrinne-ecrit- requirements]. Additionally, we use the following terms throughout the document: Emergency Call Routing Support: This term refers to entities that route the emergency call to the appropriate PSAP based on information like location information, language, etc. If SIP is used as a protocol for session setup and call routing, for example, then this entity would correspond to a SIP proxy. Directory: This entity refers to a distributed directory protocol. DNS is one example of such as distributed directory but there are other protocols that might fulfill the requirements listed in [I-D.schulzrinne-ecrit-requirements] for such a protocol. Asserted Location Information: The term asserted location information refers to the property that the recipient of such an object is able to verify that it was generated by a particular party that is authorized todo so. Tschofenig, et al. Expires January 19, 2006 [Page 4] Internet-Draft Threats and Req. for Emergency July 2005 3. Motivations of Attackers of ECRIT The most obvious motivation for an attacker, in the context of emergency, is to hinder user(s) not to avail the emergency service. This can be done by variety of means such as impersonating a PSAP, directory server, forging or spoofing location, identity etc., However,there are several other potential motivations that cause concern. Attackers might also wish to learn the nature emergency information by eavesdropping an emergency call in order to reuse or extract the relevant information that might cause potential problems to the end hosts such as replay attacks, revealing the identity of the user. Attackers may want to prevent or delay an emergency caller by modifying some information in the message typically modifying the loation of the caller, while placing the emergency call. In some cases, this will lead the emergency repsonders to dispatch the services to the spoofed ara and might not be available to the other callers. It might also be possible for an attacker to impede the users not to reach an appropriate PSAP by corrupting or modifying the location of an end host or the information returned from the mapping protocol. Since the regulatory aspects of the emergency call often does not manadate authentication of the caller, it is easy for an attacker to forge some data(location information) to an PSAP, thereby forcing the emergency responders to dispatch the services, which might cause a denial of service to its legitimate users. Finally, some attackers may simply want to halt the operation of an entire emergency architecture through denial-of-service attacks. Tschofenig, et al. Expires January 19, 2006 [Page 5] Internet-Draft Threats and Req. for Emergency July 2005 4. Basic Actors In order to support emergency services covering a large physical area various infrastructure elements are necessary: Access Infrastructure Providers, Application (Voice) Service Provider, PSAPs as endpoints for emergency calls, directory services or other infrastructure elements that assist in during the call routing and potentially many other entities. This section outlines which entities will be considered in the threat analysis and shows the high level architecture. Location Information +-----------------+ |(1) |Access | +-----------+ v |Infrastructure | | | +-----------+ |Provider | | Directory | | | | (3) | | | | Emergency |<---+-----------------+-->| | | Caller | | (2) | +-----------+ | |<---+-------+ | ^ +-----------+ | +----|---------+------+ | ^ | | Location | | | | | | Information<-+ | | | +--+--------------+ |(8) | | (5) | | +-----------v+ | | | (4) | |Emergency | | | +--------------+--->|Call Routing|<--+---+ | | |Support | | | | +------------+ | | | ^ | | | (6) | +----+--+ | (7) | +------->| | +--------------+--------------->| PSAP | | | | |Application +----+--+ |(Voice) | |Service | |Provider | +---------------------+ Figure 1: Framework Figure 1 shows the interaction between the entities involved in the call. There are a number of different deployment choices, as it can be easily seen from the figure. The following deployment choices need to be highlighted: Tschofenig, et al. Expires January 19, 2006 [Page 6] Internet-Draft Threats and Req. for Emergency July 2005 o How is location information provided to the end host? It might either be known to the end host itself (due to manual configuration or provided via GPS) or available via a third party. Even if location information is known to the network it might be made available to the end host. Alternatively, location information is used as part of call routing and inserted by intermediaries. o Is the Access Infrastructure Provider also the Application (Voice) Service Provider? In the Internet today these roles are typically provided by different entities. As a consequence, the Application (Voice) Service Provider is typically not able to learn the physical location of the Emergency Caller. Please note that the overlapping squares aim to indicate that certain functionality can be collapsed into a single entity. As an example, the Application (Voice) Service Provider might be the same entity as the Access Infrastructure Provider and they might also operate the PSAP. There is, however, no requirement that this must be the case. Additionally it is worth pointing out that end systems might be its own VoSP, e.g., for enterprises or residential users. Below, we describe various interactions between the entities shown in Figure 1 are described: o (1) Location information might be available to the end host itself. o (2) Location information might, however, also be obtained from the Access Infrastructure Provider (e.g., using DHCP or application layer signaling protocols). o (3) The Emergency Caller might need to consult a directory to determine the PSAP that is appropriate for the physical location of the emergency caller (and considering other attributes such as a certain language support by the Emergency Call Takers). o (4) The Emergency Caller might get assistance for emergency call routing by infrastructure elements (referred as Emergency Call Routing Support entities). In case of SIP these enities are proxies. o (5) Individual Emergency Call Routing Support entities might need to consult a directory to determine where to route the emergency call. o (6) The Emergency Call Routing Support entities need to finally forward the call, if infrastructure based emergency call routing Tschofenig, et al. Expires January 19, 2006 [Page 7] Internet-Draft Threats and Req. for Emergency July 2005 is used. o (7) The emergency caller might interact directly with the PSAP without any Emergency Call Routing Support entities. Tschofenig, et al. Expires January 19, 2006 [Page 8] Internet-Draft Threats and Req. for Emergency July 2005 5. Security Threats This section discusses various security threats related to emergency call handling. 5.1 Denial of Service Attacks A (distributed) denial-of-service attack (DoS attack) on a PSAP, for example, might isolate the PSAP from the Internet, for a while, thus unable to receive the emergency calls at that time. Since a particular PSAP is responsible for a certain geopraphical boundary, attacking a single PSAP means denying the service to the entire area (if no other backup PSAP is available). DoS attacks might appear in many different flavors ranging from standard SYN floodings to attacks where a human operator is involved then he has to determine whether a call is in fact a true emergency call. In some cases this might lead the case where the emergency staff (police, ambulance, etc.,) might need to rush to the indicated emergency scene (potentionally an arbitrary location) and will therefore not be available for other rescue assignments during that time. As such, PSAPs can be seen as a particularly valuable target since the consequences of an unreachable PSAP has severe consequences. Attacks against the routing infrastructure enables an adversary to prevent all nodes attached to this network to sent emergency calls. Attacks against entities that assist in the call routing (such as attacks against the directory service) might make it difficult or impossible for emergency call to reach its intended PSAP. 5.2 Call Identity Spoofing If an adversary is able to make emergency calls without the need to disclose its identity (such as a SIP URI or NAI) then prank calls cannot be traced back. If the call is proxy-routed, the PSAP will not see the IP address of the caller in signaling. Additionally, it might be necessary for the Emergency Call Taker to initiate a voice, video or instant messaging exchange towards the Emergency Caller. Trying to find an adversary that placed a crank call is difficult if somebody uses an open 802.11 access point, even if you can find the owner of that access point. This problem is no different than somebody placing an emergency call from a payphone. If the adversary is never authenticated (neither to the PSAP nor to the Access Infrastructure Provider) then it is possible to trace the call back to a make a particular entity accountable. Tschofenig, et al. Expires January 19, 2006 [Page 9] Internet-Draft Threats and Req. for Emergency July 2005 A standard requirement for emergency systems is that emergency calls must also be placed in absence of any authentication. An adversary will typically exploit these weaknesses and he will always find networks that do not perform network access authentication of the user prior to providing network access. As such, the emergency infrastructure cannot neither rely on network access authentication nor on authentication of the caller towards the PSAP or the Application (Voice) Service Provider. It is necessary to point to the fact that authentication in the emergency case might require the authorization procedure to be skipped. For example, in an emergency case it is still possible to authenticate the user of an emergency call but without considering that its credits are exhausted. 5.3 Location Spoofing An adversary might want to made-up faked location information in order to fool the emergency personnel. This is made particularly easy if the location information is provided by the Emergency Caller either via manual configuration or via GPS. Spoofing is more difficult if an entity proving Emergency Call Routing Support inserts location information into emergency call signaling. In this case the adversary needs to route the call via some intermediaries. This is possible since these devices are often, by their nature as IP devices, addressable from an arbitary physical location. The usage of VPN (or other tunneling mechanisms) and proxies further complicates the ability to infer the physical location from the IP address seen by the PSAP. 5.4 Impersonating a PSAP An adversary might pretend to operate a PSAP. When either an end host or an intermediate device wants to determine the PSAP that is responsible for a particular geographical area by sending a query to the directory an adversary might return a faked response. Returning an incorrect response message does not require the adversary to be somewhere along the path. It is sufficient for an adversary to be located in a broadcast medium and the adversary has to reply as soon as a query is observed (if no security protection is utilized). If the response indicates a legitimate but inappropriate (i.e., a PSAP that is authoritive for a different geographical area) then the emergency call interaction will be able to continue but will suffer from delays until the emergency call can be forwarded to the correct PSAP, potentially involving human interaction (by the Emergency Call Taker). Tschofenig, et al. Expires January 19, 2006 [Page 10] Internet-Draft Threats and Req. for Emergency July 2005 5.5 Signaling Message Modification An adversary that is located along the signaling path might modify the content of emergency calls, such as location information or identity information. This might lead to a denial of service attack against the emergency personell, disruption of the emergency call, delayed call setup, etc. An adversary might want to inject signaling messages to terminate or redirect the call to another location. Dropping or delaying signaling messages is also possible for an on-path adversary. Depending on the capability of the signaling protocol the range of possible attacks might have been documented already. 5.6 Modification of the Emergency Call An adversary along the media path might want to modify the data traffic part of the emergency call (voice, video or instant message). An attacker can change the message on-the-fly and fool the PSAP to receive meaningless or bogus messages. The response messages to Emergency Caller might also be subject to change, for example by injecting a recorded failure message. 5.7 Loss of confidentiality An adversary might eavesdrop an emergency call and use the information to future sessions as part of replay attacks. The ability to eavesdrop also allows to learn details about the emergency situation which might be of interest for the press or other media organizations. Please note that the location of the adversary is important regarding the eavesdropped area. For example, an adversary in a WLAN is typically able to see a small amount of traffic due to the coverage area of typical WLAN network. Reavealing the true identity of the user as part of the privacy override mechanism might conflict with the users privacy settings. 5.8 Replay Attack An adversary might want to use eavesdropped information to mount attacks in the future. This might be necessary if information cannot be re-created by the adversary (for example, asserted location information). The ability to replay messages or individual objects the specific property of these messages and objects is important. For example, asserted location information might bind location information and a timestamp with a digital signature together that makes it difficult to reuse this object beyonds its lifetime. Tschofenig, et al. Expires January 19, 2006 [Page 11] Internet-Draft Threats and Req. for Emergency July 2005 [Editor's Note: It is sometimes hard to tell what are real threats and what security threats are addressed already by certain solutions outside the scope of the working group. Addressing all standard security threats is a long process if certain mechanisms are required in an case that largely or completely mitigate against these threats.] 5.9 Corrupting Configuration Information An adversary might override all locally configured emergency numbers. This might be particular problematic if these emergency numbers are dynamically retrieved using some mechanisms. As such, an Emergency Caller would start a call that either leads to a blackhole (as such it is a DoS attack), the Emergency Caller connects to a rogue PSAP or to an inappropriate PSAP. 5.10 Corrupting Database Information An attacker might want to provide emergency callers with wrong information about emergency service contact URIs. An adversary can accomplish this goal in various ways, including message modification, spoofing or corrupting the database. Since the database provides a pointer(e.g., SIP URI) to an appropriate PSAP, care must be taken when retrieving emergency URI. A succesfull forging will lead the user to reach either a false PSAP or to a black hole. Tschofenig, et al. Expires January 19, 2006 [Page 12] Internet-Draft Threats and Req. for Emergency July 2005 6. Security Requirements [Editor's Note: A few requirements below are already addressed by a number of requirements and solution specific documents today. In order to keep the document short it would be reasonable to focus only on the difficult security threats and requiremens for emergency calls rather than enumerating everything that could happen to an emergency call. The working group should decide how to proceed with this particular issue and what threats and requirements should be elaborated in more detail.] Compiling security requirements to address the threats listed in the previous section might is impacted by several constraints: Security mechanisms may lead to a certain performance overhead (e.g., several roundtrips). A certain security infrastructure is required that might lead to deployment problems. For example, end user certificates, certificates for networks, usage of authorization certificate, etc. might need to be deployed before any of these mechanisms are useful. Many of these aspects are related to regulatory and legal requirements that may vary from country to country. Typically, these mechanisms cannot be mandated by an IETF specification. Some of the requirements impose solutions that are out-of-scope of the ECRIT working group. Given the above-listed constraints the requirements that have to be addressed by work that is done within ECRIT have to be highlighted. Other requirements have to be read as 'if you would like to address this threat, then you might want to consider this requirement' rather than 'any solution must address fulfill this requirement'. 6.1 Denial of Service Attacks It is difficult to address all possible denial of service attacks that might lead to disruption of an emergency call since a number of IETF protocols are used in order to provide this functionality. Hence, care must be taken when protocol extensions are developed that the chance for a denial of service attack is not increased. Even without using any security mechanisms (such as authentication and key exchange protocols) some degree of security has to be provided. It is important to understand that the ability to mount DoS attacks must also be considered as part of the architecture work when legal Tschofenig, et al. Expires January 19, 2006 [Page 13] Internet-Draft Threats and Req. for Emergency July 2005 and regulatory requirements are known and need to be fulfilled. 6.2 Call Identity Spoofing A standard requirement to prevent identity spoofing is to authenticate the Emergency Caller. Authentication mechanisms that require multiple roundtrips and as such might delay the call are often not desirable or cannot be mandated. 6.3 Location Spoofing An Emergency Caller might in many cases know its own location information because it was obtained via civic or geospatial location extensions for DHCP, via manual configuration or via GPS. Unfortunately, information provided by the end host is untrustworthy particularly when it is as important as location information. Two approaches have been discussed in the past that place lead to a few requirements: o Location Information is asserted by the Access Infrastructure Provider. As such, the end host might use GPS but uses a protocol to allow the network to assert the location information. This approach also has its limitations if the coverage area of the wireless network is fairly large. o Location Information is added to the emergency call via an Emergency Call Routing Support entity. Depending on the protocol used for call routing and on the properties of this protocol it might be necessary to return the asserted location information to the end host since intermediate nodes might not be allowed to insert objects into the call setup messages (at least not in all parts of the messages, such as bodies). These signaling entities, in general, do not know the physiscal location of the user. Thus, they have to rely on somebody else to actually provide the location, e.g., the Access Infrastructure Provider. As it can be seen from these two options the main difference is based on the type of protocol that is used in the message communication. This has an impact on the semantic and on the availability of certain attributes (such as identities that are used by these protocols) and on deployment constraints. Based on the observation that the Access Infrastructure Provider is closest to the end host and is therefore the most likely entity that knows something about the physical location of the end host it seems to be reasonable to assume that some entity that asserts the location information is actually available in this particular network. In the context of emergency, spoofing can be loosely divided into Tschofenig, et al. Expires January 19, 2006 [Page 14] Internet-Draft Threats and Req. for Emergency July 2005 o wide-area spoofing - users pretend to be in Germany but actually in US. o local-area spoofing - users spoof location information to an extend (few miles). o local-area cloning - users pretend to be in place X if they were actually there, a while ago. The following requirements need to be provided in order for asserted location information to accomplish its goals: o Location Information MUST be integrity protected to prevent modifications by third parties. o The recipient of the asserted location information object MUST be able to determine the party that asserted the location information in order to verify the assertion. As such, authentication of the asserting party (the entity that created the assertion) MUST be provided. o The asserted location information MUST include a timestamp to limit its validity in order to reduce replay attacks. o The recipient of the asserted location information MUST have a way to verify that the asserting party is indeed authorized to create such an assertion. As such, authentication is insufficient if not further authorization decision can be associated to the authenticated identity. o The recipient of the asserted location information SHOULD have a mechanism to determine the Emergency Caller based on the provided assertion. The last bullet deserves further discussion: If some information about the Emergency Caller identity has to be included, which is only for the purpose of traceability then this functionality might not be of general use. This is because an adversary will always find networks that do not authenticate the user prior to providing network access. Furthermore, the goal of a number of network access authentication protocols is to prevent disclosure of the user identity to entities other than to the user's home network. Note that the term 'user idenity' does not require that this identity directly points to the 'real' identity of a user. A court might want to require this identity to be resolved and to determine the user behind this identity. Even if the access network would like to assertain the user's identity as part of the asserted location information it is, in many cases, not even possible for the Access Tschofenig, et al. Expires January 19, 2006 [Page 15] Internet-Draft Threats and Req. for Emergency July 2005 Infrastructure Provider. If the authenticated user identity is not available to the Access Infrastructure Provider then only a few other identities might be useful, such as the IP address or the MAC address. Other identities, such as the Host Identity, might not be available since they are only used by very few protocols. An assertion that indicates the network in combination with the IP and/or MAC address (together with a timestamp) might provide some limited degree of traceability only if the user was authenticated directly to this particular network. Providing the IP address allows some obvious attempts to cheat to be caught. Hence, there is the question whether some identity should be added at all given the potential limitations and the potential small amounts of cut-and-paste attacks. Using end user based authentication in addition to the asserted location information would be helpful (e.g., using end user certificates) but will impose a serious deployment problem. Given the fact that emergency calls must still be allowed even without end user authentication certainly defeats the purpose of these mechanisms. A partical attempt to address some prank calls is to classify emergency calls based on the availability of the provided attributes. If suspicious information is being provided that may well be wrong then additional verification steps need to be taken. For example, if a report of a large fire on a Manhattan street is received then the PSAP may wait to dispatch until it gets a second person to call in. This approach obviously has some limitations as well. 6.4 Impersonating a PSAP The Emergency Caller SHOULD be able to determine conclusively that he has reached an accredited emergency call center. This requirement is meant to address the threat that a rogue, possibly criminal, entity pretends to accept emergency calls and disrupts the emergency infrastructure. o A user agent must be able to authenticate a PSAP. Unlike in the PSTN case IP based networks provide a better opportunity to spoof a PSAP since physical access to the cable plant is required in the PSTN case, while this may not true for the IP case. 6.5 Signaling Message Modification To protect signaling messages against modifications either individual attributes SHOULD be protected (such as location objects) or the entire signaling message communication SHOULD experience end-to-end protection. This requires integrity and replay protection to be Tschofenig, et al. Expires January 19, 2006 [Page 16] Internet-Draft Threats and Req. for Emergency July 2005 applied. Authentication of the data sender and the data receiver SHOULD be provided to prevent a man-in-the-middle attack. 6.6 Replay Attack In order to protect signaling messages (or individual attributes) to be replayed in future protocol sessions integrity and replay protection mechanisms SHOULD be provided. 6.7 Loss of confidentiality In order to prevent leakage of information exchanged during the emergency call (both signaling and data traffic) confidentiality protection SHOULD be provided. The mechanisms to accomplish this functionality are typically different for the data traffic and for the signaling messages and various scenarios, such as hop-by-hop, end-to-middle, middle-to-middle and end-to-end security, need to be considered. Particularly the key management aspects for end-to-end security mechansisms imposes a deployment burden and hence need to be critically analysed in order to determine its applicability in the given context. 6.8 Modification of the Emergency Call To protect a man-in-the-middle attack i.e disallow the adversary to modify or to inject data traffic into the communication between the Emergency Caller and the PSAP, the mechanisms like integrity, replay and data origin authentication SHOULD be provided. Since the signaling messages are used to authenticate the end points and to distribute the required keying material it is necessary that either the key exchange protocol itself and the signaling messages experience appropriate security protection. The term 'appropriate' refers to the given context, the used signaling protocol and the key exchange protocol. Please note that the interactive nature of a voice communication already provides a some degree of protection. However, with the introduction of instant messaging the freshness of the Emergency Call needs to be provided by other means. 6.9 Corrupting Configuration Information Devices SHOULD be assured of the correctness of the local emergency numbers that are automatically configured. If we assume a fixed, global emergency service identifier that requires no configuration and only configure local "traditional" emergency numbers, users are not likely to suddenly dial some random number if a rogue configuration server introduces this as an additional emergency Tschofenig, et al. Expires January 19, 2006 [Page 17] Internet-Draft Threats and Req. for Emergency July 2005 number. The ability to override all locally configured emergency number is of more concern. If the Emergency Caller does not use the infrastructure to route the call to the appropriate PSAP then the security of the directory service is of importance for security. 6.10 Corrupting Database Information If the mapping client i.e., the entity that requests location information using a mapping protocol accepts the emergency contact information from an unauthenticated mapping server i.e., the entity that provides location information, it is highly possible to receive bogus or prank emergency contact URIs. Particularly the caching properties of a distributed directory might be exploited. To ensure the secure retrieval of information, the following properties are assumed: o The maping client MUST be able to authenticate the mapping server. o The interaction between the mapping client and the mapping server MUST be integrity and replay protected. o The mapping server MUST be provide data origin authentication thereby ensuring that the provided data items are indeed from the claimed source. o The mapping server MUST provide information to ensure that it is authoritive for the provided information. 6.11 Location Validation and Verification location validation ensures that an address exists and is mappable to a PSAP. A valid address, however, does not imply that the call actually originated from that location. We refer to location verification as the assurance that the call was placed at the location claimed, including any error margins provided. Verifying a location is generally more difficult than location validation as there is currently no generally trusted service that can vouch for the location of the caller. In some cases, AIPs or ISPs may be able to indicate the location of the caller with high confidence and they may possess cryptographic certificates that are trusted by the PSAP. This may not require a global certification authority (CA), as a regional PSAP typically only deals with a modest number of larger enterprises and thus could obtain their public keys even if self-signed. However, even if the AIP or ISP provides a signed location, it is Tschofenig, et al. Expires January 19, 2006 [Page 18] Internet-Draft Threats and Req. for Emergency July 2005 difficult to ensure that such a signed location object is only used for calls from that location, as it will have to be copied from a location delivery protocol to the call signaling protocol. For example, a third party could obtain such a signed location object and use it elsewhere. Naturally, timestamps will restrict such usage to the order of minutes or hours, depending on how often location information is updated. A PSAP may want to be able to answer the following questions: o Who originally provided this particular location information? o Did the call originate from that particular geospatial or civic address and who says so and how do they know? Tschofenig, et al. Expires January 19, 2006 [Page 19] Internet-Draft Threats and Req. for Emergency July 2005 7. Security Considerations This document addresses security threats and security requirements. Therefore, security is considered throughout this document. Tschofenig, et al. Expires January 19, 2006 [Page 20] Internet-Draft Threats and Req. for Emergency July 2005 8. IANA Considerations This document does not require actions by the IANA. Tschofenig, et al. Expires January 19, 2006 [Page 21] Internet-Draft Threats and Req. for Emergency July 2005 9. References 9.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 9.2 Informative References [I-D.schulzrinne-ecrit-requirements] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", May 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 Technische Universitat Hamburg-Harburg Department of Security in Distributed applications Harburger Schlossstrasse 20 Hamburg-Harburg 21079 Germany Email: murugaraj.shanmugam@tuhh.de Tschofenig, et al. Expires January 19, 2006 [Page 22] Internet-Draft Threats and Req. for Emergency July 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 January 19, 2006 [Page 23]