idnits 2.17.1 draft-ietf-impp-reqts-02.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 1067 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 5 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 585, but no explicit reference was found in the text == Unused Reference: '1998' is defined on line 585, 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-02 ** 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: February 13, 1999 Lotus 4 Sonu Aggarwal 5 Microsoft 7 Gordon Mohr 8 Activerse 10 Jesse Vincent 11 Arepa 13 Instant Messaging / Presence Protocol Requirements 14 draft-ietf-impp-reqts-02.txt 16 1. Status of this Memo 18 This document is an Internet-Draft and is in full conformance with all 19 provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This document and related documents are discussed on the impp mailing 36 list. To join the list, send mail to impp-request@iastate.edu. To 37 contribute to the discussion, send mail to impp@iastate.edu. The 38 archives are at http://lists.fsck.com/cgi-bin/wilma/pip. The IMPP 39 working group charter, including the current list of group documents, 40 can be found at http://www.ietf.org/html.charters/impp-charter.html. 42 2. Abstract 44 Presence and Instant Messaging have recently emerged as a new medium 45 of communications over the Internet. Presence is a means for finding, 46 retrieving, and subscribing to changes in the presence information 47 (e.g. "online" or "offline") of other users. Instant messaging is a 48 means for sending small, simple messages that are delivered 49 immediately to online users. 51 Applications of presence and instant messaging currently use 52 independent, non-standard and non-interoperable protocols developed by 53 various vendors. The goal of the Instant Messaging and Presence 54 Protocol (IMPP) Working Group is to define a standard protocol so that 55 independently developed applications of instant messaging and/or 56 presence can interoperate across the Internet. This document defines a 57 minimal set of requirements that IMPP must meet. 59 3. Contents 61 1. Status of this Memo 62 2. Abstract 63 3. Contents 64 4. Terminology 65 5. Shared Requirements 66 5.1. Namespace and Administration 67 5.2. Scalability 68 5.3. Access Control 69 5.4. Network Topology 70 5.5. Message Encryption and Authentication 71 6. Additional Requirements for PRESENCE INFORMATION 72 6.1. Common Presence Format 73 6.2. Presence Lookup and Notification 74 6.3. Presence Caching and Replication 75 7. Additional Requirements for INSTANT MESSAGES 76 7.1. Common Message Format 77 7.2. Reliability 78 7.3. Performance 79 7.4. Presence Format 80 8. Security Considerations 81 8.1. Requirements related to SUBSCRIPTIONS 82 8.2. Requirements related to NOTIFICATION 83 8.3. Requirements related to receiving a NOTIFICATION 84 8.4. Requirements related to INSTANT MESSAGES 85 9. References 86 10. Authors' Addresses 87 11. Appendix: Security Expectations and Deriving Requirements 88 11.1. Presence Information 89 11.1.1. Subscription 90 11.1.2. Publication 91 11.1.3. Publication for Notification 92 11.1.4. Receiving a Notification 93 11.2. Instant Messaging 94 11.2.1. Named Instant Messaging 95 11.2.2. Anonymous Instant Messaging 96 11.2.3. Administrator Expectations 98 4. Terminology 100 The following terms are defined in [Model] and are used with those 101 definitions in this document: 103 ACCESS RULES 104 CLOSED 105 FETCHER 106 INSTANT INBOX 107 INSTANT MESSAGE 108 NOTIFICATION 109 OPEN 110 POLLER 111 PRESENCE INFORMATION 112 PRESENCE SERVICE 113 PRESENTITY 114 PRINCIPAL 115 PROXY 116 SERVER 117 STATUS 118 SUBSCRIBER 119 SUBSCRIPTION 120 WATCHER 122 The terms MUST, SHOULD, and MAY are used with the meaning defined in 123 [RFC 2119]. 125 The following terms are used in this document and defined here: 127 ADMINISTRATOR: A PRINCIPAL with authority over local computer and 128 network resources, who manages local DOMAINS or FIREWALLS. For security 129 and other purposes, an ADMINISTRATOR often needs or wants to impose 130 restrictions on network usage based on traffic type, content, volume, 131 or endpoints. A PRINCIPAL's ADMINISTRATOR has authority over 132 some or all of that PRINCIPAL's computer and network resources. 134 DOMAIN: A portion of a NAMESPACE. 136 ENTITY: Any of PRESENTITY, SUBSCRIBER, FETCHER, POLLER, or WATCHER (all 137 defined in [Model]). 139 FIREWALL: A point of administrative control over connectivity. 140 Depending on the policies being enforced, parties may need to take 141 unusual measures to establish communications through the FIREWALL. 143 IDENTIFIER: A means of indicating a point of contact, intended for 144 public use such as on a business card. Telephone numbers, email 145 addresses, and typical home page URLs are all examples of IDENTIFIERS 146 in other systems. Numeric IP addresses like 10.0.0.26 are not, and 147 neither are URLs containing numerous CGI parameters or long arbitrary 148 identifiers. 150 INTENDED RECIPIENT: The PRINCIPAL to whom the sender of an INSTANT 151 MESSAGE is sending it. 153 NAMESPACE: The system that maps from a name of an ENTITY to the 154 concrete implementation of that ENTITY. A NAMESPACE MAY be composed of 155 a number of distinct DOMAINS. 157 OUT OF CONTACT: A situation in which some ENTITY and the PRESENCE 158 SERVICE cannot communicate. 160 SUCCESSFUL DELIVERY: A situation in which an INSTANT MESSAGE was 161 transmitted to an INSTANT INBOX for the INTENDED RECIPIENT, and the 162 INSTANT INBOX acknowledged its receipt. SUCCESSFUL DELIVERY usually 163 also implies that an INBOX USER AGENT has handled the message in a 164 way chosen by the PRINCIPAL. However, SUCCESSFUL DELIVERY does not 165 imply that the message was actually seen by that PRINCIPAL. 167 5. Shared Requirements 169 This section describes non-security requirements that are common to 170 both an PRESENCE SERVICE and an INSTANT MESSAGE SERVICE. Section 6 171 describes requirements specific to a PRESENCE SERVICE, while Section 7 172 describes requirements specific to an INSTANT MESSAGE SERVICE. Section 173 8 describes security considerations. The reader should note that 174 Section 11 is an appendix that provides historical context and aids in 175 tracing the origins of requirements in Section 8. Section 11 is not, 176 however, a statement of current IMPP requirements. 178 5.1. Namespace and Administration 180 5.1.1. The protocols MUST allow a PRESENCE SERVICE to be available 181 independent of whether an INSTANT MESSAGE SERVICE is available, and 182 vice-versa. 184 5.1.2. The protocols MUST allow an INSTANT INBOX to be reached via a 185 different IDENTIFIER than the IDENTIFIER of any PRESENTITY. 187 5.1.3. The protocols MUST also allow an INSTANT INBOX to be reached 188 via the same IDENTIFIER as the IDENTIFIER of some PRESENTITY. 190 5.1.4. The administration and naming of ENTITIES within a given DOMAIN 191 MUST be able to operate independently of actions in any other DOMAIN. 193 5.1.5. The protocol MUST allow for an arbitrary number of DOMAINS 194 within the NAMESPACE. 196 5.2. Scalability 198 5.2.1. It MUST be possible for ENTITIES in one DOMAIN to interoperate 199 with ENTITIES in another DOMAIN, without the DOMAINS having previously 200 been aware of each other. 202 The protocol MUST continue to meet its other functional and 203 performance requirements even when 205 -- (5.2.2) there are millions of ENTITIES within a single DOMAIN. 207 -- (5.2.3) there are millions of DOMAINS within the single 208 NAMESPACE. 210 -- (5.2.4) every single SUBSCRIBER has SUBSCRIPTIONS to hundreds 211 of PRESENTITIES. 213 -- (5.2.5) thousands of distinct SUBSCRIBERS have SUBSCRIPTIONS to 214 a single PRESENTITY. 216 -- (5.2.6) every single SUBSCRIBER has SUBSCRIPTIONS to 217 PRESENTITIES in hundreds of distinct DOMAINS. 219 5.3. Access Control 221 The PRINCIPAL controlling a PRESENTITY MUST be able to control 223 -- (5.3.1) which WATCHERS can observe that PRESENTITY's PRESENCE 224 INFORMATION. 226 -- (5.3.2) which WATCHERS can have SUBSCRIPTIONS to that 227 PRESENTITY's PRESENCE INFORMATION. 229 -- (5.3.3) what PRESENCE INFORMATION a particular WATCHER will see 230 for that PRESENTITY, regardless of whether the WATCHER gets it by 231 fetching or NOTIFICATION. 233 -- (5.3.4) which other PRINCIPALS, if any, can update the PRESENCE 234 INFORMATION of that PRESENTITY. 236 The PRINCIPAL controlling an INSTANT INBOX MUST be able to control 238 -- (5.3.5) which other PRINCIPALS, if any, can send INSTANT MESSAGES to 239 that INSTANT INBOX. 241 -- (5.3.6) which other PRINCIPALS, if any, can read INSTANT MESSAGES from 242 that INSTANT INBOX. 244 5.3.7. Access control MUST be independent of presence: the PRESENCE 245 SERVICE MUST be able to make access control decisions even when the 246 PRESENTITY is OUT OF CONTACT. 248 5.4. Network Topology 250 5.4.1. The protocol MUST allow the creation of a SUBSCRIPTION both 251 directly and via intermediaries, such as PROXIES. 253 5.4.2. The protocol MUST allow the sending of a NOTIFICATION both 254 directly and via intermediaries, such as PROXIES. 256 5.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE both 257 directly and via intermediaries, such as PROXIES. 259 5.4.4. The protocol proxying facilities and transport practices MUST 260 allow ADMINISTRATORS ways to enable and disable protocol activity 261 through existing and commonly-deployed FIREWALLS. 263 5.5. Message Encryption and Authentication 265 5.5.1. The protocol MUST provide means to ensure confidence that a 266 received message (NOTIFICATION or INSTANT MESSAGE) has not been 267 corrupted or tampered with. 269 5.5.2. The protocol MUST provide means to ensure confidence that a 270 received message (NOTIFICATION or INSTANT MESSAGE) has not been 271 recorded and played back by an adversary. 273 5.5.3. The protocol MUST provide means to ensure that a sent message 274 (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES that 275 the sender allows. 277 5.5.4. The protocol MUST allow any client to use the means to ensure 278 non-corruption, non-playback, and privacy, but the protocol MUST NOT 279 require that all clients use these means at all times. 281 6. Additional Requirements for PRESENCE INFORMATION 283 The requirements in section 6 are applicable only to PRESENCE 284 INFORMATION and not to INSTANT MESSAGES. Additional constraints on 285 PRESENCE INFORMATION in a system supporting INSTANT MESSAGES appear in 286 Section 7.4. 288 6.1. Common Presence Format 290 6.1.1. All ENTITIES MUST produce and consume at least a common base 291 format for PRESENCE INFORMATION. 293 6.1.2. The common presence format MUST include a means to uniquely 294 identify the PRESENTITY whose PRESENCE INFORMATION is reported. 296 6.1.3. The common presence format MUST include a means to encapsulate 297 contact information for the PRESENTITY's PRINCIPAL (if applicable), 298 such as email address, telephone number, postal address, or the like. 300 6.1.4. There MUST be a means of extending the common presence format 301 to represent additional information not included in the common format, 302 without undermining or rendering invalid the fields of the common 303 format. 305 6.1.5. The working group MUST define the extension and registration 306 mechanisms for presence information schema, including new STATUS 307 conditions and new forms for OTHER PRESENCE MARKUP. 309 6.1.6. The presence format SHOULD be based on IETF standards such as 310 vCard [RFC 2426] if possible. 312 6.2. Presence Lookup and Notification 314 6.2.1. A FETCHER MUST be able to fetch a PRESENTITY's PRESENCE 315 INFORMATION even when the PRESENTITY is OUT OF CONTACT. 317 6.2.2. A SUBSCRIBER MUST be able to request a SUBSCRIPTION to a 318 PRESENTITY's PRESENCE INFORMATION, even when the PRESENTITY is OUT OF 319 CONTACT. 321 6.2.3. If the PRESENCE SERVICE has SUBSCRIPTIONS for a PRESENTITY's 322 PRESENCE INFORMATION, and that PRESENCE INFORMATION changes, the 323 PRESENCE SERVICE MUST deliver a NOTIFICATION to each SUBSCRIBER, 324 unless prevented by the PRESENTITY's ACCESS RULES. 326 6.2.4. The protocol MUST provide a mechanism for detecting when a 327 PRESENTITY or SUBSCRIBER has gone OUT OF CONTACT. 329 6.2.5. The protocol MUST NOT depend on a PRESENTITY or SUBSCRIBER 330 gracefully telling the service that it will no longer be in 331 communication, since a PRESENTITY or SUBSCRIBER may go OUT OF CONTACT 332 due to unanticipated failures. 334 6.3. Presence Caching and Replication 336 6.3.1. The protocol MUST include mechanisms to allow PRESENCE 337 INFORMATION to be cached. 339 6.3.2. The protocol MUST include mechanisms to allow cached PRESENCE 340 INFORMATION to be updated when the master copy changes. 342 6.3.3 The protocol caching facilities MUST NOT circumvent established 343 ACCESS RULES or restrict choice of authentication/encryption 344 mechanisms. 346 6.4 Performance 348 6.4.1 When a PRESENTITY changes its PRESENCE INFORMATION, any 349 SUBSCRIBER to that information MUST be notified of the changed 350 information rapidly, except when such notification is entirely 351 prevented by ACCESS RULES. This requirement is met if each 352 SUBSCRIBER's NOTIFICATION is transported as rapidly as an INSTANT 353 MESSAGE would be transported to an INSTANT INBOX. 355 7. Additional Requirements for INSTANT MESSAGES 357 The requirements in section 7 are applicable only to INSTANT MESSAGES 358 and not to PRESENCE INFORMATION, with the exception of Section 359 7.4. Section 7.4 describes constraints on PRESENCE INFORMATION that 360 are relevant only to systems that support both INSTANT MESSAGES and 361 PRESENCE INFORMATION. 363 7.1. Common Message Format 365 7.1.1. All ENTITIES sending and receiving INSTANT MESSAGES MUST 366 implement at least a common base format for INSTANT MESSAGES. 368 7.1.2. The common base format for an INSTANT MESSAGE MUST identify the 369 sender and intended recipient. 371 7.1.3. The common message format MUST include a return address for the 372 receiver to reply to the sender with another INSTANT MESSAGE. 374 7.1.4. The common message format SHOULD include standard forms of 375 addresses or contact means for media other than INSTANT 376 MESSAGES, such as telephone numbers or email addresses. 378 7.1.5. The common message format MUST permit the encoding and 379 identification of the message payload to allow for non-ASCII or 380 encrypted content. 382 7.1.6. The working group MUST define the extension and registration 383 mechanisms for the message format, including new fields and new 384 schemes for INSTANT INBOX ADDRESSES. 386 7.1.7. The working group MUST determine whether the common message format 387 includes fields for numbering or identifying messages. If there 388 are such fields, the working group MUST define the scope within which 389 such identifiers are unique and the acceptable means of generating 390 such identifiers. 392 7.1.8. The common message format SHOULD be based on IETF-standard MIME 393 [RFC 2045]. 395 7.2. Reliability 397 7.2.1. The protocol MUST include mechanisms so that a sender can be 398 informed of the SUCCESSFUL DELIVERY of an INSTANT MESSAGE or reasons 399 for failure. The working group MUST determine what mechanisms apply 400 when final delivery status is unknown, such as when a message is 401 relayed to non-IMPP systems. 403 7.3 Performance 405 7.3.1. The transport of INSTANT MESSAGES SHOULD be sufficiently rapid to 406 allow for comfortable conversational exchanges of short messages. 408 7.4 Presence Format 410 7.4.1. The common presence format MUST define a minimum standard 411 presence schema suitable for INSTANT MESSAGE SERVICES. 413 7.4.2. When used in a system supporting INSTANT MESSAGES, the common 414 presence format MUST include a means to represent the STATUS 415 conditions OPEN and CLOSED. 417 7.4.3. The STATUS conditions OPEN and CLOSED MAY also be applied to 418 messaging or communication modes other than INSTANT MESSAGE SERVICES. 420 8. Security Considerations 422 Security considerations are addressed in section 5.3, Access Control, 423 and section 5.5, Message authentication and encryption. 425 This section describes further security-related requirements that the 426 protocol must meet. 428 The security requirements were derived from a set of all-encompassing 429 "security expectations" that were then evaluated for practicality and 430 implementability and translated into requirements. In the appendix, 431 we describe the expectations and the process used to transform them 432 into requirements. In this section, we simply list the consolidated 433 set of derived requirements. 435 Note that in the requirements, ADMINISTRATORs MAY have privileges 436 beyond those allowed to PRINCIPALs referred to in the requirements. 437 (Unless otherwise noted, the individual expectations specifically 438 refer to PRINCIPALs.) It is up to individual implementations to 439 control administrative access and implement the security privileges of 440 ADMINISTRATORs without compromising the requirements made on 441 PRINCIPALs. 443 Unless noted otherwise, A,B,C are all names of non-ADMINISTRATOR 444 PRINCIPALS. 446 8.1. Requirements related to SUBSCRIPTIONS 448 When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION: 450 8.1.1. The protocol MUST provide A means of identifying and 451 authenticating that the PRESENTITY subscribed to is controlled by B. 453 8.1.2. If A so chooses, the protocol SHOULD NOT make A's SUBSCRIPTION 454 to B obvious to a third party C. 456 8.1.3. The protocol MUST provide B with means of allowing an 457 unauthenticated subscription by A. 459 8.1.4. The protocol MUST provide A means of verifying the accurate 460 receipt of the content B chooses to disclose to A. 462 8.1.5. B MUST inform A if B refuses A's SUBSCRIPTION. Note that B MAY 463 choose to accept A's SUBSCRIPTION, but fail to deliver any information 464 to it (so-called "polite blocking"). See 8.1.15. 466 8.1.6. The protocol MUST NOT let any third party C force A to subscribe 467 to B's PRESENCE INFORMATION without A's consent. 469 8.1.7. A MUST be able to cancel her SUBSCRIPTION to B's PRESENCE 470 INFORMATION at any time and for any reason. When A does so, the 471 PRESENCE SERVICE stops informing A of changes to B's PRESENCE 472 INFORMATION. 474 8.1.8. The protocol MUST NOT let a third party C cancel A's 475 SUBSCRIPTION to B. 477 8.1.9. If A's SUBSCRIPTION to B is cancelled, the service SHOULD inform 478 A of the cancellation. 480 8.1.10. A SHOULD be able to determine the status of A's SUBSCRIPTION to 481 B, at any time. 483 8.1.11. The protocol MUST provide B means of learning about A's 484 SUBSCRIPTION to B, both at the time of establishing the SUBSCRIPTION 485 and afterwards. 487 8.1.12. The protocol MUST provide B means of identifying and 488 authenticating the SUBSCRIBER's PRINCIPAL, A. 490 8.1.13. It MUST be possible for B to prevent any particular PRINCIPAL 491 from subscribing. 493 8.1.14. It MUST be possible for B to prevent anonymous PRINCIPALS from 494 subscribing. 496 8.1.15. It MUST be possible for B to configure the PRESENCE SERVICE to 497 deny A's subscription while appearing to A as if the subscription has 498 been granted (this is sometimes called "polite blocking"). The 499 protocol MUST NOT mandate the PRESENCE SERVICE to service 500 subscriptions that are treated in this manner. 502 8.1.16. B MUST be able to cancel A's subscription at will. 504 8.1.17. The protocol MUST NOT require A to reveal A's IP 505 address to B. 507 8.1.18 The protocol MUST NOT require B to reveal B's IP address to A. 509 8.2. Requirements related to NOTIFICATION 511 When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to 512 another PRINCIPAL A: 514 8.2.1. The protocol MUST provide means of ensuring that only the 515 PRINCIPAL A being sent the NOTIFICATION by B can read the 516 NOTIFICATION. 518 8.2.2. A SHOULD receive all NOTIFICATIONS intended for her. 520 8.2.3. It MUST be possible for B to prevent A from receiving 521 notifications, even if A is ordinarily permitted to see such 522 notifications. It MUST be possible for B to, at its choosing, notify 523 different subscribers differently, through different notification 524 mechanisms or through publishing different content. This is a 525 variation on "polite blocking". 527 8.2.4. The protocol MUST provide means of protecting B from another 528 PRINCIPAL C "spoofing" notification messages about B. 530 8.2.5. The protocol MUST NOT require that A reveal A's IP address to 531 B. 533 8.2.6. The protocol MUST NOT require that B reveal B's IP address to 534 A. 536 8.3. Requirements related to receiving a NOTIFICATION 538 When a PRINCIPAL A receives a notification message from another 539 principal B, conveying PRESENCE INFORMATION, 541 8.3.1. The protocol MUST provide A means of verifying that the 542 presence information is accurate, as sent by B. 544 8.3.2. The protocol MUST ensure that A is only sent NOTIFICATIONS from 545 entities she has subscribed to. 547 8.3.3. The protocol MUST provide A means of verifying that the 548 notification was sent by B. 550 8.4. Requirements related to INSTANT MESSAGES 552 When a user A sends an INSTANT MESSAGE M to another user B, 554 8.4.1. A MUST receive confirmation of non-delivery. 556 8.4.2. If M is delivered, B MUST receive the message only once. 558 8.4.3. The protocol MUST provide B means of verifying that A sent the message. 560 8.4.4. B MUST be able to reply to the message via another instant message. 562 8.4.5. The protocol MUST NOT always require A to reveal A's IP 563 address, for A to send an instant message. 565 8.4.6. The protocol MUST provide A means of ensuring that no other 566 PRINCIPAL C can see the content of M. 568 8.4.7. The protocol MUST provide A means of ensuring that no other 569 PRINCIPAL C can tamper with M, and B means to verify that no tampering 570 has occurred. 572 8.4.8. B MUST be able to read M. 574 8.4.9. The protocol MUST allow A to sign the message, using existing 575 standards for digital signatures. 577 8.4.10. B MUST be able to prevent A from sending him messages 579 9. References 581 [Aggarwal et al., 1998] 582 S. Aggarwal, M. Day, G. Mohr, "Presence Information Protocol 583 Requirements", Work in progress, draft-aggarwal-pip-reqts-00.txt 585 [Day, 1998] 586 M. Day, "Requirements for Presence and Instant Messaging", 587 Work in progress, draft-day-rpim-00.txt 589 [Model] 590 M. Day, J. Rosenberg, H. Sagano. "A Model for Presence." 591 Work in progress, draft-ietf-impp-model-02.txt. 593 [Calsyn & Dusseault, 1998] 594 M. Calsyn and L. Dusseault. "Presence Information Protocol 595 Requirements", Work in progress, draft-dusseault-pipr-00.txt 597 [RFC 2426] 598 F. Dawson and T. Howes. "vCard MIME Directory Profile." RFC 599 2426, September 1998. 601 [RFC 2045] 602 N. Freed and N. Borenstein. "Multipurpose Internet Mail Extensions 603 (MIME) - Part One: Format of Internet Message Bodies." RFC 2045, 604 November 1996. 606 [RFC 2119] 607 S. Bradner. "Key Words for Use in RFCs to Indicate Requirement 608 Levels." RFC 2119, March 1997. 610 10. Authors' Addresses 612 Mark Day 613 614 Lotus Development Corporation 615 55 Cambridge Parkway 616 Cambridge, MA 02142 617 USA 619 Sonu Aggarwal 620 621 Microsoft Corporation 622 One Microsoft Way 623 Redmond, WA 98052 624 USA 626 Gordon Mohr 627 628 Activerse, Inc. 629 1301 W. 25th St Suite 500 630 Austin, TX 78705 631 USA 633 Jesse Vincent 634 635 Arepa, Inc. 636 100 Cambridgepark Drive 637 Cambridge, MA 02140 638 USA 640 11. Appendix: Security Expectations and Deriving Requirements 642 This appendix is based on the security expectations discussed on the 643 impp mailing list and assembled by Jesse Vincent. The original form 644 of numbering has been preserved in this appendix (so there are several 645 different items labeled B1, for example). The derived requirements 646 have new numbers that are consistent with the main body of the 647 document. This appendix is included to provide a connection from 648 discussions on the list to the requirements of Section 8, but it is 649 not intended to introduce any new requirements beyond those presented 650 in Sections 5 through 8. 652 11.1. PRESENCE INFORMATION 654 In the case of PRESENCE INFORMATION, the controlling PRINCIPAL's 655 privacy interests are paramount; we agreed that "polite blocking" 656 (denying without saying that the subscription is denied, or providing 657 false information) should be possible. 659 11.1.1. Subscription 661 When a user Alice subscribes to another person, Bob's presence info, 662 Alice expects: 664 A1. the PRESENTITY's PRINCIPAL, B, is identifiable and authenticated 666 Discussion: Stands as a requirement. Note that the protocol should 667 provide Alice the capability of authenticating, without requiring 668 that Alice authenticate every SUBSCRIPTION. This caveat is made 669 necessary by performance concerns, among others, and applies to 670 many of the other requirements derived below. [Requirement 8.1.1] 672 A2. no third party will know that A has subscribed to B. 674 Discussion: This is somewhat unreasonable to enforce as is. For 675 example, in some topologies, nothing can prevent someone doing 676 traffic analysis to deduce that A has subscribed to B. We should 677 merely require that the protocol not expose subscription 678 information in any obvious manner. [Requirement 8.1.2] 680 A3. A has the capability to subscribe to B's presence without B's 681 knowledge, if B permits anonymous subscriptions. 683 Discussion: An "anonymous subscription" above can have two 684 implications - (i) B may allow an unauthenticated subscription by 685 A, and (ii) B may be unaware of A's stated identity. Requirement 686 (i) is reasonable [Requirement 8.1.3], but (ii) doesn't appear to 687 be a core requirement -- it can be adequately simulated via a 688 subscription pseudonym. 690 A4. A will accurately receive what B chooses to disclose to A 691 regarding B's presence. 693 Discussion: Stands as a requirement, with the "optional" 694 caveat. [Requirement 8.1.4] 696 A5. B will inform A if B refuses A's subscription 698 Discussion: Stands as a requirement. [Requirement 8.1.5] 700 A6. No third party, C can force A to subscribe to B's presence without 701 A's consent. 703 Discussion: Stands as a requirement. [Requirement 8.1.6] 705 A7. A can cancel her subscription to B's presence at any time and for 706 any reason. When A does so, she will receive no further information 707 about B's presence information. 709 Discussion: This essentially stands. However, implementations may 710 have to contend with a timing window where A receives, after 711 sending her cancellation request, a notification sent by B before 712 B received the cancellation request. Therefore, the requirement 713 should focus on B's ceasing to send presence information, rather 714 than A's ceasing to receive it. [Requirement 8.1.7] 716 A8. no third party, C, can cancel A's subscription to B. 718 Discussion: Stands, although the administrative exception does 719 apply. [Requirement 8.1.8] 721 A9. A is notified if her subscription to B is cancelled for any reason. 723 Discussion: Although the intent is reasonable, there are a number 724 of scenarios (e.g. overburdened server, clogged network, server 725 crash) where delivering a notification to A of the cancellation 726 is undesirable or impossible. Therefore, the service should make 727 an attempt to inform, but this is not required. [Requirement 8.1.9] 729 Bob expects: 731 B1. B will be informed that A subscribed to B's presence information, 732 as long as A has not subscribed anonymously. 734 Discussion: This essentially stands. However, B can also choose to 735 determine A's subscription after the fact. [Requirement 8.1.10] 737 B2. A is identifiable and authenticated. 739 Discussion: This stands as a requirement. [Requirement 8.1.11] 741 B3. B can prevent a particular user, D, from subscribing. 743 Discussion: This stands as a requirement. [Requirement 8.1.12] 745 B4. B can prevent anonymous users from subscribing. 747 Discussion: This stands as a requirement. [Requirement 8.1.13] 749 B5. B's presence information is not republished by A to a third party, 750 E, who does not. 752 Discussion: This is practically impossible to enforce, so it is 753 omitted from the requirement set. 755 B6. B can deny A's subscription without letting A know that she's been 756 blocked. 758 Discussion: This "polite blocking" capability essentially stands; 759 accepting a "denied" subscription should bear no implication on 760 servicing it for status notifications. [Requirement 8.1.14] 762 B7. B can cancel A's subscription at will. 764 Discussion: Stands as a requirement. [Requirement 8.1.15] 766 Charlie, bob's network administrator expects: 768 C1. C knows who is subscribed to B at all times. 770 Discussion: Administrators should be able to determine who is 771 subscribed, but needn't be continuously informed of the list of 772 subscribers. Also, in some cases user agents (e.g. proxies) may 773 have subscribed on behalf of users, and in these cases the 774 administrator can only determine the identity of these agents, not 775 their users. [Requirement 8.1.16] 777 C2. C can manage all aspects of A's presence information. 779 Discussion: This stands as a requirement. [Requirement 8.1.17] 781 C3. C can control who can access A's presence information and exchange 782 instant messages with A. 784 Discussion: This stands in principle, but C should be able to waive 785 these capabilities if C desires. [Requirement 8.1.18] 787 11.1.2. Publication 789 The publisher of status information, Bob, expects: 791 B1. That information about B is not provided to any entity without B's 792 knowledge and consent. 794 Discussion: This is nearly impossible to accomplish, so it is 795 omitted from the requirements. 797 11.1.3. Publication for Notification 799 When information is published for notification, B expects: 801 B1. only a person being sent a notification, A, can read the 802 notification. 804 Discussion: Stands as a requirement. [Requirement 8.2.1] 806 B2. A reliably receives all notifications intended for her. 808 Discussion: This stands, although "Reliably" is a little strong 809 (e.g. network outages, etc.). [Requirement 8.2.2] 811 B3. B can prevent A from receiving notifications, even if A is 812 ordinarily permitted to see such notifications. This is a variation 813 on "polite blocking." 815 Discussion: This stands as a requirement. Also incorporated into 816 this requirement is the notifications equivalent of the next 817 expectation, B4. [Requirement 8.2.3] 819 B4. B can provide two interested parties A and E with different status 820 information at the same time. (B could represent the same event 821 differently to different people.) 823 Discussion: This stands as a requirement; it has been incorporated 824 into the corresponding requirement for B3 above. 826 B5. B expects that malicious C cannot spoof notification messages about 827 B. 829 Discussion: Stands in principle, but it should be optional for B. 830 [Requirement 8.2.4] 832 11.1.4. Receiving a Notification 834 When Alice receives a notification, the recipient, Alice, expects: 836 A1. That the notification information is accurate, truthful. 838 Discussion: Stands in principle, although being "truthful" can't be 839 a requirement, and the verification is optional for Alice. 840 [Requirement 8.3.1] 842 A2. That information about subscriptions remains private; people do 843 not learn that A's subscription to B's information exists by watching 844 notifications occur. 846 Discussion: This is omitted from the requirements, as traffic 847 analysis, even of encrypted traffic, can convey this information in 848 some situations. 850 A3. That she only receives notifications of things she's subscribed to. 852 Discussion: Stands as a requirement. [Requirement 8.3.2] 854 A4. Notifications come from the apparent sender, B. 856 Discussion: Stands in principle, although the verification should 857 be optional for A. [Requirement 8.3.3] 859 A5. A can tell the difference between a message generated by the user, 860 and a message legitimately generated by the agent on behalf of the 861 user. 863 Discussion: This could be quite difficult to enforce and could 864 unduly restrict usage scenarios; this is omitted from the 865 requirements. 867 A6. That information given by agents on behalf of users can also be 868 expected to be truthful, complete, and legitimately offered; the user 869 permitted the agent to publish these notifications. 871 Discussion: This is difficult to enforce and is omitted from the 872 requirements. 874 A7. A can prove that a notification from B was delivered in a timely 875 fashion and can prove exactly how long the message took to be 876 delivered. 878 Discussion: This is difficult to enforce and is omitted from the 879 requirements. For example, such proof may entail global time 880 synchronization mechanisms (since any system clocks have associated 881 unreliability), which is outside the scope of this effort. 883 A8. A can prove that B was indeed the sender of a given message. 885 Discussion: This is a duplication of expectation A4 above and is 886 reflected in the corresponding requirement 8.3.3. 888 11.2. INSTANT MESSAGEs 890 11.2.1. Named Instant Messaging 892 When a user Alice sends an instant message M to another user Bob: 894 Alice expects that she: 896 A1. will receive notification of non-delivery 898 Discussion: Stands as a requirement. [Requirement 8.4.1] 900 Alice expects that Bob: 902 B1. will receive the message 904 Discussion: covered by A1 and is reflected in the corresponding 905 requirement 8.4.1. 907 B2. will receive the message quickly 909 Discussion: Stands as a requirement, although this is also covered 910 elsewhere (in the non-security requirements), so this is omitted 911 from the security requirements. 913 B3. will receive the message only once 915 Discussion: Stands as a requirement. [Requirement 8.4.2] 917 B4. will be able to verify that Alice sent the message 919 Discussion: Stands as a requirement. [Requirement 8.4.3] 921 B5. will not know whether there were BCCs 923 Discussion: Emulating e-mail conventions and social protocols is 924 not a core goal of this effort, and therefore references to 925 standard mail fields are omitted from the requirements. 927 B6. will be able to reply to the message 929 Discussion: Stands in principle; the recipient should be able to 930 reply via an instant message. [Requirement 8.4.4] 932 B7. will know if he was a bcc recipient 934 Discussion: Omitted, as noted above. 936 B8. will not be able to determine any information about A (such as her 937 location or IP address) without A's knowledge and consent. 939 Discussion: "Any information about A" is too general; the 940 requirement should focus on IP address. Further, "without A's 941 knowledge and consent" may be overkill. [Requirement 8.4.5] 943 Alice expects that no other user Charlie will be able to: 945 C1. see the content of M 947 Discussion: Stands in principle, although this should not be 948 mandated for all IM communication. [Requirement 8.4.6] 950 C2. tamper with M 952 Discussion: Stands, with the same caveat as above. 953 [Requirement 8.4.7] 955 C3. know that M was sent 957 Discussion: It is impossible to prevent traffic analysis, and this 958 is therefore omitted from the requirements. 960 When a user Bob receives an instant message M from another user Alice: 962 Bob expects that Bob: 964 D1. will be able to read M 966 Discussion: Stands as a requirement. [Requirement 8.4.8] 968 D2. will be able to verify M's authenticity (both Temporal and the 969 sender's identity) 971 Discussion: As noted earlier, it is not reasonable to directly 972 require temporal checks. The protocol should, however, allow 973 signing messages using existing standards for signing. 974 [Requirement 8.4.9] 976 D3. will be able to verify M's integrity 978 Discussion: Stands as a requirement. [Requirement 8.4.10] 980 D4. will be able to prevent A from sending him future messages 982 Discussion: Stands as a requirement. [Requirement 8.4.11] 984 Bob expects that Alice: 986 E1. intended to send the message to Bob 988 Discussion: This is covered by the corresponding requirement 8.4.6 989 for C1 above. 991 E2. informed Bob of all CCs. 993 Discussion: As noted earlier, references to cc:'s are omitted from 994 the requirements. 996 11.2.2. Anonymous Instant Messaging 998 Discussion: Anonymous instant messaging, as in "hiding the identity 999 of the sender", is not deemed to be a core requirement of the 1000 protocol and references to it are therefore omitted from the 1001 requirements. Implementations may provide facilities for anonymous 1002 messaging if they wish, in ways that are consistent with the other 1003 requirements. 1005 When a user Alice sends an anonymous instant message to another user 1006 Bob: 1008 Alice expects that Bob: 1010 B1. will receive the message 1012 B2. will receive the message quickly 1014 B3. will receive the message only once 1016 AB4.1. cannot know Alice sent it 1018 AB4.2. will know that the IM is anonymous, and not from a specific 1019 named user 1021 AB4.3 may not allow anonymous IMs 1023 B5. will not know whether there were BCCs 1025 B6. will be able to reply to the message 1027 Alice expects that she: 1029 C1. will receive notification of non-delivery 1031 AC2. will receive an error if the IM was refused 1033 Bob expects that he: 1035 D1. will be able to read M 1037 D2. will be able to verify M's authenticity (both temporal and the 1038 sender's identity) 1040 D3. will be able to verify M's integrity 1042 AD4. will know if an IM was sent anonymously 1044 AD5. will be able to automatically discard anonymous IM if desired 1046 AD6. will be able to control whether an error is sent to Alice if M is 1047 discarded. 1049 11.2.3. Administrator Expectations 1051 Charlie, Alice's network administrator expects: 1053 C1. that C will be able to send A instant messages at any time. 1055 C2. that A will receive any message he sends while A is online. 1057 C3. that A will not be able to refuse delivery of any instant 1058 messages sent by C. 1060 Discussion for C1-C3: It is not clear this needs to be specially 1061 handled at the protocol level; Administrators may accomplish the 1062 above objectives through other means. For example, an 1063 administrator may send a message to a user through the normal 1064 mechanisms. This is therefore omitted from the requirements.