< draft-ietf-ecrit-security-threats-02.txt		draft-ietf-ecrit-security-threats-03.txt >
	ECRIT T. Taylor		ECRIT T. Taylor
	Internet-Draft (Editor) Nortel		Internet-Draft (Editor) Nortel
	Expires: December 27, 2006 H. Tschofenig		Expires: January 13, 2007 H. Tschofenig
	Siemens		Siemens
	H. Schulzrinne		H. Schulzrinne
	Columbia U.		Columbia U.
	M. Shanmugam		M. Shanmugam
	Siemens		Siemens
	June 25, 2006		July 12, 2006
	Security Threats and Requirements for Emergency Call Marking and Mapping		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		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		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 Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document reviews the security threats associated with:		This document reviews the security threats associated with:
	o the marking of signalling messages to indicate that they are		o the marking of signalling messages to indicate that they are
	related to an emergency; and		related to an emergency; and
	o the process of mapping from locations to Universal Resource		o the process of mapping from locations to Universal Resource
	Identifiers (URIs) pointing to Public Safety Answering Points		Identifiers (URIs) pointing to Public Safety Answering Points
	(PSAPs). This mapping occurs as part of the process of routing		(PSAPs). This mapping occurs as part of the process of routing
	emergency calls through the IP network.		emergency calls through the IP network.
	Based on the idnetified threats, this document establishes a set of		Based on the identified threats, this document establishes a set of
	security requirements for the the mapping protocol and for the		security requirements for the mapping protocol and for the handling
	handling of emergency-marked calls.		of emergency-marked calls.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Marking, Mapping, and the Emergency Call Routing Process . . . 5		3. Marking, Mapping, and the Emergency Call Routing Process . . . 5
	4. Objectives of Attackers . . . . . . . . . . . . . . . . . . . 6		4. Objectives of Attackers . . . . . . . . . . . . . . . . . . . 6
	5. Potential Attacks . . . . . . . . . . . . . . . . . . . . . . 7		5. Potential Attacks . . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Attacks Involving the Emergency Identifier . . . . . . . . 7		5.1. Attacks Involving the Emergency Identifier . . . . . . . . 7
	5.2. Attacks Against or Using the Mapping Process . . . . . . . 7		5.2. Attacks Against or Using the Mapping Process . . . . . . . 7
	skipping to change at page 3, line 15 ¶		skipping to change at page 3, line 15 ¶
	1. Introduction		1. Introduction
	Legacy telephone network users can summon help for emergency services		Legacy telephone network users can summon help for emergency services
	such as ambulance, fire and police using a well known number (e.g.,		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		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		of such calls is the ability of the system to determine caller
	location and to route the call to the appropriate Public Safety		location and to route the call to the appropriate Public Safety
	Answering Point (PSAP) based on that location. With the introduction		Answering Point (PSAP) based on that location. With the introduction
	of IP-based telephony and multimedia services, support for emergency		of IP-based telephony and multimedia services, support for emergency
	calling via the Internet also has to be provided. As one of the		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		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		client entity to submit a location and receive a URI pointing to the
	applicable PSAP for that location.		applicable PSAP for that location.
	Attacks against the PSTN have taken place for decades. The Internet		Attacks against the PSTN have taken place for decades. The Internet
	is seen as an even more hostile environment. Thus it is important to		is seen as an even more hostile environment. Thus it is important to
	understand the types of attacks that might be mounted against the		understand the types of attacks that might be mounted against the
	infrastructure providing emergency services, and to develop security		infrastructure providing emergency services, and to develop security
	mechanisms to counter those attacks. While this can be a broad		mechanisms to counter those attacks. While this can be a broad
	topic, the present document restricts itself to attacks on the		topic, the present document restricts itself to attacks on the
	mapping of locations to PSAP URIs and attacks based on emergency		mapping of locations to PSAP URIs and attacks based on emergency
	skipping to change at page 6, line 20 ¶		skipping to change at page 6, line 20 ¶
	o to deny system services to all users in a given area. The		o to deny system services to all users in a given area. The
	motivation may range from thoughtless vandalism, to wide-scale		motivation may range from thoughtless vandalism, to wide-scale
	criminality, to terrorism. One interesting variant on this		criminality, to terrorism. One interesting variant on this
	motivation is the case where a victim of a large emergency hopes		motivation is the case where a victim of a large emergency hopes
	to gain faster service by blocking others' competing calls for		to gain faster service by blocking others' competing calls for
	help.		help.
	o to gain fraudulent use of services, by using an emergency		o to gain fraudulent use of services, by using an emergency
	identifier to bypass normal authentication, authorization, and		identifier to bypass normal authentication, authorization, and
	accounting procedures.		accounting procedures;
	o to divert emergency responders to non-emergency sites. This memo		o to divert emergency responders to non-emergency sites. This memo
	has not identified any attacks within its intended scope that		has not identified any attacks within its intended scope that
	achieve this objective, so it will not be mentioned further.		achieve this objective, so it will not be mentioned further.
	Attacks against an individual fall into two classes:		Attacks against an individual fall into two classes:
	o attacks to prevent an individual from receiving aid;		o attacks to prevent an individual from receiving aid;
	o attacks to gain information about an emergency that can be applied		o attacks to gain information about an emergency that can be applied
	either against an individual involved in that emergency or to the		either against an individual involved in that emergency or to the
	profit of the attacker;		profit of the attacker.
	5. Potential Attacks		5. Potential Attacks
	5.1. Attacks Involving the Emergency Identifier		5.1. Attacks Involving the Emergency Identifier
	The main attack possibility involving the emergency identifier is to		The main attack possibility involving the emergency identifier is to
	use it to bypass normal procedures in order to achieve fraudulent use		use it to bypass normal procedures in order to achieve fraudulent use
	of services. An attack of this sort is possible only if the		of services. An attack of this sort is possible only if the
	following conditions are true:		following conditions are true:
	skipping to change at page 7, line 34 ¶		skipping to change at page 7, line 34 ¶
	d. The service provider routes it according to the called address		d. The service provider routes it according to the called address
	(e.g., SIP Request-URI), without verifying that this is the		(e.g., SIP Request-URI), without verifying that this is the
	address of a PSAP (noting that a URI by itself does not indicate		address of a PSAP (noting that a URI by itself does not indicate
	the nature of the entity it is pointing to).		the nature of the entity it is pointing to).
	If these conditions are satisfied, the attacker can bypass normal		If these conditions are satisfied, the attacker can bypass normal
	service provider authorization procedures for arbitrary destinations,		service provider authorization procedures for arbitrary destinations,
	simply by reprogramming the emergency caller's device to add the		simply by reprogramming the emergency caller's device to add the
	emergency identifier to non-emergency call signalling. Most probably		emergency identifier to non-emergency call signalling. Most probably
	in this case, the call signalling will not include any location		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		An attacker wishing to disrupt the emergency call routing system may
	use a similar technique to target components of that system for a		use a similar technique to target components of that system for a
	denial of service attack. The attacker will find this attractive to		denial of service attack. The attacker will find this attractive to
	reach components that handle emergency calls only. Flooding attacks		reach components that handle emergency calls only. Flooding attacks
	are the most likely application of the technique, but it may also be		are the most likely application of the technique, but it may also be
	used to identify target components for other attacks by analyzing the		used to identify target components for other attacks by analyzing the
	content of responses to the original signalling messages.		content of responses to the original signalling messages.
	5.2. Attacks Against or Using the Mapping Process		5.2. Attacks Against or Using the Mapping Process
	skipping to change at page 12, line 14 ¶		skipping to change at page 12, line 14 ¶
	Requirement: the protocol or the system within which it is		Requirement: the protocol or the system within which it is
	implemented MUST permit the mapping client to authenticate the source		implemented MUST permit the mapping client to authenticate the source
	of mapping responses.		of mapping responses.
	Attack: corruption of the mapping database.		Attack: corruption of the mapping database.
	Requirement: the security considerations for the mapping protocol		Requirement: the security considerations for the mapping protocol
	MUST address measures to prevent database corruption by an attacker.		MUST address measures to prevent database corruption by an attacker.
	Requirement: to provide an audit trail, the protocol SHOULD allow the		Requirement: the protocol SHOULD include information in the response
	inclusion of an identifier in its response that indicates which		that allows subsequent correlation of that response with internal
	database records were used in preparing the response. This		logs that may be kept on the mapping server, to allow debugging of
	identifier SHOULD be encrypted along with randomizing information		mis-directed calls. One example of a way to meet this requirement
	such as date/time, to minimize the information provided to an		would be by means of an opaque parameter in the returned URI.
	attacker in mapping responses.
	From Section 5.2.2: no new requirements.		From Section 5.2.2: no new requirements.
	From Section 5.2.3:		From Section 5.2.3:
	Attack: snooping of location and other information.		Attack: snooping of location and other information.
	Requirement: the protocol or the system within which it is		Requirement: the protocol or the system within which it is
	implemented MUST maintain confidentiality of the request and		implemented MUST maintain confidentiality of the request and
	response.		response.
	skipping to change at page 14, line 16 ¶		skipping to change at page 14, line 16 ¶
	The writing of this document has been a task made difficult by the		The writing of this document has been a task made difficult by the
	temptation to consider the security concerns of the entire personal		temptation to consider the security concerns of the entire personal
	emergency calling system, not just the specific pieces of work within		emergency calling system, not just the specific pieces of work within
	the scope of the ECRIT Working Group. Hannes Tschofenig performed		the scope of the ECRIT Working Group. Hannes Tschofenig performed
	the initial security analysis for ECRIT, but it has been shaped since		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		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		earlier stage in the evolution of this document, Stephen Kent of the
	Security Directorate was asked to review it and provided extensive		Security Directorate was asked to review it and provided extensive
	comments which led to a complete rewriting of it. Brian Rosen, Roger		comments which led to a complete rewriting of it. Brian Rosen, Roger
	Marshall, Andrew Newton, and most recently, Spencer Dawkins and		Marshall, Andrew Newton, and most recently, Spencer Dawkins, Kamran
	Kmaran Aquil have also provided detailed reviews of this document at		Aquil, and Ron Watro have also provided detailed reviews of this
	various stages. The authors thank them.		document at various stages. The authors thank them.
	9. IANA Considerations		9. IANA Considerations
	This document does not require actions by the IANA.		This document does not require actions by the IANA.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
End of changes. 12 change blocks.
	21 lines changed or deleted		20 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/