idnits 2.17.00 (12 Aug 2021) /tmp/idnits4874/draft-ietf-geopriv-deref-protocol-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 8, 2012) is 3664 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) == Unused Reference: 'RFC3986' is defined on line 603, but no explicit reference was found in the text ** 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: A later version (-19) exists of draft-ietf-geopriv-dhcp-lbyr-uri-option-14 == 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 -- 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 (~~), 5 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: November 9, 2012 Nokia Siemens Networks 6 H. Schulzrinne 7 Columbia University 8 M. Thomson 9 (Unaffiliated) 10 May 8, 2012 12 A Location Dereferencing Protocol Using HELD 13 draft-ietf-geopriv-deref-protocol-05 15 Abstract 17 This document describes how to use the Hypertext Transfer Protocol 18 (HTTP) over Transport Layer Security (TLS) as a dereferencing 19 protocol to resolve a reference to a Presence Information Data Format 20 Location Object (PIDF-LO). The document assumes that a Location 21 Recipient possesses a URI that can be used in conjunction with the 22 HTTP-Enabled Location Delivery (HELD) protocol to request the 23 location of the Target. 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 November 9, 2012. 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 4 62 3.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 4 63 3.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 5 64 4. Authorization Models . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Authorization by Possession . . . . . . . . . . . . . . . 7 66 4.2. Authorization via Access Control . . . . . . . . . . . . . 8 67 4.3. Access Control with HELD Deference . . . . . . . . . . . . 8 68 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 74 9.2. Informative references . . . . . . . . . . . . . . . . . . 15 75 Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 16 76 Appendix B. Compliance to Location Reference Requirements . . . . 19 77 B.1. Requirements for a Location Configuration Protocol . . . . 20 78 B.2. Requirements for a Location Dereference Protocol . . . . . 21 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 81 1. Introduction 83 A location URI [RFC5808] identifies a resource that contains the 84 location of an entity. This document specifies how a holder of an 85 "http:" or "https:" location URI uses that URI to retrieve location 86 information. 88 A location URI can be acquired using a location configuration 89 protocol, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] or 90 the Dynamic Host Configuration Protocol (DHCP) location URI option 91 [I-D.ietf-geopriv-dhcp-lbyr-uri-option]. 93 A Location Recipient that dereferences a location URI acquires 94 location information in the of a Presence Information Data Format - 95 Location Object (PIDF-LO) document [RFC4119]. HELD parameters allow 96 for specifying the type of location information, though some 97 constraints are placed on allowable parameters. 99 Location URIs compatible with HELD dereferencing use the "https:" or 100 "http:" scheme. HELD can be used by Location Recipients that are 101 aware of the fact that the URI is a location URI. Mandatory support 102 for an HTTP GET request ensures that the URI can be used even if it 103 is not recognized as a location URI. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 This document uses key terminology from several sources: 113 o terms for the GEOPRIV reference model defined in [RFC6280]; 115 o the term Location Information Server (LIS), from [RFC5687], is a 116 node in the access network that provides location information to 117 an end point; a LIS provides location URIs; 119 o the term Location Server (LS), from [RFC6280], is used to identify 120 the role that responds to a location dereference request; this 121 might be the same entity as the LIS, but the model in [RFC5808] 122 allows for the existence of separate - but related - entities; and 124 o the term location URI is coined in [RFC5808]. 126 3. HELD Dereference Protocol 128 This section describes how HELD can be used to dereference a location 129 URI. This process can be applied when a Location Recipient is in 130 possession of a location URI with a "https:" or "http:" URI scheme. 132 This document does not describe a specific authentication mechanism. 133 This means that authorization policies are unable to specifically 134 identify authorized Location Recipients. 136 A Location Recipient that wishes to dereference an "https:" or 137 "http:" URI performs a HELD request on HTTP to the identified 138 resource. 140 Note: In many cases, an "http:" URI does not provide sufficient 141 security for location URIs. The absence of the security 142 mechanisms provided by TLS means that the Rule Maker has no 143 control over who receives location information and the Location 144 Recipient has no assurance that the information is correct. 146 The Location Recipient establishes a connection to the LS, as 147 described in [RFC2818]. 149 TLS SHOULD be used. When TLS is used, the TLS ciphersuite 150 TLS_NULL_WITH_NULL_NULL MUST NOT be used and the LS MUST be 151 authenticated [RFC6125] to ensure that the correct server is 152 contacted. 154 A Location Server MAY reject a request and request that a Location 155 Recipient provide authentication credentials if authorization is 156 dependent on the Location Recipient identity. Future specifications 157 could define an authentication mechanism and a means by which 158 Location Recipients are identified in authorization policies. This 159 document provides definitions for neither item. 161 3.1. HELD Usage Profile 163 Use of HELD as a location dereference protocol is largely the same as 164 its use as a location configuration protocol. Aside from the 165 restrictions noted in this document, HELD semantics do not differ 166 from those established in [RFC5985]. 168 The HELD "locationRequest" is the only request permitted by this 169 specification. Similarly, request parameters other than the 170 following MUST NOT be accepted by the LS: "responseTime", 171 "locationType" (including the associated "exact" attribute). 173 Parameters and requests that do not have known behaviour for 174 dereference requests MUST NOT be used. The LS MUST ignore any 175 parameters that it does not understand unless it knows the parameters 176 to be invalid. If parameters are understood by the LS and known to 177 be invalid, the LS MAY generate a HELD error response. For instance, 178 those defined in [RFC6155] are always invalid and can be rejected. 180 The LS MUST NOT generate location URIs or provide a "locationUriSet" 181 in response to a dereference request. If the location request 182 contains a "locationType" element that includes "locationURI", this 183 parameter is either ignored or rejected as appropriate, based on the 184 associated "exact" attribute. 186 3.2. HTTP GET Behavior 188 GET is the method assumed by generic HTTP user agents, therefore 189 unless context identifies an "https:" URI as a HELD URI, such a user 190 agent might simply send an HTTP GET. Rather than providing an HTTP 191 405 (Method Not Allowed) response indicating that POST is the only 192 permitted method, a LIS MUST provide a HELD location response if it 193 receives an HTTP GET request. 195 An HTTP GET request to a HELD URI produces a HELD response as if the 196 following HELD request had been sent using HTTP POST: 198 199 200 geodetic civic 201 202 204 Figure 1: GET Request Equivalent Location Request 206 HTTP GET requests MUST be safe and idempotent [RFC2616] - that is, 207 there are no side-effects of making the request and a repeated 208 request has no more effect than a single request. Repeating a HELD 209 request might result in a different location, but only as a result of 210 a change in the state of the resource: the location of the Target. 212 Only the creation of a location URI as a result of receiving a 213 request causes a HELD request to have side-effects. A request to a 214 location URI can be both safe and idempotent, since a location URI 215 cannot be produced in response to a request to a location URI. 217 A Location Recipient MAY infer from a response containing the HELD 218 content type, "application/held+xml", that a URI references a 219 resource that supports HELD. 221 Content negotiation MAY be supported to produce a presence document 222 in place of a HELD location response. Where the presence document 223 would otherwise be included in a "locationResponse" document, it can 224 be included in the body of the HTTP response directly by including an 225 "Accept" header that includes "application/pidf+xml". 227 4. Authorization Models 229 This section discusses two extreme types of authorization models for 230 dereferencing with HELD URIs, namely "Authorization by Possession" 231 and "Authorization by Access Control". In the subsequent subsections 232 we discuss the properties of these two models. Figure 2, from 233 [RFC5808], shows the model applicable to location configuration, 234 conveyance and dereference. 236 +---------+--------+ Location +-----------+ 237 | | | Dereference | Location | 238 | LIS - LS +---------------+ Recipient | 239 | | | Protocol | | 240 +----+----+--------+ (3) +-----+-----+ 241 | `. | 242 | Policy `. | 243 Location | Exchange `. | 244 Configuration | (*) | | 245 Protocol | +----+----+ | 246 (1) | | Rule | Location | 247 | | Maker | Conveyance | 248 +-----+----+ +---------+ Protocol | 249 | | (2) | 250 | Target +------------------------------+ 251 | | 252 +----------+ 254 Figure 2: Communication Model 256 It is important to note that this document does not mandate a 257 specific authorization model. It is possible to combine aspects of 258 both models. However, no authentication framework is provided, which 259 limits the policy options available when the "Authorization by Access 260 Control" model is used. 262 For either authorization model, the overall process is similar. The 263 following steps are followed, with minor alterations: 265 1. The Target acquires a location URI from the LIS. This uses a 266 location configuration protocol (LCP), such as HELD or DHCP. 268 2. The Target then conveys the location URI to a third party, the 269 Location Recipient (for example using SIP as described in 270 [RFC6442]). This step is shown in (2) of Figure 2. 272 3. The Location Recipient then needs to dereference the location URI 273 in order to obtain the Location Object (3). An "https:" or 274 "http:" URI is dereferenced as described in this document; other 275 URI schemes might be dereferenced using another method. 277 In this final step, the Location Server (LS) or LIS makes an 278 authorization decision. How this decision is reached depends on the 279 authorization model. 281 4.1. Authorization by Possession 283 In this model, possession - or knowledge - of the location URI is 284 used to control access to location information. A location URI is 285 constructed such that it is hard to guess (see C8 of [RFC5808]) and 286 the set of entities that it is disclosed to is limited. The only 287 authentication required by the LS is evidence of possession of the 288 URI. The LS is able to immediately authorize any request that 289 indicates this URI. 291 Authorization by possession uses a very simple policy that does not 292 typically require direct interaction with a Rule Maker; it is assumed 293 that the Rule Maker is able to exert control over the distribution of 294 the location URI. Therefore, the LIS can operate with limited policy 295 input from a Rule Maker. 297 Limited disclosure is an important aspect of this authorization 298 model. The location URI is a secret; therefore, ensuring that 299 adversaries are not able to acquire this information is paramount. 300 Encryption, such as might be offered by TLS [RFC5246] or S/MIME 301 [RFC5751], protects the information from eavesdroppers. 303 Use of authorization by possession location URIs in a hop-by-hop 304 protocol such as SIP [RFC3261] adds the possibility of on-path 305 adversaries. Depending on the usage of the location URI for certain 306 location based applications (e.g., emergency services, location based 307 routing) specific treatment is important, as discussed in [RFC6442]. 309 Using possession as a basis for authorization means that, once 310 granted, authorization cannot be easily revoked. Cancellation of a 311 location URI ensures that legitimate users are also affected; 312 application of additional policy is theoretically possible, but could 313 be technically infeasible. Expiration of location URIs limits the 314 usable time for a location URI, requiring that an attacker continue 315 to learn new location URIs to retain access to current location 316 information. 318 A very simple policy is established at the time that a location URI 319 is created. This policy specifies that the location URI expires 320 after a certain time, which limits any inadvertent exposure of 321 location information to adversaries. The expiration time of the 322 location URI might be negotiated at the time of its creation, or it 323 might be unilaterally set by the LIS. 325 4.2. Authorization via Access Control 327 Use of explicit access control provides a Rule Maker greater control 328 over the behaviour of an LS. In contrast to authorization by 329 possession, possession of this form of location URI does not imply 330 authorization. Since an explicit policy is used to authorize access 331 to location information, the location URI can be distributed to many 332 potential Location Recipients. 334 Either before creation or dissemination of the location URI, the Rule 335 Maker establishes an authorization policy with the LS. In reference 336 to Figure 2, authorization policies might be established at creation 337 (Step 1), and need to be established before the location URI is 338 published (Step 2) to ensure that the policy grants access to the 339 desired Location Recipients. Depending on the mechanism used, it 340 might also be possible to change authorization policies at any time. 342 A possible format for these authorization policies is available with 343 GEOPRIV Common Policy [RFC4745] and Geolocation Policy 344 [I-D.ietf-geopriv-policy]. Additional constraints might be 345 established by other means. 347 The LS enforces the authorization policy when a Location Recipient 348 dereferences the URI. Explicit authorization policies allow a Rule 349 Maker to specify how location information is provided to Location 350 Recipients. 352 4.3. Access Control with HELD Deference 354 This document does not describe a specific authentication mechanism; 355 therefore, the authorization by access control model is not an 356 option. Instead, this document assumes the authorization by 357 possession model. 359 Other policy mechanisms, such as those described in 360 [I-D.ietf-geopriv-policy], can be applied for different Location 361 Recipients if each recipient is given a different location URIs. 362 Each location URI can be assigned different authorization policy. 363 Selective disclosure used in this fashion can be used in place of 364 identity-based authorization. 366 How policy is associated with a location URI is not defined by this 367 document. [I-D.ietf-geopriv-policy-uri] describes one possible 368 mechanism. 370 Use of identity-based authorization policy is not precluded. A 371 Location Server MAY support an authentication mechanism that enables 372 identity-based authorization policies to be used. Future 373 specifications might define means of identifying recipients. 375 Note: Policy frameworks like [RFC4745] degrade in a way that 376 protects privacy if features are not supported. If a policy 377 specifies a rule that is conditional on the identity of a 378 recipient and the protocol does not (or cannot) provide an 379 assertion identity of the recipient, the rule has no effect and 380 the policy defaults to providing less information. 382 5. Examples 384 An example scenario envisioned by this document is shown in Figure 3. 385 This diagram shows how a location dereference protocol fits with 386 location configuration and conveyance. [RFC5808] contains more 387 information on this scenario and others like it. 389 +-------------+ 390 +------------+ | Location | +-----------+ 391 | End Device | | Information | | Location | 392 | (Target) | | Server | | Recipient | 393 +-----+------+ +------+------+ +-----+-----+ 394 | | | 395 .- + - - - - - - - - - - - - + -. | 396 : | locationRequest | : | 397 . |----(for location URI)-->| . | 398 : | | : Location | 399 . | locationResponse | . Configuration | 400 : |<-----(location URI)-----| : | 401 . | | . | 402 `- + - - - - - - - - - - - - + -' | 403 | | | 404 | Location Conveyance | 405 |~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>| 406 | | | 407 | .- + - - - - - - - - - - - - + -. 408 | : | locationRequest | : 409 | . |<------(for civic)-------| . 410 | Dereferencing : | | : 411 | . | locationResponse | . 412 | : |--------(PIDF-LO)------->| : 413 | . | | . 414 | `- + - - - - - - - - - - - - + -' 415 | | | 417 Figure 3: Example of Dereference Protocol Exchange 419 The example in Figure 4 shows the simplest form of dereferencing 420 request using HELD to the location URI 421 "https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that 422 this differs from the example in Section 10.1 of [RFC5985] is in the 423 request URI and the source of the URI. 425 POST /uri/w3g61nf5n66p0 HTTP/1.1 426 Host: ls.example.com:49152 427 Content-Type: application/held+xml 428 Content-Length: 87 430 431 433 Figure 4: Minimal Dereferencing Request 435 Figure 5 shows the response to the previous request listing both 436 civic and geodetic location information of the Target's location. 438 Again, this is identical to the response in Section 10.1 of [RFC5985] 439 - unless policy specifies otherwise, the Location Recipient receives 440 the same information as the Device. 442 HTTP/1.1 200 OK 443 Server: Example LIS 444 Date: Mon, 10 Jan 2011 03:42:29 GMT 445 Expires: Tue, 11 Jan 2011 03:42:29 GMT 446 Cache-control: private 447 Content-Type: application/held+xml 448 Content-Length: 676 450 451 452 454 455 456 458 459 461 -34.407 150.88001 462 463 464 465 466 false 467 468 2011-01-11T03:42:29+00:00 469 470 Wiremap 471 472 473 2006-01-10T03:42:28+00:00 474 475 476 478 Figure 5: Response with Location Information 480 The following GET request is treated in an equivalent fashion. The 481 LS treats this request as though it were a location request of the 482 form shown in Figure 1. The same response might be provided. 484 GET /uri/w3g61nf5n66p0 HTTP/1.1 485 Host: ls.example.com:49152 486 Accept: application/held+xml 488 Figure 6: GET Request 490 The following GET request uses content negotiation to indicate a 491 preference for a presence document. 493 GET /uri/w3g61nf5n66p0 HTTP/1.1 494 Host: ls.example.com:49152 495 Accept: application/pidf+xml,application/held+xml;q=0.5 497 Figure 7: GET Request with Content Negotiation 499 The response only differs from a normal HELD location response to a 500 POST request in that the "locationResponse" element is omitted and 501 the "Content-Type" header reflects the changed content. 503 HTTP/1.1 200 OK 504 Server: Example LIS 505 Date: Mon, 10 Jan 2011 03:42:29 GMT 506 Expires: Tue, 11 Jan 2011 03:42:29 GMT 507 Cache-control: private 508 Content-Type: application/pidf+xml 509 Content-Length: 591 511 512 514 515 517 Figure 8: GET Response with PIDF-LO 519 6. Security Considerations 521 Privacy of location information is the most important security 522 consideration for this document. Two measures in particular are used 523 to protect privacy: TLS and authorization policies. TLS provides a 524 means of ensuring confidentiality of location information through 525 encryption and mutual authentication. An authorization policy allows 526 a Rule Maker to explicitly control how location information is 527 provided to Location Recipients. 529 The process by which a Rule Maker establishes an authorization policy 530 is not covered by this document; several methods are possible, for 531 instance: [I-D.ietf-geopriv-policy-uri], [RFC4825]. 533 Use of TLS for the dereferencing of location URIs is strongly 534 RECOMMENDED, as discussed in Section 3. Location Recipients MUST 535 authenticate the host identity using the domain name included in the 536 location URI, using the procedure described in Section 3.1 of 537 [RFC2818]. Local policy determines what a Location Recipient does if 538 authentication fails or cannot be attempted. 540 The authorization by possession model (Section 4.1) further relies on 541 TLS when transmitting the location URI to protect the secrecy of the 542 URI. Possession of such a URI implies the same privacy 543 considerations as possession of the PIDF-LO document that the URI 544 references. 546 Location URIs MUST only be disclosed to authorized Location 547 Recipients. The GEOPRIV architecture [RFC6280] identifies the Rule 548 Maker role as being the entity that authorizes disclosure of this 549 nature. 551 Protection of the location URI is necessary, since the policy 552 attached to such a location URI permits any who have the URI to view 553 it. This aspect of security is covered in more detail in the 554 specification of location conveyance protocols, such as [RFC6442]. 556 The LS MUST NOT provide any information about the Target except its 557 location, unless policy from a Rule Maker allows otherwise. In 558 particular, the requirements in [RFC5808] mandate this measure to 559 protect the identity of the Target. To this end, an unlinked 560 pseudonym MUST be provided in the "entity" attribute of the PIDF-LO 561 document. 563 Further security considerations and requirements relating to the use 564 of location URIs are described in [RFC5808]. 566 7. IANA Considerations 568 This document makes no request of IANA. 570 [[IANA/RFC-EDITOR: Please remove this section before publication.]] 572 8. Acknowledgements 574 Thanks to Barbara Stark and Guy Caron for providing early comments. 575 Thanks to Rohan Mahy for constructive comments on the scope and 576 format of the document. Thanks to Ted Hardie for his strawman 577 proposal that provided assistance with the security section of this 578 document. Richard Barnes made helpful observations on the 579 application of authorization policy. Bernard Aboba and Julian 580 Reschke contributed constructive reviews. 582 The participants of the GEOPRIV interim meeting 2008 provided 583 significant feedback on this document. 585 James Polk provided input on security in June 2008. 587 Martin Dawson was an original author of this document. Sadly, he 588 passed away prior to its publication. 590 9. References 592 9.1. Normative References 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, March 1997. 597 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 598 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 599 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 601 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 603 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 604 Resource Identifier (URI): Generic Syntax", STD 66, 605 RFC 3986, January 2005. 607 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 608 Format", RFC 4119, December 2005. 610 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 611 Presence Information Data Format Location Object (PIDF-LO) 612 Usage Clarification, Considerations, and Recommendations", 613 RFC 5491, March 2009. 615 [RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", 616 RFC 5985, September 2010. 618 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 619 Verification of Domain-Based Application Service Identity 620 within Internet Public Key Infrastructure Using X.509 621 (PKIX) Certificates in the Context of Transport Layer 622 Security (TLS)", RFC 6125, March 2011. 624 9.2. Informative references 626 [I-D.ietf-geopriv-dhcp-lbyr-uri-option] 627 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 628 and IPv6 Option for a Location Uniform Resource Identifier 629 (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-14 (work 630 in progress), March 2012. 632 [I-D.ietf-geopriv-policy] 633 Cuellar, J., Tschofenig, H., Schulzrinne, H., Polk, J., 634 Morris, J., and M. Thomson, "Geolocation Policy: A 635 Document Format for Expressing Privacy Preferences for 636 Location Information", draft-ietf-geopriv-policy-25 (work 637 in progress), October 2011. 639 [I-D.ietf-geopriv-policy-uri] 640 Thomson, M., Winterbottom, J., Barnes, R., and H. 641 Tschofenig, "Location Configuration Extensions for Policy 642 Management", draft-ietf-geopriv-policy-uri-04 (work in 643 progress), November 2011. 645 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 646 A., Peterson, J., Sparks, R., Handley, M., and E. 647 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 648 June 2002. 650 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 651 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 653 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 654 Polk, J., and J. Rosenberg, "Common Policy: A Document 655 Format for Expressing Privacy Preferences", RFC 4745, 656 February 2007. 658 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 659 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 661 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 662 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 664 [RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 665 Location Configuration Protocol: Problem Statement and 666 Requirements", RFC 5687, March 2010. 668 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 669 Mail Extensions (S/MIME) Version 3.2 Message 670 Specification", RFC 5751, January 2010. 672 [RFC5808] Marshall, R., "Requirements for a Location-by-Reference 673 Mechanism", RFC 5808, May 2010. 675 [RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. 676 Barnes, "Use of Device Identity in HTTP-Enabled Location 677 Delivery (HELD)", RFC 6155, March 2011. 679 [RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., 680 Tschofenig, H., and H. Schulzrinne, "An Architecture for 681 Location and Location Privacy in Internet Applications", 682 BCP 160, RFC 6280, July 2011. 684 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 685 for the Session Initiation Protocol", RFC 6442, 686 December 2011. 688 Appendix A. GEOPRIV Using Protocol Compliance 690 This section describes how use of HELD as a location dereference 691 protocol complies with the GEOPRIV requirements described in 692 [RFC3693]. 694 Req. 1. (Location Object generalities): 696 This section relates to the PIDF-LO [RFC4119] document, 697 which is used by HELD. These requirements are addressed by 698 [RFC4119] and [RFC5491]. 700 Req. 2. (Location Object fields): 702 This section relates to the PIDF-LO [RFC4119] document, 703 which is used by HELD. These requirements are addressed by 704 [RFC4119] and [RFC5491]. 706 Req. 3. (Location Data Types): 708 This section relates to the PIDF-LO [RFC4119] document, 709 which is used by HELD. These requirements are addressed by 710 [RFC4119] and [RFC5491]. 712 Section 7.2 of [RFC3693] details the requirements of a "Using 713 Protocol". These requirements are restated, followed by a statement 714 of compliance: 716 Req. 4. "The using protocol has to obey the privacy and security 717 instructions coded in the Location Object and in the 718 corresponding Rules regarding the transmission and storage 719 of the LO." 721 Compliant: This specification describes the use of HTTP over 722 TLS for carring the PIDF-LO from the LS to the Location 723 Recipient. The sending and receiving parties are expected 724 to comply with the instructions carried inside the object. 726 Though discouraged, using unsecured http: URIs is permitted. 727 Using unsecured HTTP is likely to result in non-compliance 728 with this requirement. 730 Req. 5. "The using protocol will typically facilitate that the keys 731 associated with the credentials are transported to the 732 respective parties, that is, key establishment is the 733 responsibility of the using protocol." 735 Compliant: This document specifies that authentication of 736 the LS uses the established public key infrastructure used 737 by HTTP over TLS [RFC2818]. Authentication of Location 738 Recipients is either based on distribution of a secret (the 739 location URI) using a conveyance protocol (for instance, 740 [RFC6442]), allowances are made for later work to define 741 alternative methods. 743 Req. 6. "(Single Message Transfer) In particular, for tracking of 744 small target devices, the design should allow a single 745 message/packet transmission of location as a complete 746 transaction." 748 Not Compliant: The XML encoding specified in [RFC4119] is 749 not suited to single packet transfers. Use of compressed 750 content encoding [RFC2616] might allow this condition to be 751 met. 753 Section 7.3 of [RFC3693] details the requirements of a "Rule based 754 Location Data Transfer". These requirements are restated where they 755 are applicable to this document: 757 Req. 7. "(LS Rules) The decision of a Location Server to provide a 758 Location Recipient access to Location Information MUST be 759 based on Rule Maker-defined Privacy Rules." 761 Compliant: This document describes two alternative methods 762 by which a Rule Maker is able to control access to location 763 information. Rule Maker policy is enforced by the LS when 764 a location URI is dereferenced. However, this document 765 does not describe how a location URI is created, or how a 766 Rule Maker associates policy with a location URI. These 767 are covered by other specifications. 769 Req. 8. (LG Rules) Not Applicable: This relationship between LS and 770 the source of its information (be that Location Generator 771 (LG) or LIS) is out of scope for this document. 773 Req. 9. "(Viewer Rules) A Viewer does not need to be aware of the 774 full Rules defined by the Rule Maker (because a Viewer 775 SHOULD NOT retransmit Location Information), and thus a 776 Viewer SHOULD receive only the subset of Privacy Rules 777 necessary for the Viewer to handle the LO in compliance 778 with the full Privacy Rules (such as, instruction on the 779 time period for which the LO can be retained)." 781 Compliant: The Rule Maker might define (via mechanisms 782 outside the scope of this document) which policy rules are 783 disclosed to other entities. For instance, if [RFC4745] is 784 used to convey authorization policies from Rule Maker to 785 LS, this is possible using the parameters specified in 786 [I-D.ietf-geopriv-policy]. 788 In order to comply with these rules, a Location Recipient 789 MUST NOT redistribute a location URI without express 790 permission. Depending on the access control model, the 791 location URI might be secret (see Section 3.3 of 792 [RFC5808]). 794 Req. 10. (Full Rule language) Not Applicable: Note however that 795 Geopriv has defined a rule language capable of expressing a 796 wide range of privacy rules (see [RFC4745] and 797 [I-D.ietf-geopriv-policy]. 799 Req. 11. (Limited Rule language) Not Applicable: This requirement 800 applies to (and is addressed by) PIDF-LO [RFC4119]. 802 Section 7.4 of [RFC3693] details the requirements of "Location Object 803 Privacy and Security". These requirements are restated where they 804 are applicable to this document: 806 Req. 12. (Identity Protection) Compliant: Identity protection of the 807 Target is provided as long as both of the following 808 conditions are true: 810 (a) the location URI is not associated with the identity 811 of the Target in any context, and 813 (b) the PIDF-LO does not contain information about the 814 identity of the Target. 816 For instance, this requirement is complied with if the 817 protocol that conveys the location URI does not link the 818 identity of the Target to the location URI and the LS 819 doesn't include meaningful identification information in 820 the PIDF-LO document. Section 6 recommends that an 821 unlinked pseudonym is used by the LS. 823 Req. 13. (Credential Requirements) Compliant: The primary security 824 mechanism specified in this document is Transport Layer 825 Security. TLS offers the ability to use different types of 826 credentials, including symmetric, asymmetric credentials or 827 a combination of them. 829 Req. 14. (Security Features) Compliant: Geopriv defines a few 830 security requirements for the protection of Location 831 Objects such as mutual end-point authentication, data 832 object integrity, data object confidentiality and replay 833 protection. The ability to use Transport Layer security 834 fulfills most of these requirements. Authentication of 835 Location Recipients in this document relies on proof of a 836 shared secret - the location URI. This does not preclude 837 the addition of more robust authentication procedures. 839 Req. 15. (Minimal Crypto) Compliant: The mandatory to implement 840 ciphersuite is provided in the TLS layer security 841 specification. 843 Appendix B. Compliance to Location Reference Requirements 845 This section describes how HELD complies to the location reference 846 requirements stipulated in [RFC5808]. Compliance of [RFC5985] to the 847 Location Configuration Protocol is included. 849 Note that use of HELD as a location dereference protocol does not 850 necessarily imply that HELD is the corresponding LCP. This 851 document is still applicable to HTTP location URIs that are 852 acquired by other means. 854 B.1. Requirements for a Location Configuration Protocol 856 C1. "Location URI support: The location configuration protocol MUST 857 support a location reference in URI form." 859 Compliant: HELD only provides location references in URI form. 861 C2. "Location URI expiration: When a location URI has a limited 862 validity interval, its lifetime MUST be indicated." 864 Compliant: HELD indicates the expiry time of location URIs using 865 the "expires" attribute. [I-D.ietf-geopriv-policy-uri] provides 866 a way to control expiration of a location URI. 868 C3. "Location URI cancellation: The location configuration protocol 869 MUST support the ability to request a cancellation of a specific 870 location URI." 872 Compliant with Extension: [I-D.ietf-geopriv-policy-uri] 873 describes how a location URI can be cancelled through the 874 application of policy. Without extensions, HELD does not 875 provide a method for cancelling location URIs. 877 C4. "Location Information Masking: The location URI MUST ensure, by 878 default, through randomization and uniqueness, that the location 879 URI does not contain location information specific components." 881 Compliant: The HELD specification explicitly references this 882 requirement in providing guidance on the format of the location 883 URI. 885 C5. "Target Identity Protection: The location URI MUST NOT contain 886 information that identifies the Target (e.g., user or device)." 888 Compliant: The HELD specification provides specific guidance on 889 the anonymity of the Target with regards to the generation of 890 location URIs. Section 6 expands on this guidance. 892 C6. "Reuse indicator: There SHOULD be a way to allow a Target to 893 control whether a location URI can be resolved once only, or 894 multiple times." 896 Not Compliant: Specific extensions to the protocol or 897 authorization policy formats is needed to alter the default 898 behavior, which allows unlimited resolution of the location URI. 900 C7. "Selective disclosure: The location configuration protocol MUST 901 provide a mechanism that allows the Rule Maker to control what 902 information is being disclosed about the Target." 904 Compliant with Extension: Use of policy mechanisms and 905 [I-D.ietf-geopriv-policy-uri] enable this capability. Note that 906 this document recommends that only location information be 907 provided. 909 C8. "Location URI Not guessable: As a default, the location 910 configuration protocol MUST return location URIs that are random 911 and unique throughout the indicated lifetime. A location URI 912 with 128-bits of randomness is RECOMMENDED." 914 Compliant: HELD specifies that location URIs conform to this 915 requirement. The amount of randomness is not specifically 916 identified since it depends on a number of factors that change 917 over time, such as the number of valid location URIs, the 918 validity period of those URIs and the rate that guesses can be 919 made. 921 C9. "Location URI Options: In the case of user-provided 922 authorization policies, where anonymous or non-guessable 923 location URIs are not warranted, the location configuration 924 protocol MAY support a variety of optional location URI 925 conventions, as requested by a Target to a location 926 configuration server, (e.g., embedded location information 927 within the location URI)." 929 Not Compliant: HELD does not support Device-specified location 930 URI forms. 932 B.2. Requirements for a Location Dereference Protocol 934 D1. "Location URI support: The location dereference protocol MUST 935 support a location reference in URI form." 937 Compliant: HELD only provides location references in URI form. 939 D2. "Authentication: The location dereference protocol MUST include 940 mechanisms to authenticate both the client and the server." 942 Partially Compliant: TLS provides means for mutual 943 authentication. This document only specifies the required 944 mechanism for server authentication. Client authentication is 945 not precluded. 947 D3. "Dereferenced Location Form: The value returned by the 948 dereference protocol MUST contain a well-formed PIDF-LO 949 document." 951 Compliant: HELD requires that location objects are in the form 952 of a PIDF-LO that complies with [RFC5491]. 954 D4. "Location URI Repeated Use: The location dereference protocol 955 MUST support the ability for the same location URI to be 956 resolved more than once, based on dereference server 957 configuration." 959 Compliant: A Location Recipient may access and use a location 960 URI as many times as desired until URI expiration results in the 961 URI being invalidated. Authorization policies might include 962 rules that modify this behavior. 964 D5. "The location dereference protocol MUST support confidentiality 965 protection of messages sent between the Location Recipient and 966 the location server." 968 Compliant: This document strongly recommends the use of TLS for 969 confidentiality and HELD mandates its implementation. Unsecured 970 HTTP is permitted: the associated risks are described in 971 Section 3. 973 Authors' Addresses 975 James Winterbottom 976 Commscope 977 Andrew Building (39) 978 Wollongong University Campus 979 Northfields Avenue 980 Wollongong, NSW 2522 981 AU 983 Phone: +61 242 212938 984 Email: james.winterbottom@commscope.com 985 Hannes Tschofenig 986 Nokia Siemens Networks 987 Linnoitustie 6 988 Espoo 02600 989 Finland 991 Phone: +358 (50) 4871445 992 Email: Hannes.Tschofenig@gmx.net 993 URI: http://www.tschofenig.priv.at 995 Henning Schulzrinne 996 Columbia University 997 Department of Computer Science 998 450 Computer Science Building, New York, NY 10027 999 US 1001 Phone: +1 212 939 7004 1002 Email: hgs@cs.columbia.edu 1003 URI: http://www.cs.columbia.edu 1005 Martin Thomson 1006 (Unaffiliated) 1007 . 1008 Mountain View, CA 94043 1009 US 1011 Phone: +1 650-353-1925 1012 Email: martin.thomson@gmail.com