idnits 2.17.00 (12 Aug 2021) /tmp/idnits41290/draft-ietf-geopriv-lbyr-requirements-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 == Line 155 has weird spacing: '...ocation infor...' == Line 159 has weird spacing: '...llation reque...' -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 9, 2009) is 4569 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-geopriv-dhcp-lbyr-uri-option-06 == 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-loc-filters has been published as RFC 6447 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GeoPriv R. Marshall, Ed. 3 Internet-Draft TCS 4 Intended status: Informational November 9, 2009 5 Expires: May 13, 2010 7 Requirements for a Location-by-Reference Mechanism 8 draft-ietf-geopriv-lbyr-requirements-09 10 This document may contain material from IETF Documents or IETF 11 Contributions published or made publicly available before November 12 10, 2008. The person(s) controlling the copyright in some of this 13 material may not have granted the IETF Trust the right to allow 14 modifications of such material outside the IETF Standards Process. 15 Without obtaining an adequate license from the person(s) controlling 16 the copyright in such materials, this document may not be modified 17 outside the IETF Standards Process, and derivative works of it may 18 not be created outside the IETF Standards Process, except to format 19 it for publication as an RFC or to translate it into languages other 20 than English. 22 Abstract 24 This document defines terminology and provides requirements relating 25 to Location-by-Reference approach using a location Uniform Resource 26 Identifier (URI) to handle location information within signaling and 27 other Internet messaging. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on May 13, 2010. 52 Copyright Notice 54 Copyright (c) 2009 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3. Overview of Location-by-Reference . . . . . . . . . . . . . . 9 72 3.1. Location URI Usage . . . . . . . . . . . . . . . . . . . . 10 73 3.2. Location URI Expiration . . . . . . . . . . . . . . . . . 10 74 3.3. Location URI Authorization . . . . . . . . . . . . . . . . 11 75 3.4. Location URI Construction . . . . . . . . . . . . . . . . 11 76 4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 13 77 4.1. Requirements for a Location Configuration Protocol . . . . 13 78 4.2. Requirements for a Location Dereference Protocol . . . . . 15 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 85 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 20 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 88 1. Introduction 90 All location-based services rely on ready access to location 91 information. Using location information can be done one of two ways, 92 either in a direct, Location-by-Value (LbyV) approach, or using an 93 indirect, Location-by-Reference (LbyR) model. 95 For LbyV, location information is conveyed directly in the form of a 96 Presence Information Data Format-Location Object (PIDF-LO) 97 ([RFC4119]). Using LbyV might either be infeasible or undesirable in 98 some circumstances. There are cases where LbyR is better able to 99 address location requirements for a specific architecture or 100 application. This document provides a list of requirements for use 101 with the LbyR approach, and leaves the LbyV model explicitly out of 102 scope. 104 As justification for a LbyR model, consider the circumstance that in 105 some mobile networks it is not efficient for the end host to 106 periodically query the Location Information Server (LIS) for up-to- 107 date location information. This is especially the case when power 108 availability is a constraint or when a location update is not 109 immediately needed. Furthermore, the end host might want to delegate 110 the task of retrieving and publishing location information to a third 111 party, such as to a presence server. Additionally, in some 112 deployments, the network operator may not want to make location 113 information widely available. These kinds of location scenarios form 114 the basis of motivation for the LbyR model. 116 The concept of an LbyR mechanism is simple. An LbyR is made up of a 117 URI scheme, a domain and a randomized component. This combination of 118 data elements, in the form of a URI, is referred to specifically as a 119 "location URI". 121 A location URI is thought of as a reference to the current location 122 of the Target, yet the location value might remain unchanged over 123 specific intervals of time for several reasons. The type of location 124 information returned as part of the dereferencing step may, for 125 example, be influenced by the following factors: 127 - Limitations in the process used to generate location information 128 mean that cached location might be used. 130 - Policy constraints that may dictate that the location provided 131 remains fixed over time for specified Location Recipients. Without 132 additional information, a Location Recipient cannot assume that the 133 location information provided by any location URI is static, and will 134 never change. 136 The LbyR mechanism works according to an information lifecycle. 137 Within this lifecycle, location URIs are considered temporary 138 identifiers, each undergoing the following uses: Creation; 139 Distribution; Conveyance; Dereference; and Termination. The use of a 140 location URI according to these various states is generally applied 141 in one of the following ways: 143 1. Creation of a location URI, within a location server, based on 144 some request for its creation. 146 2. Distribution of a location URI, via a Location Configuration 147 Protocol, between a Target and a location server. 149 3. Conveyance, applied to LbyR, for example in SIP (Session 150 Inititiation Protocol), is the transporting of the location URI, in 151 this case, between any successive signaling nodes. 153 4. Dereference of a location URI, a request/response between a 154 client having a location URI and a location server holding the 155 location information that the location URI references. 157 5. Termination of a location URI, either due to expiration or 158 cancellation within a location server, and which is based on a Target 159 cancellation request or some other action, such as timer 160 expiration. 162 Note that this document makes no functional differentiation between a 163 Location Server (LS), per [RFC3693], and a Location Information 164 Server (LIS), as shown in [I-D.ietf-geopriv-l7-lcp-ps]), but may 165 refer to either of them as a location server interchangeably. 167 Location determination, as distinct from location configuration or 168 dereferencing, often includes topics related to manual provisioning 169 processes, automated location calculations based on a variety of 170 measurement techniques, and/or location transformations, (e.g., geo- 171 coding), and is beyond the scope of this document. 173 Location Conveyance for either LbyR or LbyV, as defined within SIP 174 signaling is considered out of scope for this document (see 175 [I-D.ietf-sip-location-conveyance] for an explanation of location 176 conveyance for either LbyR or LbyV scenarios.) 178 Except for location conveyance, the above stages in the LbyR 179 lifecycle fall into one of two general categories of protocols, 180 either a Location Configuration Protocol or a Location Dereference 181 Protocol. The stages of LbyR Creation, Distribution, and 182 Termination, are each found within the set of Location Configuration 183 Protocols (LCP). The Dereference stage belongs solely to the set of 184 Location Dereference Protocols. 186 The issues around location configuration protocols have been 187 documented in a location configuration protocol problem statement and 188 requirements document [I-D.ietf-geopriv-l7-lcp-ps]. There are 189 currently several examples of documented location configuration 190 protocols, namely DHCP DHCP [I-D.ietf-geopriv-dhcp-lbyr-uri-option], 191 LLDP-MED [LLDP-MED], and HELD HELD 192 [I-D.ietf-geopriv-http-location-delivery] protocols. 194 For dereferencing of a location URI, depending on the type of 195 reference used, such as a HTTP/HTTPS, or SIP Presence URI, different 196 operations can be performed. While an HTTP/HTTPS URI can be resolved 197 to location information, a SIP Presence URI provides further benefits 198 from the SUBSCRIBE/NOTIFY concept that can additionally be combined 199 with location filters [I-D.ietf-geopriv-loc-filters]. 201 The structure of this document includes terminology, Section 2, 202 followed by a discussion of the basic elements that surround how a 203 location URI is used. These elements, or actors, are discussed in an 204 overview section, Section 3, accompanied by a graph, associated 205 processing steps, and a brief discussion around the use, expiration, 206 authorization, and construction of location URIs. 208 Requirements are outlined accordingly, separated as location 209 configuration requirements, Section 4.1, and location dereference 210 requirements, Section 4.2. 212 2. Terminology 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in RFC 2119 [RFC2119], 217 with the important qualification that, unless otherwise stated, these 218 terms apply to the design of the Location Configuration Protocol and 219 the Location Dereferencing Protocol, not its implementation or 220 application. 222 This document reuses the terminology of [RFC3693], such as Location 223 Server (LS), Location Recipient (LR), Rule Maker (RM), Target, 224 Location Object (LO). Furthermore, the following terms are defined 225 in this document: 227 Location-by-Value (LbyV): Using location information in the form of 228 a location object (LO), such as a PIDF-LO. 230 Location-by-Reference (LbyR): Representing location information 231 indirectly using a location URI. 233 Location Configuration Protocol: A protocol that is used by a Target 234 to acquire either location object or a location URI from a 235 location configuration server, based on information unique to the 236 Target. 238 Location Dereference Protocol: A protocol that is used by a client 239 to query a location server, based on the location URI input and 240 which returns location information. 242 Location URI: As defined within this document, an identifier that 243 serves as a reference to location information. A location URI is 244 provided by a location server, and is later used as input by a 245 dereference protocol to retrieve location information. 247 3. Overview of Location-by-Reference 249 This section describes the entities and interactions involved in the 250 LbyR model. 252 +---------+---------+ Location +-----------+ 253 | | | Dereference | Location | 254 | LIS/LS +---------------+ Recipient | 255 | | | Protocol | | 256 +----+----+----+----+ (3) +-----+-----+ 257 | * | 258 | Policy * | 259 Location | Exchange * | 260 Configuration | (*) * | Location 261 Protocol | +----+----+ | Conveyance 262 (1) | | Rule | | Protocol 263 | | Maker | | (2) 264 +----+----+ +---------+ | 265 | | | 266 | Target +-------------------------------+ 267 | | 268 +---------+ 270 Figure 1: Location Reference Entities and Interactions 272 Figure 1 shows the assumed communication model for both a layer 7 273 location configuration protocol and a location dereference protocol. 275 1. The Target (an end device) uses a Location Configuration Protocol 276 to acquire a location reference from a LIS, which acts as (or is able 277 to access) an LS. 279 In the case where the Target is also a Rule Maker, the location 280 configuration protocol can be used to convey policy information. In 281 the case where possession of a location URI is the only required form 282 of authorization, see Section 3.3, a policy is implied whereby any 283 requester is granted access to location information. This does not 284 preclude other means of providing authorization policies. 286 A Target could also acquire a location URI from the LS directly using 287 alternative means, for example, the acquisition of a presence AoR to 288 be used for location information, in which case, it could be regarded 289 as a location URI. 291 2. The Target conveys the location URI to the Location Recipient 292 (interface out of scope). 294 3. The Location Recipient dereferences the location URI to acquire 295 location information from the LS. 297 The LS controls access to location information based on the policy 298 provided by the Rule Maker. 300 Note A. There is no requirement for using the same protocol in (1) 301 and (3). 303 Note B. Figure 1 includes the interaction between the owner of the 304 Target and the LIS to obtain Rule Maker policies. This interaction 305 needs to happen before the LIS will authorize anything other than 306 what is allowed based on default policies in order to dereference a 307 location request of the Target. This communication path is out of 308 scope for this document. 310 Note C. The Target might take on the role of the Location Recipient, 311 in which case it could attempt to dereference the location URI 312 itself, in order to obtain its own location information. 314 3.1. Location URI Usage 316 An example scenario of how the above location configuration and 317 location dereference steps might work using SIP, is where a Target 318 obtains a location URI in the form of a subscription URI (e.g., a SIP 319 URI) via a location configuration protocol. In this case, the Target 320 is the same as the Recipient, therefore the Target can subscribe to 321 the URI in order to be notified of its current location based on 322 subscription parameters. In the example, parameters are set up for a 323 specific Target/Recipient along with an expressed geospatial 324 boundary, so that the Target/Recipient receives an updated location 325 notification once the boundary is crossed (see 326 [I-D.ietf-geopriv-loc-filters]). 328 3.2. Location URI Expiration 330 Location URIs may have an expiry associated with them, primarily for 331 security considerations, and generally so that the LIS is able to 332 keep track of the location URIs that have been handed out, to know 333 whether a location URI is still valid once the LIS receives it in a 334 request, and in order for a recipient of such a URI from being able 335 to (in some cases) permanently track a host. Expiration of a 336 location URI limits the time that accidental leaking of a location 337 URI introduces. Other justifications for expiration of location URIs 338 include the ability for a LIS to do garbage collection. 340 3.3. Location URI Authorization 342 How a location URI will ultimately be used within the dereference 343 step is an important consideration at the time the location URI is 344 requested via a location configuration protocol. The process of 345 dereferencing location URIs will be influenced by the specific 346 authorization model applied by the Location Information Server and 347 the URI scheme that indicates the protocol to be used to resolve the 348 reference to a location object. 350 Location URIs manifest themselves in a few different forms. The 351 different ways that a location URI can be represented is based on 352 local policy, and are depicted in the following four scenarios. 354 1. No location information included in the URI: As is typical, a 355 location URI is used to get location information. However, in 356 this case, the URI representation itself does not need to reveal 357 any specific information at all. Location information is acquired 358 by the dereferencing operation using a location URI. 360 2. URI does not identify a Target: By default, a location URI MUST 361 NOT reveal any information about the Target other than location 362 information. This is true for the URI itself, (or in the document 363 acquired by dereferencing), unless policy explicitly permits 364 otherwise. 366 3. Access control authorization model: If the "access control 367 authorization model" is used, the location URI MUST NOT include 368 any location information in its representation. Location URIs 369 operating under this model could be widely published to recipients 370 that are not authorized to receive this information. 372 4. Possession authorization model (the URI itself is a secret): If 373 the "possession authorization" model is used, the location URI is 374 confidential information shared between the LIS/LS, the Target and 375 all authorized Location Recipients. In this case, possession 376 implies authorization. Because knowledge of the location URI is 377 used to authenticate and authorize access to location information, 378 the URI needs to include sufficient randomness to make guessing 379 its value difficult. A possession model URI can include location 380 information in its representation. 382 3.4. Location URI Construction 384 Given scenarios 2 and 4, above, and depending on local policy, a 385 location URI may be constructed in such a way as to make it difficult 386 to guess. Accordingly, the form of the URI is then constrained by 387 the degree of randomness and uniqueness applied to it. In this case, 388 it may be important to protect the actual location information from 389 inspection by an intermediate node. Construction of a location URI 390 in such a way as to not reveal any Target specific, (e.g., user or 391 device), information, with the goal of making the location URI appear 392 bland, uninteresting, and generic, may be helpful to some degree in 393 order to keep location information more difficult to detect. Thus, 394 obfuscating the location URI in this way may provide some level of 395 safeguard against the undetected stripping off of what would 396 otherwise be evident location information, since it forces a 397 dereference operation at the location dereference server, an 398 important step for the purpose of providing statistics, audit trails, 399 and general logging for many different kinds of location based 400 services. 402 4. High-Level Requirements 404 This document outlines the requirements for an Location by Reference 405 mechanism which can be used by a number of underlying protocols. 406 Requirements here address two general types of such protocols, a 407 general location configuration protocol, and a general location 408 dereferencing protocol. 410 The requirements are broken into two sections. 412 4.1. Requirements for a Location Configuration Protocol 414 Below, we summarize high-level design requirements needed for a 415 location-by-reference mechanism as used within the location 416 configuration protocol. 418 C1. Location URI support: The location configuration protocol MUST 419 support a location reference in URI form. 421 Motivation: A standardized location reference mechanism increases 422 interoperability. 424 C2. Location URI expiration: When a location URI has a limited 425 validity interval, its lifetime MUST be indicated. 427 Motivation: A location URI may not intend to represent a location 428 forever, and the identifier eventually may need to be recycled, or 429 may be subject to a specific window of validity, after which the 430 location reference fails to yield a location, or the location is 431 determined to be kept confidential. 433 C3. Location URI cancellation: The location configuration protocol 434 MUST support the ability to request a cancellation of a specific 435 location URI. 437 Motivation: If the Target determines that a location URI should no 438 longer be used to dereference a location, then there should be a 439 way to request that the location URI be nullified." 441 C4. Location Information Masking: The location URI MUST ensure, by 442 default, through randomization and uniqueness, that the location 443 URI does not contain location information specific components. 445 Motivation: It is important to keep any location information 446 masked from a casual observing node. 448 C5. Target Identity Protection: The location URI MUST NOT contain 449 information that identifies the Target (e.g., user or device). 450 Examples include phone extensions, badge numbers, first or last 451 names. 453 Motivation: It is important to protect caller identity or contact 454 address from being included in the form of the location URI itself 455 when it is generated. 457 C6. Reuse indicator: There SHOULD be a way to allow a Target to 458 control whether a location URI can be resolved once only, or 459 multiple times. 461 Motivation: The Target requesting a location URI may request a 462 location URI which has a 'one-time-use' only characteristic, as 463 opposed to a location URI having multiple reuse capability. This 464 would allow the server to return an error with or without location 465 information during the subsequent dereference operation. 467 C7. Selective disclosure: The location configuration protocol MUST 468 provide a mechanism that allows the Rule Maker to control what 469 information is being disclosed about the Target. 471 Motivation: The Rule Maker has to be in control of how much 472 information is revealed during the dereferencing step as part of 473 the privacy features. 475 C8. Location URI Not guessable: As a default, the location 476 configuration protocol MUST return location URIs that are random 477 and unique throughout the indicated lifetime. A location URI with 478 128-bits of randomness is RECOMMENDED. 480 Motivation: Location URIs should be constructed in such a way that 481 an adversary cannot guess them and dereference them without having 482 previously obtained them from the Target. 484 C9. Location URI Options: In the case of user-provided authorization 485 policies, where anonymous or non-guessable location URIs are not 486 warranted, the location configuration protocol MAY support a 487 variety of optional location URI conventions, as requested by a 488 Target to a location configuration server, (e.g., embedded 489 location information within the location URI). 491 Motivation: Users don't always have such strict privacy 492 requirements, but may opt to specify their own location URI, or 493 components to be included within a location URI. 495 4.2. Requirements for a Location Dereference Protocol 497 Below, we summarize high-level design requirements needed for a 498 location-by-reference mechanism as used within the location 499 dereference protocol. 501 D1. Location URI support: The location dereference protocol MUST 502 support a location reference in URI form. 504 Motivation: It is required that there be consistency of use 505 between location URI formats used in a configuration protocol and 506 those used by a dereference protocol. 508 D2. Authentication: The location dereference protocol MUST include 509 mechanisms to authenticate both the client and the server. 511 Motivation: Although the implementations must support 512 authentication of both parties, any given transaction has the 513 option not to authenticate one or both parties. 515 D3. Dereferenced Location Form: The value returned by the 516 dereference protocol MUST contain a well-formed PIDF-LO document. 518 Motivation: This is in order to ensure that adequate privacy rules 519 can be adhered to, since the PIDF-LO format comprises the 520 necessary structures to maintain location privacy. 522 D4. Location URI Repeated Use: The location dereference protocol 523 MUST support the ability for the same location URI to be resolved 524 more than once, based on dereference server configuration. 526 Motivation: Through dereference server configuration, for example, 527 it may be useful to not only allow more than one dereference 528 request, but, in some cases, to also limit the number of 529 dereferencing attempts by a client. 531 D5. Location Confidentiality: The location dereference protocol MUST 532 support confidentiality protection of messages sent between the 533 Location Recipient and the location server. 535 Motivation: The location URI indicates what type of security 536 protocol has to be provided. An example is a location URI using a 537 HTTPS URI scheme. 539 5. Security Considerations 541 The method of constructing the location URI to include randomized 542 components helps to prevent adversaries from obtaining location 543 information without ever retrieving a location URI. In the 544 possession model, a location URI, regardless of its construction, if 545 made publically available, implies no safeguard against anyone being 546 able to dereference and get the location. Care has to be paid when 547 distributing such a location URI to the trusted location recipients. 548 When this aspect is of concern then the authorization model has to be 549 chosen. Even in this model care has to be taken on how to construct 550 the authorization policies to ensure that only those parties have 551 access to location information that are considered trustworthy enough 552 to enforce the basic rule set that is attached to location 553 information in a PIDF-LO document. 555 Any location URI, by necessity, indicates the server (name) that 556 hosts the location information. Knowledge of the server in some 557 specific domain could therefore reveal something about the location 558 of the Target. This kind of threat may be mitigated somewhat by 559 introducing another layer of indirection: namely the use of a 560 (remote) presence server. 562 A covert channel for protocol message exchange is an important 563 consideration, given an example scenario where user A subscribes to 564 location information for user B, then every time A gets a location 565 update an (external) observer of the subscription notification may 566 know that B has moved. One mitigation to this is to have periodic 567 notification, so that user B may appear to have moved, even when 568 static. 570 6. IANA Considerations 572 This document does not require actions by the IANA. 574 7. Acknowledgements 576 I would like to thank the present IETF GEOPRIV working group chairs, 577 Alissa Cooper and Richard Barnes, past chairs, Robert Sparks, Andy 578 Newton, Allison Mankin and Randall Gellens, who established a design 579 team that initiated this requirements work. I'd also like to thank 580 those original design team participants for their inputs, comments, 581 and insightful reviews. The design team included the following 582 folks: Richard Barnes; Martin Dawson; Keith Drage; Randall Gellens; 583 Ted Hardie; Cullen Jennings; Marc Linsner; Rohan Mahy; Allison 584 Mankinl; Andrew Newton; Jon Peterson; James M. Polk; Brian Rosen; 585 John Schnizlein; Henning Schulzrinne; Barbara Stark; Hannes 586 Tschofenig; Martin Thomson; and James Winterbottom. 588 8. References 590 8.1. Normative References 592 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, March 1997. 595 8.2. Informative References 597 [I-D.ietf-geopriv-dhcp-lbyr-uri-option] 598 Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 599 and IPv6 Option for a Location Uniform Resource Identifier 600 (URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-06 (work 601 in progress), September 2009. 603 [I-D.ietf-geopriv-http-location-delivery] 604 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 605 "HTTP Enabled Location Delivery (HELD)", 606 draft-ietf-geopriv-http-location-delivery-16 (work in 607 progress), August 2009. 609 [I-D.ietf-geopriv-l7-lcp-ps] 610 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 611 Location Configuration Protocol; Problem Statement and 612 Requirements", draft-ietf-geopriv-l7-lcp-ps-10 (work in 613 progress), July 2009. 615 [I-D.ietf-geopriv-loc-filters] 616 Mahy, R., Rosen, B., and H. Tschofenig, "Filtering 617 Location Notifications in the Session Initiation Protocol 618 (SIP)", draft-ietf-geopriv-loc-filters-08 (work in 619 progress), November 2009. 621 [I-D.ietf-sip-location-conveyance] 622 Polk, J. and B. Rosen, "Location Conveyance for the 623 Session Initiation Protocol", 624 draft-ietf-sip-location-conveyance-13 (work in progress), 625 March 2009. 627 [LLDP-MED] 628 TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 629 Endpoint Discovery". 631 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 632 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 634 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 635 Format", RFC 4119, December 2005. 637 Appendix A. Change log 639 Changes to this draft in comparison to the previous version (-09 vs. 640 -08), as part of the IESG review process: 642 1. clarification of missing text, Introduction, (from Alexey 643 Melnikov), change from: "ower", to "power" (as appropriate) text now 644 reads, "This is especially the case when power availability is a 645 constraint" 647 2. clarify text, Introduction, (from Spencer Dawkins, 06/03/2009), 648 change from: "Location determination, different than location 649 configuration" change to: "Location determination, as distinct from 650 location configuration" 652 3. insert text, Terminology section, (from Spencer Dawkins, 06/03/ 653 2009), change from: "to acquire either location or a location URI" 654 change to: "to acquire either location object or a location URI" 656 4. reword, section 3.3. Location URI Authorization, (from Spencer 657 Dawkins, 06/03/2009), change from: "1. No specific information at 658 all:" change to: "1. No location information included in the URI:" 660 5. rephrase, (overlay new term), section 3.3. Location URI 661 Authorization, (from Spencer Dawkins, 06/03/2009), Change from: "2. 662 No Target specific information:" Change to: "2. URI does not 663 identify a Target:" 665 6. Add text ahead of paragraph, section titled, "Location URI 666 Construction", (from Spencer Dawkins, 06/03/2009), change from: 667 "Depending on local policy," change to: "Given scenarios 2 and 4, 668 above, and depending on local policy" 670 7. reword Motivation text, req. C3, (from Spencer Dawkins, 06/03/ 671 2009), change from: "Motivation: If the Target determines that in its 672 best interest to destroy the ability for a location URI to 673 effectively be used to dereference a location, then there should be a 674 way to nullify the location URI." change to: "Motivation: If the 675 Target determines that a location URI should no longer be used to 676 dereference a location, then there should be a way to request that 677 the location URI be nullified." 679 8. reword requirement C7, (from Spencer Dawkins, 06/03/2009), "C7. 680 Selective disclosure: The location configuration protocol MUST 681 provide a mechanism to control what information is being disclosed 682 about the Target." Change to: "C7. Selective disclosure: The 683 location configuration protocol MUST provide a mechanism that allows 684 the Rule Maker to control what information is being disclosed about 685 the Target." 687 9. replace text s/ever/previously, (from Spencer Dawkins, 06/03/ 688 2009), change from: "Motivation: Location URIs should be constructed 689 in such a way that an adversary cannot guess them and dereference 690 them without having ever obtained them from the Target." change to: 691 "Motivation: Location URIs should be constructed in such a way that 692 an adversary cannot guess them and dereference them without having 693 previously obtained them from the Target." 695 10. minor fix, section 4.2, D1., s/in an/in a/1 (from Spencer 696 Dawkins, 06/03/2009), 698 11. minor fix, section 5. Security Considerations, (from Spencer 699 Dawkins, 06/03/2009), change from: "when distribution such" change 700 to: "when distributing such" 702 12. qualifying text inserted, req. C4 (from Tin Tsou, Ops Review 10/ 703 21/2009) change from: "The location URI MUST, through randomization 704 and uniqueness, ensure that the location URI does not contain 705 location information specific components. change to: "The location 706 URI MUST ensure, by default, through randomization and uniqueness, 707 that the location URI does not contain location information specific 708 components. 710 13. resolve comments from Tina Tsou relating to C4 vs. C9 711 compatibility, 713 14. resolve comments from Lisa Dusseault relating to LIS/LS 714 references and note 716 Changes to this draft in comparison to the previous version (-08 vs. 717 -07), as part of the IESG review process: 719 1. changes sent 09/02/2009 based on IESG Security comments from 720 Hilarie Orman, 06/08/2009. 722 2. changes sent 09/02/2009 based on Operational Directorate comments 723 from Hannes Tschofenig, 06/11/2009. 725 Changes to this draft in comparison to the previous version (-07 vs. 726 -06): 728 1. deleted text and reference to ID.ietf-geopriv-policy (Thomson 729 2/26/09). 731 2. replaced text in Introduction referring to SIP (Thomson). 733 3. reworded section 3.4 on location URI authorization (Thomson). 735 Changes to this draft in comparison to the previous version (-06 vs. 736 -05): 738 1. replaced diagram (Thomson). 740 2. redefined term, "Location-by-Value" (1/08/2009, Tschofenig). 742 3. redefined term, "Location-by-Reference" (Tschofenig). 744 4. redefined term, "Location Dereference Protocol" (Tschofenig). 746 5. reworded term, "Location URI" (Tschofenig). 748 6. modified steps, text, Figure 1 (Tschofenig). 750 7. deleted redundant text in paragraph, "Because a location URI..." 751 (Tschofenig). 753 8. modified Authorization model text paragraphs, (Tschofenig). 755 9. added qualifying sentence before sentence, "Thus, obfuscating the 756 location URI..." (Marshall based on question from Tschofenig). 758 10. replaced diagram with one that contains both "LIS - LS" labeling 759 (Martin). 761 11. added text to Introduction that a location URI is dynamic and may 762 change over time (Martin, 2/23/09). 764 12. section 3 text changed to make the makeup of a location URI less 765 stringent as to being guessable, etc. (Martin, 2/23/09). 767 13. reordered "C" requirements from those remaining: C8-->C7; 768 C9-->C8; C10-->C9. 770 14. reordered "D" requirements: D3-->D2; D4-->D3; D5-->D4; D10-->D5. 772 15. section-ized the overview, (section 3), for pointing to (Martin, 773 2/23/09) 775 16. edited section 3.4 to make clear that some default requirements 776 may be relaxed ONLY if explicit local policy exists. (RSM based on 777 Martin, 2/23/09). 779 17. added an citation for the geopriv-policy draft reference. 781 18. reworded first couple of paragraphs of Introduction for 782 readability. 784 Changes to this draft in comparison to the previous version (-05 vs. 785 -04): 787 1. Fixed minor spelilng errors. 789 Changes to this draft in comparison to the previous version (-04 vs. 790 -03): 792 1. Changed wording of section 1 "Introduction", (Thomson ~ 7/09/08 793 list comments). 795 1. Relocated text in section 3 "Overview of Location-by-Reference" 796 to section 1 (Intro), (Thomson comments). 798 2. (Sect. 3, con't) Fixed Figure 1. Label, based on (Thomson 799 comments). 801 3. Fixed minor spelling errors, incl. Note B., Note C., etc., based 802 on (Thomson comments). 804 4. Added some qualifying text (security) around possession model, 805 based on (Thomson comments). 807 5. Replaced "use type" labels with "authorization models", "access 808 authorization model", and "possession authorization model", (Thomson 809 comments). 811 6. Changed the entity role of applying security from LIS (Server- 812 side authentication), to the Rule Maker (owner/Target) providing 813 policies to the LIS, (Thomson comments). 815 7. Changed requirement C3 to a MUST, (Thomson comments). 817 8. Added new requirement, C12, "C12. Location URI Lifetime:" as a 818 SHOULD for all, and MUST for possession auth model, (Thomson 819 comments). 821 9. Changed name of requirement C8 to "Location Only", (Thomson 822 comments). 824 10. Reworded C7 and D6 to be less implementation specific, (Thomson 825 comments). 827 11. Changed requirements C11, D11 to SHOULD, (Thomson comments). 829 12. (Section 5:) Removed lead in sentence for readibility, (Thomson 830 comments). 832 13. Remove "pawn ticket" reference - replaced with "possession 833 authorization model", (Thomson comments). 835 14. Added new paragraph to the security section (Thomson, 7/09/08 836 comments). 838 15. Corrected other minor spelling and wording errors and 839 deficiencies (refer to diff 04/03) (-Editor). 841 Changes to this draft in comparison to the previous version (-03 vs. 842 -02): 844 1. Changed wording of section 3 "Overview of Location-by-Reference" 845 (Polk, Thomson, Winterbottom ~ 4/1/08 list comments). 847 2. Added new requirement C4. "Location Information Masking:", based 848 on (Thomson ~4/1/08 list comment). 850 3. Added new requirement C11. "Location URI Use Type:", based on 851 (~4/1/08 list comments). 853 4. Added new requirement D11. "Location URI Use Type:", for deref. 854 based on (~4/1/08 list comments). 856 5. Replaced requirement D8. "Location URI Non-Anonymized" with 857 "Location Information Masking:". 859 Changes to this draft in comparison to the previous version (-02 vs. 860 -01): 862 1. Reworded Introduction (Barnes 12/6 list comments). 864 2. Changed name of "Basic Actors" section to "Overview of Location 865 by Reference" (Barnes). 867 3. Keeping the LCP term away (for now) since it is used as Link 868 Control Protocol elsewhere (IETF). 870 4. Changed formatting of Terminology section (Barnes). 872 5. Requirement C2. changed to indicate that if the URI has a 873 lifetime, it has to have an expiry (Barnes) 875 6. C7. Changed title and wording based on suggested text and dhcp- 876 uri-option example (Polk). 878 7. The new C2 req. describing valid-for, was also added into the 879 deref section, as D6 881 8. Changed C4 based on much list discussion - replaced by 3 new 882 requirements... 884 9. Reworded C5 based on the follow-on C4 thread/discussion on list 885 (~2/18). 887 10. Changed wording of D3 based on suggestion (Barnes). 889 11. Reworded D4 per suggestion (Barnes). 891 12. Changed D5 based on comment (Barnes), and additional title and 892 text changes for clarity. 894 13. Added D9 and D10 per Richard Barnes suggestions - something 895 needed in addition to his own security doc. 897 14. Deleted reference to individual Barnes-loc-sec draft per wg list 898 suggestion (Barnes), but need more text for this draft's security 899 section. 901 Author's Address 903 Roger Marshall (editor) 904 TeleCommunication Systems, Inc. 905 2401 Elliott Avenue 906 2nd Floor 907 Seattle, WA 98121 908 US 910 Phone: +1 206 792 2424 911 Email: rmarshall@telecomsys.com 912 URI: http://www.telecomsys.com