idnits 2.17.00 (12 Aug 2021) /tmp/idnits5624/draft-ietf-geopriv-deref-protocol-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2011) is 3854 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) ** Downref: Normative reference to an Informational RFC: RFC 2818 == Outdated reference: draft-ietf-geopriv-arch has been published as RFC 6280 == Outdated reference: A later version (-19) exists of draft-ietf-geopriv-dhcp-lbyr-uri-option-12 == Outdated reference: draft-ietf-geopriv-policy has been published as RFC 6772 == Outdated reference: draft-ietf-geopriv-policy-uri has been published as RFC 7199 == Outdated reference: draft-ietf-sipcore-location-conveyance has been published as RFC 6442 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV J. Winterbottom 3 Internet-Draft Commscope 4 Intended status: Standards Track H. Tschofenig 5 Expires: May 3, 2012 Nokia Siemens Networks 6 H. Schulzrinne 7 Columbia University 8 M. Thomson 9 M. Dawson 10 Commscope 11 October 31, 2011 13 A Location Dereferencing Protocol Using HELD 14 draft-ietf-geopriv-deref-protocol-04 16 Abstract 18 This document describes how to use the Hypertext Transfer Protocol 19 (HTTP) over Transport Layer Security (TLS) as a dereferencing 20 protocol to resolve a reference to a Presence Information Data Format 21 Location Object (PIDF-LO). The document assumes that a Location 22 Recipient possesses a URI that can be used in conjunction with the 23 HTTP-Enabled Location Delivery (HELD) protocol to request the 24 location of the Target. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 3, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Authorization Models . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Authorization by Possession . . . . . . . . . . . . . . . 6 64 3.2. Authorization via Access Control . . . . . . . . . . . . . 7 65 3.3. Access Control with HELD Deference . . . . . . . . . . . . 7 66 4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 8 67 4.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 9 68 4.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 9 69 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 75 9.2. Informative references . . . . . . . . . . . . . . . . . . 15 76 Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 17 77 Appendix B. Compliance to Location Reference Requirements . . . . 20 78 B.1. Requirements for a Location Configuration Protocol . . . . 20 79 B.2. Requirements for a Location Dereference Protocol . . . . . 22 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 82 1. Introduction 84 Provision of location information by reference [RFC5808] involves the 85 creation of a resource that is identified by a "location URI". A 86 "location URI" is a URI [RFC3986] that identifies a resource 87 containing the location of an entity. A location URI can be acquired 88 using a location configuration protocol, such as HTTP-Enabled 89 Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration 90 Protocol (DHCP) location URI option 91 [I-D.ietf-geopriv-dhcp-lbyr-uri-option]. A location URI does not 92 intrinsically include location information, instead the URI is 93 "dereferenced" by a Location Recipient to acquire location 94 information. This document specifies how a holder of an "http:" or 95 "https:" location URI uses that URI to retrieve location information. 97 HELD defines a use of HTTP that enables location configuration - the 98 process where a Device acquires location information about itself. A 99 part of location configuration is the provision of a location URI. 100 However, HELD does not describe how such a URI is used; this document 101 provides that definition. 103 This document defines how HELD is used by a Location Recipient to 104 dereference a location URI and acquire location information. The 105 result of this process is a location object in the form of a Presence 106 Information Data Format - Location Object (PIDF-LO) document 107 [RFC4119]. A constrained set of HELD features are defined such that 108 it is suitable for use as a location dereference protocol [RFC5808]. 109 Use as a location dereference protocol requires use of the Transport 110 Layer Security (TLS) binding for HTTP [RFC2818] in order to provide 111 confidentiality, authentication and protection from modification. 113 Use of HELD as a dereferencing protocol has the advantage that the 114 Location Recipient can indicate the type of location information it 115 would like to receive. This functionality is already available with 116 the HELD base specification, described in [RFC5985]. Furthermore, 117 the HELD response from the LIS towards the Location Recipient not 118 only provides the PIDF-LO but also encapsulates supplementary 119 information, such as error messages, back to the Location Recipient. 121 Location URIs created for use with HELD dereferencing use the 122 "https:" or "http:" scheme. HELD can be used by Location Recipients 123 that are aware of the fact that the URI is a location URI. Mandatory 124 support for an HTTP GET request ensures that the URI can be used even 125 if it is not recognized as a location URI. 127 An example scenario envisioned by this document is shown in Figure 1. 128 This diagram shows how a location dereference protocol fits with 129 location configuration and conveyance. [RFC5808] contains more 130 information on this scenario and others like it. 132 +-------------+ 133 +------------+ | Location | +-----------+ 134 | End Device | | Information | | Location | 135 | (Target) | | Server | | Recipient | 136 +-----+------+ +------+------+ +-----+-----+ 137 | | | 138 .- + - - - - - - - - - - - - + -. | 139 : | locationRequest | : | 140 . |----(for location URI)-->| . | 141 : | | : Location | 142 . | locationResponse | . Configuration | 143 : |<-----(location URI)-----| : | 144 . | | . | 145 `- + - - - - - - - - - - - - + -' | 146 | | | 147 | Location Conveyance | 148 |~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>| 149 | | | 150 | .- + - - - - - - - - - - - - + -. 151 | : | locationRequest | : 152 | . |<------(for civic)-------| . 153 | Dereferencing : | | : 154 | . | locationResponse | . 155 | : |--------(PIDF-LO)------->| : 156 | . | | . 157 | `- + - - - - - - - - - - - - + -' 158 | | | 160 Figure 1: Example of Dereference Protocol Exchange 162 2. Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 This document uses key terminology from several sources: 170 o terms for the GEOPRIV reference model defined in 171 [I-D.ietf-geopriv-arch]; 173 o the term Location Information Server (LIS), from [RFC5687], is a 174 node in the access network that provides location information to 175 an end point; a LIS provides location URIs; 177 o the term Location Server (LS), from [I-D.ietf-geopriv-arch], is 178 used to identify the role that responds to a location dereference 179 request; this might be the same entity as the LIS, but the model 180 in [RFC5808] allows for the existence of separate - but related - 181 entities; and 183 o the term location URI is coined in [RFC5808]. 185 3. Authorization Models 187 This section discusses two extreme types of authorization models for 188 dereferencing with HELD URIs, namely "Authorization by Possession" 189 and "Authorization by Access Control". In the subsequent subsections 190 we discuss the properties of these two models. Figure 2, from 191 [RFC5808], shows the model applicable to location configuration, 192 conveyance and dereference. 194 +---------+--------+ Location +-----------+ 195 | | | Dereference | Location | 196 | LIS - LS +---------------+ Recipient | 197 | | | Protocol | | 198 +----+----+--------+ (3) +-----+-----+ 199 | `. | 200 | Policy `. | 201 Location | Exchange `. | 202 Configuration | (*) | | 203 Protocol | +----+----+ | 204 (1) | | Rule | Location | 205 | | Maker | Conveyance | 206 +-----+----+ +---------+ Protocol | 207 | | (2) | 208 | Target +------------------------------+ 209 | | 210 +----------+ 212 Figure 2: Communication Model 214 It is important to note that this document does not mandate a 215 specific authorization model. It is possible to combine aspects of 216 both models. However, no authentication framework is provided, which 217 limits the policy options available when the "Authorization by Access 218 Control" model is used. 220 For either authorization model, the overall process is similar. The 221 following steps are followed, with minor alterations: 223 1. The Target acquires a location URI from the LIS. This uses a 224 location configuration protocol (LCP), such as HELD or DHCP. 226 2. The Target then conveys the location URI to a third party, the 227 Location Recipient (for example using SIP as described in 228 [I-D.ietf-sipcore-location-conveyance]). This step is shown in 229 (2) of Figure 2. 231 3. The Location Recipient then needs to dereference the location URI 232 in order to obtain the Location Object (3). An "https:" or 233 "http:" URI is dereferenced as described in this document; other 234 URI schemes might be dereferenced using another method. 236 In this final step, the Location Server (LS) or LIS makes an 237 authorization decision. How this decision is reached depends on the 238 authorization model. 240 3.1. Authorization by Possession 242 In this model, possession - or knowledge - of the location URI is 243 used to control access to location information. A location URI is 244 constructed such that it is hard to guess (see C9 of [RFC5808]) and 245 the set of entities that it is disclosed to is limited. The only 246 authentication required by the LS is evidence of possession of the 247 URI. The LS is able to immediately authorize any request that 248 indicates this URI. 250 Authorization by possession uses a very simple policy that does not 251 typically require direct interaction with a Rule Maker; it is assumed 252 that the Rule Maker is able to exert control over the distribution of 253 the location URI. Therefore, the LIS can operate with limited policy 254 input from a Rule Maker. 256 Limited disclosure is an important aspect of this authorization 257 model. The location URI is a secret; therefore, ensuring that 258 adversaries are not able to acquire this information is paramount. 259 Encryption, such as might be offered by TLS [RFC5246] or S/MIME 260 [RFC5751], protects the information from eavesdroppers. 262 Use of authorization by possession location URIs in a hop-by-hop 263 protocol such as SIP [RFC3261] adds the possibility of on-path 264 adversaries. Depending on the usage of the location URI for certain 265 location based applications (e.g., emergency services, location based 266 routing) specific treatment is important, as discussed in 267 [I-D.ietf-sipcore-location-conveyance]. 269 Using possession as a basis for authorization means that, once 270 granted, authorization cannot be easily revoked. Cancellation of a 271 location URI ensures that legitimate users are also affected; 272 application of additional policy is theoretically possible, but could 273 be technically infeasible. Therefore, other measures are provided to 274 prevent an adversary from gaining access to location information 275 indefinitely. 277 A very simple policy is established at the time that the location URI 278 is created. This policy specifies that the location URI expires 279 after a certain time, which limits any inadvertent exposure of 280 location information to adversaries. The expiration time of the 281 location URI might be negotiated at the time of its creation, or it 282 might be unilaterally set by the LIS. 284 3.2. Authorization via Access Control 286 Use of explicit access control provides a Rule Maker greater control 287 over the behaviour of an LS. In contrast to authorization by 288 possession, possession of a this form of location URI does not imply 289 authorization. Since an explicit policy is used to authorize access 290 to location information, the location URI can be distributed to many 291 potential Location Recipients. 293 Either before creation or dissemination of the location URI, the Rule 294 Maker establishes an authorization policy with the LS. In reference 295 to Figure 2, authorization policies might be established at creation 296 (Step 1), and need to be established before the location URI is 297 published (Step 2) to ensure that the policy grants access to the 298 desired Location Recipients. Depending on the mechanism used, it 299 might also be possible to change authorization policies at any time. 301 A possible format for these authorization policies is available with 302 GEOPRIV Common Policy [RFC4745] and Geolocation Policy 303 [I-D.ietf-geopriv-policy]. Additional constraints might be 304 established by other means. 306 The LS enforces the authorization policy when a Location Recipient 307 dereferences the URI. Explicit authorization policies allow a Rule 308 Maker to specify how location information is provided to Location 309 Recipients. 311 3.3. Access Control with HELD Deference 313 This document does not describe a specific authentication mechanism. 314 This means that authorization policies are unable to specifically 315 identify authorized Location Recipients. 317 In order to control access to location information based on the 318 identity of the Location Recipient, use of authorization by 319 possession is employed. By controlling which Location Recipients 320 receive location URIs, access to location information is controlled. 322 Other policy mechanisms, such as those described in 323 [I-D.ietf-geopriv-policy], can be applied to different Location 324 Recipients if multiple location URIs are used. Location Recipients 325 that receive a particular location URI are granted location 326 information based on the authorization policy associated with that 327 URI. 329 Providing that knowledge of a location URI is limited, policy 330 appropriate to the Location Recipients that receive the location URI 331 can be assigned. Selective disclosure used in this fashion can be 332 used in place of identity-based authorization. 334 How policy is associated with a location URI is not defined by this 335 document. [I-D.ietf-geopriv-policy-uri] describes one possible 336 mechanism. 338 Authentication of Location Recipients and use of identity-based 339 authorization policy is not precluded. A Location Server MAY support 340 an authentication mechanism that enables identity-based authorization 341 policies to be used. Future specifications might define means of 342 identifying recipients. 344 Note: Policy frameworks like [RFC4745] degrade in a way that 345 protects privacy if features are not supported. If a policy 346 specifies a rule that is conditional on the identity of a 347 recipient and the protocol does not (or cannot) provide an 348 assertion identity of the recipient, the rule has no effect and 349 the policy defaults to providing less information. 351 4. HELD Dereference Protocol 353 This section describes how HELD can be used to dereference a location 354 URI. This process can be applied when a Location Recipient is in 355 possession of a location URI with a "https:" or "http:" URI scheme. 357 A Location Recipient that wishes to dereference an "https:" or 358 "http:" URI performs a HELD request on HTTP to the identified 359 resource. 361 Note: In many cases, an "http:" URI does not provide sufficient 362 security for location URIs. The absence of the security 363 mechanisms provided by TLS means that the Rule Maker has no 364 control over who receives location information and the Location 365 Recipient has no assurance that the information is correct. 367 The Location Recipient establishes a connection to the LS, as 368 described in [RFC2818]. The TLS ciphersuite TLS_NULL_WITH_NULL_NULL 369 MUST NOT be used. The LS MUST be authenticated to ensure that the 370 correct server is contacted. 372 A Location Server MAY reject a request and request that a Location 373 Recipient provide authentication credentials if authorization is 374 dependent on the Location Recipient identity. Future specifications 375 could define an authentication mechanism and a means by which 376 Location Recipients are identified in authorization policies. This 377 document provides definitions for neither item. 379 4.1. HELD Usage Profile 381 Use of HELD as a location dereference protocol is largely the same as 382 its use as a location configuration protocol. Aside from the 383 restrictions noted in this document, HELD semantics do not differ 384 from those established in [RFC5985]. 386 The HELD "locationRequest" is the only request permitted by this 387 specification. Similarly, request parameters other than the 388 following MUST NOT be accepted by the LS: "responseTime", 389 "locationType" (including the associated "exact" attribute). 391 Parameters and requests that do not have known behaviour for 392 dereference requests MUST NOT be used. The LS MUST ignore any 393 parameters that it does not understand unless it knows the parameters 394 to be invalid. If parameters are understood by the LS and known to 395 be invalid, the LS MAY generate a HELD error response. For instance, 396 those defined in [RFC6155] are always invalid and can be rejected. 398 The LS MUST NOT generate location URIs or provide a "locationUriSet" 399 in response to a dereference request. If the location request 400 contains a "locationType" element that includes "locationURI", this 401 parameter is either ignored or rejected as appropriate, based on the 402 associated "exact" attribute. 404 4.2. HTTP GET Behavior 406 GET is the method assumed by generic HTTP user agents, therefore 407 unless context identifies an "https:" URI as a HELD URI, such a user 408 agent might simply send an HTTP GET. Rather than providing an HTTP 409 405 (Method Not Allowed) response indicating that POST is the only 410 permitted method, a LIS MUST provide a HELD location response if it 411 receives an HTTP GET request. 413 An HTTP GET request to a HELD URI produces a HELD response as if the 414 following HELD request had been sent using HTTP POST: 416 417 418 geodetic civic 419 420 422 Figure 3: GET Request Equivalent Location Request 424 HTTP GET requests MUST be safe and idempotent [RFC2616] - that is, 425 there are no side-effects of making the request and a repeated 426 request has no more effect than a single request. Repeating a HELD 427 request might result in a different location, but only as a result of 428 a change in the state of the resource: the location of the Target. 430 Only the creation of a location URI as a result of receiving a 431 request causes a HELD request to have side-effects. A request to a 432 location URI can be both safe and idempotent, since a location URI 433 cannot be produced in response to a request to a location URI. 435 A Location Recipient MAY infer from a response containing the HELD 436 content type, "application/held+xml", that a URI references a 437 resource that supports HELD. 439 Content negotiation MAY be supported to produce a presence document 440 in place of a HELD location response. Where the presence document 441 would otherwise be included in a "locationResponse" document, it can 442 be included in the body of the HTTP response directly by including an 443 "Accept" header that includes "application/pidf+xml". 445 5. Examples 447 The example in Figure 4 shows the simplest form of dereferencing 448 request using HELD to the location URI 449 "https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that 450 this differs from the example in Section 10.1 of [RFC5985] is in the 451 request URI and the source of the URI. 453 POST /uri/w3g61nf5n66p0 HTTP/1.1 454 Host: ls.example.com:49152 455 Content-Type: application/held+xml 456 Content-Length: 87 458 459 461 Figure 4: Minimal Dereferencing Request 463 Figure 5 shows the response to the previous request listing both 464 civic and geodetic location information of the Target's location. 465 Again, this is identical to the response in Section 10.1 of [RFC5985] 466 - unless policy specifies otherwise, the Location Recipient receives 467 the same information as the Device. 469 HTTP/1.1 200 OK 470 Server: Example LIS 471 Date: Mon, 10 Jan 2011 03:42:29 GMT 472 Expires: Tue, 11 Jan 2011 03:42:29 GMT 473 Cache-control: private 474 Content-Type: application/held+xml 475 Content-Length: 676 477 478 479 481 482 483 485 486 488 -34.407 150.88001 489 490 491 492 493 false 494 495 2011-01-11T03:42:29+00:00 496 497 Wiremap 498 499 500 2006-01-10T03:42:28+00:00 501 502 503 505 Figure 5: Response with Location Information 507 The following GET request is treated in an equivalent fashion. The 508 LS treats this request as though it were a location request of the 509 form shown in Figure 3. The same response might be provided. 511 GET /uri/w3g61nf5n66p0 HTTP/1.1 512 Host: ls.example.com:49152 513 Accept: application/held+xml 515 Figure 6: GET Request 517 The following GET request uses content negotiation to indicate a 518 preference for a presence document. 520 GET /uri/w3g61nf5n66p0 HTTP/1.1 521 Host: ls.example.com:49152 522 Accept: application/pidf+xml,application/held+xml;q=0.5 524 Figure 7: GET Request with Content Negotiation 526 The response only differs from a normal HELD location response to a 527 POST request in that the "locationResponse" element is omitted and 528 the "Content-Type" header reflects the changed content. 530 HTTP/1.1 200 OK 531 Server: Example LIS 532 Date: Mon, 10 Jan 2011 03:42:29 GMT 533 Expires: Tue, 11 Jan 2011 03:42:29 GMT 534 Cache-control: private 535 Content-Type: application/pidf+xml 536 Content-Length: 591 538 539 541 542 544 Figure 8: GET Response with PIDF-LO 546 6. Security Considerations 548 Privacy of location information is the most important security 549 consideration for this document. Two measures in particular are used 550 to protect privacy: TLS and authorization policies. TLS provides a 551 means of ensuring confidentiality of location information through 552 encryption and mutual authentication. An authorization policy allows 553 a Rule Maker to explicitly control how location information is 554 provided to Location Recipients. 556 The process by which a Rule Maker establishes an authorization policy 557 is not covered by this document; several methods are possible, for 558 instance: [I-D.ietf-geopriv-policy-uri], [RFC4825]. 560 Use of TLS for the dereferencing of location URIs is strongly 561 RECOMMENDED, as discussed in Section 4. Location Recipients MUST 562 authenticate the host identity using the domain name included in the 563 location URI, using the procedure described in Section 3.1 of 564 [RFC2818]. Local policy determines what a Location Recipient does if 565 authentication fails or cannot be attempted. 567 The authorization by possession model (Section 3.1) further relies on 568 TLS when transmitting the location URI to protect the secrecy of the 569 URI. Possession of such a URI implies the same privacy 570 considerations as possession of the PIDF-LO document that the URI 571 references. 573 Location URIs MUST only be disclosed to authorized Location 574 Recipients. The GEOPRIV architecture [I-D.ietf-geopriv-arch] 575 identifies the Rule Maker role as being the entity that authorizes 576 disclosure of this nature. 578 Protection of the location URI is necessary, since the policy 579 attached to such a location URI permits any who have the URI to view 580 it. This aspect of security is covered in more detail in the 581 specification of location conveyance protocols, such as 582 [I-D.ietf-sipcore-location-conveyance]. 584 The LS MUST NOT provide any information about the Target except its 585 location, unless policy from a Rule Maker allows otherwise. In 586 particular, the requirements in [RFC5808] mandate this measure to 587 protect the identity of the Target. To this end, an unlinked 588 pseudonym MUST be provided in the "entity" attribute of the PIDF-LO 589 document. 591 Further security considerations and requirements relating to the use 592 of location URIs are described in [RFC5808]. 594 7. IANA Considerations 596 This document makes no request of IANA. 598 [[IANA/RFC-EDITOR: Please remove this section before publication.]] 600 8. Acknowledgements 602 Thanks to Barbara Stark and Guy Caron for providing early comments. 603 Thanks to Rohan Mahy for constructive comments on the scope and 604 format of the document. Thanks to Ted Hardie for his strawman 605 proposal that provided assistance with the security section of this 606 document. Richard Barnes made helpful observations on the 607 application of authorization policy. Bernard Aboba and Julian 608 Reschke contributed constructive reviews. 610 The participants of the GEOPRIV interim meeting 2008 provided 611 significant feedback on this document. 613 James Polk provided input on security in June 2008. 615 9. References 617 9.1. Normative References 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, March 1997. 622 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 623 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 624 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 626 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 628 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 629 Resource Identifier (URI): Generic Syntax", STD 66, 630 RFC 3986, January 2005. 632 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 633 Format", RFC 4119, December 2005. 635 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 636 Presence Information Data Format Location Object (PIDF-LO) 637 Usage Clarification, Considerations, and Recommendations", 638 RFC 5491, March 2009. 640 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 641 RFC 5985, September 2010. 643 9.2. Informative references 645 [I-D.ietf-geopriv-arch] 646 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 647 Tschofenig, H., and H. Schulzrinne, "An Architecture for 648 Location and Location Privacy in Internet Applications", 649 draft-ietf-geopriv-arch-03 (work in progress), 650 October 2010. 652 [I-D.ietf-geopriv-dhcp-lbyr-uri-option] 653 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 654 and IPv6 Option for a Location Uniform Resource Identifier 655 (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-12 (work 656 in progress), October 2011. 658 [I-D.ietf-geopriv-policy] 659 Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., 660 Morris, J., and M. Thomson, "Geolocation Policy: A 661 Document Format for Expressing Privacy Preferences for 662 Location Information", draft-ietf-geopriv-policy-25 (work 663 in progress), October 2011. 665 [I-D.ietf-geopriv-policy-uri] 666 Barnes, R., Thomson, M., Winterbottom, J., and H. 667 Tschofenig, "Location Configuration Extensions for Policy 668 Management", draft-ietf-geopriv-policy-uri-02 (work in 669 progress), October 2011. 671 [I-D.ietf-sipcore-location-conveyance] 672 Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 673 for the Session Initiation Protocol", 674 draft-ietf-sipcore-location-conveyance-09 (work in 675 progress), September 2011. 677 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 678 A., Peterson, J., Sparks, R., Handley, M., and E. 679 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 680 June 2002. 682 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 683 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 685 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 686 Polk, J., and J. Rosenberg, "Common Policy: A Document 687 Format for Expressing Privacy Preferences", RFC 4745, 688 February 2007. 690 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 691 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 693 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 694 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 696 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 697 Location Configuration Protocol: Problem Statement and 698 Requirements", RFC 5687, March 2010. 700 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 701 Mail Extensions (S/MIME) Version 3.2 Message 702 Specification", RFC 5751, January 2010. 704 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference 705 Mechanism", RFC 5808, May 2010. 707 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 708 Barnes, "Use of Device Identity in HTTP-Enabled Location 709 Delivery (HELD)", RFC 6155, March 2011. 711 Appendix A. GEOPRIV Using Protocol Compliance 713 This section describes how use of HELD as a location dereference 714 protocol complies with the GEOPRIV requirements described in 715 [RFC3693]. 717 Req. 1. (Location Object generalities): 719 This section relates to the PIDF-LO [RFC4119] document, 720 which is used by HELD. These requirements are addressed by 721 [RFC4119] and [RFC5491]. 723 Req. 2. (Location Object fields): 725 This section relates to the PIDF-LO [RFC4119] document, 726 which is used by HELD. These requirements are addressed by 727 [RFC4119] and [RFC5491]. 729 Req. 3. (Location Data Types): 731 This section relates to the PIDF-LO [RFC4119] document, 732 which is used by HELD. These requirements are addressed by 733 [RFC4119] and [RFC5491]. 735 Section 7.2 of [RFC3693] details the requirements of a "Using 736 Protocol". These requirements are restated, followed by a statement 737 of compliance: 739 Req. 4. "The using protocol has to obey the privacy and security 740 instructions coded in the Location Object and in the 741 corresponding Rules regarding the transmission and storage 742 of the LO." 744 Compliant: This specification describes the use of HTTP over 745 TLS for carring the PIDF-LO from the LS to the Location 746 Recipient. The sending and receiving parties are expected 747 to comply with the instructions carried inside the object. 749 Though discouraged, using unsecured http: URIs is permitted. 750 Using unsecured HTTP is likely to result in non-compliance 751 with this requirement. 753 Req. 5. "The using protocol will typically facilitate that the keys 754 associated with the credentials are transported to the 755 respective parties, that is, key establishment is the 756 responsibility of the using protocol." 758 Compliant: This document specifies that authentication of 759 the LS uses the established public key infrastructure used 760 by HTTP over TLS [RFC2818]. Authentication of Location 761 Recipients is either based on distribution of a secret (the 762 location URI) using a conveyance protocol (for instance, 763 [I-D.ietf-sipcore-location-conveyance]), allowances are made 764 for later work to define alternative methods. 766 Req. 6. "(Single Message Transfer) In particular, for tracking of 767 small target devices, the design should allow a single 768 message/packet transmission of location as a complete 769 transaction." 771 Not Compliant: The XML encoding specified in [RFC4119] is 772 not suited to single packet transfers. Use of compressed 773 content encoding [RFC2616] might allow this condition to be 774 met. 776 Section 7.3 of [RFC3693] details the requirements of a "Rule based 777 Location Data Transfer". These requirements are restated where they 778 are applicable to this document: 780 Req. 7. "(LS Rules) The decision of a Location Server to provide a 781 Location Recipient access to Location Information MUST be 782 based on Rule Maker-defined Privacy Rules." 784 Compliant: This document describes two alternative methods 785 by which a Rule Maker is able to control access to location 786 information. Rule Maker policy is enforced by the LS when 787 a location URI is dereferenced. However, this document 788 does not describe how a location URI is created, or how a 789 Rule Maker associates policy with a location URI. These 790 are covered by other specifications. 792 Req. 8. (LG Rules) Not Applicable: This relationship between LS and 793 the source of its information (be that Location Generator 794 (LG) or LIS) is out of scope for this document. 796 Req. 9. "(Viewer Rules) A Viewer does not need to be aware of the 797 full Rules defined by the Rule Maker (because a Viewer 798 SHOULD NOT retransmit Location Information), and thus a 799 Viewer SHOULD receive only the subset of Privacy Rules 800 necessary for the Viewer to handle the LO in compliance 801 with the full Privacy Rules (such as, instruction on the 802 time period for which the LO can be retained)." 804 Compliant: The Rule Maker might define (via mechanisms 805 outside the scope of this document) which policy rules are 806 disclosed to other entities. For instance, if [RFC4745] is 807 used to convey authorization policies from Rule Maker to 808 LS, this is possible using the parameters specified in 809 [I-D.ietf-geopriv-policy]. 811 In order to comply with these rules, a Location Recipient 812 MUST NOT redistribute a location URI without express 813 permission. Depending on the access control model, the 814 location URI might be secret (see Section 3.3 of 815 [RFC5808]). 817 Req. 10. (Full Rule language) Not Applicable: Note however that 818 Geopriv has defined a rule language capable of expressing a 819 wide range of privacy rules (see [RFC4745] and 820 [I-D.ietf-geopriv-policy]. 822 Req. 11. (Limited Rule language) Not Applicable: This requirement 823 applies to (and is addressed by) PIDF-LO [RFC4119]. 825 Section 7.4 of [RFC3693] details the requirements of "Location Object 826 Privacy and Security". These requirements are restated where they 827 are applicable to this document: 829 Req. 12. (Identity Protection) Compliant: Identity protection of the 830 Target is provided as long as both of the following 831 conditions are true: 833 (a) the location URI is not associated with the identity 834 of the Target in any context, and 836 (b) the PIDF-LO does not contain information about the 837 identity of the Target. 839 For instance, this requirement is complied with if the 840 protocol that conveys the location URI does not link the 841 identity of the Target to the location URI and the LS 842 doesn't include meaningful identification information in 843 the PIDF-LO document. Section 6 recommends that an 844 unlinked pseudonym is used by the LS. 846 Req. 13. (Credential Requirements) Compliant: The primary security 847 mechanism specified in this document is Transport Layer 848 Security. TLS offers the ability to use different types of 849 credentials, including symmetric, asymmetric credentials or 850 a combination of them. 852 Req. 14. (Security Features) Compliant: Geopriv defines a few 853 security requirements for the protection of Location 854 Objects such as mutual end-point authentication, data 855 object integrity, data object confidentiality and replay 856 protection. The ability to use Transport Layer security 857 fulfills most of these requirements. Authentication of 858 Location Recipients in this document relies on proof of a 859 shared secret - the location URI. This does not preclude 860 the addition of more robust authentication procedures. 862 Req. 15. (Minimal Crypto) Compliant: The mandatory to implement 863 ciphersuite is provided in the TLS layer security 864 specification. 866 Appendix B. Compliance to Location Reference Requirements 868 This section describes how HELD complies to the location reference 869 requirements stipulated in [RFC5808]. Compliance of [RFC5985] to the 870 Location Configuration Protocol is included. 872 Note that use of HELD as a location dereference protocol does not 873 necessarily imply that HELD is the corresponding LCP. This 874 document is still applicable to HTTP location URIs that are 875 acquired by other means. 877 B.1. Requirements for a Location Configuration Protocol 879 C1. "Location URI support: The location configuration protocol MUST 880 support a location reference in URI form." 882 Compliant: HELD only provides location references in URI form. 884 C2. "Location URI expiration: When a location URI has a limited 885 validity interval, its lifetime MUST be indicated." 887 Compliant: HELD indicates the expiry time of location URIs using 888 the "expires" attribute. [I-D.ietf-geopriv-policy-uri] provides 889 a way to control expiration of a location URI. 891 C3. "Location URI cancellation: The location configuration protocol 892 MUST support the ability to request a cancellation of a specific 893 location URI." 895 Compliant with Extension: [I-D.ietf-geopriv-policy-uri] 896 describes how a location URI can be cancelled through the 897 application of policy. Without extensions, HELD does not 898 provide a method for cancelling location URIs. 900 C4. "Location Information Masking: The location URI MUST ensure, by 901 default, through randomization and uniqueness, that the location 902 URI does not contain location information specific components." 904 Compliant: The HELD specification explicitly references this 905 requirement in providing guidance on the format of the location 906 URI. 908 C5. "Target Identity Protection: The location URI MUST NOT contain 909 information that identifies the Target (e.g., user or device)." 911 Compliant: The HELD specification provides specific guidance on 912 the anonymity of the Target with regards to the generation of 913 location URIs. Section 6 expands on this guidance. 915 C6. "Reuse indicator: There SHOULD be a way to allow a Target to 916 control whether a location URI can be resolved once only, or 917 multiple times." 919 Not Compliant: Specific extensions to the protocol or 920 authorization policy formats is needed to alter the default 921 behavior, which allows unlimited resolution of the location URI. 923 C7. "Selective disclosure: The location configuration protocol MUST 924 provide a mechanism that allows the Rule Maker to control what 925 information is being disclosed about the Target." 927 Compliant with Extension: Use of policy mechanisms and 928 [I-D.ietf-geopriv-policy-uri] enable this capability. Note that 929 this document recommends that only location information be 930 provided. 932 C8. "Location URI Not guessable: As a default, the location 933 configuration protocol MUST return location URIs that are random 934 and unique throughout the indicated lifetime. A location URI 935 with 128-bits of randomness is RECOMMENDED." 937 Compliant: HELD specifies that location URIs conform to this 938 requirement. The amount of randomness is not specifically 939 identified since it depends on a number of factors that change 940 over time, such as the number of valid location URIs, the 941 validity period of those URIs and the rate that guesses can be 942 made. 944 C9. "Location URI Options: In the case of user-provided 945 authorization policies, where anonymous or non-guessable 946 location URIs are not warranted, the location configuration 947 protocol MAY support a variety of optional location URI 948 conventions, as requested by a Target to a location 949 configuration server, (e.g., embedded location information 950 within the location URI)." 952 Not Compliant: HELD does not support Device-specified location 953 URI forms. 955 B.2. Requirements for a Location Dereference Protocol 957 D1. "Location URI support: The location dereference protocol MUST 958 support a location reference in URI form." 960 Compliant: HELD only provides location references in URI form. 962 D2. "Authentication: The location dereference protocol MUST include 963 mechanisms to authenticate both the client and the server." 965 Partially Compliant: TLS provides means for mutual 966 authentication. This document only specifies the required 967 mechanism for server authentication. Client authentication is 968 not precluded. 970 D3. "Dereferenced Location Form: The value returned by the 971 dereference protocol MUST contain a well-formed PIDF-LO 972 document." 974 Compliant: HELD requires that location objects are in the form 975 of a PIDF-LO that complies with [RFC5491]. 977 D4. "Location URI Repeated Use: The location dereference protocol 978 MUST support the ability for the same location URI to be 979 resolved more than once, based on dereference server 980 configuration." 982 Compliant: A Location Recipient may access and use a location 983 URI as many times as desired until URI expiration results in the 984 URI being invalidated. Authorization policies might include 985 rules that modify this behavior. 987 D5. "The location dereference protocol MUST support confidentiality 988 protection of messages sent between the Location Recipient and 989 the location server." 991 Compliant: This document strongly recommends the use of TLS for 992 confidentiality and HELD mandates its implementation. Unsecured 993 HTTP is permitted: the associated risks are described in 994 Section 4. 996 Authors' Addresses 998 James Winterbottom 999 Commscope 1000 Andrew Building (39) 1001 Wollongong University Campus 1002 Northfields Avenue 1003 Wollongong, NSW 2522 1004 AU 1006 Phone: +61 242 212938 1007 Email: james.winterbottom@commscope.com 1009 Hannes Tschofenig 1010 Nokia Siemens Networks 1011 Linnoitustie 6 1012 Espoo 02600 1013 Finland 1015 Phone: +358 (50) 4871445 1016 Email: Hannes.Tschofenig@gmx.net 1017 URI: http://www.tschofenig.priv.at 1019 Henning Schulzrinne 1020 Columbia University 1021 Department of Computer Science 1022 450 Computer Science Building, New York, NY 10027 1023 US 1025 Phone: +1 212 939 7004 1026 Email: hgs@cs.columbia.edu 1027 URI: http://www.cs.columbia.edu 1028 Martin Thomson 1029 Commscope 1030 Andrew Building (39) 1031 Wollongong University Campus 1032 Northfields Avenue 1033 Wollongong, NSW 2522 1034 AU 1036 Phone: +61 2 4221 2915 1037 Email: martin.thomson@commscope.com 1039 Martin Dawson 1040 Commscope 1041 Andrew Building (39) 1042 Wollongong University Campus 1043 Northfields Avenue 1044 Wollongong, NSW 2522 1045 AU 1047 Phone: +61 2 4221 2992 1048 Email: martin.dawson@commscope.com