idnits 2.17.00 (12 Aug 2021)
/tmp/idnits35570/draft-barnes-geopriv-policy-uri-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (November 9, 2010) is 4204 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-19) exists of
draft-ietf-geopriv-dhcp-lbyr-uri-option-09
== Outdated reference: draft-ietf-geopriv-http-location-delivery has been
published as RFC 5985
** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
== Outdated reference: draft-ietf-geopriv-deref-protocol has been published
as RFC 6753
== Outdated reference: draft-ietf-geopriv-held-identity-extensions has been
published as RFC 6155
== Outdated reference: draft-ietf-geopriv-policy has been published as RFC
6772
== Outdated reference: draft-ietf-geopriv-rfc3825bis has been published as
RFC 6225
Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 GEOPRIV R. Barnes
3 Internet-Draft BBN Technologies
4 Intended status: Informational M. Thomson
5 Expires: May 13, 2011 J. Winterbottom
6 Andrew Corporation
7 H. Tschofenig
8 Nokia Siemens Networks
9 November 9, 2010
11 Location Configuration Extensions for Policy Management
12 draft-barnes-geopriv-policy-uri-02
14 Abstract
16 Current location configuration protocols are capable of provisioning
17 an Internet host with a location URI that refers to the host's
18 location. These protocols lack a mechanism for the target host to
19 inspect or set the privacy rules that are applied to the URIs they
20 distribute. This document extends the current location configuration
21 protocols to provide hosts with a reference to the rules that are
22 applied to a URI, so that the host can view or set these rules.
24 Status of this Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at http://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on May 13, 2011.
41 Copyright Notice
43 Copyright (c) 2010 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
60 3. Policy URIs . . . . . . . . . . . . . . . . . . . . . . . . . 4
61 3.1. Policy URI Usage . . . . . . . . . . . . . . . . . . . . . 4
62 3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 5
63 4. Location Configuration Extensions . . . . . . . . . . . . . . 6
64 4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
65 4.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
66 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
67 5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
68 5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
69 5.3. Basic access control policy . . . . . . . . . . . . . . . 9
70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
72 7.1. URN Sub-Namespace Registration for
73 urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 12
74 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
75 7.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 13
76 8. Operational Considerations . . . . . . . . . . . . . . . . . . 13
77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
78 9.1. Integrity and Confidentiality for Authorization Policy
79 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
80 9.2. Access Control for Authorization Policy . . . . . . . . . 14
81 9.3. Location URI Allocation . . . . . . . . . . . . . . . . . 15
82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
84 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
87 1. Introduction
89 A critical step in enabling Internet hosts to access location-based
90 services is to provision those hosts with information about their own
91 location. This is accomplished via a Location Configuration Protocol
92 (LCP) [RFC5687], which allows a location provider (e.g., a local
93 access network) to inform a host about its location.
95 There are two basic patterns for location configuration, namely
96 configuration "by value" and "by reference" [RFC5808]. Configuration
97 by value provisions a host directly with its location, by providing
98 it location information that is directly usable (e.g., coordinates or
99 a civic address). Configuration by reference provides a host with a
100 URI that references the host's location, i.e., one that can be
101 dereferenced to obtain the location (by value) of the host.
103 In some cases, location by reference offers a few benefits over
104 location by value. From a privacy perspective, the required
105 dereference transaction provides a policy enforcement point, so that
106 the opaque URI itself can be safely conveyed over untrusted media
107 (e.g., SIP through untrusted proxies [RFC5606]). If the target host
108 is mobile, an application provider can use a single reference to
109 obtain the location of the host multiple times, saving bandwidth to
110 the host. For some configuration protocols, the location object
111 referenced by a location URI provides a much more expressive syntax
112 for location values than the configuration protocol itself (e.g.,
113 DHCP geodetic location [I-D.ietf-geopriv-rfc3825bis] versus GML in a
114 PIDF-LO [RFC4119]).
116 From a privacy perspective, however, current LCPs are limited in
117 their flexibility, in that they do not provide the Device (the client
118 in an LCP) with a way to inform the Location Server with policy for
119 how his location information should be handled. This document
120 addresses this gap by defining a simple mechanism for referring to
121 and manipulating policy, and by extending current LCPs to carry
122 policy references. Using the mechanisms defined in this document, an
123 LCP server (acting for the Location Server) can inform a client as to
124 which policy document controls a given location resource, and the LCP
125 client (in its Rule Maker role) can inspect this document and modify
126 it as necessary.
128 The remainder of this document is structured as follows: After
129 introducing a few relevant terms, we define policy URIs as a channel
130 for referencing, inspecting, and updating policy documents. We then
131 define extensions to the HELD protocol and the DHCP option for
132 location by reference to allow these protocols to carry policy URIs.
133 Examples are given that demonstrate how policy URIs are carried in
134 these protocols and how they can be used by clients.
136 2. Definitions
138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
140 document are to be interpreted as described in RFC 2119 [RFC2119].
142 3. Policy URIs
144 A policy URI is an HTTP [RFC2616] URI that identifies a policy
145 resource that contains the authorization policy for a linked location
146 resource. Access to the location resource is governed by the
147 contents of the authorization policy.
149 A policy URI identifies an HTTP resource that a Rule Maker can use to
150 inspect and install policy documents that tell a Location Server how
151 it should protect the associated location resource. A policy URI
152 always identifies a resource that can be represented as a common-
153 policy document [RFC4745] (possibly including some extensions; e.g.,
154 for geolocation policy [I-D.ietf-geopriv-policy]).
156 Note: RFC 3693 [RFC3693] identified the Rule Holder role as the one
157 that stores policy information. In this document, the Location
158 Server is also a Rule Holder.
160 3.1. Policy URI Usage
162 A Location Server that is the authority for policy URIs MUST support
163 GET, PUT, and DELETE requests to these URIs, in order to allow
164 clients to inspect, replace, and delete policy documents. Clients
165 support the three request methods as they desire to perform these
166 operations.
168 Knowledge of the policy URI can be considered adequate evidence of
169 authorization. A Location Server SHOULD allow all requests, but it
170 MAY deny certain requests based on local policy. For instance, a
171 Location Server might allow clients to inspect policy (GET), but not
172 to update it (PUT).
174 A GET request to a policy URI is a request for the referenced policy
175 information. If the request is authorized, then the Location Server
176 sends an HTTP 200 response containing the complete policy identified
177 by the URI.
179 A PUT request to a policy URI is a request to replace the current
180 policy. The entity-body of a PUT request includes a complete policy
181 document. When a Location Server receives a PUT request, it MUST
182 validate the policy document included in the body of the request. If
183 the request is valid and authorized, then the Location Server
184 replaces the current policy with the policy provided in the request.
186 A DELETE request to a policy URI is a request to delete the
187 referenced policy document and terminate access to the protected
188 resource. If the request is authorized, then the Location Server
189 deletes the policy referenced by the URI and disallows any further
190 access to the location resource it governs.
192 The Location Server MUST support policy documents in the common-
193 policy format [RFC4745], as identified by the MIME media type of
194 "application/auth-policy+xml". The common-policy format MUST be
195 provided as the default format in response to GET requests that do
196 not include specific "Accept" headers, but content negotiation MAY be
197 used to allow for other formats.
199 This usage of HTTP is generally compatible with the use of XCAP
200 [RFC4825] or WebDAV [RFC4918] to manage policy documents, but this
201 document does not define or require the use of these protocols.
203 3.2. Policy URI Allocation
205 A Location Server creates a policy URI for a specific location
206 resource at the time that the location resource is created; that is,
207 a policy URI is created at the same time as the location URI that it
208 controls. The URI of the policy resource MUST be different to the
209 location URI.
211 A policy URI is provided to a target device as part of the location
212 configuration process. A policy URI MUST NOT be provided to an
213 entity that is not authorized to view or set policy. A location
214 server that provides a location configuration in addition to other
215 location services (e.g., answering dereferencing requests
216 [I-D.ietf-geopriv-deref-protocol] or requests from third parties
217 [I-D.ietf-geopriv-held-identity-extensions]) MUST only include policy
218 URIs in response to location configuration requests.
220 Each location URI has either one policy URI or no policy URI. A
221 location server MUST NOT allocate multiple policy URIs controlling
222 the same locatin URI. The initial policy that is referenced by a
223 policy URI MUST be identical to the policy that would be applied in
224 the absence of a policy URI. A client that does not support policy
225 URIs can continue to use the location URI as they would have if no
226 policy URI were provided.
228 Without a policy URI, clients have no way to know what this
229 default policy is. The safest assumption for clients is that the
230 default policy grants any request to dereference a location URI,
231 regardless of the requester's identity. With a policy URI, a
232 client can ask the server to describe the default policy (with a
233 GET request), or update the policy with a PUT request, prior to
234 distributing the location URI.
236 A Location Server chooses whether or not to provide a policy URI
237 based on local policy. A HELD-specific extension also allows a
238 requester to specifically ask for a policy URI.
240 A policy URI is a shared secret between Location Server and its
241 clients. Knowledge of a policy URI is all that is required to
242 perform any operations allowed on the policy. Thus, a policy URI is
243 constructed so that it is hard to predict (see Section 9).
245 4. Location Configuration Extensions
247 Location configuration protocols can provision hosts with location
248 URIs that refer to the host's location. If the target host is to
249 control policy on these URIs, it needs a way to access the policy
250 that the Location Server uses to guide how it serves location URIs.
251 This section defines extensions to LCPs to carry policy URIs that the
252 target can use to control access to location resources.
254 4.1. HELD
256 The HELD protocol [I-D.ietf-geopriv-http-location-delivery] defines a
257 "locationUriSet" element, which contain a set of one or more location
258 URIs that reference the same resource and share a common access
259 control policy. The schema in Figure 1 defines two extension
260 elements for HELD: an empty "requestPolicyUri" element that is added
261 to a location request to indicate that a Device desires that a policy
262 URI be allocated; and a "policyUri" element that is included as a
263 sub-element of the HELD "locationResponse" element.
265
266
272
273
274
276
278
280 Figure 1
282 The URI carried in a "policyUri" element refers to the common access
283 control policy for requests for the target's location, including
284 dereference requests for location URIs in the location response as
285 well as third-party requests. The URI MUST be a policy URI as
286 described in Section 3. A policy URI MUST use the "http:" or
287 "https:" scheme, and the Location Server MUST support the specified
288 operations on the URI.
290 A HELD request MAY contain an explicit request for a policy URI. The
291 presence of the "requestPolicyUri" element in a location request
292 indicates that a policy URI is desired. A ocation server may provide
293 a policy URI regardless of the presence of this element.
295 4.2. DHCP
297 The DHCP location by reference option
298 [I-D.ietf-geopriv-dhcp-lbyr-uri-option] provides location URIs in
299 sub-options called LuriElements. This document defines a new
300 LuriElement type for policy URIs.
302 LuriType=TBD Policy-URI - This is a policy URI that refers to the
303 access control policy for the location URIs.
305 [NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned
306 LuriType value and remove this note]
308 A Policy-URI LuriElement uses a UTF-8 character encoding.
310 A Policy-URI LuriElement identifies the policy resource for all
311 location URIs included in the location URI option. The URI MUST be a
312 policy URI as described in Section 3: It MUST use either the "http:"
313 or "https:" scheme, and the Location Server MUST support the
314 specified operations on the URI.
316 5. Examples
318 In this section, we provide some brief illustrations of how policy
319 URIs are delivered to target hosts and used by those hosts to manage
320 policy.
322 5.1. HELD
324 A HELD request that explicitly requests the creation of a policy URI
325 has the following form:
327
328 locationURI
329
331
333 A HELD response providing a single "locationUriSet", containing two
334 URIs under a common policy, would have the following form:
336
337
338
339 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
340
341
342 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
343
344
345
346 https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b
347
348
350 5.2. DHCP
352 A DHCP option providing one of the location URIs and the
353 corresponding policy URI from the previous example would have the
354 following form:
356 0 1 2 3
357 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
359 | option-code | 110 |
360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
361 | 1 | 0 | 1 | 49 | 'h' |
362 +---------------+---------------+---------------+---------------|
363 | 't' | 't' | 'p' | 's' |
364 +---------------+---------------+---------------+---------------|
365 | ':' | '/' | '/' | 'l' |
366 +---------------+---------------+---------------+---------------|
367 | 's' | '.' | ... |
368 +---------------+---------------+---------------+---------------|
369 | TBD | 56 | 'h' 't' |
370 +---------------+---------------+---------------+---------------|
371 | 't' | 'p' | 's' | ':' |
372 +---------------+---------------+---------------+---------------|
373 | '/' | '/' | ... |
374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
376 [NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned
377 LuriType value and remove this note]
379 5.3. Basic access control policy
381 Consider a user that gets the policy URI
382 , as in the
383 above LCP example. The first thing this allows the user to do is
384 inspect the default policy that the LS has assigned to this URI:
386 GET /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
387 Host: ls.example.com:9768
389 HTTP/1.1 200 OK
390 Content-type: application/auth-policy+xml
391 Content-length: 388
393
394
396
397
398
399 2011-01-01T13:00:00.0Z
400
401
402
403
404
405
406 false
407
408 0
409
410
411
413 This policy allows any requester to obtain location information, as
414 long as they know the location URI. If the user disagrees with this
415 policy, and prefers for example, to only provide location to one
416 friend, at a city level of granularity, then he can install this
417 policy on the Location Server:
419 PUT /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
420 Host: ls.example.com:9768
421 Content-type: application/auth-policy+xml
422 Content-length: 462
424
425
426
427
428
429
430
431
432 2011-01-01T13:00:00.0Z
433
434
435
436
437
439 city
440
441
442
443
445 HTTP/1.1 200 OK
447 Finally, after using the URI for a period, the user wishes to
448 permanently invalidate the URI.
450 DELETE /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
451 Host: ls.example.com:9768
453 HTTP/1.1 200 OK
455 6. Acknowledgements
457 Thanks to Mary Barnes, Alissa Cooper, and Hannes Tschofenig for
458 providing critical commentary and input on the ideas described in
459 this document.
461 7. IANA Considerations
463 This document requires several IANA registrations, detailed below.
465 7.1. URN Sub-Namespace Registration for
466 urn:ietf:params:xml:ns:geopriv:held:policy
468 This section registers a new XML namespace,
469 "urn:ietf:params:xml:ns:geopriv:held:policy", per the guidelines in
470 [RFC3688].
472 URI: urn:ietf:params:xml:ns:grip
474 Registrant Contact: IETF, GEOPRIV working group,
475 (geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com).
477 XML:
479 BEGIN
480
481
483
484
485 HELD Policy URI Extension
486
487
488 Namespace for HELD Policy URI Extension
489 urn:ietf:params:xml:ns:geopriv:held:policy
490 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX
491 with the RFC number for this specification.]
492 See RFCXXXX
493
494
495 END
497 7.2. XML Schema Registration
499 This section registers an XML schema as per the guidelines in
500 [RFC3688].
502 URI: urn:ietf:params:xml:schema:geopriv:held:policy
504 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org),
505 Richard Barnes (rbarnes@bbn.com)
507 Schema: The XML for this schema can be found in Section Section 4.1.
509 7.3. DHCP LuriType Registration
511 IANA is requested to add a value to the LuriTypes registry, as
512 follows:
514 +------------+----------------------------------------+-----------+
515 | LuriType | Name | Reference |
516 +------------+----------------------------------------+-----------+
517 | TBD* | Policy-URI | RFC XXXX**|
518 +------------+----------------------------------------+-----------+
520 * TBD is to be replaced with the assigned value
521 ** RFC XXXX is to be replaced with this document's RFC number.
523 8. Operational Considerations
525 Associating a user's privacy preferences with a location URI can have
526 a performance impact on the location configuration process, both in
527 terms of protocol execution time and the state that a location server
528 is required to store. There are additional protocol interactions (as
529 described above), and the location server must store the user's
530 privacy policies in addition to purely location-related state.
532 The mechanism that this document defines for installing policy
533 conducts policy management actions through a separate set of
534 interactions from the main location configuration transaction, rather
535 than carrying policy-management messages in existing location
536 configuration messages. This design decision imposes the cost of at
537 least one an additional HTTP transaction on endpoints that wish to
538 configure privacy policies. At the same time, however, it minimizes
539 the changes that need to be made to a location configuration
540 protocol, so that both HELD and DHCP can support policy management in
541 basically the same fashion.
543 A server that supports this extension must store additional state for
544 a location URI. By default, a location server only needs to keep
545 location-related state for a location URI, so that it can compute
546 location values to return in response to dereference requests. A
547 server supporting this extension also has to store policy
548 information. Such a server can mitigate the impact of this
549 requirement by not storing policy information explicitly for each
550 location URI. Until a user supplies his own policies, the server
551 will apply a default policy, which doesn't need to be described
552 separately for each location URI. So the amount of policy state that
553 a server has to maintain scales as the number of users that actually
554 supply their own policy information. If policy URIs are constructed
555 so that they can be associated with their corresponding location URIs
556 algorithmically, then the server doesn't even need to maintain a
557 table to store these associations.
559 Finally, a server that does not wish to be subject to any of these
560 costs can opt not to support this extension at all. Such a server
561 would simply never provide a "policyUri" element in a response,
562 silently ignoring any "requestPolicyUri" element it might receive in
563 a request.
565 9. Security Considerations
567 There are two main classes of risks associated with access control
568 policy management: The risk of unauthorized disclosure of the
569 protected resource via manipulation of the policy management process,
570 and the risk of disclosure of policy information itself.
572 Protecting the policy management process from manipulation entails
573 two primary requirements: First, the policy URI has to be faithfully
574 and confidentially transmitted to the client, and second, the policy
575 document has to be faithfully and confidentially transmitted to the
576 Location Server. The mechanism also needs to ensure that only
577 authorized entities are able to acquire or alter policy.
579 9.1. Integrity and Confidentiality for Authorization Policy Data
581 Each LCP ensures integrity and confidentiality through different
582 means (see [I-D.ietf-geopriv-http-location-delivery] and
583 [I-D.ietf-geopriv-dhcp-lbyr-uri-option]). These measures ensure that
584 a policy URI is conveyed to the client without modification or
585 interception.
587 To protect the integrity and confidentiality of policy data during
588 management, the Location Server SHOULD provide policy URIs with the
589 "https:" scheme and require the use of HTTP over TLS [RFC2818]. The
590 cipher suites required by TLS [RFC5246] provide both integrity
591 protection and confidentiality. If other means of protection are
592 available, an "http:" URI MAY be used.
594 9.2. Access Control for Authorization Policy
596 Access control for the policy resource is based on knowledge of its
597 URI. The URI of a policy resource operates under the same
598 constraints as a possession model location URI [RFC5808] and is
599 subject to the same constraints:
601 o Knowledge of a policy URI MUST be restricted to authorized Rule
602 Makers. Confidentiality is required for its conveyance in the
603 location configuration protocol, and in the requests that are used
604 to inspect, change or delete the policy resource.
606 o The Location Server MUST ensure that the URI cannot be easily
607 predicted. The policy URI MUST NOT be derived solely from
608 information that might be public, including the Target identity or
609 any location URI. The addition of random entropy increases the
610 difficulty of guessing a policy URI.
612 Additional requestor authentication MAY be used for policy resources.
613 For instance, in the particular case where the Device is identified
614 to the Location Server by its IP address, the Location Server could
615 use IP return routability as an additional authentication mechanism.
617 9.3. Location URI Allocation
619 A policy URI enables the authorization by access control lists model
620 [RFC5808] for associated location URIs. Under this model, it might
621 be possible to more widely distribute a location URI, relying on the
622 authorization policy to constrain access to location information.
624 To allow for wider distribution, authorization by access control
625 lists places additional constraints on the construction of location
626 URIs.
628 If multiple Targets share a location URI, an unauthorized location
629 recipient that acquires location URIs for the Targets can determine
630 that the Targets are at the same location by comparing location URIs.
631 With shared policy URIs, Targets are able to see and modify
632 authorization policy for other Targets.
634 To allow for the creation of Target-specific authorization policies
635 that are adequately privacy-protected, every location URI and policy
636 URI that is issued to a different Target MUST be different. That is,
637 no two client can receive the same location URI or policy URI.
639 In some deployments it is not always apparent to a LCP server that
640 two clients are different. In particular, where a middlebox
641 [RFC3234] exists two or more clients might appear as a single client.
642 An example of a deployment scenario of this nature is described in
643 [RFC5687]. An LCP server MUST create a different location URI and
644 policy URI for every request, unless the requests can be reliably
645 identified as being from the same client.
647 Conversely, if a location server chooses to provide the same location
648 URI and policy URI to multiple endpoints, then it MUST use a
649 restricted profile of the above protocol for policy management. (A
650 server might do this to mitigate problems with link-layer
651 confidentiality, e.g., for multiple clients on a shared medium.)
652 Such a server MAY allow GET requests to allow clients to know the
653 default policy, but it MUST NOT allow PUT or DELETE requests to
654 control policy unless it has an out-of-band mechanism to distinguish
655 and separately authorize clients.
657 10. References
659 10.1. Normative References
661 [I-D.ietf-geopriv-dhcp-lbyr-uri-option]
662 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
663 and IPv6 Option for a Location Uniform Resource Identifier
664 (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-09 (work
665 in progress), October 2010.
667 [I-D.ietf-geopriv-http-location-delivery]
668 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
669 "HTTP Enabled Location Delivery (HELD)",
670 draft-ietf-geopriv-http-location-delivery-16 (work in
671 progress), August 2009.
673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
674 Requirement Levels", BCP 14, RFC 2119, March 1997.
676 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
677 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
678 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
680 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
682 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
683 January 2004.
685 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
686 Polk, J., and J. Rosenberg, "Common Policy: A Document
687 Format for Expressing Privacy Preferences", RFC 4745,
688 February 2007.
690 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
691 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
693 10.2. Informative References
695 [I-D.ietf-geopriv-deref-protocol]
696 Winterbottom, J., Tschofenig, H., Schulzrinne, H.,
697 Thomson, M., and M. Dawson, "A Location Dereferencing
698 Protocol Using HELD", draft-ietf-geopriv-deref-protocol-01
699 (work in progress), September 2010.
701 [I-D.ietf-geopriv-held-identity-extensions]
702 Winterbottom, J., Thomson, M., Tschofenig, H., and R.
703 Barnes, "Use of Device Identity in HTTP-Enabled Location
704 Delivery (HELD)",
705 draft-ietf-geopriv-held-identity-extensions-05 (work in
706 progress), October 2010.
708 [I-D.ietf-geopriv-policy]
709 Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
710 and J. Polk, "Geolocation Policy: A Document Format for
711 Expressing Privacy Preferences for Location Information",
712 draft-ietf-geopriv-policy-22 (work in progress),
713 October 2010.
715 [I-D.ietf-geopriv-rfc3825bis]
716 Polk, J., Schnizlein, J., Linsner, M., Thomson, M., and B.
717 Aboba, "Dynamic Host Configuration Protocol Options for
718 Coordinate-based Location Configuration Information",
719 draft-ietf-geopriv-rfc3825bis-13 (work in progress),
720 November 2010.
722 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
723 Issues", RFC 3234, February 2002.
725 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
726 J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
728 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
729 Format", RFC 4119, December 2005.
731 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
732 Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
734 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
735 Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
737 [RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of
738 'retransmission-allowed' for SIP Location Conveyance",
739 RFC 5606, August 2009.
741 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
742 Location Configuration Protocol: Problem Statement and
743 Requirements", RFC 5687, March 2010.
745 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference
746 Mechanism", RFC 5808, May 2010.
748 Authors' Addresses
750 Richard Barnes
751 BBN Technologies
752 9861 Broken Land Parkway
753 Columbia, MD 21046
754 US
756 Phone: +1 410 290 6169
757 Email: rbarnes@bbn.com
759 Martin Thomson
760 Andrew Corporation
761 Andrew Building (39)
762 Wollongong University Campus
763 Northfields Avenue
764 Wollongong, NSW 2522
765 AU
767 Phone: +61 2 4221 2915
768 Email: martin.thomson@andrew.com
770 James Winterbottom
771 Andrew Corporation
772 Andrew Building (39)
773 Wollongong University Campus
774 Northfields Avenue
775 Wollongong, NSW 2522
776 AU
778 Phone: +61 242 212938
779 Email: james.winterbottom@andrew.com
780 Hannes Tschofenig
781 Nokia Siemens Networks
782 Linnoitustie 6
783 Espoo 02600
784 Finland
786 Phone: +358 (50) 4871445
787 Email: Hannes.Tschofenig@gmx.net
788 URI: http://www.tschofenig.priv.at