< draft-ietf-ecrit-trustworthy-location-01.txt		draft-ietf-ecrit-trustworthy-location-02.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: April 25, 2011 Columbia University		Expires: November 25, 2011 Columbia University
	B. Aboba		B. Aboba (ed.)
	Microsoft Corporation		Microsoft Corporation
	24 October 2010		24 May 2011
	Trustworthy Location Information		Trustworthy Location Information
	draft-ietf-ecrit-trustworthy-location-01.txt		draft-ietf-ecrit-trustworthy-location-02.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, it is important to be able to determine whether
	location information is trustworthy.		location information is trustworthy.
	This document outlines potential threats to trustworthy location and		This document outlines potential threats to trustworthy location and
	analyzes the operational issues with potential solutions.		analyzes the operational issues with potential solutions.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 April 25, 2011.		This Internet-Draft will expire on November 25, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 3, line 52 ¶		skipping to change at page 3, line 52 ¶
	calls can rise dramatically. For example, where emergency calls have		calls can rise dramatically. For example, where emergency calls have
	been allowed from handsets lacking a SIM card, or where ownership of		been allowed from handsets lacking a SIM card, or where ownership of
	the SIM card cannot be determined, the frequency of nuisance calls		the SIM card cannot be determined, the frequency of nuisance calls
	has often been unacceptably high [TASMANIA][UK][SA].		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 public switched telephone network (PSTN) and
	public land mobile network (PLMN) no longer hold. While the local		public land mobile network (PLMN) no longer hold. While the local
	telephone company provides both physical access and the phone		telephone company provides both physical access and the phone
	service, with VoIP there is a split between the role of the Access		service, with VoIP there is a split between the role of the Access
	Infrastructure Provider (AIP), the Application (Voice) Service		Infrastructure Provider (AIP), and the Application (Voice) Service
	Provider (VSP), and possibly a Location Service Provider (LSP). The		Provider (VSP). The VSP may be located far away from the AIP and may
	VSP may be located far away from the AIP and may either have no		either have no business relationship with the AIP or may be a
	business relationship with the AIP or may be a competitor. It is		competitor. It is also likely that the VSP will have no relationship
	also likely that the VSP will have no relationship with the PSAP.		with the PSAP.
	The LSP may have no relationship with the AIP, the VSP, or the PSAP,
	Standardization organizations have developed mechanisms to make civic		In some situations it is possible for the end host to determine its
	and geodetic location available to the end host, including LLDP-MED		own location using technology such as the Global Positioning System
	[LLDP-MED], DHCP extensions [RFC4776][RFC3825], HELD [RFC5985], or		(GPS). Where the end host cannot determine location on its own,
			mechanisms have been standardized to make civic and geodetic location
			available to the end host, including LLDP-MED [LLDP-MED], DHCP
			extensions [RFC4776][I-D.ietf-geopriv-rfc3825bis], HELD [RFC5985], or
	link-layer specifications such as [IEEE-802.11y]. The server		link-layer specifications such as [IEEE-802.11y]. The server
	offering this information is usually called a Location Information		offering this information is known as a Location Information Server
	Server (LIS). This LIS may be deployed by an AIP, or it may be run		(LIS). The LIS may be deployed by an AIP, or it may be run by a
	by a third party LSP, which may have no relatinoship with the AIP,		Location Service Provider (LSP) which may have no relationship with
	the VSP or the PSAP. More common with high-quality cellular devices		the AIP, the VSP or the PSAP. The location information is then
	is the ability for the end host itself to determine its own location		provided, by reference or value, to the service-providing entities,
	using GPS. The location information is then provided, by reference		i.e. location recipients, via application protocols, such as HTTP,
	or value, to the service-providing entities, i.e. location		SIP or XMPP.
	recipients, via application protocols, such as HTTP, SIP or XMPP.
	This document investigates security threats in Section 3, and		This document investigates security threats in Section 3, and
	outlines potential solutions in Section 4. Operational		outlines potential solutions in Section 4. Operational
	considerations are provided in Section 5 and conclusions are		considerations are provided in Section 5 and security considerations
	discussed in Section 6.		are discussed in Section 6.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	This document uses terms from [RFC5012] Section 3.		This document uses terms from [RFC5012] Section 3.
	3. Threats		3. Threats
	skipping to change at page 7, line 36 ¶		skipping to change at page 7, line 36 ¶
	each other's location.		each other's location.
	3.2. Identity Spoofing		3.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 AIP 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 nuisance emergency call. Although endpoint information		initiate a nuisance emergency call. Although endpoint information
	such as the IP or MAC address may have been logged, tying this back		such as the IP or MAC address may have been logged, tying this back
	skipping to change at page 8, line 27 ¶		skipping to change at page 8, line 27 ¶
	4.1. Location Signing		4.1. Location Signing
	One way to avoid location spoofing is to let a trusted location		One way to avoid location spoofing is to let a trusted location
	server sign the location information before it is sent to the end		server sign the location information before it is sent to the end
	host, i.e., the entity subject to the location determination process.		host, i.e., the entity subject to the location determination process.
	The signed location information is then verified by the location		The signed location information is then verified by the location
	recipient and not by the target. Figure 1 shows the communication		recipient and not by the target. Figure 1 shows the communication
	model with the target requesting signed location in step (a), the		model with the target requesting signed location in step (a), the
	location server returns it in step (b) and it is then conveyed to the		location server returns it in step (b) and it is then conveyed to the
	location recipient in step (c) who verifies it. For SIP, the		location recipient in step (c) who verifies it. For SIP, the
	procedures described in [I-D.ietf-sip-location-conveyance] are		procedures described in [I-D.ietf-sipcore-location-conveyance] are
	applicable for location conveyance.		applicable for location conveyance.
	+-----------+ +-----------+		+-----------+ +-----------+
	| | | Location |		| | | Location |
	| LIS | | Recipient |		| LIS | | Recipient |
	| | | |		| | | |
	+-+-------+-+ +----+------+		+-+-------+-+ +----+------+
	^ | --^		^ | --^
	| | --		| | --
	Geopriv |Req. | --		Geopriv |Req. | --
	skipping to change at page 15, line 34 ¶		skipping to change at page 15, line 34 ¶
	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 whether they are significantly different		certificate issuance, and whether they are significantly different
	from say, requirements for issuance of an SSL/TLS web certificate.		from say, requirements for issuance of an SSL/TLS web certificate.
	5.1.3. Location by Reference		5.1.3. 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. With the		deference the LbyR in order to obtain location. With the
	introduction of location by reference concept two authorization		introduction of location by reference concept two authorization
	models were developed, see [I-D.winterbottom-geopriv-deref-protocol],		models were developed, see [I-D.ietf-geopriv-deref-protocol], namely
	namely the "Authorization by Possession" and "Authorization via		the "Authorization by Possession" and "Authorization via Access
	Access Control Lists" model. With the "Authorization by Possession"		Control Lists" model. With the "Authorization by Possession" model
	model everyone in possession of the reference is able to obtain the		everyone in possession of the reference is able to obtain the
	corresponding location information. This might, however, be		corresponding location information. This might, however, be
	incompatible with other requirements typically imposed by AIPs, such		incompatible with other requirements typically imposed by AIPs, such
	as location hiding (see [I-D.ietf-ecrit-location-hiding-req]). As		as location hiding (see [I-D.ietf-ecrit-location-hiding-req]). As
	such, the "Authorization via Access Control Lists" model is likely to		such, the "Authorization via Access Control Lists" model is likely to
	be the preferred model for many AIPs and subject for discussion in		be the preferred model for many AIPs and subject for discussion in
	the subsequent paragraphs.		the subsequent paragraphs.
	Just as with PIDF-LO signing, the operational considerations in		Just as with PIDF-LO signing, the operational considerations in
	managing credentials for use in LbyR dereferencing can be		managing credentials for use in LbyR dereferencing can be
	considerable without the introduction of some kind of hierarchy. It		considerable without the introduction of some kind of hierarchy. It
	skipping to change at page 18, line 48 ¶		skipping to change at page 18, line 48 ¶
	9. References		9. References
	9.1. Informative References		9.1. Informative References
	[GPSCounter]		[GPSCounter]
	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.ietf-geopriv-rfc3825bis]
			Polk, J., Linsner, M., Thomson, M. and B. Aboba, "Dynamic Host
			Configuration Protocol Options for Coordinate-based Location
			Configuration Information", draft-ietf-geopriv-
			rfc3825bis-17.txt (work in progress), February 2011.
	[I-D.ietf-ecrit-location-hiding-req]		[I-D.ietf-ecrit-location-hiding-req]
	Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A.		Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A.
	Kuett, "Location Hiding: Problem Statement and Requirements",		Kuett, "Location Hiding: Problem Statement and Requirements",
	draft-ietf-ecrit-location-hiding-req-04 (work in progress),		draft-ietf-ecrit-location-hiding-req-04 (work in progress),
	February 2010.		February 2010.
	[I-D.ietf-sip-location-conveyance]		[I-D.ietf-sipcore-location-conveyance]
	Polk, J. and B. Rosen, "Location Conveyance for the Session		Polk, J. and B. Rosen, "Location Conveyance for the Session
	Initiation Protocol", draft-ietf-sip-location-conveyance-13		Initiation Protocol", draft-ietf-sipcore-location-
	(work in progress), March 2009.		conveyance-08.txt (work in progress), May 2011.
	[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-06 (work in progress), August 2010.		dependability-07 (work in progress), March 2011.
	[I-D.winterbottom-geopriv-deref-protocol]		[I-D.ietf-geopriv-deref-protocol]
	Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson,		Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson,
	M., and M. Dawson, "A Location Dereferencing Protocol Using		M., and M. Dawson, "A Location Dereferencing Protocol Using
	HELD", draft-winterbottom-geopriv-deref-protocol-05 (work in		HELD", draft-ietf-geopriv-deref-protocol-02 (work in
	progress), January 2010.		progress), December 2010.
	[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]
	skipping to change at page 20, line 5 ¶		skipping to change at page 20, line 12 ¶
	[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.		[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
	Polk, "Geopriv Requirements", RFC 3693, February 2004.		Polk, "Geopriv Requirements", RFC 3693, February 2004.
	[RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat		[RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat
	Analysis of the Geopriv Protocol", RFC 3694, February 2004.		Analysis of the Geopriv Protocol", RFC 3694, February 2004.
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	Levkowetz, "Extensible Authentication Protocol (EAP)", RFC		Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
	3748, June 2004.		3748, June 2004.
	[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
	Configuration Protocol Option for Coordinate-based Location
	Configuration Information", RFC 3825, July 2004.
	[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic		[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
	Configuration of IPv4 Link-Local Addresses", RFC 3927, May		Configuration of IPv4 Link-Local Addresses", RFC 3927, May
	2005.		2005.
	[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for		[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for
	Bridges", RFC 4188, September 2005.		Bridges", RFC 4188, September 2005.
	[RFC4293] Routhier, S., "Management Information Base for the Internet		[RFC4293] Routhier, S., "Management Information Base for the Internet
	Protocol (IP)", RFC 4293, April 2006.		Protocol (IP)", RFC 4293, April 2006.
	skipping to change at page 21, line 48 ¶		skipping to change at page 21, line 51 ¶
	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
	Bernard Aboba		Bernard Aboba
	Microsoft Corporation		Microsoft Corporation
	One Microsoft Way		One Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	US		US
	Email: bernarda@microsoft.com		Email: bernard_aboba@hotmail.com
End of changes. 20 change blocks.
	42 lines changed or deleted		45 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/