idnits 2.17.00 (12 Aug 2021) /tmp/idnits8397/draft-winterbottom-geopriv-deref-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 964. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 975. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 982. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 988. 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 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 5, 2008) is 5068 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) == Outdated reference: draft-ietf-geopriv-http-location-delivery has been published as RFC 5985 ** Obsolete normative reference: RFC 2616 (ref. '2') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 2818 (ref. '3') == Outdated reference: draft-ietf-geopriv-pdif-lo-profile has been published as RFC 5491 == Outdated reference: draft-ietf-geopriv-lbyr-requirements has been published as RFC 5808 == Outdated reference: draft-ietf-geopriv-l7-lcp-ps has been published as RFC 5687 == Outdated reference: A later version (-05) exists of draft-barnes-geopriv-lo-sec-02 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-10 == Outdated reference: draft-ietf-geopriv-policy has been published as RFC 6772 == Outdated reference: A later version (-05) exists of draft-winterbottom-geopriv-held-context-02 == Outdated reference: draft-ietf-geopriv-lis-discovery has been published as RFC 5986 == Outdated reference: A later version (-01) exists of draft-garcia-simple-indirect-presence-publish-00 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 7 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 6, 2009 Nokia Siemens Networks 6 H. Schulzrinne 7 Columbia University 8 M. Thomson 9 M. Dawson 10 Andrew Corporation 11 July 5, 2008 13 An HTTPS Location Dereferencing Protocol Using HELD 14 draft-winterbottom-geopriv-deref-protocol-01.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 6, 2009. 41 Abstract 43 This document describes how to use the Hypertext Transfer Protocol 44 (HTTP) over Transport Layer Security (TLS) as a dereferencing 45 protocol to resolve a reference into a Presence Information Data 46 Format Location Object (PIDF-LO). The document assumes that a 47 Location Recipient possesses a secure HELD URI that can be used in 48 conjunction with the HELD protocol to request the location of the 49 Target. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Authorization Models . . . . . . . . . . . . . . . . . . . . . 6 56 3.1. Authorization by Possession . . . . . . . . . . . . . . . 6 57 3.2. Authorization via Access Control Lists . . . . . . . . . . 7 58 4. Steps for Retrieval . . . . . . . . . . . . . . . . . . . . . 9 59 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 64 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 65 9.2. Informative references . . . . . . . . . . . . . . . . . . 17 66 Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 19 67 Appendix B. HELD Compliance to IETF Location Reference 68 Requirements . . . . . . . . . . . . . . . . . . . . 24 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 70 Intellectual Property and Copyright Statements . . . . . . . . . . 29 72 1. Introduction 74 This document describes how to transport Presence Information Data 75 Format Location Object (PIDF-LO) when dereferencing a location URI in 76 the form of a secure HELD URI (held: URI scheme) [1]. This held: 77 URI indicates that the XML-based HELD messages are carried on top of 78 the Hypertext Transfer Protocol (HTTP), which is secured using 79 Transport Layer Security (TLS) ([2] and [3]). 81 The document describes how HELD [1] is used to request and to receive 82 location information in a way that also satisfies the requirements 83 laid out in [7]. HELD provides location information in the form of a 84 PIDF-LO (see [4]) which, as part of its definition, complies with the 85 requirements of a location object as described in [8]. 87 To use HELD as a dereferencing protocol has the advantage that the 88 Location Recipient can indicate the type of location information it 89 would like to receive. This functionality is already available with 90 the HELD base specification, described in [1]. Furthermore, the HELD 91 response from the LIS towards the Location Recipient not only 92 provides the PIDF-LO but also encapsulates supplementary information, 93 such as error messages, back to the Location Recipient. 95 The general usage scenario envisioned by this document is shown in 96 Figure 1. While the figure shows a typical HELD location request 97 being made to initially obtain the location URI. As Figure 1 98 indicates, an alternative Location Configuration Protocol (LCP) that 99 can provide a HELD URI can be used. 101 +-----------+ 102 +------------+ | Location | +-----------+ 103 | End Device | |Information| | Location | 104 | (Target) | | Server | | Recipient | 105 +-----+------+ +----+------+ +-----+-----+ 106 | | | 107 +--+--------------------------+--+ | 108 | | | | | 109 | |===locationRequest(URI)==>0 | | 110 | | | | Location | 111 | | | | Configuration | 112 | 0<==locationResponse(URI)==| | Protocol | 113 | | | | | 114 +--+--------------------------+--+ | 115 | | | 116 | | | 117 |~~~~~~~~~~~~Location Conveyance (URI)~~~~~~~~~~~~~~~~~~>0 118 | | | 119 | +--+-----------------------------+--+ 120 | | | | | 121 | | 0<===locationRequest(Civic)===| | 122 | Dereferencing | | | | 123 | Protocol | | | | 124 | | |==locationResponse(PIDF-LO)=>0 | 125 | | | | | 126 | +--+-----------------------------+--+ 127 | | | 128 | | | 130 Figure 1: Example of Dereference Protocol Exchange 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [5]. 138 The key conventions and terminology used in this document are defined 139 as follows: 141 This document reuses the term Target, as defined in [8]. 143 This document uses the term Location Information Server, LIS, as the 144 node in the access network providing location information to an end 145 point, or to the node dereferencing a location URI. This term is 146 also used in [9]. 148 The Location Recipient acts as a HELD client and the LIS as a HELD 149 server in the context of this document. 151 Many architectural descriptions related to the updated terminology of 152 RFC 3693 can be found in [10]. 154 3. Authorization Models 156 This section discusses two extreme types of authorization models for 157 dereferencing with HELD URIs, namely "Authorization by Possession" 158 and "Authorization via Access Control Lists". In the subsequent 159 subsections we discuss the properties of these two models. These two 160 models can, however, be used in combination in a real deployment. 161 Figure 2 shows the communication model relevant for this discussion. 162 It is a simplified version of Figure 1 from [7]. 164 +--------+ Dereferencing +-----------+ 165 | | Protocol (3) | | 166 | LIS +---------------+ Location | 167 | | | Recipient | 168 +---+----+ | | 169 | +----+------+ 170 | -- 171 | Location -- 172 | Configuration -- 173 | Protocol --- 174 | (1) -- Geopriv 175 | --- Using 176 | -- Protocol 177 +----+-----+ -- (2) 178 | Target / +-- 179 | End Host | 180 +----------+ 182 Figure 2: Communication Model 184 3.1. Authorization by Possession 186 With this type of authorization model the communication steps with 187 respect to Figure 2 are as follows. We focus on the description of 188 the case where the Location URI is dereferenced by an entity other 189 than the Target. 191 1. The Target discovers the LIS. 193 2. The Target sends a request to the LIS asking for a location-by- 194 reference, as shown in (1) of Figure 2. 196 3. The LIS responds to the request and returns a Location URI. This 197 reference fullfills the requirements indicated in [7], in 198 particular it must be non-guessable (see requirement C9 of [7]). 200 4. The Target then conveys the Location URI to a third party, the 201 Location Recipient (for example using SIP as described in [11]). 202 This step is shown in (2) of Figure 2. 204 5. The Location Recipient then needs to dereference the Location URI 205 in order to obtain the Location Object. Depending on the URI 206 scheme of the Location URI this might, for example in case of a 207 HELD URI, be done as described in this document. 209 The last step where the LIS has to decide whether to resolve the 210 reference and to return the Location Object to the entity asking for 211 it is important. With this authorization model there is the 212 assumption that the possession of the Location URI by the Location 213 Recipient alone is sufficient, from an authorization point of view, 214 to grant access to the Location Object that is being referenced by 215 the Location URI. As such, the Location Recipient authenticates the 216 LIS using TLS server-side authentication but no authentication from 217 the Location Recipient point of view is demanded. 219 A few aspects are worth further discussion when the Target would like 220 to avoid unrestricted disclosure of it's location information. 221 First, the Target is able to control the disclosure of location 222 information by making the Location URI available only to trusted 223 entities. Second, in order to deal with adversary along the 224 signaling path between the Target and the Location Recipient the 225 properties of the using protocol need to be taken advantage of. For 226 example, the Location URI may be encrypted end-to-end using S/MIME 227 and consequently only the entity that is able to decrypt the 228 protected object can resolve the reference. Depending on the usage 229 of the Location URI for certain location based applications (e.g., 230 emergency services, location based routing) specific treatment is 231 important, as discussed in [11]. 233 3.2. Authorization via Access Control Lists 235 In this model the communication steps are slightly different, as 236 shown below. 238 1. The procedure again starts with the Target performing the LIS 239 discovery procedure. 241 2. The Target sends a request to the LIS asking for a location-by- 242 reference, as shown in (1) of Figure 2. 244 3. Before handing out the reference the Target uploads authorization 245 policies to the LIS that aim to control access to the 246 dereferencing step. A possible format for these authorization 247 policies is available with GEOPRIV Common Policy [12] and 248 Geolocation Policy [13]. Additional policies are described in 249 [14] that allow constraints to be placed on the dereferencing 250 procedure to limit the location information being exposed to 251 Location Recipients. 253 4. The LIS responds to the request and returns a Location URI. With 254 the uploaded authorization policies in place there are no 255 requirements for the Location URI to be non-guessable. 257 5. The Target then conveys the Location URI to a third party, the 258 Location Recipient (for example using SIP as described in [11]). 259 This step is shown in (2) of Figure 2. 261 6. The Location Recipient then needs to dereference the Location URI 262 in order to obtain the Location Object. Depending on the 263 specific content of the authorization policies (such as identity- 264 based conditions in the policy rule set) the Location Recipient 265 has to be authenticated in order to allow the authorization check 266 to continue. 268 It is important to note that this document does not mandate a 269 specific authorization model nor does it constraint the usage with 270 regard to these models in any way. Additionally, it is possible to 271 combine certain parts of both models. 273 4. Steps for Retrieval 275 When a Location Recipient obtains a Location URI with the "held:" URI 276 scheme then the following steps for dereferencing the Location URI 277 are being executed: 279 1. The Location Recipient, acting as a HELD client, determines the 280 IP address of the LIS based on the obtained Location URI 281 following the procedure described in Section 3 of [15]. 283 2. The HELD client establishes a TLS connection to the LIS, as 284 described in [3]. The TLS ciphersuite TLS_NULL_WITH_NULL_NULL 285 MUST NOT be used. 287 3. When certificate based authentication is used the client 288 authenticates the server and compares the domain part of the 289 Location URI with the identity information in the certificate. 291 4. The server MAY require the client to be authenticated. This 292 could, for example, be useful in deployment environments where 293 certain Location Recipients are granted access to location 294 information only or where access control rules have to be 295 executed as part of the authorization procedure. Various 296 authentication mechanisms for HTTP exist and this document does 297 not restrict them in any way since the preferred mechanism may be 298 deployment specific. 300 5. The client retrieves the PIDF-LO document encapsulated into the 301 HELD locationResponse or an error message conveyed in a HELD 302 error message. 304 The subsequent text describes how HELD protected by TLS can be used 305 to qualify location requests to the LIS. Only a subset of HELD 306 functionality is required and is described in the following 307 paragraphs. The HELD based dereferencing step provides ways to tell 308 the LIS what information is desired and allows the LIS to communicate 309 additional information back to the client. 311 The element allows location to be requested in a 312 specific form, such as civic or geodetic location information. The 313 Location Recipient SHOULD NOT request location as a locationURI. The 314 LIS MUST respond with a "requestError" if it receives a request for a 315 locationURI where HELD is being used as a dereference protocol. 316 Location information provided by the LIS MUST correspond to the rules 317 and guidelines in [6]. If the requested form of location violates 318 any authorization policies known to the LIS, then the LIS MUST 319 respond with a "cannotProvideLiType" error. 321 The LIS will provide location information on request even if the 322 location information does not fit the form requested. This stems 323 from the premise that some location is better than no location. HELD 324 provides a means for the requestor to modify this behaviour and 325 instruct the LIS to return an error if location information is not 326 available in the form requested. This is done using the "exact" 327 attribute. 329 Location systems often have more than one location determination 330 mechanism at their disposal. Differing determination techniques 331 provide different degrees of accuracy over differing periods of time. 332 Generally, more accurate determination techniques require more time. 333 HELD addresses this trade-off by allowing the requestor to specify 334 how long they are prepared to wait for a location result. This 335 allows the LIS to select the most accurate determination technique at 336 its disposal that can return a result in the specified time. The 337 HELD attribute for specifying this value is the "responseTime" 338 attribute and MAY be used by a Location Recipient to specify their 339 preference for the accuracy-time trade-off. 341 The LIS MUST support the HELD locationRequest semantic using an HTTP 342 GET as described in [1]. The usage of HTTP POST is optional. 344 Where the LIS is unable to process the Location Recipient's request, 345 it MUST return the appropriate error from the existing HELD error set 346 defined in [1]. 348 5. Examples 350 This example in Figure 3 shows the most basic rereferencing request 351 for a LO. This uses the GET feature described by the HTTP binding 352 from Section 9 of [1]. This example assumes that the LO is available 353 for retrieval at the URL 354 "https://lis.example.com/357yc6s64ceyoiuy5ax3o". 356 GET /357yc6s64ceyoiuy5ax3o HTTP/1.1 357 Host: lis.example.com 358 Accept:application/held+xml, 359 application/xml;q=0.8, 360 text/xml;q=0.7 361 Accept-Charset: UTF-8,* 363 Figure 3: Minimal GET Dereferencing Request 365 The GET request is exactly identical to a minimal POST request that 366 includes an empty "locationRequest" element. 368 POST /357yc6s64ceyoiuy5ax3o HTTP/1.1 369 Host: lis.example.com 370 Accept: application/held+xml, 371 application/xml;q=0.8, 372 text/xml;q=0.7 373 Accept-Charset: UTF-8,* 374 Content-Type: application/held+xml 375 Content-Length: 87 377 378 380 Figure 4: Minimal POST Dereferencing Request 382 Figure 5 shows a request indicating that both civic and geodetic 383 location information has to be returned. If it cannot be provided, 384 the request fails. 386 POST /357yc6s64ceyoiuy5ax3o HTTP/1.1 387 Host: lis.example.com 388 Accept: application/held+xml, 389 application/xml;q=0.8, 390 text/xml;q=0.7 391 Accept-Charset: UTF-8,* 392 Content-Type: application/held+xml 393 Content-Length: 87 395 396 397 398 civic 399 geodetic 400 401 403 Figure 5: Dereferencing POST Request for Civic and Geodetic Location 404 Information 406 Figure 6 shows the response to the previous request listing both 407 civic and geodetic location information of the Target's location. 409 HTTP/1.x 200 OK 410 Server: Example LIS 411 Date: Tue, 10 Jan 2006 03:42:29 GMT 412 Expires: Tue, 10 Jan 2006 03:49:20 GMT 413 Content-Type: application/held+xml 414 Content-Length: XYZ 416 417 418 420 421 422 423 424 428 -34.407242 150.882518 429 30 430 431 432 435 AU 436 NSW 437 Wollongong 438 Gwynneville 439 Northfield Avenue 440 University of Wollongong 441 2 442 Andrew Corporation 443 2500 444 39 445 WS-183 446 U40 447 448 449 450 false 451 2007-05-25T12:35:02+10:00 452 453 454 Wiremap 455 456 457 2007-05-24T12:35:02+10:00 458 459 460 462 Figure 6: Response with Civic and Geodetic Location Information 464 Figure 7 shows an error message returned in response to a request. 466 HTTP/1.x 200 OK 467 Server: Example LIS 468 Expires: Tue, 10 Jan 2006 03:49:20 GMT 469 Content-Type: application/held+xml 470 Content-Length: XYZ 472 477 Figure 7: Error Message 479 6. Security Considerations 481 This document assumes that the use of TLS to protect HTTP is 482 sufficient to protect the privacy of the PIDF-LO content while in 483 flight. When access control at the LIS is not applied, as described 484 in Section 3.1, then the possession of the location URI is equal to 485 the possession of location information. When the requirements for 486 creating a location URI, as described in [7], are met, then the 487 reference provides sufficiently high security guarantees for most 488 location-based applications. Furthermore, the ability of the Rule 489 Maker to put constraints on the dereferencing step, as described in 490 [14], provides the ability to restrict how often location can be 491 accessed through a location URI, how long the URI is valid for, and 492 the type of location information returned when a location URI is 493 accessed. If this is still not sufficient then the Target is able to 494 put authorization policies either to the LIS or uploads the Location 495 URI to a presence server that hosts authorization policies, as 496 described in [16]. 498 Connection establishment from the Location Recipient to the LIS will 499 be made using HTTP over TLS, and the location URI being dereferenced 500 by the Location Recipient will contain the hostname of the LIS. The 501 Location Recipient MUST check the FQDN of the LIS in the reference 502 with the identity presented in the server's certificate. A 503 discrepancy may indicate a possible man-in-the-middle-attack, and the 504 Location Recipient should take appropriate action based on 505 application dependent semantics. Actions may include but are not 506 limited to; proceeding anyway, flagging the result as suspect, or 507 giving up. 509 In some applications the Location Recipient has a pre-established 510 relationship with one or several Location Information Servers and 511 hence the LIS might authorize only certain Location Recipients might 512 be allowed to resolve a reference. 514 7. IANA Considerations 516 There are no specific IANA considerations for this document. 518 8. Acknowledgements 520 Thanks to Barbara Stark and Guy Caron for providing early comments. 521 Thanks to Rohan Mahy for constructive comments on the scope and 522 format of the document. Thanks to Ted Hardie for his strawman 523 proposal that provided assistance with the security section of this 524 document. 526 The authors would like to thank the participants of the GEOPRIV 527 interim meeting 2008 for their feedback. 529 James Polk provided comments on a security aspects in June 2008. 531 9. References 533 9.1. Normative References 535 [1] Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, "HTTP 536 Enabled Location Delivery (HELD)", 537 draft-ietf-geopriv-http-location-delivery-07 (work in 538 progress), April 2008. 540 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 541 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 542 HTTP/1.1", RFC 2616, June 1999. 544 [3] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 546 [4] Peterson, J., "A Presence-based GEOPRIV Location Object 547 Format", RFC 4119, December 2005. 549 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 550 Levels", BCP 14, RFC 2119, March 1997. 552 [6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 553 PIDF-LO Usage Clarification, Considerations and 554 Recommendations", draft-ietf-geopriv-pdif-lo-profile-11 (work 555 in progress), February 2008. 557 9.2. Informative references 559 [7] Marshall, R., "Requirements for a Location-by-Reference 560 Mechanism", draft-ietf-geopriv-lbyr-requirements-02 (work in 561 progress), February 2008. 563 [8] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. 564 Polk, "Geopriv Requirements", RFC 3693, February 2004. 566 [9] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location 567 Configuration Protocol; Problem Statement and Requirements", 568 draft-ietf-geopriv-l7-lcp-ps-08 (work in progress), June 2008. 570 [10] Barnes, R., Lepinski, M., Tschofenig, H., and H. Schulzrinne, 571 "Security Requirements for the Geopriv Location System", 572 draft-barnes-geopriv-lo-sec-02 (work in progress), 573 February 2008. 575 [11] Polk, J. and B. Rosen, "Location Conveyance for the Session 576 Initiation Protocol", draft-ietf-sip-location-conveyance-10 577 (work in progress), February 2008. 579 [12] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, 580 J., and J. Rosenberg, "Common Policy: A Document Format for 581 Expressing Privacy Preferences", RFC 4745, February 2007. 583 [13] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and 584 J. Polk, "Geolocation Policy: A Document Format for Expressing 585 Privacy Preferences for Location Information", 586 draft-ietf-geopriv-policy-17 (work in progress), June 2008. 588 [14] Winterbottom, J., Tschofenig, H., and M. Thomson, "HELD 589 Protocol Context Management Extensions", 590 draft-winterbottom-geopriv-held-context-02 (work in progress), 591 February 2008. 593 [15] Thomson, M. and J. Winterbottom, "Discovering the Local 594 Location Information Server (LIS)", 595 draft-ietf-geopriv-lis-discovery-01 (work in progress), 596 June 2008. 598 [16] Garcia-Martin, M., Tschofenig, H., and H. Schulzrinne, 599 "Indirect Presence Publication with the Session Initiation 600 Protocol(SIP)", 601 draft-garcia-simple-indirect-presence-publish-00 (work in 602 progress), February 2008. 604 Appendix A. GEOPRIV Using Protocol Compliance 606 This section compares the GEOPRIV requirements described in [8] with 607 the approach outlined in this document. 609 Req. 1. (Location Object generalities): 611 o Regarding requirement 1.1, the Location Object has to be 612 understood by the Location Recipient and the Location Server, the 613 two communication end points. The PIDF-LO [4] allows both civic 614 and geospatial location information to be expressed. Combining 615 this with [6] ensures that location can be constructed and 616 interpreted in a consistent manner. 618 o Regarding requirement 1.2, a number of fields in the civic 619 location information format are optional. 621 o Regarding requirement 1.3, the civic location information is 622 defined in an extensible way. 624 o Regarding requirement 1.4, the location information itself is not 625 defined in this document. 627 o Regarding requirement 1.5, the protocol described in this document 628 allows the Location Recipient to resolve a reference to a PIDF-LO 629 only. 631 o Regarding requirement 1.6, the Location Object contains both 632 location information and privacy rules. Depending on the 633 deployment scenario, which is outside the scope of this document, 634 the privacy rules might have stronger or a weaker semantic. 636 o Regarding requirement 1.7, the Location Object is usable in a 637 variety of protocols. 639 o Regarding requirement 1.8, no change regarding with respect to the 640 encoding of the Location Object (see [4]) was made by this 641 document. 643 Req. 2. (Location Object fields): 645 o Regarding requirement 2.1, depending on the deployment scenario an 646 identifier pointing to the Target may be carried inside the 647 PIDF-LO since the PIDF object provides the ability to carry this 648 identifier. In some circumstances it might be desirable not to 649 carry information about the Target's identity in the PIDF-LO. 651 o Regarding requirement 2.2, depending on the deployment scenario 652 the LIS might require that the Location Recipient performs an 653 authentication step. The security mechanisms for client and 654 server authentication are outside the scope of this document and 655 defined already for HTTPS itself. 657 o Regarding requirement 2.3, proof of possession of the Location 658 Recipient credentials is provided outside the scope of this 659 document. The security mechanisms defined for HTTPS are used by 660 this document. 662 o Regarding requirement 2.5, RFC 4119 defines the basis for carrying 663 location information in a PIDF document. The ability to extend 664 RFC 4119 to convey motion specific information is work in 665 progress. 667 o Regarding requirement 2.6, this document as specified only allows 668 the Location Recipient to resolve the reference and to indicate 669 which location format has to be returned. 671 o Regarding requirement 2.7, the PIDF-LO relevant elements and 672 attributes are available. 674 o Regarding requirement 2.8, provision exists for a reference to an 675 external (more detailed rule set) within the PIDF-LO to be made. 676 This is the element. 678 o Regarding requirement 2.9, security headers and trailers are 679 provided Transport Layer Security. 681 o Regarding requirement 2.10, extensibility within the PIDF-LO is 682 provided regarding the definition of namespaces. 684 Req. 3. (Location Data Types): 686 o Regarding requirement 3.1, [4] defines geospatial location 687 information as the mandatory to implement location format. [6] 688 describes in more detail the acceptable forms of geolocation and 689 its interaction with civic notations. 691 o With the support of civic and geodedic location information in [4] 692 the requirement 3.2 is fulfilled. 694 o Regarding requirement 3.3, rules described in [13] apply to an 695 absolute geodetic point. Geodetic information expressed in a 696 PIDF-LO that complies with [6] may express an area or volume 697 there-by "fuzzing" the location of the Target. 699 o Regarding requirement 3.4, since the PIDF-LO format is designed to 700 be extensible it allows further location information types to be 701 defined in the future. 703 Section 7.2 of [8] details the requirements of a "Using Protocol". 704 These requirements are listed below: 706 Req. 4. The using protocol has to obey the privacy and security 707 instructions coded in the Location Object regarding the 708 transmission and storage of the LO. This document carries 709 the PIDF-LO as is via HTTPS from the LIS to the Location 710 Recipient. The sending and receiving parties must obey the 711 instructions carried inside the object. 713 Req. 5. The using protocol will typically facilitate that the keys 714 associated with the credentials are transported to the 715 respective parties, that is, key establishment is the 716 responsibility of the using protocol. This document does 717 not define additional security mechanisms beyond HTTPS. 719 Req. 6. (Single Message Transfer): In particular, for tracking of 720 small target devices, the design should allow a single 721 message / packet transmission of location as a complete 722 transaction. The encoding of the RFC 4119-defined Location 723 Object format is not changed. Because of the verbose XML 724 encoding it is not tailored towards inclusion into a single 725 message. 727 Section 7.3 of [8] details the requirements of a "Rule based Location 728 Data Transfer". These requirements are listed below: 730 Req. 7. (LS Rules): Access to location information is controlled by 731 allowing the Target (or by an entity on behalf of the 732 Target) to indicate to which Location Recipients the short- 733 lived location URI that contains a unguessable random 734 component. Additionally, constraints can be put on the 735 dereferencing step by the Target. 737 Req. 8. (LG Rules): In context of location URI it is not possible 738 that there is no relationship between the Location Generator 739 and the Location Information Server. As such, the statement 740 made in Requirement 7 applies. 742 Req. 9. (Viewer Rules): The Rule Maker might define (via mechanisms 743 outside the scope of this document) which policy rules are 744 disclosed to other entities. These mechanisms are available 745 with [13]. These rules are, however, best used when the 746 location URI is not directly provided to Location Recipients 747 but rather to an intermediary that stores these 748 authorization policies, such as a location-based presence 749 server. 751 Req. 10. (Full Rule language): Geopriv has defined a rule language 752 capable of expressing a wide range of privacy rules which 753 is applicable in the area of the distribution of Location 754 Objects. The format of these rules are described in [12] 755 and [13]. These rules may be used in a larger context but 756 this document does not define their usage. 758 Req. 11. (Limited Rule language): A limited (or basic) ruleset was 759 introduced with PIDF-LO [4]). 761 Section 7.4 of [8] details the requirements of "Location Object 762 Privacy and Security". These requirements are listed below: 764 Req. 12. (Identity Protection): Identity protection of the Target 765 can be provided if both the following conditions are true: 767 (a) the protocol used to convey the reference does not 768 disclose the identity of the Target and 770 (b) if the PIDF-LO does not contain information about the 771 identity about the Target. 773 Currently, there is no mechanism available that allows the 774 Target to tell the LIS which identity information to 775 include in the PIDF-LO. 777 Req. 13. (Credential Requirements): The security mechanism 778 specified in this document is Transport Layer Security. 779 TLS offers the ability to use different types of 780 credentials, including symmetric, asymmetric credentials or 781 a combination of them. 783 Req. 14. (Security Features): Geopriv defines a few security 784 requirements for the protection of Location Objects such as 785 mutual end-point authentication, data object integrity, 786 data object confidentiality and replay protection. The 787 ability to use Transport Layer security fulfills these 788 requirements. 790 Req. 15. Minimal Crypto: The mandatory to implement ciphersuite is 791 provided in the TLS layer security specification. 793 Appendix B. HELD Compliance to IETF Location Reference Requirements 795 This section describes how HELD complies to the location reference 796 requirements stipulated in [7]. 798 High-level requirements for a location configuration protocol. 800 C1. "Location URI support - LCP: The configuration protocol MUST 801 support a location reference in URI form." 803 COMPLY. HELD only provides location references in URI form. 805 C2. "Location URI expiration: The LCP MUST support the ability to 806 specify to the server, the length of time that a location URI 807 will be valid." 809 COMPLY. basic HELD supports the LIS informing the Target of the 810 location URI expiry time. HELD context management extension 811 [14] provides the Target the ability to specify exipry times for 812 location URIs. 814 C3. "Location URI cancellation: The LCP MUST support the ability to 815 request the cancellation of a specific location URI." 817 COMPLY. HELD context management extension [14] provides the 818 Target the ability to void location URIs when required. 820 C4. "Random Generated: The location URI MUST be hard to guess, i.e., 821 it MUST contain a cryptographically random component." 823 COMPLY. The HELD specification provides specific guidance on 824 the security surrounding location URI generation. 826 C5. "Identity Protection - LCP: The location URI MUST NOT contain 827 any information that identifies the user, device or address of 828 record within the URI form." 830 COMPLY. The HELD specification provides specific guidance on 831 the anonymity of the Target with regards to the generation of 832 location URIs. 834 C6. "Reuse flag default: The LCP MUST support the default condition 835 of a requested location URI being repeatedly reused." 837 COMPLY. The default semantics of location URIs in HELD place no 838 limits on the number of times that a location URI can be 839 dereferenced. 841 C7. "One-time-use: The LCP MUST support the ability for the client 842 to request a 'one-time-use' location URI (e.g., via a reuse flag 843 setting)." 845 COMPLY. HELD context management extension [14] provides the 846 Target the ability to set the number of times that a location 847 URI may yield the Target's location. 849 High-level requirements for a location dereference protocol. 851 D1. "Location URI support - LDP: The LDP MUST support a location 852 reference in URI form." 854 COMPLY. HELD only provides location references in URI form. 856 D2. "Location URI expiration status: The LDP MUST support a message 857 indicating that for a location URI which is no longer valid, 858 that the location URI has expired." 860 COMPLY. HELD indicates to the requestor that location for the 861 URI cannot be provided by returning a locationUnknown error when 862 a location URI is found to have expired. 864 D3. "Authentication: The LDP MUST support either client-side and 865 server-side authentication between client and server." 867 COMPLY. Client authentication may be provided using a variety 868 of techniques. However, this document does not mandate a 869 specific procedure nor does it specify the format of 870 authorization policies that may be in place to control access at 871 the LIS. The server authenticates itself using the methods 872 described in HTTP on TLS [3]. 874 D4. "Dereferenced Location Form: Location URI dereferencing MUST 875 result in a well-formed PIDF-LO." 877 COMPLY. HELD when used as a dereference protocol MUST provide 878 location information as a PIDF-LO that complies with [6] as 879 described in Section 4. 881 D5. "Repeated use: The LDP MUST support the ability for the same 882 location URI to be resolved more than once, based on server 883 settings and LCP parameters." 885 COMPLY. A Location Recipient may access and use a location URI 886 as many times as desired until such time as the URI expires due 887 to age, or is made invalid by other Target policies on the LIS. 889 D6. "Updated location: The LDP MUST support the ability for the same 890 location URI to be resolved into a continuum of location values 891 (e.g., location updates)." 893 COMPLY. Using base-HELD the location of the Target is 894 determined each time that URI is accessed. 896 D7. "Location form: The LDP MUST support dereferenced location in 897 both coordinate and civic forms." 899 COMPLY. HELD provide the locationType parameter allowing the 900 Location Recipient the ability to specify the form of location 901 they require. 903 Authors' Addresses 905 James Winterbottom 906 Andrew Corporation 907 PO Box U40 908 University of Wollongong, NSW 2500 909 AU 911 Phone: +61 242 212938 912 Email: james.winterbottom@andrew.com 913 URI: http://www.andrew.com/products/geometrix 915 Hannes Tschofenig 916 Nokia Siemens Networks 917 Linnoitustie 6 918 Espoo 02600 919 Finland 921 Phone: +358 (50) 4871445 922 Email: Hannes.Tschofenig@gmx.net 923 URI: http://www.tschofenig.priv.at 925 Henning Schulzrinne 926 Columbia University 927 Department of Computer Science 928 450 Computer Science Building, New York, NY 10027 929 US 931 Phone: +1 212 939 7004 932 Email: hgs@cs.columbia.edu 933 URI: http://www.cs.columbia.edu 935 Martin Thomson 936 Andrew Corporation 937 PO Box U40 938 University of Wollongong, NSW 2500 939 AU 941 Email: martin.thomson@andrew.com 942 Martin Dawson 943 Andrew Corporation 944 PO Box U40 945 University of Wollongong, NSW 2500 946 AU 948 Email: martin.dawson@andrew.com 950 Full Copyright Statement 952 Copyright (C) The IETF Trust (2008). 954 This document is subject to the rights, licenses and restrictions 955 contained in BCP 78, and except as set forth therein, the authors 956 retain all their rights. 958 This document and the information contained herein are provided on an 959 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 960 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 961 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 962 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 963 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 964 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 966 Intellectual Property 968 The IETF takes no position regarding the validity or scope of any 969 Intellectual Property Rights or other rights that might be claimed to 970 pertain to the implementation or use of the technology described in 971 this document or the extent to which any license under such rights 972 might or might not be available; nor does it represent that it has 973 made any independent effort to identify any such rights. Information 974 on the procedures with respect to rights in RFC documents can be 975 found in BCP 78 and BCP 79. 977 Copies of IPR disclosures made to the IETF Secretariat and any 978 assurances of licenses to be made available, or the result of an 979 attempt made to obtain a general license or permission for the use of 980 such proprietary rights by implementers or users of this 981 specification can be obtained from the IETF on-line IPR repository at 982 http://www.ietf.org/ipr. 984 The IETF invites any interested party to bring to its attention any 985 copyrights, patents or patent applications, or other proprietary 986 rights that may cover technology that may be required to implement 987 this standard. Please address the information to the IETF at 988 ietf-ipr@ietf.org.