SIMPLE Group A. Houri Internet-Draft IBM Expires: November 30, 2003 A. Audu Alcatel T. Hiller Lucent T. Hansen AT&T Laboratories June 2003 SIP/SIMPLE Based Presence and IM Architecture draft-houri-simple-arch-03 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 November 30, 2003. Copyright Notice Copyright (C) The Internet Society (2003). Abstract This document collects information required for the creation a complete Presence and IM system using SIMPLE and other IETF Houri, et al. Expires November 30, 2003 [Page 1] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 protocols. This information has been spread out across numerous other internet drafts and RFCs. The document tries to put everything together, discussing the servers involved, security mechanisms, call flows, etc. The goal of this document is that someone, who is not an expert in the IETF protocols, can read this document and understand how the IETF protocols can be used for building a complete system and how it should work. SPECIFCATIONS SECTION TO BE UPDATED SHORTLY Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. High Level Architecture . . . . . . . . . . . . . . . . . . . 7 4.1 Single Server System . . . . . . . . . . . . . . . . . . . 8 4.2 Multiple Server System . . . . . . . . . . . . . . . . . . 9 5. Specifications . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 IMPP/CPIM Specifications . . . . . . . . . . . . . . . . . 9 5.2 SIMPLE Group Specifications . . . . . . . . . . . . . . . 10 5.2.1 Presence . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.2 Data Representation and Access Control . . . . . . . . 11 5.2.3 Messaging . . . . . . . . . . . . . . . . . . . . . . 12 5.2.4 Lists - Events and Manipulation . . . . . . . . . . . 12 5.2.5 Publish . . . . . . . . . . . . . . . . . . . . . . . 12 5.2.6 Watchers . . . . . . . . . . . . . . . . . . . . . . . 13 5.2.7 SIMPLE/CPIM Related Docs . . . . . . . . . . . . . . . 13 5.2.8 Relevant SIP Group Specifications . . . . . . . . . . 13 5.2.9 Relevant SIPPING Group Specifications . . . . . . . . 14 5.3 Basic Functional Model . . . . . . . . . . . . . . . . . . 15 5.4 Basic Flows . . . . . . . . . . . . . . . . . . . . . . . 19 5.4.1 Registration . . . . . . . . . . . . . . . . . . . . . 19 5.4.2 Sending and Receiving Messages . . . . . . . . . . . . 21 5.4.2.1 Sending a Pager Mode Message . . . . . . . . . . . 22 5.4.2.2 Receiving a Pager Mode Message . . . . . . . . . . 25 5.4.2.3 Deferred Message Delivery to IM Application . . . 28 5.4.2.4 Delivery of Deferred Message to User . . . . . . . 30 5.4.2.5 Logging Pager-Mode Messages . . . . . . . . . . . 32 5.4.2.6 Establishing a Point-to-Point Messaging Session . 32 5.4.2.7 Sending a Message Within a Messaging Session . . . 35 5.4.2.8 Receiving a Message Within a Messaging Session . . 37 5.4.2.9 Adding a Member to an Established Session . . . . 37 5.4.2.10 Transitioning a Two Party Session to a Multiparty Conference and Adding a Third Participant . . . . . . . . . . . . . . . . . . . 37 5.4.2.11 Adding a User to a Multiparty Session . . . . . . 41 5.4.2.12 Leaving a Messaging Session . . . . . . . . . . . 42 5.4.2.13 Logging Messaging Session Messages . . . . . . . . 42 5.4.3 Group Operations . . . . . . . . . . . . . . . . . . . 42 Houri, et al. Expires November 30, 2003 [Page 2] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.4.3.1 Creating a Group . . . . . . . . . . . . . . . . . 43 5.4.3.2 Deleting a Group . . . . . . . . . . . . . . . . . 45 5.4.3.3 Modifying a Group . . . . . . . . . . . . . . . . 46 5.4.3.4 Retrieving a Group . . . . . . . . . . . . . . . . 47 5.4.3.5 Publishing User Management Policy . . . . . . . . 48 5.4.4 Access Deferred Messages . . . . . . . . . . . . . . . 49 5.4.5 Presence Operations . . . . . . . . . . . . . . . . . 50 5.4.5.1 Publishing Presence . . . . . . . . . . . . . . . 51 5.4.5.2 Subscribing to Presence (or a Presence List) . . . 52 5.4.5.3 Receiving a Presence Notification . . . . . . . . 53 5.4.5.4 Querying Presence . . . . . . . . . . . . . . . . 54 5.5 Security and Privacy Issues in IM/Presence Architecture . 54 5.5.1 Authentication . . . . . . . . . . . . . . . . . . . . 55 5.5.1.1 Challenge-Response Access Authentication Mechanism . . . . . . . . . . . . . . . . . . . . 55 5.5.1.2 Limitations . . . . . . . . . . . . . . . . . . . 57 5.5.2 Authorization . . . . . . . . . . . . . . . . . . . . 57 5.5.3 Integrity And Confidentiality . . . . . . . . . . . . 57 5.5.3.1 Privacy . . . . . . . . . . . . . . . . . . . . . 57 5.5.3.2 AAA Service . . . . . . . . . . . . . . . . . . . 59 5.6 Types of Deployments . . . . . . . . . . . . . . . . . . . 59 5.6.1 Enterprise (Single Domains of Trust) . . . . . . . . . 60 5.6.1.1 Definition . . . . . . . . . . . . . . . . . . . . 60 5.6.1.2 Components & Diagrams . . . . . . . . . . . . . . 60 5.6.1.3 Scenarios . . . . . . . . . . . . . . . . . . . . 60 5.6.1.3.1 Locating Other Servers . . . . . . . . . . . . 60 5.6.1.3.2 Creating Connections . . . . . . . . . . . . . 60 5.6.1.3.3 Authentication . . . . . . . . . . . . . . . . 60 5.6.1.3.4 State Replication . . . . . . . . . . . . . . 60 5.6.1.3.5 Advanced Configurations & Scenarios . . . . . 61 5.6.1.3.5.1 Firewalls . . . . . . . . . . . . . . . . 61 5.6.1.3.5.2 Wireless . . . . . . . . . . . . . . . . . 61 5.6.1.3.5.3 Gateways . . . . . . . . . . . . . . . . . 61 5.6.2 Federated Systems . . . . . . . . . . . . . . . . . . 61 5.6.2.1 Definition . . . . . . . . . . . . . . . . . . . . 61 5.6.2.2 Components & Diagrams . . . . . . . . . . . . . . 61 5.6.2.3 Scenarios . . . . . . . . . . . . . . . . . . . . 61 5.6.2.3.1 Locating Other Servers . . . . . . . . . . . . 61 5.6.2.3.2 Creating Connections . . . . . . . . . . . . . 61 5.6.2.3.3 Authentication . . . . . . . . . . . . . . . . 61 5.6.2.3.4 State Replication . . . . . . . . . . . . . . 62 5.6.2.3.5 Advanced Configurations & Scenarios . . . . . 62 5.6.2.3.5.1 Firewalls . . . . . . . . . . . . . . . . 62 5.6.2.3.5.2 Wireless . . . . . . . . . . . . . . . . . 62 5.6.2.3.5.3 Gateways . . . . . . . . . . . . . . . . . 62 5.6.3 Public Systems Interconnecting . . . . . . . . . . . . 62 5.6.3.1 Definition . . . . . . . . . . . . . . . . . . . . 62 5.6.3.2 Components & Diagrams . . . . . . . . . . . . . . 62 Houri, et al. Expires November 30, 2003 [Page 3] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.6.3.3 Scenarios . . . . . . . . . . . . . . . . . . . . 62 5.6.3.3.1 Locating Other Servers . . . . . . . . . . . . 62 5.6.3.3.2 Creating Connections . . . . . . . . . . . . . 62 5.6.3.3.3 Authentication . . . . . . . . . . . . . . . . 63 5.6.3.3.4 State Replication . . . . . . . . . . . . . . 63 5.6.3.3.5 Advanced Configurations & Scenarios . . . . . 63 5.6.3.3.5.1 Firewalls . . . . . . . . . . . . . . . . 63 5.6.3.3.5.2 Wireless . . . . . . . . . . . . . . . . . 63 5.6.3.3.5.3 Gateways . . . . . . . . . . . . . . . . . 63 5.6.4 Open systems . . . . . . . . . . . . . . . . . . . . . 63 5.6.4.1 Definition . . . . . . . . . . . . . . . . . . . . 63 5.6.4.2 Components & Diagrams . . . . . . . . . . . . . . 63 5.6.4.3 Scenarios . . . . . . . . . . . . . . . . . . . . 63 5.6.4.3.1 Locating Other Servers . . . . . . . . . . . . 64 5.6.4.3.2 Creating Connections . . . . . . . . . . . . . 64 5.6.4.3.3 Authentication . . . . . . . . . . . . . . . . 64 5.6.4.3.4 State Replication . . . . . . . . . . . . . . 64 5.6.4.3.5 Advanced Configurations & Scenarios . . . . . 64 5.6.4.3.5.1 Firewalls . . . . . . . . . . . . . . . . 64 5.6.4.3.5.2 Wireless . . . . . . . . . . . . . . . . . 64 5.6.4.3.5.3 Gateways . . . . . . . . . . . . . . . . . 64 5.7 Basic User Scenarios . . . . . . . . . . . . . . . . . . . 64 5.7.1 Locating the Server(s) . . . . . . . . . . . . . . . . 64 5.7.2 Connection . . . . . . . . . . . . . . . . . . . . . . 65 5.7.3 Logging-In (AKA Registering) . . . . . . . . . . . . . 65 5.7.4 Authentication . . . . . . . . . . . . . . . . . . . . 65 5.7.5 Uploading Presence Document . . . . . . . . . . . . . 65 5.7.6 Subscribing to a Presentity . . . . . . . . . . . . . 65 5.7.7 Getting Notifications . . . . . . . . . . . . . . . . 65 5.7.8 Sending IM . . . . . . . . . . . . . . . . . . . . . . 65 5.7.9 Receiving IM . . . . . . . . . . . . . . . . . . . . . 65 5.8 The Presence Document . . . . . . . . . . . . . . . . . . 65 5.9 Composition From Multiple Sources . . . . . . . . . . . . 68 5.10 Status Values . . . . . . . . . . . . . . . . . . . . . . 68 5.11 Instant Messages . . . . . . . . . . . . . . . . . . . . . 68 5.12 Advanced Presence Scenarios . . . . . . . . . . . . . . . 68 5.13 Partial Notifications . . . . . . . . . . . . . . . . . . 68 5.14 Authorization of Subscription . . . . . . . . . . . . . . 68 5.15 Presence Lists . . . . . . . . . . . . . . . . . . . . . . 68 5.16 Watchers List . . . . . . . . . . . . . . . . . . . . . . 68 5.17 Advanced IM Scenarios . . . . . . . . . . . . . . . . . . 68 5.17.1 IM Sessions . . . . . . . . . . . . . . . . . . . . . 68 5.17.2 IM Conferences . . . . . . . . . . . . . . . . . . . . 69 5.17.3 Instant Conferences . . . . . . . . . . . . . . . . . 69 5.17.4 Scheduled Conferences . . . . . . . . . . . . . . . . 69 5.17.5 Switching between IM Page Mode, IM Sessions and IM Conferences . . . . . . . . . . . . . . . . . . . . . 69 5.18 Client Capabilities . . . . . . . . . . . . . . . . . . . 69 Houri, et al. Expires November 30, 2003 [Page 4] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.19 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.20 Additional Issues and Services . . . . . . . . . . . . . . 69 5.20.1 Invisible (Lurking) Mode . . . . . . . . . . . . . . . 69 5.20.2 Action Cues . . . . . . . . . . . . . . . . . . . . . 70 5.20.3 Emoticons & Backgrounds . . . . . . . . . . . . . . . 70 5.20.4 Message History . . . . . . . . . . . . . . . . . . . 70 5.20.5 Offline Messages . . . . . . . . . . . . . . . . . . . 70 5.20.6 Queued Offline Messages . . . . . . . . . . . . . . . 70 5.20.7 Other Offline . . . . . . . . . . . . . . . . . . . . 70 5.20.8 File Sharing . . . . . . . . . . . . . . . . . . . . . 70 5.20.9 Voice . . . . . . . . . . . . . . . . . . . . . . . . 70 5.20.10 Video . . . . . . . . . . . . . . . . . . . . . . . 70 5.20.11 General Application Invocation . . . . . . . . . . . 71 5.21 Security Considerations . . . . . . . . . . . . . . . . . 71 5.21.1 Authentication . . . . . . . . . . . . . . . . . . . . 71 5.21.2 Network Authentication of the endpoint . . . . . . . . 71 5.21.3 Endpoint Authentication of the Service Elements . . . 72 5.21.4 Authorization for Service . . . . . . . . . . . . . . 72 5.21.5 Integrity and Privacy of SIP/SIMPLE Messages . . . . . 72 5.21.6 Configuration of Subscriber Data or Stored Messages . 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 73 6.2 Non-Normative References . . . . . . . . . . . . . . . . . . 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 77 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 77 Intellectual Property and Copyright Statements . . . . . . . . 78 Houri, et al. Expires November 30, 2003 [Page 5] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 1. Introduction SIMPLE, SIP and SIPPING groups seems to be the most active groups in the IETF. Currently there are more then a hundred active I-Ds. This document tries to summarize the work in the SIMPLE group by defining what are the possible architectures for the creation of a SIMPLE based presence and IM system. The document starts by a definitions section in which we define the entities and the concepts that will serve us while we describe the architecture. The definitions sections is followed by a high level architecture that defines a very basic presence and IM architecture. The document continues with a specifications section in which we survey the current RFCs and active internet-drafts that will be referred throughout the document. These specifications are actually the building blocks of the systems described. After the introductory sections there are two major parts to this document: The server centric view of the possible systems, in which we describe the possible server deployments of a presence and IM systems. The second major part of the document is the user centric view in which we describe basic and advanced scenarios of presence and IM from the UA's point of view. Note that this is only the very first draft of the document. Most of it is still TBD. 2. Terminology 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] 3. Definitions This document uses terms as defined in various internet-drafts and RFCs. See Section 5 for the complete list and description of specifications used in the document. [TBD. This section will contain a lot of definitions that we will need. Need to specify for each definition, the specification it was taken from, Noting definitions that are defined in this document.] Presence User Agent (PUA): A Presence User Agent manipulates presence information for a presentity. This manipulation can be the side effect of some other action (such as sending a SIP REGISTER request to add a new Contact) or can be done explicitly through the publication of presence documents. We explicitly allow Houri, et al. Expires November 30, 2003 [Page 6] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 multiple PUAs per presentity. This means that a user can have many devices (such as a cell phone and Personal Digital Assistant (PDA)), each of which is independently generating a component of the overall presence information for a presentity. PUAs push data into the presence system, but are outside of it, in that they do not receive SUBSCRIBE messages, or send NOTIFY messages. Presence Agent (PA): A presence agent is a SIP user agent which is capable of receiving SUBSCRIBE requests, responding to them, and generating notifications of changes in presence state. A presence agent must have knowledge of the presence state of a presentity. This means that it must have access to presence data manipulated by PUAs for the presentity. One way to do this is by co-locating the PA with the proxy/registrar. Another way is to co-locate it with the presence user agent of the presentity. However, these are not the only ways, and this specification makes no recommendations about where the PA function should be located. A PA is always addressable with a SIP (or SIPS) URI that uniquely identifies the presentity (i.e, sip:joe@example.com). There can be multiple PAs for a particular presentity, each of which handles some subset of the total subscriptions currently active for the presentity. A PA is also a notifier (defined in RFC 3265 [7]) that supports the presence event package. Presence Server: A presence server is a physical entity that can act as either a presence agent or as a proxy server for SUBSCRIBE requests. When acting as a PA, it is aware of the presence information of the presentity through some protocol means. When acting as a proxy, the SUBSCRIBE requests are proxied to another entity that may act as a PA. Edge Presence Server: An edge presence server is a presence agent that is co-located with a PUA. It is aware of the presence information of the presentity because it is co- located with the entity that manipulates this presence information. Registrar: A registrar is a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles. Location Service: A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of address-of- record keys to zero or more contact addresses. The bindings can be created and removed in many ways; this specification defines a REGISTER method that updates the bindings. 4. High Level Architecture This section describes a high level abstraction of a presence and IM system. The intention of this section is to provide a basis for the description of the more complex system further on. Houri, et al. Expires November 30, 2003 [Page 7] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 [TBD. Relate between entities and specification documents.] 4.1 Single Server System A system of a single presence server to which user agents are connected will look like the following, +---------+ +----------------+ |Presence | | Authentication | | Server | | Server | +---------+ +----------------+ ^ ^ | | | V | +------------+ | | Registrar/ | | | Locator | | +------------+ | ^ | +---------+ | +---->| Proxy |<-+ +---------+ ^^^^^ ||||| VVVVV User Agents Figure 1 Figure 1 illustrates a very simple (or even simplistic) presence and IM architecture of a single server. Users connect through a proxy to the system. The proxy directs their logon (REGISTER)requests to the registrar that uses a back-end authentication directory for authenticating the users. Subscription and notifications requests are directed to the presence server that serves them. Sending instant messages can be done directly between the users or via the proxy. Houri, et al. Expires November 30, 2003 [Page 8] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 4.2 Multiple Server System A system of multiple servers to which user agents are connected will look like the following, +---------+ +---------+ | Single | | Single | | Server | o o o | Server | | System | | System | +---------+ +---------+ ^^^^^ ^^^^^ ||||| ||||| VVVVV VVVVV User Agents User Agents Figure 2 Figure 2 illustrates a more complex scenario where there are multiple units of a single server system. Users may connect to each of the single server systems. Following issues arise: o Mapping of users to their servers - Users may have their presence list (e.g. buddy list) and other information stored at one of the servers. When a user logs on, its server side storage has to be retrieved from the appropriate server. Furthermore, changes to the server side storage has to be replicated to the appropriate server o Replication of presence information - When a user logs on to one of the servers and uploads its presence information, other users that are logged on to other servers may subscribe to the user. There should be a way of replicating the presence information between the servers or at least letting other users know where a certain user is logged on. [TBD. How the above problems are solved.] 5. Specifications This section will survey all the active internet drafts and RFCs that are relevant this the SIMPLE based presence and IM architecture. THIS SECTION WILL BE UPDATED SHORTLY AND DOES NOT SHOW THE FULL CURRENT STATE OF SIMPLE SPECS. 5.1 IMPP/CPIM Specifications The IMPP working group was the first group at the IETF to start working on presence and IM protocols. A protocol was not defined by the IMPP group but very important basic documents were produced. Houri, et al. Expires November 30, 2003 [Page 9] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 o RFC 2778 [3] - The basic IETF document for presence and IM. Defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. The goal is to provide a common vocabulary for further work on requirements for protocols and markup for presence and instant messaging. o RFC 2779 [4] - The second basic IETF document for presence and IM. The document defines the requirements for presence and IM service. The requirements include: Scalability, Format, Security etc. o RFC 3859 [11] - Defines common semantics and data formats for presence to facilitate the creation of gateways between presence services. o RFC 3860 [12] - Defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. o RFC 3861 [13] - Presence and instant messaging are defined in RFC 2778 [3]. The Common Profiles for Presence and Instant Messaging define two Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. o RFC 3862[14] - Defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. o RFC 3863[15] - Specifies the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant Presence protocols, and also defines a new media type "application/pidf+xml" to represent the XML MIME entity for PIDF. 5.2 SIMPLE Group Specifications The SIMPLE group defines the extensions required for the SIP protocol in order to be able to implement presence and IM system. Following is a list of the active specifications that are group documents or were submitted to the group. Each specification is followed by a short description of what each specification provides. The documents were divided into several categories. 5.2.1 Presence Following documents define the notification mechanisms and requirements for presence notifications using the SIP protocol. o RFC 3856 [10] - The basic presence document for SIMPLE. Describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Subscriptions and notifications of presence are supported by defining an event Houri, et al. Expires November 30, 2003 [Page 10] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 package within the general SIP event notification framework [7]. o draft-ietf-simple-pres-filter-reqs [20] - Defines a set of structured requirements whereby an event subscriber (client) may specify when notifications are sent to it and what the contents should be. o draft-ietf-simple-event-filter-funct [30] - The document provides the mechanism whereby a watcher can specify the presence event filtering rules, using XML, for the presence agent (PA) and how that PA is to behave when receiving such filter. o draft-ietf-simple-partial-notify [19] - Presents a solution for delivering presence information that aids in reducing and increasing efficiency of devices that have constrains as low data processing capabilities, small display and limited battery power. Other limitations may be caused by the interface between the terminal and the network, i.e. over radio links with high latency and low bandwidth. The solution introduces a new MIME-type "partial notifications" and a Require header extension "partial-notification". 5.2.2 Data Representation and Access Control Following documents define ways to represent, and control access to, presence information stored in a server. o draft-ietf-simple-rpid [31] - Provides a way of richly representing presentity information by adding elements to the basic Presence Information Data Format (PIDF) that provide additional information about the presentity and its contacts. o draft-ietf-simple-partial-pdif-format [32] - A characteristic of the PIDF is that it always carries all the presence information available for the presentity. In some low bandwidth scenarios, this may be overwhelming. This document provides a way of limiting the information that is transported over the network by reporting only the changed parts of the PIDF of a presentity. o draft-ietf-simple-xcap [27] - Defines the eXensible Markup Language (XML) Configuration Access Protocol (XCAP) for enabling a client to read, write, and modify application configuration data stored in a server in XML format. An example of such application configuration data is the access authorization document. o draft-ietf-geopriv-common-policy [33] - Defines a framework for authorization policies used for controlling access to application specific data. This framework combines common location and SIP-presence-specific authorization aspects. o draft-ietf-simple-presence-rules [34] - Authorization rules or policies specify what presence information can be given to which watchers and when. This document defines an XML document format for expressing presence authorization rules; the resulting document can be manipulated by clients using XCAP. Houri, et al. Expires November 30, 2003 [Page 11] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.2.3 Messaging Following documents define requirements and ways to implement a session of messages. Note that the MESSAGE method RFC is a SIP group document [9]. o draft-ietf-simple-message-sessions [35] - The document describes a method of initiating, transmitting and managing a series of instant messages within a session using SIP. Such a media session (MSRP session) is managed by using Session Description Protocol (SDP) offer/answer model carried over SIP. It is established using a SIP INVITE, just as a normal audio or video session would be established. 5.2.4 Lists - Events and Manipulation Traditional presence and IM systems usually enable users to store a list of presences on which they subscribe on the server side. The users logging on to the system do not have to send the list every time they logon. The following documents deal with requirements and models for having parallel possibilities in the SIMPLE protocols. o draft-ietf-simple-event-list [18] - This extension to SIP enables subscribing to a homogeneous collection of event packages. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire collection, and then receive notifications when the state of any of the resources in the collection changes. o draft-ietf-simple-data-req [17] - Provides a framework and requirements for data manipulations for presence. These data manipulations include: presentity list, adding/removing presentities and authorization lists. 5.2.5 Publish SIMPLE users that need to publish their presence document to the presence server were using two types of workrooms: o Using the REGISTER method for uploading the presence document. o Using other protocols for uploading the presence document Following documents describe how it can be done via the SIP protocol while defining a new PUBLISH method o draft-ietf-sip-publish [36] - Describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to create a means, ( referred to as SIP PUBLISH) for publishing event state used within the framework for SIP Event Notification (RFC3265 [7]). The first application of this extension is targeted at the publication of presence information. o draft-ietf-simple-xcap-pidf-manipulation-usage [37] - Describes a usage of XCAP for manipulating the contents of Presence Houri, et al. Expires November 30, 2003 [Page 12] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Information Data Format (PIDF) based presence document in a SIP environment. It picks up where SIP PUBLISH leaves off. SIP PUBLISH allows a single PUA to publish its view of the state of its presentity. Since the PUA is tied to a single device, the published state is device dependent. Also, SIP PUBLISH creates a soft state which has to be refreshed before expiry of its lifespan. Thus SIP PUBLISH is unsuitable for setting overall, device independent, non-transient state. This document describes how XCAP can be used by a client to accomplish these. 5.2.6 Watchers Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. o draft-ietf-simple-winfo-package [23] - Defines the watcher information template-package for the SIP event framework. This event package is a template-package because it can be applied to any event package, including itself. o draft-ietf-simple-winfo-format [22] - Defines an XML format for watcher information for a resource. 5.2.7 SIMPLE/CPIM Related Docs Following documents define a mapping between the IMPP/CPIM documents (Section 5.1) or define ways to extend what is defined in IMPP/CPIM. o draft-ietf-simple-cpim-mapping [16] - Defines how the SIMPLE work group SIP events package for distribution of presence information [10] and the MESSAGE extension for the transport of instant messages map to the abstract CPIM service defined in RFCs 3859-3863, in order to interoperate with other CPIM compliant presence and instant messaging services. o draft-ietf-simple-prescaps-ext [38] - Proposes extensions to Presence Information Data Format (PIDF)[15] to be used within the SIMPLE based presence systems in order to enable building better applications. 5.2.8 Relevant SIP Group Specifications Following SIP RFCs are very relevant to this document: o RFC3261 [5] - The basic document of Session Initiation Protocol (SIP). o RFC3263 [6] - Describes the DNS procedures used by SIP to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. These procedures also allow a server to send a response Houri, et al. Expires November 30, 2003 [Page 13] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 to a backup client if the primary client has failed. o RFC3265 [7] - Provides an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. The event notification mechanisms defined are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. o RFC3428 [9] - Defines the MESSAGE method as an extension to SIP that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of the SIP protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request. 5.2.9 Relevant SIPPING Group Specifications The SIPPING group is responsible for defining requirements for SIP and SIMPLE work. Following is an initial list of SIPPING documents that are relevant to the architecture described in this document. [TBD. Other relevant SIPPING documents?] o draft-niemi-sipping-event-throttle-reqs [24] - The document defines requirements for all event packages to specify a maximum rate at which event notifications are generated by a single notifier. Such a limit is provided in order to reduce network congestion. In addition to the fixed limits introduced by specific event packages, further mechanisms for limiting the rate of event notification are also allowed to be defined by event package specifications but none have been specified so far. This memo discusses the requirements for a throttle mechanism that allows a subscriber to further limit the rate of event notification. o draft-ietf-sipping-conferencing-framework [25] - Defines a framework for how conferencing in SIP can occur. Note that the basic definition of SIP defines dialogs that are two-party by default. The framework in the document describes the overall architecture, terminology, and protocol components needed for multi-party conferencing. o draft-ietf-sipping-cc-conferencing [26] - Defines conferencing call control features for SIP. The document builds on the Conferencing Requirements and Framework documents [25] to define how a tightly coupled SIP conference works. The approach is explored from different user agent (UA) types perspective: conference-unaware, conference-aware and focus UAs. The use of URIs in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. Houri, et al. Expires November 30, 2003 [Page 14] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.3 Basic Functional Model Figure 1-3 shows a generic IMPS system, including SIP/SIMPLE flows. The various deployment types above are specializations of the generic model. Figure 1 shows the general SIP/SIMPLE architcture. All flows are SIP/SIMPLE (author note - the network presence sources is incorrectly drawn in the figure and needs to be fixed). Houri, et al. Expires November 30, 2003 [Page 15] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 +-----------+ |Network | +-----------+ |Presence | | AAA | |Sources | | | +----+------+ +-----+-----+ | | +------+ +------------+--------------------------+ | | | | | | | | +-----------+ +---+--+----+ +-----+-----+ +-------+ +-----+-----+ |Messaging | |Presence | |Conference +---+Message+--+IM | |Gateway | |Application| |Server | |Store | |Application| +-----------+ +----|------+ +-------+---+ +-------+ +-----+-----+ | | | | | | | | | +--------------+ | +-------------------+ +---------------------------+ | | | | | | | +-----------+ +-+-+-+----+-+ | End User | |Home Serving| | | |Proxy | +------+----+ +---+--+----++ | | | | | | | | | +----------------+ | +-------------+ | | | | +------+--+--+ +--------+-------+ +----+----+ | Edge | |Service Provider| |Transport| | Proxy | |Edge Proxy | |Proxy | +------------+ +----------------+ +---------+ Figure 3 Houri, et al. Expires November 30, 2003 [Page 16] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Figure x shows the functional architecture for group managment. +-----------+ | AAA | | | +-----+-----+ | +----------------+-----------------+ | | | | | | +-----+-----+ +-----+-----+ +-----+-----+ |Presence | |Conference | |IM | |Application| |Server | |Application| +----+------+ +----+------+ +-----+-----+ | | | | | | +--------------+ | +---------------+ | | | | | | +-----------+ +---+-+--+---+ | End User |----------|Group Mgt | | | |Directory | +-----------+ +------------+ Figure 4 Houri, et al. Expires November 30, 2003 [Page 17] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 The following figure shows the functional architecture for users accessing deferred messages. +-----------+ | AAA | | | +-----+-----+ | | | | +-----+-----+ | Message | | Store | +-----+-----+ | | | | +-----+-----+ | End User | | | +-----------+ Figure 5 The elements of the sytem are in the above figures are: o End point: nodes that support the IMPS instant messaging and presence. o Home Serving Proxy (HSP): a server that supports registrar, proxy, and application interface functions. o Transport Proxy: an IMPS node that provides transport of IMPS control messages but is not directly servicing the actual requests of the IMPS control protocol. The proxy may route IMPS control messages to the HSP to/from the end point, or to/from other HSPs. o Edge Proxy: a specialized proxy that many architectures use as an intermediary between the end point and the fixed network, often provides (SIP/SIMPLE) compression, authentication, and admission control function. Houri, et al. Expires November 30, 2003 [Page 18] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 o Service Provider Edge Proxy: a specialized proxy used as an intermediary from the home service provider to other service providers or external systems. o Network Presence Sources: Source of presence information not published directly by user equipment. Examples might include adapters for HLR registration state, geo-location systems, and the like. o AAA: Performs authentication, authorization, and accounting functions on behalf of the Radio Network and IP Access and SIP entities. Only one monolithic AAA server is depicted; but it may be that proxy AAA servers are involved to proxy AAA to an AAA server that can authenticate the user, i.e., AAA Proxies are not shown in the figures. Furthermore, the AAA server that authenticates the user is not necessarily the AAA server that authorizes various services. (???what does that mean in a real system???) o Messaging Conference Server: Provides messaging sessions by duplicating messages received from one end point to all the endpoints of a conference session. o Message Store: Provides persistent storage of messages when users are not available (e.g., the user is in a tunnel) or when messages must be archived. o Instant Messaging Application: Supports the delivery of pager mode messages to the message store for users that are not currently available; may also archive messages for later retrieval. o Presence Application: Supports presence subscription, notification, and publication. o Group Management Directory: Stores the lists of users associated with groups. o Gateway: will note be specified in this document because the gateway interacts with systems not named nor specified herein. 5.4 Basic Flows 5.4.1 Registration This section states requirements for a registration function that associates an address of record with an IP address that has been assigned to a user endpoint. An example of an address of record is one of the legal formats of a URI [RFC 2396]. The following example assumes that the user has gained access to a access network and has been assigned an IP address. The user must perform IMPS registration to associate the assigned IP address with their address of record. This registration also indicates to the network the instant message capabilities that are supported by the end point. Figure 6 shows the message exchange. Houri, et al. Expires November 30, 2003 [Page 19] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 The HSP utilizes HAAA of the end point to authenticate and authorize the user during registration. After completion of registration, the home server stores the end point's address and is able to send messages to the endpoint. The registration does not authorize any service nor does it indicate to end point the services supported by the server. Refer to Section 8 for a discussion on registration authentication. Houri, et al. Expires November 30, 2003 [Page 20] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Registration EP HSP AAA Watcher | | | | | (1) Register | | | | Request | | | |---------------->| | | | | | | | | (2) AAA | | | | Request | | | |-------------->| | | | | | | | (3) AAA | | | | Response | | | |<--------------| | | | | | | (4) Register | | | | Response | | | |<----------------| Registrar | | | | Stores Contact| | | | Address | | | |--------+ | | | | | | | | | | | | | |<-------+ | | | | | | | | | | | | Send | | | | registration | | | | messages to | | | | watcher | | | |------------------------------>| | | | | Figure 6 1. The end point sends a Registration Request to the HSP. 2. The HSP sends an AAA Request to the HAAA server. 3. The HAAA server sends an AAA Response to the HSP server. 4. The HSP acknowledges the Registration Request to the end point with a Register Response. 5. The HSP stores the new contact in its registration database. 6. if there are any registration watchers, the HSP issues registration event notifications to them. 5.4.2 Sending and Receiving Messages Instant messaging shall support two different messaging modes: Houri, et al. Expires November 30, 2003 [Page 21] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Pager mode: Each message is self-contained in one instant messaging request message. This mode is most useful for short sequences of messages, for small messages, and for messages sent to few users or to a static group of users. (See RFC 3228 for more information.) Session mode. A set of messages is carried via some transport protocol; this protocol is not SIP. The function of IMPS in this case is to establish a messaging session between the interested parties. The choice of the transport protocol to support a messaging session is ???tbd??. From a user perspective, session mode is like a chat room. This mode is most useful for extended sequences of messages, for large messages, for messages sent to a large of number of users, or to a group of users that may change over the life of the message. For short messages, especially in a wireless environment, pager mode is more spectrally efficient and represents lower latency to the user that establishing separate transport sessions. This transport session is independent of any transport involved in the transport of IMPS control messages. If the user plans on sending many messages, or large messages, pager-mode is less efficient in comparison to session mode. It is possible that a message contains a reference (e.g., a URL) that points to a large message instead of containing the message itself. This section first addresses pager mode and then session mode messaging. 5.4.2.1 Sending a Pager Mode Message The end point sends a pager-mode request to the sender Home Service Proxy (HSP). This may occur via intermediary IMPS proxies if necessary. The pager mode request contains the logical name of the desired target user or group. The body of the pager-mode request contains a message encapsulated in the form of a valid MIME format, which includes text, general multi media such as audio, still photos, or video. MIME is the widely used format for email attachments. The sender HSP receives the pager-mode request and queries the user's HAAA to verify that the user is allowed to send a message through this proxy. The authorization response from the HAAA includes transmission policy logic for the user. The authorization can be cached and details are left to ???what???, i.e., it is not necessary for the HSP to check the AAA for the user for each pager mode request. Authentication and Authorization mechanisms are discussed in Section ?. The sender HSP then executes user transmission policy logic e.g., expands the logical name of the target to which the message is being sent, expands nicknames to logical names, etc. The Houri, et al. Expires November 30, 2003 [Page 22] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 HSP sends the request to the sender IM Application, which verifies the user is authorized for service; if so logs the message on behalf of the user. As in the case of the HSP, the authorization can be cached and details are left to ???what???. In the typical case, the sender HSP then determines if the pager mode request is targeted to a user in the domain of the sender HSP. If this is the case, the HSP sends the request to the target user's IM Application. That IM Application logs the pager mode request and proxies it to the sender HSP, which then delivers the requst to the target user. The receiver endpoint responds with an acknowledge response to the sender HSP, which proxies the response to the sender endpoint. If the message is not targeted to a user in the sender HSP domain, the sender HSP then proxies the request onward via intermediary IMPS proxies towards the destination. The message is delivered to the receiver's HSP, which proxies the pager mode message to the IM Application that supports the target user, as explained in Section ?. The receiver's HSP responds with an acknowledge response to the sender HSP, which proxies it to the sending user. Figure ? shows a message exchange associated assuming a sender HSP up to the point of delivery to the receiver HSP. Figure ? then completes the scenario. If some intermediary proxy in the chain at any point is unable to forward the message, that proxy returns an appropriate error response. It is possible that the endpoint could be able to determine the receiver HSP without using the sending HSP; however, this would bypass the sender IM Application. Houri, et al. Expires November 30, 2003 [Page 23] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 End Sender IM HAAA Receiver Point HSP Application HSP | | | | | | (1) Pager- | | | | | Mode Request | | | | |------------->| | | | | | (2) AAA | | | | | Request | | | | |-------------------------->| | | | | | | | | | | | | | (3) AAA | | | | | Response | | | | |<--------------------------| | | | | | | | | (4) Pager- | | | | | Mode Request| | | | |------------>| | | | | | (5) AAA | | | | | Request | | | | |------------>| | | | | | | | | | (6) AAA | | | | | Response | | | | |<------------| | | | | | | | | |(7) Pager- | | | | |Mode Response| | | | |<------------| | | | | | | | | (8) Pager- | | | | | Mode Request| | | | |--------------------------------------->| | | | | | | | | | | | |(9) Pager- | | | | |Mode Response| | | | |<---------------------------------------- | | | | | | (10) Pager | | | | | Mode Response| | | | |<-------------| | | | | | | | | Figure 7 Houri, et al. Expires November 30, 2003 [Page 24] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 1. The endpoint station sends a pager mode request. 2. The sender HSP authenticates the user's request by sending an AAA request to the user's HAAA. 3. The HAAA authenticates and authorizes the user and sends an AAA response to the sender HSP. 4. The sender HSP proxies the request to the sender IM Application. 5. The IM Application authenticates and authorizes the user's request by sending an AAA request to the user's HAAA. 6. The HAAA authenticates and authorizes the user and sends an AAA response to the IM Application. 7. The sender IM Application archives the message and proxies the request back to the sender HSP. 8. The sender HSP proxies the request to the receiver HSP. 9. The receiver's HSP proxies a request response to the sender HSP. 10. The sender HSP sends a request response to the sending endpoint. If the user plans on sending messages to a group, the user or some other party must have previously created the desired group. A group is created using list management as described below (see section 6.3). In this case the pager-mode request is sent to the HSP serving the group. The list's logical name is the target name of the pager mode request. There are two alternative approaches outlined herein for the delivery of the pager mode request to a group: o The HSP serving the list sends the pager mode request to all the recipients per the list; recipients then acknowledge the pager mode request and one acknowledge is received per received recipient. It is possible the members of the lists are additional groups themselves. for the case of wireless use, a sending endpoint (mobile station) receives one acknowledge from all physical recipients, which may be a spectral burden if the final expansion of the list is very large. o The HSP serving the list verifies it can expand the list, sends one acknowledge to the entity that sent the pager mode request, which can be another HSP or the endpoint, and creates a new pager mode request to each of the recipients on the list. The sending endpoint only receives one acknowledge, which is spectrally more efficient. Security associated with sending a pager mode request is discussed in the section ? 5.4.2.2 Receiving a Pager Mode Message The above scenario shows a user sending a pager-mode request to a receiver's HSP. This section shows the reception process for the page-mode from the point of reception by the receiver's HSP. If the pager-mode request was sent to many receivers, they will all behave Houri, et al. Expires November 30, 2003 [Page 25] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 with the reception process below. A message targeted to the user's address of record is delivered to that user's HSP (the receiver HSP). The receiver HSP recognizes that the address of record is served by this HSP, i.e., is in the administrative domain of this HSP. The receiver HSP verifies that the receiving user is authorized to receive message through this HSP by sending an AAA request to the HAAA of the targeted user. The HAAA of the target user authorizes the receiver's HSP to deliver the message in an AAA Response and provides a reception policy to the receiver's HSP. The authorization can be cached and details are tbd, i.e., it is not necessary for the HSP to check the AAA for the user for each pager mode request. Authentication and Authorization is discussed in Section ???. The receiver's HSP then executes routing or filtering logic associated with this user (user policy), and acts accordingly, e.g., discards the message, stores it for later delivery, etc. In the typical case the user is authorized and willing to receive the message and has previously registered a contact address. The receiver HSP then proxies the pager-mode request to the receiver's IP application, which verifies the user is authorized for service, and proxies an acknowledge back. As in the case of the HSP, the authorization can be cached and details tbd. The receiver HSP then consults its registration table for that logical name, and then finds the IP address of the endpoint. The receiver HSP then sends the request to the associated IP address. The message is received at the endpoint and the endpoint responds with an acknowledge response, which is routed via proxies to the entity that sent the pager-mode request. From the previous section we see that that entity could be the endpoint itself that is the origin of the pager-mode request, or other sender HSPs that expanded the target list. (editor note: would the response have to pass via the sender HSP?) Lastly, the receiving endpoint alerts its user upon reception of the pager-mode request. See Figure ?? for scenario example. Because wireless resources are scarce and the user may not desire messages from just anyone, the user may populate a policy in the HSP that controls how incoming messages will be processed. For example, "unwanted" messages may be discarded, allowing the user to avoid charges associated with such messages. (See section ???) Houri, et al. Expires November 30, 2003 [Page 26] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Sender Receiver IM HAAA End HSP HSP Application Point | | | | | | (1) Pager- | | | | | Mode Request | | | | |------------->| | | | | | (2) AAA | | | | | Request | | | | |-------------------------->| | | | | | | | | | | | | | (3) AAA | | | | | Response | | | | |<--------------------------| | | | | | | | | (4) Pager- | | | | | Mode Request| | | | |------------>| | | | | | (5) AAA | | | | | Request | | | | |------------>| | | | | | | | | | (6) AAA | | | | | Response | | | | |<------------| | | | | | | | | |(7) Pager- | | | | |Mode Response| | | | |<------------| | | | | | | | | (8) Pager- | | | | | Mode Request| | | | |--------------------------------------->| | | | | | | | | | | | |(9) Pager- | | | | |Mode Response| | | | |<---------------------------------------| | | | | | | (10) Pager | | | | | Mode Response| | | | |<-------------| | | | | | | | | Figure 8 Houri, et al. Expires November 30, 2003 [Page 27] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 1. The sender HSP sends a pager mode request to the receiver HSP. 2. The receiver HSP veifies that the user is authorized to recieve such requests by sending an AAA request to the HAAA of the target user. 3. The HAAA authenticates and authorizes the user and sends an AAA response to the receiver HSP. 4. The receiver HSP proxies the request to the receiver IM Application. 5. The IM Application authenticates and authorizes the user's request by sending an AAA request to the user's HAAA. 6. The user's HAAA authenticates and authorizes the user and sends an AAA response to the IM Application. 7. The receiver IM Application archives the message and proxies the request back to the receiver HSP. 8. The HAAA sends an AAA response to the receiver HSP that authorizes the pager-mode request and that may contain a reception policy for the target user. 9. After possibly screening the request based on some policy, the receiver HSP sends the request to the endpoint. 10. The endpoint sends a request response to the receiver HSP. 11. The receiver HSP sends the request response to the sender HSP. 5.4.2.3 Deferred Message Delivery to IM Application It may be in Figure 6 that the receiver endpoint is not avaible. In this case, the receiver IM Application will archive the message at the message store and arrange for delivery later. When the receiver HSP receives the pager mode request from the sender HSP, it then sends the pager-mode request to the receiver IM Application. Pager-mode messages are delivered to the recipient's IM application, which applies local policy in determining what to do with that message. In the typical case, the policy will be to forward the message to the registered contact if there is one, and to store the message for future delivery if there is no registered contact. Another reasonable policy might be to reject the message if there are no registered contacts for the recipient. If the message is stored for deferred delivery, the IM application may (based on policy) indicate in its response to the sender that delivery of the message has been deferred. Th The IM Application also logs the message. The following call flow shows the delivery of a pager-mode message to an IM application, and the storing of that message by the IM application for deferred delivery to the intended recipient. The actual delivery of the message to the user will occur at some future time, and is addressed in a separate call flow in the following section. Houri, et al. Expires November 30, 2003 [Page 28] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Sender Receiver IM HAAA Message HSP HSP Application Store | | | | | | (1) Pager- | | | | | Mode Request | | | | |------------->| | | | | | (2) AAA | | | | | Request | | | | |-------------------------->| | | | | | | | | | | | | | (3) AAA | | | | | Response | | | | |<--------------------------| | | | | | | | | (4) Pager- | | | | | Mode Request| | | | |------------>| | | | | | (5) Store | | | | | Message | | | | |------------------------->| | | | | | | | | | | | | |(6) Acknowledge | | | |<-------------------------| | | | | | | |(7) Pager- | | | | |Mode Response| | | | |<------------| | | | | | | | | (8) Pager | | | | | Mode Response| | | | |<-------------| | | | | | | | | Figure 9 1. The sender HSP sends a pager mode request to the receiver HSP. 2. The receiver HSP verifies that the user is authorized to receive such requests by sending an AAA request to the HAAA of the target user. 3. The receiver HSP proxies the request to the receiver IM Application. 4. The receiver IM Application archives the message in the message store. 5. The message store acknowledges successful storage to the IM Application. Houri, et al. Expires November 30, 2003 [Page 29] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 6. The IM Application sends a request response to the receiver HSP. 7. The receiver HSP sends a request response to the sender HSP. 5.4.2.4 Delivery of Deferred Message to User In the previous section, the IM Application archived the message in the message store. At a later point in time, the user becomes available to receive instant messages. The IM application learns the user is available when it receives a presence notification that indicates the user is available to receive deferred instant messages. Houri, et al. Expires November 30, 2003 [Page 30] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Presence Receiver IM HAAA Message Application HSP Application Store | | | | | | (1) available| | | | | notification | | | | |------------->| | | | | |(2) available| | | | |notification | | | | |------------>| | | | | | | | | | | | | | | | | | | | | | | | |<--------------------------| | | | | | | | | (4) Pager- | | | | | Mode Request| | | | |------------>| | | | | | (5) Store | | | | | Message | | | | |------------------------->| | | | | | | | | | | | | |(6) Acknowledge | | | |<-------------------------| | | | | | | |(7) Pager- | | | | |Mode Response| | | | |<------------| | | | | | | | | (8) Pager | | | | | Mode Response| | | | |<-------------| | | | | | | | | Figure 10 1. The IM Application sends a message retrieve request to the message store. 2. The message store responds with deferred messages. 3. The IM Application sends one pager-mode request to the receiver HSP for each message returned by the message store. 4. The receiver HSP sends a pager-mode request to the MS. 5. The MS sends a pager-mode response back to the receiver HSP. 6. The receiver HSP sends a pager-mode response back to the IM Application Houri, et al. Expires November 30, 2003 [Page 31] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.4.2.5 Logging Pager-Mode Messages Logging pager-mode messages is outside the scope of this document. 5.4.2.6 Establishing a Point-to-Point Messaging Session There are two options for session based message transport: o Direct connections between parties; for two users this can be point-to-point, otherwise multicast is assumed. o Connections via a network based conference-like function that duplicates messages. The endpoint sends a messaging session request to its Home Service Proxy (HSP). This messaging session invitation does not actuate the transport session establishment itself; rather it serves to invite desired entities to establish the transport protocol instance that will intrinsically support message transport. The messaging session request indicates a messaging session of some type, e.g., CPIM/TCP, XMPP, etc., that is desired. The request contains the logical name of the desired target user or group as well as information describing the message transport session to be established. The HSP receives this messaging session request and sends an authentication request to the HAAA of the user to verify that the user is authorized to such a request through this proxy. The HAAA responds with an AAA response, which contains a transmission policy. The HSP then executes user transmission policy logic, e.g., expands the logical name, expands nicknames associated with the logical name, etc. In the typical case, the HSP determines if the transport establish request is targeted to a user in the domain of the HSP. If so the HSP delivers the messaging session request to the target user. If the messaging session request is not targeted to a user in the domain of the HSP, the HSP then proxies the request onward towards the receiver HSP of the target user via intermediary proxies. If some proxy in the chain is unable to forward the messaging session request, that proxy returns an appropriate error response. Otherwise, the request is delivered to the receiver HSP, which then sends an AAA to the target user's HAAA to request authorization for the messaging session request. The HAAA responds with an AAA response. The receiver HSP proxies the messaging session request to the target user. The endpoint alerts the user so it can determine whether to accept the messaging session request or not. If the target user accepts the request, it sends a messaging session response to its HSP, which proxies the messaging session response via the intermediary proxies to the sender's HSP. At this point, the endpoint and the terminating entity execute the desired transport Houri, et al. Expires November 30, 2003 [Page 32] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 protocol establish that was identified by the messaging session request. Houri, et al. Expires November 30, 2003 [Page 33] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Figure 9 provides an example flow of a point-to-point messaging session establishment. End Sender Receiver Sender Receiver End Point HSP HSP HAAA HAAA Point | | | | | | |(1) messaging | | | | |session | | | | | |request | | | | | | | (2) AAA | | | | | | Request | | | | | |------------------------->| | | | | | | | | | | | | | | | | (3) AAA | | | | | | Response | | | | | |<-------------------------| | | | | | | | | | |(4) messaging| | | | | |session | | | | | |request | | | | | |------------>| (5) AAA | | | | | | Request | | | | | |----------------------->| | | | | | | | | | | (6) AAA | | | | | | Response | | | | | |<-----------------------| | | | |(7) messaging | | | | |session | | | | | |request | | | | | |---------------------------------->| | | |(8) messaging | | | | |session | | | | | |response | | | | | |<----------------------------------| | | | | | | | |(9) messaging| | | | | |session | | | | | |response | | | | | |<------------| | | | |(10) messaging | | | | |session | | | | | |response | | | | | |<-----------| | | | | | | | | | | Houri, et al. Expires November 30, 2003 [Page 34] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Figure 11 1. The endpoint sends a messaging session invitation to the senders HSP. 2. The sender HSP authenticates the user's request and verifies the user is authorized to use that HSP. The sender HSP sends the request to the receiver HSP. 3. The receiver HSP sends the request to the receiver. 4. The receiver sends a message session response to the receiver HSP. 5. The receiver HSP sends a message session response to the sender HSP. 6. The sender HSP sends a message session response to the endpoint. 7. The endpoint sends a message session acknowledge to the target. 8. The two endpoints establish a messaging session. 5.4.2.7 Sending a Message Within a Messaging Session When the messaging session as establishment is complete, the user may send messages using it. This is shown in Figure ??. If a network based conference server is involved, it will copy the messages and forward them via the transport connection. Houri, et al. Expires November 30, 2003 [Page 35] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 | | | | | (1) Messaging Session | | Establishment Complete | |<------------------------>| | | | | | | | | | (2) Message over | | Messaging Session | |<------------------------>| | | | | | | Figure 12 1. The messaging session is established, which may be between two users or between each user and the conference server. 2. The message is sent over the messaging session. Houri, et al. Expires November 30, 2003 [Page 36] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.4.2.8 Receiving a Message Within a Messaging Session When the transport session as negotiated by SIP is complete, a user may receive messages via the transport session as shown below. | | | | | (1) Messaging Session | | Establishment Complete | |<------------------------>| | | | | | | | | | (2) Message over | | Messaging Session | |<------------------------>| | | | | | | Figure 13 1. The messaging session is established, which may be between two users or between each user and the instant messaging application. 2. The message is received over the messaging session. 5.4.2.9 Adding a Member to an Established Session This document specifies use of conference control procedures to add a member to an established session. The conference control design team of the SIPPING WG of the IETF is designing these procedures. Two cases are considered: o Adding a third user point-to-point session. Transition a two-user session to a multiparty conference and add a third part to the conference. o Adding a user to a multiparty session, i.e., a session with more than two current users. 5.4.2.10 Transitioning a Two Party Session to a Multiparty Conference and Adding a Third Participant Houri, et al. Expires November 30, 2003 [Page 37] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 End End Conference AAA Point A Point B Server | | | | | | | | | (1) pt2pt | | | | Session | | | | Established | | | |<-------------->| | | | | | | | (2) Conference | | | | Session | | | | Request | | | |-------------------------------->| | | | | (3) AAA | | | | Request | | | |-------------->| | | | | | | | (4) AAA | | | | Request | |(5) Conference | |<--------------| |Session Response| | | |-------------------------------->| | | | | | | | | | | (6) Conference | | | | Session Ack | | | |<--------------------------------| | | | | | | | | | | (7) Replace | | | | Request | | | |--------------->| | | | | | | | (8) Replace | | | | Response | | | |<---------------| | | | | | | | (9) Release | | | | Request | | | |<---------------| | | | | | | | (10) Release | | | | Response | | | |--------------->| | | | | | | Figure 14 Houri, et al. Expires November 30, 2003 [Page 38] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 End End Conference End Point A Point B Server Point C | | | | | | | | | |(11) Messaging | | | |Session Request | | | |--------------->| | | | | | | |(12) Messaging | | | |Session Response| | | |<---------------| | | | | | | |(13) Messaging | | | |Session Ack | | | |--------------->| | | (14) Notify | | | | Request | | | |<---------------| | | | | | | | (15) Notify | | | | Response | | | |--------------->| | | | | | | | (16) Join | | | | Request | | | |------------------------------------------------->| | | | | | (17) Join | | | | Response | | | |<-------------------------------------------------| | | |(18) Messaging | | | |Session Request | | | |<-------------- | | | | | | | |(19) Messaging | | | |Session Response| | | |--------------->| | | | | | | | (20) Messaging | | | | Session Ack | | | |<---------------| | | | | | | | | Figure 15 Houri, et al. Expires November 30, 2003 [Page 39] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 End End Conference End Point A Point B Server Point C | | | | | | | | | | | | | (21) pt2pt | | | | Messaging | | | | Session | | | |<------------------------------------------------>| | | (22) pt2pt | | | | Messaging | | | | Session | (23) pt2pt | | |<-------------->| Messaging | | | | Session | | | |<-------------->| | | | | | | | | | | | | Figure 16 1. A and B have a point-to-point messaging session. A now determines it wishes to add C to the messaging session. 2. A sends a conference session request to the conference server. This informs the conference server of the identity of the conference to be established. Later the actual messaging transport session is initialized. The method by which A finds the conference server is not shown in this flow. 3. The conference server sends an AAA request to the HAAA of the requesting user to verify that user is authorized to use this conference server. 4. The HAAA sends an AAA response to the requesting user. 5. The conference server responds conference session response. 6. A sends a messaging session acknowledge to the conference server. 7. A sends a replace request to B that requests that B release the point-to-point messaging session with A and replace with a point-to-point messaging session to a conference server. 8. B sends a replace response to A. 9. B sends a release request to A. 10. A responds with a release request response. 11. B sends a messaging session request to the conference server. 12. The conference server sends a messaging session response to B. 13. B sends a messaging session acknowledge to the conference server. 14. B sends a notify request to inform A that it has replaced the connection to A with one to the conference server. Houri, et al. Expires November 30, 2003 [Page 40] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 15. A sends a notify response to B. 16. A asks C to join the conference. The endpoint alerts user C and user C makes the decision to join the session. 17. C sends a response to A. 18. C sends a messaging session requst to the conference server. 19. The conference server tells C it is allowed to join the conference. 20. C acknowledges that response. 21. A and the conference server establish a point-to-point messaging session. 22. B and the conference server establish a point-to-point messaging session. 23. C and the conference server establish a point-to-point messaging session. 5.4.2.11 Adding a User to a Multiparty Session Figure 13 exactly depicts this case, i.e., substitute any other user being for user C in that figure. Houri, et al. Expires November 30, 2003 [Page 41] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.4.2.12 Leaving a Messaging Session This document specifies use of conference control procedures to delete a member to an established session. The conference control design team of the SIPPING WG of the IETF is designing these procedures. The following shows B dropping off the established conference session. End Conference Point B Server | | | | | (1) Release | | Request | |------------------------->| | | | | | (2) Release | | Response | |<-------------------------| | | | | | (3) Quit | | Messaging Session | |<------------------------>| | | | | Figure 17 1. B sends a Release Request 2. The conference server sends a Release Response to B. 3. B and the conference server terminate the messaging transport session. 5.4.2.13 Logging Messaging Session Messages Logging messages from a messaging session is outside the scope of the architecture. 5.4.3 Group Operations A group is a nested collection of addresses or identifiers such as an address or record. A group is identified by a single address. Various operations can be performed on a group. The semantics of the Houri, et al. Expires November 30, 2003 [Page 42] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 operations performed on a group (as opposed to being performed on an individual address) depend on, and should be defined by, each operation. This implies a need for usual group operations such as creation, modification, retrieval, and deletion lists. When the endpoint desires to perform instant messaging (presence) list operations, such as creating or deleting the list, or modifying an existing list, the endpoint establishes security association and then a list management session with its HSP. The endpoint then executes the desired list operation using the list management session. The method by which the endpoint is provisioned with a URL of the list server is outside the scope of this document. OMA has specified IP Provisioning Over the Air and such methods should be adopted or extended if necessary for this application. The following operations are supported: o Add, with a list of URIs to add to the designated list. o Delete, with a list of URIs to delete from the designated list. o A list of existing URIs on the designated list that are to be overwritten with new attributes. o Retrieve the designated list. o Only one list can be affected in a single transaction. 5.4.3.1 Creating a Group Users or service providers can create a group in more than one way. The list management session requires and authentication of the user and an authorization that the user is permitted to create lists at this HSP. A security session establishes privacy of all list management transactions, to be discussed in section 1.1.16.5.2. The user sends a create group request, which is acknowledged, to install the list on the Directory. After the transaction is complete, the security and list management session are terminated. The AAA server could be the Home AAA server of the user or could be an AAA server local to the Directory. Houri, et al. Expires November 30, 2003 [Page 43] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 End Point A Directory AAA | | | | | | | (1) Create | | | Group | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------| | (4) Create | | | Group Response | | |<-------------------------| | | | | | | | Figure 18 1. A user sends a create group request to the directory. 2. The directory sends an AAA request to the AAA of the requesting user to verify the user is authorized to create a group. 3. The AAA sends an AAA response that authorizes the user to create the group. 4. The user creates the group. 5. The directory acknowledges the creation of the group. Houri, et al. Expires November 30, 2003 [Page 44] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.4.3.2 Deleting a Group Authorized entities may desire to delete group lists. End Point A Directory AAA | | | | | | | (1) Delete | | | Group | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------- | (4) Delete | | | Group Response | | |<------------------------>| | | | | | | | Figure 19 1. A user sends a delete group request to the directory. 2. The directory sends an AAA request to the AAA of the requesting user to verify the user is authorized to delete the group. 3. The AAA sends an AAA response that authorizes the user to delete the group. 4. The user creates the group. 5. The directory acknowledges the deletion of the group by sending a group delete response. Houri, et al. Expires November 30, 2003 [Page 45] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.4.3.3 Modifying a Group Authorized entities may desire to modify group lists. End Point A Directory AAA | | | | | | | (1) Modify | | | Group | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------- | (4) Modify | | | Group Response | | |<------------------------>| | | | | | | | Figure 20 1. A user sends a modify group request to the directory. 2. The directory sends an AAA request to the AAA of the requesting user to verify the user is authorized to modify the group. 3. The AAA sends an AAA response that authorizes the user to modify the group. 4. The directory acknowledges the modification of the group by sending a group modify response. Houri, et al. Expires November 30, 2003 [Page 46] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.4.3.4 Retrieving a Group Authorized entities may desire to retrieve group lists. End Point A Directory AAA | | | | | | | (1) Retrieve | | | Group | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------- | (4) Retrieve | | | Group Response | | |<------------------------>| | | | | | | | Figure 21 1. A user sends a retrieve group request to the directory. 2. The directory sends an AAA request to the AAA of the requesting user to verify the user is authorized to modify the group. 3. The AAA sends an AAA response that authorizes the user to modify the group. 4. The directory sends the group data to the user. Houri, et al. Expires November 30, 2003 [Page 47] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.4.3.5 Publishing User Management Policy As stated above, wireless resources are often scarce and the user may not desire to receive messages from just anyone, the user may populate a policy in the HSP that controls how incoming messages will be processed. End Point A Directory AAA | | | | | | | (1) edit Reception | | | Policy | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------- | (4) edit Reception | | | Response | | |<------------------------>| | | | | | | | Figure 22 1. The endpoint establishes a policy management session with the presence application. 2. The presence application verifies the user is authorized to modify the policy by sending an AAA request to the AAA server. 3. The AAA responds to the presence application with an authorization for the user. 4. The endpoint edits the reception policy. 5. The endpoint terminates the policy management session. Houri, et al. Expires November 30, 2003 [Page 48] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.4.4 Access Deferred Messages An end use may wish to access deferred messages. In order to ensure that the unauthorized entities do not access the user's deferred messages, the IM Application authenticates and authorizes the user to access the messages before sending a request to the message store. End Message Point A Directory AAA Store | | | | | | | | | (1) Retrieve | | | | Message Request | | | |------------------>| | | | | (2) AAA Request | | | |---------------->| | | | | | | | | | | |(3) AAA Response | | | |<----------------| | | | | | | | | | | | | | |< | (4) Retrieve | | | | Message Request | | | |--------------------------------->| | | | | | | (5) Retrieve | | | | Message Response| | | |<---------------------------------| | (6) Retrieve | | | | Message Response | | | |<------------------| | | | | | | Figure 23 1. The user sends a request to the IM Application to retrieve deferred messages. 2. The IM Application authenticates and authorizes the user by sending an AAA Request to the user's HAAA. 3. The HAAA authenticates and authorizes the user and sends an AAA Response to the IM Application authorizing the user to access the deferred messages. Houri, et al. Expires November 30, 2003 [Page 49] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 4. The IM Application requests the messages by sending a message retrieve request to the Message Store. 5. The Message Store sends the messages to the IM Application. 6. The IM Application sends the messages to the user. 5.4.5 Presence Operations Houri, et al. Expires November 30, 2003 [Page 50] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.4.5.1 Publishing Presence The endpoint sends a presence publish request to the presence application via the HSP as in the Figure 20Figure 17. This request contains the new presence document to publish . The presence application authenticates the user and verifies the user is authorized to store the event at this proxy. End Presence Point A Application AAA | | | | | | | (1) Presence | | | Publish Request | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------| | (4) Presence | | | Publish Response | | |<-------------------------| | | | | | | | Figure 24 1. The endpoint sends a presence publish request to the presence application. 2. The presence application sends an AAA request to the AAA server to authorize the MS to publish a presence document to this application. 3. The AAA sends an AAA response to the presence application authorizing the presence publish request. 4. The presence application sends a presence publish response to the endpoint. Houri, et al. Expires November 30, 2003 [Page 51] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.4.5.2 Subscribing to Presence (or a Presence List) The endpoint sends a presence subscription request to the presence application of the presence application that owns the presence state of entity referenced in the logical address. This is shown in Figure 21Figure 18. The user may be subscribing to events for a specific user or a list of users. End Presence Point A Application AAA | | | | | | | (1) Presence | | | Subscribe Request | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------| | (4)Presence | | | Subscribe Response | | |<-------------------------| | | | | | (5) Presence | | | Notification Response | | |<-------------------------| | | | | | | | Figure 25 1. The endpoint sends a presence subscribe request to the presence application that supports the desired entity. 2. The presence application sends an AAA request to the AAA server to authorize the requesting user to subcribe to the presence of the presentity. 3. The AAA server sends an AAA response to the presence application authorizing the presence subscription request. 4. The presence application sends a presence subscription response to the endpoint. 5. The presence application sends a presence notification response to the endpoint. Houri, et al. Expires November 30, 2003 [Page 52] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.4.5.3 Receiving a Presence Notification An endpoint that has previously subscribed to an event as above. The endpoint receives a notification from the presence application of the presentity or presentity list as follows according to the subscription parameters when the subscription was made. " End Presence Point A Application | | | | | (1) Presence | | Notify Request | |<-------------------------| | | | | | | | (2) Presence | | Notify Response | |<-------------------------| | | | | Figure 26 1. The endpoint receives a presence notification request. 2. The endpoint sends a presence notification response. Houri, et al. Expires November 30, 2003 [Page 53] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.4.5.4 Querying Presence End Presence Point A Application AAA | | | | | | | (1) Presence | | | Query Request | | |------------------------->| | | | (2) AAA Request | | |-------------------------->| | | | | | | | | | | | (3) AAA Response | | |<--------------------------| | (4) Presence | | | Query Response | | |<-------------------------| | | | | | | | Figure 27 1. The endpoint sends a presence query request to the presence application that supports the desired entity. 2. The presence application sends an AAA request to the AAA server to authorize the requesting user to query the presence of the presentity. 3. The HAAA sends an AAA response to the presence application authorizing the presence query request. 4. The presence application sends a presence query response to the endpoint. 5.5 Security and Privacy Issues in IM/Presence Architecture As requests travel from clients to servers, it is important that the integrity of the message be safeguarded. At the server, the identity of the client must first be authenticated before authorizing its request. Integrity of the responses sent by the server must also be safeguarded. Also, the privacy rights of the clients must not be violated; the clients should be given the ability to set accessibility controls (authorization) to information it owns. On top of all this, the network and framework must be protected from attacks (e.g. denial-of-service (DOS), worms or viruses) launched Houri, et al. Expires November 30, 2003 [Page 54] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 from the network level, or from the application itself. Security often refers to mechanisms used to provide data confidentiality, integrity and authentication. This section gives a brief overview of the various aspects of security and privacy solutions available for use in a SIP based IM/Presence framework. 5.5.1 Authentication This allows the system to verify "who" is requesting it for service. The IM system depends on mechanism built into the underlying SIP protocol to authenticate users. SIP provides a stateless challenge-based mechanism for authentication that is itself based on authentication in HTTP. A proxy or UA that receives a request may challenge the initiator of the request to provide assurance of its identity. After the originator has been successfully identified, the recipient of the request should then carry out the Authorization process to ascertain if the requestor is authorized to make the request in question, or not. HTTP/1.0 offers two access authentication schemes: Basic and Digest. Both schemes depend on verifying that both parties to a communication know a shared secret (a password). However, Basic's verification steps involves sending the password in the clear (a big weakness of this method), unlike in Digest. 5.5.1.1 Challenge-Response Access Authentication Mechanism When a client (via its Proxy/UA) makes a requests of a server for access to a protected object or resource, the server can challenge the UA to provide authentication information by sending the "401 Unauthorized" response message, with a WWW-Authenticate header field that includes at least a challenge applicable to the requested resource. The proxy/User Agent in turn, uses the "407 Proxy Authentication Required" response message to challenge the authorization of the client, and must include a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource. The challenge itself is composed of a case-insensitive string token representing the authentication scheme in use (i.e. "Basic" or "Digest"), followed by a comma-separated list of attribute value pairs carrying authentication parameters. One such attribute is the realm, defines the protection space or region under the control of the server for which the authentication scheme is in effect. The realm value is a string generally assigned by the challenging origin Houri, et al. Expires November 30, 2003 [Page 55] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 server. This is often the canonical root URL (absolute URI) of the server, (e.g. " myrealm@host.com" ) . Other attributes include: o domain: a quoted space-separated list of URIs that define the protection space. The client can use this to determine the set of URIs for which the same authentication information may be sent. o nonce : a server-specified (hexadecimal or base64) data string which is uniquely generated each time a 401 response is made. The contents of the nonce are implementation dependent; for example, to protect against replay-attack, an implementation may chose not to accept previously used nonce. The nonce is opaque to the client. o opaque : a string of data specified by the server which should be returned unchanged by the client in the authorization header of subsequent requests. o stale : a flag indicating that the previous request from client was rejected because the nonce value was state. o algorithm : a string indicating a pair of algorithms to produce the digest and a checksum (in the case of Digest scheme). If this is absent, it is assumed to be "MD5" . o qop-options: an optional indication of the "quality of protection" values supported by the server. An example of the WWW-Authenticate header field in a "401 Unauthorized" challenge is: WWW-Authenticate: Digest realm="myhost.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" A user agent responding to the challenge, or wishing to authenticate itself with the origin server does so by including an Authorization header field with its request. Also, a client may authenticate itself with the proxy/UA by including a Proxy-Authorization header field with the request. Both these header field values contain credentials bearing the authentication information of the client for the realm of the resource being requested. The UA must chose to use one of the challenges with the strongest authentication scheme it understands, and request credentials from the user based on that challenge. In "basic" authentication scheme, the client must authenticate itself with a user-ID and a password for each realm. This is not a secure method as the user name and password are sent in the clear. The "digest" scheme challenges using a nonce value and the client's response contains, among other parameters, checksum of the user name, Houri, et al. Expires November 30, 2003 [Page 56] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 password, the nonce, and the requested URI. Thus the password is never sent in the clear. An example of an Authorization header field is: Authorization: Digest username="Joe", realm="myhost.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:joe@myhost.com", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41" 5.5.1.2 Limitations Though the Digest scheme is more secure than the Basic scheme, both are password based, and thus suffer from problems with password systems (there is no initial secure link between the server and client over which to establish the password). Also, the "Digest" scheme provides message authentication and replay protection only, without message integrity or confidentiality; it is not as secure as Kerberos or any client-side private key scheme. See RFC 3261 [5] and RFC 2617 [2] 5.5.2 Authorization This is the act of determining whether a requesting entity (client) is allowed access to a resource, and if so, to what extent. XCAP [27] has been defined to allow a client provision authorization decision rules regarding watchers of the presence information produced by the clients. The authorization decisions in the form of permission-statements are used by the server to grant or deny access to the client's presence information stored on the server. See XCAP-USAGE [28] and PRESENCE-RULES [34]. 5.5.3 Integrity And Confidentiality 5.5.3.1 Privacy This is the withholding of aspects of an individual or entity (e.g. the identity of a person and related personal information that the owner wants to remain confidential), from the recipient party in an exchange of information (as carried in a SIP dialog). These parties may include the intended destination(s) of the messages and/or any intermediaries handling the messages. The confidential aspects may Houri, et al. Expires November 30, 2003 [Page 57] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 include personal data, properties, preferences, and behavioral traits (e.g. schedules and habits). Security mechanisms are employed to maintain privacy by protecting information that should remain private or confidential. Such mechanisms include making anonymous a party or entity involved in an information exchange, and encryption. RFC 3323 [8] defines three levels of privacy - one user-provided, and the other two, network-provided. User provided privacy involves the user agent populating the "From" header field of a request with an anonymous value. Users also take necessary steps to avoid revealing other unnecessary identity information in related SIP headers (e.g. Display-names and URIs). For example, a From header for anonymity is: From: "Anonymous" ;tag=1928774 In network-provided privacy, intermediaries in the network cooperate in concealing the confidential information. The user must have a way of requesting or signaling the desired level of privacy to the user agent, to ensure the call is routed to the intermediaries capable of providing the privacy service. The privacy-header (called Privacy) exists for this reason. User agents should include a Privacy header when networked-provided privacy is required. It is used to request privacy handling for requests and responses. For example, the currently allowed privacy-value options are shown in the following production: Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value) priv-value = "header" / "session" / "user" / "none" / "critical" / token where: o header: user requests that a privacy service obscure those headers which can't be completely rid of identifying information without the assistance of intermediaries (e.g. Via, Contact headers) session: user requests that anonymity be provided for the session(s) (as described in SDP protocol body). o User: Set by intermediaries to communicate that user-level privacy functions must be provided by the network. o None: user requests that no privacy functions be applied by the privacy service. Critical: User asserts that the privacy services requested for by the message are critical, and that if these services can't be provided, the call/request should be rejected. Houri, et al. Expires November 30, 2003 [Page 58] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 When a Privacy header is constructed, it must consist of either the value 'none', or one or more of the values 'user', 'header' and 'session', which may be followed by the 'critical' indicator. 5.5.3.2 AAA Service For greater versatility and scalability, it may be more convenient for SIP entities to communicate with an Authentication, Authorization and Accounting (AAA) server (via the SIP-AAA interface). This frees the agent nodes from storing user credentials and profiles locally. A common protocol for the AAA framework is Diameter , whose base supports usage accounting. This based protocol could be used with appropriate extensions suitable for applications such as network access control and mobility/roaming. A Diameter client is a device (e.g. a Network Access Server (NAS) or a Foreign Agent) at the edge of the network that wishes to perform access control. A Diameter client generates Diameter messages to request authentication, authorization and accounting services for the user. A Diameter agent is a node that does not authenticate or authorize messages locally, but leaves this functionality to the AAA server. For SIP applications, the SIP Server and the Diameter client are assumed co-located and the SIP Server uses the Diameter client to interface with the AAA infrastructure for authenticating SIP requests (see Figure 32). This requires presence of a Diameter SIP application as defined in [29] [SIP-UA]<--->[SIP-SRVR]-[DIAMETER-CLIENT]<--->[DIAMETER-SRVR] Figure 32 5.6 Types of Deployments Several types of presence and IM systems deployments are described: o Enterprise (Single Domains of Trust)- A presence and IM system that is built for an enterprise use. The employees of the enterprise is usually authenticated using the same credentials that they use for 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 on other systems. There is no need for each user of being authenticated since the authentication 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 (as AOL, MSN, Houri, et al. Expires November 30, 2003 [Page 59] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 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 system [TBD. Are there other types of deployments?] 5.6.1 Enterprise (Single Domains of Trust) 5.6.1.1 Definition [TBD. Detailed definition and examples of the system] 5.6.1.2 Components & Diagrams [TBD. Definitions of components involved and basic diagrams] 5.6.1.3 Scenarios [TBD. Several scenarios are listed below. We may need to define different scenarios for each system type] 5.6.1.3.1 Locating Other Servers [TBD. How other servers are located mostly referring to RFC 3263 [6]] 5.6.1.3.2 Creating Connections [TBD. Which server created a connection to which server. When a connection is broken who is recolonize for re-establishing the connection etc.] 5.6.1.3.3 Authentication [TBD. How authentication between servers is done. The authentication can be very different according to the type of the system described.] 5.6.1.3.4 State Replication [TBD. What state the servers in the system should replicate. How it can be done.] Houri, et al. Expires November 30, 2003 [Page 60] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.6.1.3.5 Advanced Configurations & Scenarios 5.6.1.3.5.1 Firewalls [TBD. Firewall considerations for the system] 5.6.1.3.5.2 Wireless [TBD. What the system needs to have in order to support wireless devices. It could have been discussed under gateways but this issue deserves a section of its own] 5.6.1.3.5.3 Gateways [TBD. What gateways the system may need to use. How they are deployed. What components in each system are involved in supporting the gateway operation] 5.6.2 Federated Systems 5.6.2.1 Definition [TBD. Detailed definition and examples of the system] 5.6.2.2 Components & Diagrams [TBD. Definitions of components involved and basic diagrams] 5.6.2.3 Scenarios [TBD. Several scenarios are listed below. We may need to define different scenarios for each system type] 5.6.2.3.1 Locating Other Servers [TBD. How other servers are located mostly referring to RFC 3263 [6]] 5.6.2.3.2 Creating Connections [TBD. Which server created a connection to which server. When a connection is broken who is recolonize for re-establishing the connection etc.] 5.6.2.3.3 Authentication [TBD. How authentication between servers is done. The authentication can be very different according to the type of the Houri, et al. Expires November 30, 2003 [Page 61] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 system described.] 5.6.2.3.4 State Replication [TBD. What state the servers in the system should replicate. How it can be done.] 5.6.2.3.5 Advanced Configurations & Scenarios 5.6.2.3.5.1 Firewalls [TBD. Firewall considerations for the system] 5.6.2.3.5.2 Wireless [TBD. What the system needs to have in order to support wireless devices. It could have been discussed under gateways but this issue deserves a section of its own] 5.6.2.3.5.3 Gateways [TBD. What gateways the system may need to use. How they are deployed. What components in each system are involved in supporting the gateway operation] 5.6.3 Public Systems Interconnecting 5.6.3.1 Definition [TBD. Detailed definition and examples of the system] 5.6.3.2 Components & Diagrams [TBD. Definitions of components involved and basic diagrams] 5.6.3.3 Scenarios [TBD. Several scenarios are listed below. We may need to define different scenarios for each system type] 5.6.3.3.1 Locating Other Servers [TBD. How other servers are located mostly referring to RFC 3263 [6]] 5.6.3.3.2 Creating Connections Houri, et al. Expires November 30, 2003 [Page 62] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 [TBD. Which server created a connection to which server. When a connection is broken who is recolonize for re-establishing the connection etc.] 5.6.3.3.3 Authentication [TBD. How authentication between servers is done. The authentication can be very different according to the type of the system described.] 5.6.3.3.4 State Replication [TBD. What state the servers in the system should replicate. How it can be done.] 5.6.3.3.5 Advanced Configurations & Scenarios 5.6.3.3.5.1 Firewalls [TBD. Firewall considerations for the system] 5.6.3.3.5.2 Wireless [TBD. What the system needs to have in order to support wireless devices. It could have been discussed under gateways but this issue deserves a section of its own] 5.6.3.3.5.3 Gateways [TBD. What gateways the system may need to use. How they are deployed. What components in each system are involved in supporting the gateway operation] 5.6.4 Open systems 5.6.4.1 Definition [TBD. Detailed definition and examples of the system] 5.6.4.2 Components & Diagrams [TBD. Definitions of components involved and basic diagrams] 5.6.4.3 Scenarios [TBD. Several scenarios are listed below. We may need to define different scenarios for each system type] Houri, et al. Expires November 30, 2003 [Page 63] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.6.4.3.1 Locating Other Servers [TBD. How other servers are located mostly referring to RFC 3263 [6]] 5.6.4.3.2 Creating Connections [TBD. Which server created a connection to which server. When a connection is broken who is recolonize for re-establishing the connection etc.] 5.6.4.3.3 Authentication [TBD. How authentication between servers is done. The authentication can be very different according to the type of the system described.] 5.6.4.3.4 State Replication [TBD. What state the servers in the system should replicate. How it can be done.] 5.6.4.3.5 Advanced Configurations & Scenarios 5.6.4.3.5.1 Firewalls [TBD. Firewall considerations for the system] 5.6.4.3.5.2 Wireless [TBD. What the system needs to have in order to support wireless devices. It could have been discussed under gateways but this issue deserves a section of its own] 5.6.4.3.5.3 Gateways [TBD. What gateways the system may need to use. How they are deployed. What components in each system are involved in supporting the gateway operation] 5.7 Basic User Scenarios [TBD. The very basic user scenarios that will be done by a UA that uses presence and IM] 5.7.1 Locating the Server(s) Houri, et al. Expires November 30, 2003 [Page 64] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 [TBD. How the server(s) that the user will use will be located. Mostly referring to RFC 3263 [6]] 5.7.2 Connection [TBD. Who creates the connection to whom. Reusing of existing connections. Re-establishing broken connections etc.] 5.7.3 Logging-In (AKA Registering) [TBD. Use of the REGISTER method in order to logon into the domain.] 5.7.4 Authentication [TBD. What authentication methods can be used in order to authenticate a used in the domain.] 5.7.5 Uploading Presence Document [TBD. Use of PUBLISH for uploading the presence document. In systems that do not support PUBLISH yet what other methods are available for publishing the presence document (REGISTER fields, HTTP, Web Services)] 5.7.6 Subscribing to a Presentity [TBD. Simple subscription to a single presentity] 5.7.7 Getting Notifications [TBD. Getting notifications on the subscribed presentity. Assuming no authorization or other issues.] 5.7.8 Sending IM [TBD. Sending IM to another user.] 5.7.9 Receiving IM [TBD. Receiving IM from another user] 5.8 The Presence Document PRESENCE of a user or an entity conveys the ability and willingness of that entity to angage in communication activity with other entities. This information is represented in a Presence Document. The basic form of this is the XML based PIDF (Presence Information Houri, et al. Expires November 30, 2003 [Page 65] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Document Format) document, defined in [15].] In PIDF, presence information is modeled as a series of tuples, each of which contains a status, communications address or contact (a URI), and other optional markup. The status can be OPEN (available for communication) or CLOSED (not available for communication). The status may be extended with other multiple values. Other tuples may be contained in the presence information, including: o Identifier: a token to identify the tuple within the presence information. o Status: OPEN/CLOSE and/or other extension values. o Communication Address: Communication means and contact address of this tuple (optional). o Relative Priority: numerical value specifying the relative preference of a communication address (optional) o Timestamp: timestamp when the tuple was last changed (optiona). o Note: human readable text about the tuple (optional). An example of a PIDF document using a default XML namespace is shown below. It shows that Joe can be contacted via a telephone, instant messaging (IM) and e-mail. It also shows that Joe is currently busy on IM. Joe prefers to be contacted via IM and e-mail. He also indicates that he will be on vacation next week. Houri, et al. Expires November 30, 2003 [Page 66] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 open tel:+09012345678 busy im:Joe@yahoo.com 2004-10-27T16:49:29Z open mailto:Joe@yahoo.com I'll be on vacation next week [ Add Rich Presence information, and example ] The PIDF defines a basic XML format for represnting presence information for a presentiy. That format defines a textual note, an indication of availability (open or closed) and a Universal Resource Identifier (URI) for communication. However, it is often the case that additional information about a user need to be conveyed in ways that are suitable for automata, and as such is not appropriate for placement in the "note" element of the PIDF document. The Rich Presence Information Data Format (RPID) [31] defines extensions to the PIDF for conveying richer presence information. One of the characteristics of the PIDF is that the document needs to carry all the presence information available for the presentity. In a low bandwidth and high-latency-link environment, the share volume of such information may be overwhelming, leading to non-optimal performance. For such environments, it is beneficial to limit the amount of information transporeted over the network by transporting only portions of PIDF. This is achieved via the use of a MIME type which enables transporting changed parts of teh PIDF as specified in [32] Houri, et al. Expires November 30, 2003 [Page 67] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.9 Composition From Multiple Sources [TBD. Composing a presence document when there are multiple publishers] 5.10 Status Values [TBD. Capture the latest on the ongoing discussion on status values] 5.11 Instant Messages [TBD. On the possible format and content of IMs] 5.12 Advanced Presence Scenarios [TBD. Covering advanced scenarios of usage of presence and notifications] 5.13 Partial Notifications [TBD. Summarizing the latest work on partial notifications of changes to presence documents] 5.14 Authorization of Subscription [TBD. Scenarios of how subscription authorization can be done. The topic should include privacy lists (who can see me) and authorization by an action of the user being subscribed on] 5.15 Presence Lists [TBD. Catching the latest on events list] 5.16 Watchers List [TBD. Describing what is watchers. How to subscribe to your watchers etc.] 5.17 Advanced IM Scenarios [TBD. Advanced scenarios of IMs including sessions conferences etc.] 5.17.1 IM Sessions [TBD. The famous subject of creation of IM session. Describe the various proposals in this ares. Describe the additional Houri, et al. Expires November 30, 2003 [Page 68] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 components that systems will have to implement in order to enable IM sessions. Describe the possible scenarios for creating IM sessions] 5.17.2 IM Conferences [TBD. Describe the various possibilities of creation a conference of IM. Use the relevant parts (for IM) from the conference model work] 5.17.3 Instant Conferences [TBD. An instant conference is a conference that is created on the spot. Usually it is the evolution of one on one IM session. See Section 5.17.5] 5.17.4 Scheduled Conferences [TBD. A scheduled conference is a conference in which invitations are sent to people and advance and they join the conference on the specified time.] 5.17.5 Switching between IM Page Mode, IM Sessions and IM Conferences [TBD. Hoe switching can be done between various types of IM interactions. Not sure if there is already work regarding this subject] 5.18 Client Capabilities [TBD. How a client informs the server and other clients on its capabilities. It is a big issue especially on mobile devices] 5.19 Profiles [TBD. Yet another big issue, Searching for other users, Sending profiles to other users etc.] 5.20 Additional Issues and Services 5.20.1 Invisible (Lurking) Mode [TBD. I want to login into a system see other people while they do not see me. Should it be allowed? Should users in the system be notified that lurking is possible.] Houri, et al. Expires November 30, 2003 [Page 69] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 5.20.2 Action Cues [TBD. How action cues are going to be sent between users. for example and indication that your IM partner is typing a response now] 5.20.3 Emoticons & Backgrounds [TBD. How the emoticons/backgrounds are downloaded to the client?] [How is the content of the emoticons/backgrounds is controlled?] 5.20.4 Message History [TBD. Storing of message history. Retrieving message history. Who can store? Who can retrieve? Should I be able to block other users that I chat with from saving my messages? etc.] 5.20.5 Offline Messages [TBD. Getting messages that were sent to me while my client is not connected to the system. Two ways are discussed below] 5.20.6 Queued Offline Messages [TBD. Messages that are delivered to the user when s/he logs in] 5.20.7 Other Offline [TBD. Delivery via email, SMS etc.] 5.20.8 File Sharing [TBD. Sending files between users. A lot of security and bandwidth issues should be raised here] 5.20.9 Voice [TBD. Using client capacities, presence information and IMs in order to start a voice session. The voice session itself will be done via the INVITE message. We might talk here about sending voice as the payload of IMs.] 5.20.10 Video [TBD. Using client capacities, presence information and IMs in order to start a video session. The video session itself will be done via the INVITE message. We might talk here about sending Houri, et al. Expires November 30, 2003 [Page 70] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 video as the payload of IMs.] 5.20.11 General Application Invocation [TBD. General application invocation using the mechanisms discussed in this document. I.e. client capabilities, presence information and IMs] 5.21 Security Considerations Security is not a single monolithic property of the system, but rather a series of related but independent properties. This section discusses threats and stage 2 level solutions to address those threats. Generic threats considered are: 1. Unauthorized usage of network SIP/SIMPLE servers, either as a new user or an existing user, of the messaging and presence services 2. Rogue network entity representation as being an authentic network entity to the endpoint 3. Eavesdropping or altering a message 4. Unauthorized access and modification of configuration data or stored messages of another user 5.21.1 Authentication Mutual authentication is required: o Authentication of the endpoint by service elements o Authentication of service elements by the endpoint Note that authentication is separate from authorization to use the network. A user may be authenticated but nevertheless refused service. 5.21.2 Network Authentication of the endpoint It is possible that an attacker represent itself to service elements as a valid endpoint. This could occur by the attacker attempting to register or send SIP/SIMPLE packets using the identity of a valid endpoint. The general solution to this type of threat is cryptographic authentication, which could be provided at the SIP layer or at a lower layer. SIP supports a number of challenge response mechanisms such as digest authentication [ref]. The HSP or other proxies can perform SIP authentication using the AAA system. Possible lower layer security systems include TLS or IKE/IPSec. If TLS is used, the endpoint has to have a certificate verifiable by a PKI. This is also Houri, et al. Expires November 30, 2003 [Page 71] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 true for IKE the control protocol for IPSec , however, IPSec can also be used with pre-shared keys that exist between the endpoint and the service elements or the AAA server that can make them available to the service elements. In some cases the authentication may be performed by one service element on behalf of other service elements. This may be referred to a transitive trust model. For this to be applicable, there must be a secure relationship between the sevice elements. 5.21.3 Endpoint Authentication of the Service Elements It is important that the endpoint determine that it is communicating with legitimate service elements. TLS and IPSec provide hop-by-hop mechanisms. These allow the endpoint to verify the identity of the first service element in a chain of service elements. The endpoint must generally rely on the trust model then to establish the identity of remote service elements. Examples include use of sips uri or 3GPP IMS. 5.21.4 Authorization for Service Having authenticated the user, the service elements can use the AAA system to make authorization decisions relative to specific service requests. Another way to authorize the user is certificate attributes in the user's certificate. This assumes the service elements have verified the user's certificate. 5.21.5 Integrity and Privacy of SIP/SIMPLE Messages An attacker may attempt to eavesdrop or alter messages. General solutions to these types of threats are to use: o Secure transport protocols such as IPSec or TLS between the endpoint and the HSP or between the endpoint and the first SIP proxy encountered by the SIP traffic. There needs to be a transitive trust on the part of the endpoint with all proxies involved. Examples include use of sips uri or 3GPP IMS. o Security transport protocols such as IPSec or TLS between the endpoint and the conference bridge. There needs to be a trust on the part of the endpoint and the conference bridge function involved. Examples include use of sips uri or 3GPP IMS. o /MIME to protect SIP/SIMPLE message bodies; this security is between and users, i.e., is end to end. However, in some commercial applications the message store itself is viewed as a "user" if the messages may need to be audited later, e.g., the Houri, et al. Expires November 30, 2003 [Page 72] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Security Exchange Commission if it needs to review messages from brokers to investors. o It is possible to use both security transport protocols and S/MIME: the former protects the SIP/SIMPLE messages as they traverse public facilities and the S/MIME protects the message bodies end to end. 5.21.6 Configuration of Subscriber Data or Stored Messages An attacker may attempt an unauthorized access and modification of configuration data of another user. An example of configured data is instant message groups. The general solution to this threat is to o Authenticate the user; this is likely a separate authentication as the data is stored in separate systems outside the scope of the SIP proxies. o Verify that the authenticated user is authorized to access or modify the specific data for a specific user. o Apply encryption and integrity on the data access control messages. o The encryption and integrity should operate between the endpoint and the directory or database that stores the user's configuration data or deferred messages. 6. References 6.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [4] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [5] 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. [6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. Houri, et al. Expires November 30, 2003 [Page 73] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 [7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [8] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [9] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [10] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. [11] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004. [12] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004. [13] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004. [14] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004. [15] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W. and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [16] Campbell, B. and J. Rosenberg, "CPIM Mapping of SIMPLE Presence and Instant Messaging", draft-ietf-simple-cpim-mapping-01 (work in progress), June 2002. [17] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of Data Elements in Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Systems", draft-ietf-simple-data-req-03 (work in progress), June 2003. [18] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", draft-ietf-simple-event-list-05 (work in progress), August 2004. [19] Lonnfors, M., Costa-Requena, J., Leppanen, E. and H. Khartabil, "Partial Notification of Presence Information", draft-ietf-simple-partial-notify-02 (work in progress), April 2004. Houri, et al. Expires November 30, 2003 [Page 74] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 [20] Khartabil, H., Leppanen, E. and T. Moran, "Requirements for Presence Specific Event Notification Filtering", draft-ietf-simple-pres-filter-reqs-03 (work in progress), January 2004. [21] Campbell, B., "SIMPLE Presence Publication Requirements", draft-ietf-simple-publish-reqs-00 (work in progress), February 2003. [22] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", draft-ietf-simple-winfo-format-04 (work in progress), January 2003. [23] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", draft-ietf-simple-winfo-package-05 (work in progress), January 2003. [24] Niemi, A., "Requirements for Limiting the Rate of Event Notifications", draft-niemi-sipping-event-throttle-reqs-02 (work in progress), July 2003. [25] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol", draft-ietf-sipping-conferencing-framework-03 (work in progress), October 2004. [26] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", draft-ietf-sipping-cc-conferencing-05 (work in progress), October 2004. [27] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-04 (work in progress), October 2004. [28] Rosenberg, J., "Extensible Markup Language (XML) Configuration Access Protocol (XCAP)Usages for Setting Presence Authorization", draft-ietf-simple-xcap-auth-usage-01 (work in progress), October 2003. [29] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C. and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", draft-ietf-aaa-diameter-sip-app-04 (work in progress), October 2004. Houri, et al. Expires November 30, 2003 [Page 75] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 [30] Khartabil, H., "Functional Description of Event Notification Filtering", draft-ietf-simple-event-filter-funct-03 (work in progress), October 2004. [31] Schulzrinne, H., Gurbani, V., Kyzivat, P. and J. Rosenberg, "RPID: Rich Presence: Extensions to the Presence Information Data Format (PIDF)", draft-ietf-simple-rpid-03 (work in progress), March 2004. [32] Lonnfors, M., Leppanen, E. and H. Khartabil, "Presence Information Data format (PIDF) Extension for Partial Presence", draft-ietf-simple-partial-pidf-format-01 (work in progress), April 2004. [33] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-02 (work in progress), October 2004. [34] Rosenberg, J., "Presence Authorization Rules", draft-ietf-simple-presence-rules-00 (work in progress), May 2004. [35] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-08 (work in progress), August 2004. [36] Niemi, A., "An Event State Publication Extension to the Session Initiation Protocol (SIP)", draft-ietf-sip-publish-04 (work in progress), May 2004. [37] Isomaki, M., "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents", draft-ietf-simple-xcap-pidf-manipulation-usage-02 (work in progress), October 2004. [38] Lonnfors, M. and K. Kiss, "User agent capability presence status extension", draft-ietf-simple-prescaps-ext-01 (work in progress), May 2004. 6.2 Non-Normative References [39] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", draft-ietf-xmpp-im-22 (work in progress), April 2004. Houri, et al. Expires November 30, 2003 [Page 76] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Authors' Addresses Avshalom Houri IBM Science Park Building 18/D Rehovot Israel Phone: +972 8 9409761 Ext. 123 EMail: avshalom@il.ibm.com Alex Audu Alcatel 3400 West Plano Parkway Plano, USA Phone: EMail: alex.audu@alcatel.com Tom Hiller Lucent Chicago, IL USA Phone: EMail: tomhiller@lucent.com Tony Hansen AT&T Laboratories Middletown, NJ 07748 USA Phone: +1.732.420.8934 EMail: tony@att.com Appendix A. Acknowledgements The authors gratefully acknowledges the contributions of: Jonathan Rosenberg, Robert Sparks, Jon Peterson, Ben Campbell and Orit Levin. Houri, et al. Expires November 30, 2003 [Page 77] Internet-Draft SIP/SIMPLE Based Presence and IM ArchitectureJune 2003 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2003). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Houri, et al. Expires November 30, 2003 [Page 78]