idnits 2.17.1 draft-ietf-geopriv-lbyr-requirements-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 812. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 115 has weird spacing: '...ocation infor...' == Line 119 has weird spacing: '...llation reque...' -- 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 (November 3, 2008) is 5653 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-geopriv-policy' is defined on line 628, but no explicit reference was found in the text == Unused Reference: 'RFC4119' is defined on line 644, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-geopriv-http-location-delivery-10 == Outdated reference: A later version (-10) exists of draft-ietf-geopriv-l7-lcp-ps-08 == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-loc-filters-02 == Outdated reference: A later version (-27) exists of draft-ietf-geopriv-policy-17 == Outdated reference: A later version (-13) exists of draft-ietf-sip-location-conveyance-11 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 7 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 3, 2008 5 Expires: May 7, 2009 7 Requirements for a Location-by-Reference Mechanism 8 draft-ietf-geopriv-lbyr-requirements-04 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 7, 2009. 35 Abstract 37 This document defines terminology and provides requirements relating 38 to Location-by-Reference approach using a location URI to handle 39 location information within signaling and other Internet messaging. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 45 3. Overview of Location-by-Reference . . . . . . . . . . . . . . 7 46 4. High-Level Requirements . . . . . . . . . . . . . . . . . . . 10 47 4.1. Requirements for a Location Configuration Protocol . . . 10 48 4.2. Requirements for a Location Dereference Protocol . . . . 12 49 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 50 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 51 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 52 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 53 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 54 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 55 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 19 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 57 Intellectual Property and Copyright Statements . . . . . . . . . . 23 59 1. Introduction 61 Since all location-based services rely on ready access to location 62 information, this can accomplished through some direct means, or 63 alternatively, through some indirect means as a pointer to location 64 information. The direct vs. indirect approach we characterize as 65 either Location-by-Value (LbyV), or Location-by-Reference (LbyR). 67 While it is the case that within SIP, location can be handled in a 68 direct manner, (i.e., passing the actual location information around 69 in the form of a PIDF-LO*), there are additional location 70 requirements which apply to certain applications and/or location 71 architectures that are only satisfied by specifying an indirect 72 location mechanism. This document puts forth a set of requirements 73 for such an indirect location approach, namely, the LbyR location 74 model. 76 As justification for a LbyR model, consider the following. In some 77 mobile networks it is not efficient for the end host to periodically 78 query the LIS for up-to-date location information. This is 79 especially the case when power is a constraint or when a location 80 update is not immediately needed. Furthermore, the end host might 81 want to delegate the task of retrieving and publishing location 82 information to a third party, such as to a presence server. 83 Additionally, in some deployments, the network operator may not want 84 to make location information widely available. These kinds of 85 location scenarios, and more, such as whether a Target is mobile and 86 whether a mobile device needs to be located on demand or according to 87 some pre-determined interval, together form the basis of motivation 88 for the LbyR concept. 90 The concept of an LbyR mechanism is simple. It is made up of a 91 pointer which makes reference to the actual location information by 92 some combination of key value and fully qualified domain name. This 93 combination of data elements, in the form of a URI, is referred to 94 specifically as a "location URI". 96 The LbyR mechanism itself works according to an information 97 lifecycle. Within the LbyR mechanism, location URIs are temporary 98 identifiers, each undergoing the following uses: Creation; 99 Distribution; Conveyance; Dereference; and Termination. The use of a 100 location URI according to these various states is generally applied 101 in one of the following ways: 103 1. Creation of a location URI, within a location server, based on 104 some request for its creation. 106 2. Distribution of a location URI, via a Location Configuration 107 Protocol, between a target and a location server**. 109 3. Conveyance, applied to LbyR, in SIP, is the transporting of the 110 location URI, in this case, between any successive signaling 111 nodes***. 113 4. Dereference of a location URI, a request/response between a 114 client having a location URI and a location server holding the 115 location information that the location URI references. 117 5. Termination of a location URI, either due to expiration or 118 cancellation within a location server, and which is based on a target 119 cancellation request or some other action, such as timer 120 expiration. 122 Location determination, different than location configuration or 123 dereferencing, often includes topics related to manual provisioning 124 processes, automated location calculations based on a variety of 125 measurement techniques, and/or location transformations, (e.g., geo- 126 coding), and is beyond the scope of this document. 128 *The standard mechanism for LbyV has been defined around the use of 129 the PIDF-LO (Presence Information Document Format - Location Object 130 [RFC4119]]), and is explicitly out of scope in this document. 132 **This document make no differentiation between a LS, per RFC3693, 133 and a LIS [ref. draft-ietf-geopriv-l7-lcp-ps], but may refer to 134 either of them as a location server interchangeably. 136 ***Location Conveyance for either LbyR or LbyV, within SIP signaling 137 is considered out of scope for this document (see 138 [I-D.ietf-sip-location-conveyance] for an explanation of location 139 conveyance for either LbyR or LbyV scenarios.) 141 Except for location conveyance, the above stages in the LbyR 142 lifecycle fall into one of two general categories of protocols, 143 either a Location Configuration Protocol or a Location Dereference 144 Protocol. The stages of LbyR Creation, Distribution, and 145 Termination, are each found within the set of Location Configuration 146 Protocols (LCP). The Dereference stage belongs solely to the set of 147 Location Dereference Protocols. 149 The issues around location configuration protocols have been 150 documented in a location configuration protocol problem statement and 151 requirements document [I-D.ietf-geopriv-l7-lcp-ps]. There are 152 currently several examples of a location configuration protocols 153 currently proposed, including, DHCP, LLDP-MED, and HELD 154 [I-D.ietf-geopriv-http-location-delivery]) protocols. 156 For dereferencing of a location URI, depending on the type of 157 reference used, such as a HTTP/HTTPS, or SIP Presence URI, different 158 operations can be performed. While an HTTP/HTTPS URI can be resolved 159 to location information, a SIP Presence URI provides further benefits 160 from the SUBSCRIBE/NOTIFY concept that can additionally be combined 161 with location filters [I-D.ietf-geopriv-loc-filters]. 163 The structure of this document includes terminology, Section 2, 164 followed by a discussion of the basic elements that surround how a 165 location URI is used. These elements, or actors, are discussed in an 166 overview section, Section 3, accompanied by a graph and associated 167 processing steps. 169 Requirements are outlined accordingly, separated as location 170 configuration requirements, Section 4.1, and location dereference 171 requirements, Section 4.2. 173 2. Terminology 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119 [RFC2119]. 179 This document reuses the terminology of [RFC3693], such as Location 180 Server (LS), Location Recipient (LR), Rule Maker (RM), Target, 181 Location Generator (LG), Location Object (LO), and Using Protocol: 183 Location-by-Value (LbyV): The mechanism of representing location 184 either in configuration or conveyance protocols, (i.e., the actual 185 included location value). 187 Location-by-Reference (LbyR): The mechanism of representing location 188 by means of a location URI for use in either a location 189 configuration, conveyance, or dereferencing protocol, and which 190 refers to a fully specified location. 192 Location Configuration Protocol: A protocol which is used by a 193 client to acquire either location or a location URI from a 194 location configuration server, based on information unique to the 195 client. 197 Location Dereference Protocol: A protocol which is used by a client 198 to query a location dereference server, based on location URI 199 input and which returns location information. 201 Location URI: An identifier which serves as a pointer to a location 202 record on a remote host (e.g., LIS). Used within an Location-by- 203 Reference mechanism, a location URI is provided by a location 204 configuration server, and is used as input by a dereference 205 protocol to retrieve location from a dereference server. 207 3. Overview of Location-by-Reference 209 This section describes the entities and interactions involved in the 210 LbyR model. 212 +-----------+ Geopriv +-----------+ 213 | | Location | Location | 214 | LIS +---------------+ Recipient | 215 | | Dereference | | 216 +-+---+-----+ Protocol (3) +----+------+ 217 * | -- 218 Rulemaker * | Geopriv -- 219 Policy * | Location -- 220 Exchange * | Configuration -- 221 (1b) * | Protocol -- 222 * | (1a) -- Geopriv 223 * | -- Using Protocol 224 + - - - -*- - - - - -|- - - -+ -- (e.g., SIP) 225 |+------+----+ +-----+-----+ |-- (2) 226 | Rulemaker | | Target / |-- 227 || / owner | | End Host + | 228 | | | | 229 |+-----------+ +-----------+ | 231 | User of Target | 232 + - - - - - - - - - - - - - -+ 234 Figure 1: Location Reference Entities and Interactions 236 Figure 1 shows the assumed communication model for both a layer 7 237 location configuration protocol and a location dereference protocol. 239 (1a). Target requests reference from server; and receives back, a 240 location URI in server response 242 (1b). Rulemaker policy is consulted (interface out of scope) 244 (2). Target conveys reference to recipient (out of scope) 246 (3). Recipient dereferences location URI, by a choice of methods, 247 including a request/response (e.g., HTTP) or publish/subscription 248 (e.g., SIP SUBSCRIBE/NOTIFY) 250 Note A. There is no requirement for using the same protocol in (1a) 251 and (3). 253 Note B. Figure 1 includes the interaction between the owner of the 254 Target and the LIS to establish Rulemaker policies. This is 255 communications path (1b). This interaction needs to be done before 256 the LIS will authorize anything other than default policies to a 257 dereference request for location of the Target. 259 Note C. The Target may take on the role of the Location Recipient 260 whereby it would dereference the location URI to obtain its own 261 location information. 263 An example scenario of how this might work, is where the Target 264 obtains a location URI in the form of a subscription URI (e.g., a SIP 265 URI) via HELD (a Geopriv layer 7 location configuration protocol). 266 In this case, the Target is the same as the Recipient, therefore the 267 Target can subscribe to the URI in order to be notified of its 268 current location based on subscription parameters. In the example, 269 parameters are set up for a specific Target/Recipient along with an 270 expressed geospatial boundary, so that the Target/Recipient receives 271 an updated location notification once the boundary is crossed (see 272 [I-D.ietf-geopriv-loc-filters]). 274 Location URIs may have an expiry associated with them, primarily for 275 security considerations, and generally so that the LIS is able to 276 keep track of the location URIs that have been handed out, to know 277 whether a location URI is still valid once the LIS receives it in a 278 request, and in order for a recipient of such a URI from being able 279 to (in some cases) permanently track a host. Expiration of a 280 location URI limits the time that accidental leaking of a location 281 URI introduces. Other justifications for expiration of location URIs 282 include the ability for a LIS to do garbage collection. 284 Because a location URI is a pointer to the Target's location, it is 285 important that it be constructed in such a way that it does not 286 unintentionally reveal any usable information about the Target it 287 represents. For example, it is important to prevent adversaries from 288 obtaining any information that may be revealed about a Target by 289 direct examination of the location URI itself, (e.g., names, 290 identifiers, etc.), some determinable pattern or syntax (e.g., 291 sequence of numbers), or guessable codes (e.g., weak encryption). 292 Therefore, each location URI must be constructed with security 293 safeguards in mind. 295 How a location URI is will ultimately be used within the dereference 296 step is an important consideration at the time that the location URI 297 is requested via a location configuration protocol. Since 298 dereferencing of location URIs could be done according to one of two 299 authorization models, either an "access control authorization model" 300 or a "possession authorization model" (see definitions, below), it is 301 important that location configuration protocols indicate the type of 302 a location URI that is being requested, (and also which type is 303 returned). 305 1. Access control authorization model: Access to the location URI is 306 limited by policy. In this case, the Rule Maker (owner/Target) is 307 able to provide authorization policies to the LIS during this 308 stage, or through some other parallel mechanism (e.g., interface 309 1b., Figure 1.). Policies are attached to a location URI through 310 an (undisclosed) mechanism. 312 2. Possession authorization model: The possession authorization 313 model is described as having no authentication and/or 314 authorization requirement aside from only possessing the location 315 URI itself. In this case, possession implies authorization. 316 Access to the location URI is limited by distribution only. 317 Whoever possesses the location URI has the ability to dereference 318 it. Possession authorization models may be used within specified 319 domains only, or might be used across wide open public networks. 321 In either of the above cases, a location URI needs to be constructed 322 is such a way as to make it difficult to guess. The form of the URI 323 is constrained by the degree of randomness and uniqueness applied to 324 it. It is important to protect the actual location information from 325 an intermediate node (despite the fact that in the possession model 326 there would be nothing to prevent an interceptor from seeking to 327 dereference the location URI). Obfuscating the location URI 328 safeguards against the undetected stripping off of what would 329 otherwise be evident location information, since it forces a 330 dereference operation by the location dereference server, an 331 important step for the purpose of providing statistics, audit trails, 332 and general logging for many different kinds of location based 333 services. 335 4. High-Level Requirements 337 This document outlines the requirements for an Location by Reference 338 mechanism which can be used by a number of underlying protocols. 339 Requirements here address two general types of such protocols, a 340 general location configuration protocol, and a general location 341 dereferencing protocol. Each of these two general protocols has 342 multiple specific protocol implementations. Location configuration 343 protocols include, HELD, DHCP, and LLDP-MED, whereas current location 344 dereferencing protocols include HELD Deref, HTTP GET, and SIP 345 SUBSCRIBE/NOTIFY. Because each of these specific protocol 346 implementations has its own unique client and server interactions, 347 the requirements here are not intended to state what a client or 348 server is expected to do, but rather which requirements must be met 349 separately by any location configuration protocol or location 350 dereference protocol, for the purposes of using a location URI. 352 The requirements are broken into two sections. 354 4.1. Requirements for a Location Configuration Protocol 356 Below, we summarize high-level design requirements needed for a 357 location-by-reference mechanism as used within the location 358 configuration protocol. 360 C1. Location URI support: The configuration protocol MUST support a 361 location reference in URI form. 363 Motivation: It is helpful to have a consistent form of key for the 364 LbyR mechanism. 366 C2. Location URI expiration: When a location URI has a limited 367 validity interval, its lifetime MUST be indicated. 369 Motivation: A location URI may not intend to represent a location 370 forever, and the identifier eventually may need to be recycled, or 371 may be subject to a specific window of validity, after which the 372 location reference fails to yield a location, or the location is 373 determined to be kept confidential. 375 C3. Location URI cancellation: The location configuration protocol 376 MUST support the ability to request a cancellation of a specific 377 location URI. 379 Motivation: If the client determines that in its best interest to 380 destroy the ability for a location URI to effectively be used to 381 dereference a location, then there should be a way to nullify the 382 location URI. 384 C4. Location Information Masking: The location URI form MUST, 385 through randomization and uniqueness, ensure that any location 386 specific information embedded within the location URI itself is 387 kept obscure during location configuration. 389 Motivation: It is important to keep any location information 390 masked from a casual observing node. 392 C5. User Identity Protection: The location URI MUST NOT contain any 393 user identifying information that identifies the user, device or 394 address of record, (e.g., which includes phone extensions, badge 395 numbers, first or last names, etc.), within the URI form. 397 Motivation: It is important to protect caller identity or contact 398 address from being included in the form of the location URI itself 399 when it is generated. 401 C6. Reuse indicator: There SHOULD be a way to allow a client to 402 control whether a location URI can be resolved once only, or 403 multiple times. 405 Motivation: The client requesting a location URI may request a 406 location URI which has a 'one-time-use' only characteristic, as 407 opposed to a location URI having multiple reuse capability. 409 C7. Validity Interval Indication: A location configuration protocol 410 MUST provide an indication of the location URI validity interval 411 (i.e., expiry time) when present. 413 Motivation: It is important to be able to determine how long a 414 location URI is to remain useful for, and when it must be 415 refreshed. 417 C8. Location only: The location URI MUST NOT point to any 418 information about the Target other than it's location. 420 Motivation: A user should have the option to control how much 421 information is revealed about them. This provides that control by 422 not forcing the inclusion of other information with location, 423 (e.g., to not include any identification information in the 424 location URI.) 426 C9. Location URI Not guessable: Where location URIs are used 427 publicly, any location URI MUST be constructed using properties of 428 uniqueness and cryptographically random sequences so that it is 429 not guessable. (Note that the number of bits depends to some 430 extent on the number of active location URIs that might exist at 431 the one time; 128-bit is most likely enough for the near term.) 432 Motivation: Location URIs need to guard against any observing node 433 or individual stripping off meaningful information about the 434 Target. 436 C10. Location URI Optional: In the case of user-provided 437 authorization policies, where anonymous or non-guessable location 438 URIs are not warranted, the location configuration protocol MAY 439 support optional location URI forms. 441 Motivation: Users don't always have such strict privacy 442 requirements, but may opt to specify their own location URI, or 443 components thereof. 445 C11. Location URI Authorization Model: The location configuration 446 protocol SHOULD indicate whether the requested location URI 447 conforms to the access control authorization model or the 448 possession authorization model. 450 Motivation: Downstream dereference clients and servers need to 451 know whether a location URI provided by the location configuration 452 protocol conforms to an access control authorization model or a 453 possession authorization model. 455 C12. Location URI Lifetime: A location URI SHOULD have an 456 associated expiration lifetime (i.e., validity interval), and MUST 457 have an validity interval if used with the possession 458 authorization model. 460 Motivation: If a location URI is unintentionally leaked, then the 461 amount of time that the reference can be potentially used by an 462 unknown attacker (or, casual observer) needs to be limited. 464 4.2. Requirements for a Location Dereference Protocol 466 Below, we summarize high-level design requirements needed for a 467 location-by-reference mechanism as used within the location 468 dereference protocol. 470 D1. Location URI support: The location dereference protocol MUST 471 support a location reference in URI form. 473 Motivation: It is required that there be consistency of use 474 between location URI formats used in an configuration protocol and 475 those used by a dereference protocol. 477 D2. Validity Interval Indication: A location dereference protocol 478 MUST provide an indication of the location URI validity interval 479 (i.e., expiry time) when present. 481 Motivation: It is important to be able to determine how long a 482 location URI is to remain useful for, and what time it will no 483 longer be usable. 485 D3. Authentication: The location dereference protocol MUST include 486 mechanisms to authenticate both the client and the server. 488 Motivation: Although the implementations must support 489 authentication of both parties, any given transaction has the 490 option not to authenticate one or both parties. 492 D4. Dereferenced Location Form: The value returned by the 493 dereference protocol MUST contain a well-formed PIDF-LO document. 495 Motivation: This is in order to ensure that adequate privacy rules 496 can be adhered to, since the PIDF-LO format comprises the 497 necessary structures to maintain location privacy. 499 D5. Location URI Repeated Use: The location dereference protocol 500 MUST support the ability for the same location URI to be resolved 501 more than once, based on dereference server configuration. 503 Motivation: Through dereference server configuration, for example, 504 it may be useful to not only allow more than one dereference 505 request, but, in some cases, to also limit the number of 506 dereferencing attempts by a client. 508 D6. Validity Interval Indication: A dereference protocol MUST 509 provide an indication of the location URI validity interval (i.e., 510 expiry time) when present. 512 Motivation: It is important to be able to determine how long a 513 location URI is to remain useful for, and when it must be 514 refreshed. 516 D7. Location URI anonymized: Any location URI whose dereference will 517 not be subject to authentication and access control MUST be 518 anonymized. 520 Motivation: The dereference protocol must define an anonymized 521 format for location URIs. This format must identify the desired 522 location information via a random token with at least 128 bits of 523 entropy (rather than some kind of explicit identifier, such as an 524 IP address). 526 D8. Location Information Masking: The location URI form MUST, 527 through randomization and uniqueness, ensure that any location 528 specific information embedded within the location URI itself is 529 kept obscure during location URI dereferencing. 531 Motivation: It is important to keep any location information 532 masked from a casual observing node, requiring instead a discrete 533 dereference operation in order to return location information. 535 D9. Location Privacy: The location dereference protocol MUST support 536 the application of privacy rules to the dissemination of a 537 requested location object. 539 Motivation: The dereference server must obey all provisioned 540 privacy rules that apply to a requested location object. 542 D10. Location Confidentiality: The dereference protocol MUST 543 support encryption of messages sent between the location 544 dereference client and the location dereference server, and MAY 545 alternatively provide messaging unencrypted. 547 Motivation: Environmental and local configuration policy will 548 guide the requirement for encryption for certain transactions. In 549 some cases, encryption may be the rule, in others, it may be 550 acceptable to send and receive messages without encryption. 552 D11. Location URI Authorization Model: The location dereference 553 protocol SHOULD indicate whether the requested location URI 554 conforms to the access control authorization model or the 555 possession authorization model. 557 Motivation: Downstream dereference clients need to know whether a 558 location URI provided by the location configuration protocol 559 conforms to an access control authorization model or a possession 560 authorization model in order to save time processing dereference 561 attempts. 563 5. Security Considerations 565 A location URI, regardless of its construction, if public, by itself, 566 implies no safeguard against anyone being able to dereference and get 567 the location. The method of constructing the location URI form to 568 include randomization along with encryption does help prevent some 569 potential pattern guessing. In the case of one time use location 570 URIs, (referred to as a pawn ticket), the argument can be made that 571 possession implies permission, and location URIs that are public are 572 protected only by privacy rules enforced at the dereference server. 574 Any location URI, by necessity, indicates the server (name) that 575 hosts the location information. Knowledge of the server in some 576 specific domain could therefore reveal something about the location 577 of the Target. This kind of threat may be mitigated somewhat by 578 introducing another layer of indirection: namely the use of a 579 (remote) presence server. 581 6. IANA Considerations 583 This document does not require actions by the IANA. 585 7. Acknowledgements 587 I would like to thank the present IETF GEOPRIV working group chair 588 for their continued support in progressing this document along, as 589 well, I wish to thank past chairs, Andy Newton, Allison Mankin and 590 Randall Gellens, for creating the design team which initiated this 591 requirements work. I'd also like to thank those original design team 592 participants for their inputs, comments, and insightful reviews. The 593 design team included the following folks: Richard Barnes; Martin 594 Dawson; Keith Drage; Randall Gellens; Ted Hardie; Cullen Jennings; 595 Marc Linsner; Rohan Mahy; Allison Mankin; Roger Marshall; Andrew 596 Newton; Jon Peterson; James M. Polk; Brian Rosen; John Schnizlein; 597 Henning Schulzrinne; Barbara Stark; Hannes Tschofenig; Martin 598 Thomson; and James Winterbottom. 600 8. References 602 8.1. Normative References 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 8.2. Informative References 609 [I-D.ietf-geopriv-http-location-delivery] 610 Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, 611 "HTTP Enabled Location Delivery (HELD)", 612 draft-ietf-geopriv-http-location-delivery-10 (work in 613 progress), October 2008. 615 [I-D.ietf-geopriv-l7-lcp-ps] 616 Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 617 Location Configuration Protocol; Problem Statement and 618 Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in 619 progress), June 2008. 621 [I-D.ietf-geopriv-loc-filters] 622 Mahy, R. and B. Rosen, "A Document Format for Filtering 623 and Reporting Location Notications in the Presence 624 Information Document Format Location Object (PIDF-LO)", 625 draft-ietf-geopriv-loc-filters-02 (work in progress), 626 July 2008. 628 [I-D.ietf-geopriv-policy] 629 Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 630 and J. Polk, "Geolocation Policy: A Document Format for 631 Expressing Privacy Preferences for Location Information", 632 draft-ietf-geopriv-policy-17 (work in progress), 633 June 2008. 635 [I-D.ietf-sip-location-conveyance] 636 Polk, J. and B. Rosen, "Location Conveyance for the 637 Session Initiation Protocol", 638 draft-ietf-sip-location-conveyance-11 (work in progress), 639 October 2008. 641 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 642 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 644 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 645 Format", RFC 4119, December 2005. 647 Appendix A. Change log 649 Changes to this draft in comparison to the previous version (-04 vs. 650 -03): 652 1. Changed wording of section 1 "Introduction", (Thompson ~ 7/09/08 653 list comments). 655 1. Relocated text in section 3 "Overview of Location-by-Reference" 656 to section 1 (Intro), (Thompson comments). 658 2. (Sect. 3, con't) Fixed Figure 1. Label, based on (Thompson 659 comments). 661 3. Fixed minor spelling errors, incl. Note B., Note C., etc., based 662 on (Thompson comments). 664 4. Added some qualifying text (security) around possession model, 665 based on (Thompson comments). 667 5. Replaced "use type" labels with "authorization models", "access 668 authorization model", and "possession authorization model", (Thompson 669 comments). 671 6. Changed the entity role of applying security from LIS (Server- 672 side authentication), to the Rule-Maker (owner/Target) providing 673 policies to the LIS, (Thompson comments). 675 7. Changed requirement C3 to a MUST, (Thompson comments). 677 8. Added new requirement, C12, "C12. Location URI Lifetime:" as a 678 SHOULD for all, and MUST for possession auth model, (Thompson 679 comments). 681 9. Changed name of requirement C8 to "Location Only", (Thompson 682 comments). 684 10. Reworded C7 and D6 to be less implementation specific, (Thompson 685 comments). 687 11. Changed requirements C11, D11 to SHOULD, (Thompson comments). 689 12. (Section 5:) Removed lead in sentence for readibility, (Thompson 690 comments). 692 13. Remove "pawn ticket" reference - replaced with "possession 693 authorization model", (Thompson comments). 695 14. Added new paragraph to the security section (Thompson, 7/09/08 696 comments). 698 15. Corrected other minor spelling and wording errors and 699 deficiencies (refer to diff 04/03) (-Editor). 701 Changes to this draft in comparison to the previous version (-03 vs. 702 -02): 704 1. Changed wording of section 3 "Overview of Location-by-Reference" 705 (Polk, Thomson, Winterbottom ~ 4/1/08 list comments). 707 2. Added new requirement C4. "Location Information Masking:", based 708 on (Thomson ~4/1/08 list comment). 710 3. Added new requirement C11. "Location URI Use Type:", based on 711 (~4/1/08 list comments). 713 4. Added new requirement D11. "Location URI Use Type:", for deref. 714 based on (~4/1/08 list comments). 716 5. Replaced requirement D8. "Location URI Non-Anonymized" with 717 "Location Information Masking:". 719 Changes to this draft in comparison to the previous version (-02 vs. 720 -01): 722 1. Reworded Introduction (Barnes 12/6 list comments). 724 2. Changed name of "Basic Actors" section to "Overview of Location 725 by Reference" (Barnes). 727 3. Keeping the LCP term away (for now) since it is used as Link 728 Control Protocol elsewhere (IETF). 730 4. Changed formatting of Terminology section (Barnes). 732 5. Requirement C2. changed to indicate that if the URI has a 733 lifetime, it has to have an expiry (Barnes) 735 6. C7. Changed title and wording based on suggested text and dhcp- 736 uri-option example (Polk). 738 7. The new C2 req. describing valid-for, was also added into the 739 deref section, as D6 741 8. Changed C4 based on much list discussion - replaced by 3 new 742 requirements... 744 9. Reworded C5 based on the follow-on C4 thread/discussion on list 745 (~2/18). 747 10. Changed wording of D3 based on suggestion (Barnes). 749 11. Reworded D4 per suggestion (Barnes). 751 12. Changed D5 based on comment (Barnes), and additional title and 752 text changes for clarity. 754 13. Added D9 and D10 per Richard Barnes suggestions - something 755 needed in addition to his own security doc. 757 14. Deleted reference to individual Barnes-loc-sec draft per wg list 758 suggestion (Barnes), but need more text for this draft's security 759 section. 761 Author's Address 763 Roger Marshall (editor) 764 TeleCommunication Systems, Inc. 765 2401 Elliott Avenue 766 2nd Floor 767 Seattle, WA 98121 768 US 770 Phone: +1 206 792 2424 771 Email: rmarshall@telecomsys.com 772 URI: http://www.telecomsys.com 774 Full Copyright Statement 776 Copyright (C) The IETF Trust (2008). 778 This document is subject to the rights, licenses and restrictions 779 contained in BCP 78, and except as set forth therein, the authors 780 retain all their rights. 782 This document and the information contained herein are provided on an 783 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 784 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 785 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 786 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 787 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 788 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 790 Intellectual Property 792 The IETF takes no position regarding the validity or scope of any 793 Intellectual Property Rights or other rights that might be claimed to 794 pertain to the implementation or use of the technology described in 795 this document or the extent to which any license under such rights 796 might or might not be available; nor does it represent that it has 797 made any independent effort to identify any such rights. Information 798 on the procedures with respect to rights in RFC documents can be 799 found in BCP 78 and BCP 79. 801 Copies of IPR disclosures made to the IETF Secretariat and any 802 assurances of licenses to be made available, or the result of an 803 attempt made to obtain a general license or permission for the use of 804 such proprietary rights by implementers or users of this 805 specification can be obtained from the IETF on-line IPR repository at 806 http://www.ietf.org/ipr. 808 The IETF invites any interested party to bring to its attention any 809 copyrights, patents or patent applications, or other proprietary 810 rights that may cover technology that may be required to implement 811 this standard. Please address the information to the IETF at 812 ietf-ipr@ietf.org.