< draft-ietf-ecrit-trustworthy-location-08.txt		draft-ietf-ecrit-trustworthy-location-09.txt >
	ECRIT Working Group H. Tschofenig		ECRIT Working Group H. Tschofenig
	INTERNET-DRAFT Nokia Siemens Networks		INTERNET-DRAFT ARM Ltd.
	Category: Informational H. Schulzrinne		Category: Informational H. Schulzrinne
	Expires: July 24, 2014 Columbia University		Expires: September 24, 2014 Columbia University
	B. Aboba (ed.)		B. Aboba (ed.)
	Microsoft Corporation		Microsoft Corporation
	21 January 2014		17 March 2014
	Trustworthy Location		Trustworthy Location
	draft-ietf-ecrit-trustworthy-location-08.txt		draft-ietf-ecrit-trustworthy-location-09.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, the trustworthiness of location information is		roadside assistance, the trustworthiness of location information is
	critically important.		critically important.
	This document describes how to convey location in a manner that is		This document describes how to convey location in a manner that is
	inherently secure and reliable. It also provides guidelines for		inherently secure and reliable. It also provides guidelines for
	assessing the trustworthiness of location information.		assessing the trustworthiness of location information.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 July 24, 2014.		This Internet-Draft will expire on September 24, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	current practices for dealing with false emergency calls, which in		current practices for dealing with false emergency calls, which in
	certain European countries can constitute as much as 70% of all		certain European countries can constitute as much as 70% of all
	emergency calls. Reducing the number of prank calls represents a		emergency calls. Reducing the number of prank calls represents a
	challenge, since emergency services authorities in most countries are		challenge, since emergency services authorities in most countries are
	required to answer every call (whenever possible). Where the caller		required to answer every call (whenever possible). Where the caller
	cannot be identified, the ability to prosecute is limited.		cannot be identified, the ability to prosecute is limited.
	Since prank emergency calls can endanger bystanders or emergency		Since prank emergency calls can endanger bystanders or emergency
	services personnel, or divert resources away from legitimate		services personnel, or divert resources away from legitimate
	emergencies, they can be life threatening. A particularly dangerous		emergencies, they can be life threatening. A particularly dangerous
	form of prank call is "swatting" - an prank emergency call that draws		form of prank call is "swatting" - a prank emergency call that draws
	a response from law enforcement (e.g. a fake hostage situation that		a response from law enforcement (e.g. a fake hostage situation that
	results in dispatching of a "Special Weapons And Tactics" (SWAT)		results in dispatching of a "Special Weapons And Tactics" (SWAT)
	team). In 2008 the FBI issued a warning [Swatting] about an increase		team). In 2008 the Federal Bureau of Investigation (FBI) issued a
	in the frequency and sophistication of these attacks.		warning [Swatting] about an increase in the frequency and
			sophistication of these attacks.
	Many documented cases of "swatting" involve not only the faking of an		Many documented cases of "swatting" involve not only the faking of an
	emergency, but also the absence of accurate caller identification and		emergency, but also the absence of accurate caller identification and
	the delivery of misleading location data. Today these attacks are		the delivery of misleading location data. Today these attacks are
	often carried out by providing false caller identification, since for		often carried out by providing false caller identification, since for
	circuit-switched calls from landlines, location provided to the PSAP		circuit-switched calls from landlines, location provided to the
	is determined from a lookup using the calling telephone number. With		Public Safety Answering Point (PSAP) is determined from a lookup
	IP-based emergency services, in addition to the potential for false		using the calling telephone number. With IP-based emergency
	caller identification, it is also possible to attach misleading		services, in addition to the potential for false caller
	location information to the emergency call.		identification, it is also possible to attach misleading location
			information to the emergency call.
	Ideally, a call taker at a Public Service Answering Point (PSAP)		Ideally, a call taker at a PSAP should be put in the position to
	should be put in the position to assess, in real-time, the level of		assess, in real-time, the level of trust that can be placed on the
	trust that can be placed on the information provided within a call.		information provided within a call. This includes automated location
	This includes automated location conveyed along with the call and		conveyed along with the call and location information communicated by
	location information communicated by the caller, as well as identity		the caller, as well as identity information about the caller. Where
	information about the caller. Where real-time assessment is not		real-time assessment is not possible, it is important to be able to
	possible, it is important to be able to determine the source of the		determine the source of the call in a post-mortem, so as to be able
	call in a post-mortem, so as to be able to enforce accountability.		to enforce accountability.
	This document defines terminology (including the meaning of		This document defines terminology (including the meaning of
	"trustworthy location") in Section 1.1, investigates security threats		"trustworthy location") in Section 1.1, investigates security threats
	in Section 2, outlines potential solutions in Section 3, covers trust		in Section 2, outlines potential solutions in Section 3, covers trust
	assessment in Section 4 and discusses security considerations in		assessment in Section 4 and discusses security considerations in
	Section 5.		Section 5.
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 40 ¶
	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
	which a Recipient (Target or Third-Party) obtains location		which a Recipient (Target or Third-Party) obtains location
	information.		information.
	Additionally, the terms Location-by-Value (LbyV), Location-by-		Additionally, the terms Location-by-Value (LbyV), Location-by-
	Reference (LbyR), Location Configuration Protocol, Location		Reference (LbyR), Location Configuration Protocol, Location
	Dereference Protocol, and Location URI are re-used from "Requirements		Dereference Protocol, and Location Uniform Resource Identifier (URI)
	for a Location-by-Reference Mechanism" [RFC5808].		are re-used from "Requirements for a Location-by-Reference Mechanism"
			[RFC5808].
	"Trustworthy Location" is defined as location information that can be		"Trustworthy Location" is defined as location information that can be
	attributed to a trusted source, has been protected against		attributed to a trusted source, has been protected against
	modification in transmit, and has been assessed as trustworthy.		modification in transmit, and has been assessed as trustworthy.
	"Location Trust Assessment" refers to the process by which the		"Location Trust Assessment" refers to the process by which the
	reliability of location information can be assessed. This topic is		reliability of location information can be assessed. This topic is
	discussed in Section 4.		discussed in Section 4.
	The following additional terms apply to location spoofing:		The following additional terms apply to location spoofing:
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 18 ¶
	location other than where they are currently located. In some cases,		location other than where they are currently located. In some cases,
	place shifting can be limited in range (e.g., within the coverage		place shifting can be limited in range (e.g., within the coverage
	area of a particular cell tower).		area of a particular cell tower).
	"Time Shifting" is where the attacker uses or re-uses location		"Time Shifting" is where the attacker uses or re-uses location
	information that was valid in the past, but is no longer valid		information that was valid in the past, but is no longer valid
	because the attacker has moved.		because the attacker has moved.
	"Location Theft" is where the attacker captures a Target's location		"Location Theft" is where the attacker captures a Target's location
	information and presents it as their own. Location theft can occur		information and presents it as their own. Location theft can occur
	on a one-off basis, or may be continuous (e.g., where the attacker		in a single instance, or may be continuous (e.g., where the attacker
	has gained control over the victim's device). Location theft may		has gained control over the victim's device). Location theft may
	also be combined with time shifting to present someone else's		also be combined with time shifting to present someone else's
	location information after the original Target has moved. Where the		location information after the original Target has moved. Where the
	Target and attacker collude, the term "location swapping" is used.		Target and attacker collude, the term "location swapping" is used.
	2. Threats		2. Threats
	While previous IETF documents have analyzed aspects of the security		While previous IETF documents have analyzed aspects of the security
	of emergency services or threats to geographic location privacy,		of emergency services or threats to geographic location privacy,
	those documents do not cover the threats arising from unreliable		those documents do not cover the threats arising from unreliable
	skipping to change at page 5, line 49 ¶		skipping to change at page 6, line 4 ¶
	This document focuses on threats from attackers providing false		This document focuses on threats from attackers providing false
	location information within emergency calls. Since we do not focus		location information within emergency calls. Since we do not focus
	on attackers gaining control of infrastructure elements (e.g.,		on attackers gaining control of infrastructure elements (e.g.,
	location servers, call route servers) or the emergency services IP		location servers, call route servers) or the emergency services IP
	network, the threats arise from end hosts. In addition to threats		network, the threats arise from end hosts. In addition to threats
	arising from the intentional forging of caller identification or		arising from the intentional forging of caller identification or
	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 provide location		which may be vulnerable to attack or may not provide location
	accuracy suitable for emergency purposes.		accuracy suitable for emergency purposes.
	To provide a structured analysis we distinguish between three		To provide a structured analysis we distinguish between three
	adversary models:		adversary models:
	External adversary model: The end host, e.g., an emergency caller		External adversary model: The end host, e.g., an emergency caller
	whose location is going to be communicated, is honest and the		whose location is going to be communicated, is honest and the
	adversary may be located between the end host and the location		adversary may be located between the end host and the location
	server or between the end host and the PSAP. None of the		server or between the end host and the PSAP. None of the
	emergency service infrastructure elements act maliciously.		emergency service intrastructure elements act maliciously.
	Malicious infrastructure adversary model: The emergency call routing		Malicious infrastructure adversary model: The emergency call routing
	elements, such as the LIS, the LoST infrastructure, used for		elements, such as the Location Information Server (LIS), the
			Location-to-Service Translation (LoST) infrastructure, used for
	mapping locations to PSAP address, or call routing elements, may		mapping locations to PSAP address, or call routing elements, may
	act maliciously.		act maliciously.
	Malicious end host adversary model: The end host itself acts		Malicious end host adversary model: The end host itself acts
	maliciously, whether the owner is aware of this or whether it is		maliciously, whether the owner is aware of this or whether it is
	acting under the control of a third party.		acting under the control of a third party.
	In this document, we focus only on the malicious end host adversary		In this document, we focus only on the malicious end host adversary
	model.		model.
	2.1. Location Spoofing		2.1. Location Spoofing
	An adversary can provide false location information in an emergency		An adversary can provide false location information in an emergency
	call in order to misdirect emergency resources. For calls		call in order to misdirect emergency resources. For calls
	originating within the PSTN or via a fixed Voice over IP service,		originating within the Public Switched Telephone Network (PSTN) or
	this attack can be carried out via caller-id spoofing. For example,		via a fixed Voice over Internet Protocol (VoIP) service, this attack
	where a Voice Service Provider enables setting of the outbound caller		can be carried out via caller-id spoofing. For example, where a
			Voice Service Provider enables setting of the outbound caller
	identification without checking it against the authenticated		identification without checking it against the authenticated
	identity, forging caller identification is trivial. Where an		identity, forging caller identification is trivial. Where an
	attacker can gain entry to a PBX, they can then subsequently use that		attacker can gain entry to a Private Branch Exchange (PBX), they can
	access to launch a denial of service attack against the PSAP, or to		then subsequently use that access to launch a denial of service
	make fraudulent emergency calls.		attack against the PSAP, or to make fraudulent emergency calls.
	Where location is attached to the emergency call by an end host,		Where location is attached to the emergency call by an end host,
	several avenues are available to provide false location information:		several avenues are available to provide false location information:
	1. The end host could fabricate a PIDF-LO and convey it within an		1. The end host could fabricate a Presence Information Data
	emergency call;		Format Location Object (PIDF-LO) and convey it within an emergency
			call;
	2. The VSP (and indirectly a LIS) could be fooled into using the		2. The Voice Service Provider (VSP) (and indirectly a LIS) could
	wrong identity (such as an IP address) for location lookup,		be fooled into using the wrong identity (such as an IP address)
	thereby providing the end host with misleading location		for location lookup, thereby providing the end host with
	information;		misleading location information;
	3. Inaccurate or out-of-date information (such as spoofed GPS		3. Inaccurate or out-of-date information (such as spoofed Global
	signals, a stale wiremap or an inaccurate access point location		Positioning System (GPS) signals, a stale wiremap or an inaccurate
	database) could be utilized by the LIS or the end host in its		access point location database) could be utilized by the LIS or
	location determination, thereby leading to an inaccurate		the end host in its location determination, thereby leading to an
	determination of location.		inaccurate determination of location.
	The following represent examples of location spoofing:		The following represent examples of location spoofing:
	Place shifting: Trudy, the adversary, pretends to be at an		Place shifting: Trudy, the adversary, pretends to be at an
	arbitrary location.		arbitrary location.
	Time shifting: Trudy pretends to be at a location she was a		Time shifting: Trudy pretends to be at a location she was a
	while ago.		while ago.
	Location theft: Trudy observes Alice's location and replays		Location theft: Trudy observes Alice's location and replays
	it as her own.		it as her own.
	Location swapping: Trudy and Malory collude and swap location		Location swapping: Trudy and Malory collude and swap location
	information, pretending to be in each other's location.		information, pretending to be in each other's location.
	2.2. Identity Spoofing		2.2. Identity Spoofing
	With calls originating on an IP network, at least two forms of		With calls originating on an IP network, at least two forms of
	identity are relevant, with the distinction created by the split		identity are relevant, with the distinction created by the split
	between the AIP and the VSP:		between the Internet Access Provider (IAP) and the VSP:
	(a) network access identity such as might be determined via		(a) network access identity such as might be determined via
	authentication (e.g., using the Extensible Authentication Protocol		authentication (e.g., using the Extensible Authentication Protocol
	(EAP) [RFC3748]);		(EAP) [RFC3748]);
	(b) caller identity, such as might be determined from authentication		(b) caller identity, such as might be determined from authentication
	of the emergency caller at the VoIP application layer.		of the emergency caller at the VoIP application layer.
	If the adversary did not authenticate itself to the VSP, then		If the adversary did not authenticate itself to the VSP, then
	accountability may depend on verification of the network access		accountability may depend on verification of the network access
	identity. However, this also may not have been authenticated, such		identity. However, this also may not have been authenticated, such
	as in the case where an open IEEE 802.11 Access Point is used to		as in the case where an open IEEE 802.11 Access Point is used to
	initiate a prank emergency call. Although endpoint information such		initiate a prank emergency call. Although endpoint information such
	as the IP or MAC address may have been logged, tying this back to the		as the IP or MAC address may have been logged, tying this back to the
	device owner may be challenging.		device owner may be challenging.
	Unlike the existing telephone system, VoIP emergency calls can		Unlike the existing telephone system, VoIP emergency calls can
	provide a strong identity that need not necessarily be coupled to a		provide a strong identity that need not necessarily be coupled to a
	business relationship with the AIP, ISP or VSP. However, due to the		business relationship with the IAP, Internet Service Provider (ISP)
	time-critical nature of emergency calls, multi-layer authentication		or VSP. However, due to the time-critical nature of emergency calls,
	is undesirable, so that in most cases, only the device placing the		multi-layer authentication is undesirable, so that in most cases,
	call will be able to be identified, making the system vulnerable to		only the device placing the call will be able to be identified,
	bot-net attacks. Furthermore, deploying additional credentials for		making the system vulnerable to bot-net attacks. Furthermore,
	emergency service purposes (such as certificates) increases costs,		deploying additional credentials for emergency service purposes (such
	introduces a significant administrative overhead and is only useful		as certificates) increases costs, introduces a significant
	if widely deployed.		administrative overhead and is only useful if widely deployed.
	3. Solutions		3. Solutions
	This section presents three mechanisms which can be used to convey		This section presents three mechanisms which can be used to convey
	location securely: signed location by value (Section 3.1), location		location securely: signed location by value (Section 3.1), location
	by reference (Section 3.2) and proxy added location (Section 3.3).		by reference (Section 3.2) and proxy added location (Section 3.3).
	In order to provide authentication and integrity protection for the		In order to provide authentication and integrity protection for the
	SIP messages conveying location, several security approaches are		Session Initiation Protocol (SIP) messages conveying location,
	available. It is possible to ensure that modification of the		several security approaches are available. It is possible to ensure
	identity and location in transit can be detected by the location		that modification of the identity and location in transit can be
	recipient (e.g., the PSAP), using cryptographic mechanisms, as		detected by the location recipient (e.g., the PSAP), using
	described in "Enhancements for Authenticated Identity Management in		cryptographic mechanisms, as described in "Enhancements for
	the Session Initiation Protocol" [RFC4474]. However, compatibility		Authenticated Identity Management in the Session Initiation Protocol"
	with Session Border Controllers (SBCs) that modify integrity-		[RFC4474]. However, compatibility with Session Border Controllers
	protected headers has proven to be an issue in practice. As a		(SBCs) that modify integrity-protected headers has proven to be an
	result, SIP over TLS is currently a more deployable mechanism to		issue in practice. As a result, SIP over Transport Layer Security
	provide per-message authentication and integrity protection hop-by-		(TLS) is currently a more deployable mechanism to provide per-message
	hop.		authentication and integrity protection hop-by-hop.
	3.1. Signed Location by Value		3.1. Signed Location by Value
	With location signing, a location server signs the location		With location signing, a location server signs the location
	information before it is sent to the end host, (the entity subject to		information before it is sent to the end host, (the entity subject to
	the location determination process). The signed location information		the location determination process). The signed location information
	is then verified by the location recipient and not by the target. A		is then verified by the location recipient and not by the target. A
	straw-man proposal for location signing is provided in "Digital		straw-man proposal for location signing is provided in "Digital
	Signature Methods for Location Dependability" [I-D.thomson-geopriv-		Signature Methods for Location Dependability" [I-D.thomson-geopriv-
	location-dependability].		location-dependability].
	skipping to change at page 11, line 21 ¶		skipping to change at page 11, line 21 ¶
	3. The signature should include a timestamp.		3. The signature should include a timestamp.
	4. Where possible, the Location Object should be refreshed		4. Where possible, the Location Object should be refreshed
	periodically, with the signature (and thus the timestamp)		periodically, with the signature (and thus the timestamp)
	being refreshed as a consequence.		being refreshed as a consequence.
	5. Anti-spoofing mechanisms should be applied to the Location		5. Anti-spoofing mechanisms should be applied to the Location
	Reporting method.		Reporting method.
	[Note: The term Valid Emergency Services Authority (VESA) refers		[Note: The term Valid Emergency Services Authority (VESA) refers
	to the root certificate authority.]		to the root certificate authority. VPC stands for VoIP
			Positioning Center and ERDB stands for the Emergency Service Zone
			Routing Database.]
	As noted above, signing of location objects implies the development		As noted above, signing of location objects implies the development
	of a trust hierarchy that would enable a certificate chain provided		of a trust hierarchy that would enable a certificate chain provided
	by the LIS operator to be verified by the PSAP. Rooting the trust		by the LIS operator to be verified by the PSAP. Rooting the trust
	hierarchy in VESA can be accomplished either by having the VESA		hierarchy in VESA can be accomplished either by having the VESA
	directly sign the LIS certificates, or by the creation of		directly sign the LIS certificates, or by the creation of
	intermediate CAs certified by the VESA, which will then issue		intermediate Certificate Authorities (CAs) certified by the VESA,
	certificates to the LIS. In terms of the workload imposed on the		which will then issue certificates to the LIS. In terms of the
	VESA, the latter approach is highly preferable. However, this raises		workload imposed on the VESA, the latter approach is highly
	the question of who would operate the intermediate CAs and what the		preferable. However, this raises the question of who would operate
	expectations would be.		the intermediate CAs and what the expectations would be.
	In particular, the question arises as to the requirements for LIS		In particular, the question arises as to the requirements for LIS
	certificate issuance, and how they would compare to requirements for		certificate issuance, and how they would compare to requirements for
	issuance of other certificates such as an SSL/TLS web certificate.		issuance of other certificates such as an SSL/TLS web certificate.
	3.2. Location by Reference		3.2. Location by Reference
	Location-by-reference was developed so that end hosts can avoid		Location-by-reference was developed so that end hosts can avoid
	having to periodically query the location server for up- to-date		having to periodically query the location server for up- to-date
	location information in a mobile environment. Additionally, if		location information in a mobile environment. Additionally, if
	skipping to change at page 12, line 39 ¶		skipping to change at page 12, line 42 ¶
	Figure 2: Location by Reference		Figure 2: Location by Reference
	Where location by reference is provided, the recipient needs to		Where location by reference is provided, the recipient needs to
	deference the LbyR in order to obtain location. The details for the		deference the LbyR in order to obtain location. The details for the
	dereferencing operations vary with the type of reference, such as a		dereferencing operations vary with the type of reference, such as a
	HTTP, HTTPS, SIP, SIPS URI or a SIP presence URI.		HTTP, HTTPS, SIP, SIPS URI or a SIP presence URI.
	For location-by-reference, the location server needs to maintain one		For location-by-reference, the location server needs to maintain one
	or several URIs for each target, timing out these URIs after a		or several URIs for each target, timing out these URIs after a
	certain amount of time. References need to expire to prevent the		certain amount of time. References need to expire to prevent the
	recipient of such a URL from being able to permanently track a host		recipient of such a Uniform Resource Locator (URL) from being able to
	and to offer garbage collection functionality for the location		permanently track a host and to offer garbage collection
	server.		functionality for the location server.
	Off-path adversaries must be prevented from obtaining the target's		Off-path adversaries must be prevented from obtaining the target's
	location. The reference contains a randomized component that		location. The reference contains a randomized component that
	prevents third parties from guessing it. When the location recipient		prevents third parties from guessing it. When the location recipient
	fetches up-to-date location information from the location server, it		fetches up-to-date location information from the location server, it
	can also be assured that the location information is fresh and not		can also be assured that the location information is fresh and not
	replayed. However, this does not address location swapping.		replayed. However, this does not address location swapping.
	With respect to the security of the de-reference operation, [RFC6753]		With respect to the security of the de-reference operation, [RFC6753]
	Section 6 states:		Section 6 states:
	skipping to change at page 14, line 11 ¶		skipping to change at page 14, line 14 ¶
	adversaries are not able to acquire this information is paramount.		adversaries are not able to acquire this information is paramount.
	Encryption, such as might be offered by TLS [RFC5246] or S/MIME		Encryption, such as might be offered by TLS [RFC5246] or S/MIME
	[RFC5751], protects the information from eavesdroppers.		[RFC5751], protects the information from eavesdroppers.
	Using possession as a basis for authorization means that, once		Using possession as a basis for authorization means that, once
	granted, authorization cannot be easily revoked. Cancellation of		granted, authorization cannot be easily revoked. Cancellation of
	a location URI ensures that legitimate users are also affected;		a location URI ensures that legitimate users are also affected;
	application of additional policy is theoretically possible but		application of additional policy is theoretically possible but
	could be technically infeasible. Expiration of location URIs		could be technically infeasible. Expiration of location URIs
	limits the usable time for a location URI, requiring that an		limits the usable time for a location URI, requiring that an
	attacker continue o learn new location URIs to retain access to		attacker continue to learn new location URIs to retain access to
	current location information.		current location information.
	In situations where "Authorization by Possession" is not suitable		In situations where "Authorization by Possession" is not suitable
	(such as where location hiding [RFC6444] is required), the		(such as where location hiding [RFC6444] is required), the
	"Authorization via Access Control Lists" model may be preferred.		"Authorization via Access Control Lists" model may be preferred.
	Without the introduction of hierarchy, it would be necessary for the		Without the introduction of hierarchy, it would be necessary for the
	PSAP to obtain client certificates or Digest credentials for all the		PSAP to obtain client certificates or Digest credentials for all the
	LISes in its coverage area, to enable it to successfully dereference		LISes in its coverage area, to enable it to successfully dereference
	LbyRs. In situations with more than a few LISes per PSAP, this would		LbyRs. In situations with more than a few LISes per PSAP, this would
	skipping to change at page 15, line 38 ¶		skipping to change at page 15, line 42 ¶
	Overriding location information provided by the user requires a		Overriding location information provided by the user requires a
	deployment where an intermediary necessarily knows better than an		deployment where an intermediary necessarily knows better than an
	end user -- after all, it could be that Alice has an on-board GPS,		end user -- after all, it could be that Alice has an on-board GPS,
	and the SIP intermediary only knows her nearest cell tower. Which		and the SIP intermediary only knows her nearest cell tower. Which
	is more accurate location information? Currently, there is no way		is more accurate location information? Currently, there is no way
	to tell which entity is more accurate or which is wrong, for that		to tell which entity is more accurate or which is wrong, for that
	matter. This document will not specify how to indicate which		matter. This document will not specify how to indicate which
	location is more accurate than another.		location is more accurate than another.
	The disadvantage of this approach is the need to deploy application		The disadvantage of this approach is the need to deploy application
	layer entities, such as SIP proxies, at AIPs or associated with AIPs.		layer entities, such as SIP proxies, at IAPs or associated with IAPs.
	This requires a standardized VoIP profile to be deployed at every end		This requires a standardized VoIP profile to be deployed at every end
	device and at every AIP. This might impose interoperability		device and at every IAP. This might impose interoperability
	challenges.		challenges.
	Additionally, the AIP needs to take responsibility for emergency		Additionally, the IAP needs to take responsibility for emergency
	calls, even for customers they have no direct or indirect		calls, even for customers they have no direct or indirect
	relationship with. To provide identity information about the		relationship with. To provide identity information about the
	emergency caller from the VSP it would be necessary to let the AIP		emergency caller from the VSP it would be necessary to let the IAP
	and the VSP to interact for authentication (see, for example,		and the VSP to interact for authentication (see, for example,
	[RFC4740]). This interaction along the Authentication, Authorization		"Diameter Session Initiation Protocol (SIP) Application" [RFC4740]).
	and Accounting infrastructure is often based on business		This interaction along the Authentication, Authorization and
	relationships between the involved entities. The AIP and the VSP are		Accounting infrastructure is often based on business relationships
	very likely to have no such business relationship, particularly when		between the involved entities. An arbitrary IAP and VSP are unlikely
	talking about an arbitrary VSP somewhere on the Internet. In case		to have a business relationship. In case the interaction between the
	that the interaction between the AIP and the VSP fails due to the		IAP and the VSP fails due to the lack of a business relationship then
	lack of a business relationship then typically a fall-back would be		typically a fall-back would be provided where no emergency caller
	provided where no emergency caller identity information is made		identity information is made available to the PSAP and the emergency
	available to the PSAP and the emergency call still has to be		call still has to be completed.
	completed.
	4. Location Trust Assessment		4. Location Trust Assessment
	The ability to assess the level of trustworthiness of conveyed		The ability to assess the level of trustworthiness of conveyed
	location information is important, since this makes it possible to		location information is important, since this makes it possible to
	understand how much value should be placed on location information,		understand how much value should be placed on location information,
	as part of the decision making process. As an example, if automated		as part of the decision making process. As an example, if automated
	location information is understood to be highly suspect, a call taker		location information is understood to be highly suspect, a call taker
	can put more effort into obtaining location information from the		can put more effort into obtaining location information from the
	caller.		caller.
	skipping to change at page 18, line 27 ¶		skipping to change at page 18, line 31 ¶
	LO elements is challenging, where LIS audit logs are available (such		LO elements is challenging, where LIS audit logs are available (such
	as where a law enforcement agency can present a subpoena), linking of		as where a law enforcement agency can present a subpoena), linking of
	a pseudonym to the device obtaining location can be accomplished in a		a pseudonym to the device obtaining location can be accomplished in a
	post-mortem.		post-mortem.
	Where attacks are frequent and continuous, automated mechanisms are		Where attacks are frequent and continuous, automated mechanisms are
	required. For example, it might be valuable to develop mechanisms to		required. For example, it might be valuable to develop mechanisms to
	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 CAPTCHA-style test may be applied to suspicious calls to lower the		a Completely Automated Public Touring test to tell Computers and
	risk from bot-nets, this is quite controversial for emergency		Humans Apart (CAPTCHA) may be applied to suspicious calls to lower
			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
	IP-based emergency services face a number of security threats that do		IP-based emergency services face a number of security threats that do
	not exist within the legacy system. In order to limit prank calls,		not exist within the legacy system. In order to limit prank calls,
	legacy emergency services rely on the ability to identify callers, as		legacy emergency services rely on the ability to identify callers, as
	well as on the difficulty of location spoofing for normal users. The		well as on the difficulty of location spoofing for normal users. The
	ability to ascertain identity is important, since the threat of		ability to ascertain identity is important, since the threat of
	punishment reduces prank calls; as an example, calls from pay phones		punishment reduces prank calls; as an example, calls from pay phones
	skipping to change at page 19, line 20 ¶		skipping to change at page 19, line 24 ¶
	a small-scale attack. Finally, first responder resources are scarce,		a small-scale attack. Finally, first responder resources are scarce,
	particularly during mass-casualty events.		particularly during mass-casualty events.
	Attackers may want to modify, prevent or delay emergency calls. In		Attackers may want to modify, prevent or delay emergency calls. In
	some cases, this will lead the PSAP to dispatch emergency personnel		some cases, this will lead the PSAP to dispatch emergency personnel
	to an emergency that does not exist and, hence, the personnel might		to an emergency that does not exist and, hence, the personnel might
	not be available to other callers. It might also be possible for an		not be available to other callers. It might also be possible for an
	attacker to impede the users from reaching an appropriate PSAP by		attacker to impede the users from reaching an appropriate PSAP by
	modifying the location of an end host or the information returned		modifying the location of an end host or the information returned
	from the mapping protocol. In some countries, regulators may not		from the mapping protocol. In some countries, regulators may not
	require the authenticated identity of the emergency caller, as is		require the authenticated identity of the emergency caller (e.g.
	true for PSTN-based emergency calls placed from pay phones or SIM-		emergency calls placed from PSTN pay phones or SIM-less cell phones).
	less cell phones today. Furthermore, if identities can easily be		Furthermore, if identities can easily be crafted (as it is the case
	crafted (as it is the case with many VoIP offerings today), then the		with many VoIP offerings today), then the value of emergency caller
	value of emergency caller authentication itself might be limited. As		authentication itself might be limited. As a consequence, an
	a consequence, an attacker can forge emergency call information		attacker can forge emergency call information without the chance of
	without the chance of being held accountable for its own actions.		being held accountable for its own actions.
	The above-mentioned attacks are mostly targeting individual emergency		The above-mentioned attacks are mostly targeting individual emergency
	callers or a very small fraction of them. If attacks are, however,		callers or a very small fraction of them. If attacks are, however,
	launched against the mapping architecture (see [RFC5582] or against		launched against the mapping architecture (see "Location-URL Mapping
	the emergency services IP network (including PSAPs), a larger region		Architecture and Framework" [RFC5582] or against the emergency
	and a large number of potential emergency callers are affected. The		services IP network (including PSAPs), a larger region and a large
	call takers themselves are a particularly scarce resource and if		number of potential emergency callers are affected. The call takers
	human interaction by these call takers is required then this can very		themselves are a particularly scarce resource and if human
			interaction by these call takers is required then this can very
	quickly have severe consequences.		quickly have severe consequences.
	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 many GPS-enabled devices that will find it		be faked there will be many GPS-enabled devices that will find it
	difficult to utilize any of the solutions described in Section 3. It		difficult to utilize any of the solutions described in Section 3. It
	is also unlikely that users will be willing to upload their location		is also unlikely that users will be willing to upload their location
	information for "verification" to a nearby location server located in		information for "verification" to a nearby location server located in
	the access network.		the access network.
	Nevertheless, it should be understood that mounting several of the		Nevertheless, it should be understood that mounting several of the
	attacks described in this document is non-trivial. Location theft		attacks described in this document is non-trivial. Location theft
	requires the attacker to be in proximity to the location to spoofed,		requires the attacker to be in proximity to the location being
	and location swapping requires the attacker to collude with someone		spoofed, and location swapping requires the attacker to collude with
	who was at the spoofed location. Time shifting attacks require that		someone who was at the spoofed location. Time shifting attacks
	the attacker visit the location and submit it before the location		require that the attacker visit the location and submit it before the
	information is considered stale, while travelling rapidly away from		location information is considered stale, while travelling rapidly
	that location to avoid apprehension. Obtaining a PIDF-LO from a		away from that location to avoid apprehension. Obtaining a PIDF-LO
	spoofed IP address requires that the attacker be on the path between		from a spoofed IP address requires that the attacker be on the path
	the HELD requester and the LIS.		between the HELD requester and the LIS.
	6. IANA Considerations		6. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	7. References		7. References
	7.1. Informative References		7.1. Informative References
	[DHCP-URI-OPT]		[DHCP-URI-OPT]
	skipping to change at page 22, line 18 ¶		skipping to change at page 22, line 25 ¶
	http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384		http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384
	[Swatting]		[Swatting]
	"Don't Make the Call: The New Phenomenon of 'Swatting',		"Don't Make the Call: The New Phenomenon of 'Swatting',
	Federal Bureau of Investigation, February 4, 2008,		Federal Bureau of Investigation, February 4, 2008,
	http://www.fbi.gov/news/stories/2008/february/swatting020408		http://www.fbi.gov/news/stories/2008/february/swatting020408
	[TASMANIA]		[TASMANIA]
	"Emergency services seek SIM-less calls block", ABC News		"Emergency services seek SIM-less calls block", ABC News
	Online, August 18, 2006,		Online, August 18, 2006,
	http://www.abc.net.au/news/newsitems/200608/s1717956.htm		http://www.abc.net.au/elections/tas/2006/news/stories/
			1717956.htm?elections/tas/2006/
	[UK] "Rapper makes thousands of prank 999 emergency calls to UK		[UK] "Rapper makes thousands of prank 999 emergency calls to UK
	police", Digital Journal, June 24, 2010,		police", Digital Journal, June 24, 2010,
	http://www.digitaljournal.com/article/293796?tp=1		http://www.digitaljournal.com/article/293796?tp=1
	Acknowledgments		Acknowledgments
	We would like to thank the members of the IETF ECRIT working group,		We would like to thank the members of the IETF ECRIT working group,
	including Marc Linsner, Henning Schulzrinne and Brian Rosen, for		including Marc Linsner, Henning Schulzrinne and Brian Rosen, for
	their input at IETF 85 that helped get this documented pointed in the		their input at IETF 85 that helped get this documented pointed in the
	right direction. We would also like to thank members of the IETF		right direction. We would also like to thank members of the IETF
	GEOPRIV WG, including Andrew Newton, Murugaraj Shanmugam, Martin		GEOPRIV WG, including Andrew Newton, Murugaraj Shanmugam, Martin
	Thomson, Richard Barnes and Matt Lepinski for their feedback to		Thomson, Richard Barnes and Matt Lepinski for their feedback to
	previous versions of this document.		previous versions of this document. Thanks also to Bert Wijnen and
			Meral Shirazipour who provided review comments in IETF last call.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		ARM Ltd.
	Linnoitustie 6		110 Fulbourn Rd
	Espoo 02600		Cambridge CB1 9NJ
	Finland		Great Britain
	Phone: +358 (50) 4871445		Email: Hannes.tschofenig@gmx.net
	Email: Hannes.Tschofenig@gmx.net		URI: http://www.tschofenig.priv.at
	URI: http://www.tschofenig.priv.at
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building, New York, NY 10027		450 Computer Science Building, New York, NY 10027
	US		US
	Phone: +1 212 939 7004		Phone: +1 212 939 7004
	Email: hgs@cs.columbia.edu		Email: hgs@cs.columbia.edu
	URI: http://www.cs.columbia.edu		URI: http://www.cs.columbia.edu
End of changes. 39 change blocks.
	118 lines changed or deleted		129 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/