idnits 2.17.1 draft-ietf-simple-presence-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 20, 2002) is 8010 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2246 (ref. '6') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force SIMPLE WG 3 Internet Draft J. Rosenberg 4 dynamicsoft 5 D. Willis 6 dynamicsoft 7 H. Schulzrinne 8 Columbia U. 9 C. Huitema 10 Microsoft 11 B. Aboba 12 Microsoft 13 D. Gurle 14 Microsoft 15 D. Oran 16 Cisco 17 draft-ietf-simple-presence-07.txt 18 May 20, 2002 19 Expires: November 2002 21 Session Initiation Protocol (SIP) Extensions for Presence 23 STATUS OF THIS MEMO 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC2026. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress". 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 To view the list Internet-Draft Shadow Directories, see 42 http://www.ietf.org/shadow.html. 44 Abstract 46 This document describes the usage of the Session Initiation Protocol 47 (SIP) for subscriptions and notifications of user presence. User 48 presence is defined as the willingness and ability of a user to 49 communicate with other users on the network. Historically, presence 50 has been limited to "on-line" and "off-line" indicators; the notion 51 of presence here is broader. Subscriptions and notifications of user 52 presence are supported by defining an event package within the 53 general SIP event notification framework. This protocol is also 54 compliant with the Common Presence and Instant Messaging (CPIM) 55 framework. 57 Table of Contents 59 1 Introduction ........................................ 4 60 2 Terminology ......................................... 4 61 3 Definitions ......................................... 4 62 4 Overview of Operation ............................... 5 63 5 Usage of Presence URLs .............................. 7 64 6 Presence Event Package .............................. 8 65 6.1 Package Name ........................................ 8 66 6.2 Event Package Parameters ............................ 8 67 6.3 SUBSCRIBE bodies .................................... 9 68 6.4 Subscription Duration ............................... 9 69 6.5 NOTIFY Bodies ....................................... 9 70 6.6 Notifier Processing of SUBSCRIBE Requests ........... 10 71 6.6.1 Authentication ...................................... 10 72 6.6.2 Authorization ....................................... 11 73 6.7 Notifier Generation of NOTIFY Requests .............. 12 74 6.8 Subscriber Processing of NOTIFY Requests ............ 13 75 6.9 Handling of Forked Requests ......................... 14 76 6.10 Rate of Notifications ............................... 14 77 6.11 State Agents ........................................ 14 78 7 Publication ......................................... 16 79 7.1 Co-location ......................................... 16 80 7.2 REGISTER ............................................ 16 81 7.3 Uploading Presence Documents ........................ 17 82 8 Example message flow ................................ 17 83 9 Security considerations ............................. 20 84 9.1 Privacy ............................................. 20 85 9.2 Message integrity and authenticity .................. 21 86 9.3 Outbound authentication ............................. 21 87 9.4 Replay prevention ................................... 22 88 9.5 Denial of service attacks ........................... 22 89 9.5.1 Distributed DOS attacks through false contacts ...... 22 90 10 IANA Consideration .................................. 23 91 11 Contributors ........................................ 23 92 12 Acknowledgements .................................... 23 93 13 Authors Addresses ................................... 24 94 14 Normative References ................................ 25 95 15 Informative References .............................. 26 97 1 Introduction 99 Presence is (indirectly) defined in RFC 2778 [8] as subscription to 100 and notification of changes in the communications state of a user. 101 This communications state consists of the set of communications 102 means, communications address, and status of that user. A presence 103 protocol is a protocol for providing such a service over the Internet 104 or any IP network. 106 This document proposes the usage of the Session Initiation Protocol 107 (SIP) [1] for presence. This is accomplished through a concrete 108 instantiation of the general event notification framework defined for 109 SIP [2], and as such, makes use of the SUBSCRIBE and NOTIFY methods 110 defined there. Specifically, this document defines an event package, 111 as described in [2]. User presence is particularly well suited for 112 SIP. SIP registrars and location services already hold aspects of 113 user presence information; it is uploaded to these devices through 114 REGISTER messages, and used to route calls to those users. 115 Furthermore, SIP networks already route INVITE messages from any user 116 on the network to the proxy that holds the registration state for a 117 user. As this state is user presence, those SIP networks can also 118 allow SUBSCRIBE requests to be routed to the same proxy. This means 119 that SIP networks can be reused to establish global connectivity for 120 presence subscriptions and notifications. 122 This event package is based on the concept of a presence agent, which 123 is a new logical entity that is capable of accepting subscriptions, 124 storing subscription state, and generating notifications when there 125 are changes in user presence. The entity is defined as a logical one, 126 since it is generally co-resident with another entity. 128 This event package is also compliant with the Common Presence and 129 Instant Messaging (CPIM) framework that has been defined in [3]. This 130 allows SIP for presence to easily interwork with other presence 131 systems compliant to CPIM. 133 2 Terminology 135 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 136 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 137 and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and 138 indicate requirement levels for compliant implementations. 140 3 Definitions 142 This document uses the terms as defined in RFC 2778 [8]. 143 Additionally, the following terms are defined and/or additionally 144 clarified: 146 Presence User Agent (PUA): A Presence User Agent manipulates 147 presence information for a presentity. This manipulation 148 can be the side effect of some other action (such as 149 sending a SIP REGISTER request to add a new Contact) or can 150 be done explicitly through the publication of presence 151 documents. We explicitly allow multiple PUAs per 152 presentity. This means that a user can have many devices 153 (such as a cell phone and Personal Digital Assistant 154 (PDA)), each of which is independently generating a 155 component of the overall presence information for a 156 presentity. PUAs push data into the presence system, but 157 are outside of it, in that they do not receive SUBSCRIBE 158 messages, or send NOTIFY. 160 Presence Agent (PA): A presence agent is a SIP user agent which 161 is capable of receiving SUBSCRIBE requests, responding to 162 them, and generating notifications of changes in presence 163 state. A presence agent must have knowledge of the presence 164 state of a presentity. This means that it must have access 165 to presence data manipulated by PUAs for the presentity. 166 One way to do this is by co-locating the PA with the 167 proxy/registrar, or the presence user agent of the 168 presentity. However, this is not the only way, and this 169 specification makes no recommendations about where the PA 170 function should be located. A PA is always addressable with 171 a SIP URI that uniquely identifies the presentity (i.e, 172 sip:joe@example.com). There can be multiple PAs for a 173 particular presentity, each of which handles some subset of 174 the total subscriptions currently active for the 175 presentity. A PA is also a notifier (defined in [2]) that 176 supports the presence events package. 178 Presence Server: A presence server is a physical entity that can 179 act as either a presence agent or as a proxy server for 180 SUBSCRIBE requests. When acting as a PA, it is aware of the 181 presence information of the presentity through some 182 protocol means. When acting as a proxy, the SUBSCRIBE 183 requests are proxied to another entity that may act as a 184 PA. 186 Edge Presence Server: An edge presence server is a presence 187 agent that is co-located with a PUA. It is aware of the 188 presence information of the presentity because it is co- 189 located with the entity that manipulates this presence 190 information. 192 4 Overview of Operation 193 In this section, we present an overview of the operation of this 194 event package. The overview describes behavior that is documented in 195 part here, in part within the SIP events framework [2], and in part 196 in the SIP specification [1], in order to provide clarity on this 197 package for readers only casually familiar with those specifications. 198 However, the detailed semantics of this package require the reader to 199 be familiar with SIP events and the SIP specification itself. 201 When an entity, the subscriber, wishes to learn about presence 202 information from some user, it creates a SUBSCRIBE request. This 203 request identifies the desired presentity in the request URI, using a 204 SIP URI, SIPS URI [1] or a presence URL [3]. The subscription is 205 carried along SIP proxies as any other request would be. In most 206 cases, it eventually arrives at a presence server, which can either 207 terminate the subscription (in which case it acts as the presence 208 agent for the presentity), or proxy it on to an edge presence server. 209 If the edge presence server handles the subscription, it is 210 effectively acting as the presence agent for the presentity. The 211 decision at a presence server about whether to proxy or terminate the 212 SUBSCRIBE is a local matter; however, we describe one way to effect 213 such a configuration, using REGISTER. 215 The presence agent (whether in the presence server or edge presence 216 server) first authenticates the subscription, then authorizes it. The 217 means for authorization are outside the scope of this protocol, and 218 we expect that many mechanisms will be used. If authorized, a 200 OK 219 response is returned. If authorization could not be obtained at this 220 time, the subscription is considered "pending", and a 202 response is 221 returned. In both cases, the PA sends an immediate NOTIFY message 222 containing the state of the presentity and of the subscription. The 223 presentity state may be bogus in the case of a pending subscription, 224 indicating offline no matter what the state of the actual presentity, 225 for example. This is to protect the privacy of the presentity, who 226 may not want to reveal that they have not provided authorization for 227 the subscriber. As the state of the presentity changes, the PA 228 generates NOTIFYs containing those state changes to all subscribers 229 with authorized subscriptions. Changes in the state of the 230 subscription itself can also trigger NOTIFY requests; that state is 231 carried in the Subscription-State header of the NOTIFY, and would 232 typically indicate whether the subscription is active or pending. 234 The SUBSCRIBE message establishes a "dialog" with the presence agent. 235 A dialog is defined in [1], and it represents the SIP state between a 236 pair of entities to facilitate peer-to-peer message exchanges. This 237 state includes the sequence numbers for messages in both directions 238 (SUBSCRIBE from the subscriber, NOTIFY from the presence agent), in 239 addition to a route set and remote target URI. The route set is a 240 list of SIP (or SIPS) URIs which identify SIP proxy servers that are 241 to be visited along the path of SUBSCRIBE refreshes or NOTIFY 242 requests. The remote target URI is the SIP or SIPS URI that 243 identifies the target of the message - the subscriber, in the case of 244 NOTIFY, or the presence agent, in the case of a SUBSCRIBE refresh. 246 SIP provides a procedure called record-routing that allows for proxy 247 servers to request to be on the path of NOTIFY messages and/or 248 SUBSCRIBE refreshes. This is accomplished by inserting a URI into the 249 Record-Route header in the initial SUBSCRIBE request and/or response. 251 The subscription persists for a duration that is negotiated as part 252 of the initial SUBSCRIBE. The subscriber will need to refresh the 253 subscription before termination, if they wish to continue. This is 254 accomplished by sending a SUBSCRIBE refresh within the same dialog 255 established by the initial SUBSCRIBE. This SUBSCRIBE is nearly 256 identical to the initial one, but contains the dialog identifier, 257 different sequence numbers, and a set of Route headers that identify 258 the path of proxies the request is to take. 260 The subscriber can terminate the subscription by sending a SUBSCRIBE, 261 within the dialog, with an Expires header (which indicates duration 262 of the subscription) of zero. This causes an immediate termination of 263 the subscription. A NOTIFY request is then generated by the presence 264 agent with the most recent state. In fact, behavior of the presence 265 agent for handing a SUBSCRIBE with Expires of zero is no different 266 than for any other expiration value; all SUBSCRIBE requests result in 267 a triggered NOTIFY with the current presentity and subscription 268 state. 270 The presence agent can terminate the subscription at any time. To do 271 so, it sends a NOTIFY request with a Subscription-State header 272 indicating that the subscription has been terminated. A reason 273 parameter can be supplied which provides the reason. 275 It is also possible to fetch the current presence status, rather than 276 subscribing to it. This is accomplished by sending a SUBSCRIBE 277 request with an immediate expiration. 279 5 Usage of Presence URLs 281 A presentity is identified in the most general way through a presence 282 URL [3], which is of the form pres:user@domain. These URLs are 283 protocol independent. They are resolved to protocol specific URIs, 284 such as a SIP or SIPS URI, through DNS procedures defined in [3]. 286 When subscribing to a presentity, the subscription can be addressed 287 using the protocol independent form or the SIP or SIPS URI form. In 288 the SIP context, "addressed" refers to the Request-URI. It is 289 RECOMMENDED that if the entity sending a SUBSCRIBE is capable of 290 resolving the protocol independent form to the SIP form, this 291 resolution is done before sending the request. However, if the entity 292 is incapable of doing this translation, the protocol independent form 293 MAY be used in the Request-URI. In that case, the request would 294 typically be sent to a configured outbound proxy that would perform 295 the resolution. Performing the translation as early as possible means 296 that these requests can be routed by SIP proxies that are not aware 297 of the presence URL. 299 SUBSCRIBE messages also contain logical identifiers that define the 300 originator and recipient of the subscription (the To and From header 301 fields). These SHOULD contain SIP or SIPS URIs whenever possible, but 302 MAY contain a pres URL if a SIP or SIPS URI is not known or 303 available. 305 The Contact, Record-Route and Route fields do not identify logical 306 entities, but rather concrete ones used for SIP messaging. SIP [1] 307 specifies rules for their construction. 309 6 Presence Event Package 311 The SIP event framework [2] defines a SIP extension for subscribing 312 to, and receiving notifications of, events. It leaves the definition 313 of many additional aspects of these events to concrete extensions, 314 also known as event packages. This document qualifies as an event 315 package. This section fills in the information required by [2]. 317 6.1 Package Name 319 The name of this package is "presence". As specified in [2], this 320 value appears in the Event header present in SUBSCRIBE and NOTIFY 321 requests. 323 Example: 325 Event: presence 327 6.2 Event Package Parameters 329 The SIP Event Framework allows event packages to define additional 330 parameters carried in the Event header for the specific package. This 331 package, presence, does not define any additional parameters. 333 6.3 SUBSCRIBE bodies 335 A SUBSCRIBE request MAY contain a body. The purpose of the body 336 depends on its type. Subscriptions will normally not contain bodies. 337 The request URI, which identifies the presentity, combined with the 338 event package name, is sufficient for user presence. 340 We anticipate that document formats could be defined to act as 341 filters for subscriptions. These filters would request that only 342 certain user presence events generate notifies, or ask for a 343 restriction on the set of data returned in NOTIFY requests. For 344 example, a presence filter might specify that the notifications 345 should only be generated when the status of the users instant message 346 inbox changes. It might also say that the content of these 347 notifications should only contain the Instant Message (IM) related 348 information. 350 Honoring of these filters is at the policy discretion of the PA. 352 When no body is present, this specifies to the PA that no filter is 353 being requested, so that the PA is being requested to send all NOTIFY 354 requests that its own policy allows. 356 6.4 Subscription Duration 358 User presence changes as a result of many events. Some examples are: 360 o Turning on and off of a cell phone 362 o Modifying the registration from a softphone 364 o Changing the status on an instant messaging tool 366 These events are usually triggered by human intervention, and occur 367 with a frequency on the order of seconds to hours. As such, 368 subscriptions should have an expiration in the middle of this range, 369 which is roughly one hour. Therefore, the default expiration time for 370 subscriptions within this package is 3600 seconds. As per [2], the 371 subscriber MAY include an alternate expiration time. 373 6.5 NOTIFY Bodies 375 As described in [2], the NOTIFY message will contain bodies that 376 describe the state of the subscribed resource. This body is in a 377 format listed in the Accept header of the SUBSCRIBE, or a package- 378 specific default if the Accept header is omitted. 380 In this event package, the body of the notification contains a 381 presence document. This document describes the user presence of the 382 presentity that was subscribed to. All subscribers MUST support the 383 "application/cpim-pidf+xml" presence data format described in [5]. 384 The subscribe request MAY contain an Accept header. If no such header 385 is present, it has a default value of "application/cpim-pidf+xml". If 386 the header is present, it MUST include "application/cpim-pidf+xml", 387 and MAY include any other types capable of representing user 388 presence. 390 6.6 Notifier Processing of SUBSCRIBE Requests 392 Based on the proxy routing procedures defined in the SIP 393 specification, the SUBSCRIBE request will arrive at a presence agent 394 (PA). This subsection defines processing at the PA of a SUBSCRIBE 395 request. 397 If a PA gets a SUBSCRIBE request, and the Request-URI identifies a 398 user the PA is responsible for, but the To header does not, this 399 means that the SUBSCRIBE was forwarded for some reason. Whether the 400 PA is willing to accept subscriptions originally targeted to the user 401 in the To field is a matter of local policy. If a PA decides not to, 402 it SHOULD generate a 403 response. 404 User presence is highly sensitive information. Because the 405 implications of divulging presence information can be severe, strong 406 requirements are imposed on the PA regarding subscription processing, 407 especially related to authentication and authorization. 409 6.6.1 Authentication 411 A presence agent MUST authenticate all subscription requests. This 412 authentication can be done using any of the mechanisms defined in 413 [1]. 415 In single-domain systems, where the subscribers all have shared 416 secrets with the PA in the domain, the combination of digest 417 authentication over Transport Layer Security (TLS) [6] provides a 418 secure and workable solution for authentication. This use case is 419 described in Section 26.3.2.1 of [1]. 421 In inter-domain scenarios, establishing an authenticated identity of 422 the subscriber is harder. It is anticipated that authentication will 423 often be established through transitive trust. Specifically, when 424 user A generates a SUBSCRIBE for B@bar.com, his domain (say, foo.com) 425 will use SIP proxy digest authentication, run over a TLS connection, 426 to identify him (see Section 26.3.2.1 of [1] for an example). The 427 SUBSCRIBE is forwarded to the target domain over a secure connection, 428 such as TLS (see Section 26.3.2.2 of [1] for an example of TLS-based 429 inter-domain security). The nature of the trust relationship between 430 bar.com and foo.com is that bar.com trusts that foo.com has 431 authenticated all subscribes it receives over that secure connection. 432 As such, the bar.com server need only verify that the SUBSCRIBE came 433 over the secure connection. Any future SIP extensions for network 434 asserted identities could be used in this scenario to allow foo.com 435 to inform bar.com of the authenticated identity. 437 A presentity MAY choose to represent itself with a SIPS URI. By 438 "represent itself", it means that the user represented by the 439 presentity hands out, on business cards, web pages, and so on, a SIPS 440 URI for their presentity. The semantics associated with this URI, as 441 described in [1], require TLS usage on each hop between the 442 subscriber and the server in the domain of the URI. This provides 443 additional assurances (but no absolute guarantees) that identity has 444 been verified at each hop. 446 Another mechanism for authentication is S/MIME. Its usage with SIP is 447 described fully in [1]. It provides an end-to-end authentication 448 mechanism that can be used for a PA to establish the identity of the 449 subscriber. 451 6.6.2 Authorization 453 Once authenticated, the PA makes an authorization decision. A PA MUST 454 NOT accept a subscription unless authorization has been provided by 455 the presentity. The means by which authorization are provided are 456 outside the scope of this document. Authorization may have been 457 provided ahead of time through access lists, perhaps specified in a 458 web page. Authorization may have been provided by means of uploading 459 of some kind of standardized access control list document. Back end 460 authorization servers, such as a DIAMETER [9], RADIUS [10], or COPS 461 [11], can also be used. It is also useful to be able to query the 462 user for authorization following the receipt of a subscription 463 request for which no authorization information was present. The 464 "watcherinfo" event sub-package for SIP [12] defines a means by which 465 a presentity can become aware that a user has attempted to subscribe 466 to it, so that it can then provide an authorization decision. 468 Authorization decisions can be very complex. Ultimately, all 469 authorization decisions can be mapped into one of three states: 470 rejected, successful, and pending. Any subscription for which the 471 client is authorized to receive information about some subset of 472 presence state at some points in time is a successful subscription. 473 Any subscription for which the client will never receive any 474 information about any subset of the presence state is a rejected 475 subscription. Any subscription for which it is not known yet whether 476 it is successful or rejected is pending. Generally, pending occurs 477 when the server cannot obtain authorization at the time of the 478 subscription, and may be able to do so at a later time, when the 479 presentity becomes available. 481 The appropriate response codes for conveying a successful, rejected, 482 or pending subscription (200, 403 or 603, and 202, respectively) are 483 described in [2]. 485 The SIP events framework allows the initial NOTIFY to contain no body 486 if the resource is not in a meaningful state. In the case of 487 presence, that NOTIFY MAY contain a presence document. This document 488 would indicate whatever presence state the subscriber has been 489 authorized to see; it is interpreted by the subscriber as the current 490 presence state of the presentity. For pending subscriptions, the 491 state of the presentity SHOULD include some kind of textual note that 492 indicates a pending status. 494 Polite blocking, as described in [13], is possible by generating a 495 200 OK to the subscription even though it has been rejected (or 496 marked pending). Of course, an immediate NOTIFY will still be sent. 497 The contents of the presence document in such a NOTIFY are at the 498 discretion of the implementor, but SHOULD be constructed in such a 499 way as to not reveal to the subscriber that their request has 500 actually been blocked. Typically, this is done by indicating 501 "offline" or equivalent status for a single contact address. 503 6.7 Notifier Generation of NOTIFY Requests 505 The SIP Events specification details the formatting and structure of 506 NOTIFY messages. However, it leaves to packages the detailed 507 information about what events cause a NOTIFY to be sent, how to 508 compute the state information in the NOTIFY, how to generate neutral 509 or fake state information to hide authorization delays and decisions 510 from users, and whether state information is complete or deltas for 511 notifications. 513 A PA MAY send a NOTIFY at any time. Typically, it will send ones for 514 successful subscriptions when the state of the presentity changes. 515 The NOTIFY request MAY contain a body indicating the state of the 516 presentity. The times at which the NOTIFY is sent for a particular 517 subscriber, and the contents of the body within that notification, 518 are subject to any rules specified by the authorization policy that 519 governs the subscription. This protocol in no way limits the scope of 520 such policies. As a baseline, a reasonable policy is to generate 521 notifications when the state of any of the communications addresses 522 changes. These notifications would contain the complete and current 523 presence state of the presentity as known to the presence agent. 524 Future extensions can be defined that allow a subscriber to request 525 that the notifications contain changes in presence information only, 526 rather than complete state. 528 In the case of a pending subscription, when final authorization is 529 determined, a NOTIFY can be sent. If the result of the authorization 530 decision was success, a NOTIFY SHOULD be sent and SHOULD contain a 531 presence document with the current state of the presentity. If the 532 subscription is rejected, a NOTIFY MAY be sent. As described in [2], 533 the Subscription-State header can indicate the state of the 534 subscription. 536 The body of the NOTIFY MUST be sent using one of the types listed in 537 the Accept header in the most recent SUBSCRIBE request, or using the 538 type "application/cpim-pidf+xml" if no Accept header was present. 540 The means by which the PA learns the state of the presentity are also 541 outside the scope of this recommendation. Registrations can provide 542 one way, although the means (if any) by which a PA uses registrations 543 to construct a presence document are an implementation choice. If a 544 PUA wishes to explicitly inform the presence agent of its presence 545 state, it should explicitly upload the presence document (or its 546 piece of it) rather than attempting to manipulate their registrations 547 to achieve the desired result. 549 For reasons of privacy, it will frequently be necessary to encrypt 550 the contents of the notifications. This can be accomplished using 551 S/MIME. The encryption can be performed using the key of the 552 subscriber as identified in the From field of the SUBSCRIBE. 553 Similarly, integrity of the notifications is important to 554 subscribers. As such, the contents of the notifications MAY provide 555 authentication and message integrity using S/MIME. Since the NOTIFY 556 is generated by the presence server, which may not have access to the 557 key of the user represented by the presentity, it will frequently be 558 the case that the NOTIFY is signed by a third party. It is 559 RECOMMENDED that the signature be by an authority over the domain of 560 the presentity. In other words, for a user pres:user@example.com, the 561 signator of the NOTIFY SHOULD be the authority for example.com. 563 6.8 Subscriber Processing of NOTIFY Requests 565 The SIP Events framework [2] leaves it to event packages to describe 566 the process followed by the subscriber upon receipt of a NOTIFY 567 request, including any logic required to form a coherent resource 568 state. 570 In this specification, each NOTIFY contains either no presence 571 document, or a document representing the complete and coherent state 572 of the presentity. The presence document in the NOTIFY request with 573 the highest CSeq value is the current one. When no document is 574 present in that NOTIFY, the presence document present in the NOTIFY 575 with the next highest CSeq value is used. Extensions which specify 576 the use of partial state for presentities will need to dictate how 577 coherent state is achieved. 579 6.9 Handling of Forked Requests 581 The SIP Events framework [2] requires each package to describe 582 handling of forked SUBSCRIBE requests. 584 This specification only allows a single dialog to be constructed as a 585 result of emitting an initial SUBSCRIBE request. This guarantees that 586 only a single PA is generating notifications for a particular 587 subscription to a particular presentity. The result of this is that a 588 presentity can have multiple PAs active, but these should be 589 homogeneous, so that each can generate the same set of notifications 590 for the presentity. Supporting heterogeneous PAs, each of which 591 generated notifications for a subset of the presence data, is complex 592 and difficult to manage. Doing so would require the subscriber to act 593 as the aggregator for presence data. This aggregation function can 594 only reasonably be performed by agents representing the presentity. 595 Therefore, if aggregation is needed, it MUST be done in a PA 596 representing the presentity that has access to the total set of user 597 presence to be aggregated. 599 The required processing to guarantee that only a single dialog is 600 established is described in Section 5.4.9 of the SIP Events framework 601 [2]. 603 6.10 Rate of Notifications 605 For reasons of congestion control, it is important that the rate of 606 notifications not become excessive. As a result, it is RECOMMENDED 607 that the PA not generate notifications for a single presentity at a 608 rate faster than once every 5 seconds. 610 6.11 State Agents 612 It is important to realize that the PA function can be colocated with 613 several elements: 615 o It can be co-located with the SIP registrar handling 616 registrations for the presentity (the co-location of the PA 617 within the proxy/registrar is known as a presence server). In 618 this way, the presence server knows the presence of the user 619 through registrations or other means. 621 o It can be co-located with a PUA for that presentity (the co- 622 location of the PA within the PUA is known as an edge presence 623 server). In the case of a single PUA per presentity, the PUA 624 knows the state of the presentity by sheer nature of its co- 625 location. 627 o It can be co-located in any server along the request path. 628 That server can learn the presence state of the presentity by 629 generating its own SUBSCRIBE in order to determine it. In this 630 case, the PA is effectively a Back to Back User Agent (B2BUA) 631 for presence. For this mechanism to be effective, all PUA need 632 to act as PA. Therefore, it is RECOMMENDED that all PUA be 633 capable of acting as a PA for the state that they manipulate, 634 and that they authorize subscriptions that can be 635 authenticated as coming from the domain of the presentity. 637 On occasion, it makes sense for the PA function to migrate from one 638 of these places to another. For example, for reasons of scale, the PA 639 function may reside in the presence server when the PUA is not 640 running, but when the PUA connects to the network, the PA decides to 641 migrate subscriptions to it in order to reduce state in the network. 642 The mechanism for accomplishing the migration is described in Section 643 4.3.5 of [2]. However, packages need to define under what conditions 644 such a migration would take place. 646 A PA MAY choose to migrate subscriptions at any time, through 647 configuration, or through dynamic means. One dynamic means for a 648 presence server to discover that the function can migrate to a PUA is 649 through the REGISTER message. Specifically, if a PUA wishes to 650 indicate support for the PA function, it SHOULD include a contact 651 address in its registration with a caller preferences "methods" 652 parameter listing SUBSCRIBE [7]. This indicates that it is capable of 653 terminating and processing SUBSCRIBE, and therefore may be able to 654 act as a PA. However, just because a PUA indicates it can accept 655 subscriptions, does not mean a PA should migrate the subscriptions 656 there. In particular, a PA SHOULD NOT migrate the subscription if it 657 is composing aggregated presence documents from state received from 658 several PUA. 660 When the PA sends notifications to migrate subscriptions, it should 661 be wary of the load that this may cause. A PA SHOULD rate limit the 662 notifications, in order to avoid a flood of simultaneous re- 663 SUBSCRIBEs from all subscribers. 665 In the case where the subscription has migrated to the presence 666 server, the presence server will simply act as a PA for these new 667 subscriptions. In the case where the subscription has migrated from 668 the presence server to the PUA, the presence server MUST operate like 669 a proxy. Furthermore, it SHOULD implement the SIP Caller preferences 670 extension [7]. Because of the existence of a registered Contact with 671 a "methods" parameter containing SUBSCRIBE, the caller preferences 672 extension will cause the proxy to send the SUBSCRIBEs to that 673 Contact. Assuming it accepts, a 2xx is generated and forwarded to the 674 subscriber. The subscriber will now receive and accept notifications 675 from that PA. Because the "methods" parameter does not convey the set 676 of event packages for which the PUA can accept SUBSCRIBE, it is 677 possible that the PUA doesn't understand the presence event package, 678 and will therefore reject the subscription with a 489. In this case, 679 the presence server SHOULD act as a PA for this subscription and 680 generate its own response. Furthermore, it SHOULD NOT migrate any 681 other subscriptions to this PUA. 683 Migration of subscriptions will still work if the proxy does not 684 support the caller preferences extension. However, the proxy will 685 instead fork the SUBSCRIBE, possibly to Contacts which have not 686 indicated that they support SUBSCRIBE. The result will be 405 687 responses from those UAS. However, the one UAS which does support the 688 method will generate a 2xx class response (assuming the subscription 689 is accepted), and this will be correctly forwarded towards the 690 subscriber based on proxy response processing rules [1]. The penalty 691 of not supporting caller preferences is the additional unneeded SIP 692 traffic. 694 7 Publication 696 The user presence for a presentity can be obtained from any number of 697 different ways. None of these mechanisms are mandated by this 698 specification. The discussion here is for informational purposes 699 only. 701 7.1 Co-location 703 When the PA function is co-located with the PUA, user presence is 704 known directly by the PA. 706 7.2 REGISTER 708 Baseline SIP defines a method that is used by all SIP clients - the 709 REGISTER method. This method allows a UA to inform a SIP network of 710 its current communications addresses (ie., Contact addresses) . 711 Furthermore, multiple UA can independently register Contact addresses 712 for the same SIP URL. These Contact addresses can be SIP URLs, or 713 they can be any other valid URL. 715 Usage of REGISTER information to construct presence is only possible 716 if the PA is co-located with, or shares information with, the SIP 717 registrar. In this case, the combined PA/registrar/proxy is known as 718 a presence server. 720 Using the register information for presence is straightforward. The 721 address of record in the REGISTER (the To field) identifies the 722 presentity. The Contact headers define communications addresses that 723 describe the state of the presentity. The use of the SIP caller 724 preferences extension [7] is RECOMMENDED for use with UAs that are 725 interested in presence. It provides additional information about the 726 Contact addresses that can be used to construct a richer presence 727 document. 729 The presence of a registered Contact with a "methods" parameter [7] 730 listing the MESSAGE method implies that the presentity supports 731 instant messaging as a communications means. 733 The q values from the Contact header [1] can be used to establish 734 priorities amongst the various communications addresses in the 735 Contact headers. 737 The application of registered contacts to presence increases the 738 requirements for authenticity. Therefore, REGISTER requests used by 739 presence user agents MUST be authenticated using either SIP 740 authentication mechanisms, or a hop-by-hop mechanism. 742 7.3 Uploading Presence Documents 744 If a means exists to upload presence documents from PUA to the PA, 745 the PA can act as an aggregator and redistributor of those documents. 746 The PA, in this case, would take the presence documents received from 747 each PUA for the same presentity, and merge the communications means 748 across all of those PUA into a single presence document. Typically, 749 this aggregation would be accomplished through administrator or user 750 defined policies about how the aggregation should be done. 752 The specific means by which a presence document are uploaded to a 753 presence agent are outside the scope of this specification. When a 754 PUA wishes to have direct manipulation of the presence that is 755 distributed to subscribers, direct uploading of presence documents is 756 RECOMMENDED. 758 8 Example message flow 760 This message flow illustrates how the presence server can be the 761 responsible for sending notifications for a presentity. This flow 762 assumes that the watcher has previously been authorized to subscribe 763 to this resource at the server. 765 In this flow, the PUA informs the server about the updated presence 766 information though some non-SIP means. 768 When the value of the Content-Length header is "..." this means that 769 the value should be whatever the computed length of the body is. 771 Watcher Server PUA 772 | F1 SUBSCRIBE | | 773 |------------------>| | 774 | F2 200 OK | | 775 |<------------------| | 776 | F3 NOTIFY | | 777 |<------------------| | 778 | F4 200 OK | | 779 |------------------>| | 780 | | | 781 | | Update presence | 782 | |<------------------ | 783 | | | 784 | F5 NOTIFY | | 785 |<------------------| | 786 | F6 200 OK | | 787 |------------------>| | 789 Message Details 791 F1 SUBSCRIBE watcher->example.com server 793 SUBSCRIBE sip:resource@example.com SIP/2.0 794 Via: SIP/2.0/UDP watcherhost.example.com;branch=z9hG4bKnashds7 795 To: 796 From: ;tag=xfg9 797 Call-ID: 2010@watcherhost.example.com 798 CSeq: 17766 SUBSCRIBE 799 Max-Forwards: 70 800 Event: presence 801 Accept: application/cpim-pidf+xml 802 Contact: 803 Expires: 600 804 Content-Length: 0 806 F2 200 OK example.com server->watcher 808 SIP/2.0 200 OK 809 Via: SIP/2.0/UDP watcherhost.example.com;branch=z9hG4bKnashds7 810 ;received=192.0.2.1 811 To: ;tag=ffd2 812 From: ;tag=xfg9 813 Call-ID: 2010@watcherhost.example.com 814 CSeq: 17766 SUBSCRIBE 815 Event: presence 816 Expires: 600 817 Contact: sip:server.example.com 818 Content-Length: 0 820 F3 NOTIFY example.com server-> watcher 822 NOTIFY sip:user@watcherhost.example.com SIP/2.0 823 Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna998sk 824 From: ;tag=ffd2 825 To: ;tag=xfg9 826 Call-ID: 2010@watcherhost.example.com 827 Event: presence 828 Subscription-State: active;expires=599 829 Max-Forwards: 70 830 CSeq: 8775 NOTIFY 831 Content-Type: application/cpim-pidf+xml 832 Content-Length: .. 834 [PIDF Document] 836 F4 200 OK watcher-> example.com server 838 SIP/2.0 200 OK 839 Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna998sk 840 ;received=192.0.2.2 841 From: ;tag=ffd2 842 To: ;tag=xfg9 843 Call-ID: 2010@watcherhost.example.com 844 CSeq: 8775 NOTIFY 845 Content-Length: 0 847 F5 NOTIFY example.com server -> watcher 849 NOTIFY sip:user@watcherhost.example.com SIP/2.0 850 Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna998sl 851 From: ;tag=ffd2 852 To: ;tag=xfg9 853 Call-ID: 2010@watcherhost.example.com 854 CSeq: 8776 NOTIFY 855 Event: presence 856 Subscription-State: active;expires=543 857 Max-Forwards: 70 858 Content-Type: application/cpim-pidf+xml 859 Content-Length: ... 861 [New PIDF Document] 863 F6 200 OK 865 SIP/2.0 200 OK 866 Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna998sl 867 ;received=192.0.2.2 868 From: ;tag=ffd2 869 To: ;tag=xfg9 870 Call-ID: 2010@watcherhost.example.com 871 CSeq: 8776 NOTIFY 872 Content-Length: 0 874 9 Security considerations 876 There are numerous security considerations for presence. Many are 877 outlined above; this section considers them issue by issue. 879 9.1 Privacy 880 Privacy encompasses many aspects of a presence system: 882 o Subscribers may not want to reveal the fact that they have 883 subscribed to certain users 885 o Users may not want to reveal that they have accepted 886 subscriptions from certain users 888 o Notifications (and fetch results) may contain sensitive data 889 which should not be revealed to anyone but the subscriber 891 Privacy is provided through a combination of hop-by-hop encryption 892 and end-to-end encryption. The hop-by-hop mechanisms provide scalable 893 privacy services, disable attacks involving traffic analysis, and 894 hide all aspects of presence messages. However, they operate based on 895 transitivity of trust, and they cause message content to be revealed 896 to proxies. The end-to-end mechanisms do not require transitivity of 897 trust, and reveal information only to the desired recipient. However, 898 end-to-end encryption cannot hide all information, and is susceptible 899 to traffic analysis. Strong end to end authentication and encryption 900 also requires that both participants have public keys, which is not 901 generally the case. Thus, both mechanisms combined are needed for 902 complete privacy services. 904 SIP allows any hop by hop encryption scheme, but TLS is mandatory to 905 implement for servers. Therefore, it is RECOMMENDED that TLS [6] be 906 used between elements to provide this function. The details for 907 usage of TLS for server-to-server, and client-to-server security are 908 detailed in Section 26.3.2 of SIP [1]. 910 SIP encryption, using S/MIME, MAY be used end-to-end for the 911 transmission of both SUBSCRIBE and NOTIFY requests. 913 9.2 Message integrity and authenticity 915 It is important for the message recipient to ensure that the message 916 contents are actually what was sent by the originator, and that the 917 recipient of the message be able to determine who the originator 918 really is. This applies to both requests and responses of SUBSCRIBE 919 and NOTIFY. This is supported in SIP through end-to-end 920 authentication and message integrity. SIP provides http digest for 921 authentication, and S/MIME for authentication and integrity. 923 9.3 Outbound authentication 925 When local proxies are used for transmission of outbound messages, 926 proxy authentication is RECOMMENDED. This is useful to verify the 927 identity of the originator, and prevent spoofing and spamming at the 928 originating network. 930 9.4 Replay prevention 932 To prevent the replay of old subscriptions and notifications, all 933 signed SUBSCRIBE and NOTIFY requests and responses MUST contain a 934 Date header covered by the message signature. Any message with a date 935 older than several minutes in the past, or more than several minutes 936 into the future, SHOULD be discarded. 938 Furthermore, all signed SUBSCRIBE and NOTIFY requests MUST contain a 939 Call-ID and CSeq header covered by the message signature. A user 940 agent or presence server MAY store a list of Call-ID values, and for 941 each, the highest CSeq seen within that Call-ID. Any message that 942 arrives for a Call-ID that exists, whose CSeq is lower than the 943 highest seen so far, is discarded. 945 Finally, HTTP digest authentication MAY be used to prevent replay 946 attacks. 948 9.5 Denial of service attacks 950 Denial of Service (DOS) attacks are a critical problem for an open, 951 inter-domain, presence protocol. Here, we discuss several possible 952 attacks, and the steps we have taken to prevent them. 954 9.5.1 Distributed DOS attacks through false contacts 956 Unfortunately, presence is a good candidate for Distributed DOS 957 (DDOS) attacks because of its amplification properties. A single 958 SUBSCRIBE message could generate a nearly unending stream of 959 notifications, so long as a suitably dynamic source of presence data 960 can be found. Thus, a simple way to launch an attack is to send 961 subscriptions to a large number of users, and in the Contact header 962 (which is where notifications are sent), place the address of the 963 target. 965 The only reliable way to prevent these attacks is through 966 authentication and authorization. End users will hopefully not accept 967 subscriptions from random unrecognized users. Also, the presence 968 client software could be programmed to warn the user when the Contact 969 header in a SUBSCRIBE is from a domain which does not match that of 970 the From field (which identifies the subscriber). 972 Also, note that as described in [2], if a NOTIFY is not acknowledged 973 or was not wanted, the subscription that generated it is removed. 974 This eliminates the amplification properties of providing false 975 Contact addresses. 977 10 IANA Consideration 979 This specification registers an event package, based on the 980 registration procedures defined in [2]. The following is the 981 information required for such a registration: 983 Package Name: presence 985 Package or Template-Package: This is a package. 987 Published Document: RFC XXXX (Note to RFC Editor: Please fill in 988 XXXX with the RFC number of this specification). 990 Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net. 992 11 Contributors 994 The following individuals were part of the initial team that worked 995 through the technical design of this specification: 997 Jonathan Lennox 998 Columbia University 999 M/S 0401 1000 1214 Amsterdam Ave. 1001 New York, NY 10027-7003 1002 email: lennox@cs.columbia.edu 1004 Robert Sparks 1005 dynamicsoft 1006 5100 Tennyson Parkway 1007 Suite 1200 1008 Plano, Texas 75024 1009 email: rsparks@dynamicsoft.com 1011 Ben Campbell 1012 5100 Tennyson Parkway 1013 Suite 1200 1014 Plano, Texas 75024 1015 email: bcampbell@dynamicsoft.com 1017 12 Acknowledgements 1019 We would like to thank Rick Workman, Adam Roach, Sean Olson, Billy 1020 Biggs, Stuart Barkley, Mauricio Arango, Richard Shockey, Jorgen 1021 Bjorkner, Henry Sinnreich, Ronald Akers, Paul Kyzivat, and Hisham 1022 Khitarbil for their comments and support of this specification. 1024 13 Authors Addresses 1026 Jonathan Rosenberg 1027 dynamicsoft 1028 72 Eagle Rock Avenue 1029 First Floor 1030 East Hanover, NJ 07936 1031 email: jdrosen@dynamicsoft.com 1033 Dean Willis 1034 dynamicsoft 1035 5100 Tennyson Parkway 1036 Suite 1200 1037 Plano, Texas 75024 1038 email: dwillis@dynamicsoft.com 1040 Henning Schulzrinne 1041 Columbia University 1042 M/S 0401 1043 1214 Amsterdam Ave. 1044 New York, NY 10027-7003 1045 email: schulzrinne@cs.columbia.edu 1047 Christian Huitema 1048 Microsoft Corporation 1049 One Microsoft Way 1050 Redmond, WA 98052-6399 1051 email: huitema@microsoft.com 1053 Bernard Aboba 1054 Microsoft Corporation 1055 One Microsoft Way 1056 Redmond, WA 98052-6399 1057 email: bernarda@microsoft.com 1059 David Gurle 1060 Microsoft Corporation 1061 One Microsoft Way 1062 Redmond, WA 98052-6399 1063 email: dgurle@microsoft.com 1065 David Oran 1066 Cisco Systems 1067 170 West Tasman Dr. 1068 San Jose, CA 95134 1069 email: oran@cisco.com 1071 Full Copyright Statement 1073 Copyright (c) The Internet Society (2002). All Rights Reserved. 1075 This document and translations of it may be copied and furnished to 1076 others, and derivative works that comment on or otherwise explain it 1077 or assist in its implementation may be prepared, copied, published 1078 and distributed, in whole or in part, without restriction of any 1079 kind, provided that the above copyright notice and this paragraph are 1080 included on all such copies and derivative works. However, this 1081 document itself may not be modified in any way, such as by removing 1082 the copyright notice or references to the Internet Society or other 1083 Internet organizations, except as needed for the purpose of 1084 developing Internet standards in which case the procedures for 1085 copyrights defined in the Internet Standards process must be 1086 followed, or as required to translate it into languages other than 1087 English. 1089 The limited permissions granted above are perpetual and will not be 1090 revoked by the Internet Society or its successors or assigns. 1092 This document and the information contained herein is provided on an 1093 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1094 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1095 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1096 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1097 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1099 14 Normative References 1101 [1] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation 1102 protocol," Internet Draft, Internet Engineering Task Force, Feb. 1103 2002. Work in progress. 1105 [2] A. Roach, "SIP-specific event notification," Internet Draft, 1106 Internet Engineering Task Force, Mar. 2002. Work in progress. 1108 [3] D. Crocker et al. , "Common presence and instant messaging 1109 (CPIM)," Internet Draft, Internet Engineering Task Force, Nov. 2001. 1110 Work in progress. 1112 [4] S. Bradner, "Key words for use in RFCs to indicate requirement 1113 levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 1115 [5] H. Sugano, S. Fujimoto, et al. , "CPIM presence information data 1116 format," Internet Draft, Internet Engineering Task Force, May 2002. 1117 Work in progress. 1119 [6] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246, 1120 Internet Engineering Task Force, Jan. 1999. 1122 [7] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and 1123 callee capabilities," Internet Draft, Internet Engineering Task 1124 Force, Nov. 2001. Work in progress. 1126 15 Informative References 1128 [8] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and 1129 instant messaging," RFC 2778, Internet Engineering Task Force, Feb. 1130 2000. 1132 [9] J. Arkko, P. Calhoun, et al. , "Diameter base protocol," 1133 Internet Draft, Internet Engineering Task Force, Apr. 2002. Work in 1134 progress. 1136 [10] C. Rigney, S. Willens, A. Rubens, and W. Simpson, "Remote 1137 authentication dial in user service (RADIUS)," RFC 2865, Internet 1138 Engineering Task Force, June 2000. 1140 [11] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, and A. 1141 Sastry, "The COPS (common open policy service) protocol," RFC 2748, 1142 Internet Engineering Task Force, Jan. 2000. 1144 [12] J. Rosenberg, "A SIP event sub-package for watcher information," 1145 Internet Draft, Internet Engineering Task Force, Mar. 2002. Work in 1146 progress. 1148 [13] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging 1149 / presence protocol requirements," RFC 2779, Internet Engineering 1150 Task Force, Feb. 2000.