< draft-taylor-ecrit-security-threats-02.txt		draft-taylor-ecrit-security-threats-03.txt >
	ECRIT H. Tschofenig		ECRIT T. Taylor
	Internet-Draft Siemens		Internet-Draft (Editor) Nortel
	Expires: August 18, 2006 H. Schulzrinne		Expires: September 4, 2006 H. Tschofenig
			Siemens
			H. Schulzrinne
	Columbia U.		Columbia U.
	M. Shanmugam		M. Shanmugam
	Siemens		Siemens
	T. Taylor		March 3, 2006
	Nortel
	February 14, 2006
	Security Threats and Requirements for Emergency Call Mapping		Security Threats and Requirements for Emergency Call Marking and Mapping
	draft-taylor-ecrit-security-threats-02.txt		draft-taylor-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 August 18, 2006.		This Internet-Draft will expire on September 4, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document reviews the security threats to the process of mapping		This document reviews the security threats associated with the two
	locations to URIs pointing to Public Safety Answering Points (PSAPs).		current work items of the ECRIT Working Group. The first is the
	This mapping occurs as part of the process of routing emergency calls		marking of signalling messages to indicate that they are related to
	through the IP network. Based on the threats, this document		an emergency. The second is the process of mapping from locations to
	establishes a set of security requirements for the mapping protocol,		Universal Resource Identifiers (URIs) pointing to Public Safety
	which is being developed by the ECRIT Working Group.		Answering Points (PSAPs). This mapping occurs as part of the process
			of routing emergency calls through the IP network. Based on the
			threats, this document establishes a set of security requirements for
			the the mapping protocol and for the handling of emergency-marked
			calls.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Mapping and the emergency call routing process . . . . . . . . 5		3. Marking, mapping, and the emergency call routing process . . . 5
	4. Motivations of attackers . . . . . . . . . . . . . . . . . . . 6		4. Objectives of attackers . . . . . . . . . . . . . . . . . . . 6
	5. Potential attacks . . . . . . . . . . . . . . . . . . . . . . 7		5. Potential attacks . . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Attacks to prevent a specific individual from		5.1. Attacks involving the emergency identifier . . . . . . . . 7
	receiving aid . . . . . . . . . . . . . . . . . . . . . . 7		5.2. Attacks against or using the mapping process . . . . . . . 7
	5.2. Attacks to gain information about an emergency . . . . . . 7		5.2.1. Attacks against the emergency response system . . . . 7
	5.3. Attacks to gain fraudulent use of ASP/VSP services . . . . 8		5.2.2. Attacks to prevent a specific individual from
	5.4. Attacks against the emergency response system . . . . . . 9		receiving aid . . . . . . . . . . . . . . . . . . . . 9
	6. Security requirements relating to emergency call routing . . . 10		5.2.3. Attacks to gain information about an emergency . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security requirements relating to ECRIT work items . . . . . . 11
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.2. Informative References . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		10.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Intellectual Property and Copyright Statements . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
			Intellectual Property and Copyright Statements . . . . . . . . . . 18
	1. Introduction		1. Introduction
	Legacy telephone network (PSTN) users can summon help for emergency		Legacy telephone network users can summon help for emergency services
	services such as ambulance, fire and police using a well known unique		such as ambulance, fire and police using a well known number (e.g.,
	number (e.g., 911 in North America, 112 in Europe). A key factor in		911 in North America, 112 in Europe). A key factor in the handling
	the handling of such calls is the ability of the system to determine		of such calls is the ability of the system to determine caller
	caller location and to route the call to the appropriate Public		location and to route the call to the appropriate Public Safety
	Safety Answering Point (PSAP) based on that location. With the		Answering Point (PSAP) based on that location. With the introduction
	introduction of IP-based telephony and multimedia services, support		of IP-based telephony and multimedia services, support for emergency
	for emergency calling via the Internet also has to be provided. As		calling via the Internet also has to be provided. As one of the
	one of the steps to achieve this, a protocol must be developed		steps to achieve this, an emergency marker must be defined that can
	allowing a client entity to submit a location and receive a URI		be attached to call signalling to indicate that the call relates to
	pointing to the applicable PSAP for that location.		an emergency. In addition, a protocol must be developed allowing a
			client entity to submit a location and receive a URI pointing to the
			applicable PSAP for that location.
	Attacks against the PSTN (many focussing on free calling) have taken		Attacks against the PSTN (most often focusing on free calling) have
	place for decades. The Internet is seen as an even more hostile		taken place for decades. The Internet is seen as an even more
	environment. Thus it is important to understand the types of attacks		hostile environment. Thus it is important to understand the types of
	that might be mounted against the infrastructure providing emergency		attacks that might be mounted against the infrastructure providing
	services, and to develop security mechanisms to counter those		emergency services, and to develop security mechanisms to counter
	attacks. In view of the mandate of the ECRIT Working Group, the		those attacks. In view of the mandate of the ECRIT Working Group,
	present document restricts itself to attacks on the mapping of		the present document restricts itself to attacks on the mapping of
	locations to PSAP URIs.		locations to PSAP URIs and attacks based on emergency marking.
	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 mapping fits within the		terminology. Section 3 briefly describes how emergency marking and
	process of routing emergency calls. Section 4 describes some		mapping fit within the process of routing emergency calls. Section 4
	motivations of attackers in the context of ECRIT, Section 5 describes		describes some motivations of attackers in the context of ECRIT,
	and illustrates the attacks that might be used, and Section 6 lists		Section 5 describes and illustrates the attacks that might be used,
	the security-related requirements that must be met if these attacks		and Section 6 lists the security-related requirements that must be
	are to be mitigated.		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.
	Application (Voice) Service Provider (ASP/VSP), mapping service,		The terms Application (Voice) Service Provider (ASP/VSP), call taker,
	emergency address, emergency caller, emergency identifier, mapping,		mapping service, emergency address, emergency caller, emergency
	mapping client, mapping server, mapping protocol, and Public Safety		identifier, mapping, mapping client, mapping server, mapping
			protocol, Emergency Service Routing Proxy (ESRP), and Public Safety
	Answering Point (PSAP) are taken from [I-D.ecrit-requirements].		Answering Point (PSAP) are taken from [I-D.ecrit-requirements].
	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.
	3. Mapping and the emergency call routing process		3. Marking, mapping, and the emergency call routing process
			The ECRIT Working Group has two work items relating to the routing of
			emergency calls to their proper destination. The first is to enable
			entities along the signalling path to recognize that a particular
			signalling message is associated with an emergency call. The ECRIT
			Working Group is defining content that can be added to the signalling
			messages, an emergency identifier, for this purpose. Signalling
			containing the emergency identifier may be given priority treatment,
			special processing, and/or special routing.
	The first goal of emergency call routing is to ensure that any		The first 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 [I-D.ecrit-requirements],
	mapping is part of the process of achieving this preferable outcome.		mapping, the second ECRIT work item, 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 receive		client to pass location information to the mapping server and to
	back a URI which can be used to direct call signalling to a PSAP.		receive back a URI which can be used to direct call signalling to a
			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 constrains when mapping can be		the location information is acquired imposes constraints upon when
	done and which devices can act as mapping clients. The key		mapping can be done and which devices can act as mapping clients.
	distinction in "when" is before the emergency or during the		The key distinction in "when" is before the emergency or during the
	emergency. The key distinction in "where" is at the emergency		emergency. The key distinction in "where" is at the emergency
	caller's device or at another device in the signalling path between		caller's device or at another device in the signalling path between
	the emergency caller and the PSAP. The device that acquires the		the emergency caller and the PSAP. The device that acquires the
	location information can be the mapping client, and so can any device		location information can be the mapping client, and so can any device
	downstream of that point. It is even possible for a PSAP itself to		downstream of that point. It is even possible for a PSAP itself to
	initiate mapping, to determine whether an arriving call should be		initiate mapping, to determine whether an arriving call should be
	handled by a call taker at that PSAP or should be proxied to another		handled by a call taker at that PSAP or should be proxied to another
	PSAP.		PSAP.
	4. Motivations of attackers		4. Objectives of attackers
	Attackers may direct their efforts either against an individual or		Attackers may direct their efforts either against a portion of the
	against a portion of the emergency response system. Attacks against		emergency response system or against an individual. Attacks against
	an individual fall into three classes:		the emergency response system have three possible objectives:
			o to deny system services to all users in a given area. The
			motivation may range from thoughtless vandalism, to wide-scale
			criminality, to terrorism. One interesting variant on this
			motivation is the case where a victim of a large emergency hopes
			to gain faster service by blocking others' competing calls for
			help.
			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.
			o to divert emergency responders to non-emergency sites. No attacks
			affecting the ECRIT Working Group's decisions on the emergency
			identifier and mapping protocol have been identified that achieve
			this objective
			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;
	o attacks by the caller to gain fraudulent use of ASP/VSP services,		5. Potential attacks
	by using an Emergency Identifier to bypass normal authentication,
	authorization, and accounting procedures.
	Attacks against the emergency response system are aimed either at		5.1. Attacks involving the emergency identifier
	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. One interesting variant on
	the "system denial" motivation is the case where a victim of a large
	emergency hopes to gain faster service by blocking others' competing
	calls for help.
	5. Potential attacks		The main attack possibility involving the emergency identifier is to
			use it to bypass normal procedures in order to achieve fraudulent use
			of ASP/VSP services. An attack of this sort is possible only if the
			following conditions are true:
	This section describes classes of attacks on the mapping process that		a. The attacker is the emergency caller.
	could be used to achieve the attacker goals described in the previous
	section.
	5.1. Attacks to prevent a specific individual from receiving aid		b. The call routing system assumes that the emergency caller's
			device addresses emergency calls using the result of mapping
			based on the caller's location.
	This section discusses blocking attacks directed at a specific		c. The call enters the domain of an ASP/VSP, which accepts it
	individual. The more general blocking attacks described in		without applying normal procedures for authentication and
	Section 5.4 will also operate to the same effect. They are discussed		authorization because the signalling carries the emergency
	separately because the separation may be useful when weighing the		identifier.
	priority for implementing specific defenses.
	Blocking attacks against an individual can operate against the		d. The ASP/VSP routes it according to the called address (e.g., SIP
	operation of the mapping protocol, or through impersonation of the		Request-URI), without verifying that this is the address of a
	mapping server. It is also possible that the mapping protocol is		PSAP (noting that a URI by itself does not indicate the nature of
	used indirectly to interfere with other aspects of the emergency call		the entity it is pointing to).
	process.
	The basic attacks available against protocol operation are denial of		If these conditions are satisfied, the attacker can bypass normal
	service, interference through message insertion, and interference		ASP/VSP authorization procedures for arbitrary destinations, simply
	through man-in-the middle alteration of messages. Denial of service		by reprogramming the emergency caller's device to add the emergency
	can be achieved in several ways: by flooding attacks on the client or		identifier to non-emergency call signalling. Most probably in this
	server, by taking control of the mapping client, by installing		case, the call signalling will not include any location information.
	filters on the channel, or by installing filters at the mapping
	server. Man-in-the-middle attacks also involve taking control of the
	channel or the mapping server.
	The attacks based on control of the mapping server can also be		An attacker wishing to disrupt the emergency call routing system may
	carried out using impersonation of the mapping server. This may be		use a similar technique to target components of that system for a
	an easier attack to execute in some circumstances.		denial of service attack. The attacker will find this attractive to
			reach components that handle emergency calls only. Flooding attacks
			are the most likely application of the technique, but it may also be
			used to identify target components for other attacks by analyzing the
			content of responses to the original signalling messages.
	The mapping protocol may also be used to support a reflection attack		5.2. Attacks against or using the mapping process
	on the mapping client or on some other component of the routing
	chain. To execute this attack, the attacker impersonates the target
	when sending requests to the mapping server.
	5.2. Attacks to gain information about an emergency		This section describes classes of attacks involving the mapping
			process that could be used to achieve the attacker goals described in
			Section 4.
			5.2.1. 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. If
			the mapping operation is disabled, the immediate effect is to
			increase the probability that emergency calls are routed to the wrong
			PSAP. This has a double consequence: emergency response to the
			affected calls is delayed, and PSAP call taker resources outside the
			immediate area of the emergency are consumed due to the extra effort
			required to redirect the calls. Alternatively, attacks that cause
			the client to receive a URI that does not lead to a PSAP have the
			immediate effect of causing emergency calls to fail.
			Three basic attacks on the mapping process can be identified: denial
			of service, impersonation of the mapping server, or corruption of the
			mapping database. Denial of service in turn can be achieved in
			several ways:
			o by a flooding attack on the mapping server;
			o by taking control of the mapping server and either preventing it
			from responding or causing it send incorrect responses; or
			o by taking control of a router through which the mapping queries
			and responses pass and using that control to block them. An
			adversary may also attempt to modify the mapping protocol
			signaling messages. Additionally, it might be possible to replay
			past communication exchanges to fool an emergency caller by
			returning incorrect results.
			In an impersonation attack, the attacker induces the mapping client
			to direct its queries to a host under the attacker's control rather
			than the real mapping server. Impersonation itself is an issue for
			mapping server discovery rather than for the mapping protocol
			directly. However, the mapping protocol may help to protect against
			acceptance of responses from an impersonating entity.
			Corruption of the mapping database cannot be mitigated directly by
			mapping protocol design. The mapping protocol may have a role to
			play in analysis of which records have been corrupted, once that
			corruption has been detected.
			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.
			The other possible attack is one where the the mapping server is
			tricked into sending responses to the target of the attack through
			spoofing of the source address in the query.
			5.2.2. Attacks to prevent a specific individual from receiving aid
			If an attacker wishes to deny emergency service to a specific
			individual the mass attacks described in 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.
			It is more likely, if the attacker is using a mass attack but does
			not wish it to have too broad an effect, that it is used 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 a router through which the mapping queries and
			responses pass and 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.
			5.2.3. Attacks to gain information about an emergency
	This section discusses attacks used to gain information about an		This section discusses attacks used to gain information about an
	emergency. The attacker may be seeking the location of the caller		emergency. The attacker may be seeking the location of the caller
	(e.g., to effect a criminal attack). The attacker may be seeking		(e.g., to effect a criminal attack). The attacker may be seeking
	information that could be used to link an individual (the caller or		information that could be used to link an individual (the caller or
	someone else involved in the emergency) with embarrassing information		someone else involved in the emergency) with embarrassing information
	related to the emergency (e.g., "Who did the police take away just		related to the emergency (e.g., "Who did the police take away just
	now?"). Finally, the attacker could be seeking to profit from the		now?"). Finally, the attacker could be seeking to profit from the
	emergency, perhaps by offering his or her services (e.g., news		emergency, perhaps by offering his or her services (e.g., news
	reporter, "ambulance chaser").		reporter, "ambulance chaser").
	skipping to change at page 8, line 19 ¶		skipping to change at page 11, line 5 ¶
	information can be directly useful to an attacker if the attacker has		information can be directly useful to an attacker if the attacker has
	high assurance that the observed query is related to an emergency		high assurance that the observed query is related to an emergency
	involving the target. The other pieces of information may provide		involving the target. The other pieces of information may provide
	the basis for further attacks on emergency call routing, but because		the basis for further attacks on emergency call routing, but because
	of the time factor, are unlikely to be applicable to the routing of		of the time factor, are unlikely to be applicable to the routing of
	the current call. However, if the mapping client is the emergency		the current call. However, if the mapping client is the emergency
	caller's device, the attacker may gain information that allows for		caller's device, the attacker may gain information that allows for
	interference with the call after it has been set up or interception		interference with the call after it has been set up or interception
	of the media stream between the caller and the PSAP.		of the media stream between the caller and the PSAP.
	5.3. Attacks to gain fraudulent use of ASP/VSP services		6. Security requirements relating to ECRIT work items
	This section discusses attacks whereby the Emergency Caller is hoping
	to bypass normal procedures to achieve free use of ASP/VSP services.
	An attack of this sort is possible only if the following conditions
	are true:
	a. The attacker is the emergency caller.
	b. The attacker has control over the addressing of the emergency
	call request either as a result of or subsequent to the mapping
	operation.
	c. The call enters the domain of an ASP/VSP, which accepts it
	without applying normal requirements for an authenticated
	subscriber identity because it is marked as an emergency call.
	d. The ASP/VSP routes it according to the called address (e.g., SIP		This section describes the security requirements which must be
	Request-URI), without verifying that this is the address of a		fulfilled to prevent or reduce the effectiveness of the attacks
	PSAP.		described in Section 5. The requirements are presented in the same
			order as the attacks.
	The key condition is the second one. The attacker has two		From Section 5.1:
	possibilities for controlling the addressing of the call. One is to
	insert a false entry into the mapping database for the caller's
	location, allowing the caller free calls to wherever the entry points
	to. The second possibility comes if the emergency caller's device is
	the mapping client. In this case, if the caller reprograms the
	device to accept an arbitrary input in place of the URI returned by
	the mapping process, the caller is able to complete a call to that
	URI while bypassing the ASP/VSP's normal authentication procedures.
	5.4. Attacks against the emergency response system		Attack: fraudulent calls.
	This section considers attacks intended to reduce the effectiveness		Requirement: for calls which meet conditions a-c of Section 5.1, the
	of the emergency response system for all callers in a given area.		ASP/VSP call routing entity MUST verify that the destination address
	The motivation may range from thoughtless vandalism, to wide-scale		(e.g., SIP Request-URI) presented in the call signalling is that of a
	criminality, to terrorism.		PSAP.
	The possible attacks on the mapping process to achieve this have		Attack: use of emergency identifier to probe in order to identify
	already been described; they simply have to be less targeted. The		emergency call routing entities.
	attacks are denial of service or misdirection through provision of
	incorrect responses to mapping queries. The mechanisms are flooding
	attacks (for denial of service only), control of the Mapping Server,
	or impersonation of the Mapping Server.
	6. Security requirements relating to emergency call routing		Requirement: topology hiding SHOULD be applied to call signalling
			returned to the emergency caller, so that the identity of
			intermediate routing entities is not disclosed. The obvious
			exception is where these entities are already visible to the caller.
			Note that there is little point in hiding the PSAP itself.
	This section describes the security requirements which must be		From Section 5.2.1:
	fulfilled in the mapping protocol to prevent or blunt the
	effectiveness of the attacks described in the previous section.
	Attack: flooding attack on the mapping client, mapping server, or a		Attack: flooding attack on the mapping client, mapping server, or a
	third entity.		third entity.
	Requirement: The mapping protocol MUST NOT create new opportunities		Requirement: The mapping protocol MUST NOT create new opportunities
	for flooding attacks, including amplification attacks.		for flooding attacks, including amplification attacks.
	Attack: insertion of interfering messages.		Attack: insertion of interfering messages.
	Requirement: The protocol MUST permit the mapping client to verify		Requirement: The protocol MUST permit the mapping client to verify
	that the response is a response to the query it sent out.		that the response it receives is responding to the query it sent out.
	Attack: man-in-the-middle alteration of messages.		Attack: man-in-the-middle alteration of messages.
	Requirement: The protocol MUST permit the application of the		Requirement: The protocol MUST maintain request and response
	integrity service to requests and responses as an implementation		integrity.
	option.
	Attack: impersonation of the mapping server.		Attack: impersonation of the mapping server.
			Requirement: the security considerations for any discussion of
			mapping server discovery MUST address measures to prevent
			impersonation of the mapping server.
	Requirement: the protocol MUST permit the mapping client to		Requirement: the protocol MUST permit the mapping client to
	authenticate the mapping server as an implementation option.		authenticate the source of mapping responses.
	Attack: snooping of location and other information.		Attack: corruption of the mapping database.
	Requirement: the protocol MUST permit the use of the confidentiality		Requirement: the security considerations for the mapping protocol
	service as an implementation option.		MUST address measures to prevent database corruption by an attacker.
	Attack: fraudulent calls.		Requirement: to provide an audit trail, the protocol SHOULD allow the
			inclusion of an identifier in its response that indicates which
			database records were used in preparing the response. This
			identifier SHOULD be encrypted along with randomizing information
			such as date/time, to minimize the information provided to an
			attacker in mapping responses.
	Requirement: the protocol MUST permit the reverse lookup of URIs to		From Section 5.2.2: no new requirements.
	verify that a URI corresponds to a PSAP in the mapping database.
	Note - the necessity to use this capability depends on whether the		From Section 5.2.3:
	system architecture satisfies the conditions listed in
	Section 5.3. If the emergency caller's device is not the mapping		Attack: snooping of location and other information.
	client, the opportunity for fraud is very much limited.
			Requirement: the protocol MUST maintain confidentiality of the
			request and 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. Acknowledgements		8. Acknowledgements
	Hannes Tschofenig performed the initial security analysis for ECRIT.		The writing of this document has been a task made difficult by the
	The authors would like to thank Stephen Kent for his extensive		temptation to consider the security concerns of the entire personal
	comments on previous issues of this document, which led to a complete		emergency calling system, not just the specific pieces of work within
	rewriting of it.		the scope of the ECRIT Working Group. Hannes Tschofenig performed
			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
			earlier stage in the evolution of this document, Stephen Kent of the
			Security Directorate was asked to review it and provided extensive
			comments which led to a complete rewriting of it. Brian Rosen, Roger
			Marshall, Andrew Newton, and most recently, Spencer Dawkins have also
			provided detailed reviews of this 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
	Requirement Levels", BCP 14, RFC 2119, March 1997.		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.
	10.2. Informative References		10.2. Informative References
	[I-D.ecrit-requirements]		[I-D.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",
	February 2006.		February 2006.
	[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and		[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	J. Polk, "Geopriv Requirements", RFC 3693, February 2004.		Text on Security Considerations", BCP 72, RFC 3552,
			July 2003.
	Authors' Addresses		Authors' Addresses
			Tom Taylor
			Nortel
			1852 Lorraine Ave
			Ottawa, Ontario K1H 6Z8
			Canada
			Email: taylor@nortel.com
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bayern 81739
	Germany		Germany
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	skipping to change at page 15, line 34 ¶		skipping to change at page 18, line 5 ¶
	URI: http://www.cs.columbia.edu/~hgs		URI: http://www.cs.columbia.edu/~hgs
	Murugaraj Shanmugam		Murugaraj Shanmugam
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bayern 81739
	Germany		Germany
	Email: murugaraj.shanmugam@siemens.com		Email: murugaraj.shanmugam@siemens.com
	Tom Taylor
	Nortel
	1852 Lorraine Ave
	Ottawa, Ontario K1H 6Z8
	Canada
	Email: taylor@nortel.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
End of changes. 51 change blocks.
	184 lines changed or deleted		290 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/