idnits 2.17.00 (12 Aug 2021) /tmp/idnits3819/draft-winterbottom-geopriv-held-context-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 (April 14, 2009) is 4785 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) ** 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-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 (~~), 5 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: October 16, 2009 Nokia Siemens Networks 6 M. Thomson 7 Andrew Corporation 8 April 14, 2009 10 Establishing Location URI Contexts using HTTP-Enabled Location Delivery 11 (HELD) 12 draft-winterbottom-geopriv-held-context-04 14 Status of This Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 16, 2009. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document describes a protocol extension for the HTTP-Enabled 51 Location Delivery (HELD) protocol. It allows a Target to manage 52 their location information on a Location Information Server (LIS) 53 through the application of constraints invoked by accessing a 54 location URI. Constraints described in this memo restrict how often 55 location can be accessed through a location URI, how long the URI is 56 valid for, and the type of location information returned when a 57 location URI is accessed. Extension points are also provided. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. HELD Contexts . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Simplified Model . . . . . . . . . . . . . . . . . . . . . 4 65 3.2. Authorization Policies . . . . . . . . . . . . . . . . . . 5 66 3.3. Context Lifetime . . . . . . . . . . . . . . . . . . . . . 6 67 3.4. Snapshot Contexts . . . . . . . . . . . . . . . . . . . . 6 68 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Create Context . . . . . . . . . . . . . . . . . . . . . . 7 70 4.2. Update Context . . . . . . . . . . . . . . . . . . . . . . 8 71 4.3. Context Response Message . . . . . . . . . . . . . . . . . 10 72 4.4. Context Errors . . . . . . . . . . . . . . . . . . . . . . 11 73 4.5. Location URI and Context Identifier Generation Rules . . . 12 74 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 6.1. Multiple Contexts from the 'Same' Target . . . . . . . . . 16 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 78 7.1. URN Sub-Namespace Registration for 79 urn:ietf:params:xml:ns:geopriv:held:context . . . . . . . 17 80 7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 17 81 7.3. HELD Error Code Registration . . . . . . . . . . . . . . . 18 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 86 Appendix A. Compliance to Location by Reference Requirements . . 20 88 1. Introduction 90 The HTTP Enabled Location Delivery (HELD) protocol specification 91 [I-D.ietf-geopriv-http-location-delivery] provides a set of features 92 that can be used by a Target to retrieve location information from a 93 Location Information Server (LIS). The LIS is able to optionally 94 provide a location URI [I-D.ietf-geopriv-lbyr-requirements], which 95 provides a reference to location information. 97 A location URI that is provided by a LIS using the basic HELD 98 specification, is essentially immutable once retrieved. There is no 99 means provided of controlling how the URI is used. A default policy 100 is applied to the URI, which is fixed until the location URI expires; 101 a Location Recipient in possession of the location URI can retrieve 102 the Target's location until the expiry time lapses. 104 This basic mechanism may be reasonable in a limited set of 105 applications, but is unacceptable in a broader range of applications. 106 In particular, the ability to change policy dynamically is required 107 to better protect the privacy of the Target. 108 [I-D.ietf-geopriv-lbyr-requirements] enumerates several requirements 109 relating to location URIs that cannot be achieved using the basic 110 HELD specification. This specification provides support for these 111 requirements in HELD. 113 Two new forms of HELD request are defined by this document. These 114 requests relate to the creation and maintenance of a _HELD context_, 115 a concept that is explained in more detail in Section 3. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 This document uses the terms defined in [RFC3693] (Target, Location 124 Recipient, Location Server), [I-D.ietf-geopriv-lbyr-requirements] 125 (location URI), and [I-D.ietf-geopriv-l7-lcp-ps] (Location 126 Information Server, or LIS). 128 The distinction between Location Server (LS) and Location Information 129 Server (LIS) is important. LS is used to refer to the role that 130 serves a location URI, whereas a LIS is the role that provides the 131 location configuration. Both roles might be assumed by the same 132 entity, but the roles could be separate. 134 3. HELD Contexts 136 A location URI is a reference to the current location of a Target. 137 The host identified in the URI, the Location Server (LS), serves 138 requests to a location URI using two classes of data: 140 authorization policy: Authorization policies are set by Rule Makers 141 and determine whether the requester is permitted to receive 142 location information and whether there are any constraints on that 143 information. 145 location determination inputs: Information on the identity of the 146 Target and how location information for that Target can be 147 acquired might be saved by the LS. 149 This information is associated with every location URI served by an 150 LS. The collection of data used by the LS establishes a "context" 151 for the location dereference request made by a Location Recipient. 153 In HELD [I-D.ietf-geopriv-http-location-delivery], the establishment 154 of the necessary contextual information is implicit. Creation of a 155 location URI implies that the LIS has provided the LS with sufficient 156 information to service requests to that URI. 158 This document provides a more explicit mechanism for the creation and 159 management of the contextual information used in serving a location 160 URI. This information - dubbed a "HELD context" (simply "context" in 161 this document) - can be created, updated and destroyed at the request 162 of the Device. In addition, a Device is able to establish 163 authorization policies in the form of common policy documents 164 [RFC4745] that provide greater control over how a location URI is 165 served by the LS. 167 3.1. Simplified Model 169 The model assumed in this specification, shown in Figure 1, is a 170 simplified variant of that in [RFC3693] that includes the LIS entity. 172 +------------+ 173 | | 174 | Rule Maker | +-------------+ +-----------+ 175 | | | | | | 176 + - - -- - - + | Location | | Location | 177 | | | Server |-----------| Recipient | 178 | Target | | | (LDP) | | 179 | | + - - - - - - + +-----------+ 180 + - - -- - - + | | | 181 | | | Location | | 182 | Device |-----------| Information | | 183 | | (LCP) | Server | | 184 +------------+ | | | 185 | +-------------+ | 186 | | 187 `------------------(Conveyance)-------------------' 189 Figure 1: HELD Contexts Model 191 This model assumes some form of relationship between a Rule Maker, 192 Target and Device; for instance, the Rule Maker and Target might be 193 the same person. The Device is operated under the control of a Rule 194 Maker and is able to provide authorization policies or disseminate 195 location URIs in accordance with the Rule Maker's wishes. 197 This document also assumes a relationship is assumed between LIS and 198 LS. LIS and LS together generate location URIs and maintain context 199 information. These roles could be filled by the same entity. 201 The location configuration protocol (LCP) interface is extended by 202 this document to include a rules interface for the Rule Maker 203 associated with the Target and Device. This model does not preclude 204 the existence of other Rule Makers that use other rules interfaces. 206 3.2. Authorization Policies 208 A Device is able to specify an authorization policy when creating or 209 updating a context. The authorization policy states which Location 210 Recipients are able to access location information through the 211 context and the associated URIs, plus any other constraints on this 212 access. 214 A Device is able to provide a policy document in the form of a common 215 policy document [RFC4745] or an "https:" reference to one. Existence 216 of an explicit authorization policy implies that the "authorization 217 by access control lists" model ([I-D.ietf-geopriv-lbyr-requirements]) 218 is to be applied. The LS uses the authorization policy document to 219 control how location information is provided to Location Recipients. 221 Absence of policy, or an explicit indication otherwise, indicates 222 that the LS is permitted to apply the "authorization by possession" 223 model ([I-D.ietf-geopriv-lbyr-requirements]). Any Location Recipient 224 that proves possession of the location URI by making a location 225 dereference request to the URI is granted permission to receive the 226 location information. Location URIs for the associated context have 227 random components with enough entropy to make possession more likely 228 to be as a result of receiving the location URI from the Device than 229 guesswork. 231 3.3. Context Lifetime 233 A HELD context has a finite lifetime. This limits the time that a 234 context might refer to a Device that has since left the network. Of 235 course, a LIS might have a means of detecting the absence of a given 236 Device, invaliding any contexts when the Device is no longer present. 238 The lifetime of the context is negotiated between Device and LIS. 239 The Device requests a certain lifetime and the LIS provides a 240 location URI that is valid for up to the requested time. A Device is 241 able to extend the lifetime of a context by updating the context 242 information. Given regular updates, a context might persist 243 indefinitely, providing that authorization by possession is not used. 245 A Device can request that the LIS remove context information, 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 context the Target's location at the time that the location 314 URI is dereferenced. 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: Absence of policy information in a create context 343 request implies that authorization by possession 344 [I-D.ietf-geopriv-lbyr-requirements] is used for the context. 345 The "possession" element provides an explicit indication that 346 this policy is to be applied. 348 otherPolicy: Alternative policy information might be provided. 349 This element is provided to allow for expansion. A LIS MAY 350 reject requests that contain policy that it does not understand 351 with the "badPolicy" error code. 353 4.2. Update Context 355 A Device is able to update policy or change the lifetime of a context 356 using an update context request. Other context parameters defined in 357 other specification might also be updated using this method. 359 Once created, a context that contains a "snapshot" of the Target's 360 location cannot be made dynamic; the same applies in converse, a 361 dynamic context cannot be made into a static snapshot. 363 A Device might maintain more than one HELD context; therefore, the 364 request needs to identify the context to be updated. The 365 "context-id" is included in this message. 367 369 uhvuhdbnuiehudbnvcujevuijeijcvij3 370 3600 371 372 373 374 375 376 378 Figure 3: Update Context Example 380 When a Device includes a "lifetime" element in an update context 381 message, the lifetime of the context is modified. If the requested 382 lifetime is longer than the time remaining before the context 383 expires, the context lifetime is lengthened. If the requested 384 lifetime is shorter than the remaining time, the context lifetime is 385 shortened. 387 A context that is updated continuously can be maintained indefinitely 388 using this mechanism. The LIS MAY provide a shorter lifetime than 389 the requested time. In particular, the total lifetime of contexts 390 that use authorization by possession MUST be limited. 392 This mechanism also allows for the cancellation of contexts. The 393 Device indicates a context lifetime of 0 in the update context 394 request. The LIS MAY also terminate a context immediately if the 395 lifetime value is less than 10 seconds. 397 399 uhvuhdbnuiehudbnvcujevuijeijcvij3 400 0 401 402 403 404 406 Figure 4: Update Context Termination Example 408 When an update context request contains policy information, that 409 policy information replaces any existing policy. Omitting the 410 "policy" element means that the previous policy remains unchanged. 411 If a "ruleset-reference" element is provided, the LS MUST retrieve 412 the referenced policy document before serving subsequent requests 413 from Location Recipients. Conditional HTTP requests, such as those 414 containing the "If-Modified-Since" header MAY be used to avoid 415 retrieval of the entire policy. 417 The rules regarding the construction of location URIs in 418 [I-D.ietf-geopriv-lbyr-requirements] differ based on the 419 authorization model used. The LIS MUST NOT permit a change in policy 420 if the location URIs associated with the context do not meet the 421 requirements for the updated authorization model. See Section 4.5 422 for more details. 424 4.3. Context Response Message 426 The context response message is sent in response to a create context 427 request or an update context request. This message includes 428 information about the context that has been created, updated or 429 destroyed. 431 The "code" attribute of the context response indicates what action 432 was accomplished by the request: 434 created: The context was successfully created. 436 updated: The context was successfully updated. 438 destroyed: The context was destroyed. 440 The context response contains a "context" element that includes 441 information about the context that was the subject of the request. 443 id: A value that uniquely identifies the context within the context 444 of the LIS. This identifier is used to identify a context for 445 update context requests. Knowledge of this value is used by the 446 LIS to authenticate and authorize update context requests. The 447 Target MUST keep this value secret. 449 expires: The time at which the context will expire. After this 450 time, all location URIs that reference this context no longer 451 work. 453 snapshot: Whether the context contains a snapshot of the Target's 454 location. This value has a default value of "false". 456 The LIS also provides a set of URIs that can used to access the 457 Target's location using the created context. The set of URIs does 458 not change over the lifetime of the context. 460 A context response message sent in reply to the create context 461 message in Figure 2 might look like Figure 5. 463 465 467 468 469 https://lis.example.com:9768/357yc6s64ceyoiuy5ax3o4 470 471 472 pres:357yc6s64ceyoiuy5ax3o4@lis.example.com:9769 473 474 475 476 478 Figure 5: Context Response Example 480 4.4. Context Errors 482 A set of new HELD error codes are minted for use in context requests 483 and responses: 485 badPolicy: The LIS (or LS) was unable to use the included policy due 486 to it being invalid, badly formed, or inaccessible (when 487 "ruleset-reference" is used). A LIS MAY return an error with this 488 code if the policy contains no rules that could be used under any 489 circumstances. For instance, all the rules might have validity 490 intervals that do not correspond with the lifetime of the URI, or 491 rules might require authentication modes that are not supported by 492 the LS. 494 unknownContext: The LIS was unable to find the context, possibly 495 because the context identifier provided was invalid or because the 496 context has already expired. 498 contextFailure: The LIS was unable to create or update the context. 500 Any other HELD error message can be provided in response to a create 501 or update context request. 503 The following HELD error is sent in response to a create context 504 request where the LIS indicates that snapshot is not supported. 506 509 Figure 6: Example Error Message 511 4.5. Location URI and Context Identifier Generation Rules 513 Location URIs generated by a LIS (or LS) MUST meet the construction 514 requirements in [I-D.ietf-geopriv-lbyr-requirements]. In particular, 515 the requirements for a location URI that operates on the 516 authorization by possession model are more stringent than one that 517 operates on an authorization policy. 519 Location URIs that operate on authorization by possession MUST be 520 difficult to guess. Inclusion of a sequence of characters with at 521 least 128 bits of random entropy is RECOMMENDED. More entropy might 522 be required for location URIs with longer lifetimes. If the LIS 523 permits changing of the authorization model that applies to a 524 context, then the more stringent requirements MUST be complied with. 526 The context identifier provided by the LIS to the Target in the 527 context response message MUST be unique. Context identifiers are 528 secrets used to indicate authorization for context update requests. 529 Therefore, context identifiers MUST NOT be easily guessable. 530 Inclusion of a sequence of characters with at least 128 bits of 531 random entropy is RECOMMENDED. 533 A location URI MUST NOT include information that could be used in any 534 way to derive the value of a context identifier. Similarly, context 535 identifiers MUST NOT be based on Target identity. 537 New contexts MUST have unique location URIs that have not previously 538 been used for other contexts, even if the previous context was for 539 the same Target. 541 5. XML Schema 543 544 552 553 555 HELD Context Management 556 557 558 560 This document defines messages for HELD context management. 561 562 564 566 567 568 569 570 571 572 573 574 575 576 577 579 580 581 582 583 584 585 587 589 590 591 592 593 595 596 597 598 599 600 602 604 606 607 608 609 610 612 613 614 615 616 617 618 620 621 622 623 624 626 627 628 629 631 632 633 634 635 636 638 639 640 642 644 645 646 647 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. 711 Devices within the home network appear to have the same identity 712 information to a LIS - requests all originate from the same IP 713 address. In this case, each Device might create its own context on 714 the LIS. The LIS treats each context individually even though the 715 LIS might be unable to distinguish between the actual Devices making 716 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 different Rule Makers. Therefore, 722 might create different contexts for different uses: each might a 723 different policy that reflects the needs of the user or application. 724 Information provided by a Device related to a context MUST NOT be 725 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. Any limits need to consider the usage pattern 731 expected. If home gateways are commonly deployed in the access 732 network, then the LIS MUST allow for more than one context for each 733 discrete identifier. However, to ensure that LIS resources are not 734 exhausted, the LIS MUST limit the number of contexts that it permits 735 from each identifier. 737 7. IANA Considerations 739 This document registers the schema and associated namespace with 740 IANA. 742 7.1. URN Sub-Namespace Registration for 743 urn:ietf:params:xml:ns:geopriv:held:context 745 This section registers a new XML namespace, 746 "urn:ietf:params:xml:ns:geopriv:held:context", as per the guidelines 747 in [RFC3688]. 749 URI: urn:ietf:params:xml:ns:geopriv:held:context 751 Registrant Contact: IETF, GEOPRIV working group, 752 (geopriv@ietf.org), James Winterbottom 753 (james.winterbottom@andrew.com). 755 XML: 757 BEGIN 758 759 761 762 763 HELD Context Management Messages 764 765 766

Namespace for HELD Context Management Messages

767

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

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

See RFCXXXX.

771 772 773 END 775 7.2. XML Schema Registration 777 This section registers an XML schema as per the guidelines in 778 [RFC3688]. 780 URI: urn:ietf:params:xml:schema:geopriv:held:context 782 Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 783 James Winterbottom (james.winterbottom@andrew.com). 785 Schema: The XML for this schema can be found as the entirety of 786 Section 5 of this document. 788 7.3. HELD Error Code Registration 790 Reference: Section 4.4 of RFCXXXX (i.e., this document) specifies the 791 following HELD error codes: 793 badPolicy 795 unknownContext 797 contextFailure 799 These error codes and their descriptions are added to the HELD error 800 code respository defined in 801 [I-D.ietf-geopriv-http-location-delivery]. 803 8. Acknowledgements 805 Thanks to Adam Muhlbauer and Neil Justusson for their comments on the 806 pre-version of this draft. 808 Thanks also to Tim Zelinski and Michael Diponio, who pointed out a 809 problems while implementing an early revision of this specification. 811 9. References 813 9.1. Normative References 815 [RFC2119] Bradner, S., "Key words 816 for use in RFCs to 817 Indicate Requirement 818 Levels", BCP 14, RFC 2119, 819 March 1997. 821 [RFC2818] Rescorla, E., "HTTP Over 822 TLS", RFC 2818, May 2000. 824 [RFC3688] Mealling, M., "The IETF 825 XML Registry", BCP 81, 826 RFC 3688, January 2004. 828 [RFC4745] Schulzrinne, H., 829 Tschofenig, H., Morris, 830 J., Cuellar, J., Polk, J., 831 and J. Rosenberg, "Common 832 Policy: A Document Format 833 for Expressing Privacy 834 Preferences", RFC 4745, 835 February 2007. 837 [I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom, 838 J., Thomson, M., and B. 839 Stark, "HTTP Enabled 840 Location Delivery (HELD)", 841 draft-ietf-geopriv-http- 842 location-delivery-13 (work 843 in progress), 844 February 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-l7-lcp-ps] Tschofenig, H. and H. 861 Schulzrinne, "GEOPRIV 862 Layer 7 Location 863 Configuration Protocol; 864 Problem Statement and 865 Requirements", draft-ietf- 866 geopriv-l7-lcp-ps-09 (work 867 in progress), 868 February 2009. 870 [I-D.ietf-geopriv-lbyr-requirements] Marshall, R., 871 "Requirements for a 872 Location-by-Reference 873 Mechanism", draft-ietf- 874 geopriv-lbyr-requirements- 875 07 (work in progress), 876 February 2009. 878 [I-D.ietf-geopriv-lis-discovery] Thomson, M. and J. 879 Winterbottom, "Discovering 880 the Local Location 881 Information Server (LIS)", 882 draft-ietf-geopriv-lis- 883 discovery-09 (work in 884 progress), March 2009. 886 Appendix A. Compliance to Location by Reference Requirements 888 This section describes how HELD and this specification comply to the 889 location configuration protocol requirements stipulated in 890 [I-D.ietf-geopriv-lbyr-requirements]. 892 C1. "Location URI support: The configuration protocol MUST support 893 a location reference in URI form." 895 Compliant: HELD only provides location references in URI form. 897 C2. "Location URI expiration: When a location URI has a limited 898 validity interval, its lifetime MUST be indicated." 900 Compliant: All location URIs provided expire; the context 901 response message indicates when the URI expires. 903 C3. "Location URI cancellation: The location configuration protocol 904 MUST support the ability to request a cancellation of a 905 specific location URI." 907 Compliant: Updating a context with a lifetime set to zero 908 cancels a context. 910 C4. "Location Information Masking: The location URI form MUST, 911 through randomization and uniqueness, ensure that any location 912 specific information embedded within the location URI itself is 913 kept obscure during location configuration." 915 Compliant: With an explicit reference to this requirement, the 916 URIs produced for a HELD context are required to comply with 917 this condition. 919 C5. "User Identity Protection: The location URI MUST NOT contain 920 any user identifying information that identifies the user, 921 device or address of record, (e.g., which includes phone 922 extensions, badge numbers, first or last names, etc.), within 923 the URI form." 925 Compliant: With an explicit reference to this requirement, the 926 URIs produced for a HELD context are required to comply with 927 this condition. 929 C6. "Reuse indicator: There SHOULD be a way to allow a client to 930 control whether a location URI can be resolved once only, or 931 multiple times." 933 Not compliant. 935 C7. "Validity Interval Indication: A location configuration 936 protocol MUST provide an indication of the location URI 937 validity interval (i.e., expiry time) when present." 939 Compliant: The "expires" attribute indicates the time when the 940 context becomes invalid. 942 C8. "Location only: The location URI MUST NOT point to any 943 information about the Target other than it's location." 945 Compliant: PIDF-LO documents that are produced by the LS in 946 response to a request at the URI do not contain Target 947 identification, unless policy states otherwise. 949 C9. "Location URI Not guessable: Where location URIs are used 950 publicly, any location URI MUST be constructed using properties 951 of uniqueness and cryptographically random sequences so that it 952 is not guessable. (Note that the number of bits depends to 953 some extent on the number of active location URIs that might 954 exist at the one time; 128-bit is most likely enough for the 955 near term.)" 957 Compliant: Section 4.5 describes how this requirement is met by 958 implementations. 960 C10. "Location URI Optional: In the case of user-provided 961 authorization policies, where anonymous or non-guessable 962 location URIs are not warranted, the location configuration 963 protocol MAY support optional location URI forms." 965 Not compliant: The format of location URIs generated by the LIS 966 cannot be influenced through any of the parameters described in 967 this document. 969 C11. "Location URI Authorization Model: The location configuration 970 protocol SHOULD indicate whether the requested location URI 971 conforms to the access control authorization model or the 972 possession authorization model." 974 Compliant: The authorization model is explicitly selected by 975 the Device in the request. 977 C12. "Location URI Lifetime: A location URI SHOULD have an 978 associated expiration lifetime (i.e., validity interval), and 979 MUST have an validity interval if used with the possession 980 authorization model." 982 Duplicate requirement. 984 Authors' Addresses 986 James Winterbottom 987 Andrew Corporation 988 PO Box U40 989 University of Wollongong, NSW 2500 990 AU 992 Phone: +61 242 212938 993 EMail: james.winterbottom@andrew.com 994 URI: http://www.andrew.com/products/geometrix 996 Hannes Tschofenig 997 Nokia Siemens Networks 998 Linnoitustie 6 999 Espoo 02600 1000 Finland 1002 Phone: +358 (50) 4871445 1003 EMail: Hannes.Tschofenig@gmx.net 1004 URI: http://www.tschofenig.priv.at 1006 Martin Thomson 1007 Andrew Corporation 1008 PO Box U40 1009 University of Wollongong, NSW 2500 1010 AU 1012 Phone: +61 242 212915 1013 EMail: martin.thomson@andrew.com 1014 URI: http://www.andrew.com/products/geometrix