idnits 2.17.00 (12 Aug 2021) /tmp/idnits60618/draft-winterbottom-geopriv-held-context-05.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 (October 21, 2009) is 4588 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: 'RFC3693' is defined on line 848, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2818 == Outdated reference: draft-ietf-geopriv-http-location-delivery has been published as RFC 5985 == Outdated reference: draft-ietf-geopriv-arch has been published as RFC 6280 == 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 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 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 24, 2010 Nokia Siemens Networks 6 M. Thomson 7 Andrew Corporation 8 October 21, 2009 10 Location URI Contexts in HTTP-Enabled Location Delivery (HELD) 11 draft-winterbottom-geopriv-held-context-05 13 Status of This Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 24, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document describes a protocol extension for the HTTP-Enabled 50 Location Delivery (HELD) protocol. It allows a Target to manage 51 their location information on a Location Information Server (LIS) 52 through the application of constraints invoked by accessing a 53 location URI. Constraints are described that allow control over how 54 long the URI is valid for and the access policy used when a location 55 URI is accessed. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. HELD Contexts . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Simplified Model . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Authorization Policies . . . . . . . . . . . . . . . . . . 5 64 3.3. Context Lifetime . . . . . . . . . . . . . . . . . . . . . 6 65 3.4. Snapshot Contexts . . . . . . . . . . . . . . . . . . . . 6 66 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. Create Context . . . . . . . . . . . . . . . . . . . . . . 7 68 4.2. Update Context . . . . . . . . . . . . . . . . . . . . . . 8 69 4.3. Context Response Message . . . . . . . . . . . . . . . . . 10 70 4.4. Context Errors . . . . . . . . . . . . . . . . . . . . . . 11 71 4.5. Location URI and Context Identifier Generation Rules . . . 12 72 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 74 6.1. Multiple Contexts from the 'Same' Target . . . . . . . . . 16 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 76 7.1. URN Sub-Namespace Registration for 77 urn:ietf:params:xml:ns:geopriv:held:context . . . . . . . 17 78 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 17 79 7.3. HELD Error Code Registration . . . . . . . . . . . . . . . 18 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 84 Appendix A. Compliance to Location by Reference Requirements . . 20 86 1. Introduction 88 The HTTP Enabled Location Delivery (HELD) protocol specification 89 [I-D.ietf-geopriv-http-location-delivery] provides a set of features 90 that can be used by a Target to retrieve location information from a 91 Location Information Server (LIS). The LIS is able to optionally 92 provide a location URI [I-D.ietf-geopriv-lbyr-requirements], which 93 provides a reference to location information. 95 A location URI that is provided by a LIS using the basic HELD 96 specification, is essentially immutable once retrieved. There is no 97 means provided of controlling how the URI is used. A default policy 98 is applied to the URI, which is fixed until the location URI expires; 99 a Location Recipient in possession of the location URI can retrieve 100 the Target's location until the expiry time lapses. 102 This basic mechanism may be reasonable in a limited set of 103 applications, but is unacceptable in a broader range of applications. 104 In particular, the ability to change policy dynamically is more able 105 to protect the privacy of the Target. 106 [I-D.ietf-geopriv-lbyr-requirements] enumerates several requirements 107 relating to location URIs that cannot be achieved using the basic 108 HELD specification. This specification addresses these requirements 109 in HELD. 111 Two new forms of HELD request are defined by this document. These 112 requests relate to the creation and maintenance of a _HELD context_, 113 a concept that is explained in more detail in Section 3. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 This document uses the terms defined in [I-D.ietf-geopriv-arch] 122 (Target, Location Recipient, Location Server), 123 [I-D.ietf-geopriv-lbyr-requirements] (location URI), and 124 [I-D.ietf-geopriv-l7-lcp-ps] (Location Information Server, or LIS). 126 3. HELD Contexts 128 A location URI is a reference to the current location of a Target. 129 The host identified in the URI, the Location Server (LS), serves 130 requests to a location URI using two classes of data: 132 authorization policy: Authorization policies are set by Rule Makers 133 and determine whether the requester is permitted to receive 134 location information and whether there are any constraints on that 135 information. 137 location determination inputs: Information on the identity of the 138 Target and how location information for that Target can be 139 acquired might be saved by the LS. 141 This information is associated with every location URI served by an 142 LS. The collection of data used by the LS establishes a "context" 143 for the location dereference request made by a Location Recipient. 145 The LS role could be assumed by the LIS that provides the location 146 URI to the Device, or it could be a separate entity. 148 In HELD [I-D.ietf-geopriv-http-location-delivery], the establishment 149 of the necessary contextual information is implicit. Creation of a 150 location URI implies that the identified LS has sufficient 151 information to service requests to that URI. 153 This document provides a more explicit mechanism for the creation and 154 management of the contextual information used in serving a location 155 URI. A "HELD context" - simply "context" in this document - can be 156 created, updated and destroyed at the request of the Device. In 157 addition, a Device is able to establish authorization policies in the 158 form of common policy documents [RFC4745] that provide greater 159 control over how a location URI is served by the LS. 161 3.1. Simplified Model 163 The model assumed in this specification, shown in Figure 1, is a 164 simplified variant of that in [I-D.ietf-geopriv-arch] that includes 165 the LIS entity. 167 +------------+ 168 | | 169 | Rule Maker | +-------------+ +-----------+ 170 | | | | | | 171 + - - -- - - + | Location | | Location | 172 | | | Server |-----------| Recipient | 173 | Target | | | (LDP) | | 174 | | + - - - - - - + +-----------+ 175 + - - -- - - + | | | 176 | | | Location | | 177 | Device |-----------| Information | | 178 | | (LCP) | Server | | 179 +------------+ | | | 180 | +-------------+ | 181 | | 182 `------------------(Conveyance)-------------------' 184 Figure 1: HELD Contexts Model 186 This model assumes some form of relationship between a Rule Maker, 187 Target and Device; for instance, the Rule Maker and Target might be 188 the same person. The Device is operated under the control of a Rule 189 Maker and is able to provide authorization policies or disseminate 190 location URIs in accordance with the Rule Maker's wishes. 192 This document also assumes a relationship is assumed between LIS and 193 LS. LIS and LS together generate location URIs and maintain context 194 information. These roles could be filled by the same entity. 196 The location configuration protocol (LCP) interface is extended by 197 this document to include a rules interface for the Rule Maker 198 associated with the Target and Device. This model does not preclude 199 the existence of other Rule Makers that use other rules interfaces. 201 3.2. Authorization Policies 203 A Device is able to specify an authorization policy when creating or 204 updating a context. The authorization policy states which Location 205 Recipients are able to access location information through the 206 context and the associated URIs, plus any other constraints on this 207 access. 209 A Device is able to provide a policy document in the form of a common 210 policy document [RFC4745] or an "https:" reference to one. Existence 211 of an explicit authorization policy implies that the "authorization 212 by access control lists" model ([I-D.ietf-geopriv-lbyr-requirements]) 213 is to be applied. The LS uses the authorization policy document to 214 control how location information is provided to Location Recipients. 216 A Device is able to indicate that the LS is permitted to apply the 217 "authorization by possession" model to the context (see 218 [I-D.ietf-geopriv-lbyr-requirements] and [I-D.ietf-geopriv-arch]). 219 Any Location Recipient that proves possession of the location URI by 220 making a location dereference request to the URI is granted 221 permission to receive the location information. Location URIs for 222 the associated context MUST contain enough random entropy proof of 223 possession of the URI more likely to be as a result of receiving the 224 location URI from the Device than guessing. 226 3.3. Context Lifetime 228 A HELD context has a finite lifetime. This limits the time that a 229 context might refer to a Device that has since left the network. Of 230 course, a LIS MAY remove a context sooner, particularly if it has a 231 means of detecting when the Device becomes absent. 233 The lifetime of the context is negotiated between Device and LIS. 234 The Device requests a certain lifetime and the LIS provides a 235 location URI that is valid for any period less than the requested 236 time. Later requests by the Device can be used to delay the 237 expiration of a context by requesting an extended lifetime. With 238 regular updates a context could persist indefinitely. 240 Note that a LIS SHOULD NOT allow URIs that follow the 241 authorization by possession model to exist indefinitely, since no 242 means is provided for updating policy to revoke access to location 243 information. 245 A Device can request that the LIS remove context information, thereby 246 invalidating the associated location URIs, by the same mechanism used 247 to extend the lifetime. 249 3.4. Snapshot Contexts 251 At the time that a context is created, the Device is able to request 252 that the context refer to a static document that is created at the 253 time of request. The LIS creates a Location Object (LO) based on the 254 associated HELD request parameters and stores the LO. All requests 255 to the location URI created in response to this request are served 256 based on the stored LO. 258 This basic constraint on the context applies for the life of the 259 context. Only the application of authorization policy rules can 260 change what is provided to different Location Recipients. If 261 authorization by possession is used, the associated location URI is 262 different to a Location Object only in that it needs to be 263 dereferenced. 265 4. Protocol Details 267 This specification introduces three new HELD messages, create context 268 (), update context (), and context 269 response (). 271 All context-related messages are HELD messages, sent using the 272 "application/held+xml" MIME type defined in 273 [I-D.ietf-geopriv-http-location-delivery]. 275 A LIS that does not understand this specification returns a HELD 276 "unsupportedMessage" error code in a HELD "error" message. A LIS 277 that does understand this specification returns errors associated 278 with context operations in a HELD error message. New error codes 279 relating to failed context operations are defined in Section 4.4. 281 The specification assumes that the LIS was discovered as part of the 282 LIS discovery [I-D.ietf-geopriv-lis-discovery] and that the LIS is 283 able to provide location information. 285 4.1. Create Context 287 The Device creates a context on the LIS using a create context 288 message. A sample create context request is shown in Figure 2. 290 292 7200 293 false 294 295 296 http://policy.example.com/geolocation-policy/users/alice/index 297 298 299 301 Figure 2: Create Context Example 303 The following parameters of the create context request are defined: 305 lifetime: The maximum lifetime of the context in seconds. All 306 create contexts requests include this parameter. The LIS MAY 307 create the context with a shorter lifetime than was requested, but 308 the lifetime MUST NOT be longer than was requested. 310 snapshot: Whether the value provided to location Recipients is fixed 311 from the time that the context is created (see Section 3.4). This 312 a boolean parameter with a default value of "false", meaning that 313 the location is generate each time that the location URI is 314 dereferenced or recently cached information is used. 316 policy: An authorization policy, either included directly as an 317 instance of a common policy [RFC4745] document, or by reference as 318 a URI. Only one of the following forms of policy are permitted: 320 cp:ruleset: The Device is able to provide an authorization policy 321 explicitly in the request by including a common policy document 322 in the create context request. A "ruleset" element is included 323 as a child of the "policy" element. 325 ruleset-reference: Alternatively, a reference to a policy 326 document can be included using the "ruleset-reference" element. 327 A Rule Maker might maintain an authorization policy on a server 328 (perhaps with XCAP [RFC4825]). This reference MUST be an 329 "https:" URI. The LS MUST retrieve the policy before granting 330 any Location Recipient access to location information; the 331 policy MAY either be retrieved immediately or as a Location 332 Recipient makes a request. The LS can be expected to retrieve 333 the policy document once only, but it MAY be retrieved multiple 334 times. 336 Note that the LIS could be unable to detect errors in policy 337 before sending a response to a request that includes this 338 element. A successful context response might be sent, even if 339 the policy document cannot be retrieved by the LIS or the 340 referenced policy document is not understood by the LIS. 342 possession: This element indicates that authorization by 343 possession [I-D.ietf-geopriv-lbyr-requirements] is to be used 344 for the context. 346 otherPolicy: Alternative policy information might be provided. 347 This element is provided to allow for expansion. A LIS MAY 348 reject requests that contain policy that it does not understand 349 with the "badPolicy" error code. 351 4.2. Update Context 353 A Device is able to update policy or change the lifetime of a context 354 using an update context request. Other context parameters defined in 355 other specification might also be updated using this method. 357 Once created, a context that contains a "snapshot" of the Target's 358 location cannot be made dynamic; the same applies in converse, a 359 dynamic context cannot be made into a static snapshot. 361 A Device might maintain more than one HELD context; therefore, the 362 request needs to identify the context to be updated. The 363 "context-id" is included in this message. 365 367 uhvuhdbnuiehudbnvcujevuijeijcvij3 368 3600 369 370 371 372 373 374 376 Figure 3: Update Context Example 378 When a Device includes a "lifetime" element in an update context 379 message, the lifetime of the context is modified. If the requested 380 lifetime is longer than the time remaining before the context 381 expires, the context lifetime is lengthened. If the requested 382 lifetime is shorter than the remaining time, the context lifetime is 383 shortened. 385 A context that is updated continuously can be maintained indefinitely 386 using this mechanism. The LIS MAY provide a shorter lifetime than 387 the requested time. In particular, the total lifetime of contexts 388 that use authorization by possession MUST be limited. 390 This mechanism also allows for the cancellation of contexts. The 391 Device indicates a context lifetime of 0 in the update context 392 request. The LIS MAY also terminate a context immediately if the 393 lifetime value is less than 10 seconds. 395 397 uhvuhdbnuiehudbnvcujevuijeijcvij3 398 0 399 400 401 402 404 Figure 4: Update Context Termination Example 406 When an update context request contains policy information, that 407 policy information replaces any existing policy. Omitting the 408 "policy" element means that the previous policy remains unchanged. 409 If a "ruleset-reference" element is provided, the LS MUST retrieve 410 the referenced policy document before serving subsequent requests 411 from Location Recipients. Conditional HTTP requests, such as those 412 containing the "If-Modified-Since" header MAY be used to avoid 413 retrieval of the entire policy. 415 The rules regarding the construction of location URIs in 416 [I-D.ietf-geopriv-lbyr-requirements] differ based on the 417 authorization model used. The LIS MUST NOT permit a change in policy 418 if the location URIs associated with the context do not meet the 419 requirements for the updated authorization model. See Section 4.5 420 for more details. 422 4.3. Context Response Message 424 The context response message is sent in response to a create context 425 request or an update context request. This message includes 426 information about the context that has been created, updated or 427 destroyed. 429 The "code" attribute of the context response indicates what action 430 was accomplished by the request: 432 created: The context was successfully created. 434 updated: The context was successfully updated. 436 destroyed: The context was destroyed. 438 The context response contains a "context" element that includes 439 information about the context that was the subject of the request. 441 id: A value that uniquely identifies the context within the context 442 of the LIS. This identifier is used to identify a context for 443 update context requests. Knowledge of this value is used by the 444 LIS to authenticate and authorize any attempts to update the 445 context. The Target MUST keep this value secret. 447 expires: The time at which the context will expire. After this 448 time, all location URIs that reference this context no longer 449 work. 451 snapshot: Whether the context contains a snapshot of the Target's 452 location. This value has a default value of "false". 454 The LIS also provides a set of URIs that can used to access the 455 Target's location using the created context. The set of URIs does 456 not change over the lifetime of the context. 458 A context response message sent in reply to the create context 459 message in Figure 2 might look like Figure 5. 461 463 465 466 467 https://lis.example.com:9768/357yc6s64ceyoiuy5ax3o4 468 469 470 pres:357yc6s64ceyoiuy5ax3o4@lis.example.com:9769 471 472 473 474 476 Figure 5: Context Response Example 478 4.4. Context Errors 480 A set of HELD error codes are minted for use in context requests and 481 responses: 483 badPolicy: The LIS (or LS) was unable to use the included policy due 484 to it being invalid, badly formed, or inaccessible (when 485 "ruleset-reference" is used). A LIS MAY return an error with this 486 code if the policy contains no rules that could be used by the LS. 487 For instance, all the rules might have validity intervals that do 488 not correspond with the lifetime of the URI, or rules might 489 require authentication modes that are not supported by the LS. 491 unknownContext: The LIS was unable to find the context, possibly 492 because the context identifier provided was invalid or because the 493 context has already expired. 495 contextFailure: The LIS was unable to create or update the context. 497 Any other HELD error message can be provided in response to a create 498 or update context request. 500 The following HELD error is sent in response to a create context 501 request where the LIS indicates that snapshot is not supported. 503 506 Figure 6: Example Error Message 508 4.5. Location URI and Context Identifier Generation Rules 510 Location URIs generated by a LIS (or LS) MUST meet the construction 511 requirements in [I-D.ietf-geopriv-lbyr-requirements]. If the LIS 512 permits changing of the authorization model that applies to a 513 context, then the more stringent requirements MUST be complied with. 514 In particular, the requirements for a location URI that operates on 515 the authorization by possession model are more stringent than one 516 that operates on an authorization policy. 518 Location URIs that operate on authorization by possession rely on 519 being difficult to guess to prevent unintential disclosure of 520 location information. A LIS MUST include a sequence of characters 521 with random entropy sufficient to prevent guessing. In general, more 522 entropy is needed for location URIs with longer lifetimes. 524 The context identifier provided by the LIS to the Target in the 525 context response message MUST be unique. Context identifiers are 526 secrets used to indicate authorization for context update requests. 527 Therefore, context identifiers MUST contain sufficient random entropy 528 that they are not easily guessable. 530 A location URI MUST NOT include information that could be used in any 531 way to derive the value of a context identifier. Similarly, context 532 identifiers MUST NOT be based on Target identity. 534 New contexts MUST have unique location URIs that have not previously 535 been used for other contexts, even if the previous context was for 536 the same Target. This might be achieved by including a monotonically 537 increasing sequence number in addition to the random sequence. 539 5. XML Schema 541 542 550 551 553 HELD Context Management 554 555 556 558 This document defines messages for HELD context management. 559 560 562 564 565 566 567 568 569 570 571 572 573 574 575 577 578 579 580 581 582 583 585 587 588 589 590 591 593 594 595 596 597 598 600 602 604 605 606 607 608 610 611 612 613 614 615 616 618 619 620 621 622 624 625 626 627 629 630 631 632 633 634 636 637 638 640 642 643 645 646 648 649 650 651 652 653 655 656 658 659 660 661 663 664 665 667 669 6. Security Considerations 671 The data that is maintained in a HELD context is privacy sensitive 672 information. This information is provided by a Device for the 673 purposes of providing authorized Location Recipients with location 674 information. The LIS MUST NOT use the information it stores in a 675 HELD context for anything other than serving requests to the 676 associated location URIs. 678 The LS MUST enforce the authorization policy established by the 679 Device. The authorization policy determines which Location 680 Recipients are permitted to receive location information, and how 681 that location information is provided. An authorization policy can 682 be updated by the Device at any time using the update context 683 request; after the LIS responds to this request, the authorization 684 policy applies to all subsequent requests from Location Recipients. 686 An authorization policy can be referenced using "ruleset-reference" 687 in a create context or update context request. The LS MUST retrieve 688 any referenced authorization policy using HTTP over TLS [RFC2818] 689 before providing location information to any Location Recipient. 691 Context identifiers are confidential information shared only between 692 LIS and Device. Location URIs are also confidential if authorization 693 by possession is chosen by the device, in which case the location URI 694 is shared only between LIS, Device and authorized Location 695 Recipients. The LIS MUST ensure that context identifiers and 696 location URIs are constructed following the rules described in 697 Section 4.5 of this document. 699 HELD [I-D.ietf-geopriv-http-location-delivery] mandates the use of 700 TLS for exchanges between a Device and the LIS. TLS provides 701 confidentiality, protection from modification, LIS (and possibly 702 Device) authentication. Messages related to HELD contexts contain 703 information that requires the same protections. 705 6.1. Multiple Contexts from the 'Same' Target 707 It is conceivable that a LIS will be required to provide location to 708 Devices residing behind a NAT. A home gateway is a good example of a 709 situation where the relatively small geographic area served by the 710 gateway is adequately served by a LIS external to that network (see 711 [I-D.ietf-geopriv-l7-lcp-ps]). Devices within the home network 712 appear to have the same identity information to a LIS - requests all 713 originate from the same IP address. In this case, each Device might 714 create its own context on the LIS. The LIS treats each context 715 individually even though the LIS might be unable to distinguish 716 between the actual Devices making the requests. 718 It is also possible that a single Device could request multiple 719 contexts. Devices might have multiple users, or multiple 720 applications running that each have have different privileges, 721 different privacy requirements or are controlled by different Rule 722 Makers. Therefore, different contexts might be used for different 723 uses: each might a different policy that reflects the needs of the 724 user or application. Information provided by a Device related to a 725 context MUST NOT be used by the LIS outside of that context. 727 The state information maintained by the LIS or LS in providing a 728 context presents a denial of service attack vector. Limiting the 729 number of contexts that the LIS allows to be created can protect 730 against such attacks. To ensure that LIS resources are not 731 exhausted, the LIS MUST limit the number of contexts that it permits 732 from each identifier. 734 Any limits need to consider the usage pattern expected. For 735 instance, if home gateways are commonly deployed in the access 736 network, then the LIS might allow for more than one context for 737 each discrete identifier. 739 7. IANA Considerations 741 This document registers the schema and associated namespace with 742 IANA. 744 7.1. URN Sub-Namespace Registration for 745 urn:ietf:params:xml:ns:geopriv:held:context 747 This section registers a new XML namespace, 748 "urn:ietf:params:xml:ns:geopriv:held:context", as per the guidelines 749 in [RFC3688]. 751 URI: urn:ietf:params:xml:ns:geopriv:held:context 753 Registrant Contact: IETF, GEOPRIV working group, 754 (geopriv@ietf.org), James Winterbottom 755 (james.winterbottom@andrew.com). 757 XML: 759 BEGIN 760 761 763 764 765 HELD Context Management Messages 766 767 768

Namespace for HELD Context Management Messages

769

urn:ietf:params:xml:ns:geopriv:held:context

770 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 771 with the RFC number for this specification.]] 772

See RFCXXXX.

773 774 775 END 777 7.2. XML Schema Registration 779 This section registers an XML schema as per the guidelines in 780 [RFC3688]. 782 URI: urn:ietf:params:xml:schema:geopriv:held:context 783 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 784 James Winterbottom (james.winterbottom@andrew.com). 786 Schema: The XML for this schema can be found as the entirety of 787 Section 5 of this document. 789 7.3. HELD Error Code Registration 791 Reference: Section 4.4 of RFCXXXX (i.e., this document) specifies the 792 following HELD error codes: 794 badPolicy 796 unknownContext 798 contextFailure 800 These error codes and their descriptions are added to the HELD error 801 code respository created in 802 [I-D.ietf-geopriv-http-location-delivery]. 804 8. Acknowledgements 806 Thanks to Adam Muhlbauer and Neil Justusson for their comments on the 807 pre-version of this draft. 809 Thanks also to Tim Zelinski and Michael Diponio, who pointed out a 810 problems while implementing an early revision of this specification. 812 9. References 814 9.1. Normative References 816 [RFC2119] Bradner, S., "Key words 817 for use in RFCs to 818 Indicate Requirement 819 Levels", BCP 14, RFC 2119, 820 March 1997. 822 [RFC2818] Rescorla, E., "HTTP Over 823 TLS", RFC 2818, May 2000. 825 [RFC3688] Mealling, M., "The IETF 826 XML Registry", BCP 81, 827 RFC 3688, January 2004. 829 [RFC4745] Schulzrinne, H., 830 Tschofenig, H., Morris, 831 J., Cuellar, J., Polk, J., 832 and J. Rosenberg, "Common 833 Policy: A Document Format 834 for Expressing Privacy 835 Preferences", RFC 4745, 836 February 2007. 838 [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, 839 J., Thomson, M., and B. 840 Stark, "HTTP Enabled 841 Location Delivery (HELD)", 842 draft-ietf-geopriv-http- 843 location-delivery-16 (work 844 in progress), August 2009. 846 9.2. Informative References 848 [RFC3693] Cuellar, J., Morris, J., 849 Mulligan, D., Peterson, 850 J., and J. Polk, "Geopriv 851 Requirements", RFC 3693, 852 February 2004. 854 [RFC4825] Rosenberg, J., "The 855 Extensible Markup Language 856 (XML) Configuration Access 857 Protocol (XCAP)", 858 RFC 4825, May 2007. 860 [I-D.ietf-geopriv-arch] Barnes, R., Lepinski, M., 861 Cooper, A., Morris, J., 862 Tschofenig, H., and H. 863 Schulzrinne, "An 864 Architecture for Location 865 and Location Privacy in 866 Internet Applications", 867 draft-ietf-geopriv-arch-00 868 (work in progress), 869 July 2009. 871 [I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. and H. 872 Schulzrinne, "GEOPRIV 873 Layer 7 Location 874 Configuration Protocol; 875 Problem Statement and 876 Requirements", draft-ietf- 877 geopriv-l7-lcp-ps-10 (work 878 in progress), July 2009. 880 [I-D.ietf-geopriv-lbyr-requirements] Marshall, R., 881 "Requirements for a 882 Location-by-Reference 883 Mechanism", draft-ietf- 884 geopriv-lbyr-requirements- 885 08 (work in progress), 886 September 2009. 888 [I-D.ietf-geopriv-lis-discovery] Thomson, M. and J. 889 Winterbottom, "Discovering 890 the Local Location 891 Information Server (LIS)", 892 draft-ietf-geopriv-lis- 893 discovery-11 (work in 894 progress), May 2009. 896 Appendix A. Compliance to Location by Reference Requirements 898 This section describes how HELD and this specification comply to the 899 location configuration protocol requirements stipulated in 900 [I-D.ietf-geopriv-lbyr-requirements]. 902 C1. "Location URI support: The configuration protocol MUST support a 903 location reference in URI form." 905 Compliant: HELD only provides location references in URI form. 907 C2. "Location URI expiration: When a location URI has a limited 908 validity interval, its lifetime MUST be indicated." 910 Compliant: All location URIs provided expire; the context 911 response message indicates when the URI expires. 913 C3. "Location URI cancellation: The location configuration protocol 914 MUST support the ability to request a cancellation of a specific 915 location URI." 917 Compliant: Updating a context with a lifetime set to zero 918 cancels a context. 920 C4. "Location Information Masking: The location URI MUST, through 921 randomization and uniqueness, ensure that the location URI does 922 not contain location information specific components." 924 Compliant: The URIs produced for a HELD context are required to 925 comply with this condition, see Section 4.5. 927 C5. "Target Identity Protection: The location URI MUST NOT contain 928 information that identifies the Target (e.g., user or device)." 930 Compliant: The URIs produced for a HELD context are required to 931 comply with this condition, see Section 4.5. 933 C6. "Reuse indicator: There SHOULD be a way to allow a Target to 934 control whether a location URI can be resolved once only, or 935 multiple times." 937 Not compliant: No means is provided to control how often a URI 938 can be resolved. Extensions to this mechanism or additions to 939 authorization policy definitions might provide this function. 941 C7. "Selective disclosure: The location configuration protocol MUST 942 provide a mechanism to control what information is being 943 disclosed about the Target." 945 Compliant: Policy [RFC4745] is used to control what information 946 is disclosed about the target. No information about the Target 947 is included in a location URI. 949 C8. "Location URI Not guessable: As a default, the location 950 configuration protocol MUST return location URIs that are random 951 and unique throughout the indicated lifetime. A location URI 952 with 128-bits of randomness is RECOMMENDED." 954 Compliant: Section 4.5 describes how this requirement is met by 955 implementations. 957 C9. "Location URI Options: In the case of user-provided 958 authorization policies, where anonymous or non-guessable 959 location URIs are not warranted, the location configuration 960 protocol MAY support a variety of optional location URI 961 conventions, as requested by a Target to a location 962 configuration server, (e.g., embedded location information 963 within the location URI)." 965 Partially compliant: The authorization model is explicitly 966 selected by the Device in the request. This determines the 967 constraints on how the location URI is created. No means is 968 provided for a Target or other entity to otherwise influence 969 what information is included in a location URI. This may be 970 provided by extension documents. 972 Authors' Addresses 974 James Winterbottom 975 Andrew Corporation 976 PO Box U40 977 University of Wollongong, NSW 2500 978 AU 980 Phone: +61 242 212938 981 EMail: james.winterbottom@andrew.com 982 URI: http://www.andrew.com/products/geometrix 984 Hannes Tschofenig 985 Nokia Siemens Networks 986 Linnoitustie 6 987 Espoo 02600 988 Finland 990 Phone: +358 (50) 4871445 991 EMail: Hannes.Tschofenig@gmx.net 992 URI: http://www.tschofenig.priv.at 994 Martin Thomson 995 Andrew Corporation 996 PO Box U40 997 University of Wollongong, NSW 2500 998 AU 1000 Phone: +61 242 212915 1001 EMail: martin.thomson@andrew.com 1002 URI: http://www.andrew.com/products/geometrix