< draft-winterbottom-geopriv-deref-protocol-00.txt		draft-winterbottom-geopriv-deref-protocol-01.txt >
	Geopriv J. Winterbottom		Geopriv J. Winterbottom
	Internet-Draft Andrew Corporation		Internet-Draft Andrew Corporation
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: May 14, 2008 Nokia Siemens Networks		Expires: January 6, 2009 Nokia Siemens Networks
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	M. Thomson		M. Thomson
	M. Dawson		M. Dawson
	Andrew Corporation		Andrew Corporation
	November 11, 2007		July 5, 2008
	An HTTPS Location Dereferencing Protocol Using HELD		An HTTPS Location Dereferencing Protocol Using HELD
	draft-winterbottom-geopriv-deref-protocol-00.txt		draft-winterbottom-geopriv-deref-protocol-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 14, 2008.		This Internet-Draft will expire on January 6, 2009.
	Copyright Notice
	Copyright (C) The IETF Trust (2007).
	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 into a Presence Information Data		protocol to resolve a reference into a Presence Information Data
	Format Location Object (PIDF-LO). The document assumes that a		Format Location Object (PIDF-LO). The document assumes that a
	Location Recipient possesses a secure HELD URI that can be used in		Location Recipient possesses a secure HELD URI that can be used in
	conjunction with the HELD protocol to request the location of the		conjunction with the HELD protocol to request the location of the
	Target.		Target.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Steps for Retrieval . . . . . . . . . . . . . . . . . . . . . 6		3. Authorization Models . . . . . . . . . . . . . . . . . . . . . 6
	4. Threat Models . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Authorization by Possession . . . . . . . . . . . . . . . 6
	5. Using HELD to Dereference a Location URI . . . . . . . . . . . 9		3.2. Authorization via Access Control Lists . . . . . . . . . . 7
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		4. Steps for Retrieval . . . . . . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
	10.1. Normative References . . . . . . . . . . . . . . . . . . 16		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	10.2. Informative references . . . . . . . . . . . . . . . . . 16		9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 18		9.2. Informative references . . . . . . . . . . . . . . . . . . 17
			Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 19
	Appendix B. HELD Compliance to IETF Location Reference		Appendix B. HELD Compliance to IETF Location Reference
	Requirements . . . . . . . . . . . . . . . . . . . . 23		Requirements . . . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
	Intellectual Property and Copyright Statements . . . . . . . . . . 28		Intellectual Property and Copyright Statements . . . . . . . . . . 29
	1. Introduction		1. Introduction
	This document describes how to transport Presence Information Data		This document describes how to transport Presence Information Data
	Format Location Object (PIDF-LO) when dereferencing a location URI in		Format Location Object (PIDF-LO) when dereferencing a location URI in
	the form of a secure HELD URI (held: URI scheme)		the form of a secure HELD URI (held: URI scheme) [1]. This held:
	[I-D.ietf-geopriv-http-location-delivery]. This held: URI indicates		URI indicates that the XML-based HELD messages are carried on top of
	that the XML-based HELD messages are carried on top of the Hypertext		the Hypertext Transfer Protocol (HTTP), which is secured using
	Transfer Protocol (HTTP), which is secured using Transport Layer		Transport Layer Security (TLS) ([2] and [3]).
	Security (TLS) ([RFC2616] and [RFC2818]).
	The document describes how HELD		The document describes how HELD [1] is used to request and to receive
	[I-D.ietf-geopriv-http-location-delivery] is used to request and to		location information in a way that also satisfies the requirements
	receive location information in a way that also satisfies the		laid out in [7]. HELD provides location information in the form of a
	requirements laid out in [I-D.ietf-geopriv-lbyr-requirements]. HELD		PIDF-LO (see [4]) which, as part of its definition, complies with the
	provides location information in the form of a PIDF-LO (see		requirements of a location object as described in [8].
	[RFC4119]) which, as part of its definition, complies with the
	requirements of a location object as described in [RFC3693].
	To use HELD as a dereferencing protocol has the advantage that the		To use HELD as a dereferencing protocol has the advantage that the
	Location Recipient can indicate the type of location information it		Location Recipient can indicate the type of location information it
	would like to receive. This functionality is already available with		would like to receive. This functionality is already available with
	the HELD base specification, described in		the HELD base specification, described in [1]. Furthermore, the HELD
	[I-D.ietf-geopriv-http-location-delivery]. Furthermore, the HELD
	response from the LIS towards the Location Recipient not only		response from the LIS towards the Location Recipient not only
	provides the PIDF-LO but also encapsulates supplementary information,		provides the PIDF-LO but also encapsulates supplementary information,
	such as error messages, back to the Location Recipient.		such as error messages, back to the Location Recipient.
	The general usage scenario envisioned by this document is shown in		The general usage scenario envisioned by this document is shown in
	Figure 1. While the figure shows a typical HELD location request		Figure 1. While the figure shows a typical HELD location request
	being made to initially obtain the location URI. As Figure 1		being made to initially obtain the location URI. As Figure 1
	indicates, an alternative Location Configuration Protocol (LCP) that		indicates, an alternative Location Configuration Protocol (LCP) that
	can provide a HELD URI can be used.		can provide a HELD URI can be used.
	skipping to change at page 4, line 34 ¶		skipping to change at page 4, line 34 ¶
	| | | | |		| | | | |
	| | 0<===locationRequest(Civic)===| |		| | 0<===locationRequest(Civic)===| |
	| Dereferencing | | | |		| Dereferencing | | | |
	| Protocol | | | |		| Protocol | | | |
	| | |==locationResponse(PIDF-LO)=>0 |		| | |==locationResponse(PIDF-LO)=>0 |
	| | | | |		| | | | |
	| +--+-----------------------------+--+		| +--+-----------------------------+--+
	| | |		| | |
	| | |		| | |
	Figure 1: HTTPS Dereference Context Diagram Using HELD		Figure 1: Example of Dereference Protocol Exchange
	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 [5].
	The key conventions and terminology used in this document are defined		The key conventions and terminology used in this document are defined
	as follows:		as follows:
	This document reuses the term Target, as defined in [RFC3693].		This document reuses the term Target, as defined in [8].
	This document uses the term Location Information Server, LIS, as the		This document uses the term Location Information Server, LIS, as the
	node in the access network providing location information to an end		node in the access network providing location information to an end
	point, or to the node dereferencing a location URI. This term is		point, or to the node dereferencing a location URI. This term is
	also used in [I-D.ietf-geopriv-l7-lcp-ps].		also used in [9].
	The Location Recipient acts as a HELD client and the LIS as a HELD		The Location Recipient acts as a HELD client and the LIS as a HELD
	server in the context of this document.		server in the context of this document.
	3. Steps for Retrieval		Many architectural descriptions related to the updated terminology of
			RFC 3693 can be found in [10].
	1. The Location Recipient obtains a helds: based location URI.		3. Authorization Models
	2. The HELD client establishes a TLS connection to the LIS, as		This section discusses two extreme types of authorization models for
	described in [RFC2818]. The TLS ciphersuite		dereferencing with HELD URIs, namely "Authorization by Possession"
	TLS_NULL_WITH_NULL_NULL MUST NOT be used.		and "Authorization via Access Control Lists". In the subsequent
			subsections we discuss the properties of these two models. These two
			models can, however, be used in combination in a real deployment.
			Figure 2 shows the communication model relevant for this discussion.
			It is a simplified version of Figure 1 from [7].
	3. When certificate based authentication is used the client		+--------+ Dereferencing +-----------+
	authenticates the server and compares the domain part of the		| | Protocol (3) | |
	location URI with the identity information in the certificate.		| LIS +---------------+ Location |
			| | | Recipient |
			+---+----+ | |
			| +----+------+
			| --
			| Location --
			| Configuration --
			| Protocol ---
			| (1) -- Geopriv
			| --- Using
			| -- Protocol
			+----+-----+ -- (2)
			| Target / +--
			| End Host |
			+----------+
	4. The server MAY require the client to be authenticated. This is,		Figure 2: Communication Model
	however, only useful in certain deployment environments where a
	strong relationship between the LIS and the Location Recipients
	exists.
	5. The client retrieves the PIDF-LO document encapsulated into the		3.1. Authorization by Possession
	HELD locationResponse or an error message conveyed in a HELD
	error message.
	4. Threat Models		With this type of authorization model the communication steps with
			respect to Figure 2 are as follows. We focus on the description of
			the case where the Location URI is dereferenced by an entity other
			than the Target.
	This document assumes that the HELD messages between the Location		1. The Target discovers the LIS.
	Recipient and the LIS are carried on top of HTTP and secured via TLS.
	HTTP can be used as a substrate to a number of different
	applications, and defining a set of guidelines for conveying a
	PIDF-LO for any application that might use HTTP would be difficult or
	impossible. This document does not attempt that task. Instead, it
	is limited in applicability to the case where a client uses a HELD
	locationRequest to retrieve a PIDF-LO object from a server. No other
	functionality is covered. This document does not describe how the
	Location Recipient obtains the location URI pointing to the PIDF-LO
	document. This is subject of the Location Conveyance protocol
	[I-D.ietf-sip-location-conveyance]
	There are three security models. They assume that the Location		2. The Target sends a request to the LIS asking for a location-by-
	Recipient who obtains the the location URI does not act maliciously		reference, as shown in (1) of Figure 2.
	and does not distribute the obtained Location Object without
	inspecting the privacy policies attached with the Location Object.
	Authorization Policy Security Model:		3. The LIS responds to the request and returns a Location URI. This
			reference fullfills the requirements indicated in [7], in
			particular it must be non-guessable (see requirement C9 of [7]).
	The assumption of this model is that the LIS has some		4. The Target then conveys the Location URI to a third party, the
	authorization policies (such as those specified in [RFC4745] and		Location Recipient (for example using SIP as described in [11]).
	[I-D.ietf-geopriv-policy]) that are provided by the Target and		This step is shown in (2) of Figure 2.
	uploaded to the LIS. The policies have the form of access control
	lists that indicate to which Location Recipients location
	information is disclosed. The LIS is therefore able to control
	access to location information. Consequently, when the reference
	is conveyed to the potential Location Recipient (e.g., via SIP
	[I-D.ietf-sip-location-conveyance]), then it does not need to be
	protected (neither hop-by-hop nor end-to-end). Authentication by
	the Location Recipient to the LIS is necessary (e.g., TLS client
	authentication, HTTP Digest authentication) to allow the LIS to
	determine whether access to location information has to be
	granted.
	End-to-End Security Model:		5. The Location Recipient then needs to dereference the Location URI
			in order to obtain the Location Object. Depending on the URI
			scheme of the Location URI this might, for example in case of a
			HELD URI, be done as described in this document.
	In this security model we assume that the transport of the		The last step where the LIS has to decide whether to resolve the
	location URI is encrypted end-to-end, for example using S/MIME,		reference and to return the Location Object to the entity asking for
	and an adversary along the signaling path is not able to		it is important. With this authorization model there is the
	eavesdrop, modify or replay a location URI. The Target is able to		assumption that the possession of the Location URI by the Location
	control the disclosure of the PIDF-LO by making it available only		Recipient alone is sufficient, from an authorization point of view,
	to trusted entities. Consequently, only the entity that is able		to grant access to the Location Object that is being referenced by
	to decrypt the end-to-end protected object, such as S/MIME		the Location URI. As such, the Location Recipient authenticates the
	encrypted object, can resolve the reference.		LIS using TLS server-side authentication but no authentication from
			the Location Recipient point of view is demanded.
	Hop-by-Hop Security Model:		A few aspects are worth further discussion when the Target would like
			to avoid unrestricted disclosure of it's location information.
			First, the Target is able to control the disclosure of location
			information by making the Location URI available only to trusted
			entities. Second, in order to deal with adversary along the
			signaling path between the Target and the Location Recipient the
			properties of the using protocol need to be taken advantage of. For
			example, the Location URI may be encrypted end-to-end using S/MIME
			and consequently only the entity that is able to decrypt the
			protected object can resolve the reference. Depending on the usage
			of the Location URI for certain location based applications (e.g.,
			emergency services, location based routing) specific treatment is
			important, as discussed in [11].
	In this security model we assume that the location URI can either		3.2. Authorization via Access Control Lists
	be directly communicated between the Target and the Location
	Recipient or from the Target via trusted proxies to the Location
	Recipient. In some cases the location URI is conveyed to multiple
	Location Recipients, for example in case of location-based routing
	applications. The entity that observes the location URI has to be
	able to resolve it into a literal location.
	The description of the security models above shows the responsibility		In this model the communication steps are slightly different, as
	of the participating entities; from a dereferencing protocol point of		shown below.
	view an important responsibility can be found in the protection of
	the interaction between the Location Recipient and the LIS against
	the classical communication security threats.
	With respect to the Location Configuration and the Location		1. The procedure again starts with the Target performing the LIS
	Conveyance protocol interaction, which are outside the scope of this		discovery procedure.
	document, this document at least assumes the hop-by-hop security
	model. Additionally, it is assumed that the requirements outlined in
	[I-D.ietf-geopriv-lbyr-requirements], such as the requirement that
	the location URI contains a random component with sufficient entropy
	and that it does not contain identity information. When the pre-
	requisites for the end-to-end security model are met then further
	protection can be accomplished. End-to-end security mechanisms do,
	however, not enjoy widespread deployment so in SIP so far (when SIP
	is used as the Location Conveyance protocol). The usage of policies
	local to the LIS are possible. Furthermore,
	[I-D.winterbottom-geopriv-held-context] allows constraints to be
	placed on the dereferencing procedure that limit the location
	information available to the Location Recipient, for example limiting
	the number of times a reference may be used.
	5. Using HELD to Dereference a Location URI		2. The Target sends a request to the LIS asking for a location-by-
			reference, as shown in (1) of Figure 2.
	This section describes how HELD protected by TLS can be used to		3. Before handing out the reference the Target uploads authorization
	qualify location requests to the LIS. Only a subset of HELD		policies to the LIS that aim to control access to the
			dereferencing step. A possible format for these authorization
			policies is available with GEOPRIV Common Policy [12] and
			Geolocation Policy [13]. Additional policies are described in
			[14] that allow constraints to be placed on the dereferencing
			procedure to limit the location information being exposed to
			Location Recipients.
			4. The LIS responds to the request and returns a Location URI. With
			the uploaded authorization policies in place there are no
			requirements for the Location URI to be non-guessable.
			5. The Target then conveys the Location URI to a third party, the
			Location Recipient (for example using SIP as described in [11]).
			This step is shown in (2) of Figure 2.
			6. The Location Recipient then needs to dereference the Location URI
			in order to obtain the Location Object. Depending on the
			specific content of the authorization policies (such as identity-
			based conditions in the policy rule set) the Location Recipient
			has to be authenticated in order to allow the authorization check
			to continue.
			It is important to note that this document does not mandate a
			specific authorization model nor does it constraint the usage with
			regard to these models in any way. Additionally, it is possible to
			combine certain parts of both models.
			4. Steps for Retrieval
			When a Location Recipient obtains a Location URI with the "held:" URI
			scheme then the following steps for dereferencing the Location URI
			are being executed:
			1. The Location Recipient, acting as a HELD client, determines the
			IP address of the LIS based on the obtained Location URI
			following the procedure described in Section 3 of [15].
			2. The HELD client establishes a TLS connection to the LIS, as
			described in [3]. The TLS ciphersuite TLS_NULL_WITH_NULL_NULL
			MUST NOT be used.
			3. When certificate based authentication is used the client
			authenticates the server and compares the domain part of the
			Location URI with the identity information in the certificate.
			4. The server MAY require the client to be authenticated. This
			could, for example, be useful in deployment environments where
			certain Location Recipients are granted access to location
			information only or where access control rules have to be
			executed as part of the authorization procedure. Various
			authentication mechanisms for HTTP exist and this document does
			not restrict them in any way since the preferred mechanism may be
			deployment specific.
			5. The client retrieves the PIDF-LO document encapsulated into the
			HELD locationResponse or an error message conveyed in a HELD
			error message.
			The subsequent text describes how HELD protected by TLS can be used
			to qualify location requests to the LIS. Only a subset of HELD
	functionality is required and is described in the following		functionality is required and is described in the following
	paragraphs. The HELD based dereferencing step provides ways to tell		paragraphs. The HELD based dereferencing step provides ways to tell
	the LIS what information is desired and allows the LIS to communicate		the LIS what information is desired and allows the LIS to communicate
	additional information back to the client.		additional information back to the client.
	The <locationType> element allows location to be requested in a		The <locationType> element allows location to be requested in a
	specific form, such as civic or geodetic location information. The		specific form, such as civic or geodetic location information. The
	Location Recipient SHOULD NOT request location as a locationURI. The		Location Recipient SHOULD NOT request location as a locationURI. The
	LIS MUST respond with a "requestError" if it receives a request for a		LIS MUST respond with a "requestError" if it receives a request for a
	locationURI where HELD is being used as a dereference protocol.		locationURI where HELD is being used as a dereference protocol.
	Location information provided by the LIS MUST correspond to the rules		Location information provided by the LIS MUST correspond to the rules
	and guidelines in [I-D.ietf-geopriv-pdif-lo-profile]. If the		and guidelines in [6]. If the requested form of location violates
	requested form of location violates any authorization policies known		any authorization policies known to the LIS, then the LIS MUST
	to the LIS, then the LIS MUST respond with a "cannotProvideLiType"		respond with a "cannotProvideLiType" error.
	error.
	The LIS will provide location information on request even if the		The LIS will provide location information on request even if the
	location information does not fit the form requested. This stems		location information does not fit the form requested. This stems
	from the premise that some location is better than no location. HELD		from the premise that some location is better than no location. HELD
	provides a means for the requestor to modify this behaviour and		provides a means for the requestor to modify this behaviour and
	instruct the LIS to return an error if location information is not		instruct the LIS to return an error if location information is not
	available in the form requested. This is done using the "exact"		available in the form requested. This is done using the "exact"
	attribute.		attribute.
	Location systems often have more than one location determination		Location systems often have more than one location determination
	skipping to change at page 9, line 46 ¶		skipping to change at page 10, line 26 ¶
	Generally, more accurate determination techniques require more time.		Generally, more accurate determination techniques require more time.
	HELD addresses this trade-off by allowing the requestor to specify		HELD addresses this trade-off by allowing the requestor to specify
	how long they are prepared to wait for a location result. This		how long they are prepared to wait for a location result. This
	allows the LIS to select the most accurate determination technique at		allows the LIS to select the most accurate determination technique at
	its disposal that can return a result in the specified time. The		its disposal that can return a result in the specified time. The
	HELD attribute for specifying this value is the "responseTime"		HELD attribute for specifying this value is the "responseTime"
	attribute and MAY be used by a Location Recipient to specify their		attribute and MAY be used by a Location Recipient to specify their
	preference for the accuracy-time trade-off.		preference for the accuracy-time trade-off.
	The LIS MUST support the HELD locationRequest semantic using an HTTP		The LIS MUST support the HELD locationRequest semantic using an HTTP
	GET as described in [I-D.ietf-geopriv-http-location-delivery].		GET as described in [1]. The usage of HTTP POST is optional.
	Where the LIS is unable to process the Location Recipient's request,		Where the LIS is unable to process the Location Recipient's request,
	it MUST return the appropriate error from the existing HELD error set		it MUST return the appropriate error from the existing HELD error set
	defined in [I-D.ietf-geopriv-http-location-delivery].		defined in [1].
	6. Examples		5. Examples
	Figure 2 illustrates a simple dereferencing request example.		This example in Figure 3 shows the most basic rereferencing request
			for a LO. This uses the GET feature described by the HTTP binding
			from Section 9 of [1]. This example assumes that the LO is available
			for retrieval at the URL
			"https://lis.example.com/357yc6s64ceyoiuy5ax3o".
	GET /357yc6s64ceyoiuy5ax3o HTTP/1.1		GET /357yc6s64ceyoiuy5ax3o HTTP/1.1
	Host: lis.example.com		Host: lis.example.com
	Accept:application/held+xml		Accept:application/held+xml,
			application/xml;q=0.8,
			text/xml;q=0.7
			Accept-Charset: UTF-8,*
	Figure 2: Minimal Dereferencing Request		Figure 3: Minimal GET Dereferencing Request
	Figure 3 shows a request indicating that both civic and geodetic		The GET request is exactly identical to a minimal POST request that
			includes an empty "locationRequest" element.
			POST /357yc6s64ceyoiuy5ax3o HTTP/1.1
			Host: lis.example.com
			Accept: application/held+xml,
			application/xml;q=0.8,
			text/xml;q=0.7
			Accept-Charset: UTF-8,*
			Content-Type: application/held+xml
			Content-Length: 87
			<?xml version="1.0"?>
			<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
			Figure 4: Minimal POST Dereferencing Request
			Figure 5 shows a request indicating that both civic and geodetic
	location information has to be returned. If it cannot be provided,		location information has to be returned. If it cannot be provided,
	the request fails.		the request fails.
	HTTP/1.x 200 OK		POST /357yc6s64ceyoiuy5ax3o HTTP/1.1
	Server: Example LIS		Host: lis.example.com
	Expires: Tue, 10 Jan 2006 03:49:20 GMT		Accept: application/held+xml,
	Content-Type: application/held+xml		application/xml;q=0.8,
	Content-Length: XYZ		text/xml;q=0.7
			Accept-Charset: UTF-8,*
			Content-Type: application/held+xml
			Content-Length: 87
	<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">		<?xml version="1.0"?>
	<locationType exact="true">		<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
	civic		<locationType exact="true">
	geodetic		civic
	</locationType>		geodetic
	</locationRequest>		</locationType>
			</locationRequest>
	Figure 3: Dereferencing Request for Civic and Geodetic Information		Figure 5: Dereferencing POST Request for Civic and Geodetic Location
			Information
	Figure 4 shows the response to the previous request listing both		Figure 6 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.
	HTTP/1.x 200 OK		HTTP/1.x 200 OK
	Server: Example LIS		Server: Example LIS
			Date: Tue, 10 Jan 2006 03:42:29 GMT
	Expires: Tue, 10 Jan 2006 03:49:20 GMT		Expires: Tue, 10 Jan 2006 03:49:20 GMT
	Content-Type: application/held+xml		Content-Type: application/held+xml
	Content-Length: XYZ		Content-Length: XYZ
			<?xml version="1.0"?>
	<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">		<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
	<presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"		<presence xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
	entity="pres:ae3be8585902e2253ce2@10.102.23.9">		entity="pres:ae3be8585902e2253ce2@10.102.23.9">
	<tuple id="lisLocation">		<tuple id="lisLocation">
	<status>		<status>
	<geopriv>		<geopriv>
	<location-info>		<location-info>
	<gs:Circle		<gs:Circle
	xmlns:gs="http://www.opengis.net/pidflo/1.0"		xmlns:gs="http://www.opengis.net/pidflo/1.0"
	xmlns:gml="http://www.opengis.net/gml"		xmlns:gml="http://www.opengis.net/gml"
	skipping to change at page 11, line 42 ¶		skipping to change at page 13, line 33 ¶
	</retention-expiry>		</retention-expiry>
	</usage-rules>		</usage-rules>
	<method>Wiremap</method>		<method>Wiremap</method>
	</geopriv>		</geopriv>
	</status>		</status>
	<timestamp>2007-05-24T12:35:02+10:00</timestamp>		<timestamp>2007-05-24T12:35:02+10:00</timestamp>
	</tuple>		</tuple>
	</presence>		</presence>
	</locationResponse>		</locationResponse>
	Figure 4: Response with Civic and Geodetic Location Information		Figure 6: Response with Civic and Geodetic Location Information
	Figure 5 shows an error message returned in response to a request.		Figure 7 shows an error message returned in response to a request.
	HTTP/1.x 200 OK		HTTP/1.x 200 OK
	Server: Example LIS		Server: Example LIS
	Expires: Tue, 10 Jan 2006 03:49:20 GMT		Expires: Tue, 10 Jan 2006 03:49:20 GMT
	Content-Type: application/held+xml		Content-Type: application/held+xml
	Content-Length: XYZ		Content-Length: XYZ
	<error xmlns="urn:ietf:params:xml:ns:geopriv:held"		<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
	code="cannotProvideLiType"		code="cannotProvideLiType"
	message="Authorization policies do not permit		message="Authorization policies do not permit
	location information to be disclosed."/>		location information to be disclosed."/>
	Figure 5: Error Message		Figure 7: Error Message
	7. Security Considerations		6. Security Considerations
	This document assumes that the use of TLS to protect HTTP is		This document assumes that the use of TLS to protect HTTP is
	sufficient to protect the privacy of the PIDF-LO content while in		sufficient to protect the privacy of the PIDF-LO content while in
	flight. When access control at the LIS is not applied, as described		flight. When access control at the LIS is not applied, as described
	in the threat models in Section 4, then the possession of the		in Section 3.1, then the possession of the location URI is equal to
	location URI is equal to the possession of location information.		the possession of location information. When the requirements for
	When the requirements for creating a location URI, as described in		creating a location URI, as described in [7], are met, then the
	[I-D.winterbottom-geopriv-held-context], are met, then the reference		reference provides sufficiently high security guarantees for most
	provides sufficiently high security guarantees for most usages.		location-based applications. Furthermore, the ability of the Rule
	Furthermore, the ability of the Target to put constraints on the		Maker to put constraints on the dereferencing step, as described in
	dereferencing step, as described in		[14], provides the ability to restrict how often location can be
	[I-D.winterbottom-geopriv-held-context], provides additional security		accessed through a location URI, how long the URI is valid for, and
	guarantees.		the type of location information returned when a location URI is
			accessed. If this is still not sufficient then the Target is able to
			put authorization policies either to the LIS or uploads the Location
			URI to a presence server that hosts authorization policies, as
			described in [16].
	In the normal case, connection establishment from the Location		Connection establishment from the Location Recipient to the LIS will
	Recipient to the LIS will be made on HTTP over TLS, and the location		be made using HTTP over TLS, and the location URI being dereferenced
	URI being dereferenced by the Location Recipient will contain the		by the Location Recipient will contain the hostname of the LIS. The
	hostname of the LIS. The Location Recipient MUST check the FQDN of		Location Recipient MUST check the FQDN of the LIS in the reference
	the LIS in the reference with the identity presented in the server's		with the identity presented in the server's certificate. A
	certificate. A discrepancy may indicate a possible man-in-the-		discrepancy may indicate a possible man-in-the-middle-attack, and the
	middle-attack, and the Location Recipient should take appropriate		Location Recipient should take appropriate action based on
	action based on application dependent semantics. Actions may include		application dependent semantics. Actions may include but are not
	but are not limited to; proceeding anyway, flagging the result as		limited to; proceeding anyway, flagging the result as suspect, or
	suspect, or giving up.		giving up.
	In some applications the Location Recipient has a pre-established		In some applications the Location Recipient has a pre-established
	relationship with one or several Location Information Servers and		relationship with one or several Location Information Servers and
	hence the LIS might authorize only certain Location Recipients might		hence the LIS might authorize only certain Location Recipients might
	be allowed to resolve a reference.		be allowed to resolve a reference.
	8. IANA Considerations		7. IANA Considerations
	There are no specific IANA considerations for this document.		There are no specific IANA considerations for this document.
	9. Acknowledgements		8. Acknowledgements
	Thanks to Barbara Stark and Guy Caron for providing early comments.		Thanks to Barbara Stark and Guy Caron for providing early comments.
	Thanks to Rohan Mahy for constructive comments on the scope and		Thanks to Rohan Mahy for constructive comments on the scope and
	format of the document. Thanks to Ted Hardie for his strawman		format of the document. Thanks to Ted Hardie for his strawman
	proposal that provided assistance with the security section of this		proposal that provided assistance with the security section of this
	document.		document.
	10. References		The authors would like to thank the participants of the GEOPRIV
			interim meeting 2008 for their feedback.
	10.1. Normative References		James Polk provided comments on a security aspects in June 2008.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		9. References
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		9.1. Normative References
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object		[1] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP
	Format", RFC 4119, December 2005.		Enabled Location Delivery (HELD)",
			draft-ietf-geopriv-http-location-delivery-07 (work in
			progress), April 2008.
	[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and		[2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
	J. Polk, "Geopriv Requirements", RFC 3693, February 2004.		Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
			HTTP/1.1", RFC 2616, June 1999.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.		[3] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
	[I-D.ietf-geopriv-pdif-lo-profile]		[4] Peterson, J., "A Presence-based GEOPRIV Location Object
	Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV		Format", RFC 4119, December 2005.
	PIDF-LO Usage Clarification, Considerations and
	Recommendations", draft-ietf-geopriv-pdif-lo-profile-10
	(work in progress), October 2007.
	[I-D.ietf-geopriv-http-location-delivery]		[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,		Levels", BCP 14, RFC 2119, March 1997.
	"HTTP Enabled Location Delivery (HELD)",
	draft-ietf-geopriv-http-location-delivery-02 (work in
	progress), September 2007.
	[I-D.ietf-geopriv-lbyr-requirements]		[6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
	Marshall, R., "Requirements for a Location-by-Reference		PIDF-LO Usage Clarification, Considerations and
	Mechanism", draft-ietf-geopriv-lbyr-requirements-01 (work		Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work
	in progress), October 2007.		in progress), February 2008.
	10.2. Informative references		9.2. Informative references
	[I-D.ietf-geopriv-policy]		[7] Marshall, R., "Requirements for a Location-by-Reference
	Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,		Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work in
	and J. Polk, "Geolocation Policy: A Document Format for		progress), February 2008.
	Expressing Privacy Preferences for Location Information",
	draft-ietf-geopriv-policy-13 (work in progress),
	October 2007.
	[I-D.winterbottom-geopriv-held-context]		[8] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
	Winterbottom, J., Tschofenig, H., and M. Thomson, "HELD		Polk, "Geopriv Requirements", RFC 3693, February 2004.
	Protocol Context Management Extensions",
	draft-winterbottom-geopriv-held-context-01 (work in
	progress), October 2007.
	[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,		[9] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
	Polk, J., and J. Rosenberg, "Common Policy: A Document		Configuration Protocol; Problem Statement and Requirements",
	Format for Expressing Privacy Preferences", RFC 4745,		draft-ietf-geopriv-l7-lcp-ps-08 (work in progress), June 2008.
	February 2007.
	[I-D.ietf-sip-location-conveyance]		[10] Barnes, R., Lepinski, M., Tschofenig, H., and H. Schulzrinne,
	Polk, J. and B. Rosen, "Location Conveyance for the		"Security Requirements for the Geopriv Location System",
	Session Initiation Protocol",		draft-barnes-geopriv-lo-sec-02 (work in progress),
	draft-ietf-sip-location-conveyance-08 (work in progress),		February 2008.
	July 2007.
	[I-D.ietf-geopriv-l7-lcp-ps]		[11] Polk, J. and B. Rosen, "Location Conveyance for the Session
	Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7		Initiation Protocol", draft-ietf-sip-location-conveyance-10
	Location Configuration Protocol; Problem Statement and		(work in progress), February 2008.
	Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in
	progress), September 2007.		[12] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk,
			J., and J. Rosenberg, "Common Policy: A Document Format for
			Expressing Privacy Preferences", RFC 4745, February 2007.
			[13] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and
			J. Polk, "Geolocation Policy: A Document Format for Expressing
			Privacy Preferences for Location Information",
			draft-ietf-geopriv-policy-17 (work in progress), June 2008.
			[14] Winterbottom, J., Tschofenig, H., and M. Thomson, "HELD
			Protocol Context Management Extensions",
			draft-winterbottom-geopriv-held-context-02 (work in progress),
			February 2008.
			[15] Thomson, M. and J. Winterbottom, "Discovering the Local
			Location Information Server (LIS)",
			draft-ietf-geopriv-lis-discovery-01 (work in progress),
			June 2008.
			[16] Garcia-Martin, M., Tschofenig, H., and H. Schulzrinne,
			"Indirect Presence Publication with the Session Initiation
			Protocol(SIP)",
			draft-garcia-simple-indirect-presence-publish-00 (work in
			progress), February 2008.
	Appendix A. GEOPRIV Using Protocol Compliance		Appendix A. GEOPRIV Using Protocol Compliance
	This section compares the GEOPRIV requirements described in [RFC3693]		This section compares the GEOPRIV requirements described in [8] with
	with the approach outlined in this document.		the approach outlined in this document.
	Req. 1. (Location Object generalities):		Req. 1. (Location Object generalities):
	o Regarding requirement 1.1, the Location Object has to be		o Regarding requirement 1.1, the Location Object has to be
	understood by the Location Recipient and the Location Server, the		understood by the Location Recipient and the Location Server, the
	two communication end points. The PIDF-LO [RFC4119] allows both		two communication end points. The PIDF-LO [4] allows both civic
	civic and geospatial location information to be expressed.		and geospatial location information to be expressed. Combining
	Combining this with [I-D.ietf-geopriv-pdif-lo-profile] ensures		this with [6] ensures that location can be constructed and
	that location can be constructed and interpreted in a consistent		interpreted in a consistent manner.
	manner.
	o Regarding requirement 1.2, a number of fields in the civic		o Regarding requirement 1.2, a number of fields in the civic
	location information format are optional.		location information format are optional.
	o Regarding requirement 1.3, the civic location information is		o Regarding requirement 1.3, the civic location information is
	defined in an extensible way.		defined in an extensible way.
	o Regarding requirement 1.4, the location information itself is not		o Regarding requirement 1.4, the location information itself is not
	defined in this document.		defined in this document.
	skipping to change at page 18, line 42 ¶		skipping to change at page 19, line 41 ¶
	o Regarding requirement 1.6, the Location Object contains both		o Regarding requirement 1.6, the Location Object contains both
	location information and privacy rules. Depending on the		location information and privacy rules. Depending on the
	deployment scenario, which is outside the scope of this document,		deployment scenario, which is outside the scope of this document,
	the privacy rules might have stronger or a weaker semantic.		the privacy rules might have stronger or a weaker semantic.
	o Regarding requirement 1.7, the Location Object is usable in a		o Regarding requirement 1.7, the Location Object is usable in a
	variety of protocols.		variety of protocols.
	o Regarding requirement 1.8, no change regarding with respect to the		o Regarding requirement 1.8, no change regarding with respect to the
	encoding of the Location Object (see [RFC4119]) was made by this		encoding of the Location Object (see [4]) was made by this
	document.		document.
	Req. 2. (Location Object fields):		Req. 2. (Location Object fields):
	o Regarding requirement 2.1, depending on the deployment scenario an		o Regarding requirement 2.1, depending on the deployment scenario an
	identifier pointing to the Target may be carried inside the		identifier pointing to the Target may be carried inside the
	PIDF-LO since the PIDF object provides the ability to carry this		PIDF-LO since the PIDF object provides the ability to carry this
	identifier. In some circumstances it might be desirable not to		identifier. In some circumstances it might be desirable not to
	carry information about the Target's identity in the PIDF-LO.		carry information about the Target's identity in the PIDF-LO.
	skipping to change at page 19, line 40 ¶		skipping to change at page 20, line 40 ¶
	This is the <external-ruleset> element.		This is the <external-ruleset> element.
	o Regarding requirement 2.9, security headers and trailers are		o Regarding requirement 2.9, security headers and trailers are
	provided Transport Layer Security.		provided Transport Layer Security.
	o Regarding requirement 2.10, extensibility within the PIDF-LO is		o Regarding requirement 2.10, extensibility within the PIDF-LO is
	provided regarding the definition of namespaces.		provided regarding the definition of namespaces.
	Req. 3. (Location Data Types):		Req. 3. (Location Data Types):
	o Regarding requirement 3.1, [RFC4119] defines geospatial location		o Regarding requirement 3.1, [4] defines geospatial location
	information as the mandatory to implement location format.		information as the mandatory to implement location format. [6]
	[I-D.ietf-geopriv-pdif-lo-profile] describes in more detail the		describes in more detail the acceptable forms of geolocation and
	acceptable forms of geolocation and its interaction with civic		its interaction with civic notations.
	notations.
	o With the support of civic and geodedic location information in		o With the support of civic and geodedic location information in [4]
	[RFC4119] the requirement 3.2 is fulfilled.		the requirement 3.2 is fulfilled.
	o Regarding requirement 3.3, rules described in		o Regarding requirement 3.3, rules described in [13] apply to an
	[I-D.ietf-geopriv-policy] apply to an absolute geodetic point.		absolute geodetic point. Geodetic information expressed in a
	Geodetic information expressed in a PIDF-LO that complies with		PIDF-LO that complies with [6] may express an area or volume
	[I-D.ietf-geopriv-pdif-lo-profile] may express an area or volume
	there-by "fuzzing" the location of the Target.		there-by "fuzzing" the location of the Target.
	o Regarding requirement 3.4, since the PIDF-LO format is designed to		o Regarding requirement 3.4, since the PIDF-LO format is designed to
	be extensible it allows further location information types to be		be extensible it allows further location information types to be
	defined in the future.		defined in the future.
	Section 7.2 of [RFC3693] details the requirements of a "Using		Section 7.2 of [8] details the requirements of a "Using Protocol".
	Protocol". These requirements are listed below:		These requirements are listed below:
	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 regarding the		instructions coded in the Location Object regarding the
	transmission and storage of the LO. This document carries		transmission and storage of the LO. This document carries
	the PIDF-LO as is via HTTPS from the LIS to the Location		the PIDF-LO as is via HTTPS from the LIS to the Location
	Recipient. The sending and receiving parties must obey the		Recipient. The sending and receiving parties must obey the
	instructions carried inside the object.		instructions carried inside the object.
	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. This document does		responsibility of the using protocol. This document does
	not define additional security mechanisms beyond HTTPS.		not define additional security mechanisms beyond HTTPS.
	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
	message / packet transmission of location as a complete		message / packet transmission of location as a complete
	transaction. The encoding of the RFC 4119-defined Location		transaction. The encoding of the RFC 4119-defined Location
	Object format is not changed. Because of the verbose XML		Object format is not changed. Because of the verbose XML
	encoding it is not tailored towards inclusion into a single		encoding it is not tailored towards inclusion into a single
	message.		message.
	Section 7.3 of [RFC3693] details the requirements of a "Rule based		Section 7.3 of [8] details the requirements of a "Rule based Location
	Location Data Transfer". These requirements are listed below:		Data Transfer". These requirements are listed below:
	Req. 7. (LS Rules): Access to location information is controlled by		Req. 7. (LS Rules): Access to location information is controlled by
	allowing the Target (or by an entity on behalf of the		allowing the Target (or by an entity on behalf of the
	Target) to indicate to which Location Recipients the short-		Target) to indicate to which Location Recipients the short-
	lived location URI that contains a unguessable random		lived location URI that contains a unguessable random
	component. Additionally, constraints can be put on the		component. Additionally, constraints can be put on the
	dereferencing step by the Target.		dereferencing step by the Target.
	Req. 8. (LG Rules): In context of location URI it is not possible		Req. 8. (LG Rules): In context of location URI it is not possible
	that there is no relationship between the Location Generator		that there is no relationship between the Location Generator
	and the Location Information Server. As such, the statement		and the Location Information Server. As such, the statement
	made in Requirement 7 applies.		made in Requirement 7 applies.
	Req. 9. (Viewer Rules): The Rule Maker might define (via mechanisms		Req. 9. (Viewer Rules): 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. These mechanisms are available		disclosed to other entities. These mechanisms are available
	with [I-D.ietf-geopriv-policy]. These rules are, however,		with [13]. These rules are, however, best used when the
	best used when the location URI is not directly provided to		location URI is not directly provided to Location Recipients
	Location Recipients but rather to an intermediary that		but rather to an intermediary that stores these
	stores these authorization policies, such as a location-		authorization policies, such as a location-based presence
	based presence server.		server.
	Req. 10. (Full Rule language): Geopriv has defined a rule language		Req. 10. (Full Rule language): Geopriv has defined a rule language
	capable of expressing a wide range of privacy rules which		capable of expressing a wide range of privacy rules which
	is applicable in the area of the distribution of Location		is applicable in the area of the distribution of Location
	Objects. The format of these rules are described in		Objects. The format of these rules are described in [12]
	[RFC4745] and [I-D.ietf-geopriv-policy]. These rules may		and [13]. These rules may be used in a larger context but
	be used in a larger context but this document does not		this document does not define their usage.
	define their usage.
	Req. 11. (Limited Rule language): A limited (or basic) ruleset was		Req. 11. (Limited Rule language): A limited (or basic) ruleset was
	introduced with PIDF-LO [RFC4119]).		introduced with PIDF-LO [4]).
	Section 7.4 of [RFC3693] details the requirements of "Location Object		Section 7.4 of [8] details the requirements of "Location Object
	Privacy and Security". These requirements are listed below:		Privacy and Security". These requirements are listed below:
	Req. 12. (Identity Protection): Identity protection of the Target		Req. 12. (Identity Protection): Identity protection of the Target
	can be provided if both the following conditions are true:		can be provided if both the following conditions are true:
	(a) the protocol used to convey the reference does not		(a) the protocol used to convey the reference does not
	disclose the identity of the Target and		disclose the identity of the Target and
	(b) if the PIDF-LO does not contain information about the		(b) if the PIDF-LO does not contain information about the
	identity about the Target.		identity about the Target.
	Currently, there is no mechanism available that allows the		Currently, there is no mechanism available that allows the
	Target to tell the LIS which identity information to		Target to tell the LIS which identity information to
	include in the PIDF-LO.		include in the PIDF-LO.
	Req. 13. (Credential Requirements): The security mechanism specified		Req. 13. (Credential Requirements): The security mechanism
	in this document is Transport Layer Security. TLS offers		specified in this document is Transport Layer Security.
	the ability to use different types of credentials,		TLS offers the ability to use different types of
	including symmetric, asymmetric credentials or a		credentials, including symmetric, asymmetric credentials or
	combination of them.		a combination of them.
	Req. 14. (Security Features): Geopriv defines a few security		Req. 14. (Security Features): Geopriv defines a few security
	requirements for the protection of Location Objects such as		requirements for the protection of Location Objects such as
	mutual end-point authentication, data object integrity,		mutual end-point authentication, data object integrity,
	data object confidentiality and replay protection. The		data object confidentiality and replay protection. The
	ability to use Transport Layer security fulfills these		ability to use Transport Layer security fulfills these
	requirements.		requirements.
	Req. 15. Minimal Crypto: The mandatory to implement ciphersuite is		Req. 15. Minimal Crypto: The mandatory to implement ciphersuite is
	provided in the TLS layer security specification.		provided in the TLS layer security specification.
	Appendix B. HELD Compliance to IETF Location Reference Requirements		Appendix B. HELD Compliance to IETF Location Reference Requirements
	This section describes how HELD complies to the location reference		This section describes how HELD complies to the location reference
	requirements stipulated in [I-D.ietf-geopriv-lbyr-requirements].		requirements stipulated in [7].
	High-level requirements for a location configuration protocol.		High-level requirements for a location configuration protocol.
	C1. "Location URI support - LCP: The configuration protocol MUST		C1. "Location URI support - LCP: The configuration protocol MUST
	support a location reference in URI form."		support a location reference in URI form."
	COMPLY. HELD only provides location references in URI form.		COMPLY. HELD only provides location references in URI form.
	C2. "Location URI expiration: The LCP MUST support the ability to		C2. "Location URI expiration: The LCP MUST support the ability to
	specify to the server, the length of time that a location URI		specify to the server, the length of time that a location URI
	will be valid."		will be valid."
	COMPLY. basic HELD supports the LIS informing the Target of the		COMPLY. basic HELD supports the LIS informing the Target of the
	location URI expiry time. HELD context management extension		location URI expiry time. HELD context management extension
	[I-D.winterbottom-geopriv-held-context] provides the Target the		[14] provides the Target the ability to specify exipry times for
	ability to specify exipry times for location URIs.		location URIs.
	C3. "Location URI cancellation: The LCP MUST support the ability to		C3. "Location URI cancellation: The LCP MUST support the ability to
	request the cancellation of a specific location URI."		request the cancellation of a specific location URI."
	COMPLY. HELD context management extension		COMPLY. HELD context management extension [14] provides the
	[I-D.winterbottom-geopriv-held-context] provides the Target the		Target the ability to void location URIs when required.
	ability to void location URIs when required.
	C4. "Random Generated: The location URI MUST be hard to guess, i.e.,		C4. "Random Generated: The location URI MUST be hard to guess, i.e.,
	it MUST contain a cryptographically random component."		it MUST contain a cryptographically random component."
	COMPLY. The HELD specification provides specific guidance on		COMPLY. The HELD specification provides specific guidance on
	the security surrounding location URI generation.		the security surrounding location URI generation.
	C5. "Identity Protection - LCP: The location URI MUST NOT contain		C5. "Identity Protection - LCP: The location URI MUST NOT contain
	any information that identifies the user, device or address of		any information that identifies the user, device or address of
	record within the URI form."		record within the URI form."
	skipping to change at page 24, line 18 ¶		skipping to change at page 25, line 17 ¶
	of a requested location URI being repeatedly reused."		of a requested location URI being repeatedly reused."
	COMPLY. The default semantics of location URIs in HELD place no		COMPLY. The default semantics of location URIs in HELD place no
	limits on the number of times that a location URI can be		limits on the number of times that a location URI can be
	dereferenced.		dereferenced.
	C7. "One-time-use: The LCP MUST support the ability for the client		C7. "One-time-use: The LCP MUST support the ability for the client
	to request a 'one-time-use' location URI (e.g., via a reuse flag		to request a 'one-time-use' location URI (e.g., via a reuse flag
	setting)."		setting)."
	COMPLY. HELD context management extension		COMPLY. HELD context management extension [14] provides the
	[I-D.winterbottom-geopriv-held-context] provides the Target the		Target the ability to set the number of times that a location
	ability to set the number of times that a location URI may yield		URI may yield the Target's location.
	the Target's location.
	High-level requirements for a location dereference protocol.		High-level requirements for a location dereference protocol.
	D1. "Location URI support - LDP: The LDP MUST support a location		D1. "Location URI support - LDP: The LDP MUST support a location
	reference in URI form."		reference in URI form."
	COMPLY. HELD only provides location references in URI form.		COMPLY. HELD only provides location references in URI form.
	D2. "Location URI expiration status: The LDP MUST support a message		D2. "Location URI expiration status: The LDP MUST support a message
	indicating that for a location URI which is no longer valid,		indicating that for a location URI which is no longer valid,
	skipping to change at page 25, line 8 ¶		skipping to change at page 26, line 6 ¶
	a location URI is found to have expired.		a location URI is found to have expired.
	D3. "Authentication: The LDP MUST support either client-side and		D3. "Authentication: The LDP MUST support either client-side and
	server-side authentication between client and server."		server-side authentication between client and server."
	COMPLY. Client authentication may be provided using a variety		COMPLY. Client authentication may be provided using a variety
	of techniques. However, this document does not mandate a		of techniques. However, this document does not mandate a
	specific procedure nor does it specify the format of		specific procedure nor does it specify the format of
	authorization policies that may be in place to control access at		authorization policies that may be in place to control access at
	the LIS. The server authenticates itself using the methods		the LIS. The server authenticates itself using the methods
	described in HTTP on TLS [RFC2818].		described in HTTP on TLS [3].
	D4. "Dereferenced Location Form: Location URI dereferencing MUST		D4. "Dereferenced Location Form: Location URI dereferencing MUST
	result in a well-formed PIDF-LO."		result in a well-formed PIDF-LO."
	COMPLY. HELD when used as a dereference protocol MUST provide		COMPLY. HELD when used as a dereference protocol MUST provide
	location information as a PIDF-LO that complies with		location information as a PIDF-LO that complies with [6] as
	[I-D.ietf-geopriv-pdif-lo-profile] as described in Section 5.		described in Section 4.
	D5. "Repeated use: The LDP MUST support the ability for the same		D5. "Repeated use: The LDP MUST support the ability for the same
	location URI to be resolved more than once, based on server		location URI to be resolved more than once, based on server
	settings and LCP parameters."		settings and LCP parameters."
	COMPLY. A Location Recipient may access and use a location URI		COMPLY. A Location Recipient may access and use a location URI
	as many times as desired until such time as the URI expires due		as many times as desired until such time as the URI expires due
	to age, or is made invalid by other Target policies on the LIS.		to age, or is made invalid by other Target policies on the LIS.
	D6. "Updated location: The LDP MUST support the ability for the same		D6. "Updated location: The LDP MUST support the ability for the same
	skipping to change at page 26, line 13 ¶		skipping to change at page 27, line 13 ¶
	they require.		they require.
	Authors' Addresses		Authors' Addresses
	James Winterbottom		James Winterbottom
	Andrew Corporation		Andrew Corporation
	PO Box U40		PO Box U40
	University of Wollongong, NSW 2500		University of Wollongong, NSW 2500
	AU		AU
	Phone: +61 242 212938		Phone: +61 242 212938
	Email: james.winterbottom@andrew.com		Email: james.winterbottom@andrew.com
	URI: http://www.andrew.com/products/geometrix		URI: http://www.andrew.com/products/geometrix
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Otto-Hahn-Ring 6		Linnoitustie 6
	Munich, Bavaria 81739		Espoo 02600
	Germany		Finland
	Phone: +49 89 636 40390		Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@nsn.com		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.com		URI: http://www.tschofenig.priv.at
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building, New York, NY 10027		450 Computer Science Building, New York, NY 10027
	US		US
	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
	Martin Thomson		Martin Thomson
	Andrew Corporation		Andrew Corporation
	PO Box U40		PO Box U40
	University of Wollongong, NSW 2500		University of Wollongong, NSW 2500
	AU		AU
	Email: martin.thomson@andrew.com		Email: martin.thomson@andrew.com
	Martin Dawson		Martin Dawson
	Andrew Corporation		Andrew Corporation
	PO Box U40		PO Box U40
	University of Wollongong, NSW 2500		University of Wollongong, NSW 2500
	AU		AU
	Email: martin.dawson@andrew.com		Email: martin.dawson@andrew.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	skipping to change at page 28, line 44 ¶		skipping to change at line 989 ¶
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 105 change blocks.
	308 lines changed or deleted		388 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/