GEOPRIV WG J. Winterbottom Internet-Draft M. Thomson Expires: July 24, 2006 Andrew J. Peterson NeuStar, Inc. January 20, 2006 Rationale for Location by Reference draft-winterbottom-location-uri-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 24, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract An analysis is performed on the advantages and disadvantages for provision of Location Information (LI) by-reference in the GEOPRIV architecture. The concept of a Location URI, that is, a URI that references LI, is introduced. A number of usage patterns for Location URIs are discussed, particularly with regard to addressing mobility. Security concerns that are introduced by Location URIs are Winterbottom, et al. Expires July 24, 2006 [Page 1] Internet-Draft Location URI January 2006 also considered. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Location By-Value . . . . . . . . . . . . . . . . . . . . 3 1.2. Location By-Reference . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 3. Session Decoupling . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Subscriptions and Presence . . . . . . . . . . . . . . . . 6 3.2. Location Format . . . . . . . . . . . . . . . . . . . . . 6 4. Performance and Optimization . . . . . . . . . . . . . . . . . 7 4.1. Reducing Device Responsibilities . . . . . . . . . . . . . 7 4.2. Open Medium Scenarios . . . . . . . . . . . . . . . . . . 8 5. Device Mobility . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. The Cost of Determining Location Information . . . . . . . 9 5.2. Impact of Mobility on By-Value Location . . . . . . . . . 9 5.3. Addressing Mobility . . . . . . . . . . . . . . . . . . . 10 5.4. Expiry of Location Information . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6.1. Authorizing the Source of Location Information . . . . . . 11 6.2. Assigning a Location URI . . . . . . . . . . . . . . . . . 12 6.3. Location URI Theft . . . . . . . . . . . . . . . . . . . . 12 6.3.1. Protecting the Location URI . . . . . . . . . . . . . 12 6.3.2. Strong Identity Association . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Winterbottom, et al. Expires July 24, 2006 [Page 2] Internet-Draft Location URI January 2006 1. Introduction The basic GEOPRIV architecture [RFC3693] concentrates on how Location Information (LI) is conveyed from creation at a Location Generator (LG) to consumption at a Location Recipient (LR). Particular emphasis is placed on ensuring that appropriate privacy constraints exist to protect the Target. Two primary usage models have evolved from this basic architecture, which we shall call _by-value_ and _by-reference_. This document concentrates on the by-reference method for conveyance of LI. The strengths and particular vulnerabilities, from implementation, network architecture, security and privacy perspectives are discussed. This document is intended to provide a guide to making a choice between the two approaches, as well as providing some additional information on providing LI by-reference. 1.1. Location By-Value The by-value usage model is based on the concept that the Target, as the subject of the LI, should also be the owner and controller of the data. The Target receives LI from the LG and is then responsible for providing a Location Object (LO) [RFC4119] to LRs. This model places the control over which LRs gain access to LI directly with the Target. +-----------+ +--------+ +-----------+ | Location | | | | Location | | Generator |---LI/LO-->| Target |----LO--->| Recipient | | | | | | | +-----------+ +--------+ +-----------+ Figure 1: Basic By-Value Model Implicit in this diagram are a number of other entities from the GEOPRIV architecture. The Target also assumes the roles of Rule Maker (RM), Rule Holder (RH) and Location Server (LS). The Device is considered to be acting for the Target. Two minor variations have evolved from this model, either of the LG or Target can construct the LO. 1.2. Location By-Reference When a Location URI is used, a Location Server (LS) is employed to manage interactions with LRs. The Target either explicitly delegates Winterbottom, et al. Expires July 24, 2006 [Page 3] Internet-Draft Location URI January 2006 this task, or the LG arranges for this. The Target then makes a Location URI available to the LR, which de-references that URI to acquire the Target's LO. +-----------+ +-----------+ | Location | | Location | | Generator |---LI/LO--->| Server | | | (a) ,->| | +-----------+ / +------+ | / | LI/LO (b) LI/LO LO | (b) | V / V +-----------+ / +-----------+ | |--' | Location | | Target |----URI---->| Recipient | | | | | +-----------+ +-----------+ Figure 2: Basic By-Reference Model Two variations are shown in the diagram: (a) shows the LG publishing LI to the LS directly; (b) shows that the LI is first provided to the Target, which then publishes LI to the LS. Note: To simplify this diagram, variations related to privacy and the means by which authorization rules are made available to the LS are not shown. Winterbottom, et al. Expires July 24, 2006 [Page 4] Internet-Draft Location URI January 2006 2. Conventions and Terminology This document uses the terminology and acronyms defined in RFC 3693 [RFC3693]. The term _Location URI_ is defined as a reference to a Location Object (LO). A Location URI contains the address of a Location Server (LS) and provides sufficient additional information for the LS to be able to retrieve a LO. Location URI is preferred over the term _location-key_, which is sometimes used in this context. Winterbottom, et al. Expires July 24, 2006 [Page 5] Internet-Draft Location URI January 2006 3. Session Decoupling A Location URI decouples interactions between LR and LS from any application-specific interactions between Target and LR. This introduces the possibility of a different protocol, and enables more sophisticated interactions between LR and LS. 3.1. Subscriptions and Presence The LR is able to subscribe to the LS for notifications of changes in a particular Target's location. The LR is also able to provide its own time and resolution constraints to limit these notifications, see [I-D.mahy-geopriv-loc-filters]. This subscribe/notify mode of operation closely matches the general presence model [RFC3859]. Note: In order to support a subscription service for location the LG must be able to detect changes in location and then communicate these changes to the LS. 3.2. Location Format When LI is provided to an LR by-value, the LR is somewhat dependent on the Target to provide LI in a form that can be used. For instance, the LR could be unable to make use of a civic address [I-D.ietf-geopriv-revised-civic-lo]. Therefore, application protocols that support by-value provision of LI need to support negotiation for the correct form of LI. A Location URI enables the retrieval of LI directly from the LS; the LR can request the necessary form of LI directly. This reduces the level of support required for LI in application protocols. Winterbottom, et al. Expires July 24, 2006 [Page 6] Internet-Draft Location URI January 2006 4. Performance and Optimization Using a Location URI also introduces a retrieval step that could add additional delay to a time-critical application. By-value location can be used in these situations to remove this step; if a Target is able to acquire LI beforehand, this information can be provided by- value, thus avoiding adding delays. However, care must be taken to ensure the validity of LI, particularly when the Target is mobile, see Section 5. Note also that if a time-critical operation is started when LI is not available, by-value location provision is delayed until location generation has completed. Using Location URIs places the control over when location is generated with the LR. Again, in a time-critical application this also means that the LR may be forced to wait for location generation to occur. Several methods can reduce the impact of the location generation delay when using Location URIs: o Because the LR interacts with the LS directly, it has some degree of control over the costs involved. The LR can communicate urgency to the LS and request that the LI is generated quickly; a parameter indicating priority, or maximum time to respond could be used. o The LS is able to perform caching of LI. Subsequent requests for LI can use cached values without incurring the costs associated with generating location. o The generation or assignment of a Location URI has a minimal cost, therefore a Location URI can be provided to an LR without adding additional delays at the start of time-critical operations. The Target could also initiate a location generation process at this time; this way some of the delay can occur in parallel to the main operation, and potentially LI can be pre-cached at the LS in preparation for a request from the LR. 4.1. Reducing Device Responsibilities Using a Location URI allows a Device to delegate much of the effort involved with providing LI. In particular, authentication of LRs can require processing of encrypted data and interaction with network servers, for example Online Certification Status Protocol (OCSP) [RFC2560]. For lightweight devices with limited processing capabilities, battery dependencies or limited network access, this Winterbottom, et al. Expires July 24, 2006 [Page 7] Internet-Draft Location URI January 2006 can be advantageous. Delegating this responsibility can also reduce the complexity of an end device. Deciding when LI is required for an application is sometimes difficult. For instance, it is difficult to determine if certain telephony services require LI based on dialed digits. Because a Location URI does not necessarily leak any private information, a Location URI can be provided in all cases without having to make any decision. This leaves the receiver the choice of whether LI is required. A privacy profile at the LS guarantees that only authorized LRs gain access to LI. If this approach is taken, the security implications of this approach need to be considered, see Section 6.3. 4.2. Open Medium Scenarios Providing LI by-value over a medium that is accessible to multiple parties presents a particular challenge to the Target. In order to ensure that only authorized entities have access to LI, the LO must be individually encrypted for those entities. This also implies that those entities are known ahead of time. For example, this might apply for an application where intermediaries are part of a transaction with another end point. Using a Location URI on such an open medium allows this authorization decision to occur at the LS based on a policy. A Location URI can be provided to all parties with only those who are permitted actually gaining access to LI, including the other end point if desired. Section 6.3.1 covers the implications of this approach with regards to theft. Winterbottom, et al. Expires July 24, 2006 [Page 8] Internet-Draft Location URI January 2006 5. Device Mobility Device mobility, specifically the degree to which devices are able or expected to move, has an effect on the applicability of by-value and by-reference location. Some networks have definite mobility characteristics; for instance, a cellular network is expected to have highly mobile devices, whereas devices in a residential wired access network rarely move. How frequently devices move is the primary way that mobility affects the validity of LI. LI for a mobile device can become inaccurate in a very short period of time. 5.1. The Cost of Determining Location Information One further impact of mobility is the cost of determining location, in both processing power consumed and time. As mobility increases, the means of determining a precise location become more complex and time-consuming. To take a generic wireless network as an example, a coarse location estimate based on the location of a transmitter can be provided relatively quickly, however this estimate may not be sufficiently precise to be of use to the LR. More accurate wireless location determination methods incur a greater cost, in processing capacity, time or both. For instance, generating a location based on signal propagation delays is relatively processing intensive; similarly, a significant amount of time can be required to acquire Global Positioning System (GPS) signals, which then also require processing to derive location. Therefore, it can be seen that the usefulness of inexpensive location estimates is reduced where network mobility is allowed; conversely, the cost of acquiring a sufficiently precise estimate increases. 5.2. Impact of Mobility on By-Value Location In order for LI to be current at the time of use in a network that allows for mobility, the LG must ensure that it provides new LI to the Target every time it moves. Since location is practically continuous (Planck length notwithstanding) a moving device can generate any number of such notifications, limited only by the ability of the LG to recognise changes in location and any artificially imposed constraints. In practice, both time and resolution constraints are used to limit the rate of polling that occurs. Even with these constraints, there is still a potential for a substantial proportion of the location Winterbottom, et al. Expires July 24, 2006 [Page 9] Internet-Draft Location URI January 2006 determination effort to be wasted. 5.3. Addressing Mobility In more mobile access networks, a Location URI can reduce this expenditure of effort. A Location URI grants the LR some control over how and when LI is determined. Using a Location URI ensures that the information that the LR receives is current, and therefore more accurate; it also reduces the cost of polling. 5.4. Expiry of Location Information The inclusion of parameters such as expiry time enables better management of the validity of LI. For fixed services, expiry times can be moderately lengthy with little risk of LI actually being inaccurate. Fixed services based on a wired connection can also detect movement based on detecting the physical disconnection and connection of a wire or cable. Expiry of LI becomes more important when the Target is mobile. Appropriate values for expiry times can limit the chances of LI being inaccurate due to movement. However, if location is provided by- value, the Target must provide LI more frequently as expiry times are shorter. Using a Location URI can reduce the impact of this on the Target. Winterbottom, et al. Expires July 24, 2006 [Page 10] Internet-Draft Location URI January 2006 6. Security Considerations RFC 3693 [RFC3693] primarily concentrates on protecting the privacy of the Target. However, much of the security implications of using a Location URI arise from location fraud. The LR, as a consumer of LI, requires protection against being provided fraudulent LI, which can occur in a number of ways. 6.1. Authorizing the Source of Location Information To protect against fraudulent LI, the LR must be able to authenticate the identity of the source of LI, then ensure that the LI has not been modified in transit. In this instance, three potential _sources_ of LI are considered: the Target, the LG and the LS. Protection against modification can be assured either by guaranteeing a secure connection directly between the source and recipient using a protocol such as TLS [RFC2246], or by the application of a digital signature. If a secure channel is used, authentication needs to applied within that channel. A digital signature should include authentication information for the signer. Once an authenticated source of LI has been identified, the LR must also determine if it trusts that entity to provide accurate LI. o If the Target is the source of LI, as may be the case when location is provided by-value, the LR must authorize the Target. Where the LR has a strong need to trust the veracity of the LI, the effort involved in establishing this level of authorization for each possible Target could be prohibitive. Situations where this might not be appropriate are where there are very large numbers of potential Targets and/or where resources are expended based on the value of the LI. o For the LS, it is expected that there are fewer Location Servers with which an LR needs to establish an adequate trust relationship. Thus, by-reference LI can be used to avoid the Target authorization problem. However, the LR must also trust that the LS is not likely to accept fraudulent LI; if the LS relies on an LG to generate LI, then the LR must also trust the LG. o The LG can also be considered as a part of either LS or Target, in which case, the guidelines for either of those roles apply. Winterbottom, et al. Expires July 24, 2006 [Page 11] Internet-Draft Location URI January 2006 6.2. Assigning a Location URI A Location URI is an identifier generated by an LS so that an LR can retrieve LI. The Location URI must not include any information that could be used to identify the Target or any other entity that might be associated with the Target, such as the Device. The Location URI can therefore be considered an _unlinked pseudonym_ as defined in [RFC3693]. This implies that internal correlation (using a hash- table or similar) is the only method that the LS can use to associate a Location URI with a particular Target. The LS must assign a Location URI and then must maintain a link between the assigned URI and the specific Target. If this association can be subverted, an attacker could request a URI using fake identification information so that subsequent requests to this URI resulted in the location of another Target being determined and returned to the LR. The LS must employ measures to prevent this from occuring. 6.3. Location URI Theft The lack of identification information means that a recipient of a Location URI cannot be sure to whom the Location URI belongs. To this end, two options are presented: protecting the Location URI from theft, and weak Location URI protection with strong identity association. 6.3.1. Protecting the Location URI This is the simpler approach, the Target ensures that the Location URI is only provided to trusted entities. The Target need only trust these entities to not retransmit the Location URI, they need not include all such entities in an authorization policy. For this reason, a Location URI should always be carried over a transport that protects against eavesdropping. 6.3.2. Strong Identity Association One advantage of a Location URI is that it can be used to provide LI to an LR, even when untrusted intermediaries are involved in a transaction. The Location URI can be given to these intermediaries, but they cannot access LI as long as they are not included in the Target's authorization policy. Note also that because the Location URI does not include identification information, the Target could also remain anonymous, depending on the application protocol used. The disadvantage of using a Location URI in this manner is that it is Winterbottom, et al. Expires July 24, 2006 [Page 12] Internet-Draft Location URI January 2006 exposed to theft, whereby the intermediaries (or other parties) can take the Location URI and use it as if it were their own. The LR, upon receiving the LI cannot know to whom the Location URI belongs. To protect against this, the Target can provide the LS with a presentity identifier that is also known to the LR. When the LR retrieves the LO from the LS, the LO includes this presentity identifier. In this way the LR can link the LI with the identity of the Target. This approach requires that the LS authenticate the Target when assigning a Location URI. 7. References [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004. [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [I-D.ietf-geopriv-revised-civic-lo] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-01 (work in progress), January 2006. [I-D.mahy-geopriv-loc-filters] Mahy, R., "A Document Format for Filtering and Reporting Location Notications in PIDF-LO", draft-mahy-geopriv-loc-filters-00 (work in progress), October 2005. Winterbottom, et al. Expires July 24, 2006 [Page 13] Internet-Draft Location URI January 2006 Authors' Addresses James Winterbottom Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU Phone: +61 2 4221 2938 Email: james.winterbottom@andrew.com URI: http://www.andrew.com/ Martin Thomson Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU Phone: +61 2 4221 2915 Email: martin.thomson@andrew.com URI: http://www.andrew.com/ Jon Peterson NeuStar, Inc. 1800 Sutter St, Suite 570 Concord, CA 94520 US Phone: +1 925/363-8720 Email: jon.peterson@neustar.biz URI: http://www.neustar.biz/ Winterbottom, et al. Expires July 24, 2006 [Page 14] Internet-Draft Location URI January 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Winterbottom, et al. Expires July 24, 2006 [Page 15]