idnits 2.17.1 draft-ietf-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 (October 4, 2011) is 4587 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-12 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-07) exists of draft-ietf-geopriv-deref-protocol-03 == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-24 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV R. Barnes 3 Internet-Draft BBN Technologies 4 Intended status: Informational M. Thomson 5 Expires: April 6, 2012 J. Winterbottom 6 Andrew Corporation 7 H. Tschofenig 8 Nokia Siemens Networks 9 October 4, 2011 11 Location Configuration Extensions for Policy Management 12 draft-ietf-geopriv-policy-uri-02.txt 14 Abstract 16 Current location configuration protocols are capable of provisioning 17 an Internet host with a location URI that refers to the host's 18 location. These protocols lack a mechanism for the target host to 19 inspect or set the privacy rules that are applied to the URIs they 20 distribute. This document extends the current location configuration 21 protocols to provide hosts with a reference to the rules that are 22 applied to a URI, so that the host can view or set these rules. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 6, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Policy URIs . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Policy URI Usage . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. Policy URI Allocation . . . . . . . . . . . . . . . . . . 6 63 4. Location Configuration Extensions . . . . . . . . . . . . . . 7 64 4.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.3. Client Processing . . . . . . . . . . . . . . . . . . . . 8 67 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.1. HELD . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.3. Basic Access Control Policy . . . . . . . . . . . . . . . 10 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 6.1. URN Sub-Namespace Registration for 73 urn:ietf:params:xml:ns:geopriv:held:policy . . . . . . . . 12 74 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12 75 6.3. DHCP LuriType Registration . . . . . . . . . . . . . . . . 13 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 7.1. Integrity and Confidentiality for Authorization Policy 78 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 7.2. Access Control for Authorization Policy . . . . . . . . . 13 80 7.3. Location URI Allocation . . . . . . . . . . . . . . . . . 14 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 A critical step in enabling Internet hosts to access location-based 90 services is to provision those hosts with information about their own 91 location. This is accomplished via a Location Configuration Protocol 92 (LCP) [RFC5687], which allows a location provider (e.g., a local 93 access network) to inform a host about its location. 95 There are two basic patterns for location configuration, namely 96 configuration "by value" and "by reference" [RFC5808]. Configuration 97 by value provisions a host directly with its location, by providing 98 it location information that is directly usable (e.g., coordinates or 99 a civic address). Configuration by reference provides a host with a 100 URI that references the host's location, i.e., one that can be 101 dereferenced to obtain the location (by value) of the host. 103 In some cases, location by reference offers a few benefits over 104 location by value. From a privacy perspective, the required 105 dereference transaction provides a policy enforcement point, so that 106 the opaque URI itself can be safely conveyed over untrusted media 107 (e.g., SIP through untrusted proxies [RFC5606]). If the target host 108 is mobile, an application provider can use a single reference to 109 obtain the location of the host multiple times, saving bandwidth to 110 the host. For some configuration protocols, the location object 111 referenced by a location URI provides a much more expressive syntax 112 for location values than the configuration protocol itself (e.g., 113 DHCP geodetic location [RFC6225] versus GML in a PIDF-LO [RFC4119]). 115 From a privacy perspective, however, current LCPs are limited in 116 their flexibility, in that they do not provide hosts (the clients in 117 an LCP) with a way to inform the Location Server with policy for how 118 his location information should be handled. This document addresses 119 this gap by defining a simple mechanism for referring to and 120 manipulating policy, and by extending current LCPs to carry policy 121 references. Using the mechanisms defined in this document, an LCP 122 server (acting for the Location Server) can inform a host as to which 123 policy document controls a given location resource, and the host (in 124 its Rule Maker role) can inspect this document and modify it as 125 necessary. 127 In the following figure, adapted from RFC 5808, this document extends 128 the Location Configuration Protocols (1) and defines a simple 129 protocol for policy exchange (4). 131 +---------+---------+ Location +-----------+ 132 | | | Dereference | Location | 133 | LIS/LS +---------------+ Recipient | 134 | | | Protocol | | 135 +----+----+----+----+ (3) +-----+-----+ 136 | | | 137 | | | 138 Policy| |Location |Location 139 Exchange| |Configuration |Conveyance 140 (4)| |Protocol |Protocol 141 | |(1) |(2) 142 | | | 143 +------+----+----+----+ | 144 | Rule | Target/ | | 145 | Maker | Host +---------------------+ 146 | | | 147 +-----------+---------+ 149 The remainder of this document is structured as follows: After 150 introducing a few relevant terms, we define policy URIs as a channel 151 for referencing, inspecting, and updating policy documents. We then 152 define extensions to the HELD protocol and the DHCP option for 153 location by reference to allow these protocols to carry policy URIs. 154 Examples are given that demonstrate how policy URIs are carried in 155 these protocols and how they can be used by clients. 157 2. Definitions 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119 [RFC2119]. 163 3. Policy URIs 165 A policy URI is an HTTP [RFC2616] or HTTPS [RFC2818]URI that 166 identifies a policy resource that contains the authorization policy 167 for a linked location resource. Access to the location resource is 168 governed by the contents of the authorization policy. 170 A policy URI identifies an HTTP resource that a Rule Maker can use to 171 inspect and install policy documents that tell a Location Server how 172 it should protect the associated location resource. A policy URI 173 always identifies a resource that can be represented as a common- 174 policy document [RFC4745] (possibly including some extensions; e.g., 175 for geolocation policy [I-D.ietf-geopriv-policy]). 177 Note: RFC 3693 [RFC3693] identified the Rule Holder role as the one 178 that stores policy information. In this document, the Location 179 Server is also a Rule Holder. 181 3.1. Policy URI Usage 183 A Location Server that is the authority for policy URIs MUST support 184 GET, PUT, and DELETE requests to these URIs, in order to allow 185 clients to inspect, replace, and delete policy documents. Clients 186 support the three request methods as they desire to perform these 187 operations. 189 Knowledge of the policy URI can be considered adequate evidence of 190 authorization. A Location Server SHOULD allow all requests, but it 191 MAY deny certain requests based on local policy. For instance, a 192 Location Server might allow clients to inspect policy (GET), but not 193 to update it (PUT). 195 A GET request to a policy URI is a request for the referenced policy 196 information. If the request is authorized, then the Location Server 197 sends an HTTP 200 response containing the complete policy identified 198 by the URI. 200 A PUT request to a policy URI is a request to replace the current 201 policy. The entity-body of a PUT request includes a complete policy 202 document. When a Location Server receives a PUT request, it MUST 203 validate the policy document included in the body of the request. If 204 the request is valid and authorized, then the Location Server MUST 205 replace the current policy with the policy provided in the request. 207 A DELETE request to a policy URI is a request to delete the 208 referenced policy document. If the request is authorized, then the 209 Location Server MUST delete the policy referenced by the URI and 210 disallow access to the location URIs it governs until a new policy 211 document has been put in place via a PUT request. 213 A policy URI is only valid while the corresponding location URI set 214 is valid. A location server MUST NOT respond to any requests to a 215 policy URIs once the corresponding location URI set has expired. 216 This expiry time is specified by the 'expires' attribute in the HELD 217 locationResponse or the 'Valid-For' LuriType in DHCP. 219 A location URI can thus become invalid in three ways: By the 220 expiration of a validity interval in policy, by the removal of a 221 policy document with a DELETE request, or by the expiry of the 222 LCP-specified validity interval. The former two are temporary, 223 since the policy URI can be used to update the policy. The latter 224 one is permanent, since the expiry causes the policy URI to be 225 invalidated as well. 227 The Location Server MUST support policy documents in the common- 228 policy format [RFC4745], as identified by the MIME media type of 229 "application/auth-policy+xml". The common-policy format MUST be 230 provided as the default format in response to GET requests that do 231 not include specific "Accept" headers, but content negotiation MAY be 232 used to allow for other formats. 234 This usage of HTTP is generally compatible with the use of XCAP 235 [RFC4825] or WebDAV [RFC4918] to manage policy documents, but this 236 document does not define or require the use of these protocols. 238 3.2. Policy URI Allocation 240 A Location Server creates a policy URI for a specific location 241 resource at the time that the location resource is created; that is, 242 a policy URI is created at the same time as the location URI that it 243 controls. The URI of the policy resource MUST be different from the 244 location URI. 246 A policy URI is provided in response to location configuration 247 requests. A policy URI MUST NOT be provided to an entity that is not 248 authorized to view or set policy. This document does not describe 249 how policy might be provided to entities other than for location 250 configuration, for example, in responses to dereferencing requests 251 [I-D.ietf-geopriv-deref-protocol] or requests from third parties 252 [RFC6155]. 254 Each location URI has either one policy URI or no policy URI. The 255 initial policy that is referenced by a policy URI MUST be identical 256 to the policy that would be applied in the absence of a policy URI. 257 A client that does not support policy URIs can continue to use the 258 location URI as they would have if no policy URI were provided. 260 For DHCP and HELD, the client assumes that the default policy 261 grants any requester access to location information, as long as 262 the request possesses the location URI. To ensure that the 263 authorization policy is less permissive, a client updates the 264 policy prior to distributing the location URI. 266 A Location Server chooses whether or not to provide a policy URI 267 based on local policy. A HELD-specific extension also allows a 268 requester to specifically ask for a policy URI. 270 A policy URI is effectively a shared secret between Location Server 271 and its clients. Knowledge of a policy URI is all that is required 272 to perform any operations allowed on the policy. Thus, a policy URI 273 should be constructed so that it is hard to predict and 274 confidentiality-protected when transmitted (see Section 7). To avoid 275 re-using these shared secrets, the Location Server MUST generate a 276 new policy URI whenever it generates a new location URI set. 278 4. Location Configuration Extensions 280 Location configuration protocols can provision hosts with location 281 URIs that refer to the host's location. If the target host is to 282 control policy on these URIs, it needs a way to access the policy 283 that the Location Server uses to guide how it serves location URIs. 284 This section defines extensions to LCPs to carry policy URIs that the 285 target can use to control access to location resources. 287 4.1. HELD 289 The HELD protocol [RFC5985] defines a "locationUriSet" element, which 290 contain a set of one or more location URIs that reference the same 291 resource and share a common access control policy. The schema in 292 Figure 1 defines two extension elements for HELD: an empty 293 "requestPolicyUri" element that is added to a location request to 294 indicate that a Device desires that a policy URI be allocated; and a 295 "policyUri" element that is included in the location response. 297 298 304 305 306 308 310 312 Figure 1 314 The URI carried in a "policyUri" element refers to the common access 315 control policy for location URIs in the location response. The URI 316 MUST be a policy URI as described in Section 3. A policy URI MUST 317 use the "http:" or "https:" scheme, and the Location Server MUST 318 support the specified operations on the URI. 320 A HELD request MAY contain an explicit request for a policy URI. The 321 presence of the "requestPolicyUri" element in a location request 322 indicates that a policy URI is desired. 324 4.2. DHCP 326 The DHCP location by reference option 327 [I-D.ietf-geopriv-dhcp-lbyr-uri-option] provides location URIs in 328 sub-options called LuriElements. This document defines a new 329 LuriElement type for policy URIs. 331 LuriType=TBD Policy-URI - This is a policy URI that refers to the 332 access control policy for the location URIs. 334 [NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned 335 LuriType value and remove this note] 337 A Policy-URI LuriElement uses a UTF-8 character encoding. 339 A Policy-URI LuriElement identifies the policy resource for all 340 location URIs included in the location URI option. The URI MUST be a 341 policy URI as described in Section 3: It MUST use either the "http:" 342 or "https:" scheme, and the Location Server MUST support the 343 specified operations on the URI. 345 4.3. Client Processing 347 It is possible that this document will be updated to allow the use of 348 policy URIs that use protocols other than the HTTP-based protocol 349 described above. To ensure that they fail safely when presented with 350 such a URI, clients implementing this specification MUST verify that 351 a policy URI received from either HELD or DHCP uses either the 352 "http:" or "https:" scheme. If the URI does not match those schemes, 353 then the client MUST discard the URI and behave as if no policy URI 354 was provided. 356 5. Examples 358 In this section, we provide some brief illustrations of how policy 359 URIs are delivered to target hosts and used by those hosts to manage 360 policy. 362 5.1. HELD 364 A HELD request that explicitly requests the creation of a policy URI 365 has the following form: 367 368 locationURI 369 371 373 A HELD response providing a single "locationUriSet", containing two 374 URIs under a common policy, would have the following form: 376 377 378 379 https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o 380 381 382 sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com: 383 384 385 386 https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b 387 388 390 5.2. DHCP 392 A DHCP option providing one of the location URIs and the 393 corresponding policy URI from the previous example would have the 394 following form: 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | option-code | 110 | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | 1 | 0 | 1 | 49 | 'h' | 402 +---------------+---------------+---------------+---------------| 403 | 't' | 't' | 'p' | 's' | 404 +---------------+---------------+---------------+---------------| 405 | ':' | '/' | '/' | 'l' | 406 +---------------+---------------+---------------+---------------| 407 | 's' | '.' | ... | 408 +---------------+---------------+---------------+---------------| 409 | TBD | 56 | 'h' 't' | 410 +---------------+---------------+---------------+---------------| 411 | 't' | 'p' | 's' | ':' | 412 +---------------+---------------+---------------+---------------| 413 | '/' | '/' | ... | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 [NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned 417 LuriType value and remove this note] 419 5.3. Basic Access Control Policy 421 Consider a client that gets the policy URI 422 , as in the 423 above LCP example. The first thing this allows the client to do is 424 inspect the default policy that the LS has assigned to this URI: 426 GET /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 427 Host: ls.example.com:9768 429 HTTP/1.1 200 OK 430 Content-type: application/auth-policy+xml 431 Content-length: 388 433 434 436 437 438 439 2011-01-01T13:00:00.0Z 440 441 442 443 444 445 446 false 447 448 0 449 450 451 453 This policy allows any requester to obtain location information, as 454 long as they know the location URI. If the user disagrees with this 455 policy, and prefers for example, to only provide location to one 456 friend, at a city level of granularity, then the client can install 457 this policy on the Location Server: 459 PUT /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 460 Host: ls.example.com:9768 461 Content-type: application/auth-policy+xml 462 Content-length: 462 464 465 466 467 468 469 470 471 472 2011-01-01T13:00:00.0Z 473 474 475 476 477 479 city 480 481 482 483 485 HTTP/1.1 200 OK 487 Finally, after using the URI for a period, the user wishes to 488 permanently invalidate the URI. 490 DELETE /policy/357lp6f64prlbvhl5nk3b HTTP/1.1 491 Host: ls.example.com:9768 493 HTTP/1.1 200 OK 495 6. IANA Considerations 497 This document requires several IANA registrations, detailed below. 499 6.1. URN Sub-Namespace Registration for 500 urn:ietf:params:xml:ns:geopriv:held:policy 502 This section registers a new XML namespace, 503 "urn:ietf:params:xml:ns:geopriv:held:policy", per the guidelines in 504 [RFC3688]. 506 URI: urn:ietf:params:xml:ns:geopriv:held:policy 508 Registrant Contact: IETF, GEOPRIV working group, 509 (geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com). 511 XML: 513 BEGIN 514 515 517 518 519 HELD Policy URI Extension 520 521 522

Namespace for HELD Policy URI Extension

523

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

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

See RFCXXXX

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