Network Working Group J. Peterson Internet-Draft NeuStar Intended status: Informational T. Hardie Expires: August 18, 2008 Qualcomm J. Morris CDT February 15, 2008 Implications of for SIP Location Conveyance draft-peterson-geopriv-retransmission-00 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 August 18, 2008. Copyright Notice Copyright (C) The IETF Trust (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 Peterson, et al. Expires August 18, 2008 [Page 1] Internet-Draft Retransmission February 2008 adapt to these ambiguities. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Indicating Permission . . . . . . . . . . . . . . . . . . 5 3.2. Withholding Location . . . . . . . . . . . . . . . . . . . 7 4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Informational References . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Peterson, et al. Expires August 18, 2008 [Page 2] Internet-Draft Retransmission February 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 RFC3693 [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 (RFC3261 [1]) is one proposed Using Protocol (see RFC3693) for PIDF-LO. The conveyance of PIDF-LO within SIP is specified in [5]. The common motivation for providing LI in SIP is to allow location-based personal communications services. One example would be emergency services; another would be fast food delivery. 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 possible solutions before providing a recommendation. 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 Peterson, et al. Expires August 18, 2008 [Page 3] Internet-Draft Retransmission February 2008 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 may inspect the LI in order to make a SIP routing decision; we will hereafter refer to this as location-based routing. Common examples would 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 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 however 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 a by-value PIDF-LO body - 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. The conveyance of a reference may have very different privacy properties than conveying a PIDF-LO body by-value in a SIP request. In these location-based routing cases, a number of questions and concerns arise when is set to "no". The core concern is "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 Peterson, et al. Expires August 18, 2008 [Page 4] Internet-Draft Retransmission February 2008 is not to "no" unless they strip location out of the message? This interpretation is fairly problematic, and a solution is required to allow location-based routing to take place. By forwarding a request at all, is a SIP proxy violating RFC4119? Of course, not all proxies understand RFC4119, but is any entity that potentially could read LI under an obligation to read it if only to learn that it is not authorized to retransmit it? Is there a need for SIP-level indications regarding retransmission for the benefit of entities that do not understand 4119? If 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 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? 3. Solution Space At a high level, a solution for this problem would enable location- based routing to work even when the flag is set to "no". Ideally, it would give the Rule Maker responsible for LO policy the ability to allow or forbid the use of LI for location- based routing, and similarly allow or forbid the use of LI for the consumption of the endpoint. It is important to note that whatever the solution turns out to be, solving this problem does not obviate the need to explain the meaning of "no" in the absence of the solution. This work cannot be complete without an account of how is to be understood. 3.1. Indicating Permission A SIP message conveying location information could contain some sort of indication that allows location-based routing, or more specifically specifies what entity or entities are intended to consume the LI. This admits of varying degrees of specificity: a binary indicator might say only whether or not routing is allowed, a more complex indicator might allow and/or disallow both routing and consumption by endpoints, or a very specific indicator might designate (by hostname, for example) a list of exactly which entities on the SIP signaling path are intended to inspect PIDF-LO. In order for indicators with a great deal of specificity to serve Peterson, et al. Expires August 18, 2008 [Page 5] Internet-Draft Retransmission February 2008 their purpose, the sender of SIP requests must be able to anticipate the path and ultimate destination of messages. In most operational environments this is a more complicated matter than one might think. The manner in which proxy servers make forwarding decisions is unpredictable to the originating UAC, as are any registrations that might be associated with the destination AoR, which might point to unexpected endpoints or new AoRs. Thus, solutions along the lines of specifying an exact list of hosts that a request will visit have very limited applicability. It may even be difficult for the originator of a SIP request to anticipate whether an intermediary or endpoint will need to inspect LI to process a request. In sending a request to sip:orders@pizzahut.example.com, for instance, the UAC cannot anticipate whether pizzahut.example.com uses location-based routing to direct requests to particular retail outlets, or whether the location information is consumed by a centralized monolithic endpoint that dispatches orders in some manner outside the scope of SIP and PIDF-LO. That much said, a binary indicator used to authorize location-based routing (something like "routing=yes") would at least serve to allow location-based routing to occur when is set to "no". Placing the indicator in the Location header has the advantage that a recipient need not inspect the PIDF-LO body in order to learn whether or not they are supposed to inspect it. Parsing an XML body also entails a computational expense that may be burdensome for an intermediary processing large numbers of messages, especially in cases where the parsing yields nothing more than a stop sign. Placing the indicator within the PIDF-LO object has the advantage of binding the indicator to the other policy elements in PIDF-LO. Were the indicator to appear in a SIP header, it would be unclear who set the indicator and what the relationship of that entity might be to the Rule Maker. Furthermore, were the PIDF-LO object in the course of its routing ever to leave the scope of SIP conveyance (say, hitting a gateway to another protocol like Jabber), the indicator would be retained without the need for any special intelligence on the part of the gateway. Regardless of where the indicator is staged, it can do nothing but indicate - it will not prevent any entity from inspecting LI out of malice or incompetence. Of course, the same is true of the element itself. The indicator can serve no other purpose than to express the policy of the originator (hopefully the Rule Maker), and in turn to provide grounds for liability when these policies are violated. Peterson, et al. Expires August 18, 2008 [Page 6] Internet-Draft Retransmission February 2008 3.2. Withholding Location The originator of a SIP request can also withhold LI from particular elements in the signaling stream and reveal it to others. In this manner, the Rule Maker can guarantee that the LI will only be reveal to appropriate recipients, and all such recipients will be understood to be constrained by the of PIDF-LO. Since the Rule Maker specifically authorized each entity capable of inspecting the LI, forwarding the SIP request in this case does not constitute "retransmission". One manner of accomplishing this 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. However, for the much the same reason as the very specific (list of hosts) indicator above is problematic, this is also more or less useless in most practical deployments. Not only is anticipating the intermediaries or endpoints that a request will visit prohibitively difficult, but this approach also requires some sort of public key discovery system which compounds the operational complexity significantly. In some very specific environments this might have some applicability, but they would be rare. 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. A recent study [Henning's types-of-LbyR] has pointed out that 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, 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 Peterson, et al. Expires August 18, 2008 [Page 7] Internet-Draft Retransmission February 2008 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 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 . 4. Analysis Regardless of how permission for location-based routing is granted, the meaning of with a value of "no" in a PIDF-LO body conveyed in a SIP request must be unambiguous for all endpoints and intermediaries that process the message. Since even location-aware intermediaries might perform a baseline SIP forwarding function without inspecting LI, and location-unaware intermediaries can do nothing but, it is clear that SIP messages with a flag of equal to "no" can and will be forwarded by SIP intermediaries. Leaving aside for the moment the question of LI in particular, and Peterson, et al. Expires August 18, 2008 [Page 8] Internet-Draft Retransmission February 2008 instead considering the matter purely from a SIP perspective, when a UAC sends a SIP request with a body, SIP permits any intermediaries and the eventual endpoint recipient to inspect the body, and places little constraints on how intermediaries arrive at a forwarding decision. In other words, when a UAC sends a request, it is implicitly allowing set of entities to receive that message body, a set whose contents the UAC cannot anticipate in typical SIP environments. Consequently, for the purposes of SIP as a conveyance protocol, it would not be unreasonable to proceed as if each location-aware entity in the routeset of a SIP request is an RFC3693 Location Recipient, and as such each is bound by as if the LG had shared this information with them bilaterally, regardless of what actions they take as they process SIP requests. This approach has the desirable property that it does not alter the RFC4119 semantics of . It does however require some additional work to make this understanding of SIP location conveyance meet the privacy goals of RFC3693. Consider, for example, that an unanticipated SIP intermediary which is not location-aware might log SIP requests, body and all, enabling parties interested in tracking location information to data mine its logs later. In any system of intermediaries whose behavior cannot be predicted, these sorts of scenarios are a potential downside. The simplest way to mitigate this risk is by withholding LI. For the many reasons described in the previous section, encryption is not a feasible approach to this. However, a privacy-conscious UAC can send LI by-reference in SIP requests. The service that manages requests for LI (an RFC3693 LS) can then use whatever access controls it sees fit to ensure that LI is only shared with appropriate parties. A SIP intermediary which logged all requests would in this instance merely log a URI rather than a copy of the LI. These risks are not always a primacy concern for UACs, however, and when a UAC cannot or does not wish to publish its location to an LS, it can avail itself of the 'routing-permitted' indicator to express the intended usage of location information. If 'routing-permitted' is set to "yes", a location-aware intermediary knows that the LI so designated is likely to be useful for routing, and that it is worth the trouble to run any routing algorithm. If it is set to "no", then a location-aware intermediary knows not to invoke any routing algorithm - the LI might not be even be useful for making a routing decision in this case. Where location by-reference is preferred, a location-aware intermediary does not want to incur the costs of looking up the reference URI needlessly. If LI is not intended for use by Peterson, et al. Expires August 18, 2008 [Page 9] Internet-Draft Retransmission February 2008 intermediaries, and dereferencing a URI conveyed within SIP would only lead to the denial of the request, the UAC could set the 'routing-permitted' indicator in the SIP request to "no". This would let any location-aware intermediary know that it needn't even bother to try to dereference the URI. This use of the indicator argues strongly for making it a SIP-layer indicator (a part of the Location header) rather than a new element of PIDF-LO. Although in this case it is not possible to provide a common integrity protection over the 'routing-permitted' indicator and the remainder of policies set by the Rule Maker, the value of tampering with 'routing-permitted' seems low; it will not result in privacy leaks, in any event, since privacy can be managed with greater granularity by withholding LI. In summary, both the strategies of indicating permission and withholding LI are viable, and in fact compatible. 5. Recommendation This document recommends that the "recipient" parameter in the SIP location conveyance proposal ([5]) by replaced by a parameter called "routing-permitted". This parameter accepts only a binary value of "yes" or "no". The default value shall be "no". The current text in the SIP location conveyance proposal on privacy, in the first paragraph of Section 5, considers encryption as a means of providing access control for PIDF-LO. For the reasons mentioned in Section 3, encryption is not an optimal means of withholding location information. The relevant text in Section 4.2, 5 and 7 of the SIP location conveyance proposals should instead reference or include the discussion in this document. 6. IANA Considerations This document contains no considerations for the IANA. 7. Security Considerations The privacy and security implications of distributing location information are the fundamental subject of this document. 8. Informational References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, et al. Expires August 18, 2008 [Page 10] Internet-Draft Retransmission February 2008 Session Initiation Protocol", RFC 3261, June 2002. [2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [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. [5] Polk, J. and B. Rosen, "Location Conveyance for the Session Initiation Protocol", draft-ietf-sip-location-conveyance-09 (work in progress), November 2007. Authors' Addresses Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA Phone: +1 925/363-8720 Email: jon.peterson@neustar.biz URI: http://www.neustar.biz/ Ted Hardie Qualcomm, Inc. Email: hardie@qualcomm.com John B. Morris, Jr. Center for Democracy and Technology 1634 I Street NW Suite 1100 Washington, DC 20006 USA Email: jmorris@cdt.org URI: http://www.cdt.org Peterson, et al. Expires August 18, 2008 [Page 11] Internet-Draft Retransmission February 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Peterson, et al. Expires August 18, 2008 [Page 12]