idnits 2.17.00 (12 Aug 2021) /tmp/idnits45688/draft-ietf-geopriv-policy-uri-06.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 21, 2012) is 3528 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-15 ** 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 (~~), 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: March 25, 2013 Microsoft 6 J. Winterbottom 7 Andrew Corporation 8 H. Tschofenig 9 Nokia Siemens Networks 10 September 21, 2012 12 Location Configuration Extensions for Policy Management 13 draft-ietf-geopriv-policy-uri-06.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 25, 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 4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.3. Client Processing . . . . . . . . . . . . . . . . . . . . 9 69 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5.3. Basic Access Control Policy . . . . . . . . . . . . . . . 11 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 6.1. URN Sub-Namespace Registration for 75 urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 13 76 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 13 77 6.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 14 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 7.1. Integrity and Confidentiality for Authorization Policy 80 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 7.2. Access Control for Authorization Policy . . . . . . . . . 15 82 7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 16 83 7.4. Policy URI Handling . . . . . . . . . . . . . . . . . . . 17 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 88 Appendix A. Example Policy URI Generation Algorithm . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 91 1. Introduction 93 A critical step in enabling Internet hosts to access location-based 94 services is to provision those hosts with information about their own 95 location. This is accomplished via a Location Configuration Protocol 96 (LCP) [RFC5687], which allows a location provider (e.g., a local 97 access network) to inform a host about its location. 99 There are two basic patterns for location configuration, namely 100 configuration "by value" and "by reference" [RFC5808]. Configuration 101 by value provisions a host directly with its location, by providing 102 it location information that is directly usable (e.g., coordinates or 103 a civic address). Configuration by reference provides a host with a 104 URI that references the host's location, i.e., one that can be 105 dereferenced to obtain the location (by value) of the host. 107 In some cases, location by reference offers a few benefits over 108 location by value. From a privacy perspective, the required 109 dereference transaction provides a policy enforcement point, so that 110 if suitable privacy policies have been provisioned, the opaque 111 location URI can be safely conveyed over untrusted media. (If the 112 location URI is not subject to privacy rules, then conveying the 113 location URI may pose even greater risk than sending location by 114 value [RFC5606]) If the target host is mobile, an application 115 provider can use a single reference to obtain the location of the 116 host multiple times, saving bandwidth to the host. For some 117 configuration protocols, the location object referenced by a location 118 URI provides a much more expressive syntax for location values than 119 the configuration protocol itself (e.g., DHCP geodetic location 120 [RFC6225] versus GML in a PIDF-LO [RFC4119]). 122 From a privacy perspective, however, current LCPs are limited in 123 their flexibility, in that they do not provide hosts (the clients in 124 an LCP) with a way to inform the Location Server with policy for how 125 his location information should be handled. This document addresses 126 this gap by defining a simple mechanism for referring to and 127 manipulating policy, and by extending current LCPs to carry policy 128 references. Using the mechanisms defined in this document, an LCP 129 server (acting for the Location Server (LS) or Location Information 130 Server (LIS)) can inform a host as to which policy document controls 131 a given location resource, and the host (in its Rule Maker role) can 132 inspect this document and modify it as necessary. 134 In the following figure, adapted from RFC 5808, this document extends 135 the Location Configuration Protocols (1) and defines a simple 136 protocol for policy exchange (4). 138 +---------+---------+ Location +-----------+ 139 | | | Dereference | Location | 140 | LIS/LS +---------------+ Recipient | 141 | | | Protocol | | 142 +----+----+----+----+ (3) +-----+-----+ 143 | | | 144 | | | 145 Policy| |Location |Location 146 Exchange| |Configuration |Conveyance 147 (4)| |Protocol |Protocol 148 | |(1) |(2) 149 | | | 150 +------+----+----+----+ | 151 | Rule | Target/ | | 152 | Maker | Host +---------------------+ 153 | | | 154 +-----------+---------+ 156 The remainder of this document is structured as follows: After 157 introducing a few relevant terms, we define policy URIs as a channel 158 for referencing, inspecting, and updating policy documents. We then 159 define extensions to the HELD protocol and the DHCP option for 160 location by reference to allow these protocols to carry policy URIs. 161 Examples are given that demonstrate how policy URIs are carried in 162 these protocols and how they can be used by clients. 164 2. Definitions 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119]. 170 3. Policy URIs 172 A policy URI is an HTTP [RFC2616] or HTTPS [RFC2818]URI that 173 identifies a policy resource that contains the authorization policy 174 for a linked location resource. Access to the location resource is 175 governed by the contents of the authorization policy. 177 A policy URI identifies an HTTP resource that a Rule Maker can use to 178 inspect and install policy documents that tell a Location Server how 179 it should protect the associated location resource. A policy URI 180 always identifies a resource that can be represented as a common- 181 policy document [RFC4745] (possibly including some extensions; e.g., 182 for geolocation policy [I-D.ietf-geopriv-policy]). 184 Note: RFC 3693 [RFC3693] identified the Rule Holder role as the one 185 that stores policy information. In this document, the Location 186 Server is also a Rule Holder. 188 3.1. Policy URI Usage 190 A Location Server that is the authority for policy URIs MUST support 191 GET, PUT, and DELETE requests to these URIs, in order to allow 192 clients to inspect, replace, and delete policy documents. Clients 193 support the three request methods as they desire to perform these 194 operations. 196 Knowledge of the policy URI can be considered adequate evidence of 197 authorization; a policy URI functions as a shared secret between the 198 client and the server (see Section 7). A Location Server SHOULD 199 allow all requests, but it MAY deny certain requests based on local 200 policy. For instance, a Location Server might allow clients to 201 inspect policy (GET), but not to update it (PUT). Or a Location 202 Server might require clients to authenticate using HTTP or TLS client 203 authentication. Clients implementing this specification SHOULD 204 support HTTP client authentication [RFC2617] and MAY support TLS 205 client certificates. 207 A GET request to a policy URI is a request for the referenced policy 208 information. If the request is authorized, then the Location Server 209 sends an HTTP 200 response containing the complete policy identified 210 by the URI. 212 A PUT request to a policy URI is a request to replace the current 213 policy. The entity-body of a PUT request includes a complete policy 214 document. When a Location Server receives a PUT request, it MUST 215 validate the policy document included in the body of the request. If 216 the request is valid and authorized, then the Location Server MUST 217 replace the current policy with the policy provided in the request. 219 A DELETE request to a policy URI is a request to delete the 220 referenced policy document. If the request is authorized, then the 221 Location Server MUST delete the policy referenced by the URI and 222 disallow access to the location URIs it governs until a new policy 223 document has been put in place via a PUT request. 225 A policy URI is only valid while the corresponding location URI set 226 is valid. A location server MUST NOT respond to any requests to a 227 policy URIs once the corresponding location URI set has expired. 228 This expiry time is specified by the 'expires' attribute in the HELD 229 locationResponse or the 'Valid-For' LuriType in DHCP. 231 A location URI can thus become invalid in three ways: By the 232 expiration of a validity interval in policy, by the removal of a 233 policy document with a DELETE request, or by the expiry of the 234 LCP-specified validity interval. The former two are temporary, 235 since the policy URI can be used to update the policy. The latter 236 one is permanent, since the expiry causes the policy URI to be 237 invalidated as well. 239 The Location Server MUST support policy documents in the common- 240 policy format [RFC4745], as identified by the MIME media type of 241 "application/auth-policy+xml". The common-policy format MUST be 242 provided as the default format in response to GET requests that do 243 not include specific "Accept" headers, but content negotiation MAY be 244 used to allow for other formats. 246 This usage of HTTP is generally compatible with the use of XCAP 247 [RFC4825] or WebDAV [RFC4918] to manage policy documents, but this 248 document does not define or require the use of these protocols. 250 3.2. Policy URI Allocation 252 A Location Server creates a policy URI for a specific location 253 resource at the time that the location resource is created; that is, 254 a policy URI is created at the same time as the location URI that it 255 controls. The URI of the policy resource MUST be different from the 256 location URI. 258 A policy URI is provided in response to location configuration 259 requests. A policy URI MUST NOT be provided to an entity that is not 260 authorized to view or set policy. This document does not describe 261 how policy might be provided to entities other than for location 262 configuration, for example, in responses to dereferencing requests 263 [I-D.ietf-geopriv-deref-protocol] or requests from third parties 264 [RFC6155]. 266 Each location URI has either one policy URI or no policy URI. The 267 initial policy that is referenced by a policy URI MUST be identical 268 to the policy that would be applied in the absence of a policy URI. 269 A client that does not support policy URIs can continue to use the 270 location URI as they would have if no policy URI were provided. 272 For DHCP and HELD, the client assumes that the default policy 273 grants any requester access to location information, as long as 274 the request possesses the location URI. To ensure that the 275 authorization policy is less permissive, a client updates the 276 policy prior to distributing the location URI. 278 A Location Server chooses whether or not to provide a policy URI 279 based on local policy. A HELD-specific extension also allows a 280 requester to specifically ask for a policy URI. 282 A policy URI is effectively a shared secret between Location Server 283 and its clients. Knowledge of a policy URI is all that is required 284 to perform any operations allowed on the policy. Thus, a policy URI 285 should be constructed so that it is hard to predict and 286 confidentiality-protected when transmitted (see Section 7). To avoid 287 re-using these shared secrets, the Location Server MUST generate a 288 new policy URI whenever it generates a new location URI set. 290 3.3. Policy Defaults 292 Client implementors should keep in mind that setting no policy (never 293 performing an HTTP request to a policy URI) is very different from 294 setting an empty policy (performing a PUT with the empty policy). By 295 "the empty policy", we mean a policy containing no rules, which would 296 be represented by the following policy document: 298 299 300 302 Figure 1: The empty policy 304 If no policy is set, then the client tacitly accepts whatever policy 305 the server applies to location URIs, including a policy that provides 306 location to anyone that makes a dereference request. If the empty 307 policy is set, then the opposite is true; the client directs the 308 server to never provide access to location. (Since there are no 309 rules to allow access, and the policy language is default-deny.) 311 Implementors should thus consider carefully how to handle the case 312 where the user provides no privacy policy input. On the one hand, an 313 implementation might treat this case as if the user had no privacy 314 preferences, and thus set no policy. On the other hand, another 315 implementation might decide that if a user provides no positive 316 authorization, then the empty policy should be installed. 318 The same reasoning could also be applied to servers, with the caveat 319 that servers do not know whether a given HELD client supports the use 320 of policy URIs. A client that does not understand policy URIs will 321 not be able to set its own policy, and so the server must choose a 322 default that is open enough that clients will find it useful. On the 323 other hand, once a client indicates that it understands policy URIs 324 (e.g., by sending an HTTP request to a policy URI), the server may 325 change its default policy to something more restrictive -- even the 326 empty, default-deny policy -- since the client can specify something 327 more permissive if desired. 329 4. Location Configuration Extensions 331 Location configuration protocols can provision hosts with location 332 URIs that refer to the host's location. If the target host is to 333 control policy on these URIs, it needs a way to access the policy 334 that the Location Server uses to guide how it serves location URIs. 335 This section defines extensions to LCPs to carry policy URIs that the 336 target can use to control access to location resources. 338 4.1. HELD 340 The HELD protocol [RFC5985] defines a "locationUriSet" element, which 341 contain a set of one or more location URIs that reference the same 342 resource and share a common access control policy. The schema in 343 Figure 2 defines two extension elements for HELD: an empty 344 "requestPolicyUri" element that is added to a location request to 345 indicate that a Device desires that a policy URI be allocated; and a 346 "policyUri" element that is included in the location response. 348 349 355 356 357 359 361 363 Figure 2: XML Schema for the policy URI extension 365 The URI carried in a "policyUri" element refers to the common access 366 control policy for location URIs in the location response. The URI 367 MUST be a policy URI as described in Section 3. A policy URI MUST 368 use the "http:" or "https:" scheme, and the Location Server MUST 369 support the specified operations on the URI. 371 A HELD request MAY contain an explicit request for a policy URI. The 372 presence of the "requestPolicyUri" element in a location request 373 indicates that a policy URI is desired. 375 4.2. DHCP 377 The DHCP location by reference option 378 [I-D.ietf-geopriv-dhcp-lbyr-uri-option] provides location URIs in 379 sub-options called LuriElements. This document defines a new 380 LuriElement type for policy URIs. 382 LuriType=TBD Policy-URI - This is a policy URI that refers to the 383 access control policy for the location URIs. 385 [NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned 386 LuriType value and remove this note] 388 A Policy-URI LuriElement uses a UTF-8 character encoding. 390 A Policy-URI LuriElement identifies the policy resource for all 391 location URIs included in the location URI option. The URI MUST be a 392 policy URI as described in Section 3: It MUST use either the "http:" 393 or "https:" scheme, and the Location Server MUST support the 394 specified operations on the URI. 396 4.3. Client Processing 398 It is possible that this document will be updated to allow the use of 399 policy URIs that use protocols other than the HTTP-based protocol 400 described above. To ensure that they fail safely when presented with 401 such a URI, clients implementing this specification MUST verify that 402 a policy URI received from either HELD or DHCP uses either the 403 "http:" or "https:" scheme. If the URI does not match those schemes, 404 then the client MUST discard the URI and behave as if no policy URI 405 was provided. 407 5. Examples 409 In this section, we provide some brief illustrations of how policy 410 URIs are delivered to target hosts and used by those hosts to manage 411 policy. 413 5.1. HELD 415 A HELD request that explicitly requests the creation of a policy URI 416 has the following form: 418 419 locationURI 420 423 425 A HELD response providing a single "locationUriSet", containing two 426 URIs under a common policy, would have the following form: 428 429 430 431 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 432 433 434 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 435 436 437 438 https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b 439 440 442 5.2. DHCP 444 A DHCP option providing one of the location URIs and the 445 corresponding policy URI from the previous example would have the 446 following form: 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | option-code | 110 | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | 1 | 0 | 1 | 49 | 'h' | 454 +---------------+---------------+---------------+---------------| 455 | 't' | 't' | 'p' | 's' | 456 +---------------+---------------+---------------+---------------| 457 | ':' | '/' | '/' | 'l' | 458 +---------------+---------------+---------------+---------------| 459 | 's' | '.' | ... | 460 +---------------+---------------+---------------+---------------| 461 | TBD | 56 | 'h' 't' | 462 +---------------+---------------+---------------+---------------| 463 | 't' | 'p' | 's' | ':' | 464 +---------------+---------------+---------------+---------------| 465 | '/' | '/' | ... | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 [NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned 469 LuriType value and remove this note] 471 5.3. Basic Access Control Policy 473 Consider a client that gets the policy URI 474 , as in the 475 above LCP example. The first thing this allows the client to do is 476 inspect the default policy that the LS has assigned to this URI: 478 GET /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 479 Host: ls.example.com:9768 481 HTTP/1.1 200 OK 482 Content-type: application/auth-policy+xml 483 Content-length: 388 485 486 488 489 490 491 2011-01-01T13:00:00.0Z 492 493 494 495 496 497 498 false 499 500 0 501 502 503 505 This policy allows any requester to obtain location information, as 506 long as they know the location URI. If the user disagrees with this 507 policy, and prefers for example, to only provide location to one 508 friend, at a city level of granularity, then the client can install 509 this policy on the Location Server: 511 PUT /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 512 Host: ls.example.com:9768 513 Content-type: application/auth-policy+xml 514 Content-length: 462 516 517 518 519 520 521 522 523 524 2011-01-01T13:00:00.0Z 525 526 527 528 529 531 city 532 533 534 535 537 HTTP/1.1 200 OK 539 Finally, after using the URI for a period, the user wishes to 540 permanently invalidate the URI. 542 DELETE /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 543 Host: ls.example.com:9768 545 HTTP/1.1 200 OK 547 6. IANA Considerations 549 This document requires several IANA registrations, detailed below. 551 6.1. URN Sub-Namespace Registration for 552 urn:ietf:params:xml:ns:geopriv:held:policy 554 This section registers a new XML namespace, 555 "urn:ietf:params:xml:ns:geopriv:held:policy", per the guidelines in 556 [RFC3688]. 558 URI: urn:ietf:params:xml:ns:geopriv:held:policy 560 Registrant Contact: IETF, GEOPRIV working group, 561 (geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com). 563 XML: 565 BEGIN 566 567 569 570 571 HELD Policy URI Extension 572 573 574

Namespace for HELD Policy URI Extension

575

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

576 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX 577 with the RFC number for this specification.] 578

See RFCXXXX

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