< draft-ietf-geopriv-deref-protocol-05.txt		draft-ietf-geopriv-deref-protocol-06.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: November 9, 2012 Nokia Siemens Networks		Expires: January 13, 2013 Nokia Siemens Networks
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	M. Thomson		M. Thomson
	(Unaffiliated)		(Unaffiliated)
	May 8, 2012		July 12, 2012
	A Location Dereferencing Protocol Using HELD		A Location Dereferencing Protocol Using HELD
	draft-ietf-geopriv-deref-protocol-05		draft-ietf-geopriv-deref-protocol-06
	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
	HTTP-Enabled Location Delivery (HELD) protocol to request the		HTTP-Enabled Location Delivery (HELD) protocol to request the
	location of the Target.		location of the Target.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 9, 2012.		This Internet-Draft will expire on January 13, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 28 ¶
	Note: In many cases, an "http:" URI does not provide sufficient		Note: In many cases, an "http:" URI does not provide sufficient
	security for location URIs. The absence of the security		security for location URIs. The absence of the security
	mechanisms provided by TLS means that the Rule Maker has no		mechanisms provided by TLS means that the Rule Maker has no
	control over who receives location information and the Location		control over who receives location information and the Location
	Recipient has no assurance that the information is correct.		Recipient has no assurance that the information is correct.
	The Location Recipient establishes a connection to the LS, as		The Location Recipient establishes a connection to the LS, as
	described in [RFC2818].		described in [RFC2818].
	TLS SHOULD be used. When TLS is used, the TLS ciphersuite		TLS MUST be used unless confidentiality and integrity are provided by
	TLS_NULL_WITH_NULL_NULL MUST NOT be used and the LS MUST be		some other mechanism, such as IPsec or a fully trusted network.
	authenticated [RFC6125] to ensure that the correct server is		Without a reliable assertion that a mechanism is in place, such as
	contacted.		through configuration or user override, then TLS MUST be used. When
			TLS is used, the TLS ciphersuite TLS_NULL_WITH_NULL_NULL MUST NOT be
			used and the LS MUST be authenticated [RFC6125] to ensure that the
			correct server is contacted.
	A Location Server MAY reject a request and request that a Location		A Location Server MAY reject a request and request that a Location
	Recipient provide authentication credentials if authorization is		Recipient provide authentication credentials if authorization is
	dependent on the Location Recipient identity. Future specifications		dependent on the Location Recipient identity. Future specifications
	could define an authentication mechanism and a means by which		could define an authentication mechanism and a means by which
	Location Recipients are identified in authorization policies. This		Location Recipients are identified in authorization policies. This
	document provides definitions for neither item.		document provides definitions for neither item.
	3.1. HELD Usage Profile		3.1. HELD Usage Profile
	skipping to change at page 7, line 21 ¶		skipping to change at page 7, line 24 ¶
	"http:" URI is dereferenced as described in this document; other		"http:" URI is dereferenced as described in this document; other
	URI schemes might be dereferenced using another method.		URI schemes might be dereferenced using another method.
	In this final step, the Location Server (LS) or LIS makes an		In this final step, the Location Server (LS) or LIS makes an
	authorization decision. How this decision is reached depends on the		authorization decision. How this decision is reached depends on the
	authorization model.		authorization model.
	4.1. Authorization by Possession		4.1. Authorization by Possession
	In this model, possession - or knowledge - of the location URI is		In this model, possession - or knowledge - of the location URI is
	used to control access to location information. A location URI is		used to control access to location information. A location URI might
	constructed such that it is hard to guess (see C8 of [RFC5808]) and		be constructed such that it is hard to guess (see C8 of [RFC5808])
	the set of entities that it is disclosed to is limited. The only		and the set of entities that it is disclosed to can be limited. The
	authentication required by the LS is evidence of possession of the		only authentication this would require by the LS is evidence of
	URI. The LS is able to immediately authorize any request that		possession of the URI. The LS could immediately authorize any
	indicates this URI.		request that indicates this URI.
	Authorization by possession uses a very simple policy that does not		Authorization by possession does not require direct interaction with
	typically require direct interaction with a Rule Maker; it is assumed		a Rule Maker; it is assumed that the Rule Maker is able to exert
	that the Rule Maker is able to exert control over the distribution of		control over the distribution of the location URI. Therefore, the
	the location URI. Therefore, the LIS can operate with limited policy		LIS can operate with limited policy input from a Rule Maker.
	input from a Rule Maker.
	Limited disclosure is an important aspect of this authorization		Limited disclosure is an important aspect of this authorization
	model. The location URI is a secret; therefore, ensuring that		model. The location URI is a secret; therefore, ensuring that
	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.
	Use of authorization by possession location URIs in a hop-by-hop		Use of authorization by possession location URIs in a hop-by-hop
	protocol such as SIP [RFC3261] adds the possibility of on-path		protocol such as SIP [RFC3261] adds the possibility of on-path
	adversaries. Depending on the usage of the location URI for certain		adversaries. Depending on the usage of the location URI for certain
	skipping to change at page 8, line 6 ¶		skipping to change at page 8, line 8 ¶
	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 a		granted, authorization cannot be easily revoked. Cancellation of a
	location URI ensures that legitimate users are also affected;		location URI ensures that legitimate users are also affected;
	application of additional policy is theoretically possible, but could		application of additional policy is theoretically possible, but could
	be technically infeasible. Expiration of location URIs limits the		be technically infeasible. Expiration of location URIs limits the
	usable time for a location URI, requiring that an attacker continue		usable time for a location URI, requiring that an attacker continue
	to learn new location URIs to retain access to current location		to learn new location URIs to retain access to current location
	information.		information.
	A very simple policy is established at the time that a location URI		A very simple policy might be established at the time that a location
	is created. This policy specifies that the location URI expires		URI is created. This policy specifies that the location URI expires
	after a certain time, which limits any inadvertent exposure of		after a certain time, which limits any inadvertent exposure of
	location information to adversaries. The expiration time of the		location information to adversaries. The expiration time of the
	location URI might be negotiated at the time of its creation, or it		location URI might be negotiated at the time of its creation, or it
	might be unilaterally set by the LIS.		might be unilaterally set by the LIS.
	4.2. Authorization via Access Control		4.2. Authorization via Access Control
	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 this form of location URI does not imply		possession, possession of this form of location URI does not imply
	skipping to change at page 13, line 12 ¶		skipping to change at page 13, line 12 ¶
	to protect privacy: TLS and authorization policies. TLS provides a		to protect privacy: TLS and authorization policies. TLS provides a
	means of ensuring confidentiality of location information through		means of ensuring confidentiality of location information through
	encryption and mutual authentication. An authorization policy allows		encryption and mutual authentication. An authorization policy allows
	a Rule Maker to explicitly control how location information is		a Rule Maker to explicitly control how location information is
	provided to Location Recipients.		provided to Location Recipients.
	The process by which a Rule Maker establishes an authorization policy		The process by which a Rule Maker establishes an authorization policy
	is not covered by this document; several methods are possible, for		is not covered by this document; several methods are possible, for
	instance: [I-D.ietf-geopriv-policy-uri], [RFC4825].		instance: [I-D.ietf-geopriv-policy-uri], [RFC4825].
	Use of TLS for the dereferencing of location URIs is strongly		TLS MUST be used for dereferencing location URIs unless
	RECOMMENDED, as discussed in Section 3. Location Recipients MUST		confidentiality and integrity are provided by some other mechanism,
	authenticate the host identity using the domain name included in the		as discussed in Section 3. Location Recipients MUST authenticate the
	location URI, using the procedure described in Section 3.1 of		host identity using the domain name included in the location URI,
	[RFC2818]. Local policy determines what a Location Recipient does if		using the procedure described in Section 3.1 of [RFC2818]. Local
	authentication fails or cannot be attempted.		policy determines what a Location Recipient does if authentication
			fails or cannot be attempted.
	The authorization by possession model (Section 4.1) further relies on		The authorization by possession model (Section 4.1) further relies on
	TLS when transmitting the location URI to protect the secrecy of the		TLS when transmitting the location URI to protect the secrecy of the
	URI. Possession of such a URI implies the same privacy		URI. Possession of such a URI implies the same privacy
	considerations as possession of the PIDF-LO document that the URI		considerations as possession of the PIDF-LO document that the URI
	references.		references.
	Location URIs MUST only be disclosed to authorized Location		Location URIs MUST only be disclosed to authorized Location
	Recipients. The GEOPRIV architecture [RFC6280] identifies the Rule		Recipients. The GEOPRIV architecture [RFC6280] identifies the Rule
	Maker role as being the entity that authorizes disclosure of this		Maker role as being the entity that authorizes disclosure of this
	skipping to change at page 15, line 14 ¶		skipping to change at page 15, line 14 ¶
	Verification of Domain-Based Application Service Identity		Verification of Domain-Based Application Service Identity
	within Internet Public Key Infrastructure Using X.509		within Internet Public Key Infrastructure Using X.509
	(PKIX) Certificates in the Context of Transport Layer		(PKIX) Certificates in the Context of Transport Layer
	Security (TLS)", RFC 6125, March 2011.		Security (TLS)", RFC 6125, March 2011.
	9.2. Informative references		9.2. Informative references
	[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-14 (work		(URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-15 (work
	in progress), March 2012.		in progress), May 2012.
	[I-D.ietf-geopriv-policy]		[I-D.ietf-geopriv-policy]
	Cuellar, J., Tschofenig, H., Schulzrinne, H., Polk, J.,		Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J.,
	Morris, J., and M. Thomson, "Geolocation Policy: A		Morris, J., and M. Thomson, "Geolocation Policy: A
	Document Format for Expressing Privacy Preferences for		Document Format for Expressing Privacy Preferences for
	Location Information", draft-ietf-geopriv-policy-25 (work		Location Information", draft-ietf-geopriv-policy-26 (work
	in progress), October 2011.		in progress), June 2012.
	[I-D.ietf-geopriv-policy-uri]		[I-D.ietf-geopriv-policy-uri]
	Thomson, M., Winterbottom, J., Barnes, R., and H.		Thomson, M., Winterbottom, J., Barnes, R., and H.
	Tschofenig, "Location Configuration Extensions for Policy		Tschofenig, "Location Configuration Extensions for Policy
	Management", draft-ietf-geopriv-policy-uri-04 (work in		Management", draft-ietf-geopriv-policy-uri-04 (work in
	progress), November 2011.		progress), November 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,
End of changes. 12 change blocks.
	32 lines changed or deleted		35 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/