Internet Engineering Task Force SIMPLE WG Internet Draft J. Rosenberg dynamicsoft M. Isomaki Nokia draft-ietf-simple-data-req-00.txt October 9, 2002 Expires: April 2003 Requirements for Manipulation of Data Elements in SIMPLE Systems 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract In an instant messaging and presence application, it is frequently necessary for the user to configure a number of pieces of information. Users will need to manipulate their presentity list, adding and removing presentities, and manipulate their authorization lists, which specify the set of users that can subscribe to their presence. In this document, we provide a framework and requirements for such data manipulations. J. Rosenberg et. al. [Page 1] Internet Draft data req October 9, 2002 Table of Contents 1 Introduction ........................................ 3 2 Terminology ......................................... 3 3 Framework ........................................... 4 4 Presentity Collection Manipulation Requirements ..... 7 5 Authorization Policy Manipulation ................... 9 5.1 Acceptance Policy Requirements ...................... 9 5.2 Notification Requirements ........................... 11 5.3 Content Requirements ................................ 12 5.4 General Requirements ................................ 12 6 Possible Solutions .................................. 13 7 Security Considerations ............................. 13 8 Acknowledgements .................................... 14 9 Authors Addresses ................................... 14 10 Normative References ................................ 15 11 Informative References .............................. 15 J. Rosenberg et. al. [Page 2] Internet Draft data req October 9, 2002 1 Introduction Consumer-based instant messaging and presence applications typically provide a rich set of features. In addition to being able to subscribe to, and get notified of, changes in presence, users can also configure the operation of the application. Most systems allow the user to add or remove users from their "buddy list", which we refer to here as a presentity collection. The presentity collection is the set of presentities [1] that a user is subscribed to. This list is frequently stored on the server, allowing the user to generate a single subscription to the entire list. The server then "fans out" that subscription too all the presentities on the list. Subscription to presentity collections is supported through the presence collection event package defined for SIMPLE [2]. However, no automated means is currently defined to create these lists, add users to them, remove users from them, or query for the set of users on the list. Similarly, most systems support user-defined authorization policies. A user can specify which watchers are (or are not) allowed to subscribe to their presence, and furthermore, what aspects of their presence a watcher is able to see. While SIMPLE [3] systems can support such authorization policies, besides human-driven techniques, such as web or voice response, there is no automated way to specify these policies. In this document, we propose a framework and a set of requirements for manipulation of presentity collections and authorization policies. 2 Terminology This document uses the following terminology: Presentity Collection: A presentity collection is a set of presentities, each of which is identified by a URI. The collection itself is identified by a URI (for example, sip:myfriends@example.com). Using the presence list package [2], a watcher can subscribe to the presentity collection and learn about the presence state of all the presentities in the set. Presence Authorization Policy: Presence authorization policy refers to the set of directives given to a presence agent on what subscriptions to accept, when to generate notifications for a subscription, and what information should be placed in those notifications. J. Rosenberg et. al. [Page 3] Internet Draft data req October 9, 2002 Acceptance Policy: The component of presence authorization policy that determines whether or not to accept a subscription from a watcher. Notification Policy: The component of presence authorization policy that determines when a notification should be sent to a watcher. Content Policy: The component of presence authorization that determines the content of the information provided to a watcher in a notification. SIMPLE Data Elements: SIMPLE data elements are user specified data that determine the behavior of a presence agent. This includes presentity collections and presence authorization policy. Data Manipulation Client: A data manipulation client is a protocol agent that reads, writes, and receives notifications of changes in SIMPLE data elements. Data Manipulation Server: A data manipulation server is a protocol agent that receives reads, writes, and sends notifications of changes in SIMPLE data elements. The server is responsible for the storage of the SIMPLE data elements. 3 Framework The framework for the the usage and manipulation of SIMPLE data elements is shown in Figure 1. The data manipulation client (just referred to as the client) uses some protocol, whose requirements are specified here, to interact with the data manipulation server. Those interactions include requests to read a SIMPLE data element, write one, or receive notifications in changes to one. The data manipulation server (just referred to as the server) mananges a persistent store of the SIMPLE data elements, and interacts with the client. When a Presence Agent (PA) receives a SIP SUBSCRIBE request [3], it may require access to SIMPLE data elements in order to process the request. For example, if the subscription is for a presentity collection, the PA will need to determine that this is the case, and secondly, "expand" the collection, obtaining the list of URIs for that collection. J. Rosenberg et. al. [Page 4] Internet Draft data req October 9, 2002 SUBSCRIBE +--------+ --------------->| | Read | PA |<--+ //----\\ <---------------| | | || || NOTIFY +--------+ +--- \\----//| | | | Storage| | | +--------+ | | | Server |------> | | | | Write \ / | | \------/ +--------+ ^ | | | | | BL/Auth | | Manipulations | | | | | V +--------+ | Client | | | | | +--------+ Figure 1: Framework for Data Manipulation If the SUBSCRIBE request is for a presentity, the PA will need to obtain the presence authorization policy of that presentity in order to process the SUBSCRIBE request. In both cases, the PA requires only read access to the data. As a result, it obtains it directly from the data store, rather than interacting with the server. This, of course, is just a model of the system; a real implementation might involve interaction with the J. Rosenberg et. al. [Page 5] Internet Draft data req October 9, 2002 server before reading the data. Between the presentity collection and presence authorization policy, the presence authorization policy is a far more complicated piece of data. The authorization policy can be reasonably split into three separate pieces. The first, which we call the acceptance policy, determines whether or not to grant a subscription to the subscriber. This policy results in a binary decision. The second piece, which we call the notification policy, determines when that particular subscriber should receive notifications. For example, a subscriber might only be permitted to see when I log in or log out of IM, but not receive notifications when my phone goes on hook. This is closely related to the third piece, which we call the content policy. This policy specifies the content of the information present in a notification that is sent to a subscriber. Generally, there are two aspects to each of these policy components. One is the logic that guides the policy, and the other is the data (such as lists of users) accessed by that logic. As an example, the logic of the acceptance policy might dictate that a watcher is checked against an explicit deny list, and if present, their subscription is denied. If they are not on the deny list, they are checked against an explicit allow list, and if present, their subscription is accepted. If they are on neither list, they are marked as pending. This logic makes use of two lists, which represent the data. In this model, the logic can be represented by a script, similar to the operation of a Call Processing Language (CPL) [4] script. The primitives of the scripting language would allow for access to the lists that represent the data. For example, a CPL-like script representing the policy example of the previous paragraph might look like: J. Rosenberg et. al. [Page 6] Internet Draft data req October 9, 2002 The deny and allow lists are, in this example, represented by SIP URIs. The script itself can also be represented by a URI. In order to activate a policy, a particular script is bound to the authorization function that executes at the PA. 4 Presentity Collection Manipulation Requirements The following are the set of requirements for the protocol between the client and the server for the purposes of manipulation presentity collections. REQ 1: It MUST be possible for the client to create a presentity collection and associate it with a URI. REQ 2: It MUST be possible for the user to specify the URI for the presentity collection when one is created. If the name cannot be allocated (because it already exists, for example), it MUST be possible to inform the client of the failure, and the reason for it. REQ 3: It SHOULD be possible for the server to provide the client a URI for the list when one is created, in the case where the client does not provide it. REQ 4: It MUST be possible to add an entry to the presentity collection. Each entry MUST consist of at least a URI, and MAY include a display name. It MUST be possible for the entry to be any URI that is meaningful in the context of a presentity collection. Examples would include a SIP URI or pres URI [5]. REQ 5: It MUST be possible for a presentity collection to contain entries which are themselves presentity collections. REQ 6: It MUST be possible to remove an entry from the presentity collection, by providing the URI for the specific entry to be removed. If the entry does not exist, it MUST be possible for the server to inform the client of J. Rosenberg et. al. [Page 7] Internet Draft data req October 9, 2002 this fact. REQ 7: It SHOULD be possible to clear all entries from a presentity collection. REQ 8: It MUST be possible to delete a presentity collection. In this context, deleted means that the name of the presentity collection is no longer defined, so that subscriptions to the list would fail. REQ 9: It MUST be possible to query for the set of URIs in a particular presentity collection, by providing the URI for the presentity collection. REQ 10: It MUST be possible for the presentity collection to be associated with a list of authorized users. Those authorized users are the only ones permitted to manipulate the presentity collection. REQ 11: It MUST be possible for a client to store a cached copy of the list. This implies that it MUST be possible for the server to notify the client of a change in the list. It MUST be possible for the client to manipulate the local cached copy even when there is no connectivity to the server. It MUST be possible to synchronize the cached copy with the master copy on the server, when connectivity is re-established. This particular requirement is crucial for wireless systems, where a copy of the list resides ont he handset. Without this requirement, a user would not be able to view the list, or add a user to it, when they go out of coverage. REQ 12: It MUST be possible for there to be multiple clients with cached copies of the list. REQ 13: Manipulations of the presentity collection MUST exhibit the ACID property; that is, they MUST be atomic, be consistent, durable, and operate independently. REQ 14: It MAY be possible for the client to batch multiple operations (add a presentity, remove a presentity) into a single request that is processed atomically. REQ 15: It MUST be possible for the server to authenticate the client. J. Rosenberg et. al. [Page 8] Internet Draft data req October 9, 2002 REQ 16: It MUST be possible for the client to authenticate the server. REQ 17: It MUST be possible for message integrity to be insured between the client and the server. REQ 18: It MUST be possible for privacy to be insured between the client and server. As a motivating example, an eavesdropper on the protocol could ascertain the set of people in my presentity collection, resulting in divulging private information. REQ 19: It MUST be possible for the protocol to operate through an intermediary, such as a proxy. REQ 20: It MUST be possible to modify an entry in the presentity collection. 5 Authorization Policy Manipulation The following are the set of requirements for the protocol between the client and the server for the purposes of manipulating presence authorization policy. The requirements are divided between acceptance policy, notification policy, and content policy. 5.1 Acceptance Policy Requirements REQ 1: It MUST be possible for the acceptance policy to support rejection of the subscription if the watcher is present on a specified list of "blocked watchers". When a list is checked in this fashion, its referred to as a blocked list. This is effectively a requirement on the scripting language. REQ 2: It MUST be possible for the acceptance policy to support rejection of the subscription if the watcher is not present on a specified list of "allowed watchers". When a list is checked in this fashion, its referred to as an allowed list. REQ 3: It MUST be possible for the acceptance policy to check multiple blocked and allowed lists. REQ 4: It MUST be possible for the acceptance policy to support rejection of the subscription based on filter information provided in the subscription. REQ 4.1: It MUST be possible for the policy to be based on the J. Rosenberg et. al. [Page 9] Internet Draft data req October 9, 2002 status types (for example, the basic status type as defined in PIDF [6] requested in the filter. REQ 4.2: It MUST be possible for the policy to be based on the status values requested in the filter. REQ 4.3: It MUST be possible for the policy to be based on whether the subscriber has requested, using the filter, to receive contact addresses. REQ 5: It SHOULD be possible for the policy to be based on the time of day. REQ 6: It SHOULD be possible for the policy to be based on the means by which the authenticated identity of the watcher was determined. REQ 7: It MUST be possible for the user to manipulate any lists that are checked by by the authorization policy (for example, the allowed and denied lists). REQ 7.1: It MUST be possible for the user to add URIs to the lists. REQ 7.2: It MUST be possible for the user to remove URIs from the lists. REQ 7.3: It MUST be possible for the user to modify URIs in the lists. REQ 7.4: It MUST be possible for the user to obtain the contents of a list. REQ 7.5: It MUST be possible for the user to create new lists. REQ 7.6: It MUST be possible for the user to delete lists. REQ 7.7: It MUST be possible for the user to clear all URIs on a list. REQ 7.8: It MUST be possible for the user to assign a URI that identifies the list. REQ 7.9: It MUST be possible for the server to assign a URI that identifies a list created by the user. REQ 8: It MUST be possible to bind a script defining the logic for processing to a particular authorization function. J. Rosenberg et. al. [Page 10] Internet Draft data req October 9, 2002 REQ 9: It MUST be possible for the client to determine the set of supported scripting languages. REQ 10: It MUST be possible for the server to reject the script because it is malformed, too complex, or not acceptable for some other reason. REQ 11: It MUST be possible for the client to fetch the current script. REQ 12: It MUST be possible for the client to indicate what script languages it supports when it fetches the script. In this way, a server could conceivably translate it to a format supported by the client. REQ 13: When a list referenced by script is deleted, the user MUST either be alerted or prevented from doing so. 5.2 Notification Requirements REQ 1: It MUST be possible for the user to specify that notifications are to be sent only when the value of a particular status type changes. REQ 2: It MUST be possible for the user to specify that the notifications are to be sent only when a particular status type changes to a specified value or set of values. REQ 3: It MUST be possible for the user to specify that the notifications are to be sent only when a particular status type changes from a specified value to a specified value (i.e., from open to closed). REQ 4: It MUST be possible for the user to specify that the notifications are to be sent no more frequently than a specified minimum rate. REQ 5: It MUST be possible for the user to specify that the notifications are to be sent only when the value of the contact address changes. OPEN ISSUE: Does this even make sense? REQ 6: It SHOULD be possible for the user to specify that the notifications are not to be sent on changes in the state of the subscription (as opposed to the state of the presentity). J. Rosenberg et. al. [Page 11] Internet Draft data req October 9, 2002 REQ 7: It SHOULD be possible for the user to specify that the notifications are to be sent based on the filter policy present in the SUBSCRIBE request. In that case, the overall filter policy would be the composition of the requested filter and the filters explicitly specified by the presentity. 5.3 Content Requirements REQ 1: It MUST be possible for the user to specify that the notification should or should not contain a contact address. REQ 2: It MUST be possible for the user to specify that the notification should contain only specific status types (such as basic). REQ 3: The user MUST be able to specify the specific values of a specific status type that the notification should or should not contain. Values not permitted must be omitted from the status in notifications. If all status is omitted, the tuple must be omitted as well. As an example, a user can specify that the notification should include tuples with OPEN status, but suppress those with only CLOSED status. REQ 4: The user MUST be able to specify that the notification should only contain information for particular tuples. OPEN ISSUE: Its not clear how to meaningfully identify the tuples. REQ 5: It SHOULD be possible for the user to specify that the notifications are to be sent based on the filter policy present in the SUBSCRIBE request. In that case, the overall filter policy would be the composition of the requested filter and the filters explicitly specified by the presentity. 5.4 General Requirements These requirements apply to all of the three components of the authorization policy. REQ 1: It SHOULD be possible for a client to store a cached copy of the policies and any related data (the lists, for example). This implies that it MUST be possible for the server to notify the client of a change in these data. It J. Rosenberg et. al. [Page 12] Internet Draft data req October 9, 2002 MUST be possible for the client to manipulate the local cached copy even when there is no connectivity to the server. It MUST be possible to synchronize the cached copy with the master copy on the server, when connectivity is re-established. REQ 2: It MUST be possible for there to be multiple clients with cached copies of the data. REQ 3: Manipulations of the data MUST exhibit the ACID property; that is, they MUST be atomic, be consistent, durable, and operate independently. REQ 4: It MAY be possible for the client to batch multiple operations (add a user to a list, change the script) into a single request that is processed atomically. REQ 5: It MUST be possible for the server to authenticate the client. REQ 6: It MUST be possible for the client to authenticate the server. REQ 7: It MUST be possible for message integrity to be insured between the client and the server. REQ 8: It MUST be possible for privacy to be insured between the client and server. As a motivating example, an eavesdropper on the protocol could ascertain the set of people in my allowed list collection, resulting in divulging private information. REQ 9: It MUST be possible for the protocol to operate through an intermediary, such as a proxy. 6 Possible Solutions This document is primarily a requirements document, and does not aim to provide a protocol for meeting the requirements defined here. However, there are several protocols already in existence which appear close to meeting the requirements described. One of these is ACAP [7]. Since the protocol is primarily a client-server RPC type of operation, it seems like HTTP and SOAP might also serve as a basis, with a suitably defined set of WSDL. SIP could operate alongside SOAP, to provide the notification aspects of the requirements. SNMP is another possibility for the protocol. 7 Security Considerations J. Rosenberg et. al. [Page 13] Internet Draft data req October 9, 2002 There are many security considerations associated with the protocol whose requirements are defined here. The protocol is used to manipulate data that has a signficiant impact on the operation of a service provided to a user. In particular, if the data is manipulated by an attacker, the attacker can: o convey information to subscribers that the presentity wishes to keep private; o launch denial of service attacks by flooding a subscriber with more presence information than they expected; o deny service to subscribers or to presentities. To prevent these attacks, the protocol has to ensure than only authorized users can manipulate the data. Requirements for authentication and authorization are defined above. Information conveyed in the protocol represents sensitive data. It can include the content of presentity collections and lists of blocked users, both of which reveal personal preferences of a user that they do not wish to convey. As a result, it is necessary that the client authenticate the server, to be sure it is passing this information to a trusted entity. It is also necessary for the protocol to provide encryption services, so that eavesdroppers cannot inspect the data as it passes by. 8 Acknowledgements The authors would like to thank Paul Kyzivat for his input. 9 Authors Addresses Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com Markus Isomaki Nokia Nokia House Keilalahti, Espoo Finland email: markus.isomaki@nokia.com J. Rosenberg et. al. [Page 14] Internet Draft data req October 9, 2002 10 Normative References 11 Informative References [1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and instant messaging," RFC 2778, Internet Engineering Task Force, Feb. 2000. [2] J. Rosenberg and B. Campbell, "A SIP event package for list presence," Internet Draft, Internet Engineering Task Force, June 2002. Work in progress. [3] J. Rosenberg, "Session initiation protocol (SIP) extensions for presence," Internet Draft, Internet Engineering Task Force, May 2002. Work in progress. [4] J. Lennox and H. Schulzrinne, "Call processing language framework and requirements," RFC 2824, Internet Engineering Task Force, May 2000. [5] D. Crocker et al. , "Common presence and instant messaging (CPIM)," Internet Draft, Internet Engineering Task Force, Aug. 2002. Work in progress. [6] H. Sugano, S. Fujimoto, et al. , "Common presence and instant messaging (CPIM)presence information data format," Internet Draft, Internet Engineering Task Force, May 2002. Work in progress. [7] C. Newman and J. G. Myers, "ACAP -- application configuration access protocol," RFC 2244, Internet Engineering Task Force, Nov. 1997. Full Copyright Statement Copyright (c) The Internet Society (2002). 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 J. Rosenberg et. al. [Page 15] Internet Draft data req October 9, 2002 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. J. Rosenberg et. al. [Page 16]