GEORIV T. Hardie Internet-Draft Qualcomm, Inc. Intended status: Standards Track J. Peterson Expires: January 4, 2009 NeuStar, Inc. J. Morris Center for Democracy and Technology July 3, 2008 Implications of for SIP Location Conveyance draft-ietf-geopriv-sip-lo-retransmission-00.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 January 4, 2009. Hardie, et al. Expires January 4, 2009 [Page 1] Internet-Draft LO Retransmission July 2008 Abstract This document explores an ambiguity in the interpretation of the element of the Presence Information Data Format for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to these ambiguities. Documents standardizing the SIP location conveyance mechanisms will be standards-track documents processed according to the usual SIP process. This document is intended primarily to provide the SIP working group with a statement of the consensus of the GEOPRIV working group on this topic. It secondarily provides tutorial information on the problem space for the general reader. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Core Semantics . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Limiting Access . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Limiting access using public-key encryption . . . . . 7 3.3.2. Limiting access using Location-by-Reference . . . . . 8 3.3.3. Refraining from including location . . . . . . . . . . 9 3.4. Choosing among the available mechanisms . . . . . . . . . 10 3.5. Indicating permission to use location-based routing in SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. Behavior of Back-to-Back User Agents . . . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. Informative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Hardie, et al. Expires January 4, 2009 [Page 2] Internet-Draft LO Retransmission July 2008 1. Introduction The Presence Information Data Format for Location Objects (PIDF-LO [4] carries both location information (LI) and policy information set by the Rule Maker, as is stipulated in [3]. The policy carried along with LI allows the Rule Maker to restrict, among other things, the duration for which LI will be retained by recipients and the redistribution of LI by recipients. The Session Initiation Protocol [2] is one proposed Using Protocol for PIDF-LO. The conveyance of PIDF-LO within SIP is specified in [1]. The common motivation for providing LI in SIP is to allow location to be considered in routing the SIP message. One example use case would be emergency services, in which the location will be used by dispatchers to direct the response. Another use case might be providing location to be used by services associated with the SIP session; a location associated with a call to a taxi service, for example, might be used to route to a local franchisee of a national service and also to route the taxi to pick up the caller. Some ambiguities have arisen in the interpretation of Rule Maker policy when PIDF-LO is conveyed by SIP. The following sections explore the problem and provide a recommendation. Hardie, et al. Expires January 4, 2009 [Page 3] Internet-Draft LO Retransmission July 2008 2. Problem Statement The element of RFC4119 was designed for use in an environment like that of Section 4 of RFC3693, in which Location Information (LI) propagates from a Location Generator through a Location Server to a Location Recipient. In this architecture, it is the responsibility of the Location Server to act on the rules (policy) governing access control to LI, which are in turn set by the Rule Maker. The most important of these responsibilities is delivering LI to authorized Location Recipients and denying it to others. Internal to RFC4119-compliant location objects (LOs) are additional privacy rules which are intended to constrain Location Recipients. These include the element. This element is intended to prevent a compromise of privacy when an authorized recipient of LI shares that LI with third-party entities, principally those who are not authorized by the Rule Maker to receive LI. For example, a user might be willing to share their LI with a pizza shop, but they might not want that pizza shop to sell their LI to a targeted advertising company that will contact the user with coupons for a nearby hair salon. Bear in mind, however, that is not intended to provide any protocol-level mechanism to prevent unauthorized parties from learning location through means like eavesdropping. It is merely a way to express the preferences of the Rule Maker to the LR. If the LR were, for example, legally bound to follow the privacy preferences expressed by Rule Makers, then they might incur liability of they ignored the parameter. No further privacy protection is assumed to be provided by . There is a use case for LI that involves embedding it in a SIP request that will potentially traverse multiple SIP intermediaries before arriving at a UAS. In this use case, one or more intermediaries might inspect the LI in order to make a SIP routing decision; we will hereafter refer to this as location-based routing. Common examples could include emergency services and other more mundane cases where the originator of a SIP request wants to reach a service in proximity to a particular geographic location, such as contacting a nearby pizza shop. In both such cases the UAC may intend for selected intermediaries and the UAS to have access to the LI. In the pizza case, for instance, the UAC shares an address both for location-based routing and additionally so that the pizza shop reached by that routing has the address to which a pizza should be sent. This location-based routing use case for LI has a number of important Hardie, et al. Expires January 4, 2009 [Page 4] Internet-Draft LO Retransmission July 2008 disconnects from the RFC3693 model. Unlike the RFC3693 model, there is no LS designating to which specific entities LI will be sent. There may be multiple intermediaries between the UAC and UAS, some of which need or want to inspect LI (which would seem to qualify them as LRs) and some of them will not. While SIP proxy servers generally are not RFC4119-aware and do not need to inspect SIP request bodies in order to perform their function, nothing precludes proxy servers inspecting or logging any SIP message bodies, including LI. Furthermore, it is very difficult for the UAC to anticipate which intermediaries and which eventual UAS a SIP request might reach. This architecture is further complicated by the possibility of sending location information by-reference, that is, placing a URL where LI can be retrieved in SIP requests instead of using a PIDF-LO body (commonly called including the PIDF-LO by value) Depending on the qualities of a reference, further authorization checks may be performed before LI is retrieved, LI may be customized depending on who is asking, and so forth. As will be discussed in greater detail below, the conveyance of a reference may have very different privacy properties than conveying a PIDF-LO body by-value in a SIP request. In this architecture, the question of who is an "authorized recipient" from the point of view of the Rule Maker has been muddy. The SIP elements along the path are authorized to receive and forward the SIP message; does that make them automatically authorized recipients of the LI it contains? The final target of the SIP message will receive the LI along with other information, but it may be different than the initial target in a variety of scenarios; is it authorized to read the LI? These questions and concerns are particularly problematic when is set to "no" (the default case). This core concern might be put as "to whom does apply in location-based routing?" More specifically: Is any entity that reads LI bound by ? If so, does that mean a proxy that performs location-based routing is unable to forward a request and complete a SIP call if is "no"? Alternatively, must they strip the location body from the message in order to complete the call? If the proxy does not understand RFC4119, it may forward a SIP message containing a policy statement set to "no". Is any proxy that does understand RFC4119 required to parse the LI for this statement, even if it would not do so in order to route the message? Is there a need for SIP-level indications regarding retransmission Hardie, et al. Expires January 4, 2009 [Page 5] Internet-Draft LO Retransmission July 2008 for the benefit of entities that do not understand 4119? Since the UAC cannot anticipate who may receive a SIP request, how do we understand who the intended LR is in the location-based routing case? Can a UAC have intended for there to be multiple serial LRs in a transmission? If so, if one LR is authorized to retransmit to another LR, how will it know it is not also authorized to transmit LI to other third parties (i.e., how will the serial LRs know to whom they are authorized to retransmit)? How could all of this be designated? Hardie, et al. Expires January 4, 2009 [Page 6] Internet-Draft LO Retransmission July 2008 3. Recommendation 3.1. Goals After extensive discussion in both GEOPRIV and SIP contexts, there seems to be consensus that a solution for this problem must enable location-based routing to work even when the flag is set to "no". A solution should also give the Rule Maker the ability to allow or forbid the use of LI for location-based routing and the ability to allow or forbid the use of LI for the consumption of the endpoint. 3.2. Core Semantics Consensus has emerged that any SIP entity which receives a SIP message containing LI through the operation of SIP's normal routing procedures or as a result of location-based routing should be considered an authorized recipient of that LI. Because of this presumption, one SIP element may pass the LI to another even if the LO it contains has set to "no"; this sees the passing of the SIP message as part of the delivery to authorized recipients, rather than as retransmission. SIP entities are still enjoined from passing these messages outside the normal routing to external entities if is set to "no", as it is the passing to 3rd parties that is meant to control. This is considerably different from the presumptions of RFC3963, in that authorized recipients pass the LO on to other authorized recipients, but it seems to be the most sensible mechanism given SIP's operation. To maintain the Rule Maker's ability to affect the consumption of this information, two different mechanisms may be used to limit the distribution of LI and one may used to limit the sphere in which it may be used; these are discussed below. 3.3. Limiting Access 3.3.1. Limiting access using public-key encryption One way of limiting access to LI is to encrypt the PIDF-LO object in a SIP request. If the originator knows which specific entity on the path needs to inspect the LI, and knows a public key for that entity, this is a straightforward matter. It is even possible to encrypt multiple instance of PIDF-LO, containing different policies or levels of location granularity, in the same SIP request if multiple entities along the path need to inspect the location. Hardie, et al. Expires January 4, 2009 [Page 7] Internet-Draft LO Retransmission July 2008 This is most likely to be effective in cases where the originator does not wish the LI to be inspected by intermediate entities and has the public key for the target of the SIP message, as it is very difficult for the originator to anticipate the intermediaries through which a SIP message will pass. It may also be useful in limited environments where the originator has a trust relationship with a specific SIP element (e.g. a "home" or first-hop proxy) and it wants to reveal that LI only to that element. Note that even in the case where the originator intends to encrypt LI for the benefit only of the target of the message it may be quite difficult to anticipate the eventual endpoint of the message. These encrypted LIs will not be useful in any case where the anticipation of the originators is not met. An additional problem posed by this approach is that it requires some sort of public key discovery system, which compounds the operational complexity significantly. While this method is included for completeness, it is the consensus of the working group that the deployment scenarios in which this is appropriate will be relatively few; we do not believe it is an appropriate baseline approach. 3.3.2. Limiting access using Location-by-Reference Another, more feasible approach is leveraging location by reference. When a SIP request conveys a reference, it cannot be properly said to be conveying location; location is conveyed upon dereferencing the URI in the question, and the meaning of must be understood in the context of that conveyance, not the forwarding of the SIP request. The properties of references, especially the security properties, vary significantly depending on the nature and disposition of the resource indicated. Clearly, if the referenced PIDF-LO is available, in the same form, to any entity along the SIP signaling path that requests it, then inserting a reference has no advantages over inserting LI by value (and introduces wasteful complexity). However, if the Rule Maker influences the results of the dereferencing process, including determining who can receive LI at what degree of granularity and what policies are bound with the LI, the security properties are different. It might superficially appear that this suffers from the same problems as the encryption approach, since the Rule Maker must anticipate a set of entities who are authorized to receive location information. The difference is that this set does not need to be communicated in the SIP request in order for authorization decisions to be made. There is a world of difference between managing a Hardie, et al. Expires January 4, 2009 [Page 8] Internet-Draft LO Retransmission July 2008 whitelist of a thousand parties that might ask for LI and sending a SIP request containing a thousand differently-encrypted adumbrations on LI - the former is commonplace and the latter is impossible. Additionally, some Rule Maker policies might not even require the establishment of an exhaustive whitelist. For example, it may be that there exists a finite set of commercial requestors that the Rule Maker would like to block, in a manner similar to the way ad-blockers operate in modern web browsers. In any system where one makes an authorization decision, a certain cost in authentication must be paid - the greater the assurance the greater the cost. The precise cost will of course depend on the URI scheme of the reference. For SIP, Digest has a low computational cost but requires pre-established keys, which limits applicability. RFC4474 Identity does not require any pre-association, but it does make signaling more heavyweight and requires the deployment of additional features in the network, including a web-like PKI. But even if no authentication takes place, in the LbyR case the meaning of is unambiguous - each entity to which LI is conveyed in the dereference process is bound by the retransmission policy. The cost of the reference itself is of course the server that maintains the resource. While not every SIP client has access to an appropriate server for this purpose, the fact that PIDF-LO builds on the typical SIP presence service makes this less implausible than it might be. Moreover, the LbyR approach casts the conveyance architecture in a manner familiar from RFC3693, with a Location Server receiving requests from Location Recipients which may be accepted or denied. This allows the preservation of the original semantics of . 3.3.3. Refraining from including location The most fundamental mechanism for limiting access to location information is simply not including it. While location-based-routing might conceivably occur in almost any SIP message in the future, there is no requirement that location be included in the general case to support it. If it is not included and is required, an appropriate error indicating the lack may be returned and the choice made to continue communication with the information included. This challenge and response will slow the establishment of communication when it is required, but it is the most basic way to ensure that location distribution is limited to the times when it is required for communication to proceed. Hardie, et al. Expires January 4, 2009 [Page 9] Internet-Draft LO Retransmission July 2008 3.4. Choosing among the available mechanisms Refraining from including location is the most appropriate choice for systems that do not wish to reveal location to any party in the SIP path. Location-by-Reference is generally recommended as the most deployable mechanism for limiting access to LI which is passed via a SIP message. It is significantly easier to deploy than public key discovery systems, allows for both whitelists and blacklists, and can scale in ways that the inclusion of multiple encrypted bodies cannot. Encryption may be used in a limited set of circumstance where location-by-value must be used. 3.5. Indicating permission to use location-based routing in SIP The discussion in 3.3 describes 3 mechanisms for limiting the distribution of LI to specific entities. There remains the problem of limiting the use to which LI included by value or by reference may be put. In order to meet the need to limit that use, this document recommends the creation of a "Location-Routing-Allowed" header for SIP. When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is indicating permission to use the included LI for location-based routing. When "Location-Routing-Allowed" is set to "No", the originator is indicating that this use is not permitted. "Location- Routing-Allowed" being set to "No" has no protocol-level mechanism for enforcement of this behavior; like the PIDF-LO "retransmission- allowed" being set to "no", it is a way for the Rule Maker to express a preference to the SIP elements which are LI recipients. It may, however, present a significant optimization. Where a location-by- reference is included with "Location-Routing-Allowed" set to "No", the SIP elements along the path know that they do not need to attempt to dereference the location information; this is significantly faster than attempting the dereference and being denied at the authentication stage. We recommend that "Location-Routing-Allowed" be made mandatory-to- implement for elements complying with [1]. We recommend that it appear in any SIP message that contains a location, whether by reference or by value. We recommend that any SIP message containing a location but no "Location-Routing-Allowed" header should be treated as containing a "Location-Routing-Allowed" header set to "No". Hardie, et al. Expires January 4, 2009 [Page 10] Internet-Draft LO Retransmission July 2008 We recommend that a UA be allowed to insert a "Location-Routing- Allowed" header even when it has not included a location, in order to set the policy for any locations inserted by other SIP elements. This allows the UA to assert that it is a Rule Maker for locations, even when the network architecture in which the UA is present inserts the location into SIP messages after the UA has originated the SIP exchange. We recommend that any SIP element inserting a location, whether by reference or by value, insert a "Location-Routing-Allowed header if one is not already present. If one is present, it should not be over-ridden by the SIP element inserting the location. We recommend that any SIP element not the originator of a message and not inserting a location be enjoined from inserting a "Location- Routing-Allowed" header. 3.6. Behavior of Back-to-Back User Agents Back-to-Back user agents are always a bit tricky, since they function in multiple realms. One standard way of approaching their behavior is to see them as terminating one flow of information and originating a new one. From that perspective, the correct behavior of a B2BUA receiving LI on one "back" is to treat that as terminating the information flow. It can originate a new information flow containing that LI by value in the other direction only if the PIDF-LO it contains permits it by using set to yes. If the PIDF-LO it contains is encrypted, it can pass it onward with the understanding that a recipient capable of decrypting it is authorized. Note that this case is also easier to handle using the location-by- reference model. Since the passing of location-by-reference does not properly include the location itself, it can pass a location-by- reference pointer in the new direction with the understanding that the dereferencing protocol handles the determination of whether those dereferencing the location are authorized recipients or not. If both sides of a B2BUA's are SIP, we recommend that it copy any "Location-Routing-Allowed" header value found in the input flow when it re-originates the flow. Hardie, et al. Expires January 4, 2009 [Page 11] Internet-Draft LO Retransmission July 2008 4. IANA Considerations This document contains no considerations for the IANA. Hardie, et al. Expires January 4, 2009 [Page 12] Internet-Draft LO Retransmission July 2008 5. Security Considerations The privacy and security implications of distributing location information are the fundamental subject of this document. Hardie, et al. Expires January 4, 2009 [Page 13] Internet-Draft LO Retransmission July 2008 6. Acknowledgements James Polk provided a series of questions regarding the specifics of the Location-Routing-Allowed mechanism, and this resulted in the recommendations in Section 3.4 Hardie, et al. Expires January 4, 2009 [Page 14] Internet-Draft LO Retransmission July 2008 7. Informative References [1] Polk, J. and B. Rosen, "Location Conveyance for the Session Initiation Protocol", draft-ietf-sip-location-conveyance-10 (work in progress), February 2008. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [4] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. Hardie, et al. Expires January 4, 2009 [Page 15] Internet-Draft LO Retransmission July 2008 Authors' Addresses Ted Hardie Qualcomm, Inc. Email: hardie@qualcomm.com Jon Peterson NeuStar, Inc. 1800 Sutter St., Suite 570 Concord, CA 94520 US Phone: +1 925 363-8720 Email: jon.peterson@neustar.biz John B. Morris, Jr. Center for Democracy and Technology 1634 I Street NW Suite 1100 Washington, DC 20006 US Email: jmorris@cdt.org Hardie, et al. Expires January 4, 2009 [Page 16] Internet-Draft LO Retransmission July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Hardie, et al. Expires January 4, 2009 [Page 17]