idnits 2.17.1 draft-ietf-impp-reqts-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1020 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Day' is defined on line 542, but no explicit reference was found in the text == Unused Reference: '1998' is defined on line 542, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'Day' -- Duplicate reference: draft-day-rpim, mentioned in '1998', was also mentioned in 'Day'. -- Possible downref: Normative reference to a draft: ref. '1998' == Outdated reference: A later version (-03) exists of draft-ietf-impp-model-00 ** Downref: Normative reference to an Informational draft: draft-ietf-impp-model (ref. 'Model') ** Obsolete normative reference: RFC 2426 (Obsoleted by RFC 6350) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Mark Day 2 Expires: November 17, 1999 Lotus 4 Sonu Aggarwal 5 Microsoft 7 Gordon Mohr 8 Activerse 10 Jesse Vincent 12 Instant Messaging / Presence Protocol Requirements 13 draft-ietf-impp-reqts-00.txt 15 [IMPP LIST DISCUSSION DRAFT 01, 1999-05-17] 17 1. Status of this Memo 19 This document is an Internet-Draft and is in full conformance with all 20 provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 2. Abstract 38 Presence and Instant Messaging have recently emerged as a new medium 39 of communications over the Internet. Presence is a means for finding, 40 retrieving, and subscribing to changes in the presence information 41 (e.g. "online" or "offline") of other users. Instant messaging is a 42 means for sending small, simple messages that are delivered 43 immediately to online users. 45 Applications of presence and instant messaging currently use 46 independent, non-standard and non-interoperable protocols developed by 47 various vendors. The goal of the Instant Messaging and Presence 48 Protocol (IMPP) Working Group is to define a standard protocol so that 49 independently developed applications of instant messaging and/or 50 presence can interoperate across the Internet. This document defines a 51 minimal set of requirements that IMPP must meet. 53 3. Contents 55 1. Status of this Memo 56 2. Abstract 57 3. Contents 58 4. Terminology 59 5. Shared Requirements 60 5.1. Namespace and Administration 61 5.2. Scalability 62 5.3. Access Control 63 5.4. Network Topology 64 5.5. Message Encryption and Authentication 65 6. Additional Requirements for PRESENCE INFORMATION 66 6.1. Common Presence Format 67 6.2. Presence Lookup and Notification 68 6.3. Presence Caching and Replication 69 7. Additional Requirements for INSTANT MESSAGES 70 7.1. Common Message Format 71 7.2. Reliability 72 8. Open Issues and ToDos for this Draft 73 9. Security Considerations 74 9.1. Requirements related to SUBSCRIPTIONS 75 9.2. Requirements related to NOTIFICATION 76 9.3. Requirements related to receiving a NOTIFICATION 77 9.4. Requirements related to INSTANT MESSAGES 78 10. References 79 11. Authors' Addresses 80 12. Appendix: Security Expectations and Deriving Requirements 81 12.1. Presence Information 82 12.1.1. Subscription 83 12.1.2. Publication 84 12.1.3. Publication for Notification 85 12.1.4. Receiving a Notification 86 12.2. Instant Messaging 87 12.2.1. Named Instant Messaging 88 12.2.2 Anonymous Instant Messaging 89 12.2.3 Administrator Expectations 91 4. Terminology 93 The following terms are defined in [Model] and are used with those 94 definitions in this document: 96 ACCESS RULES 97 FETCHER 98 INSTANT INBOX 99 INSTANT MESSAGE 100 NOTIFICATION 101 PRESENCE INFORMATION 102 PRESENCE SERVICE 103 PRESENTITY 104 PRINCIPAL 105 PROXY 106 SERVER 107 STATUS 108 SUBSCRIBER 109 SUBSCRIPTION 110 WATCHER 112 The terms MUST, SHOULD, and MAY are used with the meaning defined in 113 [RFC 2119]. 115 The following terms are used in this document and defined here: 117 ADMINISTRATOR: A PRINCIPAL with authority over local computer and 118 network resources, who manages local DOMAINS or FIREWALLS. For security 119 and other purposes, an ADMINISTRATOR often needs or wants to impose 120 restrictions on network usage based on traffic type, content, volume, 121 or endpoints. A PRINCIPAL's ADMINISTRATOR has authority over 122 some or all of that PRINCIPAL's computer and network resources. 124 DOMAIN: A portion of a NAMESPACE. 126 ENTITY: Any of PRESENTITY, SUBSCRIBER, FETCHER, or WATCHER (all 127 defined in [Model]). 129 FIREWALL: A point of administrative control over connectivity. 130 Depending on the policies being enforced, parties may need to take 131 unusual measures to establish communications through the FIREWALL. 133 INTENDED RECIPIENT: The PRINCIPAL to whom the sender of an INSTANT 134 MESSAGE is sending it. 136 NAMESPACE: The system that maps from a name of an ENTITY to the 137 concrete implementation of that ENTITY. A NAMESPACE MAY be composed of 138 a number of distinct DOMAINS. 140 OFFLINE: A STATUS indicating that any associated INSTANT INBOX cannot 141 serve as a means to convey an INSTANT MESSAGE to its PRINCIPAL. 143 ONLINE: A STATUS indicating that any associated INSTANT INBOX may be 144 able to serve as a means to convey an INSTANT MESSAGE to its 145 PRINCIPAL. Note that an ONLINE status may be further refined to 146 indicate "busy," "do not disturb," and the like. 148 OUT OF CONTACT: A situation in which som ENTITY and the PRESENCE 149 SERVICE cannot communicate. 151 SUCCESSFUL DELIVERY: A situation in which an INSTANT MESSAGE was 152 transmitted to an INSTANT INBOX for the INTENDED RECIPIENT, and the 153 INSTANT INBOX acknowledged its receipt. SUCCESSFUL DELIVERY usually 154 also implies that an INBOX USER AGENT has handled the message in a 155 way chosen by the PRINCIPAL. However, SUCCESSFUL DELIVERY does not 156 imply that the message was actually seen by that PRINCIPAL. 158 5. Shared Requirements 160 5.1. Namespace and Administration 162 5.1.1. The protocol(s) MUST define a single NAMESPACE. In general, an 163 ENTITY that makes PRESENCE INFORMATION available can receive INSTANT 164 MESSAGES, and vice versa. 166 5.1.2. The administration and naming of ENTITIES within a given DOMAIN 167 MUST be able to operate independently of actions in any other DOMAIN. 169 5.1.3. The protocol MUST allow for an arbitrary number of DOMAINS 170 within the NAMESPACE. 172 5.2. Scalability 174 5.2.1. It MUST be possible for ENTITIES in one DOMAIN to interoperate 175 with ENTITIES in another DOMAIN, without the DOMAINS having previously 176 been aware of each other. 178 5.2.2. The protocol MUST continue to meet its other functional and 179 performance requirements even when there are millions of ENTITIES 180 within a single DOMAIN. 182 5.2.3. The protocol MUST continue to meet its other functional and 183 performance requirements even when there are millions of DOMAINS 184 within the single NAMESPACE. 186 5.2.4. The protocol MUST continue to meet its other functional and 187 performance requirements even when every single SUBSCRIBER has 188 SUBSCRIPTIONS to hundreds of PRESENTITIES. 190 5.2.5. The protocol MUST continue to meet its other functional and 191 performance requirements even when thousands of distinct SUBSCRIBERS 192 have SUBSCRIPTIONS to a single PRESENTITY. 194 5.2.6. The protocol MUST continue to meet its other functional and 195 performance requirements even when every single SUBSCRIBER has 196 SUBSCIPTIONS to PRESENTITIES in hundreds of distinct DOMAINS. 198 5.2.7. The transport of INSTANT MESSAGES SHOULD be sufficiently rapid 199 to allow for comfortable conversational exchanges of short messages. 201 5.2.8. When a PRESENTITY changes its PRESENCE INFORMATION, any 202 SUBSCRIBER to that information MUST be notified of the changed 203 information, except when prevented by ACCESS RULES, as rapidly as an 204 INSTANT MESSAGE would be delivered. 206 5.3. Access Control 208 5.3.1. The PRINCIPAL controlling a PRESENTITY MUST be able to control 209 which FETCHERS can observe its PRESENCE INFORMATION. 211 5.3.2. The PRINCIPAL controlling a PRESENTITY MUST be able to control 212 which SUBSCRIBERS can have SUBSCRIPTIONS to its PRESENCE INFORMATION. 214 5.3.3. The PRINCIPAL controlling a PRESENTITY MUST be able to control 215 what PRESENCE INFORMATION a particular WATCHER will see, either by 216 fetching or NOTIFICATION. 218 5.3.4. The PRINCIPAL controlling a PRESENTITY MUST be able to control 219 which other PRINCIPALS, if any, can update the PRESENCE INFORMATION of 220 that PRESENTITY. 222 5.3.5. The PRINCIPAL controlling an INSTANT INBOX MUST be able to 223 control which other PRINCIPALS, if any, can send INSTANT MESSAGES to 224 that INSTANT INBOX. 226 5.3.6. The PRINCIPAL controlling an INSTANT INBOX MUST be able to 227 control which other PRINCIPALS, if any, can read INSTANT MESSAGES from 228 that INSTANT INBOX. 230 5.3.7. Access control MUST be independent of presence: the PRESENCE 231 SERVICE MUST be able to make access control decisions even when the 232 PRESENTITY is OUT OF CONTACT. 234 5.4. Network Topology 236 5.4.1. The protocol MUST allow the creation of a SUBSCRIPTION both 237 directly and via intermediaries, such as PROXIES. 239 5.4.2. The protocol MUST allow the sending of a NOTIFICATION both 240 directly and via intermediaries, such as PROXIES. 242 5.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE both 243 directly and via intermediaries, such as PROXIES. 245 5.4.4 The protocol's network traffic MUST be sufficiently well- 246 characterized that ADMINISTRATORS can apply local policies via 247 FIREWALLS. 249 5.4.5 The protocol proxying facilities and transport practices MUST 250 allow ADMINISTRATORS ways to enable protocol activity through existing 251 and commonly-deployed FIREWALLS. 253 5.5. Message Encryption and Authentication 255 5.5.1. The protocol MUST provide means to ensure confidence that a 256 received message (NOTIFICATION or INSTANT MESSAGE) has not been 257 corrupted or tampered with. 259 5.5.2. The protocol MUST provide means to ensure confidence that a 260 received message (NOTIFICATION or INSTANT MESSAGE) has not been 261 recorded and played back by an adversary. 263 5.5.3. The protocol MUST provide means to ensure that a sent message 264 (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES that 265 the sender allows. 267 5.5.4. The protocol MUST allow any client to use the means to ensure 268 non-corruption, non-playback, and privacy, but the protocol MUST NOT 269 require that all clients use these means at all times. 271 6. Additional Requirements for PRESENCE INFORMATION 273 The requirements in section 6 are applicable only to PRESENCE 274 INFORMATION and not to INSTANT MESSAGES. 276 6.1. Common Presence Format 278 6.1.1. All ENTITIES MUST produce and consume at least a common base 279 format for PRESENCE INFORMATION. 281 6.1.2. The common presence format MUST include a means to uniquely 282 identify the PRESENTITY whose PRESENCE INFORMATION is reported. 284 6.1.3. The common presence format MUST include a means to represent at 285 least the following STATUS conditions: online/offline, and 286 available/busy/idle. 288 6.1.4. The common presence format MUST include a means to encapsulate 289 contact information for the PRESENTITY's PRINCIPAL (if applicable), 290 such as email address, telephone number, postal address, or the like. 292 6.1.5. There MUST be a means of extending the common presence format 293 to represent additional information not included in the common format, 294 without undermining or rendering invalid the fields of the common 295 format. 297 6.1.6. The working group MUST define the extension and registration 298 mechanisms for presence information schema. 300 6.1.7. The presence format SHOULD be based on IETF-standards such as 301 vCard [RFC 2426] if possible. 303 6.2. Presence Lookup and Notification 305 6.2.1. A FETCHER MUST be able to fetch a PRESENTITY's PRESENCE 306 INFORMATION even when the PRESENTITY is not in communication with the 307 PRESENCE SERVICE. 309 6.2.2. A SUBSCRIBER MUST be able to request a SUBSCRIPTION to a 310 PRESENTITY's PRESENCE INFORMATION, even when the PRESENTITY is not in 311 communication with the PRESENCE SERVICE. 313 6.2.3. If the PRESENCE SERVICE has SUBSCRIPTIONS for a PRESENTITY's 314 PRESENCE INFORMATION, and that PRESENCE INFORMATION changes, the 315 PRESENCE SERVICE MUST deliver a NOTIFICATION to each SUBSCRIBER, 316 unless prevented by the PRESENTITY's ACCESS RULES. 318 6.2.4. The protocol MUST provide a mechanism for detecting when a 319 PRESENTITY or SUBSCRIBER goes OUT OF CONTACT. 321 6.2.5. The protocol MUST NOT depend on a PRESENTITY or SUBSCRIBER 322 gracefully telling the service that it will no longer be in 323 communication, since a PRESENTITY or SUBSCRIBER may go OUT OF CONTACT 324 due to unanticipated failures. 326 6.3. Presence Caching and Replication 328 6.3.1. The protocol MUST include mechanisms to allow PRESENCE 329 INFORMATION to be cached. 331 6.3.2. The protocol MUST include mechanisms to allow cached PRESENCE 332 INFORMATION to be updated when the master copy changes. 334 6.3.3 The protocol caching facilities MUST NOT circumvent established 335 ACCESS RULES or restrict choice of authentication/encryption 336 mechanisms. 338 7. Additional Requirements for INSTANT MESSAGES 340 The requirements in section 7 are applicable only to INSTANT MESSAGES 341 and not to PRESENCE INFORMATION. 343 7.1. Common Message Format 345 7.1.1. All ENTITIES sending and receiving INSTANT MESSAGES MUST 346 implement at least a common base format for INSTANT MESSAGES. 348 7.1.2. The common base format for an INSTANT MESSAGE MUST identify the 349 sender and intended recipient. 351 7.1.3. The common message format MUST include a return address for the 352 receiver to reply to the sender with another INSTANT MESSAGE. 354 7.1.4. The common message format SHOULD include standard forms of 355 return addresses or contact means for media other than INSTANT 356 MESSAGES, such as telephone numbers or email addresses. 358 7.1.5. The common message format MUST permit the encoding and 359 identification of the message payload to allow for non-ASCII or 360 encrypted content. 362 7.1.6. The common message format MUST provide for the association of a 363 reply with the message that prompted that reply. 365 7.1.7. This reply-association mechanism MUST allow a user agent to 366 organize instant message exchanges into conversational threads. 368 7.1.8. The common message format SHOULD be based on IETF-standard MIME 369 [RFC 2045]. 371 7.2. Reliability 373 7.2.1. The protocol MUST inform the sender of the INSTANT MESSAGE's 374 SUCCESSFUL DELIVERY or reasons for failure. 376 8. Open Issues and ToDos for this Draft 378 Is it required that there be a one-to-one mapping of the existing 379 email namespace onto the IMPP NAMESPACE? 381 9. Security Considerations 383 Security considerations are addressed in section 5.3, Access Control, 384 and section 5.5, Message authentication and encryption. 386 This section describes further security-related requirements that the 387 protocol must meet. 389 The security requirements were derived from a set of all-encompassing 390 "security expectations" that were then evaluated for practicality and 391 implementability and translated into requirements. In the appendix, 392 we describe the expectations and the process used to transform them 393 into requirements. In this section, we simply list the consolidated 394 set of derived requirements. 396 The following are the requirements derived from the expectations 397 above. Note that in the requirements, ADMINISTRATORs MAY have 398 privileges beyond those allowed to PRINCIPALs referred to in the 399 requirements. (Unless otherwise noted, the individual expectations 400 specifically refer to PRINCIPALs.) It is up to individual 401 implementations to control administrative access and implement the 402 security privileges of ADMINISTRATORs without compromising the 403 requirements made on PRINCIPALs. 405 Unless noted otherwise, A,B,C are all names of non-ADMINISTRATOR 406 PRINCIPALS. 408 9.1. Requirements related to SUBSCRIPTIONS 410 When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION: 412 9.1.1. The protocol MUST provide A means of identifying and 413 authenticating that the PRESENTITY subscribed to is controlled by B. 415 9.1.2. If A so chooses, the protocol SHOULD NOT make A's SUBSCRIPTION 416 to B obvious to a third party C. 418 9.1.3. The protocol MUST provide B with means of allowing an 419 unauthenticated subscription by A. 421 9.1.4. The protocol MUST provide A means of verifying the accurate 422 receipt of the content B chooses to disclose to A. 424 9.1.5. B MUST inform A if B refuses A's SUBSCRIPTION. 426 9.1.6. The protocol MUST NOT let any third party C force A to subscribe 427 to B's PRESENCE INFORMATION without A's consent. 429 9.1.7. A MUST be able to cancel her SUBSCRIPTION to B's PRESENCE 430 INFORMATION at any time and for any reason. When A does so, B stops 431 informing A of changes to its PRESENCE INFORMATION. 433 9.1.8. The protocol MUST NOT let a third party C cancel A's 434 subscription to B. 436 9.1.9. If A's subscription to B is cancelled, the service SHOULD inform 437 A of the cancellation. 439 9.1.10. A SHOULD be able to determine the status of A's subscription to 440 B, at any time. 442 9.1.11. The protocol MUST provide B means of learning about A's 443 SUBSCRIPTION to B, both at the time of establishing the SUBSCRIPTION 444 and afterwards. 446 9.1.12. The protocol MUST provide B means of identifying and 447 authenticating the SUBSCRIBER's PRINCIPAL, A. 449 9.1.13. It MUST be possible for B to prevent any particular PRINCIPAL 450 from subscribing. 452 9.1.14. It MUST be possible for B to prevent anonymous PRINCIPALS from 453 subscribing. 455 9.1.15. It MUST be possible for B to deny A's subscription while 456 appearing to A as if the subscription has been granted ("polite 457 blocking"). The protocol MUST NOT mandate B to service subscriptions 458 that it denies in this manner. 460 9.1.16. B MUST be able to cancel A's subscription at will. 462 9.1.17. B's ADMINISTRATOR MUST have the option to determine the set of 463 PRINCIPALS or their PROXIES subscribed to B at any time. 465 9.1.18. B's ADMINISTRATOR MUST have the option to manage all aspects of 466 B's presence information. 468 9.1.19. B's ADMINISTRATOR MUST have the option to control who can 469 access B's presence information and exchange instant messages with B. 471 9.2. Requirements related to NOTIFICATION 473 When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to 474 another PRINCIPAL A: 476 9.2.1. The protocol MUST provide means of ensuring that only the 477 PRINCIPAL A being sent the NOTIFICATION by B can read the 478 NOTIFICATION. 480 9.2.2. A SHOULD receive all NOTIFICATIONS intended for her. 482 9.2.3. It MUST be possible for B to prevent A from receiving 483 notifications, even if A is ordinarily permitted to see such 484 notifications. It MUST be possible for B to, at its choosing, notify 485 different subscribers differently, through different notification 486 mechanisms or through publishing different content. This is a 487 variation on "polite blocking". 489 9.2.4. The protocol MUST provide means of protecting B from another 490 PRINCIPAL C "spoofing" notification messages about B. 492 9.3. Requirements related to receiving a NOTIFICATION 494 When a PRINCIPAL A receives a notification message from another 495 principal B, conveying PRESENCE INFORMATION, 497 9.3.1. The protocol MUST provide A means of verifying that the 498 presence information is accurate, as sent by B. 500 9.3.2. The protocol MUST ensure that A only receives NOTIFICATIONS 501 from entities she's subscribed to. 503 9.3.3. The protocol MUST provide A means of verifying that the 504 notification was sent by B. 506 9.4. Requirements related to INSTANT MESSAGES 508 When a user A sends an INSTANT MESSAGE M to another user B, 510 9.4.1. A MUST receive confirmation of non-delivery. 512 9.4.2. If M is delivered, B MUST receive the message only once. 514 9.4.3. The protocol MUST provide B means of verifying that A sent the message. 516 9.4.4. B MUST be able to reply to the message via another instant message. 518 9.4.5. The protocol MUST NOT always require A to reveal A's IP 519 address, for A to send an instant message. 521 9.4.6. The protocol MUST provide A means of ensuring that no other 522 PRINCIPAL C can see the content of M. 524 9.4.7. The protocol MUST provide A means of ensuring that no other 525 PRINCIPAL C can tamper with M. 527 9.4.8. B MUST be able to read M. 529 9.4.9. The protocol MUST allow A to sign the message, using existing 530 standards for digital signatures. 532 9.4.10. The protocol MUST provide B means of verifying M's integrity. 534 9.4.11. B MUST be able to prevent A from sending him future messages 536 10. References 538 [Aggarwal et al., 1998] 539 S. Aggarwal, M. Day, G. Mohr, "Presence Information Protocol 540 Requirements", draft-aggarwal-pip-reqts-00.txt 542 [Day, 1998] 543 M. Day, "Requirements for Presence and Instant Messaging", 544 draft-day-rpim-00.txt 546 [Model] 547 M. Day and J. Rosenberg. "A Model for Presence." 548 draft-ietf-impp-model-00.txt. 550 [Calsyn & Dusseault, 1998] 551 M. Calsyn and L. Dusseault. "Presence Information Protocol 552 Requirements", draft-dusseault-pipr-00.txt 554 [RFC 2426] 555 F. Dawson and T. Howes. "vCard MIME Directory Profile." RFC 556 2426, September 1998. 558 [RFC 2045] 559 N. Freed and N. Borenstein. "Multipurpose Internet Mail Extensions 560 (MIME) - Part One: Format of Internet Message Bodies." RFC 2045, 561 November 1996. 563 [RFC 2119] 564 S. Bradner. "Key Words for Use in RFCs to Indicate Requirement 565 Levels." RFC 2119, March 1997. 567 11. Authors' Addresses 569 Mark Day 570 571 Lotus Development Corporation 572 55 Cambridge Parkway 573 Cambridge, MA 02142 574 USA 576 Sonu Aggarwal 577 578 Microsoft Corporation 579 One Microsoft Way 580 Redmond, WA 98052 581 USA 583 Gordon Mohr 584 585 Activerse, Inc. 586 1301 W. 25th St Suite 500 587 Austin, TX 588 USA 590 Jesse Vincent 591 592 22 Kirkstall Rd 593 Newton, MA 02160 594 USA 596 12. Appendix: Security Expectations and Deriving Requirements 598 This appendix is based on the security expectations discussed on the 599 impp mailing list and assembled by Jesse Vincent. The original form 600 of numbering has been preserved in this appendix (so there are several 601 different items labeled B1, for example). The derived requirements 602 have new numbers that are consistent with the main body of the 603 document. 605 12.1. PRESENCE INFORMATION 607 In the case of PRESENCE INFORMATION, the controlling PRINCIPAL's 608 privacy interests are paramount; we agreed that "polite blocking" 609 (denying without saying that the subscription is denied, or providing 610 false information) should be possible. 612 12.1.1. Subscription 614 When a user Alice subscribes to another person, Bob's presence info, 615 Alice expects: 617 A1. the PRESENTITY's PRINCIPAL, B, is identifiable and authenticated 619 Discussion: Stands as a requirement. Note that the protocol should 620 provide Alice the capability of authenticating, without requiring 621 that Alice authenticate every SUBSCRIPTION. This caveat is made 622 necessary by performance concerns, among others, and applies to 623 many of the other requirements derived below. [Requirement 9.1.1] 625 A2. no third party will know that A has subscribed to B. 627 Discussion: This is somewhat unreasonable to enforce as is. For 628 example, in some topologies, nothing can prevent someone doing 629 traffic analysis to deduce that A has subscribed to B. We should 630 merely require that the protocol not expose subscription 631 information in any obvious manner. [Requirement 9.1.2] 633 A3. A has the capability to subscribe to B's presence without B's 634 knowledge, if B permits anonymous subscriptions. 636 Discussion: An "anonymous subscription" above can have two 637 implications - (i) B may allow an unauthenticated subscription by 638 A, and (ii) B may be unaware of A's stated identity. Requirement 639 (i) is reasonable [Requirement 9.1.3], but (ii) doesn't appear to 640 be a core requirement -- it can be adequately simulated via a 641 subscription pseudonym. 643 A4. A will accurately receive what B chooses to disclose to A 644 regarding B's presence. 646 Discussion: Stands as a requirement, with the "optional" 647 caveat. [Requirement 9.1.4] 649 A5. B will inform A if B refuses A's subscription 651 Discussion: Stands as a requirement. [Requirement 9.1.5] 653 A6. No third party, C can force A to subscribe to B's presence without 654 A's consent. 656 Discussion: Stands as a requirement. [Requirement 9.1.6] 658 A7. A can cancel her subscription to B's presence at any time and for 659 any reason. When A does so, she will receive no further information 660 about B's presence information. 662 Discussion: This essentially stands. However, implementations may 663 have to contend with a timing window where A receives, after 664 sending her cancellation request, a notification sent by B before 665 B received the cancellation request. Therefore, the requirement 666 should focus on B's ceasing to send presence information, rather 667 than A's ceasing to receive it. [Requirement 9.1.7] 669 A8. no third party, C, can cancel A's subscription to B. 671 Discussion: Stands, although the administrative exception does 672 apply. [Requirement 9.1.8] 674 A9. A is notified if her subscription to B is cancelled for any reason. 676 Discussion: Although the intent is reasonable, there are a number 677 of scenarios (e.g. overburdened server, clogged network, server 678 crash) where delivering a notification to A of the cancellation 679 is undesirable or impossible. Therefore, the service should make 680 an attempt to inform, but this is not required. [Requirement 9.1.9] 682 Bob expects: 684 B1. B will be informed that A subscribed to B's presence information, 685 as long as A has not subscribed anonymously. 687 Discussion: This essentially stands. However, B can also choose to 688 determine A's subscription after the fact. [Requirement 9.1.10] 690 B2. A is identifiable and authenticated. 692 Discussion: This stands as a requirement. [Requirement 9.1.11] 694 B3. B can prevent a particular user, D, from subscribing. 696 Discussion: This stands as a requirement. [Requirement 9.1.12] 698 B4. B can prevent anonymous users from subscribing. 700 Discussion: This stands as a requirement. [Requirement 9.1.13] 702 B5. B's presence information is not republished by A to a third party, 703 E, who does not. 705 Discussion: This is practically impossible to enforce, so it is 706 omitted from the requirement set. 708 B6. B can deny A's subscription without letting A know that she's been 709 blocked. 711 Discussion: This "polite blocking" capability essentially stands; 712 accepting a "denied" subscription should bear no implication on 713 servicing it for status notifications. [Requirement 9.1.14] 715 B7. B can cancel A's subscription at will. 717 Discussion: Stands as a requirement. [Requirement 9.1.15] 719 Charlie, bob's network administrator expects: 721 C1. C knows who is subscribed to B at all times. 723 Discussion: Administrators should be able to determine who is 724 subscribed, but needn't be continuously informed of the list of 725 subscribers. Also, in some cases user agents (e.g. proxies) may 726 have subscribed on behalf of users, and in these cases the 727 administrator can only determine the identity of these agents, not 728 their users. [Requirement 9.1.16] 730 C2. C can manage all aspects of A's presence information. 732 Discussion: This stands as a requirement. [Requirement 9.1.17] 734 C3. C can control who can access A's presence information and exchange 735 instant messages with A. 737 Discussion: This stands in principle, but C should be able to waive 738 these capabilities if C desires. [Requirement 9.1.18] 740 12.1.2. Publication 742 The publisher of status information, Bob, expects: 744 B1. That information about B is not provided to any entity without B's 745 knowledge and consent. 747 Discussion: This is nearly impossible to accomplish, so it is 748 omitted from the requirements. 750 12.1.3. Publication for Notification 752 When information is published for notification, B expects: 754 B1. only a person being sent a notification, A, can read the 755 notification. 757 Discussion: Stands as a requirement. [Requirement 9.2.1] 759 B2. A reliably receives all notifications intended for her. 761 Discussion: This stands, although "Reliably" is a little strong 762 (e.g. network outages, etc.). [Requirement 9.2.2] 764 B3. B can prevent A from receiving notifications, even if A is 765 ordinarily permitted to see such notifications. This is a variation 766 on "polite blocking." 768 Discussion: This stands as a requirement. Also incorporated into 769 this requirement is the notifications equivalent of the next 770 expectation, B4. [Requirement 9.2.3] 772 B4. B can provide two interested parties A and E with different status 773 information at the same time. (B could represent the same event 774 differently to different people.) 776 Discussion: This stands as a requirement; it has been incorporated 777 into the corresponding requirement for B3 above. 779 B5. B expects that malicious C cannot spoof notification messages about 780 B. 782 Discussion: Stands in principle, but it should be optional for B. 783 [Requirement 9.2.4] 785 12.1.4. Receiving a Notification 787 When Alice receives a notification, the recipient, Alice, expects: 789 A1. That the notification information is accurate, truthful. 791 Discussion: Stands in principle, although being "truthful" can't be 792 a requirement, and the verification is optional for Alice. 793 [Requirement 9.3.1] 795 A2. That information about subscriptions remains private; people do 796 not learn that A's subscription to B's information exists by watching 797 notifications occur. 799 Discussion: This is omitted from the requirements, as traffic 800 analysis, even of encrypted traffic, can convey this information in 801 some situations. 803 A3. That she only receives notifications of things she's subscribed to. 805 Discussion: Stands as a requirement. [Requirement 9.3.2] 807 A4. Notifications come from the apparent sender, B. 809 Discussion: Stands in principle, although the verification should 810 be optional for A. [Requirement 9.3.3] 812 A5. A can tell the difference between a message generated by the user, 813 and a message legitimately generated by the agent on behalf of the 814 user. 816 Discussion: This could be quite difficult to enforce and could 817 unduly restrict usage scenarios; this is omitted from the 818 requirements. 820 A6. That information given by agents on behalf of users can also be 821 expected to be truthful, complete, and legitimately offered; the user 822 permitted the agent to publish these notifications. 824 Discussion: This is difficult to enforce and is omitted from the 825 requirements. 827 A7. A can prove that a notification from B was delivered in a timely 828 fashion and can prove exactly how long the message took to be 829 delivered. 831 Discussion: This is difficult to enforce and is omitted from the 832 requirements. For example, such proof may entail global time 833 synchronization mechanisms (since any system clocks have associated 834 unreliability), which is outside the scope of this effort. 836 A8. A can prove that B was indeed the sender of a given message. 838 Discussion: This is a duplication of expectation A4 above and is 839 reflected in the corresponding requirement 9.3.3. 841 12.2. INSTANT MESSAGEs 843 12.2.1. Named Instant Messaging 845 When a user Alice sends an instant message M to another user Bob: 847 Alice expects that she: 849 A1. will receive notification of non-delivery 851 Discussion: Stands as a requirement. [Requirement 9.4.1] 853 Alice expects that Bob: 855 B1. will receive the message 857 Discussion: covered by A1 and is reflected in the corresponding 858 requirement 9.4.1. 860 B2. will receive the message quickly 862 Discussion: Stands as a requirement, although this is also covered 863 elsewhere (in the non-security requirements), so this is omitted 864 from the security requirements. 866 B3. will receive the message only once 868 Discussion: Stands as a requirement. [Requirement 9.4.2] 870 B4. will be able to verify that Alice sent the message 872 Discussion: Stands as a requirement. [Requirement 9.4.3] 874 B5. will not know whether there were BCCs 876 Discussion: Emulating e-mail conventions and social protocols is 877 not a core goal of this effort, and therefore references to 878 standard mail fields are omitted from the requirements. 880 B6. will be able to reply to the message 882 Discussion: Stands in principle; the recipient should be able to 883 reply via an instant message. [Requirement 9.4.4] 885 B7. will know if he was a bcc recipient 887 Discussion: Omitted, as noted above. 889 B8. will not be able to determine any information about A (such as her 890 location or IP address) without A's knowledge and consent. 892 Discussion: "Any information about A" is too general; the 893 requirement should focus on IP address. Further, "without A's 894 knowledge and consent" may be overkill. [Requirement 9.4.5] 896 Alice expects that no other user Charlie will be able to: 898 C1. see the content of M 900 Discussion: Stands in principle, although this should not be 901 mandated for all IM communication. [Requirement 9.4.6] 903 C2. tamper with M 905 Discussion: Stands, with the same caveat as above. 906 [Requirement 9.4.7] 908 C3. know that M was sent 910 Discussion: It is impossible to prevent traffic analysis, and this 911 is therefore omitted from the requirements. 913 When a user Bob receives an instant message M from another user Alice: 915 Bob expects that Bob: 917 D1. will be able to read M 919 Discussion: Stands as a requirement. [Requirement 9.4.8] 921 D2. will be able to verify M's authenticity (both Temporal and the 922 sender's identity) 924 Discussion: As noted earlier, it is not reasonable to directly 925 require temporal checks. The protocol should, however, allow 926 signing messages using existing standards for signing. 927 [Requirement 9.4.9] 929 D3. will be able to verify M's integrity 931 Discussion: Stands as a requirement. [Requirement 9.4.10] 933 D4. will be able to prevent A from sending him future messages 935 Discussion: Stands as a requirement. [Requirement 9.4.11] 937 Bob expects that Alice: 939 E1. intended to send the message to Bob 941 Discussion: This is covered by the corresponding requirement 9.4.6 942 for C1 above. 944 E2. informed Bob of all CCs. 946 Discussion: As noted earlier, references to cc:'s are omitted from 947 the requirements. 949 12.2.2. Anonymous Instant Messaging 951 Discussion: Anonymous instant messaging, as in "hiding the identity 952 of the sender", is not deemed to be a core requirement of the 953 protocol and references to it are therefore omitted from the 954 requirements. Implementations may provide facilities for anonymous 955 messaging if they wish, in ways that are consistent with the other 956 requirements. 958 When a user Alice sends an anonymous instant message to another user 959 Bob: 961 Alice expects that Bob: 963 B1. will receive the message 965 B2. will receive the message quickly 967 B3. will receive the message only once 969 AB4.1. cannot know Alice sent it 971 AB4.2. will know that the IM is anonymous, and not from a specific 972 named user 974 AB4.3 may not allow anonymous IMs 976 B5. will not know whether there were BCCs 978 B6. will be able to reply to the message 980 Alice expects that she: 982 C1. will receive notification of non-delivery 984 AC2. will receive an error if the IM was refused 986 Bob expects that he: 988 D1. will be able to read M 990 D2. will be able to verify M's authenticity (both temporal and the 991 sender's identity) 993 D3. will be able to verify M's integrity 995 AD4. will know if an IM was sent anonymously 997 AD5. will be able to automatically discard anonymous IM if desired 999 AD6. will be able to control whether an error is sent to Alice if M is 1000 discarded. 1002 12.2.3. Administrator Expectations 1004 Charlie, Alice's network administrator expects: 1006 C1. that C will be able to send A instant messages at any time. 1008 C2. that A will receive any message he sends while A is online. 1010 C3. that A will not be able to refuse delivery of any instant 1011 messages sent by C. 1013 Discussion for C1-C3: It is not clear this needs to be specially 1014 handled at the protocol level; Administrators may accomplish the 1015 above objectives through other means. For example, an 1016 administrator may send a message to a user through the normal 1017 mechanisms. This is therefore omitted from the requirements.