Internet Engineering Task Force SIMPLE WG Internet Draft Rosenberg et al. draft-ietf-simple-presence-03.txt Various Places September 24, 2001 Expires: March 2002 SIP Extensions for Presence STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document describes the usage of SIP for subscriptions and notifications of user presence. User presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of user presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence and Instant Messaging (CPIM) framework. 1 Introduction Presence is (indirectly) defined in RFC2778 [1] as subscription to and notification of changes in the communications state of a user. Rosenberg et al. [Page 1]
Internet Draft presence September 24, 2001 This communications state consists of the set of communications means, communications address, and status of that user. A presence protocol is a protocol for providing such a service over the Internet or any IP network. This document proposes the usage of the Session Initiation Protocol (SIP) [2] for presence. This is accomplished through a concrete instantiation of the general event notification framework defined for SIP [3], and as such, makes use of the SUBSCRIBE and NOTIFY methods defined there. Specifically, this document defines an event package, as described in [3]. User presence is particularly well suited for SIP. SIP registrars and location services already hold user presence information; it is uploaded to these devices through REGISTER messages, and used to route calls to those users. Furthermore, SIP networks already route INVITE messages from any user on the network to the proxy that holds the registration state for a user. As this state is user presence, those SIP networks can also allow SUBSCRIBE requests to be routed to the same proxy. This means that SIP networks can be reused to establish global connectivity for presence subscriptions and notifications. This event package is based on the concept of a presence agent, which is a new logical entity that is capable of accepting subscriptions, storing subscription state, and generating notifications when there are changes in user presence. The entity is defined as a logical one, since it is generally co-resident with another entity, and can even move around during the lifetime of a subscription. This event package is also compliant with the Common Presence and Instant Messaging (CPIM) framework that has been defined in [4]. This allows SIP for presence to easily interwork with other presence systems compliant to CPIM. 2 Definitions This document uses the terms as defined in [1]. Additionally, the following terms are defined and/or additionally clarified: 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 multiple PUAs per presentity. This means that a user can have many devices (such as a cell phone and PDA), each of which is independently generating a component of the overall presence information for a presentity. PUAs push data into Rosenberg et al. [Page 2]
Internet Draft presence September 24, 2001 the presence system, but are outside of it, in that they do not receive SUBSCRIBE messages, or send NOTIFY. 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 complete knowledge of the presence state of a presentity. One way to do this is by co-locating the PA with the proxy/registrar, or the presence user agent of the presentity. However, this is not the only way, and this specification makes no recommendations about where the PA function should be located. A PA is always addressable with a SIP URL. 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. This protocol means can be SIP REGISTER requests, but other mechanisms are allowed. When acting as a proxy, the SUBSCRIBE requests are proxied to another entity that may act as a PA. Presence Client: A presence client is a presence agent that is colocated 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. 3 Overview of Operation In this section, we present an overview of the operation of this event package. When an entity, the subscriber, wishes to learn about presence information from some user, it creates a SUBSCRIBE request. This request identifies the desired presentity in the request URI, using a SIP URL. The subscription is carried along SIP proxies as any other INVITE would be. It eventually arrives at a presence server, which can either terminate the subscription (in which case it acts as the presence agent for the presentity), or proxy it on to a presence client. If the presence client handles the subscription, it is effectively acting as the presence agent for the presentity. The decision about whether to proxy or terminate the SUBSCRIBE is a local matter; however, we describe one way to effect such a configuration, using REGISTER. The presence agent (whether in the presence server or presence client) first authenticates the subscription, then authorizes it. The Rosenberg et al. [Page 3]
Internet Draft presence September 24, 2001 means for authorization are outside the scope of this protocol, and we expect that many mechanisms will be used. Once authorized, the presence agent sends a 202 Accepted response. It also sends an immediate NOTIFY message containing the state of the presentity. As the state of the presentity changes, the PA generates NOTIFYs for all subscribers. The SUBSCRIBE message effectively establishes a session with the presence agent (a presence session). As a result, the SUBSCRIBE can be record-routed, and rules for tag handling and Contact processing mirror those for INVITE. Similarly, the NOTIFY message is handled in much the same way a re-INVITE within a call leg is handled. 4 Usage of Presence URLs A presentity is identified in the most general way through a presence URL [4], which is of the form pres:user@domain. These URLs are protocol independent. They are resolved to protocol specific URLs, such as a SIP URL, through DNS procedures defined in [4]. When subscribing to a presentity, the subscription can be addressed using the protocol independent form or the sip URL form. In the SIP context, "addressed" refers to the request URI. It is RECOMMENDED that if the entity sending a SUBSCRIBE is capable of resolving the protocol independent form to the SIP form, this resolution is done before sending the request. However, if the entity is incapable of doing this translation, the protocol independent form is used in the request URI. Performing the translation as early as possible means that these requests can be routed by SIP proxies that are not aware of the presence namespace. SUBSCRIBE messages also contain logical identifiers that define the originator and recipient of the subscription (the To and From header fields). These SHOULD contain SIP URLs whenever possible, but MAY contain a pres URL if a SIP URL is not known or available. The Contact, Record-Route and Route fields do not identify logical entities, but rather concrete ones used for SIP messaging. As such, they MUST use the SIP URL forms in both SUBSCRIBE and NOTIFY. 5 Presence Event Package The SIP event framework [3] defines an abstract SIP extension for subscribing to, and receiving notifications of, events. It leaves the definition of many additional aspects of these events to concrete extensions, also known as event packages. This document qualifies as an event package. This section fills in the information required by [5]. Rosenberg et al. [Page 4]
Internet Draft presence September 24, 2001 5.1 Package Name The name of this package is "presence". This name MUST appear within the Event header in SUBSCRIBE request and NOTIFY request. Example: Event: presence 5.2 Event Package Parameters The SIP Event Framework allows event packages to define additional parameters carried in the Event header for the specific package. This package, presence, does not define any additional parameters. 5.3 SUBSCRIBE bodies The body of a SUBSCRIBE request MAY contain a body. The purpose of the body depends on its type. Subscriptions will normally not contain bodies. The request URI, which identifies the presentity, combined with the event package name, is sufficient for user presence. We anticipate that document formats could be defined to act as filters for subscriptions. These filters would request that only certain user presence events that would generate notifies, or ask for a restriction on the set of data returned in NOTIFY requests. For example, a presence filter might specify that the notifications should only be generated when the status of the users instant message inbox changes. It might also say that the content of these notifications should only contain the IM related information. Honoring of these filters is at the policy discretion of the PA. When no body is present, this specifies to the presence agent that no filter is being requested. All presence changes SHOULD be conveyed in NOTIFY requests. 5.4 Subscription Duration User presence changes as a result of many events. Some examples are: o Turning on and off of a cell phone o Modifying the registration from a softphone Rosenberg et al. [Page 5]
Internet Draft presence September 24, 2001 o Changing the status on an instant messaging tool These events are usually triggered by human intervention, and occur with a frequency on the order of seconds to hours. As such, subscriptions should have an expiration in the middle of this range, which is roughly one hour. Therefore, the default expiration time for subscriptions within this package is 3600 seconds. As per [3], the subscriber MAY include an alternate expiration time. 5.5 NOTIFY Bodies The body of the notification contains a presence document. This document describes the user presence of the presentity that was subscribed to. All subscribers MUST support the presence data format described in [6], and MUST list its MIME type, "application/cpim- pidf+xml" in an Accept header present in the SUBSCRIBE request. Other presence data formats might be defined in the future. In that case, the subscriptions MAY indicate support for other presence formats. However, they MUST always support and list "application/cpim-pidf+xml" as an allowed format. Of course, the notifications generated by the presence agent MUST be in one of the formats specified in the Accept header in the SUBSCRIBE request. 5.6 Subscriber Generation of SUBSCRIBE Requests If a user wishes to subscribe to a user's presence, they formulate a SIP SUBSCRIBE request. The Request-URI SHOULD contain the SIP URL of the presentity whose presence is desired, but MAY contain a presence URL if no SIP URL is known. The To field SHOULD contain the same value as the Request-URI. The From field MUST be present, and SHOULD contain a logical identifier for the subscriber (i.e., sip:joe@yahoo.com as opposed to sip:joe@1.2.3.4). The request MUST contain a Contact header, Via header, Call-ID header and CSeq header as defined by SIP [2]. Other header usage is described in [2]. This request is then sent. This MAY be done using the DNS procedures defined in [2] if the Request-URI contains a SIP URL, else the request MAY be sent to a configured local outbound proxy. If the client placed a presence URL in the Request-URI because it was unable to translate it, it MUST forward the request to a configured local outbound proxy. The SUBSCRIBE request is a non-INVITE transaction and follows the transaction rules defined in [2] as specified for BYE. Rosenberg et al. [Page 6]
Internet Draft presence September 24, 2001 5.7 Notifier Processing of SUBSCRIBE Requests Based on the proxy routing procedures defined in the SIP specification, the SUBSCRIBE request will arrive at a presence agent (PA). This subsection defines processing at the PA of a SUBSCRIBE request. User presence is highly sensitive information. Because the implications of divulging presence information can be severe, strong requirements are imposed on the PA regarding subscription processing, especially related to authentication and authorization. A presence agent MUST authenticate all subscription requests. This authentication can be done using any of the mechanisms defined for SIP, except that the SIP basic authentication mechanism MUST NOT be used. It is anticipated that authentication will often be established through transitive trust. Specifically, when user A generates a SUBSCRIBE for B@bar.com, his domain (say, foo.com) will use SIP proxy authentication mechanisms to identify him. The SUBSCRIBE is forwarded to the target domain over a secure connection, such as TLS. The nature of the trust relationship between bar.com and foo.com is that bar.com trusts that foo.com has authenticated all subscribes it receives over that secure connection. As such, the bar.com server need only verify that the SUBSCRIBE came over the secure connection. The SIP extension for caller identity and privacy [7] can be used to allow one domain to provide the authenticated identity to another, even while maintaining privacy. These mechanisms apply equally well to SUBSCRIBE requests for presence. It is RECOMMENDED that any subscriptions that are not authenticated do not cause state to be established in the PA. This can be accomplished by generating a 401 in response to the SUBSCRIBE, and then discarding all state for that transaction. Retransmissions of the SUBSCRIBE generate the same response, guaranteeing reliability even over UDP. Furthermore, a PA MUST NOT accept a subscription unless authorization has been provided by the presentity. The means by which authorization are provided are outside the scope of this document. Authorization may have been provided ahead of time through access lists, perhaps specified in a web page. Authorization may have been provided by means of uploading of some kind of standardized access control list document. Back end authorization servers, such as a DIAMETER [8], RADIUS [9], or COPS [10], can also be used. It is also useful to be able to query the user for authorization following the receipt of a subscription request for which no authorization information was present. The "watcherinfo" event sub-package for SIP [11] defines a means by which a PUA can become aware that a user has attempted to Rosenberg et al. [Page 7]
Internet Draft presence September 24, 2001 subscribe to it, and no authorization exists. Authorization decisions can be very complex. At a minimum, these are be reject, accept, and pending. Pending occurs when the server cannot obtain authorization at this time, and may be able to do so at a later time, when the presentity becomes available. An accepted subscription generates a 200 OK, rejected subscription generates a 603 Declined response, and a pending subscription generates a 202 Accepted response. Any other valid responses, as specified in [2] MAY be used as well. A successful subscription also generates a NOTIFY request which contains the current presence state. See Section 5.8 for details. Polite blocking, as described in [12], is possible by generating a 200 OK to the subscription even though it has been rejected (or marked pending). Of course, an immediate NOTIFY MUST be sent also. The contents of the presence document in such a NOTIFY are at the discretion of the implementor, but SHOULD be constructed in such a way as to not reveal to the subscriber that their request has actually been blocked. 5.8 Notifier Generation of NOTIFY Requests If a subscription is accepted (or politely blocked), a NOTIFY MUST be sent after the 200 OK response to the SUBSCRIBE has been sent. Notifications MAY be sent at later times, possibly when the presence state of the presentity changes. The body of the NOTIFY MUST be sent using one of the types listed in the Accept header in the most recent SUBSCRIBE request, or using the type "application/cpim-pidf+xml" if no Accept header was present. The times at which the NOTIFY is sent for a particular subscriber, and the contents of the body within that notification, are subject to any rules specified by the authorization policy that governs the subscription. This protocol in no way limits the scope of such policies. As a baseline, a reasonable policy is to generate notifications when the state of any of the communications addresses changes. These notifications contain the complete and current presence state of the presentity as known to the presence agent. Future extensions MAY be defined that allow a subscriber to request that the notifications contain changes in presence information only, rather than complete state. The means by which the PA learns the state of the presentity are also outside the scope of this recommendation. Registrations can provide one way, although the means (if any) by which a PA uses registrations Rosenberg et al. [Page 8]
Internet Draft presence September 24, 2001 to construct a presence document are an implementation choice. If a PUA wishes to explicitly inform the presence agent of its presence state, it should explicitly upload the presence document (or its piece of it) rather than attempting to manipulate their registrations to achieve the desired result. For reasons of privacy, it will frequently be necessary to encrypt the contents of the notifications. This can be accomplished using the standard SIP encryption mechanisms. The encryption should be performed using the key of the subscriber as identified in the From field of the SUBSCRIBE. Similarly, integrity of the notifications is important to subscribers. As such, the contents of the notifications SHOULD be authenticated using one of the standardized SIP mechanisms. Since the NOTIFY are generated by the presence server, which may not have access to the key of the user represented by the presentity, it will frequently be the case that the NOTIFY are signed by a third party. It is RECOMMENDED that the signature be by an authority over domain of the presentity. In other words, for a user pres:user@example.com, the signator of the NOTIFY SHOULD be the authority for example.com. 5.9 Subscriber Processing of NOTIFY Requests The NOTIFY requests contain presence documents which describe the presentity. The subscriber SHOULD reject, with a 481 response, all NOTIFY requests whose From field tag does not match the tag in the To field of the 200 OK to the SUBSCRIBE. This means that only a single PA can be active for a particular subscription. The presence documents delivered in NOTIFY are ordered through the CSeq in the NOTIFY requests. The presence document in the NOTIFY request with the highest CSeq value is the current one. Assuming the NOTIFY request is valid, and authenticated, a 200 response MUST be sent. 5.10 Handling of Forked Requests Since SUBSCRIBE is routed by proxies as any other method, it is possible that a subscription might fork. The result is that it might arrive at multiple devices which are configured to act as a PA for the same presentity. Some of these may respond with a 2xx response to the SUBSCRIBE. Based on the forking rules in SIP, only one of these responses is passed to the subscriber. However, the subscriber will receive notifications from each of those PA which accepted the subscriptions. The SIP event framework allows each package to define the handling for this case. Rosenberg et al. [Page 9]
Internet Draft presence September 24, 2001 The processing in this case is identical to the way INVITE would be handled. The 2xx response to the SUBSCRIBE will result in the installation of subscription state in the subscriber. The subscription is associated with the To and From (both with tags) and Call-ID from the 2xx. When notifications arrive, those from the PA's whose 2xx's were discarded in the forking proxy will not match the subscription ID stored at the subscriber (the From tags will differ). These SHOULD be responded to with a 481. This will disable the subscriptions from those PA. Furthermore, when refreshing the subscription, the refresh SHOULD make use of the tags from the 2xx and make use of any Contact or Record-Route headers in order to deliver the SUBSCRIBE back to the same PA that sent the 2xx. The result of this is that a presentity can have multiple PAs active, but these should be homogeneous, so that each can generate the same set of notifications for the presentity. Supporting heterogeneous PAs, each of which generated notifications for a subset of the presence data, is complex and difficult to manage. Doing so would require the subscriber to act as the aggregator for presence data. This aggregation function can only reasonably be performed by agents representing the presentity. Therefore, if aggregation is needed, it MUST be done in a PA present in a network server representing the presentity that has access to the total set of user presence to be aggregated. 5.11 Rate of Notifications For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the PA not generate notifications for a single presentity at a rate faster than once every 5 seconds. 5.12 State Agents and Notifier Migration It is important to realize that the PA function can be colocated with several elements: o It can be co-located with the SIP registrar handling registrations for the presentity (the co-location of the PA within the proxy/registrar is known as a presence server). In this way, the presence server knows the presence of the user through registrations or other means. o It can be co-located with a PUA for that presentity (the co- location of the PA within the PUA is known as a presence client). In the case of a single PUA per presentity, the PUA knows the state of the presentity by sheer nature of its co- location. Rosenberg et al. [Page 10]
Internet Draft presence September 24, 2001 o It can be co-located in any server along the call setup path. That proxy can learn the presence state of the presentity by generating its own SUBSCRIBE in order to determine it. In this case, the PA is effectively a B2BUA. On occassion, it makes sense for the PA function to migrate from one of these places to another. For example, for reasons of scale, the PA function may reside in the presence server when the PUA is not running, but when the PUA connects to the network, the PA decides to migrate subscriptions to it in order to reduce state in the network. There are three phases to this migration: o The element currently providing the PA function determines that another element is capable of handling the subscription. o That element currently hosting the PA function destroys subscription state, and inform those subscribers that the state needs to be re-established with a new SUBSCRIBE. o When the subscribers re-SUBSCRIBE, the request is proxied, eventually arriving at the new element performing the PA function. That element accepts the request and creates a subscription. The first of these phases can occur through configuration, or through dynamic means. One dynamic means for a presence server to discover that the function can migrate to a PUA through the REGISTER message. Specifically, if a PUA wishes to indicate support for the PA function, it SHOULD include a contact address in its registration with a caller preferences "methods" parameter listing SUBSCRIBE [13]. This indicates that it is capable of terminating and processing SUBSCRIBE, and therefore can act as a PA. A PUA MUST NOT do this unless it knows definitively that it has complete presence information for a user. Because of the forking rules described in Section 5.10, a subscriber will only get presence information from one PA, and this information has to be complete. For the second phase, the PA destroys the subscriptions and then sends a NOTIFY to each subscriber, with an Subscription-Expires header with value 0 [3]. This informs the subscribers that their subscription was destroyed, and should be re-established with a new SUBSCRIBE (with a new Call-ID). The subscribers then create brand new subscriptions, with a new Call-ID, no route set and no To tag, and this is sent to recreate the subscription. In the case where the subscription has migrated to the presence server, the presence server will simply act as a PA for Rosenberg et al. [Page 11]
Internet Draft presence September 24, 2001 these new subscriptions. In the case where the subscription has migrated from the presence server to the PUA, the presence server MUST operate like a proxy. Furthermore, it SHOULD implement the SIP Caller preferences extension [13]. Because of the existence of a registered Contacts with a "methods" parameter containing SUBSCRIBE, the caller preferences extension will cause the proxy to send the SUBSCRIBEs to those Contacts. All of those should have complete presence state for the presentity. Assuming at least one accepts, a 2xx is generated and forwarded to the subscriber. The subscriber will now receive and accept notifications from that PA. Migration of subscriptions will still work if the proxy does not support the caller preferences extension. However, the proxy will instead fork the SUBSCRIBE, possibly to Contacts which have not indicated that they support SUBSCRIBE. The result will be 405 responses from those UAS. However, the one UAS which does support the method will generate a 2xx class response (assuming the subscription is accepted), and this will be correctly forwarded towards the subscriber based on proxy response processing rules [2]. The penalty of not supporting caller preferences is the additional unneeded SIP traffic. 6 Publication The user presence for a presentity can be obtained from any number of different ways. None of these mechanisms are mandated by this specification. The discussion here is for informational purposes only. 6.1 Co-location When the PA function is co-located with the PUA, user presence is known directly by the PA. 6.2 REGISTER Baseline SIP defines a method that is used by all SIP clients - the REGISTER method. This method allows a UA to inform a SIP network of its current communications addresses (ie., Contact addresses) . Furthermore, multiple UA can independently register Contact addresses for the same SIP URL. These Contact addresses can be SIP URLs, or they can be any other valid URL. Usage of REGISTER information to construct presence is only possible if the PA is co-located with, or shares information with, the SIP registrar. In this case, the combined PA/registrar/proxy is known as a presence server. Rosenberg et al. [Page 12]
Internet Draft presence September 24, 2001 Using the register information for presence is straightforward. The address of record in the REGISTER (the To field) identifies the presentity. The Contact headers define communications addresses that describe the state of the presentity. The use of the SIP caller preferences extension [13] is RECOMMENDED for use with UAs that are interested in presence. It provides additional information about the Contact addresses that can be used to construct a richer presence document. The presence of a registered Contact with a "methods" parameter [13] listing the MESSAGE method implies that the presentity supports instant messaging as a communications means. The q values from the Contact header [2] can be used to establish priorities amongst the various communications addresses in the Contact headers. The application of registered contacts to presence increases the requirements for authenticity. Therefore, REGISTER requests used by presence user agents SHOULD be authenticated using either SIP authentication mechanisms, or a hop-by-hop mechanism. 6.3 Uploading Presence Documents If a means exists to upload presence documents from PUA to the PA, the PA can act as an aggregator and redistributor of those documents. The PA, in this case, would take the presence documents received from each PUA for the same presentity, and merge the communications means across all of those PUA into a single presence document. Typically, this aggregation would be accomplished through administrator or user defined policies about how the aggregation should be done. The specific means by which a presence document are uploaded to a presence agent are outside the scope of this specification. When a PUA wishes to have direct manipulation of the presence that is distributed to subscribers, direct uploading of presence documents is RECOMMENDED. 7 Security considerations There are numerous security considerations for presence. Many are outlined above; this section considers them issue by issue. 7.1 Firewall and NAT Traversal It is anticipated that presence services will be used by clients and presentities that are connected to proxy servers on the other side of firewalls and NATs. Fortunately, since the SIP presence messages do Rosenberg et al. [Page 13]
Internet Draft presence September 24, 2001 not establish independent media streams, as INVITE does, firewall and NAT traversal is straightforward. Specifically, the SIP extensions for NAT traversal [14] are directly applicable to SUBSCRIBE and NOTIFY, and will allow operation of the protocol through NATs. Firewall administrators can set policies that allow or disallow communications services by opening or closing access to port 5060 (the default SIP port). 7.2 Privacy Privacy encompasses many aspects of a presence system: o Subscribers may not want to reveal the fact that they have subscribed to certain users o Users may not want to reveal that they have accepted subscriptions from certain users o Notifications (and fetch results) may contain sensitive data which should not be revealed to anyone but the subscriber Privacy is provided through a combination of hop by hop encryption and end to end encryption. The hop by hop mechanisms provide scalable privacy services, disable attacks involving traffic analysis, and hide all aspects of presence messages. However, they operate based on transitivity of trust, and they cause message content to be revealed to proxies. The end-to-end mechanisms do not require transitivity of trust, and reveal information only to the desired recipient. However, end-to-end encryption cannot hide all information, and is susceptible to traffic analysis. Strong end to end authentication and encryption also requires that both participants have public keys, which is not generally the case. Thus, both mechanisms combined are needed for complete privacy services. SIP allows any hop by hop encryption scheme. It is RECOMMENDED that TLS [15] be used between elements to provide this function. The presence server can determine whether TLS is supported by the receiving client based on the transport parameter in the Contact header of its registration. If there is a registered Contact with a URL that contains a transport parameter with value "tls", it implies that the PUA supports TLS. SIP encryption MAY be used end to end for the transmission of both SUBSCRIBE and NOTIFY requests. 7.3 Message integrity and authenticity Rosenberg et al. [Page 14]
Internet Draft presence September 24, 2001 It is important for the message recipient to ensure that the message contents are actually what was sent by the originator, and that the recipient of the message be able to determine who the originator really is. This applies to both requests and responses of SUBSCRIBE and NOTIFY. This is supported in SIP through end to end authentication and message integrity. SIP provides http basic and digest authentication. HTTP Basic is NOT RECOMMENDED. 7.4 Outbound authentication When local proxies are used for transmission of outbound messages, proxy authentication is RECOMMENDED. This is useful to verify the identity of the originator, and prevent spoofing and spamming at the originating network. 7.5 Replay prevention To prevent the replay of old subscriptions and notifications, all signed SUBSCRIBE and NOTIFY requests and responses MUST contain a Date header covered by the message signature. Any message with a date older than several minutes in the past, or more than several minutes into the future, SHOULD be discarded. Furthermore, all signed SUBSCRIBE and NOTIFY requests MUST contain a Call-ID and CSeq header covered by the message signature. A user agent or presence server MAY store a list of Call-ID values, and for each, the higest CSeq seen within that Call-ID. Any message that arrives for a Call-ID that exists, whose CSeq is lower than the highest seen so far, is discarded. Finally, challenge-response authentication MAY be used to prevent replay attacks. 7.6 Denial of service attacks Denial of service attacks are a critical problem for an open, inter- domain, presence protocol. Here, we discuss several possible attacks, and the steps we have taken to prevent them. 7.6.1 Smurf attacks through false contacts Unfortunately, presence is a good candidate for smurfing attacks because of its amplification properties. A single SUBSCRIBE message could generate a nearly unending stream of notifications, so long as a suitably dynamic source of presence data can be found. Thus, a simple way to launch an attack is to send subscriptions to a large number of users, and in the Contact header (which is where notifications are sent), place the address of the target. Rosenberg et al. [Page 15]
Internet Draft presence September 24, 2001 The only reliable way to prevent these attacks is through authentication and authorization. End users will hopefully not accept subscriptions from random unrecognized users. Also, the presence client software could be programmed to warn the user when the Contact header in a SUBSCRIBE is from a domain which does not match that of the From field (which identifies the subscriber). Also, note that as described in [3], if a NOTIFY is not acknowledged or was not wanted, the subscription that generated it is removed. This eliminates the amplification properties of providing false Contact addresses. 8 Example message flows The following subsections exhibit example message flows, to further clarify behavior of the protocol. When the value of the Content- Length header is "..." this means that the value should be whatever the computed length of the body is. 8.1 Client to Client Subscription with Presentity State Changes This call flow illustrates subscriptions and notifications that do not involve a presence server. The watcher subscribes to the presentity, and the subscription is accepted, resulting in a 200 OK response. The presentity subsequently changes state (is on the phone), resulting in a new notification. The flow finishes with the watcher terminating the subscription. Watcher Presentity ------- ----------- | F1 SUBSCRIBE | | ----------------------------->| | F2 200 OK | |<------------------------------| | F3 NOTIFY | |<------------------------------| | F4 200 OK | |------------------------------>| | F5 NOTIFY | |<------------------------------| | F6 200 OK | |------------------------------>| | F7 SUBSCRIBE (unsub) | |------------------------------>| Rosenberg et al. [Page 16]
Internet Draft presence September 24, 2001 | F8 200 OK | |<------------------------------| | F9 NOTIFY | |<------------------------------| | F10 200 OK | |------------------------------>| Message Details F1 SUBSCRIBE watcher -> presentity SUBSCRIBE sip:presentity@pres.example.com SIP/2.0 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User <sip:user@example.com>;tag=9988 To: Resource <sip:presentity@example.com> Call-ID: 3248543@watcherhost.example.com CSeq : 1 SUBSCRIBE Expires: 600 Accept: application/cpim-pidf+xml Event: presence Contact: sip:user@watcherhost.example.com F2 200 OK presentity->watcher SIP/2.0 200 OK Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User <sip:user@example.com>;tag=9988 To: Resource <sip:presentity@example.com>;tag=88a7s Call-ID: 3248543@watcherhost.example.com Cseq: 1 SUBSCRIBE Event: presence Expires: 600 Contact: sip:presentity@pres.example.com Rosenberg et al. [Page 17]
Internet Draft presence September 24, 2001 F3 NOTIFY Presentity->watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP pres.example.com:5060 From: Resource <sip:presentity@example.com>;tag=88a7s To: User <sip:user@example.com>;tag=9988 Call-ID: 3248543@watcherhost.example.com CSeq: 1 NOTIFY Event: presence Content-Type: application/cpim-pidf+xml Content-Length: ... <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0"> <tuple name="ph-1"> <status> <value>open</value> <detail type="phone" schema="http://www.ietf.org/dtd/im-type-phone.dtd">on-hook</detail> </status> <contact priority="2">sip:user@example.com</contact> </tuple> </presence> F4 200 OK watcher->presentity SIP/2.0 200 OK Via: SIP/2.0/UDP pres.example.com:5060 From: Resource <sip:presentity@example.com>;tag=88a7s To: User <sip:user@example.com>;tag=9988 Call-ID: 3248543@watcherhost.example.com CSeq: 1 NOTIFY F5 NOTIFY Presentity->watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP pres.example.com:5060 From: Resource <sip:presentity@example.com>;tag=88a7s To: User <sip:user@example.com>;tag=9988 Call-ID: 3248543@watcherhost.example.com CSeq: 2 NOTIFY Rosenberg et al. [Page 18]
Internet Draft presence September 24, 2001 Event: presence Content-Type: application/cpim-pidf+xml Content-Length: ... <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0"> <tuple name="ph-1"> <status> <value>closed</value> <detail type="phone" schema="http://www.ietf.org/dtd/im-type-phone.dtd">off-hook</detail> </status> <contact priority="2">sip:user@example.com</contact> </tuple> </presence> F6 200 OK watcher->presentity SIP/2.0 200 OK Via: SIP/2.0/UDP pres.example.com:5060 From: Resource <sip:presentity@example.com>;tag=88a7s To: User <sip:user@example.com>;tag=9988 Call-ID: 3248543@watcherhost.example.com CSeq: 2 NOTIFY F7 SUBSCRIBE watcher -> presentity SUBSCRIBE sip:presentity@pres.example.com SIP/2.0 Via: SIP/2.0/UDP watcherhost.example.com:5060 Call-ID: 3248543@watcherhost.example.com To: Resource <sip:presentity@example.com>;tag=88a7s From: User <sip:user@example.com>;tag=9988 Event: presence CSeq : 2 SUBSCRIBE Expires: 0 Accept: application/cpim-pidf+xml Contact: sip:user@watcherhost.example.com Rosenberg et al. [Page 19]
Internet Draft presence September 24, 2001 F8 200 OK presentity->watcher SIP/2.0 200 OK Via: SIP/2.0/UDP watcherhost.example.com:5060 Call-ID: 3248543@watcherhost.example.com To: Resource <sip:presentity@example.com>;tag=88a7s From: User <sip:user@example.com>;tag=9988 Event: presence Cseq: 2 SUBSCRIBE Expires:0 Contact: sip:presentity@pres.example.com F9 NOTIFY Presentity->watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP pres.example.com:5060 From: Resource <sip:presentity@example.com>;tag=88a7s To: User <sip:user@example.com>;tag=9988 Call-ID: 3248543@watcherhost.example.com CSeq: 3 NOTIFY Event: presence Content-Type: application/cpim-pidf+xml Content-Length: ... <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0"> <tuple name="ph-1"> <status> <value>closed</value> <detail type="phone" schema="http://www.ietf.org/dtd/im-type-phone.dtd">off-hook</detail> </status> <contact priority="2">sip:user@example.com</contact> </tuple> </presence> F10 200 OK watcher->presentity SIP/2.0 200 OK Via: SIP/2.0/UDP pres.example.com:5060 Rosenberg et al. [Page 20]
Internet Draft presence September 24, 2001 From: Resource <sip:presentity@example.com>;tag=88a7s To: User <sip:user@example.com>;tag=9988 Call-ID: 3248543@watcherhost.example.com CSeq: 3 NOTIFY 8.2 Presence Server with Client Notifications This call flow shows the involvement of a presence server in the handling of subscriptions. In this scenario, the client has indicated that it will handle subscriptions and thus notifications. The message flow shows a change of presence state by the client and a cancellation of the subscription by the watcher. Presence Watcher Server PUA | | F1 REGISTER | | |<---------------------| | | F2 200 OK | | |--------------------->| | F3 SUBSCRIBE | | |--------------------->| | | | F4 SUBSCRIBE | | |--------------------->| | | F5 200 | | |<---------------------| | F6 200 | | |<---------------------| | | F7 NOTIFY | | |<--------------------------------------------+ | F8 200 OK | | |-------------------------------------------->| | | F9 REGISTER | | |<---------------------| | | F10 200 OK | | |--------------------->| | F11 NOTIFY | | |<--------------------------------------------+ | F12 200 OK | | |-------------------------------------------->| Rosenberg et al. [Page 21]
Internet Draft presence September 24, 2001 Message Details F1 REGISTER PUA->server REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 To: <sip:resource@example.com> From: <sip:resource@example.com> Call-ID: 2818@pua.example.com CSeq: 1 REGISTER Contact: <sip:id@pua.example.com>;methods="MESSAGE,SUBSCRIBE" Expires: 600 F2 200 OK server->PUA SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com:5060 To: <sip:resource@example.com> From: <sip:resource@example.com> Call-ID: 2818@pua.example.com CSeq: 1 REGISTER Contact: <sip:id@pua.example.com>;methods="MESSAGE,SUBSCRIBE" Expires: 600 F3 SUBSCRIBE watcher->server SUBSCRIBE sip:resource@example.com SIP/2.0 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User <sip:user@example.com>;tag=ggf8 To: Resource <sip:resource@example.com> Call-ID: 32485@watcherhost.example.com CSeq : 1 SUBSCRIBE Expires: 600 Event: presence Accept: application/cpim-pidf+xml Rosenberg et al. [Page 22]
Internet Draft presence September 24, 2001 Contact: sip:user@watcherhost.example.com F4 SUBSCRIBE server->PUA SUBSCRIBE sip:id@pua.example.com SIP/2.0 Via: SIP/2.0/UDP server.example.com:5060 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User <sip:user@example.com>;tag=ggf8 To: Resource <sip:resource@example.com> Call-ID: 32485@watcherhost.example.com CSeq : 1 SUBSCRIBE Event: presence Expires: 600 Accept: application/cpim-pidf+xml Contact: sip:user@watcherhost.example.com F5 200 OK PUA->server SIP/2.0 200 OK Via: SIP/2.0/UDP server.example.com:5060 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User <sip:user@example.com>;tag=ggf8 To: Resource <sip:resource@example.com>;tag=ffd2 Call-ID: 32485@watcherhost.example.com CSeq : 1 SUBSCRIBE Event: presence Expires: 600 Contact: sip:id@pua.example.com F6 200 OK server->watcher SIP/2.0 200 OK Rosenberg et al. [Page 23]
Internet Draft presence September 24, 2001 Via: SIP/2.0/UDP watcherhost.example.com:5060 From: User <sip:user@example.com>;tag=ggf8 To: Resource <sip:resource@example.com>;tag=ffd2 Call-ID: 32485@watcherhost.example.com CSeq : 1 SUBSCRIBE Event: presence Expires: 600 Contact: sip:id@pua.example.com F7 NOTIFY PUA->watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 To: User <sip:user@example.com>;tag=ggf8 From: Resource <sip:resource@example.com>;tag=ffd2 Call-ID: 32485@watcherhost.example.com CSeq : 1 NOTIFY Event: presence Content-Type: application/cpim-pidf+xml Content-Length: ... <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0"> <tuple name="im-1"> <status> <value>open</value> <detail type="im" schema="http://www.ietf.org/dtd/im-type-im.dtd">available</detail> </status> <contact priority="2">im:user@example.com</contact> </tuple> </presence> F8 200 OK watcher->PUA SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com:5060 To: User <sip:user@example.com>;tag=ggf8 Rosenberg et al. [Page 24]
Internet Draft presence September 24, 2001 From: Resource <sip:resource@example.com>;tag=ffd2 Call-ID: 32485@watcherhost.example.com CSeq : 1 NOTIFY F9 REGISTER PUA->server REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 To: <sip:resource@example.com> From: <sip:resource@example.com> Call-ID: 2818@pua.example.com CSeq: 2 REGISTER Contact: <sip:id@pua.example.com>;methods="MESSAGE,SUBCSRIBE" ;q=0.0 Expires: 600 F10 200 OK server->PUA SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com:5060 To: <sip:resource@example.com> From: <sip:resource@example.com> Call-ID: 2818@pua.example.com CSeq: 2 REGISTER Contact: <sip:id@pua.example.com>;methods="MESSAGE,SUBSCRIBE" ;q=0.0 Expires: 600 F11 NOTIFY PUA->watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com:5060 Rosenberg et al. [Page 25]
Internet Draft presence September 24, 2001 To: User <sip:user@example.com>;tag=ggf8 From: Resource <sip:resource@example.com>;tag=ffd2 Call-ID: 32485@watcherhost.example.com CSeq : 2 NOTIFY Event: presence Content-Type: application/cpim-pidf+xml Content-Length: ... <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0"> <tuple name="im-1"> <status> <value>open</value> <detail type="im" schema="http://www.ietf.org/dtd/im-type-im.dtd">available</detail> </status> <contact priority="2">im:user@example.com</contact> </tuple> </presence> F12 200 OK watcher->PUA SIP/2.0 200 OK Via: SIP/2.0/UDP pua.example.com:5060 To: User <sip:user@example.com> ;tag=ggf8 From: Resource <sip:resource@example.com>;tag=ffd2 Call-ID: 32485@watcherhost.example.com CSeq : 2 NOTIFY 8.3 Presence Server Notifications This message flow illustrates how the presence server can be the responsible for sending notifications for a presentity. This flow assumes that the watcher has previously been authorized to subscribe to this resource at the server. In this flow, the PUA informs the server about the updated presence information though some non-SIP means. Rosenberg et al. [Page 26]
Internet Draft presence September 24, 2001 Watcher Server PUA | F1 SUBSCRIBE | | |------------------>| | | F2 200 OK | | |<------------------| | | F3 NOTIFY | | |<------------------| | | F4 200 OK | | |------------------>| | | | | | | Update presence | | |<------------------ | | | | | F5 NOTIFY | | |<------------------| | | F6 200 OK | | |------------------>| | Message Details F1 SUBSCRIBE watcher->server SUBSCRIBE sip:resource@example.com SIP/2.0 Via: SIP/2.0/UDP watcherhost.example.com:5060 To: <sip:resource@example.com> From: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 1 SUBSCRIBE Event: presence Accept: application/cpim-pidf+xml Contact: <sip:user@watcherhost.example.com> Expires: 600 F2 202 OK server->watcher SIP/2.0 200 OK Via: SIP/2.0/UDP watcherhost.example.com:5060 To: <sip:resource@example.com>;tag=ffd2 From: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com Rosenberg et al. [Page 27]
Internet Draft presence September 24, 2001 CSeq: 1 SUBSCRIBE Event: presence Expires: 600 Contact: sip:example.com F3 NOTIFY server-> watcher NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP server.example.com:5060 From: <sip:resource@example.com>;tag=ffd2 To: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com Event: presence CSeq: 1 NOTIFY Content-Type: application/cpim-pidf+xml Content-Length: .. <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0"> <tuple name="im-1"> <status> <value>open</value> <detail type="im" schema="http://www.ietf.org/dtd/im-type-im.dtd">available</detail> </status> <contact priority="2">im:user@example.com</contact> </tuple> </presence> F4 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP server.example.com:5060 From: <sip:resource@example.com>;tag=ffd2 To: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 1 NOTIFY Rosenberg et al. [Page 28]
Internet Draft presence September 24, 2001 F5 NOTIFY NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP server.example.com:5060 From: <sip:resource@example.com>;tag=ffd2 To: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 2 NOTIFY Event: presence Content-Type: application/cpim-pidf+xml Content-Length: 120 <presence xmlns="http://www.ietf.org/ns/cpim-pidf-xml-1.0"> <tuple name="im-1"> <status> <value>closed</value> <detail type="im" schema="http://www.ietf.org/dtd/im-type-im.dtd">busy</detail> </status> <contact priority="2">im:user@example.com</contact> </tuple> </presence> F6 200 OK SIP/2.0 200 OK Via: SIP/2.0/UDP server.example.com:5060 From: <sip:resource@example.com>;tag=ffd2 To: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 2 NOTIFY 9 Changes from draft-ietf-simple-presence-02 o No longer calling this document an extension, since its not. Its an Event Package. o Clarified migration section so that applies equally well to PS Rosenberg et al. [Page 29]
Internet Draft presence September 24, 2001 to PUA, and PUA to PS. Previous text assumed PS to PUA only. o Changed the default filter to "no filter". o Removed Section 6.4 on "Call State Subscription" since it is informational but may confused those not familiar with the referenced work. o Removed PGP references since these have been deprecated from SIP. o We now allow a proxy to migrate a subscription even if there are multiple registered contacts supporting SUBSCRIBE. The text has clarified that a PUA should only register support for SUBSCRIBE if it has complete state about the presentity. 10 Changes from draft-ietf-simple-presence-01 o Complete alignment with draft-ietf-sip-events. o Removal of non-confirming mode. Instead, just mention that polite blocking is possible, and how it is done is implementation specific. o Removed CPIM sections to a separate specification. o Added reference to privacy specification for transitive authentication scenarios. o Implementation of caller preferneces by presence servers is now a SHOULD. o Clarification on the process of subscription migration. o For subscription migration, the specification now mentions the Subscription-Expires header as the means for a PA to inform subscribers that their subscription has expired. This header has yet to appear in draft-ietf-sip-events. o Updated section of usage of presence URLs based on consensus of the IMPP group at IETF 51. o Construction of presence documents based on REGISTER is now defined as implementation dependent. If a UA wants to manipulate its presence, it should upload a presence document fragment instead. o Removed bit about recreating subscriptions when a 481 is Rosenberg et al. [Page 30]
Internet Draft presence September 24, 2001 received to a SUBSCRIBE request. This should be in draft- ietf-sip-events instead. o Removed references to draft-lennox-sip-reg-payload and much of that discussion. Now, the section talks more generally about uploading and aggregation of presence documents, and simply states that the means for such upload is outside the scope of this spec. o Updated example flows. Consistent use of From tags, elimination of pres URL, usage of application/cpim-pidf+xml types. Fixed caller preferences usage bug. 11 Changes from draft-ietf-simple-presence-00 o Clarified that user presence can be obtained in many ways, not just SIP. o Defined the default notification content when a filter is not provided in the body of a SUBSCRIBE. o Removed text about the inability of a PA to increase a subscription expiration time (this needs to be reconciled with draft-ietf-sip-events. o Removed requirement that authentication be end-to-end only, and not transitive. This is not practical at all, and transitive trust is likely to be the only deployable mechanism initially. o Removed the Appendix on the watcher info mechanism for triggering authorization decisions; draft-ietf-simple-winfo- package is now referenced. o Defined confirming and non-confirming modes for revealing authorization information. o Strengthened the section about how a PA obtains information about the presentity. o Updated section on migrating PA function. o Added requirement that a subscriber generate a new subscription when a refresh fails with a 481. o Removed transport mode ESP as the reccommended inter-server transport. TLS is now consistently recommended. Rosenberg et al. [Page 31]
Internet Draft presence September 24, 2001 o Removed insertion of tls transport parameter into Contact header in 200 OK response to SUBSCRIBE. This is because this parameter needs to be UDP for interoperability. 12 Changes from draft-rosenberg-impp-presence-01 Renamed to draft-ietf-simple-presence-00. 13 Changes from draft-rosenberg-impp-presence-00 The document has been completely rewritten, to reflect the change from a sales pitch and educational document, to a more formal protocol specification. It has also been changed to align with the SIP event architecture and with CPIM. The specific protocol changes resulting from this rewrite are: o The Event header must now be used in the SUBSCRIBE and NOTIFY requests. o The SUBSCRIBE message can only have a single Contact header. -00 allowed for more than one. o The From and To headers can contain presence URIs. o The Request-URI can contain a presence URI. o Subscriptions are responded to with a 202 if they are pending or accepted. o Presence documents are not returned in the body of the SUBSCRIBE response. Rather, they are sent in a separate NOTIFY. This more cleanly separates subscription and notification, and is mandated by alignment with CPIM. o Authentication is now mandatory at the PA. Authorization is now mandatory at the PA. o Fake NOTIFY is sent for pending or rejected subscriptions. o A rate limit on notifications was introduced. o Merging of presence data has been removed. o The subscriber rejects notifications received with tags that don't match those in the 202 response to the SUBSCRIBE. This means that only one PA will hold subscription state for a particular subscriber for a particular presentity. Rosenberg et al. [Page 32]
Internet Draft presence September 24, 2001 o IM URLs allowed in Contacts in register o CPIM mappings defined. o Persistent connections recommended for firewall traversal. 14 Acknowledgements We would like to thank the following people for their support and comments on this draft: Rick Workman Nortel Adam Roach Ericsson Sean Olson Ericsson Billy Biggs University of Waterloo Stuart Barkley UUNet Mauricio Arango SUN Richard Shockey Shockey Consulting LLC Jorgen Bjorkner Hotsip Henry Sinnreich MCI Worldcom Ronald Akers Motorola 15 Authors Addresses Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com Dean Willis dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 email: dwillis@dynamicsoft.com Robert Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 email: rsparks@dynamicsoft.com Rosenberg et al. [Page 33]
Internet Draft presence September 24, 2001 Ben Campbell 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 email: bcampbell@dynamicsoft.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: schulzrinne@cs.columbia.edu Jonathan Lennox Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: lennox@cs.columbia.edu Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 email: huitema@microsoft.com Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 email: bernarda@microsoft.com David Gurle Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 email: dgurle@microsoft.com David Oran Cisco Systems 170 West Tasman Dr. San Jose, CA 95134 email: oran@cisco.com 16 Bibliography Rosenberg et al. [Page 34]
Internet Draft presence September 24, 2001 [1] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and instant messaging," Request for Comments 2778, Internet Engineering Task Force, Feb. 2000. [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [3] A. Roach, "SIP specific event notification," Internet Draft, Internet Engineering Task Force, July 2001. Work in progress. [4] D. Crocker et al. , "A common profile for instant messaging (CPIM)," Internet Draft, Internet Engineering Task Force, Feb. 2001. Work in progress. [5] A. Roach, "Event notification in SIP," Internet Draft, Internet Engineering Task Force, Feb. 2001. Work in progress. [6] H. Sugano and S. Fujimoto, "Cpim presence information data format," Internet Draft, Internet Engineering Task Force, Aug. 2001. Work in progress. [7] B. Marshall et al. , "SIP extensions for caller identity and privacy," Internet Draft, Internet Engineering Task Force, Mar. 2001. Work in progress. [8] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, and G. Zorn, "Diameter base protocol," Internet Draft, Internet Engineering Task Force, Apr. 2001. Work in progress. [9] C. Rigney, S. Willens, A. Rubens, and W. Simpson, "Remote authentication dial in user service (RADIUS)," Request for Comments 2865, Internet Engineering Task Force, June 2000. [10] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A. Sastry, "The COPS (common open policy service) protocol," Request for Comments 2748, Internet Engineering Task Force, Jan. 2000. [11] J. Rosenberg, "A SIP event sub-package for watcher information," Internet Draft, Internet Engineering Task Force, July 2001. Work in progress. [12] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging / presence protocol requirements," Request for Comments 2779, Internet Engineering Task Force, Feb. 2000. [13] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and callee capabilities," Internet Draft, Internet Engineering Task Rosenberg et al. [Page 35]
Internet Draft presence September 24, 2001 Force, Nov. 2000. Work in progress. [14] J. Rosenberg, J. Weinberger, and H. Schulzrinne, "SIP extensions for NAT traversal," Internet Draft, Internet Engineering Task Force, Aug. 2001. Work in progress. [15] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request for Comments 2246, Internet Engineering Task Force, Jan. 1999. Table of Contents 1 Introduction ........................................ 1 2 Definitions ......................................... 2 3 Overview of Operation ............................... 3 4 Usage of Presence URLs .............................. 4 5 Presence Event Package .............................. 4 5.1 Package Name ........................................ 5 5.2 Event Package Parameters ............................ 5 5.3 SUBSCRIBE bodies .................................... 5 5.4 Subscription Duration ............................... 5 5.5 NOTIFY Bodies ....................................... 6 5.6 Subscriber Generation of SUBSCRIBE Requests ......... 6 5.7 Notifier Processing of SUBSCRIBE Requests ........... 7 5.8 Notifier Generation of NOTIFY Requests .............. 8 5.9 Subscriber Processing of NOTIFY Requests ............ 9 5.10 Handling of Forked Requests ......................... 9 5.11 Rate of Notifications ............................... 10 5.12 State Agents and Notifier Migration ................. 10 6 Publication ......................................... 12 6.1 Co-location ......................................... 12 6.2 REGISTER ............................................ 12 6.3 Uploading Presence Documents ........................ 13 7 Security considerations ............................. 13 7.1 Firewall and NAT Traversal .......................... 13 7.2 Privacy ............................................. 14 7.3 Message integrity and authenticity .................. 14 7.4 Outbound authentication ............................. 15 7.5 Replay prevention ................................... 15 7.6 Denial of service attacks ........................... 15 7.6.1 Smurf attacks through false contacts ................ 15 8 Example message flows ............................... 16 8.1 Client to Client Subscription with Presentity Rosenberg et al. [Page 36]
Internet Draft presence September 24, 2001 State Changes .................................................. 16 8.2 Presence Server with Client Notifications ........... 21 8.3 Presence Server Notifications ....................... 26 9 Changes from draft-ietf-simple-presence-02 .......... 29 10 Changes from draft-ietf-simple-presence-01 .......... 30 11 Changes from draft-ietf-simple-presence-00 .......... 31 12 Changes from draft-rosenberg-impp-presence-01 ....... 32 13 Changes from draft-rosenberg-impp-presence-00 ....... 32 14 Acknowledgements .................................... 33 15 Authors Addresses ................................... 33 16 Bibliography ........................................ 34 Rosenberg et al. [Page 37]
