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