Network Working Group T. Taylor, Ed. Request for Comments: 5069 Nortel Category: Informational H. Tschofenig Nokia Siemens Networks H. Schulzrinne Columbia University M. Shanmugam Detecon January 2008 Security Threats and Requirements for Emergency Call Marking and Mapping Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
AbstractThis document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to Universal Resource Identifiers (URIs) that point 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.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Marking, Mapping, and the Emergency Call Routing Process . . . 3 3.1. Call Marking . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Objectives of Attackers . . . . . . . . . . . . . . . . . . . 4 5. Potential Attacks . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Attacks Involving the Emergency Identifier . . . . . . . . 5 5.2. Attacks Against or Using the Mapping Process . . . . . . . 5 5.2.1. Attacks Against the Emergency Response System . . . . 6 5.2.2. Attacks to Prevent a Specific Individual from Receiving Aid . . . . . . . . . . . . . . . . . . . . 7 5.2.3. Attacks to Gain Information about an Emergency . . . . 7 6. Security Requirements Relating to Emergency Marking and Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
operator of the truthfulness of a reported incident 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. 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 [RFC5012]. 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.
RFC5012], 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.
Beyond these attacks on the mapping operation itself, it is possible to use mapping to attack other entities. One possibility is that mapping clients are misled into sending mapping queries to the target of the attack instead of the mapping server. Prevention of such an attack is an operational issue rather than one of protocol design. Another possible attack is where the mapping server is tricked into sending responses to the target of the attack through spoofing of the source address in the query. Section 5.2.1 will obviously work provided that the target individual is within the affected population. Except for the flooding attack on the mapping server, the attacker can in theory limit these attacks to the target, but this requires extra effort that the attacker is unlikely to expend. If the attacker is using a mass attack but does not wish to have too broad an effect, it is more likely to attack for a carefully limited period of time. If the attacker wants to be selective, however, it may make more sense to attack the mapping client rather than the mapping server. This is particularly so if the mapping client is the emergency caller's device. The choices available to the attacker are similar to those for denial of service on the server side: o a flooding attack on the mapping client; o taking control of any intermediary node (for example, a router) through which the mapping queries and responses pass, and then using that control to block or modify them. Taking control of the mapping client is also a logical possibility, but raises no issues for the mapping protocol.
The primary information that interceptions of mapping requests and responses will reveal are a location, a URI identifying a PSAP, the emergency service identifier, and the addresses of the mapping client and server. The location information can be directly useful to an attacker if the attacker has high assurance that the observed query is related to an emergency involving the target. The type of emergency (fire, police, or ambulance) might also be revealed by the emergency service identifier in the mapping query. The other pieces of information may provide the basis for further attacks on emergency call routing, but because of the time factor, are unlikely to be applicable to the routing of the current call. However, if the mapping client is the emergency caller's device, the attacker may gain information that allows for interference with the call after it has been set up or for interception of the media stream between the caller and the PSAP. Section 5. The requirements are presented in the same order as the attacks. From Section 5.1: Attack A1: fraudulent calls. Requirement R1: For calls that meet conditions a) to c) of Section 5.1, the service provider's call routing entity MUST verify that the destination address (e.g., SIP Request-URI) presented in the call signalling is that of a PSAP. Attack A2: Use of emergency identifier to probe in order to identify emergency call routing entities for attack by other means. Requirement: None identified, beyond the ordinary operational requirement to defend emergency call routing entities by means such as firewalls and, where possible, authentication and authorization. From Section 5.2.1: Attack A3: Flooding attack on the mapping client, mapping server, or a third entity. Requirement R2: The mapping protocol MUST NOT create new opportunities for flooding attacks, including amplification attacks.
Attack A4: Insertion of interfering messages. Requirement R3: The protocol MUST permit the mapping client to verify that the response it receives is responding to the query it sent out. Attack A5: Man-in-the-middle modification of messages. Requirement R4: The mapping protocol MUST provide integrity protection of requests and responses. Requirement R5: The mapping protocol or the system within which the protocol is implemented MUST permit the mapping client to authenticate the source of mapping responses. Attack A6: Impersonation of the mapping server. Requirement R6: The security considerations for any discussion of mapping server discovery MUST address measures to prevent impersonation of the mapping server. Requirement R5 also follows from this attack. Attack A7: Corruption of the mapping database. Requirement R7: The security considerations for the mapping protocol MUST address measures to prevent database corruption by an attacker. Requirement R8: 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. 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 and the system within which it is implemented MUST maintain confidentiality of the request and response.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
http://www.tschofenig.com Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 EMail: email@example.com URI: http://www.cs.columbia.edu Murugaraj Shanmugam Detecon International GmbH Oberkasseler str 2 Bonn, NRW 53227 Germany EMail: firstname.lastname@example.org
Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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. Intellectual Property 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 email@example.com.