< draft-ietf-ecrit-security-threats-04.txt		draft-ietf-ecrit-security-threats-05.txt >
	ECRIT T. Taylor		ECRIT T. Taylor, Ed.
	Internet-Draft (Editor) Nortel		Internet-Draft Nortel
	Expires: October 18, 2007 H. Tschofenig		Expires: February 22, 2008 H. Tschofenig
	Siemens		Nokia Siemens Networks
	H. Schulzrinne		H. Schulzrinne
	Columbia U.		Columbia University
	M. Shanmugam		M. Shanmugam
	Siemens		Detecon
	April 16, 2007		August 21, 2007
	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-04.txt		draft-ietf-ecrit-security-threats-05.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 October 18, 2007.		This Internet-Draft will expire on February 22, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document reviews the security threats associated with:		This document reviews the security threats associated with the
			marking of signalling messages to indicate that they are related to
	o the marking of signalling messages to indicate that they are		an emergency, and the process of mapping from locations to Universal
	related to an emergency; and		Resource Identifiers (URIs) pointing to Public Safety Answering
			Points (PSAPs). This mapping occurs as part of the process of
	o the process of mapping from locations to Universal Resource		routing emergency calls through the IP network.
	Identifiers (URIs) pointing to Public Safety Answering Points
	(PSAPs). This mapping occurs as part of the process of routing
	emergency calls through the IP network.
	Based on the identified threats, this document establishes a set of		Based on the identified threats, this document establishes a set of
	security requirements for the mapping protocol and for the handling		security requirements for the mapping protocol and for the 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
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 28 ¶
	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
	marking.		marking. Verification of the truthfulness of a reported incident by
			the PSAP operator 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		This document is organized as follows: Section 2 describes basic
	terminology. Section 3 briefly describes how emergency marking and		terminology. Section 3 briefly describes how emergency marking and
	mapping fit within the process of routing emergency calls. Section 4		mapping fit within the process of routing emergency calls. Section 4
	describes some motivations of attackers in the context of emergency		describes some motivations of attackers in the context of emergency
	calling, Section 5 describes and illustrates the attacks that might		calling, Section 5 describes and illustrates the attacks that might
	be used, and Section 6 lists the security-related requirements that		be used, and Section 6 lists the security-related requirements that
	must be met if these attacks are to be mitigated.		must be met if these attacks are to be mitigated.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119], with the		document are to be interpreted as described in [RFC2119], with the
	qualification that unless otherwise stated they apply to the design		qualification that unless otherwise stated they apply to the design
	of the mapping protocol, not its implementation or application.		of the mapping protocol, not its implementation or application.
	The terms call taker, mapping service, emergency caller, emergency		The terms call taker, mapping service, emergency caller, emergency
	identifier, mapping, mapping client, mapping server, mapping		identifier, mapping, mapping client, mapping server, mapping
	protocol, and Public Safety Answering Point (PSAP) are taken from		protocol, and Public Safety Answering Point (PSAP) are taken from
	[I-D.ecrit-requirements].		[I-D.ietf-ecrit-requirements].
	The term "location information" is taken from RFC 3693 [RFC3693].		The term "location information" is taken from RFC 3693 [RFC3693].
	The term "emergency caller's device" designates the IP host closest		The term "emergency caller's device" designates the IP host closest
	to the emergency caller in the signalling path between the emergency		to the emergency caller in the signalling path between the emergency
	caller and the PSAP. Examples include an IP phone running SIP,		caller and the PSAP. Examples include an IP phone running SIP,
	H.323, or a proprietary signalling protocol, a PC running a soft		H.323, or a proprietary signalling protocol, a PC running a soft
	client, or an analogue terminal adapter or a residential gateway		client, or an analogue terminal adapter or a residential gateway
	controlled by a softswitch.		controlled by a softswitch.
	skipping to change at page 5, line 24 ¶		skipping to change at page 5, line 24 ¶
	an emergency call. Signalling containing the emergency identifier		an emergency call. Signalling containing the emergency identifier
	may be given priority treatment, special processing, and/or special		may be given priority treatment, special processing, and/or special
	routing.		routing.
	3.2. Mapping		3.2. Mapping
	An important goal of emergency call routing is to ensure that any		An important goal of emergency call routing is to ensure that any
	emergency call is routed to a PSAP. Preferably the call is routed to		emergency call is routed to a PSAP. Preferably the call is routed to
	the PSAP responsible for the caller's location, since misrouting		the PSAP responsible for the caller's location, since misrouting
	consumes valuable time while the call taker locates and forwards the		consumes valuable time while the call taker locates and forwards the
	call to the right PSAP. As described in [I-D.ecrit-requirements],		call to the right PSAP. As described in
	mapping is part of the process of achieving this preferable outcome.		[I-D.ietf-ecrit-requirements], mapping is part of the process of
			achieving this preferable outcome.
	In brief, mapping involves a mapping client, a mapping server, and		In brief, mapping involves a mapping client, a mapping server, and
	the protocol that passes between them. The protocol allows the		the protocol that passes between them. The protocol allows the
	client to pass location information to the mapping server and to		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		receive back a URI which can be used to direct call signalling to a
	PSAP.		PSAP.
	Since mapping requires location information for input, when and where		Since mapping requires location information for input, when and where
	the location information is acquired imposes constraints upon when		the location information is acquired imposes constraints upon when
	mapping can be done and which devices can act as mapping clients.		mapping can be done and which devices can act as mapping clients.
	skipping to change at page 6, line 22 ¶		skipping to change at page 6, line 22 ¶
	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 calls to non-emergency sites. This is a form
	has not identified any attacks within its intended scope that		of denial of service attack similar to the first item but quite
	achieve this objective, so it will not be mentioned further.		likely more confusing for the caller itself since it expects to
			talk to a PSAP operator but instead gets connected to someone
			else.
	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
	skipping to change at page 12, line 27 ¶		skipping to change at page 12, line 27 ¶
	debugging of mis-directed calls. One example of a way to meet this		debugging of mis-directed calls. One example of a way to meet this
	requirement would be by means of an opaque parameter in the returned		requirement would be by means of an opaque parameter in the returned
	URI.		URI.
	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 A8: snooping of location and other information.		Attack A8: snooping of location and other information.
	Requirement R9: the protocol or the system within which it is		Requirement R9: the protocol and the system within which it is
	implemented MUST maintain confidentiality of the request and		implemented MUST maintain confidentiality of the request and
	response.		response.
	7. Security Considerations		7. Security Considerations
	This document addresses security threats and security requirements.		This document addresses security threats and security requirements.
	Therefore, security is considered throughout this document.		Therefore, security is considered throughout this document.
	8. IANA Considerations		8. IANA Considerations
	skipping to change at page 16, line 5 ¶		skipping to change at page 15, line 20 ¶
	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, Kamran		Marshall, Andrew Newton, and most recently, Spencer Dawkins, Kamran
	Aquil, and Ron Watro have also provided detailed reviews of this		Aquil, and Ron Watro have also provided detailed reviews of this
	document at various stages. The authors thank them.		document at various stages. The authors thank them.
			We would like to thank the Donald Eastlake for his review on behalf
			of the Security Area Directorate and Christian Vogt for his review as
			part of the General Area Review Team.
			Finally, we would like to think Jari Arkko, Jon Peterson, and Russ
			Housley for their IETF Last Call comments.
	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
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	10.2. Informative References		10.2. Informative References
	[I-D.ecrit-requirements]		[I-D.ietf-ecrit-requirements]
	Schulzrinne, H. and R. Marshall, "Requirements for		Schulzrinne, H. and R. Marshall, "Requirements for
	Emergency Context Resolution with Internet Technologies",		Emergency Context Resolution with Internet Technologies",
	March 2006.		draft-ietf-ecrit-requirements-13 (work in progress),
			March 2007.
	[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and		[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
	J. Polk, "Geopriv Requirements", RFC 3693, February 2004.		J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
	Authors' Addresses		Authors' Addresses
	Tom Taylor		Tom Taylor (editor)
	Nortel		Nortel
	1852 Lorraine Ave		1852 Lorraine Ave
	Ottawa, Ontario K1H 6Z8		Ottawa, Ontario K1H 6Z8
	Canada		Canada
	Email: taylor@nortel.com		Email: tom.taylor@rogers.com
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Nokia Siemens Networks
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bavaria 81739
	Germany		Germany
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@nsn.com
			URI: http://www.tschofenig.com
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building		450 Computer Science Building
	New York, NY 10027		New York, NY 10027
	USA		US
	Phone: +1 212 939 7042		Phone: +1 212 939 7004
	Email: schulzrinne@cs.columbia.edu		Email: hgs+ecrit@cs.columbia.edu
	URI: http://www.cs.columbia.edu/~hgs		URI: http://www.cs.columbia.edu
	Murugaraj Shanmugam		Murugaraj Shanmugam
	Siemens		Detecon International GmbH
	Otto-Hahn-Ring 6		Oberkasseler str 2
	Munich, Bayern 81739		Bonn, NRW 53227
	Germany		Germany
	Email: murugaraj.shanmugam@siemens.com		Email: murugaraj.shanmugam@detecon.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
End of changes. 23 change blocks.
	41 lines changed or deleted		53 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/