idnits 2.17.00 (12 Aug 2021) /tmp/idnits46452/draft-ietf-geopriv-policy-uri-05.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 (September 20, 2012) is 3529 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) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Downref: Normative reference to an Informational RFC: RFC 2818 ** 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-policy has been published as RFC 6772 Summary: 4 errors (**), 0 flaws (~~), 3 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: March 24, 2013 Microsoft 6 J. Winterbottom 7 Andrew Corporation 8 H. Tschofenig 9 Nokia Siemens Networks 10 September 20, 2012 12 Location Configuration Extensions for Policy Management 13 draft-ietf-geopriv-policy-uri-05.txt 15 Abstract 17 Current location configuration protocols are capable of provisioning 18 an Internet host with a location URI that refers to the host's 19 location. These protocols lack a mechanism for the target host to 20 inspect or set the privacy rules that are applied to the URIs they 21 distribute. This document extends the current location configuration 22 protocols to provide hosts with a reference to the rules that are 23 applied to a URI, so that the host can view or set these rules. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 24, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Policy URIs . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Policy URI Usage . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 6 64 3.3. Policy Defaults . . . . . . . . . . . . . . . . . . . . . 7 65 4. Location Configuration Extensions . . . . . . . . . . . . . . 8 66 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5.2. Basic Access Control Policy . . . . . . . . . . . . . . . 9 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 6.1. URN Sub-Namespace Registration for 71 urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 12 72 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 7.1. Integrity and Confidentiality for Authorization Policy 75 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 7.2. Access Control for Authorization Policy . . . . . . . . . 13 77 7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 15 78 7.4. Policy URI Handling . . . . . . . . . . . . . . . . . . . 15 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 83 Appendix A. Example Policy URI Generation Algorithm . . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 A critical step in enabling Internet hosts to access location-based 89 services is to provision those hosts with information about their own 90 location. This is accomplished via a Location Configuration Protocol 91 (LCP) [RFC5687], which allows a location provider (e.g., a local 92 access network) to inform a host about its location. 94 There are two basic patterns for location configuration, namely 95 configuration "by value" and "by reference" [RFC5808]. Configuration 96 by value provisions a host directly with its location, by providing 97 it location information that is directly usable (e.g., coordinates or 98 a civic address). Configuration by reference provides a host with a 99 URI that references the host's location, i.e., one that can be 100 dereferenced to obtain the location (by value) of the host. 102 In some cases, location by reference offers a few benefits over 103 location by value. From a privacy perspective, the required 104 dereference transaction provides a policy enforcement point, so that 105 if suitable privacy policies have been provisioned, the opaque 106 location URI can be safely conveyed over untrusted media. (If the 107 location URI is not subject to privacy rules, then conveying the 108 location URI may pose even greater risk than sending location by 109 value [RFC5606]) If the target host is mobile, an application 110 provider can use a single reference to obtain the location of the 111 host multiple times, saving bandwidth to the host. For some 112 configuration protocols, the location object referenced by a location 113 URI provides a much more expressive syntax for location values than 114 the configuration protocol itself (e.g., DHCP geodetic location 115 [RFC6225] versus GML in a PIDF-LO [RFC4119]). 117 From a privacy perspective, however, current LCPs are limited in 118 their flexibility, in that they do not provide hosts (the clients in 119 an LCP) with a way to inform the Location Server with policy for how 120 his location information should be handled. This document addresses 121 this gap by defining a simple mechanism for referring to and 122 manipulating policy, and by extending current LCPs to carry policy 123 references. Using the mechanisms defined in this document, an LCP 124 server (acting for the Location Server (LS) or Location Information 125 Server (LIS)) can inform a host as to which policy document controls 126 a given location resource, and the host (in its Rule Maker role) can 127 inspect this document and modify it as necessary. 129 In the following figure, adapted from RFC 5808, this document extends 130 the Location Configuration Protocols (1) and defines a simple 131 protocol for policy exchange (4). 133 +---------+---------+ Location +-----------+ 134 | | | Dereference | Location | 135 | LIS/LS +---------------+ Recipient | 136 | | | Protocol | | 137 +----+----+----+----+ (3) +-----+-----+ 138 | | | 139 | | | 140 Policy| |Location |Location 141 Exchange| |Configuration |Conveyance 142 (4)| |Protocol |Protocol 143 | |(1) |(2) 144 | | | 145 +------+----+----+----+ | 146 | Rule | Target/ | | 147 | Maker | Host +---------------------+ 148 | | | 149 +-----------+---------+ 151 The remainder of this document is structured as follows: After 152 introducing a few relevant terms, we define policy URIs as a channel 153 for referencing, inspecting, and updating policy documents. We then 154 define an extension to the HELD protocol to carry policy URIs. 155 Examples are given that demonstrate how policy URIs are carried in 156 these protocols and how they can be used by clients. 158 2. Definitions 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [RFC2119]. 164 3. Policy URIs 166 A policy URI is an HTTP [RFC2616] or HTTPS [RFC2818]URI that 167 identifies a policy resource that contains the authorization policy 168 for a linked location resource. Access to the location resource is 169 governed by the contents of the authorization policy. 171 A policy URI identifies an HTTP resource that a Rule Maker can use to 172 inspect and install policy documents that tell a Location Server how 173 it should protect the associated location resource. A policy URI 174 always identifies a resource that can be represented as a common- 175 policy document [RFC4745] (possibly including some extensions; e.g., 176 for geolocation policy [I-D.ietf-geopriv-policy]). 178 Note: RFC 3693 [RFC3693] identified the Rule Holder role as the one 179 that stores policy information. In this document, the Location 180 Server is also a Rule Holder. 182 3.1. Policy URI Usage 184 A Location Server that is the authority for policy URIs MUST support 185 GET, PUT, and DELETE requests to these URIs, in order to allow 186 clients to inspect, replace, and delete policy documents. Clients 187 support the three request methods as they desire to perform these 188 operations. 190 Knowledge of the policy URI can be considered adequate evidence of 191 authorization; a policy URI functions as a shared secret between the 192 client and the server (see Section 7). A Location Server SHOULD 193 allow all requests, but it MAY deny certain requests based on local 194 policy. For instance, a Location Server might allow clients to 195 inspect policy (GET), but not to update it (PUT). Or a Location 196 Server might require clients to authenticate using HTTP or TLS client 197 authentication. Clients implementing this specification SHOULD 198 support HTTP client authentication [RFC2617] and MAY support TLS 199 client certificates. 201 A GET request to a policy URI is a request for the referenced policy 202 information. If the request is authorized, then the Location Server 203 sends an HTTP 200 response containing the complete policy identified 204 by the URI. 206 A PUT request to a policy URI is a request to replace the current 207 policy. The entity-body of a PUT request includes a complete policy 208 document. When a Location Server receives a PUT request, it MUST 209 validate the policy document included in the body of the request. If 210 the request is valid and authorized, then the Location Server MUST 211 replace the current policy with the policy provided in the request. 213 A DELETE request to a policy URI is a request to delete the 214 referenced policy document. If the request is authorized, then the 215 Location Server MUST delete the policy referenced by the URI and 216 disallow access to the location URIs it governs until a new policy 217 document has been put in place via a PUT request. 219 A policy URI is only valid while the corresponding location URI set 220 is valid. A location server MUST NOT respond to any requests to a 221 policy URIs once the corresponding location URI set has expired. 222 This expiry time is specified by the 'expires' attribute in the HELD 223 locationResponse. 225 A location URI can thus become invalid in three ways: By the 226 expiration of a validity interval in policy, by the removal of a 227 policy document with a DELETE request, or by the expiry of the 228 LCP-specified validity interval. The former two are temporary, 229 since the policy URI can be used to update the policy. The latter 230 one is permanent, since the expiry causes the policy URI to be 231 invalidated as well. 233 The Location Server MUST support policy documents in the common- 234 policy format [RFC4745], as identified by the MIME media type of 235 "application/auth-policy+xml". The common-policy format MUST be 236 provided as the default format in response to GET requests that do 237 not include specific "Accept" headers, but content negotiation MAY be 238 used to allow for other formats. 240 This usage of HTTP is generally compatible with the use of XCAP 241 [RFC4825] or WebDAV [RFC4918] to manage policy documents, but this 242 document does not define or require the use of these protocols. 244 3.2. Policy URI Allocation 246 A Location Server creates a policy URI for a specific location 247 resource at the time that the location resource is created; that is, 248 a policy URI is created at the same time as the location URI that it 249 controls. The URI of the policy resource MUST be different from the 250 location URI. 252 A policy URI is provided in response to location configuration 253 requests. A policy URI MUST NOT be provided to an entity that is not 254 authorized to view or set policy. This document does not describe 255 how policy might be provided to entities other than for location 256 configuration, for example, in responses to dereferencing requests 257 [I-D.ietf-geopriv-deref-protocol] or requests from third parties 258 [RFC6155]. 260 Each location URI has either one policy URI or no policy URI. The 261 initial policy that is referenced by a policy URI MUST be identical 262 to the policy that would be applied in the absence of a policy URI. 263 A client that does not support policy URIs can continue to use the 264 location URI as they would have if no policy URI were provided. 266 For HELD, the client assumes that the default policy grants any 267 requester access to location information, as long as the requestor 268 possesses the location URI. To ensure that the authorization 269 policy is less permissive, a client updates the policy prior to 270 distributing the location URI. 272 A Location Server chooses whether or not to provide a policy URI 273 based on local policy. A HELD-specific extension also allows a 274 requester to specifically ask for a policy URI. 276 A policy URI is effectively a shared secret between Location Server 277 and its clients. Knowledge of a policy URI is all that is required 278 to perform any operations allowed on the policy. Thus, a policy URI 279 should be constructed so that it is hard to predict and 280 confidentiality-protected when transmitted (see Section 7). To avoid 281 re-using these shared secrets, the Location Server MUST generate a 282 new policy URI whenever it generates a new location URI set. 284 3.3. Policy Defaults 286 Client implementors should keep in mind that setting no policy (never 287 performing an HTTP request to a policy URI) is very different from 288 setting an empty policy (performing a PUT with the empty policy). By 289 "the empty policy", we mean a policy containing no rules, which would 290 be represented by the following policy document: 292 293 294 296 Figure 1: The empty policy 298 If no policy is set, then the client tacitly accepts whatever policy 299 the server applies to location URIs, including a policy that provides 300 location to anyone that makes a dereference request. If the empty 301 policy is set, then the opposite is true; the client directs the 302 server to never provide access to location. (Since there are no 303 rules to allow access, and the policy language is default-deny.) 305 Implementors should thus consider carefully how to handle the case 306 where the user provides no privacy policy input. On the one hand, an 307 implementation might treat this case as if the user had no privacy 308 preferences, and thus set no policy. On the other hand, another 309 implementation might decide that if a user provides no positive 310 authorization, then the empty policy should be installed. 312 The same reasoning could also be applied to servers, with the caveat 313 that servers do not know whether a given HELD client supports the use 314 of policy URIs. A client that does not understand policy URIs will 315 not be able to set its own policy, and so the server must choose a 316 default that is open enough that clients will find it useful. On the 317 other hand, once a client indicates that it understands policy URIs 318 (e.g., by sending an HTTP request to a policy URI), the server may 319 change its default policy to something more restrictive -- even the 320 empty, default-deny policy -- since the client can specify something 321 more permissive if desired. 323 4. Location Configuration Extensions 325 Location configuration protocols can provision hosts with location 326 URIs that refer to the host's location. If the target host is to 327 control policy on these URIs, it needs a way to access the policy 328 that the Location Server uses to guide how it serves location URIs. 329 This section defines extensions to the HELD LCP to carry policy URIs 330 that the target can use to control access to location resources. 332 The HELD protocol [RFC5985] defines a "locationUriSet" element, which 333 contain a set of one or more location URIs that reference the same 334 resource and share a common access control policy. The schema in 335 Figure 2 defines two extension elements for HELD: an empty 336 "requestPolicyUri" element that is added to a location request to 337 indicate that a Device desires that a policy URI be allocated; and a 338 "policyUri" element that is included in the location response. 340 341 347 348 349 351 353 355 Figure 2: XML Schema for the policy URI extension 357 The URI carried in a "policyUri" element refers to the common access 358 control policy for location URIs in the location response. The URI 359 MUST be a policy URI as described in Section 3. A policy URI MUST 360 use the "http:" or "https:" scheme, and the Location Server MUST 361 support the specified operations on the URI. 363 A HELD request MAY contain an explicit request for a policy URI. The 364 presence of the "requestPolicyUri" element in a location request 365 indicates that a policy URI is desired. 367 It is possible that this document will be updated to allow the use of 368 policy URIs that use policy-management protocols other than the HTTP- 369 based protocol described above. To ensure that they fail safely when 370 presented with such a URI, clients implementing this specification 371 MUST verify that a policy URI received from an LCP uses either the 372 "http:" or "https:" scheme. If the URI does not match those schemes, 373 then the client MUST discard the URI and behave as if no policy URI 374 was provided. 376 5. Examples 378 In this section, we provide some brief illustrations of how policy 379 URIs are delivered to target hosts and used by those hosts to manage 380 policy. 382 5.1. HELD 384 A HELD request that explicitly requests the creation of a policy URI 385 has the following form: 387 388 locationURI 389 391 393 A HELD response providing a single "locationUriSet", containing two 394 URIs under a common policy, would have the following form: 396 397 398 399 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 400 401 402 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 403 404 405 406 https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b 407 408 410 5.2. Basic Access Control Policy 412 Consider a client that gets the policy URI 413 , as in the 414 above LCP example. The first thing this allows the client to do is 415 inspect the default policy that the LS has assigned to this URI: 417 GET /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 418 Host: ls.example.com:9768 420 HTTP/1.1 200 OK 421 Content-type: application/auth-policy+xml 422 Content-length: 388 424 425 427 428 429 430 2011-01-01T13:00:00.0Z 431 432 433 434 435 436 437 false 438 439 0 440 441 442 444 This policy allows any requester to obtain location information, as 445 long as they know the location URI. If the user disagrees with this 446 policy, and prefers for example, to only provide location to one 447 friend, at a city level of granularity, then the client can install 448 this policy on the Location Server: 450 PUT /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 451 Host: ls.example.com:9768 452 Content-type: application/auth-policy+xml 453 Content-length: 462 455 456 457 458 459 460 461 462 463 2011-01-01T13:00:00.0Z 464 465 466 467 468 470 city 471 472 473 474 476 HTTP/1.1 200 OK 478 Finally, after using the URI for a period, the user wishes to 479 permanently invalidate the URI. 481 DELETE /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 482 Host: ls.example.com:9768 484 HTTP/1.1 200 OK 486 6. IANA Considerations 488 This document requires several IANA registrations, detailed below. 490 6.1. URN Sub-Namespace Registration for 491 urn:ietf:params:xml:ns:geopriv:held:policy 493 This section registers a new XML namespace, 494 "urn:ietf:params:xml:ns:geopriv:held:policy", per the guidelines in 495 [RFC3688]. 497 URI: urn:ietf:params:xml:ns:geopriv:held:policy 499 Registrant Contact: IETF, GEOPRIV working group, 500 (geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com). 502 XML: 504 BEGIN 505 506 508 509 510 HELD Policy URI Extension 511 512 513

Namespace for HELD Policy URI Extension

514

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

515 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 516 with the RFC number for this specification.] 517

See RFCXXXX

518 519 520 END 522 6.2. XML Schema Registration 524 This section registers an XML schema as per the guidelines in 525 [RFC3688]. 527 URI: urn:ietf:params:xml:schema:geopriv:held:policy 529 Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 530 Richard Barnes (rbarnes@bbn.com) 532 Schema: The XML for this schema can be found in Section Section 4. 534 7. Security Considerations 536 There are two main classes of risks associated with access control 537 policy management: The risk of unauthorized grants or denial of 538 access to the protected resource via manipulation of the policy 539 management process, and the risk of disclosure of policy information 540 itself. 542 Protecting the policy management process from manipulation entails 543 two primary requirements: First, the policy URI has to be faithfully 544 and confidentially transmitted to the client, and second, the policy 545 document has to be faithfully and confidentially transmitted to the 546 Location Server. The mechanism also needs to ensure that only 547 authorized entities are able to acquire or alter policy. 549 7.1. Integrity and Confidentiality for Authorization Policy Data 551 Each LCP ensures integrity and confidentiality through different 552 means (see, for example, [RFC5985]). These measures ensure that a 553 policy URI is conveyed to the client without modification or 554 interception. 556 In general, the requirements for transport-layer security on policy 557 transactions are the same as for the dereference transactions they 558 set policy for [I-D.ietf-geopriv-deref-protocol]. To protect the 559 integrity and confidentiality of policy data during management, the 560 Location Server SHOULD provide policy URIs with the "https:" scheme 561 and require the use of HTTP over TLS [RFC2818]. The cipher suites 562 required by TLS [RFC5246] provide both integrity protection and 563 confidentiality. If other means of protection are available, an 564 "http:" URI MAY be used, but location servers SHOULD reject PUT and 565 DELETE requests for policy URIs that use the "http:" URI scheme. 567 7.2. Access Control for Authorization Policy 569 Access control for the policy resource is based on knowledge of its 570 URI. The URI of a policy resource operates under the same 571 constraints as a possession model location URI [RFC5808] and is 572 subject to the same constraints: 574 o Knowledge of a policy URI MUST be restricted to authorized Rule 575 Makers. Confidentiality and integrity protections SHOULD be used 576 when policy URIs are conveyed in a location configuration 577 protocol, and in the requests that are used to inspect, change or 578 delete the policy resource. Note that in some protocols (such as 579 DHCP), these protections may arise from limiting the use of the 580 protocol to the local network, thus relying on lower-layer 581 security mechanisms. When neither application-layer or network- 582 layer security is provided, location servers MUST reject requests 583 using the PUT and DELETE methods. 585 o The Location Server MUST ensure that it is not practical for an 586 attacker to guess a policy URI value, even if the attacker has 587 requested many policy URIs from the Location Server over time. 588 The policy URI MUST NOT be derived solely from information that 589 might be public, including the Target identity or any location 590 URI. The addition of 128 bits or more of random entropy is 591 RECOMMENDED to make it infeasible for a third party to guess a 592 policy URI. 594 o Servers SHOULD apply rate limits in order to make brute-force 595 guessing infeasible. If a server allocates location URIs that 596 include N bits of entropy with a lifetime of T seconds, then the 597 server should limit clients to (2^(N/2))/T queries per second. 598 (The lifetime T of a location URI set is specified by the 599 "expires" attribute in HELD.) 601 One possible algorithm for generating appropriately unpredictable 602 policy URIs for a location URI set is described in Appendix A. 604 The goal of the above recommendation on rate limiting is to bound the 605 probability that an attacker can guess a policy URI during its 606 lifetime. If an attacker is limited to (2^(N/2))/T queries per 607 second, then he will be able to make at most 2^(N/2) guesses over the 608 lifetime of the URI. Assuming these guesses are distinct, the 609 probability of the attacker guessing any given URI is 610 (2^(N/2))/(2^N), so the probability of compromise over the T-second 611 lifetime of the URI is at most 2^(-N/2). (Of course, if the attacker 612 guesses the URI after the policy URI has expired, then there is no 613 risk.) With N=128, the probability of compromise is 5.4e-20 under 614 this rate-limiting scheme. Operators should choose values for N so 615 that the corresponding risk of compromise presents an acceptable 616 level of risk. 618 If M distinct URIs are issued within the same namespace, then the 619 probability of any of the M URIs being compromised is M*2^(N/2). The 620 example algorithm for generating policy URIs (see Appendix A) places 621 them in independent namespaces (i.e., below the corresponding 622 location URIs), so this compounding does not occur. 624 Note that the chosen entropy level will also affect how quickly 625 legitimate clients can query a given URI, especially for very long- 626 lived URIs. If the default lifetime T is greater than 2^(N/2), then 627 clients will have to wait multiple seconds between queries. 628 Operators should choose entropy and lifetime values that result in 629 acceptable high maximum query rates and acceptably low probability of 630 compromise. For example, with 32 bits of entropy (much less than 631 recommended above), the one-query-per-second policy URI lifetime is 632 around 18 hours. 634 7.3. Location URI Allocation 636 A policy URI enables the authorization by access control lists model 637 [RFC5808] for associated location URIs. Under this model, it might 638 be possible to more widely distribute a location URI, relying on the 639 authorization policy to constrain access to location information. 641 To allow for wider distribution, authorization by access control 642 lists places additional constraints on the construction of location 643 URIs. 645 If multiple Targets share a location URI, an unauthorized location 646 recipient that acquires location URIs for the Targets can determine 647 that the Targets are at the same location by comparing location URIs. 648 With shared policy URIs, Targets are able to see and modify 649 authorization policy for other Targets. 651 To allow for the creation of Target-specific authorization policies 652 that are adequately privacy-protected, each location URI and policy 653 URI that is issued to a different Target MUST be different from other 654 location URIs and policy URIs. That is, two clients MUST NOT receive 655 the same location URI or the same policy URI. 657 In some deployments, it is not always apparent to a LCP server that 658 two clients are different. In particular, where a middlebox 659 [RFC3234] exists two or more clients might appear as a single client. 660 An example of a deployment scenario of this nature is described in 661 [RFC5687]. An LCP server MUST create a different location URI and 662 policy URI for every request, unless the requests can be reliably 663 identified as being from the same client. 665 7.4. Policy URI Handling 667 Although servers may choose to implement access controls on policy 668 URIs, by default, any holder of a policy URI is authorized to access 669 and modify the referenced policy document, and thus, to control 670 access to the associated location resources. Because policy URIs 671 function as shared secrets, clients SHOULD protect them as they would 672 passwords. For example, policy URIs SHOULD NOT be transmitted to 673 other hosts or stored in plaintext. 675 It should be noted that one of the benefits of the policy URI 676 construct is that in most cases, there is not a policy URI to leave 677 the client device to which it is provided. Without policy URIs, 678 location URIs are subject to the "authorization by possession model", 679 and location URIs must be conveyed to another entity in order to be 680 useful. With policy URIs, location URIs can have more nuanced access 681 controls, and the shared secret used to authenticate the client 682 (i.e., the policy URI) can simply be stored on the client and used to 683 set the access control policy on the location URI. So while policy 684 URIs do use a default model of authorization by possession, they 685 reduce the overall risk to location privacy posed by leakage of 686 shared secret URIs. 688 8. Acknowledgements 690 Thanks to Mary Barnes and Alissa Cooper for providing critical 691 commentary and input on the ideas described in this document, and to 692 Ted Hardie and Adam Roach for helping clarify the relationships 693 between policy URIs, policy documents, and location resources. 694 Thanks to Stephen Farrell for a helpful discussion on security and 695 privacy challenges. 697 9. References 699 9.1. Normative References 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", BCP 14, RFC 2119, March 1997. 704 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 705 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 706 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 708 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 709 Leach, P., Luotonen, A., and L. Stewart, "HTTP 710 Authentication: Basic and Digest Access Authentication", 711 RFC 2617, June 1999. 713 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 715 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 716 January 2004. 718 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 719 Polk, J., and J. Rosenberg, "Common Policy: A Document 720 Format for Expressing Privacy Preferences", RFC 4745, 721 February 2007. 723 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 724 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 726 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 727 RFC 5985, September 2010. 729 9.2. Informative References 731 [I-D.ietf-geopriv-deref-protocol] 732 Winterbottom, J., Tschofenig, H., Schulzrinne, H., and M. 733 Thomson, "A Location Dereferencing Protocol Using HELD", 734 draft-ietf-geopriv-deref-protocol-07 (work in progress), 735 July 2012. 737 [I-D.ietf-geopriv-policy] 738 Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., 739 Morris, J., and M. Thomson, "Geolocation Policy: A 740 Document Format for Expressing Privacy Preferences for 741 Location Information", draft-ietf-geopriv-policy-27 (work 742 in progress), August 2012. 744 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 745 Issues", RFC 3234, February 2002. 747 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 748 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 750 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 751 Format", RFC 4119, December 2005. 753 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 754 Encodings", RFC 4648, October 2006. 756 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 757 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 759 [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed 760 Authoring and Versioning (WebDAV)", RFC 4918, June 2007. 762 [RFC5606] Peterson, J., Hardie, T., and J. Morris, "Implications of 763 'retransmission-allowed' for SIP Location Conveyance", 764 RFC 5606, August 2009. 766 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 767 Location Configuration Protocol: Problem Statement and 768 Requirements", RFC 5687, March 2010. 770 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference 771 Mechanism", RFC 5808, May 2010. 773 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 774 Barnes, "Use of Device Identity in HTTP-Enabled Location 775 Delivery (HELD)", RFC 6155, March 2011. 777 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic 778 Host Configuration Protocol Options for Coordinate-Based 779 Location Configuration Information", RFC 6225, July 2011. 781 Appendix A. Example Policy URI Generation Algorithm 783 One possible algorithm for generating appropriately unpredictable 784 policy URIs for a location URI set is as follows: 786 1. Choose parameters: 788 * A cryptographic hash function H, e.g., SHA256 790 * A number N of bits of entropy to add, such that N is no more 791 than the length of the output of the hash function 793 2. On allocation of a location URI, generate a policy URI in the 794 following way: 796 1. Generate a random value NONCE at least N/8 bytes long 798 2. Compute hash = H( Location-URI-Set || NONCE ) using some 799 cryptographic hash function H and some serialization of the 800 location URI set (e.g., the XML from a HELD response) 802 3. Form the policy URI by appending the base64url-encoded form 803 of the hash [RFC4648] to one of the location URIs, e.g., as a 804 query parameter: "http://example.com/loc/ 805 foo?policy=j3WTGUb3smxcZA6eKIqmqdV3ALE" 807 Authors' Addresses 809 Richard Barnes 810 BBN Technologies 811 9861 Broken Land Parkway 812 Columbia, MD 21046 813 US 815 Phone: +1 410 290 6169 816 Email: rbarnes@bbn.com 817 Martin Thomson 818 Microsoft 819 3210 Porter Drive 820 Palo Alto, CA 94304 821 US 823 Phone: +1 650-353-1925 824 Email: martin.thomson@outlook.com 826 James Winterbottom 827 Andrew Corporation 828 Andrew Building (39) 829 Wollongong University Campus 830 Northfields Avenue 831 Wollongong, NSW 2522 832 AU 834 Phone: +61 242 212938 835 Email: james.winterbottom@andrew.com 837 Hannes Tschofenig 838 Nokia Siemens Networks 839 Linnoitustie 6 840 Espoo 02600 841 Finland 843 Phone: +358 (50) 4871445 844 Email: Hannes.Tschofenig@gmx.net 845 URI: http://www.tschofenig.priv.at