< draft-ietf-ecrit-trustworthy-location-02.txt		draft-ietf-ecrit-trustworthy-location-03.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: November 25, 2011 Columbia University		Expires: October 4, 2012 Columbia University
	B. Aboba (ed.)		B. Aboba (ed.)
	Microsoft Corporation		Microsoft Corporation
	24 May 2011		4 April 2012
	Trustworthy Location Information		Trustworthy Location Information
	draft-ietf-ecrit-trustworthy-location-02.txt		draft-ietf-ecrit-trustworthy-location-03.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 November 25, 2011.		This Internet-Draft will expire on October 4, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 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
	skipping to change at page 4, line 14 ¶		skipping to change at page 4, line 14 ¶
	Provider (VSP). The VSP may be located far away from the AIP and may		Provider (VSP). The VSP may be located far away from the AIP and may
	either have no business relationship with the AIP or may be a		either have no business relationship with the AIP or may be a
	competitor. It is also likely that the VSP will have no relationship		competitor. It is also likely that the VSP will have no relationship
	with the PSAP.		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][I-D.ietf-geopriv-rfc3825bis], HELD [RFC5985], or		extensions [RFC4776][RFC6225], HELD [RFC5985], or link-layer
	link-layer specifications such as [IEEE-802.11y]. The server		specifications such as [IEEE-802.11y]. The server offering this
	offering this information is known as a Location Information Server		information is known as a Location Information Server (LIS). The LIS
	(LIS). The LIS may be deployed by an AIP, or it may be run by a		may be deployed by an AIP, or it may be run by a Location Service
	Location Service Provider (LSP) which may have no relationship with		Provider (LSP) which may have no relationship with the AIP, the VSP
	the AIP, the VSP or the PSAP. The location information is then		or the PSAP. The location information is then provided, by reference
	provided, by reference or value, to the service-providing entities,		or value, to the service-providing entities, i.e. location
	i.e. location recipients, via application protocols, such as HTTP,		recipients, via application protocols, such as HTTP, SIP or XMPP.
	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 security considerations		considerations are provided in Section 5 and security considerations
	are 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
	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-sipcore-location-conveyance] are		procedures described in [RFC6442] are applicable for location
	applicable for location conveyance.		conveyance.
	+-----------+ +-----------+		+-----------+ +-----------+
	| | | Location |		| | | Location |
	| LIS | | Recipient |		| LIS | | Recipient |
	| | | |		| | | |
	+-+-------+-+ +----+------+		+-+-------+-+ +----+------+
	^ | --^		^ | --^
	| | --		| | --
	Geopriv |Req. | --		Geopriv |Req. | --
	Location |Signed |Signed -- Geopriv		Location |Signed |Signed -- Geopriv
	skipping to change at page 15, line 40 ¶		skipping to change at page 15, line 40 ¶
	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.ietf-geopriv-deref-protocol], namely		models were developed, see [I-D.ietf-geopriv-deref-protocol], namely
	the "Authorization by Possession" and "Authorization via Access		the "Authorization by Possession" and "Authorization via Access
	Control Lists" model. With the "Authorization by Possession" model		Control Lists" model. With the "Authorization by Possession" 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 [RFC6444]). As such, the "Authorization via
	such, the "Authorization via Access Control Lists" model is likely to		Access Control Lists" model is likely to be the preferred model for
	be the preferred model for many AIPs and subject for discussion in		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
	does not seem reasonable for a PSAP to manage client certificates or		does not seem reasonable for a PSAP to manage client certificates or
	Digest credentials for all the LISes in its coverage area, so as to		Digest credentials for all the LISes in its coverage area, so as to
	enable it to successfully dereference LbyRs. In some respects, this		enable it to successfully dereference LbyRs. In some respects, this
	issue is even more formidable than the validation of signed PIDF-		issue is even more formidable than the validation of signed PIDF-
	LOs. While PIDF-LO signing credentials are provided to the LIS		LOs. While PIDF-LO signing credentials are provided to the LIS
	operator, in the case of de-referencing, the PSAP needs to be obtain		operator, in the case of de-referencing, the PSAP needs to be obtain
	skipping to change at page 18, line 48 ¶		skipping to change at page 18, line 46 ¶
	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]
	Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A.
	Kuett, "Location Hiding: Problem Statement and Requirements",
	draft-ietf-ecrit-location-hiding-req-04 (work in progress),
	February 2010.
	[I-D.ietf-sipcore-location-conveyance]
	Polk, J. and B. Rosen, "Location Conveyance for the Session
	Initiation Protocol", draft-ietf-sipcore-location-
	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-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., Thomson,
	M., and M. Dawson, "A Location Dereferencing Protocol Using		M., and M. Dawson, "A Location Dereferencing Protocol Using
	HELD", draft-ietf-geopriv-deref-protocol-02 (work in		HELD", draft-ietf-geopriv-deref-protocol-04 (work in
	progress), December 2010.		progress), October 2011.
	[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 21, line 5 ¶		skipping to change at page 20, line 37 ¶
	[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam,		[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam,
	"Security Threats and Requirements for Emergency Call Marking		"Security Threats and Requirements for Emergency Call Marking
	and Mapping", RFC 5069, January 2008.		and Mapping", RFC 5069, January 2008.
	[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and		[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and
	Framework", RFC 5582, September 2009.		Framework", RFC 5582, September 2009.
	[RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985,		[RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985,
	September 2010.		September 2010.
			[RFC6225] Polk, J., Linsner, M., Thomson, M. and B. Aboba, "Dynamic Host
			Configuration Protocol Options for Coordinate-based Location
			Configuration Information", RFC 6225, July 2011.
			[RFC6442] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance for
			the Session Initiation Protocol", RFC 6442, December 2011.
			[RFC6444] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A.
			Kuett, "Location Hiding: Problem Statement and Requirements",
			RFC 6444, January 2012.
	[SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in prank		[SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in prank
	calls", Arab News, May 4, 2010,		calls", Arab News, May 4, 2010,
	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]
End of changes. 11 change blocks.
	39 lines changed or deleted		31 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/