< draft-ietf-ecrit-trustworthy-location-03.txt		draft-ietf-ecrit-trustworthy-location-04.txt >
	ECRIT Working Group H. Tschofenig		ECRIT Working Group H. Tschofenig
	INTERNET-DRAFT Nokia Siemens Networks		INTERNET-DRAFT Nokia Siemens Networks
	Category: Informational H. Schulzrinne		Category: Informational H. Schulzrinne
	Expires: October 4, 2012 Columbia University		Expires: April 22, 2013 Columbia University
	B. Aboba (ed.)		B. Aboba (ed.)
	Microsoft Corporation		Microsoft Corporation
	4 April 2012		22 October 2012
	Trustworthy Location Information		Trustworthy Location
	draft-ietf-ecrit-trustworthy-location-03.txt		draft-ietf-ecrit-trustworthy-location-04.txt
	Abstract		Abstract
	For some location-based applications, such as emergency calling or		For some location-based applications, such as emergency calling or
	roadside assistance, it is important to be able to determine whether		roadside assistance, the trustworthiness of location information is
	location information is trustworthy.		critically important.
	This document outlines potential threats to trustworthy location and		This document describes the problem of "trustworthy location" as well
	analyzes the operational issues with potential solutions.		as potential solutions.
	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/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on October 4, 2012.		This Internet-Draft will expire on April 22, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
			2. Emergency Services Architecture . . . . . . . . . . . . . . . 4
	3. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 6		3.1. Location Spoofing . . . . . . . . . . . . . . . . . . . . 6
	3.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 7		3.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 7
	4. Solution Proposals . . . . . . . . . . . . . . . . . . . . . . 8		4. Solution Proposals . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Location Signing . . . . . . . . . . . . . . . . . . . . . 8		4.1. Location Signing . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Location by Reference . . . . . . . . . . . . . . . . . . 9		4.2. Location by Reference . . . . . . . . . . . . . . . . . . 10
	4.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 11		4.3. Proxy Adding Location . . . . . . . . . . . . . . . . . . 11
	5. Operational Considerations . . . . . . . . . . . . . . . . . . 11		5. Operational Considerations . . . . . . . . . . . . . . . . . . 12
	5.1. Attribution to a Specific Trusted Source . . . . . . . . . 11		5.1. Attribution to a Specific Trusted Source . . . . . . . . . 12
	5.2. Application to a Specific Point in Time . . . . . . . . . 16		5.2. Application to a Specific Point in Time . . . . . . . . . 16
	5.3. Linkage to a Specific Endpoint . . . . . . . . . . . . . . 16		5.3. Linkage to a Specific Endpoint . . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	9.1. Informative references . . . . . . . . . . . . . . . . . . 18		9.1. Informative references . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	The operation of a number of public and commercial services depend		Several public and commercial services depend upon location
	upon location information in their operations. Emergency services,		information in their operations. This includes emergency services
	such as fire department, ambulance and police, are among these, as		(such as fire, ambulance and police) as well as commercial services
	are commercial services such as food delivery and roadside		such as food delivery and roadside assistance.
	assistance.
			Services that depend on accurate location commonly experience
			security issues today. While prank calls have been a problem for
			emergency services dating back to the time of street corner call
			boxes, a recent increase in the frequency and sophistication of the
			attacks has lead to the FBI issuing a warning [Swatting]. Since
			prank emergency calls can endanger bystanders or emergency services
			personnel, or divert resources away from legitimate emergencies, they
			can be life threatening.
			It should be kept in mind that issues of location trust and
			attribution are closely linked. In situations where tracing of an
			emergency call back to the originator is more difficult, experience
			has shown that the frequency of nuisance calls can rise dramatically.
			For example, where emergency calls have been allowed from handsets
			lacking a SIM card, or where ownership of the SIM card cannot be
			determined, the frequency of nuisance calls has often been
			unacceptably high [TASMANIA][UK][SA].
			Conversely, where the ability exists enable an investigator to
			determine the originator of a prank emergency call after the fact,
			the trustworthiness of location is likely to improve, even without
			the introduction of measures to limit location spoofing. Under a
			court order, an investigator can have access to additional
			information beyond the messages conveyed in the emergency call. For
			example, in such a situation, audit logs will often be made available
			and in addition, information relating to the owner of an unlinked
			pseudonym could be provided to investigators, enabling them to
			unravel the chain of events that lead to the attack.
			This document reviews the emergency services architecture in Section
			2, investigates security threats in Section 3, and outlines potential
			solutions in Section 4. Operational considerations are provided in
			Section 5 and security considerations are discussed in Section 6.
			1.1. Terminology
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
			This document uses terms from [RFC5012] Section 3.
			2. Emergency Services Architecture
	Users of the telephone network can summon emergency services such as		Users of the telephone network can summon emergency services such as
	ambulance, fire and police using a well-known emergency service		ambulance, fire and police using a well-known emergency service
	number (e.g., 9-1-1 in North America, 1-1-2 in Europe). Location		number (e.g., 9-1-1 in North America, 1-1-2 in Europe). Location
	information is used to route emergency calls to the appropriate		information is used to route emergency calls to the appropriate
	regional Public Safety Answering Point (PSAP) that serves the caller		regional Public Safety Answering Point (PSAP) that serves the caller
	to dispatch first-level responders to the emergency site.		to dispatch first-level responders to the emergency site.
	Physical security is often based on location. Light switches in
	buildings are not typically protected by keycards or passwords, but
	are only accessible to those within the perimeter of the building.
	Merchants processing credit card payments already use location
	information to estimate the risk that a transaction is fraudulent,
	based on translation of the HTTP client's IP address to an estimated
	location. In these cases, location information can be used to
	augment identity or, in some cases, avoid the need for role-based
	authorization.
	For services that depend on the accuracy of location information in
	their operation, the ability to determine the trustworthiness of
	location information may be important. Prank calls have been a
	problem for emergency services, dating back to the time of street
	corner call boxes. Individual prank calls waste emergency services
	and possibly endanger bystanders or emergency service personnel as
	they rush to the reported scene of a fire or accident. However, a
	recent increase in the frequency and sophistication of the attacks
	has lead to the FBI issuing a warning [Swatting].
	In situations where it is possible to place emergency calls without
	accountability, experience has shown that the frequency of nuisance
	calls can rise dramatically. For example, where emergency calls have
	been allowed from handsets lacking a SIM card, or where ownership of
	the SIM card cannot be determined, the frequency of nuisance calls
	has often been unacceptably high [TASMANIA][UK][SA].
	In emergency services deployments utilizing voice over IP, many of		In emergency services deployments utilizing voice over IP, many of
	the assumptions of the public switched telephone network (PSTN) and		the assumptions of the Plain Old Telephone Service (POTS) and public
	public land mobile network (PLMN) no longer hold. While the local		land mobile network (PLMN) no longer hold. While both POTS and PLMN
	telephone company provides both physical access and the phone		service providers often both physical access as well as phone
	service, with VoIP there is a split between the role of the Access		service, with Voice over IP (VoIP) there is a split between the role
	Infrastructure Provider (AIP), and the Application (Voice) Service		of the Access Infrastructure Provider (AIP), and the Application
	Provider (VSP). The VSP may be located far away from the AIP and may		(Voice) Service Provider (VSP). The VSP may be located far away from
	either have no business relationship with the AIP or may be a		the AIP and may either have no business relationship with the AIP or
	competitor. It is also likely that the VSP will have no relationship		may be a competitor. It is also likely that the VSP will have no
	with the PSAP.		relationship with the PSAP.
	In some situations it is possible for the end host to determine its		In some situations it is possible for the end host to determine its
	own location using technology such as the Global Positioning System		own location using technology such as the Global Positioning System
	(GPS). Where the end host cannot determine location on its own,		(GPS). Where the end host cannot determine location on its own,
	mechanisms have been standardized to make civic and geodetic location		mechanisms have been standardized to make civic and geodetic location
	available to the end host, including LLDP-MED [LLDP-MED], DHCP		available to the end host, including LLDP-MED [LLDP-MED], DHCP
	extensions [RFC4776][RFC6225], HELD [RFC5985], or link-layer		extensions [RFC4776][RFC6225], HELD [RFC5985], or link-layer
	specifications such as [IEEE-802.11y]. The server offering this		specifications such as [IEEE-802.11y]. The server offering this
	information is known as a Location Information Server (LIS). The LIS		information is known as a Location Information Server (LIS). The LIS
	may be deployed by an AIP, or it may be run by a Location Service		may be deployed by an AIP, or it may be run by a Location Service
	Provider (LSP) which may have no relationship with the AIP, the VSP		Provider (LSP) which may have no relationship with the AIP, the VSP
	or the PSAP. The location information is then provided, by reference		or the PSAP. The location information, provided by reference or by
	or value, to the service-providing entities, i.e. location		value, is then conveyed to the service-providing entities, i.e.
	recipients, via application protocols, such as HTTP, SIP or XMPP.		location recipients, via application protocols, such as HTTP, SIP or
			XMPP.
	This document investigates security threats in Section 3, and
	outlines potential solutions in Section 4. Operational
	considerations are provided in Section 5 and security considerations
	are discussed in Section 6.
	2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	This document uses terms from [RFC5012] Section 3.		Where the end host does not provide location, or is not trusted to do
			so, it is possible for an intermediary to retrieve location
			information on behalf of the endpoint.
	3. Threats		3. Threats
	This document focuses on threats deriving from the introduction of		This section focuses on threats deriving from the introduction of
	untrustworthy location information by end hosts, regardless of		untrustworthy location information, regardless of whether this occurs
	whether this occurs intentionally or unintentionally.		intentionally or unintentionally.
	In addition to threats arising from the intentional forging of		In addition to threats arising from the intentional forging of
	location information, end hosts may be induced to provide		location information, end hosts may be induced to provide
	untrustworthy location information. For example, end hosts may		untrustworthy location information. For example, end hosts may
	obtain location from civilian GPS, which is vulnerable to spoofing		obtain location from civilian GPS, which is vulnerable to spoofing
	[GPSCounter] or from third party Location Service Providers (LSPs)		[GPSCounter] or from third party Location Service Providers (LSPs)
	which may be vulnerable to attack or may not warrant the use of their		which may be vulnerable to attack or may not warrant the use of their
	services for emergency purposes.		services for emergency purposes.
	Emergency services have three finite resources subject to denial of		Emergency services have three finite resources subject to denial of
	skipping to change at page 12, line 10 ¶		skipping to change at page 12, line 31 ¶
	5.1. Attribution to a Specific Trusted Source		5.1. Attribution to a Specific Trusted Source
	[NENA-i2] Section 3.7 describes some of the aspects of attribution as		[NENA-i2] Section 3.7 describes some of the aspects of attribution as
	follows:		follows:
	The i2 solution proposes a Location Information Server (LIS) be		The i2 solution proposes a Location Information Server (LIS) be
	the source for distributing location information within an access		the source for distributing location information within an access
	network. Furthermore the validity, integrity and authenticity of		network. Furthermore the validity, integrity and authenticity of
	this information are directly attributed to the LIS operator.		this information are directly attributed to the LIS operator.
	Section 6.1.1 describes the issues that arise in ensuring the		Section 5.1.1 describes the issues that arise in ensuring the
	validity of location information provided by the LIS operator.		validity of location information provided by the LIS operator.
	Section 6.1.2 and Section 6.1.3 describe operational issues that		Section 5.1.2 and Section 5.1.3 describe operational issues that
	arise in ensuring the integrity and authenticity of location		arise in ensuring the integrity and authenticity of location
	information provided by the LIS operator.		information provided by the LIS operator.
	5.1.1. Validity		5.1.1. Validity
	In existing networks where location information is both determined by		In existing networks where location information is both determined by
	the access/voice service provider as well as communicated by the AIP/		the access/voice service provider as well as communicated by the AIP/
	VSP, responsibility for location validity can be attributed entirely		VSP, responsibility for location validity can be attributed entirely
	to a single party, namely the AIP/VSP.		to a single party, namely the AIP/VSP.
	skipping to change at page 17, line 34 ¶		skipping to change at page 18, line 10 ¶
	gain fraudulent use of services and to divert emergency calls to non-		gain fraudulent use of services and to divert emergency calls to non-
	emergency sites. [RFC5069] also describes attacks against		emergency sites. [RFC5069] also describes attacks against
	individuals, including attempts to prevent an individual from		individuals, including attempts to prevent an individual from
	receiving aid, or to gain information about an emergency.		receiving aid, or to gain information about an emergency.
	"Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats		"Threat Analysis of the Geopriv Protocol" [RFC3694] describes threats
	against geographic location privacy, including protocol threats,		against geographic location privacy, including protocol threats,
	threats resulting from the storage of geographic location data, and		threats resulting from the storage of geographic location data, and
	threats posed by the abuse of information.		threats posed by the abuse of information.
	This document focuses on threats deriving from the introduction of
	untrustworthy location information by end hosts, regardless of
	whether this occurs intentionally or unintentionally.
	Although it is important to ensure that location information cannot		Although it is important to ensure that location information cannot
	be faked there will be a larger number of GPS-enabled devices out		be faked there will be many GPS-enabled devices that will find it
	there that will find it difficult to utilize any of the security		difficult to utilize any of the security mechanisms described in
	mechanisms described in Section 5. It is unlikely that end users		Section 5. It is also unlikely that users will be willing to upload
	will upload their location information for "verification" to a nearby		their location information for "verification" to a nearby location
	location server located in the access network.		server located in the access network.
	Given the practical and operational limitations in the technology, it
	may be worthwhile to consider whether the goals of trustworthy
	location, as for example defined by NENA i2 [NENA-i2], are
	attainable, or whether lesser goals (such as auditability) should be
	substituted instead.
	The goal of auditability is to enable an investigator to determine		While auditability is an important deterrent, it is likely to be of
	the source of a rogue emergency call after the fact. Since such an		most benefit in situations where attacks on the emergency services
	investigation can rely on audit logs provided under court order, the		system are likely to be relatively infrequent, since the resources
	information available to the investigator could be considerably		required to pursue an investigation are likely to be considerable.
	greater than that present in messages conveyed in the emergency call.
	As a consequence the emergency caller becomes accountable for his
	actions. For example, in such a situation, information relating to
	the owner of the unlinked pseudonym could be provided to
	investigators, enabling them to unravel the chain of events that lead
	to the attack. Auditability is likely to be of most benefits in
	situations where attacks on the emergency services system are likely
	to be relatively infrequent, since the resources required to pursue
	an investigation are likely to be considerable.
	Where attacks are frequent and continuous, a reliance on non-		Where attacks are frequent and continuous, automated mechanisms are
	automated mechanisms is unlikely to be satisfactory. As such,		required. For example, mechanisms to exchange audit trails
	mechanisms to exchange audit trails information in a standardized		information in a standardized format between ISPs and PSAPs / VSPs
	format between ISPs and PSAPs / VSPs and PSAPs or heuristics to		and PSAPs or heuristics to distinguish potentially fraudulent
	distinguish potentially fraudulent emergency calls from real		emergency calls from real emergencies might be valuable.
	emergencies might be valuable for the emergency services community.
	7. IANA Considerations		7. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	8. Acknowledgments		8. Acknowledgments
	We would like to thank the members of the IETF ECRIT and the IETF		We would like to thank the members of the IETF ECRIT and the IETF
	GEOPRIV working group for their input to the discussions related to		GEOPRIV working group for their input to the discussions related to
	this topic. We would also like to thank Andrew Newton, Murugaraj		this topic. We would also like to thank Andrew Newton, Murugaraj
	skipping to change at page 19, line 6 ¶		skipping to change at page 19, line 7 ¶
	Warner, J. S. and R. G. Johnston, "GPS Spoofing		Warner, J. S. and R. G. Johnston, "GPS Spoofing
	Countermeasures", Los Alamos research paper LAUR-03-6163,		Countermeasures", Los Alamos research paper LAUR-03-6163,
	December 2003.		December 2003.
	[I-D.thomson-geopriv-location-dependability]		[I-D.thomson-geopriv-location-dependability]
	Thomson, M. and J. Winterbottom, "Digital Signature Methods		Thomson, M. and J. Winterbottom, "Digital Signature Methods
	for Location Dependability", draft-thomson-geopriv-location-		for Location Dependability", draft-thomson-geopriv-location-
	dependability-07 (work in progress), March 2011.		dependability-07 (work in progress), March 2011.
	[I-D.ietf-geopriv-deref-protocol]		[I-D.ietf-geopriv-deref-protocol]
	Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson,		Winterbottom, J., Tschofenig, H., Schulzrinne, H. and M.
	M., and M. Dawson, "A Location Dereferencing Protocol Using		Thomson, "A Location Dereferencing Protocol Using HELD",
	HELD", draft-ietf-geopriv-deref-protocol-04 (work in		draft-ietf-geopriv-deref-protocol-07 (work in progress), July
	progress), October 2011.		2012.
	[IEEE-802.11y]		[IEEE-802.11y]
	Information technology - Telecommunications and information		Information technology - Telecommunications and information
	exchange between systems - Local and metropolitan area		exchange between systems - Local and metropolitan area
	networks - Specific requirements - Part 11: Wireless LAN		networks - Specific requirements - Part 11: Wireless LAN
	Medium Access Control (MAC) and Physical Layer (PHY)		Medium Access Control (MAC) and Physical Layer (PHY)
	specifications Amendment 3: 3650-3700 MHz Operation in USA,		specifications Amendment 3: 3650-3700 MHz Operation in USA,
	November 2008.		November 2008.
	[LLDP-MED]		[LLDP-MED]
End of changes. 23 change blocks.
	113 lines changed or deleted		102 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/