< draft-ietf-ecrit-trustworthy-location-11.txt		draft-ietf-ecrit-trustworthy-location-12.txt >
	ECRIT Working Group H. Tschofenig		ECRIT Working Group H. Tschofenig
	INTERNET-DRAFT ARM Ltd.		INTERNET-DRAFT ARM Ltd.
	Category: Informational H. Schulzrinne		Category: Informational H. Schulzrinne
	Expires: December 2, 2014 Columbia University		Expires: December 2, 2014 Columbia University
	B. Aboba (ed.)		B. Aboba (ed.)
	Microsoft Corporation		Microsoft Corporation
	1 June 2014		2 June 2014
	Trustworthy Location		Trustworthy Location
	draft-ietf-ecrit-trustworthy-location-11.txt		draft-ietf-ecrit-trustworthy-location-12.txt
	Abstract		Abstract
	The trustworthiness of location information is critically important		The trustworthiness of location information is critically important
	for some location-based applications, such as emergency calling or		for some location-based applications, such as emergency calling or
	roadside assistance.		roadside assistance.
	This document describes threats relating to conveyance of location an		This document describes threats relating to conveyance of location in
	emergency call, and describes techniques that improve the reliability		an emergency call, and describes techniques that improve the
	and security of location information conveyed in a IP-based emergency		reliability and security of location information conveyed in a IP-
	service call. It also provides guidelines for assessing the		based emergency service call. It also provides guidelines for
	trustworthiness of location information.		assessing the trustworthiness of location information.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2 Literature review . . . . . . . . . . . . . . . . . . . . 5		1.2 Literature review . . . . . . . . . . . . . . . . . . . . 5
	2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 7		2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 8		2.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 9
	2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 9		2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 9
	3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 9		3. Mitigation Techniques . . . . . . . . . . . . . . . . . . . . 10
	3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 10		3.1. Signed Location by Value . . . . . . . . . . . . . . . . . 10
	3.2. Location by Reference . . . . . . . . . . . . . . . . . . 13		3.2. Location by Reference . . . . . . . . . . . . . . . . . . 14
	3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 16		3.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 17
	4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 18		4. Location Trust Assessment . . . . . . . . . . . . . . . . . . 18
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 20		5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	7.1. Informative references . . . . . . . . . . . . . . . . . . 22		7.1. Informative references . . . . . . . . . . . . . . . . . . 22
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	Several public and commercial services depend upon location		Several public and commercial services depend upon location
	information in their operations. This includes emergency services		information in their operations. This includes emergency services
	(such as fire, ambulance and police) as well as commercial services		(such as fire, ambulance and police) as well as commercial services
	such as food delivery and roadside assistance.		such as food delivery and roadside assistance.
	For circuit-switched calls from landlines, as well as for Voice over		For circuit-switched calls from landlines, as well as for Voice over
	IP (VoIP) services only supporting emergency service calls from		IP (VoIP) services only supporting emergency service calls from
	skipping to change at page 4, line 13 ¶		skipping to change at page 4, line 13 ¶
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	The definitions of "Internet Access Provider (IAP)", "Internet		The definitions of "Internet Access Provider (IAP)", "Internet
	Service Provider (ISP)" and "Voice Service Provider (VSP)" are taken		Service Provider (ISP)" and "Voice Service Provider (VSP)" are taken
	from "Requirements for Emergency Context Resolution with Internet		from "Requirements for Emergency Context Resolution with Internet
	Technologies" [RFC5012].		Technologies" [RFC5012].
	The definition of a "hoax call" is taken from "False Emergency Calls"		The definition of a "hoax call" is taken from "False Emergency Calls"
	[EENA].		[EENA].
	The definition of "Target" and "Device" is taken from "An		The definition of "Device", "Target" and "Location Information
	Architecture for Location and Location Privacy in Internet		Server" (LIS) is taken from "An Architecture for Location and
	Applications" [RFC6280].		Location Privacy in Internet Applications" [RFC6280], Section 7.
			The term "Device" denotes the physical device, such as a mobile
			phone, PC, or embedded micro-controller, whose location is tracked as
			a proxy for the location of a Target.
			The term "Target" denotes an individual or other entity whose
			location is sought in the Geopriv architecture. In many cases, the
			Target will be the human user of a Device, or it may be an object
			such as a vehicle or shipping container to which a Device is
			attached. In some instances, the Target will be the Device itself.
			The Target is the entity whose privacy Geopriv seeks to protect.
			The term "Location Information Server" denotes an entity responsible
			for providing devices within an access network with information about
			their own locations. A Location Information Server uses knowledge of
			the access network and its physical topology to generate and
			distribute location information to devices.
	The term "location determination method" refers to the mechanism used		The term "location determination method" refers to the mechanism used
	to determine the location of a Target. This may be something		to determine the location of a Target. This may be something
	employed by a location information server (LIS), or by the Target		employed by a location information server (LIS), or by the Target
	itself. It specifically does not refer to the location configuration		itself. It specifically does not refer to the location configuration
	protocol (LCP) used to deliver location information either to the		protocol (LCP) used to deliver location information either to the
	Target or the Recipient. This term is re-used from "GEOPRIV PIDF-LO		Target or the Recipient. This term is re-used from "GEOPRIV PIDF-LO
	Usage Clarification, Considerations, and Recommendations" [RFC5491].		Usage Clarification, Considerations, and Recommendations" [RFC5491].
	The term "source" is used to refer to the LIS, node, or device from		The term "source" is used to refer to the LIS, node, or device from
	skipping to change at page 20, line 25 ¶		skipping to change at page 20, line 45 ¶
	exchange audit trails information in a standardized format between		exchange audit trails information in a standardized format between
	ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish		ISPs and PSAPs / VSPs and PSAPs or heuristics to distinguish
	potentially fraudulent emergency calls from real emergencies. While		potentially fraudulent emergency calls from real emergencies. While
	a Completely Automated Public Turing test to tell Computers and		a Completely Automated Public Turing test to tell Computers and
	Humans Apart (CAPTCHA) may be applied to suspicious calls to lower		Humans Apart (CAPTCHA) may be applied to suspicious calls to lower
	the risk from bot-nets, this is quite controversial for emergency		the risk from bot-nets, this is quite controversial for emergency
	services, due to the risk of delaying or rejecting valid calls.		services, due to the risk of delaying or rejecting valid calls.
	5. Security Considerations		5. Security Considerations
	It should be understood that mounting the attacks described in
	Section 2 is non-trivial. Location theft requires the attacker to be
	in proximity to the location being spoofed, or to either collude with
	another end host or gain control of an end host so as to obtain its
	location. Time shifting attacks require that the attacker visit the
	location and submit it before the location information is considered
	stale, while travelling rapidly away from that location to avoid
	apprehension. Obtaining a PIDF-LO from a spoofed IP address requires
	that the attacker be on the path between the HELD requester and the
	LIS.
	Although it is important to ensure that location information cannot		Although it is important to ensure that location information cannot
	be faked, it should be understood that the mitigation techniques		be faked, the mitigation techniques presented in this document are
	presented in this document are not universally applicable. For		not universally applicable. For example, there will be many GPS-
	example, there will be many GPS-enabled devices that will find it		enabled devices that will find it difficult to utilize any of the
	difficult to utilize any of the solutions described in Section 3. It		solutions described in Section 3. It is also unlikely that users
	is also unlikely that users will be willing to upload their location		will be willing to upload their location information for
	information for "verification" to a nearby location server located in		"verification" to a nearby location server located in the access
	the access network.		network.
	While this document focuses on threats that arise from conveyance of		This document focuses on threats that arise from conveyance of
	misleading location information, rather than caller identification or		misleading location information, rather than caller identification or
	authentication and integrity protection of the messages in which		authentication and integrity protection of the messages in which
	location is conveyed. Nevertheless, it should be understood that		location is conveyed. Nevertheless, these aspects are important. In
	these aspects are important.		some countries, regulators may not require the authenticated identity
			of the emergency caller (e.g. emergency calls placed from PSTN pay
	In some countries, regulators may not require the authenticated		phones or SIM-less cell phones). Furthermore, if identities can
	identity of the emergency caller (e.g. emergency calls placed from		easily be crafted (as it is the case with many VoIP offerings today),
	PSTN pay phones or SIM-less cell phones). Furthermore, if identities		then the value of emergency caller authentication itself might be
	can easily be crafted (as it is the case with many VoIP offerings		limited. As a result, attackers can forge emergency call information
	today), then the value of emergency caller authentication itself		with a lower risk of being held accountable, which may encourage hoax
	might be limited. As a result, attackers can forge emergency call		calls.
	information with a lower risk of being held accountable, and this
	appears to be correlated with an increase in hoax calls.
	In order to provide authentication and integrity protection for the		In order to provide authentication and integrity protection for the
	Session Initiation Protocol (SIP) messages conveying location,		Session Initiation Protocol (SIP) messages conveying location,
	several security approaches are available. It is possible to ensure		several security approaches are available. It is possible to ensure
	that modification of the identity and location in transit can be		that modification of the identity and location in transit can be
	detected by the location recipient (e.g., the PSAP), using		detected by the location recipient (e.g., the PSAP), using
	cryptographic mechanisms, as described in "Enhancements for		cryptographic mechanisms, as described in "Enhancements for
	Authenticated Identity Management in the Session Initiation Protocol"		Authenticated Identity Management in the Session Initiation Protocol"
	[RFC4474]. However, compatibility with Session Border Controllers		[RFC4474]. However, compatibility with Session Border Controllers
	(SBCs) that modify integrity-protected headers has proven to be an		(SBCs) that modify integrity-protected headers has proven to be an
	issue in practice, and as a result, a revision is in progress		issue in practice, and as a result, a revision is in progress
	[I.D.jennings-stir-rfc4474bis]. In the absence of an end-to-end		[I.D.jennings-stir-rfc4474bis]. In the absence of an end-to-end
	solution, SIP over Transport Layer Security (TLS) can be used to		solution, SIP over Transport Layer Security (TLS) can be used to
	provide message authentication and integrity protection hop-by-hop.		provide message authentication and integrity protection hop-by-hop.
	It should also be understood that even where the mitigation		PSAPs remain vulnerable to distributed denial of service attacks,
	techniques described in this document are utilized, PSAPs remain		even where the mitigation techniques described in this document are
	vulnerable to distributed denial of service attacks. Placing a large		utilized. Placing a large number of emergency calls that appear to
	number of emergency calls that appear to come from different		come from different locations is an example of an attack that is
	locations is an example of an attack that is difficult to carry out		difficult to carry out within the legacy system, but is easier to
	within legacy system, but is easier to imagine within IP-based		imagine within IP-based emergency services. Also, in the current
	emergency services. Also, in the current system, it would be very		system, it would be very difficult for an attacker from country 'Foo'
	difficult for an attacker from country 'Foo' to attack the emergency		to attack the emergency services infrastructure located in country
	services infrastructure located in country 'Bar', but this attack is		'Bar', but this attack is possible within IP-based emergency
	possible within IP-based emergency services.		services.
			While manually mounting the attacks described in Section 2 is non-
			trivial, the attacks described in this document can be automated.
			While manually carrying out a location theft would require the
			attacker to be in proximity to the location being spoofed, or to
			collude with another end host, an attacker able to run code on an end
			host can obtain its location, and cause an emergency call to be made.
			While manually carrying out a time shifting attack would require that
			the attacker visit the location and submit it before the location
			information is considered stale, while travelling rapidly away from
			that location to avoid apprehension, these limitations would not
			apply to an attacker able to run code on the end host. While
			obtaining a PIDF-LO from a spoofed IP address requires that the
			attacker be on the path between the HELD requester and the LIS, if
			the attacker is able to run code requesting the PIDF-LO, retrieve it
			from the LIS, and then make an emergency call using it, this attack
			becomes much easier. To mitigate the risk of automated attacks,
			service providers can limit the ability of untrusted code (such as
			WebRTC applications written in Javascript) to make emergency calls.
	Emergency services have three finite resources subject to denial of		Emergency services have three finite resources subject to denial of
	service attacks: the network and server infrastructure, call takers		service attacks: the network and server infrastructure, call takers
	and dispatchers, and the first responders, such as fire fighters and		and dispatchers, and the first responders, such as fire fighters and
	police officers. Protecting the network infrastructure is similar to		police officers. Protecting the network infrastructure is similar to
	protecting other high-value service providers, except that location		protecting other high-value service providers, except that location
	information may be used to filter call setup requests, to weed out		information may be used to filter call setup requests, to weed out
	requests that are out of area. Even for large cities PSAPs may only		requests that are out of area. Even for large cities PSAPs may only
	have a handful of call takers on duty. So even if automated		have a handful of call takers on duty. So even if automated
	techniques are utilized to evaluate the trustworthiness of conveyed		techniques are utilized to evaluate the trustworthiness of conveyed
End of changes. 13 change blocks.
	56 lines changed or deleted		79 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/