< draft-ietf-geopriv-policy-24.txt		draft-ietf-geopriv-policy-25.txt >
	GEOPRIV H. Schulzrinne, Ed.		GEOPRIV H. Schulzrinne, Ed.
	Internet-Draft Columbia University		Internet-Draft Columbia University
	Intended status: Standards Track H. Tschofenig, Ed.		Intended status: Standards Track H. Tschofenig, Ed.
	Expires: March 17, 2012 Nokia Siemens Networks		Expires: April 16, 2012 Nokia Siemens Networks
	J. Cuellar		J. Cuellar
	Siemens		Siemens
	J. Polk		J. Polk
	Cisco		Cisco
	J. Morris		J. Morris
	September 14, 2011
			M. Thomson
			Commscope
			October 14, 2011
	Geolocation Policy: A Document Format for Expressing Privacy Preferences		Geolocation Policy: A Document Format for Expressing Privacy Preferences
	for Location Information		for Location Information
	draft-ietf-geopriv-policy-24.txt		draft-ietf-geopriv-policy-25.txt
	Abstract		Abstract
	This document defines an authorization policy language for		This document defines an authorization policy language for
	controlling access to location information. It extends the Common		controlling access to location information. It extends the Common
	Policy authorization framework to provide location-specific access		Policy authorization framework to provide location-specific access
	control. More specifically, this document defines condition elements		control. More specifically, this document defines condition elements
	specific to location information in order to restrict access based on		specific to location information in order to restrict access based on
	the current location of the Target.		the current location of the Target.
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 6 ¶
	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 March 17, 2012.
			This Internet-Draft will expire on April 16, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 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
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	11.2. Geolocation Policy Namespace Registration . . . . . . . . 31		11.2. Geolocation Policy Namespace Registration . . . . . . . . 31
	11.3. Geolocation Policy Location Profile Registry . . . . . . . 32		11.3. Geolocation Policy Location Profile Registry . . . . . . . 32
	11.4. Basic Location Profile XML Schema Registration . . . . . . 32		11.4. Basic Location Profile XML Schema Registration . . . . . . 32
	11.5. Basic Location Profile Namespace Registration . . . . . . 33		11.5. Basic Location Profile Namespace Registration . . . . . . 33
	11.6. XCAP Application Usage ID . . . . . . . . . . . . . . . . 33		11.6. XCAP Application Usage ID . . . . . . . . . . . . . . . . 33
	12. Internationalization Considerations . . . . . . . . . . . . . 35		12. Internationalization Considerations . . . . . . . . . . . . . 35
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 36		13. Security Considerations . . . . . . . . . . . . . . . . . . . 36
	13.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 36		13.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 36
	13.2. Obfuscation . . . . . . . . . . . . . . . . . . . . . . . 36		13.2. Obfuscation . . . . . . . . . . . . . . . . . . . . . . . 36
	13.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 38		13.3. Usability . . . . . . . . . . . . . . . . . . . . . . . . 38
			13.4. Location Obscuring Limitations . . . . . . . . . . . . . . 39
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 40		14.1. Normative References . . . . . . . . . . . . . . . . . . . 40
	14.2. Informative References . . . . . . . . . . . . . . . . . . 40		14.2. Informative References . . . . . . . . . . . . . . . . . . 40
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 42		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 42
	Appendix B. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . 43		Appendix B. Pseudo-Code . . . . . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
	1. Introduction		1. Introduction
	Location information needs to be protected against unauthorized		Location information needs to be protected against unauthorized
	skipping to change at page 13, line 42 ¶		skipping to change at page 13, line 42 ¶
	The <provide-location> element contains child elements of a specific		The <provide-location> element contains child elements of a specific
	location profile that controls the granularity of returned location		location profile that controls the granularity of returned location
	information. This form of location granularity reduction is also		information. This form of location granularity reduction is also
	called 'obfuscation' and is defined in [duckham05] as		called 'obfuscation' and is defined in [duckham05] as
	"the means of deliberately degrading the quality of information		"the means of deliberately degrading the quality of information
	about an individual's location in order to protect that		about an individual's location in order to protect that
	individual's location privacy."		individual's location privacy."
			Location obscuring presents a number of technical challenges. The
			algorithms provided in this document are provided as examples only.
			A discussion of the technical constraints on location obscuring is
			included in Section 13.4.
	The functionality of location granularity reduction depends on the		The functionality of location granularity reduction depends on the
	type of location provided as input. This document defines two		type of location provided as input. This document defines two
	profiles for reduction, namely:		profiles for reduction, namely:
	o If the <provide-location> element has a <provide-civic> child		o If the <provide-location> element has a <provide-civic> child
	element then civic location information is disclosed as described		element then civic location information is disclosed as described
	in Section 6.5.1, subject to availability.		in Section 6.5.1, subject to availability.
	o If the <provide-location> element has a <provide-geo> child		o If the <provide-location> element has a <provide-geo> child
	element then geodetic location information is disclosed as		element then geodetic location information is disclosed as
	skipping to change at page 15, line 49 ¶		skipping to change at page 15, line 49 ¶
	This profile uses the token 'geodetic-transformation' and refers only		This profile uses the token 'geodetic-transformation' and refers only
	to the Coordinate Reference System (CRS) WGS 84		to the Coordinate Reference System (CRS) WGS 84
	(urn:ogc:def:crs:EPSG::4326, 2D). This profile allows geodetic		(urn:ogc:def:crs:EPSG::4326, 2D). This profile allows geodetic
	location transformations to be specified by means of the <provide-		location transformations to be specified by means of the <provide-
	geo> element that may restrict the returned geodetic location		geo> element that may restrict the returned geodetic location
	information based on the value provided in the 'radius' attribute.		information based on the value provided in the 'radius' attribute.
	The value of the 'radius' attribute expresses the radius in meters.		The value of the 'radius' attribute expresses the radius in meters.
	The schema of the <provide-geo> element is defined in Section 8.		The schema of the <provide-geo> element is defined in Section 8.
	The algorithm proceeds in 6 steps. The first two steps are		The algorithm proceeds in 6 steps.The first two steps are independent
	independent of the measured position to be obscured. Those two steps		of the measured position to be obscured. Those two steps should be
	should be run only once or rather seldom (for every region and		run only once or rather seldom (for every region and desired
	desired uncertainty). The steps are:		uncertainty). The steps are:
	1. Choose a geodesic projection with Cartesian coordinates and a		1. Choose a geodesic projection with Cartesian coordinates and a
	surface you want to cover. The maximal distortion of the map may		surface you want to cover. The maximal distortion of the map may
	not be too much (see notes below).		not be too much (see notes below).
	2. Given uncertainty "d", choose a grid of so called "landmarks" at		2. Given uncertainty "d", choose a grid of so called "landmarks" at
	a distance (maximal) d of each other.		a distance (maximal) d of each other.
	3. Given a measured location M=(m,n) in the surface, calculate its 4		3. Given a measured location M=(m,n) in the surface, calculate its 4
	closest landmarks on the grid, with coordinates: SW = (l,b),		closest landmarks on the grid, with coordinates: SW = (l,b),
	skipping to change at page 18, line 5 ¶		skipping to change at page 17, line 27 ¶
	the region of the map is small, then the scale may be taken as a		the region of the map is small, then the scale may be taken as a
	constant over the whole map).		constant over the whole map).
	Regarding Step3:		Regarding Step3:
	SW is mnemonic for south-west, b for bottom, l for left		SW is mnemonic for south-west, b for bottom, l for left
	(SW=(l,b)), etc, but the directions of the geodesic projection may		(SW=(l,b)), etc, but the directions of the geodesic projection may
	be arbitrary, and thus SW may be not south-west of M but it will		be arbitrary, and thus SW may be not south-west of M but it will
	be left and below M *on the map*.		be left and below M *on the map*.
			This algorithm is applied to the known location every time it
			changes. Movement between the defined grid areas triggers a change
			in the location that is reported, which could reveal significantly
			more about the location than desired.
	7. Examples		7. Examples
	This section provides a few examples for authorization rules using		This section provides a few examples for authorization rules using
	the extensions defined in this document.		the extensions defined in this document.
	7.1. Rule Example with Civic Location Condition		7.1. Rule Example with Civic Location Condition
	This example illustrates a single rule that employs the civic		This example illustrates a single rule that employs the civic
	location condition. It matches if the current location of the Target		location condition. It matches if the current location of the Target
	equal the content of the child elements of the <location> element.		equal the content of the child elements of the <location> element.
	skipping to change at page 40, line 5 ¶		skipping to change at page 39, line 8 ¶
	When XCAP is used to upload authorization policies then built-in		When XCAP is used to upload authorization policies then built-in
	features of XCAP can be utilized to convey error messages back to the		features of XCAP can be utilized to convey error messages back to the
	user about an error condition. Section 8.2.5 of [RFC4825] indicates		user about an error condition. Section 8.2.5 of [RFC4825] indicates
	that some degree of application specific checking is provided when		that some degree of application specific checking is provided when
	authorization policies are added, modified or deleted. The XCAP		authorization policies are added, modified or deleted. The XCAP
	protocol may return a 409 response with a response that may contain a		protocol may return a 409 response with a response that may contain a
	detailed conflict report containing the <constraint-failure> element.		detailed conflict report containing the <constraint-failure> element.
	A human readable description of the problem can be indicated in the		A human readable description of the problem can be indicated in the
	'phrase' attribute of that element.		'phrase' attribute of that element.
			13.4. Location Obscuring Limitations
			Location obscuring attempts to remove information about the location
			of a Target. The effectiveness of location obscuring is determined
			by how much uncertainty a Location Recipient has about the location
			of the Target. A location obscuring algorithm is effective if the
			Location Recipient cannot recover a location with better uncertainty
			than the obscuring algorithm was instructed to add.
			Effective location obscuring is difficult. The amount of information
			that can be recovered by a determined and resourceful Location
			Recipient can be considerably more than is immediately apparent. A
			concise summary of the challenges is included in [duckham10].
			A Location Recipient in possession of external information about the
			Target or geographical area that is reported can make assumptions or
			guesses aided by that information to recover more accurate location
			information. This is true even when a single location is reported,
			but it is especially true when multiple locations are reported for
			the same Target over time.
			Furthermore, a Location Recipient that attempts to recover past
			locations for a Target can use later reported locations to further
			refine any recovered location. A location obscuring algorithm
			typically does not have any information about the future location of
			the Target.
			The degree to which location information can be effectively degraded
			by an obscuring algorithm depends on the information that is used by
			the obscuring algorithm. If the information available to the
			obscuring algorithm is both more extensive and more effectively
			employed than the information available to the Location Recipient,
			then location obscuring might be effective.
			Obscured locations can still serve a purpose where a Location
			Recipient is willing to respect privacy. A privacy-respecting
			Location Recipient can choose to interpret the existence of
			uncertainty as a request from a Rule Maker to not recover location.
			Location obscuring is unlikely to be effective against a more
			determined or resourceful adversary. Withholding location
			information entirely is perhaps the most effective method of ensuring
			that it is not recovered. However, a caution: omitted data also
			conveys some information.
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[GML] OpenGIS, "OpenGIS Geography Markup Language (GML)		[GML] OpenGIS, "OpenGIS Geography Markup Language (GML)
	Implementation Specification, Version 3.00, OGC 02 023r4",		Implementation Specification, Version 3.00, OGC 02 023r4",
	http://www.opengeospatial.org/docs/02-023r4.pdf,		http://www.opengeospatial.org/docs/02-023r4.pdf,
	January 2003.		January 2003.
	[NIMA.TR8350.2-3e]		[NIMA.TR8350.2-3e]
	skipping to change at page 41, line 34 ¶		skipping to change at page 41, line 34 ¶
	[RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025,		[RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025,
	December 2007.		December 2007.
	[duckham05]		[duckham05]
	Duckham, M. and L. Kulik, "A formal model of obfuscation		Duckham, M. and L. Kulik, "A formal model of obfuscation
	and negotiation for location privacy. In Proc. of the 3rd		and negotiation for location privacy. In Proc. of the 3rd
	International Conference PERVASIVE 2005,Munich, Germany",		International Conference PERVASIVE 2005,Munich, Germany",
	May 2005.		May 2005.
			[duckham10]
			Duckham, M., "Moving forward: Location privacy and
			location awareness. In Proc. 3rd ACM SIGSPATIAL GIS
			Workshop on Security and Privacy in GIS and LBS
			(SPRINGL), ACM.", Nov 2010.
	[ifip07] Ardagna, C., Cremonini, M., Damiani, E., De Capitani di		[ifip07] Ardagna, C., Cremonini, M., Damiani, E., De Capitani di
	Vimercati, S., and S. Samarati, "Location-privacy		Vimercati, S., and S. Samarati, "Location-privacy
	protection through obfuscation-based techniques, in:		protection through obfuscation-based techniques, in:
	Proceedings of the 21st Annual IFIP WG 11.3 Working		Proceedings of the 21st Annual IFIP WG 11.3 Working
	Conference on Data and Applications Security, Redondo		Conference on Data and Applications Security, Redondo
	Beach, CA, USA", July 2007.		Beach, CA, USA", July 2007.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	This document is informed by the discussions within the IETF GEOPRIV		This document is informed by the discussions within the IETF GEOPRIV
	skipping to change at line 1752 ¶		skipping to change at page 48, line 4 ¶
	Cisco		Cisco
	2200 East President George Bush Turnpike		2200 East President George Bush Turnpike
	Richardson, Texas 75082		Richardson, Texas 75082
	USA		USA
	Email: jmpolk@cisco.com		Email: jmpolk@cisco.com
	John B. Morris, Jr.		John B. Morris, Jr.
	Email: ietf@jmorris.org		Email: ietf@jmorris.org
			Martin Thomson
			Commscope
			Andrew Building (39)
			University of Wollongong Campus, Wollongong, NSW 2522
			AU
			Phone: +61 2 4221 2915
			Email: martin.thomson@commscope.com
End of changes. 11 change blocks.
	8 lines changed or deleted		74 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/