SIMPLE WG O. Levin Internet-Draft Microsoft Corporation Expires: August 1, 2004 A. Houri IBM Feb 2004 Inter-domain Requirements for SIMPLE draft-levin-simple-interdomain-reqs-00.txt 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. This Internet-Draft will expire on August 1, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines the inter-domain SIMPLE interface and identifies the requirements particular to this interface for secure and scalable exchange of presence information. Levin & Houri Expires August 1, 2004 [Page 1] Internet-Draft Inter-domain Requirements for SIMPLE Feb 2004 Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Existing Topologies . . . . . . . . . . . . . . . . . . . . 3 4. Inter-domain SIMPLE Interface Definition . . . . . . . . . . 4 5. PS to PS Logical Connection Requirements . . . . . . . . . . 5 6. User-to-User Requirements . . . . . . . . . . . . . . . . . 6 7. Information Optimization Model . . . . . . . . . . . . . . . 6 7.1 New Functionality . . . . . . . . . . . . . . . . . . . . . 6 7.2 Batching of REQUESTS for Presence Information Retrieval . . 6 7.3 Grouping of Watchers for SHARING of Presence Info . . . . . 7 7.3.1 A Single Watchers Group per Presentity . . . . . . . . . . . 7 7.3.2 Trusted vs. Non-trusted Presence Servers . . . . . . . . . . 8 8. Potential Impacts on SIP and SIMPLE . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . 9 Informational References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . 11 Levin & Houri Expires August 1, 2004 [Page 2] Internet-Draft Inter-domain Requirements for SIMPLE Feb 2004 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 2. Introduction SIMPLE defines a set of extensions to the existing protocols (e.g. SIP [2]) and some new technologies (e.g. XCAP [3]) in order to implement presence and instant messaging (IM) systems. The basic SIMPLE architecture relies completely on a peer-to-peer Internet model for exchanging both presence and IM data. This open system architecture remains an important part of the core SIMPLE functionality. As SIMPLE has matured and became an important technology for implementing presence and IM, different deployment models have been contributing to SIMPLE architecture. The most obvious example is the 3GPP requirements [4] for wireless mobile access. We expect that with growing SIMPLE popularity, more architectural needs will be identified. At this point of time it is important to identify existing deployment architectures and explicitly define a set of requirements for each. It will allow achieving both interoperability and efficiency for each identified interface. Our experience shows that the requirements (and their SIMPLE realization) may differ between the interfaces based on the nature of the deployments. As a result, it is equally important that the SIMPLE realization allows for a straightforward mapping between the interfaces concepts and data models. This document defines the inter-domain SIMPLE interface and identifies the requirements particular to this interface for secure and scalable exchange of presence information. The IM protocol inter-domain requirements [6] are identified and presented in a separate document. 3. Existing Topologies Several main types of presence and IM system deployments can be identified today: o Enterprise (Single Domains of Trust): A presence and IM system that is built for an enterprise use. The enterprise employees are usually authenticated using the same credentials that they use for Levin & Houri Expires August 1, 2004 [Page 3] Internet-Draft Inter-domain Requirements for SIMPLE Feb 2004 other operations within the enterprise. The system is usually located within the secured enterprise network. o Federated Systems: Several networks that have created a federation between them. In these systems a user is able to inter-operate with users in other systems. Usually, there is no need for each user of being authenticated since the authentication is achieved on system level (i.e. is done at the level of each system). o Public Systems Interconnecting: A public system that enables registered users to use the services of the system (such as AOL, MSN, and Yahoo). The users in each public system do not belong to the same organization and therefore can not be trusted as a whole as in enterprise systems. o Open Systems: Users do not belong to an organization and are not registered to use the services of a public system. The services that the users will use will be freely available on the network while peer to peer operations between users will be very common in these systems. 4. Inter-domain SIMPLE Interface Definition In this document the "inter-domain SIMPLE interface" û is defined as the interface between two presence servers (PS) (per SIMPLE presence [5] definitions) that are responsible for all aspects of presence information on behalf of their users and under their consent on federated or/and open public interconnection links. The picture below shows two separately administered networks A and B interconnected by Public Internet potentially with a chain of SIP proxies for application level routing in-between. The components shown in the picture are only the logical SIMPLE entities that are participating in different aspects of presence application. It includes Presence Servers (PS-A and PS-B) and PUAs (A1, A2, A3, B1, B2, and B3). Examples of administered networks include enterprises, public services, etc. The exchange of information between the PS servers doesnÆt rely on shared database because of existing security regulations and/or concerns associated with inter-domain communications. Levin & Houri Expires August 1, 2004 [Page 4] Internet-Draft Inter-domain Requirements for SIMPLE Feb 2004 /\ /\ /A1\ /B1\ /____\ ------------- /____\ ///// \\\\\ +-------+ // \\ +-------+ /\ | | | | | | /\ /A2\ | PS-A | | Public Internet | | PS-B | /B2\ /____\ | | | | | | /____\ +-------+ \\ // +-------+ \\\\\ ///// /\ ------------- /\ /A3\ /B3\ /____\ /____\ The inter-domain presence solution needs to result in both reasonably minimized presence information traffic volume and, in the same time, being able to address very different security models (from multi-branch enterprises with trusted presence servers to public deployments with non-trusted foreign presence servers). It is important both to be able to address all the hard requirements and in the same time to be able to deploy interoperable systems that entail only a subset of the identified requirements. 5. PS to PS Logical Connection Requirements o The servers MUST be able to announce or negotiate their capabilities. o The servers MUST be able to authenticate each other. o The servers MUST be able to sign (and where possible encrypt) the information exchanged between each other (e.g. in the headers). o The servers MUST be able to encrypt payload information exchanged between each other. o It MUST be possible to originate the connection by either server. o The connection MUST enable multiplexing of data from multiple users and domains. o It MUST be possible to detect PS to PS connection failure (and report it to the applications) by both sides in real time. o It SHOULD be possible to allow compression between PS servers. o It MUST be possible to implement periodic refresh of information (such as the presence information) between servers independently of the periodic refresh of users clients because access/local networks differ in their physical characteristics (e.g. bandwidth, resilience, packet loss ratio) from backbone/WAN networks. o It SHOULD be possible to support throttling/congestion control between PS servers. Examples include negotiation of a maximum message rate and resolving the HOL blocking issues with TCP. o It MAY be possible to re-establish a connection without losing data (buffering). Levin & Houri Expires August 1, 2004 [Page 5] Internet-Draft Inter-domain Requirements for SIMPLE Feb 2004 o Connections between servers MAY be transitive. That is when server A is connected to server B and server C is connected to server B; it will be possible to send data between server A and server C through server B. Note: In order to meet this requirement authorization/security model for this case MUST be defined. 6. User-to-User Requirements o Explicit Domain Identifier: It MUST be possible to unambiguously determine which domain the user belongs to from the userÆs identifier (without requiring complicated lookups). o Meaningful User Identifier: The user name MUST be meaningful to the end-users (e.g. not a random global identifier). o A user to all users in other domain: A user in one domain MUST be able to allow and disallow its presence visibility to all users in a specific other domain. o Per user granularity: A user in one domain MUST be able to allow and disallow its presence visibility to a specific user in a remote domain. o Asymmetric user relationships: Users in different domains MUST be able to allow or disallow their presence visibility to each other independently for each direction. o Peer-to-peer authentication in federation scenario: Users MAY be able to authenticate each other. o Peer-to-peer authentication in open public interconnection scenario: Users SHOULD be able to authenticate each other. o Peer-to-peer presence info encryption: In open public interconnection scenarios it SHOULD be possible to encrypt the presence information end-to-end. 7. Information Optimization Model 7.1 New Functionality o Presence access: It MUST be possible to request continuous access to the status of a remote presentity without "subscribing" to it. o Presence query: It MUST be possible to retrieve the status of a remote presentity in present time only (i.e. without "subscribing" to it). o Users search: It MAY be possible to search for a list of presence-enabled users by regular expression. 7.2 Batching of REQUESTS for Presence Information Retrieval o Present access: It MUST be possible to perform a request for presence access from a single watcher to an arbitrary ad-hoc list of presentities in a single operation. o Presence query: It MUST be possible to perform a query request from a single watcher to an arbitrary ad-hoc list of presentities in a single operation. Levin & Houri Expires August 1, 2004 [Page 6] Internet-Draft Inter-domain Requirements for SIMPLE Feb 2004 o Subscription/Unsubscription to presence state: It MUST be possible to perform a subscription/unsubscription request from a single watcher to an arbitrary ad-hoc list of presentities in a single operation. 7.3 Grouping of Watchers for SHARING of Presence Info This document introduces an expanded concept of "a group of watchers". In the basic form of the concept, a presentity can locally arrange its buddies in a number of groups. The watchers in the same group get the same level of exposure to the presentityÆs information. The presentity can assign a different set and/or level of its presence information for each group of watchers. In order to minimize the amount of presence traffic on the inter-domain link, the real-time presence information is being communicated for a pre-defined group of watchers (that are getting the same presence information) in addition to or instead of the peer-to-peer basic mode. In order to accomplish this, PS-B (on behalf of B1) for each B1Æs watcher group constructs a sub-group for domain B (as a subset of watchers belonging to domain A). Each group can contain zero or more B1Æs watchers in domain A. The watcher groups are being maintained in domain B and communicated to domain A. PS-B notifies PS-A about both the changes in the groupÆs membership and the changes in presence state per group. PS-B MUST mark the watchers group whether the changes in the presence information need to be pushed to PS-A (i.e. there is at least one A watcher had "subscribed" to B1Æs presence) or (alternatively) all the current watchers in the group had enquired for access rights (and momentary info) only. PS-A MAY hold the information about the preferred local mode for presence information distribution (e.g. push, pull, none) per its local watcher in the watchers list. The presence information of B1 is distributed by PS-A to the groupÆs current members (potentially according to their local preferences in either push or pull mode) and is also cached by PS-A in order to quickly accommodate newly added group members (without reusing the inter-domain link). 7.3.1 A Single Watchers Group per Presentity In this simplest case, domain A MAY support "a single watchers group Levin & Houri Expires August 1, 2004 [Page 7] Internet-Draft Inter-domain Requirements for SIMPLE Feb 2004 per remote presentity". Note, that this allows for most efficient inter-domain link usage because each piece of presence information is being transmitted only once. If the neighboring (to A) domain B supports multiple watchers group concept, PS-B MUST NOT allow for watchers from domain A being assigned in different groups of presentity B1. The easiest way to present this constraint to user B1 would be to restrict all his "A" buddies to their own dedicated group. 7.3.2 Trusted vs. Non-trusted Presence Servers In a single enterprise deployment with its branches using separate presence systems, a presentity of domain B (B1) trusts the presence server of domain A (PS-A) to distribute and cache B1Æs presence information in open format. In this case no end-to-end keys for encrypting the presence information are required. In other deployments, presentities of domain B donÆt trust a foreign presence server (e.g. of domain A) to have access to their presence information in open format. That is especially crucial in combination with multiple watchers group approach, where the presence information MUST reach the right group of people only. In this type of deployments, the Presence information MUST be encrypted end-to-end and 1-to-N key distribution mechanisms MUST be applied per a group of watchers with more than a single member. In order to allow for encrypted 1-to-1 type of connection, both servers (on behalf of their users) MUST be able to request 1-to-1 encrypted mode of operation (resulting in a "single member" group establishment). It MUST be possible to deploy a combination of open presence information approach and a "single member" group with 1-to-1 presence encryption mechanism for sensitive presence information, thus avoiding the need for using the 1-to-N encryption mechanisms. 8. Potential Impacts on SIP and SIMPLE o TBD. 9. Security Considerations TBD. 10. IANA Considerations None. Levin & Houri Expires August 1, 2004 [Page 8] Internet-Draft Inter-domain Requirements for SIMPLE Feb 2004 11. Acknowledgments Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. Informational References [3] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-01 (work in progress), October 2003. [4] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)", draft-ietf-sipping-3gpp-r5-requirements-00 (work in progress), October 2002. [5] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work in progress), January 2003. [6] Mahy, R., et al., "SIMPLE Session and Relay IM Protocol Requirements ", draft-mahy-simple-im-protocol-reqs-00 (work in progress), February 2004. Authors' Addresses Orit Levin Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: oritl@microsoft.com Levin & Houri Expires August 1, 2004 [Page 9] Internet-Draft Inter-domain Requirements for SIMPLE Feb 2004 Avshalom Houri IBM Science Park Building 18/D Rehovot, Israel EMail: avshalom@il.ibm.com Levin & Houri Expires August 1, 2004 [Page 10] Internet-Draft Inter-domain Requirements for SIMPLE Feb 2004 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 (2004). 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 assignees. 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 Levin & Houri Expires August 1, 2004 [Page 11] Internet-Draft Inter-domain Requirements for SIMPLE Feb 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Levin & Houri Expires August 1, 2004 [Page 12]