< draft-ietf-geopriv-deref-protocol-03.txt		draft-ietf-geopriv-deref-protocol-04.txt >
	GEOPRIV J. Winterbottom		GEOPRIV J. Winterbottom
	Internet-Draft Commscope		Internet-Draft Commscope
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: December 25, 2011 Nokia Siemens Networks		Expires: May 3, 2012 Nokia Siemens Networks
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	M. Thomson		M. Thomson
	M. Dawson		M. Dawson
	Commscope		Commscope
	June 23, 2011		October 31, 2011
	A Location Dereferencing Protocol Using HELD		A Location Dereferencing Protocol Using HELD
	draft-ietf-geopriv-deref-protocol-03.txt		draft-ietf-geopriv-deref-protocol-04
	Abstract		Abstract
	This document describes how to use the Hypertext Transfer Protocol		This document describes how to use the Hypertext Transfer Protocol
	(HTTP) over Transport Layer Security (TLS) as a dereferencing		(HTTP) over Transport Layer Security (TLS) as a dereferencing
	protocol to resolve a reference to a Presence Information Data Format		protocol to resolve a reference to a Presence Information Data Format
	Location Object (PIDF-LO). The document assumes that a Location		Location Object (PIDF-LO). The document assumes that a Location
	Recipient possesses a URI that can be used in conjunction with the		Recipient possesses a URI that can be used in conjunction with the
	HELD protocol to request the location of the Target.		HTTP-Enabled Location Delivery (HELD) protocol to request the
			location of the Target.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 25, 2011.		This Internet-Draft will expire on May 3, 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 2, line 34 ¶		skipping to change at page 2, line 35 ¶
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 15		9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	9.2. Informative references . . . . . . . . . . . . . . . . . . 15		9.2. Informative references . . . . . . . . . . . . . . . . . . 15
	Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 17		Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 17
	Appendix B. Compliance to Location Reference Requirements . . . . 20		Appendix B. Compliance to Location Reference Requirements . . . . 20
	B.1. Requirements for a Location Configuration Protocol . . . . 20		B.1. Requirements for a Location Configuration Protocol . . . . 20
	B.2. Requirements for a Location Dereference Protocol . . . . . 22		B.2. Requirements for a Location Dereference Protocol . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	Provision of location information by reference [RFC5808] involves the		Provision of location information by reference [RFC5808] involves the
	creation of a resource that is identified by a "location URI". A		creation of a resource that is identified by a "location URI". A
	"location URI" is a URI [RFC3986] that identifies a resource		"location URI" is a URI [RFC3986] that identifies a resource
	containing the location of an entity. A location URI can be acquired		containing the location of an entity. A location URI can be acquired
	using a location configuration protocol, such as HTTP-Enabled		using a location configuration protocol, such as HTTP-Enabled
	Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration		Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration
	Protocol (DHCP) location URI option		Protocol (DHCP) location URI option
	skipping to change at page 4, line 14 ¶		skipping to change at page 4, line 14 ¶
	information on this scenario and others like it.		information on this scenario and others like it.
	+-------------+		+-------------+
	+------------+ | Location | +-----------+		+------------+ | Location | +-----------+
	| End Device | | Information | | Location |		| End Device | | Information | | Location |
	| (Target) | | Server | | Recipient |		| (Target) | | Server | | Recipient |
	+-----+------+ +------+------+ +-----+-----+		+-----+------+ +------+------+ +-----+-----+
	| | |		| | |
	.- + - - - - - - - - - - - - + -. |		.- + - - - - - - - - - - - - + -. |
	: | locationRequest | : |		: | locationRequest | : |
	. |------(location URI)---->| . |		. |----(for location URI)-->| . |
	: | | : Location |		: | | : Location |
	. | locationResponse | . Configuration |		. | locationResponse | . Configuration |
	: |<-----(location URI)-----| : |		: |<-----(location URI)-----| : |
	. | | . |		. | | . |
	`- + - - - - - - - - - - - - + -' |		`- + - - - - - - - - - - - - + -' |
	| | |		| | |
	| Location Conveyance |		| Location Conveyance |
	|~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|		|~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|
	| | |		| | |
	| .- + - - - - - - - - - - - - + -.		| .- + - - - - - - - - - - - - + -.
	| : | locationRequest | :		| : | locationRequest | :
	| . |<--------(civic)---------| .		| . |<------(for civic)-------| .
	| Dereferencing : | | :		| Dereferencing : | | :
	| . | locationResponse | .		| . | locationResponse | .
	| : |--------(PIDF-LO)------->| :		| : |--------(PIDF-LO)------->| :
	| . | | .		| . | | .
	| `- + - - - - - - - - - - - - + -'		| `- + - - - - - - - - - - - - + -'
	| | |		| | |
	Figure 1: Example of Dereference Protocol Exchange		Figure 1: Example of Dereference Protocol Exchange
	2. Terminology		2. Terminology
	skipping to change at page 7, line 29 ¶		skipping to change at page 7, line 29 ¶
	Use of explicit access control provides a Rule Maker greater control		Use of explicit access control provides a Rule Maker greater control
	over the behaviour of an LS. In contrast to authorization by		over the behaviour of an LS. In contrast to authorization by
	possession, possession of a this form of location URI does not imply		possession, possession of a this form of location URI does not imply
	authorization. Since an explicit policy is used to authorize access		authorization. Since an explicit policy is used to authorize access
	to location information, the location URI can be distributed to many		to location information, the location URI can be distributed to many
	potential Location Recipients.		potential Location Recipients.
	Either before creation or dissemination of the location URI, the Rule		Either before creation or dissemination of the location URI, the Rule
	Maker establishes an authorization policy with the LS. In reference		Maker establishes an authorization policy with the LS. In reference
	to Figure 2, authorization policies might be established at creation		to Figure 2, authorization policies might be established at creation
	(Step 1), and need to be established before before the location URI		(Step 1), and need to be established before the location URI is
	is published (Step 2) to ensure that the policy grants access to the		published (Step 2) to ensure that the policy grants access to the
	desired Location Recipients. Depending on the mechanism used, it		desired Location Recipients. Depending on the mechanism used, it
	might also be possible to change authorization policies at any time.		might also be possible to change authorization policies at any time.
	A possible format for these authorization policies is available with		A possible format for these authorization policies is available with
	GEOPRIV Common Policy [RFC4745] and Geolocation Policy		GEOPRIV Common Policy [RFC4745] and Geolocation Policy
	[I-D.ietf-geopriv-policy]. Additional constraints might be		[I-D.ietf-geopriv-policy]. Additional constraints might be
	established by other means.		established by other means.
	The LS enforces the authorization policy when a Location Recipient		The LS enforces the authorization policy when a Location Recipient
	dereferences the URI. Explicit authorization policies allow a Rule		dereferences the URI. Explicit authorization policies allow a Rule
	skipping to change at page 11, line 18 ¶		skipping to change at page 11, line 18 ¶
	Content-Length: 87		Content-Length: 87
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>		<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
	Figure 4: Minimal Dereferencing Request		Figure 4: Minimal Dereferencing Request
	Figure 5 shows the response to the previous request listing both		Figure 5 shows the response to the previous request listing both
	civic and geodetic location information of the Target's location.		civic and geodetic location information of the Target's location.
	Again, this is identical to the response in Section 10.1 of [RFC5985]		Again, this is identical to the response in Section 10.1 of [RFC5985]
	- unless policy specfies otherwise, the Location Recipient receives		- unless policy specifies otherwise, the Location Recipient receives
	the same information as the Device.		the same information as the Device.
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Server: Example LIS		Server: Example LIS
	Date: Mon, 10 Jan 2011 03:42:29 GMT		Date: Mon, 10 Jan 2011 03:42:29 GMT
	Expires: Tue, 11 Jan 2011 03:42:29 GMT		Expires: Tue, 11 Jan 2011 03:42:29 GMT
	Cache-control: private		Cache-control: private
	Content-Type: application/held+xml		Content-Type: application/held+xml
	Content-Length: 676		Content-Length: 676
	skipping to change at page 15, line 50 ¶		skipping to change at page 15, line 50 ¶
	[I-D.ietf-geopriv-arch]		[I-D.ietf-geopriv-arch]
	Barnes, R., Lepinski, M., Cooper, A., Morris, J.,		Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
	Tschofenig, H., and H. Schulzrinne, "An Architecture for		Tschofenig, H., and H. Schulzrinne, "An Architecture for
	Location and Location Privacy in Internet Applications",		Location and Location Privacy in Internet Applications",
	draft-ietf-geopriv-arch-03 (work in progress),		draft-ietf-geopriv-arch-03 (work in progress),
	October 2010.		October 2010.
	[I-D.ietf-geopriv-dhcp-lbyr-uri-option]		[I-D.ietf-geopriv-dhcp-lbyr-uri-option]
	Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4		Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
	and IPv6 Option for a Location Uniform Resource Identifier		and IPv6 Option for a Location Uniform Resource Identifier
	(URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-11 (work		(URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-12 (work
	in progress), February 2011.		in progress), October 2011.
	[I-D.ietf-geopriv-policy]		[I-D.ietf-geopriv-policy]
	Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,		Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,
	and J. Polk, "Geolocation Policy: A Document Format for		Morris, J., and M. Thomson, "Geolocation Policy: A
	Expressing Privacy Preferences for Location Information",		Document Format for Expressing Privacy Preferences for
	draft-ietf-geopriv-policy-23 (work in progress),		Location Information", draft-ietf-geopriv-policy-25 (work
	March 2011.		in progress), October 2011.
	[I-D.ietf-geopriv-policy-uri]		[I-D.ietf-geopriv-policy-uri]
	Barnes, R., Thomson, M., Winterbottom, J., and H.		Barnes, R., Thomson, M., Winterbottom, J., and H.
	Tschofenig, "Location Configuration Extensions for Policy		Tschofenig, "Location Configuration Extensions for Policy
	Management", draft-ietf-geopriv-policy-uri-01 (work in		Management", draft-ietf-geopriv-policy-uri-02 (work in
	progress), June 2011.		progress), October 2011.
	[I-D.ietf-sipcore-location-conveyance]		[I-D.ietf-sipcore-location-conveyance]
	Polk, J., Rosen, B., and J. Peterson, "Location Conveyance		Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
	for the Session Initiation Protocol",		for the Session Initiation Protocol",
	draft-ietf-sipcore-location-conveyance-08 (work in		draft-ietf-sipcore-location-conveyance-09 (work in
	progress), May 2011.		progress), September 2011.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and		[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
	J. Polk, "Geopriv Requirements", RFC 3693, February 2004.		J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
	[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,		[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
	skipping to change at page 17, line 42 ¶		skipping to change at page 17, line 42 ¶
	Section 7.2 of [RFC3693] details the requirements of a "Using		Section 7.2 of [RFC3693] details the requirements of a "Using
	Protocol". These requirements are restated, followed by a statement		Protocol". These requirements are restated, followed by a statement
	of compliance:		of compliance:
	Req. 4. "The using protocol has to obey the privacy and security		Req. 4. "The using protocol has to obey the privacy and security
	instructions coded in the Location Object and in the		instructions coded in the Location Object and in the
	corresponding Rules regarding the transmission and storage		corresponding Rules regarding the transmission and storage
	of the LO."		of the LO."
	Compliant: This document carries the PIDF-LO as is via HTTPS		Compliant: This specification describes the use of HTTP over
	from the LS to the Location Recipient. The sending and		TLS for carring the PIDF-LO from the LS to the Location
	receiving parties are expected to comply with the		Recipient. The sending and receiving parties are expected
	instructions carried inside the object.		to comply with the instructions carried inside the object.
			Though discouraged, using unsecured http: URIs is permitted.
			Using unsecured HTTP is likely to result in non-compliance
			with this requirement.
	Req. 5. "The using protocol will typically facilitate that the keys		Req. 5. "The using protocol will typically facilitate that the keys
	associated with the credentials are transported to the		associated with the credentials are transported to the
	respective parties, that is, key establishment is the		respective parties, that is, key establishment is the
	responsibility of the using protocol."		responsibility of the using protocol."
	Compliant: This document specifies that authentication of		Compliant: This document specifies that authentication of
	the LS uses the established public key infrastructure used		the LS uses the established public key infrastructure used
	by HTTP over TLS [RFC2818]. Authentication of Location		by HTTP over TLS [RFC2818]. Authentication of Location
	Recipients is either based on distribution of a secret (the		Recipients is either based on distribution of a secret (the
	location URI) using a conveyance protocol (for instance,		location URI) using a conveyance protocol (for instance,
	[I-D.ietf-sipcore-location-conveyance]), allowances are made		[I-D.ietf-sipcore-location-conveyance]), allowances are made
	for later work to define alternative methods.		for later work to define alternative methods.
	Req. 6. "(Single Message Transfer) In particular, for tracking of		Req. 6. "(Single Message Transfer) In particular, for tracking of
	small target devices, the design should allow a single		small target devices, the design should allow a single
	skipping to change at page 19, line 9 ¶		skipping to change at page 19, line 14 ¶
	with the full Privacy Rules (such as, instruction on the		with the full Privacy Rules (such as, instruction on the
	time period for which the LO can be retained)."		time period for which the LO can be retained)."
	Compliant: The Rule Maker might define (via mechanisms		Compliant: The Rule Maker might define (via mechanisms
	outside the scope of this document) which policy rules are		outside the scope of this document) which policy rules are
	disclosed to other entities. For instance, if [RFC4745] is		disclosed to other entities. For instance, if [RFC4745] is
	used to convey authorization policies from Rule Maker to		used to convey authorization policies from Rule Maker to
	LS, this is possible using the parameters specified in		LS, this is possible using the parameters specified in
	[I-D.ietf-geopriv-policy].		[I-D.ietf-geopriv-policy].
			In order to comply with these rules, a Location Recipient
			MUST NOT redistribute a location URI without express
			permission. Depending on the access control model, the
			location URI might be secret (see Section 3.3 of
			[RFC5808]).
	Req. 10. (Full Rule language) Not Applicable: Note however that		Req. 10. (Full Rule language) Not Applicable: Note however that
	Geopriv has defined a rule language capable of expressing a		Geopriv has defined a rule language capable of expressing a
	wide range of privacy rules (see [RFC4745] and		wide range of privacy rules (see [RFC4745] and
	[I-D.ietf-geopriv-policy].		[I-D.ietf-geopriv-policy].
	Req. 11. (Limited Rule language) Not Applicable: This requirement		Req. 11. (Limited Rule language) Not Applicable: This requirement
	applies to (and is addressed by) PIDF-LO [RFC4119].		applies to (and is addressed by) PIDF-LO [RFC4119].
	Section 7.4 of [RFC3693] details the requirements of "Location Object		Section 7.4 of [RFC3693] details the requirements of "Location Object
	Privacy and Security". These requirements are restated where they		Privacy and Security". These requirements are restated where they
	are applicable to this document:		are applicable to this document:
	Req. 12. (Identity Protection) Compliant: Identity protection of the		Req. 12. (Identity Protection) Compliant: Identity protection of the
	Target is provided as long as both of the following		Target is provided as long as both of the following
	conditions are true:		conditions are true:
	(a) the location URI is not associated with the identity		(a) the location URI is not associated with the identity
	of the Target in any context, and		of the Target in any context, and
	(b) the PIDF-LO does not contain information about the		(b) the PIDF-LO does not contain information about the
	identity about the Target.		identity of the Target.
	For instance, this requirement is complied with if the		For instance, this requirement is complied with if the
	protocol that conveys the location URI does not link the		protocol that conveys the location URI does not link the
	identity of the Target to the location URI and the LS		identity of the Target to the location URI and the LS
	doesn't include meaningful identification information in		doesn't include meaningful identification information in
	the PIDF-LO document. Section 6 recommends that an		the PIDF-LO document. Section 6 recommends that an
	unlinked pseudonym is used by the LS.		unlinked pseudonym is used by the LS.
	Req. 13. (Credential Requirements) Compliant: The primary security		Req. 13. (Credential Requirements) Compliant: The primary security
	mechanism specified in this document is Transport Layer		mechanism specified in this document is Transport Layer
	skipping to change at page 20, line 33 ¶		skipping to change at page 20, line 48 ¶
	C1. "Location URI support: The location configuration protocol MUST		C1. "Location URI support: The location configuration protocol MUST
	support a location reference in URI form."		support a location reference in URI form."
	Compliant: HELD only provides location references in URI form.		Compliant: HELD only provides location references in URI form.
	C2. "Location URI expiration: When a location URI has a limited		C2. "Location URI expiration: When a location URI has a limited
	validity interval, its lifetime MUST be indicated."		validity interval, its lifetime MUST be indicated."
	Compliant: HELD indicates the expiry time of location URIs using		Compliant: HELD indicates the expiry time of location URIs using
	the "expires" attribute. [I-D.ietf-geopriv-policy-uri] provides		the "expires" attribute. [I-D.ietf-geopriv-policy-uri] provides
	a way to control expiration of a location URI; a Device is able		a way to control expiration of a location URI.
	to specify limits on the life time of a HELD context.
	C3. "Location URI cancellation: The location configuration protocol		C3. "Location URI cancellation: The location configuration protocol
	MUST support the ability to request a cancellation of a specific		MUST support the ability to request a cancellation of a specific
	location URI."		location URI."
	Compliant with Extension: [I-D.ietf-geopriv-policy-uri]		Compliant with Extension: [I-D.ietf-geopriv-policy-uri]
	describes how a location URI can be cancelled through the		describes how a location URI can be cancelled through the
	application of policy. Without extensions, HELD does not		application of policy. Without extensions, HELD does not
	provide a method for cancelling location URIs.		provide a method for cancelling location URIs.
	skipping to change at page 21, line 36 ¶		skipping to change at page 21, line 52 ¶
	[I-D.ietf-geopriv-policy-uri] enable this capability. Note that		[I-D.ietf-geopriv-policy-uri] enable this capability. Note that
	this document recommends that only location information be		this document recommends that only location information be
	provided.		provided.
	C8. "Location URI Not guessable: As a default, the location		C8. "Location URI Not guessable: As a default, the location
	configuration protocol MUST return location URIs that are random		configuration protocol MUST return location URIs that are random
	and unique throughout the indicated lifetime. A location URI		and unique throughout the indicated lifetime. A location URI
	with 128-bits of randomness is RECOMMENDED."		with 128-bits of randomness is RECOMMENDED."
	Compliant: HELD specifies that location URIs conform to this		Compliant: HELD specifies that location URIs conform to this
	requirement.		requirement. The amount of randomness is not specifically
			identified since it depends on a number of factors that change
			over time, such as the number of valid location URIs, the
			validity period of those URIs and the rate that guesses can be
			made.
	C9. "Location URI Options: In the case of user-provided		C9. "Location URI Options: In the case of user-provided
	authorization policies, where anonymous or non-guessable		authorization policies, where anonymous or non-guessable
	location URIs are not warranted, the location configuration		location URIs are not warranted, the location configuration
	protocol MAY support a variety of optional location URI		protocol MAY support a variety of optional location URI
	conventions, as requested by a Target to a location		conventions, as requested by a Target to a location
	configuration server, (e.g., embedded location information		configuration server, (e.g., embedded location information
	within the location URI)."		within the location URI)."
	Not Compliant: HELD does not support Device-specified location		Not Compliant: HELD does not support Device-specified location
End of changes. 20 change blocks.
	30 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/