Internet Engineering Task Force SIPPING WG Internet Draft D. Trossen Nokia Research H. Schulzrinne Columbia University draft-trossen-sipping-ondemand-00.txt 20. October 2003 Expires: April 2004 On-Demand Access Authorization for SIP Event Subscriptions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (c) The Internet Society (2003). All rights reserved. Abstract This document will describe the problem and possible solution space for a so-called æon-demand access authorization for SIP event subscriptionsÆ. The objective of this document is to properly describe the particular problem, define requirements for solutions to this problem, and outline possible solutions. With this, the document intends to drive the standardization of one method forward in order to provide a common solution to the presented problem. Trossen, Schulzrinne Expires April 2004 [1] Internet Draft On-Demand Authorization for SUBSCRIBE October 2003 Table of Contents 1. Introduction....................................................3 2. Terminology.....................................................3 3. Problem Space...................................................4 3.1. Use Cases.....................................................4 3.1.1. Location Scenarios..........................................4 3.1.2. Content Delivery Scenarios..................................5 3.1.3. Service Discovery in Visitor Environment....................5 3.1.4. Match Making Service........................................5 3.1.5. Context-aware Gaming........................................6 4. The Role of (XCAP) Authorization Policies.......................6 5. Requirements....................................................7 6. Solution Space..................................................8 6.1. Authorization Policy Server Transactions......................8 6.2. Temporary Account.............................................9 6.2.1 Temporary Account with Time Window...........................9 6.3. Ticket.......................................................10 6.4. Message Authentication.......................................11 7. Security Considerations........................................12 8. Acknowledgements...............................................12 9. References.....................................................12 10. Authors' Addresses............................................13 Trossen, Schulzrinne Expires April 2004 [2] Internet Draft On-Demand Authorization for SUBSCRIBE October 2003 1. Introduction Access authorization for SIP event subscriptions is crucial due to the highly private nature of information revealed in the resulting notifications. Work is ongoing within the SIMPLE and GEOPRIV working groups to define authorization policies for certain use cases [5][7] as well as the protocol for defining, conveying, and managing such policies [4][6]. This work is based on the proper definition of access policies for a set of users related to a set of information. Upon reception of a SIP SUBSCRIBE, it is assumed that the SIP event server verifies the access policy for the particular subscriber with respect to the requested information, using the stored policy information. Hence, at the time of receiving the SIP SUBSCRIBE at the SIP event server, the existence of a proper policy for the particular access is assumed. In this document, we will outline a problem referred to as æon- demand accessÆ, i.e., a type of access for which a proper authorization policy does not exist at the time of access due to the ad-hoc character of the access. We will present use cases in which such æon-demand accessÆ will happen. We will then outline the solution space as to address this problem. The objective of this document is to properly describe particular problem, define requirements for solutions to this problem, and outline possible solutions. With this, the document intends to drive the standardization of one method forward in order to provide a common solution to the presented problem. 2. Terminology Resource: A resource in the scope of this document is an object to which a certain state information is associated, called æresource dataÆ in the remainder of the document. Examples are presence as a resource belonging to the presentity. The resource data is the current presence information (subject to the particular disclosure policy of the presentity). Resources can also be associated to devices, such as printers, in which the resource data represents, for instance, the current state of the printer. Resource data provider: An element that hosts a particular piece of resource data. Examples are SIP event servers, which host event data related to a particular user, e.g., presence event data. Querier: An element, such as an application or service, that requests access to a particular piece of resource data. Examples are watchers in SIP presence or subscribers for any SIP events. Resource owner: An entity that has authorization power over the particular resource data. Examples are presentities in SIP presence. Trossen, Schulzrinne Expires April 2004 [3] Internet Draft On-Demand Authorization for SUBSCRIBE October 2003 3. Problem Space With the defined terminology of Section 2, consider a resource data provider, a querier, and a resource owner. The querier desires (temporary) access to the particular resource (or particular parts of the resource) at the resource data provider, without having the resource owner to create or modify state information for such access at the resource data provider. In this, the desire for access is somehow conveyed from the querier towards the resource owner. The temporary access can be time-limited or limited in notifications (such as time window based, one-time or N- time notifications). The following additional constraints might occur: * The identity of the querier might not be known to the resource owner before the desire for access is conveyed towards the resource owner. * The type of access, i.e., the resource as such as well as the resource data, might not be known to the resource owner before the desire for access is conveyed towards the resource owner. * The conveyance of the desire to access the resource data and the actual access might lie within a rather short time window. The problem to be solved is to enable an authorized access to the desired resource by the querier at the resource data provider. In the case of SIP event subscriptions, the resource data provider is a SIP event server, the querier is the subscriber (or watcher in presence [3]), and the resource owner is the presentity in the presence case. The desired access constitutes a (properly authorized) SIP event subscription to the particular resource. In this, it is worth mentioning that such access is not restricted to currently discussed presence items only [9][10] rather than to any kind of (future) presence items or SIP events in general. It is beyond the scope of this document as to how the querier conveys the desire for access to the resource owner. A variety of methods, such as within an HTTP or SOAP transaction between querier and resource owner (see also the following use cases), are possible for such conveyance. 3.1. Use Cases The following section outlines use cases for the above described on- demand access authorization problem. 3.1.1. Location Scenarios Consider the provisioning of location-based services from a service provider (the querier) to a user (the resource owner). Trossen, Schulzrinne Expires April 2004 [4] Internet Draft On-Demand Authorization for SUBSCRIBE October 2003 As one example, the user desires to obtain location-based data from the service provider, such as map information for the current location of the user. For that, the service provider needs a one- time access in order to fetch the current location information of the user. As another example, the user subscribes to a location-based service at the provider. In order to perform the requested service, the service provider requires permission to obtain the userÆs current location information with a particular granularity for a certain time period, e.g., 10 minutes. 3.1.2. Content Delivery Scenarios Consider the delivery of content, such as news, that is dependent on certain presence items. In order to perform the adaptation, the content provider needs to access these presence items for the time of the content delivery (which can be rather temporary in cases where the content was found during surfing the Internet). Examples for such presence items are location, activity, or placetype [10](to distinguish business-related from more private news or select appropriate content if in public places). Although not defined (yet), one could also envision the usage of affective information, e.g., the userÆs current mood, to deliver appropriate content. 3.1.3. Service Discovery in Visitor Environment Consider the problem of service discovery in visitor environments, i.e., the requesting user and the service discovery system are not known to each other before engaging in transactions. In this, we assume that the discovery service allows for service selection based on user information such as current location (based on an indoor system), activity, currently used communication device and so on. For this, the discovery service requires an on-demand access to this information of the user, in which the actual access being implemented through SIP event subscriptions. 3.1.4. Match Making Service Consider a match making service, locally provided within a point of interest, such as an amusement park, a mall or a bar. Upon arriving at the point of interest, the user receives the service announcement and subscribes to the service (during this service subscription, the provisioning of the user profile might happen as well). In order to perform the desired match making, the service provider might require access to certain user information, such as location Trossen, Schulzrinne Expires April 2004 [5] Internet Draft On-Demand Authorization for SUBSCRIBE October 2003 within the point of interest (if the place is larger) or current activity. 3.1.5. Context-aware Gaming Multi-player gaming experience can be enriched by userÆs context information such as location of the players or even aggregated sensor information (e.g., information such as æstandingÆ, æwalkingÆ, ærunningÆ that was derived from sensor data), potentially provided through (enriched) presence or dedicated SIP events. Further, such games could be established between a-priori unknown parties (ad-hoc gaming in point-of-interest for instance) but could also require a-priori unknown set of information from either player. Hence, upon starting the game, each player requires access authorization for this particular set of information from each of the other players for the duration of the game (if the duration of the game is unknown, the authorization can be renewed before expiring). 4. The Role of (XCAP) Authorization Policies The SIMPLE working group is current developing XCAP [4] as a solution to define and convey authorization policies for presence events. This system assumes an XCAP policy server to be consulted prior to granting access to the requested resource in the SIP event subscription [11]. In this, note that such protocol for consulting, i.e., the communication between presence server and XCAP server, has not yet been defined. However, within the above defined problem space, such existence of an XCAP server for authorization cannot generally be assumed for two reasons. Firstly, XCAP currently only defines authorization policies for presence document items. It does not define access authorization for general SIP events (although the underlying XML schema is likely to support this), and currently there does not exist any work item within the IETF to do so for general SIP events. Secondly, the assumption of the existence of an authorization server [11] as such, to be consulted in the case of receiving a presence subscription, cannot easily be transferred to SIP events in general. In contrast to SIP presence, general SIP events could be hosted by a much wider variety of service providers, and even through end user systems themselves. The proper integration of such a diverse system of SIP event servers into an XCAP-based framework is unlikely to happen. Hence, for the remainder of this document, we have to keep in mind that the existence of such authorization server is not a given fact, rather than an option only, and a rather unlikely one for general SIP events. Trossen, Schulzrinne Expires April 2004 [6] Internet Draft On-Demand Authorization for SUBSCRIBE October 2003 5. Requirements From the outlined problem and the presented use cases, we derive the following requirements to be fulfilled by any solution: REQ 1: A solution MUST allow for specifying the particular pieces of resource data to which access is granted. REQ 2: A solution MUST allow for verifying the identity of the resource owner in the authorization. REQ 3: A solution MUST prevent replay attacks of access authorization information through the querier or third parties. REQ 4: A solution SHOULD allow for specifying a time window of access, either relatively (starting with the time of subscription) or absolutely. REQ 5: A solution SHOULD allow for tying the access to a particular querier, if so desired by the resource owner. REQ 6: A solution SHOULD allow for restricting the notifications the querier will receive within the access period. REQ 7: A solution SHOULD avoid racing conditions in the access to the resource data in the sense that the querier will not subscribe to the resource data before proper authorization is ensured. REQ 8: Any authorization information SHOULD be transmitted in a secure manner. REQ 9: [Something about additional complexity/involved transactions of a solution?] Requirements 1 and 2 ensure as a minimal functionality that the particular pieces to access are well defined in the authorization and that the identity of the resource owner can be verified as the identity that granted the access. Requirement 3 targets unwanted resource access through re-using the access authorization, either through the querier or third parties (handing the information after usage to someone else). Requirement 4 aims at supporting scenarios such as in Section 3.1.1, in which the querier has time-restricted access to the resource. Requirement 5 targets the transferability of the authorization. However, the fulfillment of this requirement is only useful in certain scenarios. For instance, if the resource data were certain presence items, tying the access to the querier (the watcher in this case) would still allow the querier to act as a strawman, i.e., the Trossen, Schulzrinne Expires April 2004 [7] Internet Draft On-Demand Authorization for SUBSCRIBE October 2003 watcher could simply pass the very same presence items to someone else who could even be explicitly excluded from the access. In scenarios though, in which the resource data is associated with some kind of physical resource, tying the access to the particular querier is highly desirable. However, such support of prohibiting authorization transfer will most likely highly influence a final solution. Requirement 6 aims at supporting cases such in Section 3.1.1 in which one-time access (or generally N-time access, in which N can be defined through the resource owner) is granted to the querier. Requirement 7 aims at ensuring that services using such kind of æon- demand access authorizationÆ will not have to deal with race conditions that are imposed by the access granting process. Requirement 8 targets unwanted access disclosure to third parties. 6. Solution Space This section gives an overview of possible solutions for the presented problem. These possible solutions are presented on a rather functional level, appreciating that dedicated solutions can be found in each of the presented solution categories. 6.1. Authorization Policy Server Transactions The first category relies on the existence of a server that hosts appropriate authorization policies for the resource data. Such server is consulted prior to the actual granting of access through the resource data provider. The work around XCAP [4][11] defines such system as well as the appropriate protocols and application usages. In the following, we will use XCAP as an exemplary implementation of this solution category. XCAP in general allows for solving the on-demand access authorization by having the resource owner set the appropriate access policy for the particular access at the XCAP server using appropriate XCAP transactions. However, this requires the existence of an appropriate XML schema within XCAP for the particular SIP event or presence item. These XCAP transactions have to happen during the conveyance of the querierÆs desire for access prior to the actual subscription. This needs proper synchronization with the transaction during which the desire is conveyed in order to avoid that the querier sends the subscription before the appropriate authorization setting has been finalized. Due to the ad-hoc character of the access, it is likely that the resource owner would like to have the authorization removed after the actual service transaction, e.g., after the location service (as outlined in Section 3.2.1.) has been provided to the resource owner. Trossen, Schulzrinne Expires April 2004 [8] Internet Draft On-Demand Authorization for SUBSCRIBE October 2003 This requires another set of XCAP transactions after the service provisioning took place. However, as already outlined in Section 3.1., while the existence of an XCAP-like system is likely in SIP presence, its existence for general SIP events is rather unlikely, in particular if we envision the provisioning of SIP event based services by a larger diversity of service providers than in the SIP presence case. 6.2. Temporary Account Temporary accounts could be used to some extent for on-demand access authorization of a-priori unknown identities. For that, it is assumed that proper authorization policies exist for each temporary account, which has been created by the resource owner. This of course also assumes an XCAP-like authorization system (see Section 3.1.) to be in place. The credentials for a particular temporary account could then be conveyed from the resource owner to the querier, which in turn uses the credentials for access of the particular data. In order to end the access period, the resource owner needs to explicitly revoke the access authorization at some point after the access period, requiring appropriate XCAP transactions for the particular temporary account. The creation of temporary accounts though puts a certain burden on the resource data provider due to the required maintenance of the additional temporary accounts. Further, the temporary accounts needs to be incorporated in the authorization policies, involving the XCAP server. This becomes even more critical since, depending on the particular use case, the resource owner might not want to re-use the temporary account (since a previous querier could use the credentials to gain access even after the desired access period). In that case, the particular temporary account needs to be removed together with the authorization policy. For a-priori unknown information, it is required to set appropriate authorization policies through XCAP before the actual subscription, folding this into the XCAP transactions case of Section 4.1. 6.2.1 Temporary Account with Time Window Temporary accounts, as described above, could also be associated with time windows of validity to solve the re-use problem. The resource owner is then responsible to provide the appropriate credentials for the desired time window of access. TO BE DISCUSSED: * such techniques usually work with fixed time windows, posing a problem for arbitrary lengths of access periods. This would Trossen, Schulzrinne Expires April 2004 [9] Internet Draft On-Demand Authorization for SUBSCRIBE October 2003 require re-provisioning with appropriate credentials for the next time window. [IS THIS CORRECT?] * How would the problem be solved to define appropriate authorization policies for time window based identities in XCAP? 6.3. Ticket Tickets can be seen as a temporary account with assigned authorization policies for a particular querier. The resource owner, after having received the necessary information to be accessed, creates a ticket with a trusted æticket serverÆ (the ticket server could be co-located with the resource data provider or it could be a separate entity). This ticket is associated with the particular information that is intended to be accessed, i.e., resource owner has to specify this information towards the ticket server. Further, an identifier is included to prevent re-usage of the ticket. The resource owner might include the querierÆs identifier if the access is intended to be bound to the particular querier. The ticket could also be bound to a certain time window, which would have to be specified by the resource owner in the ticket creation. The resource owner then conveys the ticket towards the querier, which in turn includes the ticket in the subscription towards the resource data provider. Upon reception of the subscription, the resource data provider needs to verify the ticket. In this, the resource data provider needs to verify that the ticket is associated with the specified information in the querierÆs subscription. This requires appropriate extraction of the subscription data and conveyance of the information, together with the ticket, to the ticket server. Other information to be included could be the querierÆs identity. If the ticket is indeed valid and associated to the provided information, the ticket server responds positively, and the subscription can be granted. The described method requires appropriate protocols for ticket creation (between resource owner and ticket server) and verification (between resource data provider and ticket server) to be defined. It further requires extensions to SIP SUBSCRIBE in the sense that the SIP event server processing has to take into account the embedding of the ticket information in the SIP SUBSCRIBE body. Even though the ticket-based approach does not require an XCAP-like authorization server, it still introduces a new logical component, namely the ticket server, with which the resource data provider needs to have a trust relationship. In case the ticket server is not co-located with the resource data provider, similar arguments as in Section 3.1. apply regarding the likelihood of having such kind of system in place for arbitrary SIP events. As related work, [13] describes a ticket-based scheme for obtaining location information. Trossen, Schulzrinne Expires April 2004 [10] Internet Draft On-Demand Authorization for SUBSCRIBE October 2003 6.4. Message Authentication In our assumptions and description of the problem space in Section 3, we assumed that the resource owner obtained knowledge of the resource information to which the querier desires access. Based on this knowledge, the following message authentication scheme can be used for granting access. This method is similar to the æPGPticketÆ scheme [8], although applied in this case to SIP event subscriptions and not necessarily using PGP only. After receiving the information from the querier regarding the desired access, the resource owner formulates a message back to the querier. This message includes, similar to the ticket approach: * information regarding the desired access, such as presence items or SIP event package names or other event-specific information, based on the obtained resource information from the querier. * an identifier that prevents re-usage of the message (Could be a simple sequence number, which is increased with each granted access. Such sequence number exists for each resource owner and is maintained at the resource data provider) * identity of the querier, if the permission is bound to the querier. * time window of access, i.e., start and/or end time of validity of the access, if the permission is restricted in time. The resource owner then signs the message appropriately (using either public key mechanisms or shared secrets û it is assumed that the shared secret between resource owner and resource data provider was established prior to the transaction), and sends the message towards the querier. Note that this conveyance back depends on the general nature of the transaction between the querier and resource owner, during which the desire for access has been formulated. This could be, for instance, an HTTP transaction. The querier then embeds the signed payload within the SIP SUBSCRIBE message that is sent towards the resource data provider, i.e., the SIP event server. Upon reception, the SIP event server (resource data provider) extracts the payload and verifies the authenticity of the payload. Apart from verifying the authenticity, checks could be required regarding the identity of the querier, the time window of access, and the desired information to be accessed, depending on the inclusion of the corresponding information within the signed payload (see above). For that, the SIP SUBSCRIBE processing within SIP event servers needs to be extended, compared to RFC 3265 [12]. If the authenticity of the SIP SUBSCRIBE payload has been verified positively, the SIP event server grants access to the corresponding resources, i.e., it positively confirms the subscription according to [12]. Trossen, Schulzrinne Expires April 2004 [11] Internet Draft On-Demand Authorization for SUBSCRIBE October 2003 7. Security Considerations A solution for the problem described in this document shall allow for granting access in ad-hoc authorization scenarios as described in Section 3.1. In this, any solution should allow for * defining all relevant resource information in the authorization, * tying the access to a particular querier, if so desired by the resource owner, * preventing re-usage of the authorization through the querier or third parties, * preventing disclosure of the authorization to third parties * tying the access to a particular (relative or absolute) time window, if so desired by the resource owner, and * verifying the identity of the resource owner. These security considerations have been identified and are addressed within the defined requirements of Section 5. In addition, mechanisms should be in place that allow for revoking any granted authorization even before the expiration of the defined time window (if it was defined). However, such revocation mechanism has been left out of this document as an optional mechanism. 8. Acknowledgements The authors would like to thank Dana Pavel and Chris Newman for their input. 9. References [1] H. Sugano, S. Fujimoto, et al., "Presence information data format (PIDF)," Internet draft, Internet Engineering Task Force, May 2003. Work in progress. [2] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Internet Engineering Task Force, March 1997. [3] J. Rosenberg, "A presence event package for the session initiation protocol (SIP)," Internet draft, Internet Engineering Task Force, Jan. 2003. Work in progress. [4] J. Rosenberg, "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", Internet Draft, Internet Engineering Task Force, (work in progress), May 2003. [5] J. Rosenberg, "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Presence Lists", Internet Draft, Internet Engineering Task Force, (work in progress), May 2003. [6] J. Rosenberg, "A Session Initiation Protocol (SIP) Event Package for Modification Events for the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Managed Trossen, Schulzrinne Expires April 2004 [12] Internet Draft On-Demand Authorization for SUBSCRIBE October 2003 Documents", Internet Draft, Internet Engineering Task Force, (work in progress), May 2003. [7] H. Tschofenig et al., "Location Object Authorization Policies", Internet Draft, Internet Engineering Task Force, (work in progress), August 2003. [8] V. Moscaritolo, A. Mione, "PGPticket", Internet Draft (expired), Internet Engineering Task Force, August 1999. [9] H. Sugano, S. Fujimoto, et al., "Presence information data format(PIDF)", Internet Draft, Internet Engineering Task Force, (work in progress), May 2003. [10] H. Schulzrinne (ed.), "RPID -- Rich Presence Information Data Format", Internet Draft, Internet Engineering Task Force, (work in progress), July 2003. [11] J. Rosenberg, M. Isomaki, "Requirements for Manipulation of Data Elements in Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Systems", Internet Draft, Internet Engineering Task Force, (work in progress), April 2003. [12] A. Roach, "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [13] C. Newman, ôPawn Ticket based Access to Location Informationö, Presentation at 57th IETF meeting, Vienna, July 2003. 10. Authors' Addresses Dirk Trossen Nokia Research 5 Wayside Road Burlington, MA 02474 USA Email: dirk.trossen@nokia.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA Email: schulzrinne@cs.columbia.edu Trossen, Schulzrinne Expires April 2004 [13] Internet Draft On-Demand Authorization for SUBSCRIBE October 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Trossen, Schulzrinne Expires April 2004 [14]