idnits 2.17.00 (12 Aug 2021) /tmp/idnits31458/draft-ietf-geopriv-deref-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 29, 2010) is 4252 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 632, but no explicit reference was found in the text == Unused Reference: 'RFC4395' is defined on line 639, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 643, but no explicit reference was found in the text == Outdated reference: draft-ietf-geopriv-http-location-delivery has been published as RFC 5985 ** 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 ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) == Outdated reference: A later version (-02) exists of draft-barnes-geopriv-policy-uri-01 == Outdated reference: draft-ietf-geopriv-arch has been published as RFC 6280 == Outdated reference: draft-ietf-geopriv-held-identity-extensions has been published as RFC 6155 == Outdated reference: draft-ietf-geopriv-policy has been published as RFC 6772 == Outdated reference: draft-ietf-sipcore-location-conveyance has been published as RFC 6442 -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GEOPRIV J. Winterbottom 3 Internet-Draft Andrew Corporation 4 Intended status: Standards Track H. Tschofenig 5 Expires: April 2, 2011 Nokia Siemens Networks 6 H. Schulzrinne 7 Columbia University 8 M. Thomson 9 M. Dawson 10 Andrew Corporation 11 September 29, 2010 13 A Location Dereferencing Protocol Using HELD 14 draft-ietf-geopriv-deref-protocol-01 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 secure HELD URI that can be used in conjunction 23 with the HELD protocol to request the 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 April 2, 2011. 42 Copyright Notice 44 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Authorization Models . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Authorization by Possession . . . . . . . . . . . . . . . 6 63 3.2. Authorization via Access Control . . . . . . . . . . . . . 7 64 3.3. Access Control with HELD Deference . . . . . . . . . . . . 7 65 4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 8 66 4.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 9 67 4.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 9 68 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . 19 78 B.2. Requirements for a Location Dereference Protocol . . . . . 21 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 81 1. Introduction 83 Provision of location information by reference [RFC5808] involves the 84 creation of a resource that is identified by a "location URI". A 85 "location URI" identifies resource that contains the location of an 86 entity. A location URI might be a temporary resource, created in 87 response to a HTTP-Enabled Location Delivery (HELD) 88 [I-D.ietf-geopriv-http-location-delivery] request. A location URI 89 does not intrinsically include location information, instead the URI 90 is "dereferenced" by a Location Recipient to acquire location 91 information. This document specifies how a holder of a location URI 92 uses that URI to retrieve location information. 94 The HELD protocol, as described in 95 [I-D.ietf-geopriv-http-location-delivery], defines a use of HTTP that 96 enables location configuration - the process where a Device acquires 97 location information about itself. A part of location configuration 98 is the provision of a location URI. However, HELD does not describe 99 how such a URI is used; this document provides that definition. 101 This document defines how HELD is used by a Location Recipient to 102 dereference a location URI and acquire location information. The 103 result of this process is location object in the form of a Presence 104 Information Data Format - Location Object (PIDF-LO) document 105 [RFC4119]. A constrained set of HELD features are defined such that 106 it is suitable for use as a location dereference protocol [RFC5808]. 107 Use as a location dereference protocol requires use of the Transport 108 Layer Security (TLS) binding for HTTP [RFC2818] in order to provide 109 confidentiality, authentication and protection from modification. 111 Use of HELD as a dereferencing protocol has the advantage that the 112 Location Recipient can indicate the type of location information it 113 would like to receive. This functionality is already available with 114 the HELD base specification, described in 115 [I-D.ietf-geopriv-http-location-delivery]. Furthermore, the HELD 116 response from the LIS towards the Location Recipient not only 117 provides the PIDF-LO but also encapsulates supplementary information, 118 such as error messages, back to the Location Recipient. 120 Location URIs created for use with HELD dereferencing use the 121 "https:" or "http:" scheme. The behaviour described in this document 122 can be used by Location Recipients that are aware of the fact that 123 the URI is a location URI. 125 An example scenario envisioned by this document is shown in Figure 1. 126 This diagram shows how a location dereference protocol fits with 127 location configuration and conveyance. [RFC5808] contains more 128 information on this scenario and others like it. 130 +-------------+ 131 +------------+ | Location | +-----------+ 132 | End Device | | Information | | Location | 133 | (Target) | | Server | | Recipient | 134 +-----+------+ +------+------+ +-----+-----+ 135 | | | 136 .- + - - - - - - - - - - - - + -. | 137 : | locationRequest | : | 138 . |------(location URI)---->| . | 139 : | | : Location | 140 . | locationResponse | . Configuration | 141 : |<-----(location URI)-----| : Protocol | 142 . | | . | 143 `- + - - - - - - - - - - - - + -' | 144 | | | 145 | Location Conveyance | 146 |~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>| 147 | | | 148 | .- + - - - - - - - - - - - - + -. 149 | : | locationRequest | : 150 | . |<--------(civic)---------| . 151 | Dereferencing : | | : 152 | Protocol . | locationResponse | . 153 | : |--------(PIDF-LO)------->| : 154 | . | | . 155 | `- + - - - - - - - - - - - - + -' 156 | | | 158 Figure 1: Example of Dereference Protocol Exchange 160 2. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 This document uses key terminology from several sources: 168 o terms for the GEOPRIV reference model defined in 169 [I-D.ietf-geopriv-arch]; 171 o the term Location Information Server (LIS), from [RFC5687], is a 172 node in the access network that provides location information to 173 an end point; a LIS provides location URIs; 175 o the term Location Server (LS), from [I-D.ietf-geopriv-arch], is 176 used to identify the role that responds to a location dereference 177 request; this might be the same entity as the LIS, but the model 178 in [RFC5808] allows for the existence of separate - but related - 179 entities; and 181 o the term location URI is coined in [RFC5808]. 183 3. Authorization Models 185 This section discusses two extreme types of authorization models for 186 dereferencing with HELD URIs, namely "Authorization by Possession" 187 and "Authorization by Access Control". In the subsequent subsections 188 we discuss the properties of these two models. Figure 2, from 189 [RFC5808], shows the model applicable to location configuration, 190 conveyance and dereference. 192 +---------+--------+ Location +-----------+ 193 | | | Dereference | Location | 194 | LIS - LS +---------------+ Recipient | 195 | | | Protocol | | 196 +----+----+--------+ (3) +-----+-----+ 197 | `. | 198 | Policy `. | 199 Location | Exchange `. | 200 Configuration | (*) | | 201 Protocol | +----+----+ | 202 (1) | | Rule | Location | 203 | | Maker | Conveyance | 204 +-----+----+ +---------+ Protocol | 205 | | (2) | 206 | Target +------------------------------+ 207 | | 208 +----------+ 210 Figure 2: Communication Model 212 It is important to note that this document does not mandate a 213 specific authorization model. It is possible to combine aspects of 214 both models. However, no authentication framework is provided, which 215 limits the policy options available when the "Authorization by Access 216 Control" model is used. 218 For either authorization model, the overall process is similar. The 219 following steps are followed, with minor alterations: 221 1. The Target acquires a location URI from the LIS. This might use 222 HELD as a location configuration protocol (LCP). 224 2. The Target then conveys the location URI to a third party, the 225 Location Recipient (for example using SIP as described in 226 [I-D.ietf-sipcore-location-conveyance]). This step is shown in 227 (2) of Figure 2. 229 3. The Location Recipient then needs to dereference the location URI 230 in order to obtain the Location Object (3). Depending on the URI 231 scheme of the location URI dereferencing might, as is the case 232 for "https:" or "http:" URIs, be performed as described in this 233 document. 235 In this final step, the Location Server (LS) or LIS makes an 236 authorization decision. How this decision is reached depends on the 237 authorization model. 239 3.1. Authorization by Possession 241 In this model, possession - or knowledge - of the location URI is 242 used to control access to location information. A location URI is 243 constructed such that it is hard to guess (see C9 of [RFC5808]) and 244 the set of entities that it is disclosed to is limited. The only 245 authentication required by the LS is evidence of possession of the 246 URI. The LS is able to immediately authorize any request that 247 indicates this URI. 249 Authorization by possession uses a very simple policy that does not 250 typically require direct interaction with a Rule Maker; it is assumed 251 that the Rule Maker is able to exert control over the distribution of 252 the location URI. Therefore, the LIS can operate with limited policy 253 input from a Rule Maker. 255 Limited disclosure is an important aspect of this authorization 256 model. The location URI is a secret; therefore, ensuring that 257 adversaries are not able to acquire this information is paramount. 258 Encryption, such as might be offered by TLS [RFC5246] or S/MIME 259 [RFC3851], protects the information from eavesdroppers. 261 Use of authorization by possession location URIs in a hop-by-hop 262 protocol such as SIP [RFC3261] adds the possibility of on-path 263 adversaries. Depending on the usage of the location URI for certain 264 location based applications (e.g., emergency services, location based 265 routing) specific treatment is important, as discussed in 266 [I-D.ietf-sipcore-location-conveyance]. 268 Using possession as a basis for authorization means that, once 269 granted, authorization cannot be easily revoked. Cancellation of a 270 location URI ensures that legitimate users are also affected; 271 application of additional policy is theoretically possible, but could 272 be technically infeasible. Therefore, other measures are provided to 273 prevent an adversary from gaining access to location information 274 indefinitely. 276 A very simple policy is established at the time that the location URI 277 is created. This policy specifies that the location URI expires 278 after a certain time, which limits any inadvertent exposure of 279 location information to adversaries. The expiration time of the 280 location URI might be negotiated at the time of its creation, or it 281 might be unilaterally set by the LIS. 283 3.2. Authorization via Access Control 285 Use of explicit access control provides a Rule Maker greater control 286 over the behaviour of an LS. In contrast to authorization by 287 possession, possession of a this form of location URI does not imply 288 authorization. Since an explicit policy is used to authorize access 289 to location information, the location URI can be distributed to many 290 potential Location Recipients. 292 Either before creation or dissemination of the location URI, the Rule 293 Maker establishes an authorization policy with the LS. In reference 294 to Figure 2, authorization policies might be established at creation 295 (Step 1), and need to be established before before the location URI 296 is published (Step 2) to ensure that the policy grants access to the 297 desired Location Recipients. Depending on the mechanism used, it 298 might also be possible to change authorization policies at any time. 300 A possible format for these authorization policies is available with 301 GEOPRIV Common Policy [RFC4745] and Geolocation Policy 302 [I-D.ietf-geopriv-policy]. Additional constraints might be 303 established by other means. 305 The LS enforces the authorization policy when a Location Recipient 306 dereferences the URI. Explicit authorization policies allow a Rule 307 Maker to specify how location information is provided to Location 308 Recipients. 310 3.3. Access Control with HELD Deference 312 This document does not describe a specific authentication mechanism. 313 This means that authorization policies are unable to specifically 314 identify authorized Location Recipients. 316 In order to control access to location information based on the 317 identity of the Location Recipient, use of authorization by 318 possession is employed. By controlling which Location Recipients 319 receive location URIs, access to location information is controlled. 321 Other policy mechanisms, such as those described in 322 [I-D.ietf-geopriv-policy], can be applied to different Location 323 Recipients if multiple location URIs are used. Location Recipients 324 that receive a particular location URI are granted location 325 information based on the authorization policy associated with that 326 URI. 328 Providing that knowledge of a location URI is limited, policy 329 appropriate to the Location Recipients that receive the location URI 330 can be assigned. Selective disclosure used in this fashion can be 331 used in place of identity-based authorization. 333 How policy is associated with a location URI is not defined by this 334 document. [I-D.barnes-geopriv-policy-uri] describes one possible 335 mechanism. 337 Authentication of Location Recipients and use of identity-based 338 authorization policy is not precluded. A Location Server MAY support 339 an authentication mechanism that enables identity-based authorization 340 policies to be used. Future specifications might define means of 341 identifying recipients. 343 Note: Policy frameworks like [RFC4745] degrade in a way that 344 protects privacy if features are not supported. If a policy 345 specifies a rule that is conditional on the identity of a 346 recipient and the protocol does not (or cannot) provide an 347 assertion identity of the recipient, the rule has no effect and 348 the policy defaults to providing less information. 350 4. HELD Dereference Protocol 352 This section describes how HELD can be used to dereference a location 353 URI. This process can be applied when a Location Recipient is in 354 possession of a location URI with a "https:" or "http:" URI scheme. 356 A Location Recipient that wishes to dereference an "https:" or 357 "http:" URI performs a HELD request on HTTP to the identified 358 resource. 360 Note: In many cases, an "http:" URI does not provide sufficient 361 security for location URIs. The absence of the security 362 mechanisms provided by TLS means that the Rule Maker has no 363 control over who receives location information and the Location 364 Recipient has no assurance that the information is correct. 366 The Location Recipient establishes a connection to the LS, as 367 described in [RFC2818]. The TLS ciphersuite TLS_NULL_WITH_NULL_NULL 368 MUST NOT be used. The LS MUST be authenticated to ensure that the 369 correct server is contacted. 371 A Location Server MAY reject a request and request that a Location 372 Recipient provide authentication credentials if authorization is 373 dependent on the Location Recipient identity. Future specifications 374 could define an authentication mechanism and a means by which 375 Location Recipients are identified in authorization policies. This 376 document provides definitions for neither item. 378 4.1. HELD Usage Profile 380 Use of HELD as a location dereference protocol is largely the same as 381 its use as a location configuration protocol. Aside from the 382 restrictions noted in this document, HELD semantics do not differ 383 from those established in [I-D.ietf-geopriv-http-location-delivery]. 385 The HELD "locationRequest" is the only request permitted by this 386 specification. Similarly, request parameters other than the 387 following MUST NOT be accepted by the LS: "responseTime", 388 "locationType" (including the associated "exact" attribute). 390 Parameters and requests that do not have known behaviour for 391 dereference requests MUST NOT be used. The LS MUST ignore any 392 parameters that it does not understand unless it knows the parameters 393 to be invalid. If parameters are known to be invalid, the LS MAY 394 generate a HELD error response. For instance, those defined in 395 [I-D.ietf-geopriv-held-identity-extensions] are always invalid and 396 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, this document describes a way for a LIS to provide 411 a HELD location response if it 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. Only when a 426 location URI is created does HELD request have side-effects. A 427 request to a location URI can be both safe and idempotent, since a 428 location URI cannot be produced in response to a request to a 429 location URI. 431 Note: Idempotence does not require that the same answer be provided 432 to different requests only that there are no side effects. 433 Changes in the response can occur for a number of reasons, 434 including a change in the value of the resource: the location of 435 the Target. 437 Content negotiation MAY be supported to produce a presence document 438 in place of a HELD location response. Where the presence document 439 would otherwise be included in a "locationResponse" document, it can 440 be included in the body of the HTTP response directly. 442 5. Examples 444 The example in Figure 4 shows the simplest form of dereferencing 445 request using HELD to the location URI 446 "https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that 447 this differs from the example in Section 10.1 of 448 [I-D.ietf-geopriv-http-location-delivery] is in the request URI and 449 the source of the URI. 451 POST /uri/w3g61nf5n66p0 HTTP/1.1 452 Host: ls.example.com:49152 453 Content-Type: application/held+xml 454 Content-Length: 87 456 457 459 Figure 4: Minimal Dereferencing Request 461 Figure 5 shows the response to the previous request listing both 462 civic and geodetic location information of the Target's location. 463 Again, this is identical to the response in Section 10.1 of 464 [I-D.ietf-geopriv-http-location-delivery] - unless policy specfies 465 otherwise, the Location Recipient receives the same information as 466 the Device. 468 HTTP/1.1 200 OK 469 Server: Example LIS 470 Date: Mon, 10 Jan 2011 03:42:29 GMT 471 Expires: Tue, 11 Jan 2011 03:42:29 GMT 472 Cache-control: private 473 Content-Type: application/held+xml 474 Content-Length: 676 476 477 478 480 481 482 484 485 487 -34.407 150.88001 488 489 490 491 492 false 493 494 2011-01-11T03:42:29+00:00 495 496 Wiremap 497 498 499 2006-01-10T03:42:28+00:00 500 501 502 504 Figure 5: Response with Location Information 506 The following GET request is treated in an equivalent fashion. The 507 LS treats this request as though it were a location request of the 508 form shown in Figure 3. The same response might be provided. 510 GET /uri/w3g61nf5n66p0 HTTP/1.1 511 Host: ls.example.com:49152 512 Accept: application/held+xml 514 Figure 6: GET Request 516 The following GET request uses content negotiation to indicate a 517 preference for a presence document. 519 GET /uri/w3g61nf5n66p0 HTTP/1.1 520 Host: ls.example.com:49152 521 Accept: application/pidf+xml,application/held+xml;q=0.5 523 Figure 7: GET Request with Content Negotiation 525 The response only differs from a normal HELD location response to a 526 POST request in that the "locationResponse" element is omitted and 527 the "Content-Type" header reflects the changed content. 529 HTTP/1.1 200 OK 530 Server: Example LIS 531 Date: Mon, 10 Jan 2011 03:42:29 GMT 532 Expires: Tue, 11 Jan 2011 03:42:29 GMT 533 Cache-control: private 534 Content-Type: application/pidf+xml 535 Content-Length: 591 537 538 540 ... PIDF contents are identical to the previous example ... 541 543 Figure 8: GET Response with PIDF-LO 545 6. Security Considerations 547 Privacy of location information is the most important security 548 consideration for this document. Two measures in particular are used 549 to protect privacy: TLS and authorization policies. TLS provides a 550 means of ensuring confidentiality of location information through 551 encryption and mutual authentication. An authorization policy allows 552 a Rule Maker to explicitly control how location information is 553 provided to Location Recipients. 555 The process by which a Rule Maker establishes an authorization policy 556 is not covered by this document; several methods are possible, for 557 instance: [I-D.barnes-geopriv-policy-uri], [RFC4825]. 559 Use of TLS for the dereferencing of location URIs is strongly 560 RECOMMENDED, as discussed in Section 4.1. Location Recipients MUST 561 authenticate the host identity using the domain name included in the 562 location URI, using the procedure described in Section 3.1 of 563 [RFC2818]. Local policy determines what a Location Recipient does if 564 authentication fails or cannot be attempted. 566 The authorization by possession model (Section 3.1) further relies on 567 TLS when transmitting the location URI to protect the secrecy of the 568 URI. Possession of such a URI implies the same privacy 569 considerations as possession of the PIDF-LO document that the URI 570 references. 572 Location URIs MUST only be disclosed to authorized Location 573 Recipients. The GEOPRIV architecture [I-D.ietf-geopriv-arch] 574 identifies the Rule Maker role as being the entity that authorizes 575 disclosure of this nature. 577 Protection of the location URI is necessary, since the policy 578 attached to such a location URI permits any who have the URI to view 579 it. This aspect of security is covered in more detail in the 580 specification of location conveyance protocols, such as 581 [I-D.ietf-sipcore-location-conveyance]. 583 The LS MUST NOT provide any information about the Target except its 584 location, unless policy from a Rule Maker allows otherwise. In 585 particular, the requirements in [RFC5808] mandate this measure to 586 protect the identity of the Target. To this end, an unlinked 587 pseudonym MUST be provided in the "entity" attribute of the PIDF-LO 588 document. 590 Further security considerations and requirements relating to the use 591 of location URIs are described in [RFC5808]. 593 7. IANA Considerations 595 This document makes no request of IANA. 597 [[IANA/RFC-EDITOR: Please remove this section before publication.]] 599 8. Acknowledgements 601 Thanks to Barbara Stark and Guy Caron for providing early comments. 602 Thanks to Rohan Mahy for constructive comments on the scope and 603 format of the document. Thanks to Ted Hardie for his strawman 604 proposal that provided assistance with the security section of this 605 document. Richard Barnes made helpful observations on the 606 application of authorization policy. 608 The Participants of the GEOPRIV interim meeting 2008 provided 609 significant feedback on this document. 611 James Polk provided input on security in June 2008. 613 9. References 615 9.1. Normative References 617 [I-D.ietf-geopriv-http-location-delivery] 618 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 619 "HTTP Enabled Location Delivery (HELD)", 620 draft-ietf-geopriv-http-location-delivery-16 (work in 621 progress), August 2009. 623 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 624 Requirement Levels", BCP 14, RFC 2119, March 1997. 626 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 627 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 628 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 630 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 632 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 633 Resource Identifier (URI): Generic Syntax", STD 66, 634 RFC 3986, January 2005. 636 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 637 Format", RFC 4119, December 2005. 639 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 640 Registration Procedures for New URI Schemes", BCP 35, 641 RFC 4395, February 2006. 643 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 644 Specifications: ABNF", STD 68, RFC 5234, January 2008. 646 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 647 Presence Information Data Format Location Object (PIDF-LO) 648 Usage Clarification, Considerations, and Recommendations", 649 RFC 5491, March 2009. 651 9.2. Informative references 653 [I-D.barnes-geopriv-policy-uri] 654 Barnes, R., Thomson, M., and J. Winterbottom, "Location 655 Configuration Extensions for Policy Management", 656 draft-barnes-geopriv-policy-uri-01 (work in progress), 657 May 2010. 659 [I-D.ietf-geopriv-arch] 660 Barnes, R., Lepinski, M., Cooper, A., Morris, J., 661 Tschofenig, H., and H. Schulzrinne, "An Architecture for 662 Location and Location Privacy in Internet Applications", 663 draft-ietf-geopriv-arch-02 (work in progress), May 2010. 665 [I-D.ietf-geopriv-held-identity-extensions] 666 Winterbottom, J., Thomson, M., Tschofenig, H., and R. 667 Barnes, "Use of Device Identity in HTTP-Enabled Location 668 Delivery (HELD)", 669 draft-ietf-geopriv-held-identity-extensions-04 (work in 670 progress), June 2010. 672 [I-D.ietf-geopriv-policy] 673 Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 674 and J. Polk, "Geolocation Policy: A Document Format for 675 Expressing Privacy Preferences for Location Information", 676 draft-ietf-geopriv-policy-21 (work in progress), 677 January 2010. 679 [I-D.ietf-sipcore-location-conveyance] 680 Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 681 for the Session Initiation Protocol", 682 draft-ietf-sipcore-location-conveyance-03 (work in 683 progress), July 2010. 685 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 686 A., Peterson, J., Sparks, R., Handley, M., and E. 687 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 688 June 2002. 690 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 691 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 693 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 694 Extensions (S/MIME) Version 3.1 Message Specification", 695 RFC 3851, July 2004. 697 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 698 Polk, J., and J. Rosenberg, "Common Policy: A Document 699 Format for Expressing Privacy Preferences", RFC 4745, 700 February 2007. 702 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 703 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 705 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 706 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 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 Appendix A. GEOPRIV Using Protocol Compliance 717 This section describes how use of HELD as a location dereference 718 protocol complies with the GEOPRIV requirements described in 719 [RFC3693]. 721 Req. 1. (Location Object generalities): 723 This section relates to the PIDF-LO [RFC4119] document, 724 which is used by HELD. These requirements are addressed by 725 [RFC4119] and [RFC5491]. 727 Req. 2. (Location Object fields): 729 This section relates to the PIDF-LO [RFC4119] document, 730 which is used by HELD. These requirements are addressed by 731 [RFC4119] and [RFC5491]. 733 Req. 3. (Location Data Types): 735 This section relates to the PIDF-LO [RFC4119] document, 736 which is used by HELD. These requirements are addressed by 737 [RFC4119] and [RFC5491]. 739 Section 7.2 of [RFC3693] details the requirements of a "Using 740 Protocol". These requirements are restated, followed by a statement 741 of compliance: 743 Req. 4. "The using protocol has to obey the privacy and security 744 instructions coded in the Location Object and in the 745 corresponding Rules regarding the transmission and storage 746 of the LO." 748 Compliant: This document carries the PIDF-LO as is via HTTPS 749 from the LS to the Location Recipient. The sending and 750 receiving parties are expected to comply with the 751 instructions carried inside the object. 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 Req. 10. (Full Rule language) Not Applicable: Note however that 812 Geopriv has defined a rule language capable of expressing a 813 wide range of privacy rules (see [RFC4745] and 814 [I-D.ietf-geopriv-policy]. 816 Req. 11. (Limited Rule language) Not Applicable: This requirement 817 applies to (and is addressed by) PIDF-LO [RFC4119]. 819 Section 7.4 of [RFC3693] details the requirements of "Location Object 820 Privacy and Security". These requirements are restated where they 821 are applicable to this document: 823 Req. 12. (Identity Protection) Compliant: Identity protection of the 824 Target is provided as long as both of the following 825 conditions are true: 827 (a) the location URI is not associated with the identity 828 of the Target in any context, and 830 (b) the PIDF-LO does not contain information about the 831 identity about the Target. 833 For instance, this requirement is complied with if the 834 protocol that conveys the location URI does not link the 835 identity of the Target to the location URI and the LS 836 doesn't include meaningful identification information in 837 the PIDF-LO document. Section 6 recommends that an 838 unlinked pseudonym is used by the LS. 840 Req. 13. (Credential Requirements) Compliant: The primary security 841 mechanism specified in this document is Transport Layer 842 Security. TLS offers the ability to use different types of 843 credentials, including symmetric, asymmetric credentials or 844 a combination of them. 846 Req. 14. (Security Features) Compliant: Geopriv defines a few 847 security requirements for the protection of Location 848 Objects such as mutual end-point authentication, data 849 object integrity, data object confidentiality and replay 850 protection. The ability to use Transport Layer security 851 fulfills most of these requirements. Authentication of 852 Location Recipients in this document relies on proof of a 853 shared secret - the location URI. This does not preclude 854 the addition of more robust authentication procedures. 856 Req. 15. (Minimal Crypto) Compliant: The mandatory to implement 857 ciphersuite is provided in the TLS layer security 858 specification. 860 Appendix B. Compliance to Location Reference Requirements 862 This section describes how HELD complies to the location reference 863 requirements stipulated in [RFC5808]. Compliance to the Location 864 Configuration Protocol are included in this document. 866 Note that use of HELD as a location dereference protocol does not 867 necessarily imply that HELD is the corresponding LCP. This 868 document is still applicable to HTTP location URIs that are 869 acquired by other means. 871 B.1. Requirements for a Location Configuration Protocol 873 C1. "Location URI support: The location configuration protocol MUST 874 support a location reference in URI form." 876 Compliant: HELD only provides location references in URI form. 878 C2. "Location URI expiration: When a location URI has a limited 879 validity interval, its lifetime MUST be indicated." 881 Compliant: HELD indicates the expiry time of location URIs using 882 the "expires" attribute. [I-D.barnes-geopriv-policy-uri] 883 provides a way to control expiration of a location URI; a Device 884 is able to specify limits on the life time of a HELD context. 886 C3. "Location URI cancellation: The location configuration protocol 887 MUST support the ability to request a cancellation of a specific 888 location URI." 890 Compliant with Extension: [I-D.barnes-geopriv-policy-uri] 891 describes how a location URI can be cancelled through the 892 application of policy. Without extensions, HELD does not 893 provide a method for cancelling location URIs. 895 C4. "Location Information Masking: The location URI MUST ensure, by 896 default, through randomization and uniqueness, that the location 897 URI does not contain location information specific components." 899 Compliant: The HELD specification explicitly references this 900 requirement in providing guidance on the format of the location 901 URI. 903 C5. "Target Identity Protection: The location URI MUST NOT contain 904 information that identifies the Target (e.g., user or device)." 906 Compliant: The HELD specification provides specific guidance on 907 the anonymity of the Target with regards to the generation of 908 location URIs. Section 6 expands on this guidance. 910 C6. "Reuse indicator: There SHOULD be a way to allow a Target to 911 control whether a location URI can be resolved once only, or 912 multiple times." 914 Not Compliant: Specific extensions to the protocol or 915 authorization policy formats is needed to alter the default 916 behavior, which allows unlimited resolution of the location URI. 918 C7. "Selective disclosure: The location configuration protocol MUST 919 provide a mechanism that allows the Rule Maker to control what 920 information is being disclosed about the Target." 922 Compliant with Extension: Use of policy mechanisms and 923 [I-D.barnes-geopriv-policy-uri] enable this capability. Note 924 that this document recommends that only location information be 925 provided. 927 C8. "Location URI Not guessable: As a default, the location 928 configuration protocol MUST return location URIs that are random 929 and unique throughout the indicated lifetime. A location URI 930 with 128-bits of randomness is RECOMMENDED." 931 Compliant: HELD specifies that location URIs conform to this 932 requirement. 934 C9. "Location URI Options: In the case of user-provided 935 authorization policies, where anonymous or non-guessable 936 location URIs are not warranted, the location configuration 937 protocol MAY support a variety of optional location URI 938 conventions, as requested by a Target to a location 939 configuration server, (e.g., embedded location information 940 within the location URI)." 942 Not Compliant: HELD does not support Device-specified location 943 URI forms. 945 B.2. Requirements for a Location Dereference Protocol 947 D1. "Location URI support: The location dereference protocol MUST 948 support a location reference in URI form." 950 Compliant: HELD only provides location references in URI form. 952 D2. "Authentication: The location dereference protocol MUST include 953 mechanisms to authenticate both the client and the server." 955 Partially Compliant: TLS provides means for mutual 956 authentication. This document only specifies the required 957 mechanism for server authentication. Client authentication is 958 not precluded. 960 D3. "Dereferenced Location Form: The value returned by the 961 dereference protocol MUST contain a well-formed PIDF-LO 962 document." 964 Compliant: HELD requires that location objects are in the form 965 of a PIDF-LO that complies with [RFC5491]. 967 D4. "Location URI Repeated Use: The location dereference protocol 968 MUST support the ability for the same location URI to be 969 resolved more than once, based on dereference server 970 configuration." 972 Compliant: A Location Recipient may access and use a location 973 URI as many times as desired until URI expiration results in the 974 URI being invalidated. Authorization policies might include 975 rules that modify this behavior. 977 D5. "The location dereference protocol MUST support confidentiality 978 protection of messages sent between the Location Recipient and 979 the location server." 981 Compliant: This document strongly recommends the use of TLS for 982 confidentiality and HELD mandates its implementation. Unsecured 983 HTTP is permitted, and some of the associated risks are 984 described in Section 4.1. 986 Authors' Addresses 988 James Winterbottom 989 Andrew Corporation 990 Andrew Building (39) 991 Wollongong University Campus 992 Northfields Avenue 993 Wollongong, NSW 2522 994 AU 996 Phone: +61 242 212938 997 Email: james.winterbottom@andrew.com 999 Hannes Tschofenig 1000 Nokia Siemens Networks 1001 Linnoitustie 6 1002 Espoo 02600 1003 Finland 1005 Phone: +358 (50) 4871445 1006 Email: Hannes.Tschofenig@gmx.net 1007 URI: http://www.tschofenig.priv.at 1009 Henning Schulzrinne 1010 Columbia University 1011 Department of Computer Science 1012 450 Computer Science Building, New York, NY 10027 1013 US 1015 Phone: +1 212 939 7004 1016 Email: hgs@cs.columbia.edu 1017 URI: http://www.cs.columbia.edu 1018 Martin Thomson 1019 Andrew Corporation 1020 Andrew Building (39) 1021 Wollongong University Campus 1022 Northfields Avenue 1023 Wollongong, NSW 2522 1024 AU 1026 Phone: +61 2 4221 2915 1027 Email: martin.thomson@andrew.com 1029 Martin Dawson 1030 Andrew Corporation 1031 Andrew Building (39) 1032 Wollongong University Campus 1033 Northfields Avenue 1034 Wollongong, NSW 2522 1035 AU 1037 Phone: +61 2 4221 2992 1038 Email: martin.dawson@andrew.com