idnits 2.17.00 (12 Aug 2021) /tmp/idnits22985/draft-winterbottom-geopriv-deref-protocol-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 27, 2009) is 4680 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: 'RFC2616' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC4395' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'RFC5234' is defined on line 588, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-geopriv-lis-discovery' is defined on line 662, 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) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Downref: Normative reference to an Informational RFC: RFC 2818 ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) == Outdated reference: draft-ietf-geopriv-l7-lcp-ps has been published as RFC 5687 == Outdated reference: draft-ietf-geopriv-lbyr-requirements has been published as RFC 5808 == Outdated reference: draft-ietf-geopriv-lis-discovery has been published as RFC 5986 == Outdated reference: draft-ietf-geopriv-policy has been published as RFC 6772 -- No information found for draft-winterbottom-geopriv-held-context - is the name correct? -- No information found for draft-winterbottom-geopriv-held-identity-extensions - is the name correct? -- 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: 5 errors (**), 0 flaws (~~), 11 warnings (==), 6 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: January 28, 2010 Nokia Siemens Networks 6 H. Schulzrinne 7 Columbia University 8 M. Thomson 9 M. Dawson 10 Andrew Corporation 11 July 27, 2009 13 A Location Dereferencing Protocol Using HELD 14 draft-winterbottom-geopriv-deref-protocol-04 16 Status of This Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 28, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 This document describes how to use the Hypertext Transfer Protocol 53 (HTTP) over Transport Layer Security (TLS) as a dereferencing 54 protocol to resolve a reference to a Presence Information Data Format 55 Location Object (PIDF-LO). The document assumes that a Location 56 Recipient possesses a secure HELD URI that can be used in conjunction 57 with the HELD protocol to request the location of the Target. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Authorization Models . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Authorization by Possession . . . . . . . . . . . . . . . 6 65 3.2. Authorization via Access Control . . . . . . . . . . . . . 7 66 4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 7 67 4.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 8 68 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 9.2. Informative references . . . . . . . . . . . . . . . . . . 14 75 Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 18 76 Appendix B. Compliance to Location Reference Requirements . . . . 21 77 B.1. Requirements for a Location Configuration Protocol . . . . 21 78 B.2. Requirements for a Location Dereference Protocol . . . . . 24 80 1. Introduction 82 Provision of location information by reference 83 [I-D.ietf-geopriv-lbyr-requirements] involves the creation of a 84 resource that is identified by a "location URI". A "location URI" 85 identifies resource that contains the location of an entity. A 86 location URI might be a temporary resource, created in response to a 87 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 107 [I-D.ietf-geopriv-lbyr-requirements]. Use as a location dereference 108 protocol requires use of the Transport Layer Security (TLS) binding 109 for HTTP [RFC2818] in order to provide confidentiality, 110 authentication and protection from modification. 112 Use of HELD as a dereferencing protocol has the advantage that the 113 Location Recipient can indicate the type of location information it 114 would like to receive. This functionality is already available with 115 the HELD base specification, described in 116 [I-D.ietf-geopriv-http-location-delivery]. Furthermore, the HELD 117 response from the LIS towards the Location Recipient not only 118 provides the PIDF-LO but also encapsulates supplementary information, 119 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 for the HTTP binding of HELD. The 123 behaviour described in this document can be used by Location 124 Recipients that are aware of the fact that the URI is a location URI. 126 An example scenario envisioned by this document is shown in Figure 1. 127 This diagram shows how a location dereference protocol fits with 128 location configuration and conveyance. 129 [I-D.ietf-geopriv-lbyr-requirements] contains more information on 130 this scenario and others like it. 132 +-------------+ 133 +------------+ | Location | +-----------+ 134 | End Device | | Information | | Location | 135 | (Target) | | Server | | Recipient | 136 +-----+------+ +------+------+ +-----+-----+ 137 | | | 138 .- + - - - - - - - - - - - - + -. | 139 : | locationRequest | : | 140 . |------(location URI)---->| . | 141 : | | : Location | 142 . | locationResponse | . Configuration | 143 : |<-----(location URI)-----| : Protocol | 144 . | | . | 145 `- + - - - - - - - - - - - - + -' | 146 | | | 147 | Location Conveyance | 148 |~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>| 149 | | | 150 | .- + - - - - - - - - - - - - + -. 151 | : | locationRequest | : 152 | . |<--------(civic)---------| . 153 | Dereferencing : | | : 154 | Protocol . | 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 [RFC3693] and 171 [I-D.barnes-geopriv-lo-sec]; 173 o the term Location Information Server (LIS), from 174 [I-D.ietf-geopriv-l7-lcp-ps], is a node in the access network that 175 provides location information to an end point; a LIS provides 176 location URIs; 178 o the term Location Server (LS), from [RFC3693], is used to identify 179 the server that responds to a location dereference request; this 180 might be the same entity as the LIS, but the model in 181 [I-D.ietf-geopriv-lbyr-requirements] allows for the existence of 182 separate - but related - entities; and 184 o the term location URI is coined in 185 [I-D.ietf-geopriv-lbyr-requirements]. 187 3. Authorization Models 189 This section discusses two extreme types of authorization models for 190 dereferencing with HELD URIs, namely "Authorization by Possession" 191 and "Authorization by Access Control". In the subsequent subsections 192 we discuss the properties of these two models. These two models can, 193 however, be used in combination in a real deployment. Figure 2, from 194 [I-D.ietf-geopriv-lbyr-requirements], shows the model applicable to 195 location configuration, conveyance and dereference. 197 +---------+--------+ Location +-----------+ 198 | | | Dereference | Location | 199 | LIS - LS +---------------+ Recipient | 200 | | | Protocol | | 201 +----+----+--------+ (3) +-----+-----+ 202 | `. | 203 | Policy `. | 204 Location | Exchange `. | 205 Configuration | (*) | | 206 Protocol | +----+----+ | 207 (1) | | Rule | Location | 208 | | Maker | Conveyance | 209 +-----+----+ +---------+ Protocol | 210 | | (2) | 211 | Target +------------------------------+ 212 | | 213 +----------+ 215 Figure 2: Communication Model 217 It is important to note that this document does not mandate a 218 specific authorization model, nor does it constrain the usage with 219 regard to these models in any way. Additionally, it is possible to 220 combine certain parts of both models. 222 For either authorization model, the overall process is similar. The 223 following steps are followed, with minor alterations: 225 1. The Target acquires a location URI from the LIS. This might use 226 HELD as a location configuration protocol (LCP). 228 2. The Target then conveys the location URI to a third party, the 229 Location Recipient (for example using SIP as described in 230 [I-D.ietf-sip-location-conveyance]). This step is shown in (2) 231 of Figure 2. 233 3. The Location Recipient then needs to dereference the location URI 234 in order to obtain the Location Object (3). Depending on the URI 235 scheme of the location URI dereferencing might, as is the case 236 for "https:" or "http:" URIs, be performed as described in this 237 document. 239 In this final step, the Location Server (LS) or LIS makes an 240 authorization decision. How this decision is reached depends on the 241 authorization model. 243 3.1. Authorization by Possession 245 In this model, possession - or knowledge - of the location URI is 246 used to control access to location information. A location URI is 247 constructed such that it is hard to guess (see C9 of 248 [I-D.ietf-geopriv-lbyr-requirements]) and the set of entities that it 249 is disclosed to is limited. The only authentication required by the 250 LS is evidence of possession of the URI. The LS is able to 251 immediately authorize any request that indicates this URI. 253 Authorization by possession uses a very simple policy that does not 254 typically require direct interaction with a Rule Maker; it is assumed 255 that the Rule Maker is able to exert control over the distribution of 256 the location URI. Therefore, the LIS can operate with limited policy 257 input from a Rule Maker. 259 Limited disclosure is an important aspect of this authorization 260 model. The location URI is a secret; therefore, ensuring that 261 adversaries are not able to acquire this information is paramount. 262 Encryption, such as might be offered by TLS [RFC5246] or S/MIME 263 [RFC3851], protects the information from eavesdroppers. 265 Use of authorization by possession location URIs in a hop-by-hop 266 protocol such as SIP [RFC3261] adds the possibility of on-path 267 adversaries. Depending on the usage of the location URI for certain 268 location based applications (e.g., emergency services, location based 269 routing) specific treatment is important, as discussed in 270 [I-D.ietf-sip-location-conveyance]. 272 Using possession as a basis for authorization means that, once 273 granted, authorization cannot be easily revoked. Cancellation of a 274 location URI ensures that legitimate users are also affected; 275 application of additional policy is theoretically possible, but could 276 be technically infeasible. Therefore, other measures are provided to 277 prevent an adversary from gaining access to location information 278 indefinitely. 280 A very simple policy is established at the time that the location URI 281 is created. This policy specifies that the location URI expires 282 after a certain time, which limits any inadvertent exposure of 283 location information to adversaries. The expiration time of the 284 location URI might be negotiated at the time of its creation, as is 285 the case with [I-D.winterbottom-geopriv-held-context]. 287 3.2. Authorization via Access Control 289 Use of explicit access control provides a Rule Maker greater control 290 over the behaviour of an LS. In contrast to authorization by 291 possession, possession of a this form of location URI does not imply 292 authorization. Since an explicit policy is used to authorize access 293 to location information, the location URI can be distributed to many 294 potential Location Recipients. 296 Either before creation or dissemination of the location URI, the Rule 297 Maker establishes an authorization policy with the LS. In reference 298 to Figure 2, authorization policies might be established at creation 299 (Step 1), and need to be established before before the location URI 300 is published (Step 2) to ensure that the policy grants access to the 301 desired Location Recipients. Depending on the mechanism used, it 302 might also be possible to change authorization policies at any time. 304 A possible format for these authorization policies is available with 305 GEOPRIV Common Policy [RFC4745] and Geolocation Policy 306 [I-D.ietf-geopriv-policy]. Additional constraints might be 307 established by other means. 309 The LS enforces the authorization policy when a Location Recipient 310 dereferences the URI. Explicit authorization policies allow a Rule 311 Maker to specify the identity of Location Recipients, constrain the 312 accuracy and form of location information, and to control other 313 aspects of the authorization process. 315 4. HELD Dereference Protocol 317 This section describes how HELD can be used to dereference a location 318 URI. This process can be applied when a Location Recipient is in 319 possession of a location URI with a "https:" or "http:" URI scheme. 321 A Location Recipient that wishes to dereference an "https:" or 322 "http:" URI performs a HELD request on HTTP to the identified 323 resource. 325 Note: In many cases, an "http:" URI does not provide sufficient 326 security for location URIs. The absence of the security 327 mechanisms provided by TLS means that the Rule Maker has no 328 control over who receives location information and the Location 329 Recipient has no assurance that the information is correct. 331 The Location Recipient establishes a connection to the LS, as 332 described in [RFC2818]. The TLS ciphersuite TLS_NULL_WITH_NULL_NULL 333 MUST NOT be used. The LS MUST be authenticated to ensure that the 334 correct server is contacted. Given that a location URI does not 335 indicate the authorization model used, the Location Recipient MUST be 336 prepared to provide authentication information unless it has external 337 information on the authorization model used by the URI. This 338 document does not specify how the LS authenticates the Location 339 Recipient; however, a Location Recipient MUST support provision of a 340 client certificate during TLS session creation and HTTP digest 341 authentication [RFC2617], unless these authentication methods are 342 known to be inapplicable. 344 4.1. HELD Usage Profile 346 Use of HELD as a location dereference protocol is largely the same as 347 its use as a location configuration protocol. Aside from the 348 restrictions noted in this document, HELD semantics do not differ 349 from those established in [I-D.ietf-geopriv-http-location-delivery]. 351 The HELD "locationRequest" is the only request permitted by this 352 specification. Similarly, request parameters other than the 353 following MUST NOT be accepted by the LS: "responseTime", 354 "locationType" (including the associated "exact" attribute). Other 355 specifications MUST explicitly describe whether other requests or 356 parameters apply to dereference requests and how they are to be 357 interpreted if they are permitted. The LS MUST ignore any parameters 358 that it does not understand unless it knows the parameters to be 359 invalid, such as those defined in 360 [I-D.winterbottom-geopriv-held-identity-extensions]. If parameters 361 are known to be invalid, the LS MAY generate a HELD error response. 363 The LS MUST NOT generate any location URIs or provide a 364 "locationUriSet" in response to a dereference request. If the 365 location request contains a "locationType" element that includes 366 "locationURI", this parameter is either ignored or rejected as 367 appropriate, based on the associated "exact" attribute. 369 This document requires additional HTTP features from Location 370 Recipients that are not required of Devices in HELD. HTTP digest 371 authentication [RFC2617] MUST be supported by Location Recipients, 372 unless there is no means to provide such authentication information. 374 5. Examples 376 The example in Figure 3 shows the simplest form of dereferencing 377 request using HELD to the location URI 378 "https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that 379 this differs from the example in Section 10.1 of 380 [I-D.ietf-geopriv-http-location-delivery] is in the request URI and 381 the source of the URI. 383 POST /uri/w3g61nf5n66p0 HTTP/1.1 384 Host: ls.example.com:49152 385 Content-Type: application/held+xml 386 Content-Length: 87 388 389 391 Figure 3: Minimal Dereferencing Request 393 Figure 4 shows the response to the previous request listing both 394 civic and geodetic location information of the Target's location. If 395 this looks similar to the response in Section 10.1 of 396 [I-D.ietf-geopriv-http-location-delivery], that is no coincidence - 397 unless policy specfies otherwise, the Location Recipient receives the 398 same information as the Device. 400 HTTP/1.1 200 OK 401 Server: Example LIS 402 Date: Tue, 10 Jan 2009 03:42:29 GMT 403 Expires: Tue, 10 Jan 2009 03:42:29 GMT 404 Cache-control: private 405 Content-Type: application/held+xml 406 Content-Length: 594 408 409 410 412 413 414 415 416 418 -34.407 150.88001 419 420 421 422 423 2006-01-11T03:42:28+00:00 424 425 Wiremap 426 427 428 2006-01-10T03:42:28+00:00 429 430 431 433 Figure 4: Response with Location Information 435 6. Security Considerations 437 Privacy of location information is the most important security 438 consideration for this document. Two measures in particular are used 439 to protect privacy: TLS and authorization policies. TLS provides a 440 means of ensuring confidentiality of location information through 441 encryption and mutual authentication. An authorization policy allows 442 a Rule Maker to explicitly control how location information is 443 provided to Location Recipients. The process by which a Rule Maker 444 establishes an authorization policy is not covered by this document; 445 several methods are possible, for instance: 446 [I-D.winterbottom-geopriv-held-context], [RFC4825]. 448 Use of TLS for the dereferencing of location URIs is strongly 449 RECOMMENDED, as discussed in Section 4.1. Location Recipients MUST 450 authenticate the host identity using the domain name included in the 451 location URI, using the procedure described in Section 3.1 of 452 [RFC2818]. Local policy determines what a Location Recipient does is 453 authentication fails, or is not attempted. 455 The authorization by possession model (Section 3.1) further relies on 456 TLS when transmitting the location URI to protect the secrecy of the 457 URI. Possession of such a URI implies the same privacy 458 considerations as possession of the PIDF-LO document that the URI 459 references. This is necessary, since the policy attached to such a 460 location URI permits any who have the URI to view it. This aspect of 461 security is covered in more detail in the specification of location 462 conveyance protocols, such as [I-D.ietf-sip-location-conveyance]. 464 The Location Recipient MUST be prepared to provide authentication 465 credentials when making a dereference request. 467 To comply with identity protection requirements in [RFC3693], the LS 468 MUST NOT include any information that could be used to identify a 469 Target, unless policy is provided that allows this. To this end, an 470 unlinked pseudonym MUST be provided in the "entity" attribute of the 471 PIDF-LO document. 473 Further security considerations and requirements relating to the use 474 of location URIs are described in 475 [I-D.ietf-geopriv-lbyr-requirements]. 477 7. IANA Considerations 479 This document makes no request of IANA. 481 [[IANA/RFC-EDITOR: Please remove this section before publication.]] 483 8. Acknowledgements 485 Thanks to Barbara Stark and Guy Caron for providing early comments. 486 Thanks to Rohan Mahy for constructive comments on the scope and 487 format of the document. Thanks to Ted Hardie for his strawman 488 proposal that provided assistance with the security section of this 489 document. 491 The authors would like to thank the participants of the GEOPRIV 492 interim meeting 2008 for their feedback. 494 James Polk provided comments on a security aspects in June 2008. 496 9. References 498 9.1. Normative References 500 [I-D.ietf-geopriv-http-location-delivery] Barnes, M., 501 Winterbottom, 502 J., Thomson, M., 503 and B. Stark, 504 "HTTP Enabled 505 Location 506 Delivery 507 (HELD)", draft- 508 ietf-geopriv- 509 http-location- 510 delivery-15 511 (work in 512 progress), 513 June 2009. 515 [RFC2119] Bradner, S., 516 "Key words for 517 use in RFCs to 518 Indicate 519 Requirement 520 Levels", BCP 14, 521 RFC 2119, 522 March 1997. 524 [RFC2616] Fielding, R., 525 Gettys, J., 526 Mogul, J., 527 Frystyk, H., 528 Masinter, L., 529 Leach, P., and 530 T. Berners-Lee, 531 "Hypertext 532 Transfer 533 Protocol -- 534 HTTP/1.1", 535 RFC 2616, 536 June 1999. 538 [RFC2617] Franks, J., 539 Hallam-Baker, 540 P., Hostetler, 541 J., Lawrence, 542 S., Leach, P., 543 Luotonen, A., 544 and L. Stewart, 545 "HTTP 546 Authentication: 547 Basic and Digest 548 Access 549 Authentication", 550 RFC 2617, 551 June 1999. 553 [RFC2818] Rescorla, E., 554 "HTTP Over TLS", 555 RFC 2818, 556 May 2000. 558 [RFC3986] Berners-Lee, T., 559 Fielding, R., 560 and L. Masinter, 561 "Uniform 562 Resource 563 Identifier 564 (URI): Generic 565 Syntax", STD 66, 566 RFC 3986, 567 January 2005. 569 [RFC4119] Peterson, J., "A 570 Presence-based 571 GEOPRIV Location 572 Object Format", 573 RFC 4119, 574 December 2005. 576 [RFC4395] Hansen, T., 577 Hardie, T., and 578 L. Masinter, 579 "Guidelines and 580 Registration 581 Procedures for 582 New URI 583 Schemes", 584 BCP 35, 585 RFC 4395, 586 February 2006. 588 [RFC5234] Crocker, D. and 589 P. Overell, 590 "Augmented BNF 591 for Syntax 592 Specifications: 593 ABNF", STD 68, 594 RFC 5234, 595 January 2008. 597 [RFC5491] Winterbottom, 598 J., Thomson, M., 599 and H. 600 Tschofenig, 601 "GEOPRIV 602 Presence 603 Information Data 604 Format Location 605 Object (PIDF-LO) 606 Usage 607 Clarification, 608 Considerations, 609 and 610 Recommendations" 611 , RFC 5491, 612 March 2009. 614 9.2. Informative references 616 [I-D.barnes-geopriv-lo-sec] Barnes, R., 617 Lepinski, M., 618 Cooper, A., 619 Morris, J., 620 Tschofenig, H., 621 and H. 622 Schulzrinne, "An 623 Architecture for 624 Location and 625 Location Privacy 626 in Internet 627 Applications", d 628 raft-barnes- 629 geopriv-lo-sec- 630 05 (work in 631 progress), 632 March 2009. 634 [I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. 635 and H. 636 Schulzrinne, 637 "GEOPRIV Layer 7 638 Location 639 Configuration 640 Protocol; 641 Problem 642 Statement and 643 Requirements", d 644 raft-ietf- 645 geopriv-l7-lcp- 646 ps-10 (work in 647 progress), 648 July 2009. 650 [I-D.ietf-geopriv-lbyr-requirements] Marshall, R., 651 "Requirements 652 for a Location- 653 by-Reference 654 Mechanism", draf 655 t-ietf-geopriv- 656 lbyr- 657 requirements-07 658 (work in 659 progress), 660 February 2009. 662 [I-D.ietf-geopriv-lis-discovery] Thomson, M. and 663 J. Winterbottom, 664 "Discovering the 665 Local Location 666 Information 667 Server (LIS)", d 668 raft-ietf- 669 geopriv-lis- 670 discovery-11 671 (work in 672 progress), 673 May 2009. 675 [I-D.ietf-geopriv-policy] Schulzrinne, H., 676 Tschofenig, H., 677 Morris, J., 678 Cuellar, J., and 679 J. Polk, 680 "Geolocation 681 Policy: A 682 Document Format 683 for Expressing 684 Privacy 685 Preferences for 686 Location 687 Information", dr 688 aft-ietf- 689 geopriv-policy- 690 21 (work in 691 progress), 692 July 2009. 694 [I-D.ietf-sip-location-conveyance] Polk, J. and B. 695 Rosen, "Location 696 Conveyance for 697 the Session 698 Initiation 699 Protocol", draft 700 -ietf-sip- 701 location- 702 conveyance-13 703 (work in 704 progress), 705 March 2009. 707 [I-D.winterbottom-geopriv-held-context] Winterbottom, 708 J., Tschofenig, 709 H., and M. 710 Thomson, 711 "Establishing 712 Location URI 713 Contexts using 714 HTTP-Enabled 715 Location 716 Delivery 717 (HELD)", draft- 718 winterbottom- 719 geopriv-held- 720 context-04 (work 721 in progress), 722 April 2009. 724 [I-D.winterbottom-geopriv-held-identity-extensions] Thomson, M., 725 Tschofenig, H., 726 Barnes, R., and 727 J. Winterbottom, 728 "Use of Target 729 Identity in 730 HTTP-Enabled 731 Location 732 Delivery 733 (HELD)", draft- 734 winterbottom- 735 geopriv-held- 736 identity- 737 extensions-09 738 (work in 739 progress), 740 February 2009. 742 [RFC3261] Rosenberg, J., 743 Schulzrinne, H., 744 Camarillo, G., 745 Johnston, A., 746 Peterson, J., 747 Sparks, R., 748 Handley, M., and 749 E. Schooler, 750 "SIP: Session 751 Initiation 752 Protocol", 753 RFC 3261, 754 June 2002. 756 [RFC3693] Cuellar, J., 757 Morris, J., 758 Mulligan, D., 759 Peterson, J., 760 and J. Polk, 761 "Geopriv 762 Requirements", 763 RFC 3693, 764 February 2004. 766 [RFC3851] Ramsdell, B., "S 767 ecure/ 768 Multipurpose 769 Internet Mail 770 Extensions 771 (S/MIME) Version 772 3.1 Message 773 Specification", 774 RFC 3851, 775 July 2004. 777 [RFC4745] Schulzrinne, H., 778 Tschofenig, H., 779 Morris, J., 780 Cuellar, J., 781 Polk, J., and J. 782 Rosenberg, 783 "Common Policy: 785 A Document 786 Format for 787 Expressing 788 Privacy 789 Preferences", 790 RFC 4745, 791 February 2007. 793 [RFC4825] Rosenberg, J., 794 "The Extensible 795 Markup Language 796 (XML) 797 Configuration 798 Access Protocol 799 (XCAP)", 800 RFC 4825, 801 May 2007. 803 [RFC5246] Dierks, T. and 804 E. Rescorla, 805 "The Transport 806 Layer Security 807 (TLS) Protocol 808 Version 1.2", 809 RFC 5246, 810 August 2008. 812 Appendix A. GEOPRIV Using Protocol Compliance 814 This section describes how use of HELD as a location dereference 815 protocol complies with the GEOPRIV requirements described in 816 [RFC3693]. 818 Req. 1. (Location Object generalities): 820 This section relates to the PIDF-LO [RFC4119] document, 821 which is used by HELD. These requirements are addressed by 822 [RFC4119] and [RFC5491]. 824 Req. 2. (Location Object fields): 826 This section relates to the PIDF-LO [RFC4119] document, 827 which is used by HELD. These requirements are addressed by 828 [RFC4119] and [RFC5491]. 830 Req. 3. (Location Data Types): 832 This section relates to the PIDF-LO [RFC4119] document, 833 which is used by HELD. These requirements are addressed by 834 [RFC4119] and [RFC5491]. 836 Section 7.2 of [RFC3693] details the requirements of a "Using 837 Protocol". These requirements are repeated here for reference, 838 followed by a statement of compliance: 840 Req. 4. "The using protocol has to obey the privacy and security 841 instructions coded in the Location Object and in the 842 corresponding Rules regarding the transmission and storage 843 of the LO." 845 Compliant: This document carries the PIDF-LO as is via 846 HTTPS from the LIS to the Location Recipient. The sending 847 and receiving parties must obey the instructions carried 848 inside the object. 850 Req. 5. "The using protocol will typically facilitate that the keys 851 associated with the credentials are transported to the 852 respective parties, that is, key establishment is the 853 responsibility of the using protocol." 855 Compliant: This document specifies that authentication of 856 the LS uses the established public key infrastructure used 857 by HTTP over TLS [RFC2818]. Location Recipient is 858 accomplished using certificates exchanged using TLS, or 859 through HTTP digest authentication [RFC2617]. 860 Authentication of Location Recipients as specified in this 861 document requires pre-arrangement; further key establishment 862 methods are left to later work. 864 Req. 6. "(Single Message Transfer) In particular, for tracking of 865 small target devices, the design should allow a single 866 message/packet transmission of location as a complete 867 transaction." 869 Not Compliant: The XML encoding specified in [RFC4119] is 870 not suited to single packet transfers. It is not the goal 871 of this document to define a new Location Object format. 873 Section 7.3 of [RFC3693] details the requirements of a "Rule based 874 Location Data Transfer". These requirements are repeated where they 875 are applicable to this document: 877 Req. 7. "(LS Rules) The decision of a Location Server to provide a 878 Location Recipient access to Location Information MUST be 879 based on Rule Maker-defined Privacy Rules." 881 Compliance or Not Applicable: This document describes two 882 alternative methods by which a Rule Maker is able to 883 control access to location information. Rule Maker policy 884 is enforced by the LS when a location URI is dereferenced. 885 However, this document does not describe how a location URI 886 is created, or how a Rule Maker associates policy with a 887 location URI. These are outside the scope of this 888 document. 890 Req. 8. (LG Rules) Not Applicable: This relationship between LS 891 and the source of its information (be that Location 892 Generator (LG) or LIS) is out of scope for this document. 894 Req. 9. "(Viewer Rules) A Viewer does not need to be aware of the 895 full Rules defined by the Rule Maker (because a Viewer 896 SHOULD NOT retransmit Location Information), and thus a 897 Viewer SHOULD receive only the subset of Privacy Rules 898 necessary for the Viewer to handle the LO in compliance 899 with the full Privacy Rules (such as, instruction on the 900 time period for which the LO can be retained)." 902 Compliant: The Rule Maker might define (via mechanisms 903 outside the scope of this document) which policy rules are 904 disclosed to other entities. For instance, if [RFC4745] is 905 used to convey authorization policies from Rule Maker to 906 LS, this is possible using the parameters specified in 907 [I-D.ietf-geopriv-policy]. 909 Req. 10. (Full Rule language) Not Applicable: Note however that 910 Geopriv has defined a rule language capable of expressing a 911 wide range of privacy rules (see [RFC4745] and 912 [I-D.ietf-geopriv-policy]. 914 Req. 11. (Limited Rule language) Not Applicable: This requirement 915 applies to (and is addressed by) PIDF-LO [RFC4119]. 917 Section 7.4 of [RFC3693] details the requirements of "Location Object 918 Privacy and Security". These requirements are repeated where they 919 are applicable to this document: 921 Req. 12. (Identity Protection) Potentially Compliant: Identity 922 protection of the Target is provided as long as both of the 923 following conditions are true: 925 (a) the location URI is not associated with the identity 926 of the Target in any context, and 928 (b) if the PIDF-LO does not contain information about the 929 identity about the Target. 931 For instance, this requirement is complied with if the 932 protocol that conveys the location URI does not link the 933 identity of the Target to the location URI and the LS 934 doesn't include meaningful identification information in 935 the PIDF-LO document. Section 6 recommends that an 936 unlinked pseudonym is used by the LS. 938 Req. 13. (Credential Requirements) Compliant: The primary security 939 mechanism specified in this document is Transport Layer 940 Security. TLS offers the ability to use different types of 941 credentials, including symmetric, asymmetric credentials or 942 a combination of them. 944 Req. 14. (Security Features) Compliant: Geopriv defines a few 945 security requirements for the protection of Location 946 Objects such as mutual end-point authentication, data 947 object integrity, data object confidentiality and replay 948 protection. The ability to use Transport Layer security 949 fulfills these requirements. 951 Req. 15. (Minimal Crypto) Compliant: The mandatory to implement 952 ciphersuite is provided in the TLS layer security 953 specification. 955 Appendix B. Compliance to Location Reference Requirements 957 This section describes how HELD complies to the location reference 958 requirements stipulated in [I-D.ietf-geopriv-lbyr-requirements]. 959 Compliance to the Location Configuration Protocol are included in 960 this document. 962 Note that use of HELD as a location dereference protocol does not 963 necessarily imply that HELD is the corresponding LCP. This 964 document is still applicable to "held:" location URIs that are 965 acquired by other means. 967 B.1. Requirements for a Location Configuration Protocol 968 C1. "location URI support: The configuration protocol MUST support 969 a location reference in URI form." 971 Compliant: HELD only provides location references in URI form. 973 C2. "location URI expiration: When a location URI has a limited 974 validity interval, its lifetime MUST be indicated." 976 Compliant: HELD indicates the expiry time of location URIs 977 using the "expires" attribute. HELD contexts 978 [I-D.winterbottom-geopriv-held-context] also expire, and an 979 explicit indication is included in the context response; a 980 Device is able to specify limits on the life time of a HELD 981 context. 983 C3. "location URI cancellation: The location configuration 984 protocol MUST support the ability to request a cancellation of 985 a specific location URI." 987 Compliant conditional on on the source of the location URI: 988 HELD contexts [I-D.winterbottom-geopriv-held-context] can be 989 explicitly removed. HELD does not provide a method for 990 cancelling location URIs. 992 C4. "Location Information Masking: The location URI form MUST, 993 through randomization and uniqueness, ensure that any location 994 specific information embedded within the location URI itself is 995 kept obscure during location configuration." 997 Compliant: The HELD specification explicitly references this 998 requirement in providing guidance on the format of the location 999 URI. 1001 C5. "User Identity Protection: The location URI MUST NOT contain 1002 any user identifying information that identifies the user, 1003 device or address of record, (e.g., which includes phone 1004 extensions, badge numbers, first or last names, etc.), within 1005 the URI form." 1007 Compliant: The HELD specification provides specific guidance 1008 on the anonymity of the Target with regards to the generation 1009 of location URIs. Section 6 expands on this guidance. 1011 C6. "Reuse indicator: There SHOULD be a way to allow a client to 1012 control whether a location URI can be resolved once only, or 1013 multiple times." 1015 Compliant: The default semantics of location URIs in HELD 1016 place no limits on the number of times that a location URI can 1017 be dereferenced. 1019 C7. "Validity Interval Indication: A location configuration 1020 protocol MUST provide an indication of the location URI 1021 validity interval (i.e., expiry time) when present." 1023 Duplicate Requirement: As above. 1025 C8. "Location only: The location URI MUST NOT point to any 1026 information about the Target other than it's location." 1028 Compliance depends on implementation: A PIDF-LO document can 1029 contain information other than location, but no protocol 1030 semantics exist that allow for or encourage inclusion of other 1031 information. 1033 C9. "Location URI Not guessable: Where location URIs are used 1034 publicly, any location URI MUST be constructed using properties 1035 of uniqueness and cryptographically random sequences so that it 1036 is not guessable." 1038 Compliant: HELD specifies that location URIs conform to this 1039 requirement. 1041 C10. "Location URI Optional: In the case of user-provided 1042 authorization policies, where anonymous or non-guessable 1043 location URIs are not warranted, the location configuration 1044 protocol MAY support optional location URI forms." 1046 Not Compliant: HELD does not support Device-specified location 1047 URI forms. 1049 C11. "Location URI Authorization Model: The location configuration 1050 protocol SHOULD indicate whether the requested location URI 1051 conforms to the access control authorization model or the 1052 possession authorization model." 1054 Compliant: HELD explicitly indicates that the possession model 1055 applies to all URIs. 1057 C12. "Location URI Lifetime: A location URI SHOULD have an 1058 associated expiration lifetime (i.e., validity interval), and 1059 MUST have an validity interval if used with the possession 1060 authorization model." 1062 Duplicate Requirement: As above. 1064 B.2. Requirements for a Location Dereference Protocol 1066 D1. "Location URI support: The location dereference protocol MUST 1067 support a location reference in URI form." 1069 Compliant: HELD only provides location references in URI form. 1071 D2. "Validity Interval Indication: A location dereference protocol 1072 MUST provide an indication of the location URI validity 1073 interval (i.e., expiry time) when present." 1075 Invalid Requirement: not applicable to location dereference 1076 protocols. 1078 D3. "Authentication: The location dereference protocol MUST 1079 include mechanisms to authenticate both the client and the 1080 server." 1082 Compliant: TLS provides means for mutual authentication. This 1083 document only specifies the required mechanism for server 1084 authentication. 1086 D4. "Dereferenced Location Form: The value returned by the 1087 dereference protocol MUST contain a well-formed PIDF-LO 1088 document." 1090 Compliant: HELD requires that location objects are in the form 1091 of a PIDF-LO that complies with [RFC5491]. 1093 D5. "Location URI Repeated Use: The location dereference protocol 1094 MUST support the ability for the same location URI to be 1095 resolved more than once, based on dereference server 1096 configuration." 1098 Compliant: A Location Recipient may access and use a location 1099 URI as many times as desired until URI expiration results in 1100 the URI being invalidated. Authorization policies might 1101 include rules that modify this behavior. 1103 D6. "Validity Interval Indication: A dereference protocol MUST 1104 provide an indication of the location URI validity interval 1105 (i.e., expiry time) when present." 1107 Not Compliant: This document does not provide this indication 1108 - this information is arguably useful to a Location Recipient, 1109 but it also reveals something about the policy associated with 1110 the location URI. Without also providing a mechanism to 1111 suppress this capability and hide the expiry time, this might 1112 reveal more information than a Rule Maker is willing to share. 1114 D7. "Location URI anonymized: Any location URI whose dereference 1115 will not be subject to authentication and access control MUST 1116 be anonymized." 1118 Not applicable to location dereference protocols - applies to 1119 the creation of the URI. 1121 D8. "Location Information Masking: The location URI form MUST, 1122 through randomization and uniqueness, ensure that any location 1123 specific information embedded within the location URI itself is 1124 kept obscure during location URI dereferencing." 1126 Not applicable to location dereference protocols - applies to 1127 the creation of the URI. 1129 D9. "Location Privacy: The location dereference protocol MUST 1130 support the application of privacy rules to the dissemination 1131 of a requested location object." 1133 Compliant: Authorization policy must be applied by the LS for 1134 all attempts at dereferencing. Note that in the case of 1135 authorization by possession, this authorization policy grants 1136 access to location information based on proof of knowledge of 1137 the location URI. 1139 D10. "Location Confidentiality: The dereference protocol MUST 1140 support encryption of messages sent between the location 1141 dereference client and the location dereference server, and MAY 1142 alternatively provide messaging unencrypted." 1144 Compliant: This document strongly recommends the use of TLS 1145 for confidentiality. Unsecured HTTP is permitted, and some of 1146 the associated risks are described in Section 4.1. 1148 D11. "Location URI Authorization Model: The location dereference 1149 protocol SHOULD indicate whether the requested location URI 1150 conforms to the access control authorization model or the 1151 possession authorization model." 1153 Not Compliant: The basis of an authorization decision is 1154 potentially private information; this document does not provide 1155 this indication. Note that the recipient of a location URI is 1156 expected to respect the confidentiality of a location URI as if 1157 it were secret, even if it is not. 1159 Authors' Addresses 1161 James Winterbottom 1162 Andrew Corporation 1163 PO Box U40 1164 University of Wollongong, NSW 2500 1165 AU 1167 Phone: +61 242 212938 1168 EMail: james.winterbottom@andrew.com 1169 URI: http://www.andrew.com/products/geometrix 1171 Hannes Tschofenig 1172 Nokia Siemens Networks 1173 Linnoitustie 6 1174 Espoo 02600 1175 Finland 1177 Phone: +358 (50) 4871445 1178 EMail: Hannes.Tschofenig@gmx.net 1179 URI: http://www.tschofenig.priv.at 1181 Henning Schulzrinne 1182 Columbia University 1183 Department of Computer Science 1184 450 Computer Science Building, New York, NY 10027 1185 US 1187 Phone: +1 212 939 7004 1188 EMail: hgs@cs.columbia.edu 1189 URI: http://www.cs.columbia.edu 1191 Martin Thomson 1192 Andrew Corporation 1193 PO Box U40 1194 University of Wollongong, NSW 2500 1195 AU 1197 EMail: martin.thomson@andrew.com 1198 Martin Dawson 1199 Andrew Corporation 1200 PO Box U40 1201 University of Wollongong, NSW 2500 1202 AU 1204 EMail: martin.dawson@andrew.com