idnits 2.17.1 draft-ietf-geopriv-policy-uri-04.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 28, 2011) is 4530 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-ietf-geopriv-dhcp-lbyr-uri-option-12 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-07) exists of draft-ietf-geopriv-deref-protocol-04 == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-25 Summary: 3 errors (**), 0 flaws (~~), 4 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: Standards Track M. Thomson 5 Expires: May 31, 2012 J. Winterbottom 6 Andrew Corporation 7 H. Tschofenig 8 Nokia Siemens Networks 9 November 28, 2011 11 Location Configuration Extensions for Policy Management 12 draft-ietf-geopriv-policy-uri-04.txt 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 31, 2012. 41 Copyright Notice 43 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 6 63 4. Location Configuration Extensions . . . . . . . . . . . . . . 7 64 4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.3. Client Processing . . . . . . . . . . . . . . . . . . . . 8 67 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.3. Basic Access Control Policy . . . . . . . . . . . . . . . 10 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 6.1. URN Sub-Namespace Registration for 73 urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 12 74 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12 75 6.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 13 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 7.1. Integrity and Confidentiality for Authorization Policy 78 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 7.2. Access Control for Authorization Policy . . . . . . . . . 14 80 7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 14 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 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 [RFC6225] versus GML in a PIDF-LO [RFC4119]). 115 From a privacy perspective, however, current LCPs are limited in 116 their flexibility, in that they do not provide hosts (the clients in 117 an LCP) with a way to inform the Location Server with policy for how 118 his location information should be handled. This document addresses 119 this gap by defining a simple mechanism for referring to and 120 manipulating policy, and by extending current LCPs to carry policy 121 references. Using the mechanisms defined in this document, an LCP 122 server (acting for the Location Server (LS) or Location Information 123 Server (LIS)) can inform a host as to which policy document controls 124 a given location resource, and the host (in its Rule Maker role) can 125 inspect this document and modify it as necessary. 127 In the following figure, adapted from RFC 5808, this document extends 128 the Location Configuration Protocols (1) and defines a simple 129 protocol for policy exchange (4). 131 +---------+---------+ Location +-----------+ 132 | | | Dereference | Location | 133 | LIS/LS +---------------+ Recipient | 134 | | | Protocol | | 135 +----+----+----+----+ (3) +-----+-----+ 136 | | | 137 | | | 138 Policy| |Location |Location 139 Exchange| |Configuration |Conveyance 140 (4)| |Protocol |Protocol 141 | |(1) |(2) 142 | | | 143 +------+----+----+----+ | 144 | Rule | Target/ | | 145 | Maker | Host +---------------------+ 146 | | | 147 +-----------+---------+ 149 The remainder of this document is structured as follows: After 150 introducing a few relevant terms, we define policy URIs as a channel 151 for referencing, inspecting, and updating policy documents. We then 152 define extensions to the HELD protocol and the DHCP option for 153 location by reference to allow these protocols to carry policy URIs. 154 Examples are given that demonstrate how policy URIs are carried in 155 these protocols and how they can be used by clients. 157 2. Definitions 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119 [RFC2119]. 163 3. Policy URIs 165 A policy URI is an HTTP [RFC2616] or HTTPS [RFC2818]URI that 166 identifies a policy resource that contains the authorization policy 167 for a linked location resource. Access to the location resource is 168 governed by the contents of the authorization policy. 170 A policy URI identifies an HTTP resource that a Rule Maker can use to 171 inspect and install policy documents that tell a Location Server how 172 it should protect the associated location resource. A policy URI 173 always identifies a resource that can be represented as a common- 174 policy document [RFC4745] (possibly including some extensions; e.g., 175 for geolocation policy [I-D.ietf-geopriv-policy]). 177 Note: RFC 3693 [RFC3693] identified the Rule Holder role as the one 178 that stores policy information. In this document, the Location 179 Server is also a Rule Holder. 181 3.1. Policy URI Usage 183 A Location Server that is the authority for policy URIs MUST support 184 GET, PUT, and DELETE requests to these URIs, in order to allow 185 clients to inspect, replace, and delete policy documents. Clients 186 support the three request methods as they desire to perform these 187 operations. 189 Knowledge of the policy URI can be considered adequate evidence of 190 authorization; a policy URI functions as a shared secret between the 191 client and the server (see Section 7). A Location Server SHOULD 192 allow all requests, but it MAY deny certain requests based on local 193 policy. For instance, a Location Server might allow clients to 194 inspect policy (GET), but not to update it (PUT). 196 A GET request to a policy URI is a request for the referenced policy 197 information. If the request is authorized, then the Location Server 198 sends an HTTP 200 response containing the complete policy identified 199 by the URI. 201 A PUT request to a policy URI is a request to replace the current 202 policy. The entity-body of a PUT request includes a complete policy 203 document. When a Location Server receives a PUT request, it MUST 204 validate the policy document included in the body of the request. If 205 the request is valid and authorized, then the Location Server MUST 206 replace the current policy with the policy provided in the request. 208 A DELETE request to a policy URI is a request to delete the 209 referenced policy document. If the request is authorized, then the 210 Location Server MUST delete the policy referenced by the URI and 211 disallow access to the location URIs it governs until a new policy 212 document has been put in place via a PUT request. 214 A policy URI is only valid while the corresponding location URI set 215 is valid. A location server MUST NOT respond to any requests to a 216 policy URIs once the corresponding location URI set has expired. 217 This expiry time is specified by the 'expires' attribute in the HELD 218 locationResponse or the 'Valid-For' LuriType in DHCP. 220 A location URI can thus become invalid in three ways: By the 221 expiration of a validity interval in policy, by the removal of a 222 policy document with a DELETE request, or by the expiry of the 223 LCP-specified validity interval. The former two are temporary, 224 since the policy URI can be used to update the policy. The latter 225 one is permanent, since the expiry causes the policy URI to be 226 invalidated as well. 228 The Location Server MUST support policy documents in the common- 229 policy format [RFC4745], as identified by the MIME media type of 230 "application/auth-policy+xml". The common-policy format MUST be 231 provided as the default format in response to GET requests that do 232 not include specific "Accept" headers, but content negotiation MAY be 233 used to allow for other formats. 235 This usage of HTTP is generally compatible with the use of XCAP 236 [RFC4825] or WebDAV [RFC4918] to manage policy documents, but this 237 document does not define or require the use of these protocols. 239 3.2. Policy URI Allocation 241 A Location Server creates a policy URI for a specific location 242 resource at the time that the location resource is created; that is, 243 a policy URI is created at the same time as the location URI that it 244 controls. The URI of the policy resource MUST be different from the 245 location URI. 247 A policy URI is provided in response to location configuration 248 requests. A policy URI MUST NOT be provided to an entity that is not 249 authorized to view or set policy. This document does not describe 250 how policy might be provided to entities other than for location 251 configuration, for example, in responses to dereferencing requests 252 [I-D.ietf-geopriv-deref-protocol] or requests from third parties 253 [RFC6155]. 255 Each location URI has either one policy URI or no policy URI. The 256 initial policy that is referenced by a policy URI MUST be identical 257 to the policy that would be applied in the absence of a policy URI. 258 A client that does not support policy URIs can continue to use the 259 location URI as they would have if no policy URI were provided. 261 For DHCP and HELD, the client assumes that the default policy 262 grants any requester access to location information, as long as 263 the request possesses the location URI. To ensure that the 264 authorization policy is less permissive, a client updates the 265 policy prior to distributing the location URI. 267 A Location Server chooses whether or not to provide a policy URI 268 based on local policy. A HELD-specific extension also allows a 269 requester to specifically ask for a policy URI. 271 A policy URI is effectively a shared secret between Location Server 272 and its clients. Knowledge of a policy URI is all that is required 273 to perform any operations allowed on the policy. Thus, a policy URI 274 should be constructed so that it is hard to predict and 275 confidentiality-protected when transmitted (see Section 7). To avoid 276 re-using these shared secrets, the Location Server MUST generate a 277 new policy URI whenever it generates a new location URI set. 279 4. Location Configuration Extensions 281 Location configuration protocols can provision hosts with location 282 URIs that refer to the host's location. If the target host is to 283 control policy on these URIs, it needs a way to access the policy 284 that the Location Server uses to guide how it serves location URIs. 285 This section defines extensions to LCPs to carry policy URIs that the 286 target can use to control access to location resources. 288 4.1. HELD 290 The HELD protocol [RFC5985] defines a "locationUriSet" element, which 291 contain a set of one or more location URIs that reference the same 292 resource and share a common access control policy. The schema in 293 Figure 1 defines two extension elements for HELD: an empty 294 "requestPolicyUri" element that is added to a location request to 295 indicate that a Device desires that a policy URI be allocated; and a 296 "policyUri" element that is included in the location response. 298 299 305 306 307 309 311 313 Figure 1 315 The URI carried in a "policyUri" element refers to the common access 316 control policy for location URIs in the location response. The URI 317 MUST be a policy URI as described in Section 3. A policy URI MUST 318 use the "http:" or "https:" scheme, and the Location Server MUST 319 support the specified operations on the URI. 321 A HELD request MAY contain an explicit request for a policy URI. The 322 presence of the "requestPolicyUri" element in a location request 323 indicates that a policy URI is desired. 325 4.2. DHCP 327 The DHCP location by reference option 328 [I-D.ietf-geopriv-dhcp-lbyr-uri-option] provides location URIs in 329 sub-options called LuriElements. This document defines a new 330 LuriElement type for policy URIs. 332 LuriType=TBD Policy-URI - This is a policy URI that refers to the 333 access control policy for the location URIs. 335 [NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned 336 LuriType value and remove this note] 338 A Policy-URI LuriElement uses a UTF-8 character encoding. 340 A Policy-URI LuriElement identifies the policy resource for all 341 location URIs included in the location URI option. The URI MUST be a 342 policy URI as described in Section 3: It MUST use either the "http:" 343 or "https:" scheme, and the Location Server MUST support the 344 specified operations on the URI. 346 4.3. Client Processing 348 It is possible that this document will be updated to allow the use of 349 policy URIs that use protocols other than the HTTP-based protocol 350 described above. To ensure that they fail safely when presented with 351 such a URI, clients implementing this specification MUST verify that 352 a policy URI received from either HELD or DHCP uses either the 353 "http:" or "https:" scheme. If the URI does not match those schemes, 354 then the client MUST discard the URI and behave as if no policy URI 355 was provided. 357 5. Examples 359 In this section, we provide some brief illustrations of how policy 360 URIs are delivered to target hosts and used by those hosts to manage 361 policy. 363 5.1. HELD 365 A HELD request that explicitly requests the creation of a policy URI 366 has the following form: 368 369 locationURI 370 372 374 A HELD response providing a single "locationUriSet", containing two 375 URIs under a common policy, would have the following form: 377 378 379 380 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 381 382 383 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 384 385 386 387 https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b 388 389 391 5.2. DHCP 393 A DHCP option providing one of the location URIs and the 394 corresponding policy URI from the previous example would have the 395 following form: 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | option-code | 110 | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | 1 | 0 | 1 | 49 | 'h' | 403 +---------------+---------------+---------------+---------------| 404 | 't' | 't' | 'p' | 's' | 405 +---------------+---------------+---------------+---------------| 406 | ':' | '/' | '/' | 'l' | 407 +---------------+---------------+---------------+---------------| 408 | 's' | '.' | ... | 409 +---------------+---------------+---------------+---------------| 410 | TBD | 56 | 'h' 't' | 411 +---------------+---------------+---------------+---------------| 412 | 't' | 'p' | 's' | ':' | 413 +---------------+---------------+---------------+---------------| 414 | '/' | '/' | ... | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 [NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned 418 LuriType value and remove this note] 420 5.3. Basic Access Control Policy 422 Consider a client that gets the policy URI 423 , as in the 424 above LCP example. The first thing this allows the client to do is 425 inspect the default policy that the LS has assigned to this URI: 427 GET /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 428 Host: ls.example.com:9768 430 HTTP/1.1 200 OK 431 Content-type: application/auth-policy+xml 432 Content-length: 388 434 435 437 438 439 440 2011-01-01T13:00:00.0Z 441 442 443 444 445 446 447 false 448 449 0 450 451 452 454 This policy allows any requester to obtain location information, as 455 long as they know the location URI. If the user disagrees with this 456 policy, and prefers for example, to only provide location to one 457 friend, at a city level of granularity, then the client can install 458 this policy on the Location Server: 460 PUT /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 461 Host: ls.example.com:9768 462 Content-type: application/auth-policy+xml 463 Content-length: 462 465 466 467 468 469 470 471 472 473 2011-01-01T13:00:00.0Z 474 475 476 477 478 480 city 481 482 483 484 486 HTTP/1.1 200 OK 488 Finally, after using the URI for a period, the user wishes to 489 permanently invalidate the URI. 491 DELETE /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 492 Host: ls.example.com:9768 494 HTTP/1.1 200 OK 496 6. IANA Considerations 498 This document requires several IANA registrations, detailed below. 500 6.1. URN Sub-Namespace Registration for 501 urn:ietf:params:xml:ns:geopriv:held:policy 503 This section registers a new XML namespace, 504 "urn:ietf:params:xml:ns:geopriv:held:policy", per the guidelines in 505 [RFC3688]. 507 URI: urn:ietf:params:xml:ns:geopriv:held:policy 509 Registrant Contact: IETF, GEOPRIV working group, 510 (geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com). 512 XML: 514 BEGIN 515 516 518 519 520 HELD Policy URI Extension 521 522 523

Namespace for HELD Policy URI Extension

524

urn:ietf:params:xml:ns:geopriv:held:policy

525 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 526 with the RFC number for this specification.] 527

See RFCXXXX

528 529 530 END 532 6.2. XML Schema Registration 534 This section registers an XML schema as per the guidelines in 535 [RFC3688]. 537 URI: urn:ietf:params:xml:schema:geopriv:held:policy 539 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 540 Richard Barnes (rbarnes@bbn.com) 542 Schema: The XML for this schema can be found in Section Section 4.1. 544 6.3. DHCP LuriType Registration 546 IANA is requested to add a value to the LuriTypes registry, as 547 follows: 549 +------------+----------------------------------------+-----------+ 550 | LuriType | Name | Reference | 551 +------------+----------------------------------------+-----------+ 552 | TBD* | Policy-URI | RFC XXXX**| 553 +------------+----------------------------------------+-----------+ 555 * TBD is to be replaced with the assigned value 556 ** RFC XXXX is to be replaced with this document's RFC number. 558 7. Security Considerations 560 There are two main classes of risks associated with access control 561 policy management: The risk of unauthorized grants or denial of 562 access to the protected resource via manipulation of the policy 563 management process, and the risk of disclosure of policy information 564 itself. 566 Protecting the policy management process from manipulation entails 567 two primary requirements: First, the policy URI has to be faithfully 568 and confidentially transmitted to the client, and second, the policy 569 document has to be faithfully and confidentially transmitted to the 570 Location Server. The mechanism also needs to ensure that only 571 authorized entities are able to acquire or alter policy. 573 7.1. Integrity and Confidentiality for Authorization Policy Data 575 Each LCP ensures integrity and confidentiality through different 576 means (see [RFC5985] and [I-D.ietf-geopriv-dhcp-lbyr-uri-option]). 577 These measures ensure that a policy URI is conveyed to the client 578 without modification or interception. 580 To protect the integrity and confidentiality of policy data during 581 management, the Location Server SHOULD provide policy URIs with the 582 "https:" scheme and require the use of HTTP over TLS [RFC2818]. The 583 cipher suites required by TLS [RFC5246] provide both integrity 584 protection and confidentiality. If other means of protection are 585 available, an "http:" URI MAY be used, but location servers SHOULD 586 reject PUT and DELETE requests for policy URIs that use the "http:" 587 URI scheme. 589 7.2. Access Control for Authorization Policy 591 Access control for the policy resource is based on knowledge of its 592 URI. The URI of a policy resource operates under the same 593 constraints as a possession model location URI [RFC5808] and is 594 subject to the same constraints: 596 o Knowledge of a policy URI MUST be restricted to authorized Rule 597 Makers. ConfideConfidentiality and integrity protections SHOULD 598 be used when policy URIs are conveyed in a location configuration 599 protocol, and in the requests that are used to inspect, change or 600 delete the policy resource. Note that in some protocols (such as 601 DHCP), these protections may arise from limiting the use of the 602 protocol to the local network, thus relying on lower-layer 603 security mechanisms. When neither application-layer or network- 604 layer security is provided, location servers MUST reject requests 605 using the PUT and DELETE methods. 607 o The Location Server MUST ensure that the URI cannot be easily 608 predicted. The policy URI MUST NOT be derived solely from 609 information that might be public, including the Target identity or 610 any location URI. The addition of 32 bits or more of random 611 entropy is RECOMMENDED to make it infeasible for a third party to 612 guess a policy URI. 614 o Servers SHOULD apply rate limits in order to make brute-force 615 guessing infeasible. If a server allocates policy URIs that 616 include N bits of entropy with a default lifetime of T seconds, 617 then the server should limit clients to 2^(N/2)/T queries per 618 second. 620 7.3. Location URI Allocation 622 A policy URI enables the authorization by access control lists model 623 [RFC5808] for associated location URIs. Under this model, it might 624 be possible to more widely distribute a location URI, relying on the 625 authorization policy to constrain access to location information. 627 To allow for wider distribution, authorization by access control 628 lists places additional constraints on the construction of location 629 URIs. 631 If multiple Targets share a location URI, an unauthorized location 632 recipient that acquires location URIs for the Targets can determine 633 that the Targets are at the same location by comparing location URIs. 634 With shared policy URIs, Targets are able to see and modify 635 authorization policy for other Targets. 637 To allow for the creation of Target-specific authorization policies 638 that are adequately privacy-protected, each location URI and policy 639 URI that is issued to a different Target MUST be different from other 640 location URIs and policy URIs. That is, two clients MUST NOT receive 641 the same location URI or the same policy URI. 643 In some deployments, it is not always apparent to a LCP server that 644 two clients are different. In particular, where a middlebox 645 [RFC3234] exists two or more clients might appear as a single client. 646 An example of a deployment scenario of this nature is described in 647 [RFC5687]. An LCP server MUST create a different location URI and 648 policy URI for every request, unless the requests can be reliably 649 identified as being from the same client. 651 8. Acknowledgements 653 Thanks to Mary Barnes and Alissa Cooper for providing critical 654 commentary and input on the ideas described in this document, and to 655 Ted Hardie and Adam Roach for helping clarify the relationships 656 between policy URIs, policy documents, and location resources. 658 9. References 660 9.1. Normative References 662 [I-D.ietf-geopriv-dhcp-lbyr-uri-option] 663 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 664 and IPv6 Option for a Location Uniform Resource Identifier 665 (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-12 (work 666 in progress), October 2011. 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", BCP 14, RFC 2119, March 1997. 671 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 672 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 673 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 675 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 677 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 678 January 2004. 680 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 681 Polk, J., and J. Rosenberg, "Common Policy: A Document 682 Format for Expressing Privacy Preferences", RFC 4745, 683 February 2007. 685 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 686 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 688 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 689 RFC 5985, September 2010. 691 9.2. Informative References 693 [I-D.ietf-geopriv-deref-protocol] 694 Winterbottom, J., Tschofenig, H., Schulzrinne, H., 695 Thomson, M., and M. Dawson, "A Location Dereferencing 696 Protocol Using HELD", draft-ietf-geopriv-deref-protocol-04 697 (work in progress), October 2011. 699 [I-D.ietf-geopriv-policy] 700 Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., 701 Morris, J., and M. Thomson, "Geolocation Policy: A 702 Document Format for Expressing Privacy Preferences for 703 Location Information", draft-ietf-geopriv-policy-25 (work 704 in progress), October 2011. 706 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 707 Issues", RFC 3234, February 2002. 709 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 710 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 712 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 713 Format", RFC 4119, December 2005. 715 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 716 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 718 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 719 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 721 [RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of 722 'retransmission-allowed' for SIP Location Conveyance", 723 RFC 5606, August 2009. 725 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 726 Location Configuration Protocol: Problem Statement and 727 Requirements", RFC 5687, March 2010. 729 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference 730 Mechanism", RFC 5808, May 2010. 732 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 733 Barnes, "Use of Device Identity in HTTP-Enabled Location 734 Delivery (HELD)", RFC 6155, March 2011. 736 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic 737 Host Configuration Protocol Options for Coordinate-Based 738 Location Configuration Information", RFC 6225, July 2011. 740 Authors' Addresses 742 Richard Barnes 743 BBN Technologies 744 9861 Broken Land Parkway 745 Columbia, MD 21046 746 US 748 Phone: +1 410 290 6169 749 Email: rbarnes@bbn.com 751 Martin Thomson 752 Andrew Corporation 753 Andrew Building (39) 754 Wollongong University Campus 755 Northfields Avenue 756 Wollongong, NSW 2522 757 AU 759 Phone: +61 2 4221 2915 760 Email: martin.thomson@andrew.com 762 James Winterbottom 763 Andrew Corporation 764 Andrew Building (39) 765 Wollongong University Campus 766 Northfields Avenue 767 Wollongong, NSW 2522 768 AU 770 Phone: +61 242 212938 771 Email: james.winterbottom@andrew.com 772 Hannes Tschofenig 773 Nokia Siemens Networks 774 Linnoitustie 6 775 Espoo 02600 776 Finland 778 Phone: +358 (50) 4871445 779 Email: Hannes.Tschofenig@gmx.net 780 URI: http://www.tschofenig.priv.at