diff options
Diffstat (limited to 'doc/rfc/rfc2779.txt')
| -rw-r--r-- | doc/rfc/rfc2779.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc2779.txt b/doc/rfc/rfc2779.txt new file mode 100644 index 0000000..dbe89d1 --- /dev/null +++ b/doc/rfc/rfc2779.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group M. Day +Request for Comments: 2779 Lotus +Category: Informational S. Aggarwal + Microsoft + G. Mohr + Activerse + J. Vincent + Into Networks + February 2000 + + + Instant Messaging / Presence Protocol Requirements + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + Presence and Instant Messaging have recently emerged as a new medium + of communications over the Internet. Presence is a means for + finding, retrieving, and subscribing to changes in the presence + information (e.g. "online" or "offline") of other users. Instant + messaging is a means for sending small, simple messages that are + delivered immediately to online users. + + Applications of presence and instant messaging currently use + independent, non-standard and non-interoperable protocols developed + by various vendors. The goal of the Instant Messaging and Presence + Protocol (IMPP) Working Group is to define a standard protocol so + that independently developed applications of instant messaging and/or + presence can interoperate across the Internet. This document defines + a minimal set of requirements that IMPP must meet. + + + + + + + + + + + + +Day, et al. Informational [Page 1] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + +Table of Contents + + 1. Terminology................................................... 3 + 2. Shared Requirements........................................... 4 + 2.1. Namespace and Administration............................... 5 + 2.2. Scalability................................................ 5 + 2.3. Access Control............................................. 6 + 2.4. Network Topology........................................... 6 + 2.5. Message Encryption and Authentication...................... 7 + 3. Additional Requirements for PRESENCE INFORMATION.............. 7 + 3.1. Common Presence Format..................................... 7 + 3.2. Presence Lookup and Notification........................... 8 + 3.3. Presence Caching and Replication........................... 8 + 3.4. Performance................................................ 9 + 4. Additional Requirements for INSTANT MESSAGES.................. 9 + 4.1. Common Message Format...................................... 9 + 4.2. Reliability................................................ 10 + 4.3. Performance................................................ 10 + 4.4. Presence Format............................................ 10 + 5. Security Considerations....................................... 11 + 5.1. Requirements related to SUBSCRIPTIONS...................... 11 + 5.2. Requirements related to NOTIFICATION....................... 12 + 5.3. Requirements related to receiving a NOTIFICATION........... 13 + 5.4. Requirements related to INSTANT MESSAGES................... 13 + 6. References.................................................... 14 + 7. Authors' Addresses............................................ 15 + 8. Appendix: Security Expectations and Deriving Requirements..... 16 + 8.1. Presence Information....................................... 16 + 8.1.1. Subscription............................................ 16 + 8.1.2. Publication............................................. 19 + 8.1.3. Publication for Notification............................ 19 + 8.1.4. Receiving a Notification................................ 20 + 8.2. Instant Messaging.......................................... 21 + 8.2.1. Named Instant Messaging................................. 21 + 8.2.2. Anonymous Instant Messaging............................. 23 + 8.2.3. Administrator Expectations.............................. 24 + Full Copyright Statement......................................... 26 + + + + + + + + + + + + + + +Day, et al. Informational [Page 2] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + +1. Terminology + + The following terms are defined in [RFC 2778] and are used with those + definitions in this document: + + ACCESS RULES + CLOSED + FETCHER + INSTANT INBOX + INSTANT MESSAGE + NOTIFICATION + OPEN + POLLER + PRESENCE INFORMATION + PRESENCE SERVICE + PRESENTITY + PRINCIPAL + PROXY + SERVER + STATUS + SUBSCRIBER + SUBSCRIPTION + WATCHER + + The terms MUST and SHOULD are used in the following sense while + specifying requirements: + + MUST: A proposed solution will have to meet this requirement. + SHOULD: A proposed solution may choose not to meet this requirement. + + Note that this usage of MUST and SHOULD differs from that of RFC + 2119. + + Additionally, the following terms are used in this document and + defined here: + + ADMINISTRATOR: A PRINCIPAL with authority over local computer and + network resources, who manages local DOMAINS or FIREWALLS. For + security and other purposes, an ADMINISTRATOR often needs or wants to + impose restrictions on network usage based on traffic type, content, + volume, or endpoints. A PRINCIPAL's ADMINISTRATOR has authority over + some or all of that PRINCIPAL's computer and network resources. + + DOMAIN: A portion of a NAMESPACE. + + ENTITY: Any of PRESENTITY, SUBSCRIBER, FETCHER, POLLER, or WATCHER + (all defined in [RFC 2778]). + + + + +Day, et al. Informational [Page 3] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + FIREWALL: A point of administrative control over connectivity. + Depending on the policies being enforced, parties may need to take + unusual measures to establish communications through the FIREWALL. + + IDENTIFIER: A means of indicating a point of contact, intended for + public use such as on a business card. Telephone numbers, email + addresses, and typical home page URLs are all examples of IDENTIFIERS + in other systems. Numeric IP addresses like 10.0.0.26 are not, and + neither are URLs containing numerous CGI parameters or long arbitrary + identifiers. + + INTENDED RECIPIENT: The PRINCIPAL to whom the sender of an INSTANT + MESSAGE is sending it. + + NAMESPACE: The system that maps from a name of an ENTITY to the + concrete implementation of that ENTITY. A NAMESPACE may be composed + of a number of distinct DOMAINS. + + OUT OF CONTACT: A situation in which some ENTITY and the PRESENCE + SERVICE cannot communicate. + + SUCCESSFUL DELIVERY: A situation in which an INSTANT MESSAGE was + transmitted to an INSTANT INBOX for the INTENDED RECIPIENT, and the + INSTANT INBOX acknowledged its receipt. SUCCESSFUL DELIVERY usually + also implies that an INBOX USER AGENT has handled the message in a + way chosen by the PRINCIPAL. However, SUCCESSFUL DELIVERY does not + imply that the message was actually seen by that PRINCIPAL. + +2. Shared Requirements + + This section describes non-security requirements that are common to + both an PRESENCE SERVICE and an INSTANT MESSAGE SERVICE. Section 6 + describes requirements specific to a PRESENCE SERVICE, while Section + 7 describes requirements specific to an INSTANT MESSAGE SERVICE. + Section 8 describes security considerations. The reader should note + that Section 11 is an appendix that provides historical context and + aids in tracing the origins of requirements in Section 8. Section 11 + is not, however, a statement of current IMPP requirements. + + It is expected that Presence and Instant Messaging services will be + particularly valuable to users over mobile IP wireless access + devices. Indeed the number of devices connected to the Internet via + wireless means is expected to grow substantially in the coming years. + It is not reasonable to assume that separate protocols will be + available for the wireless portions of the Internet. In addition, we + note that wireless infrastructure is maturing rapidly; the work + undertaken by this group should take into account the expected state + of the maturity of the technology in the time-frame in which the + + + +Day, et al. Informational [Page 4] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + Presence and Instant Messaging protocols are expected to be deployed. + + To this end, the protocols designed by this Working Group must be + suitable for operation in a context typically associated with mobile + wireless access devices, viz. high latency, low bandwidth and + possibly intermittent connectivity (which lead to a desire to + minimize round-trip delays), modest computing power, battery + constraints, small displays, etc. In particular, the protocols must + be designed to be reasonably efficient for small payloads. + +2.1. Namespace and Administration + + 2.1.1. The protocols MUST allow a PRESENCE SERVICE to be available + independent of whether an INSTANT MESSAGE SERVICE is available, and + vice-versa. + + 2.1.2. The protocols must not assume that an INSTANT INBOX is + necessarily reached by the same IDENTIFIER as that of a PRESENTITY. + Specifically, the protocols must assume that some INSTANT INBOXes may + have no associated PRESENTITIES, and vice versa. + + 2.1.3. The protocols MUST also allow an INSTANT INBOX to be reached + via the same IDENTIFIER as the IDENTIFIER of some PRESENTITY. + + 2.1.4. The administration and naming of ENTITIES within a given + DOMAIN MUST be able to operate independently of actions in any other + DOMAIN. + + 2.1.5. The protocol MUST allow for an arbitrary number of DOMAINS + within the NAMESPACE. + +2.2. Scalability + + 2.2.1. It MUST be possible for ENTITIES in one DOMAIN to interoperate + with ENTITIES in another DOMAIN, without the DOMAINS having + previously been aware of each other. + + The protocol MUST be capable of meeting its other functional and + performance requirements even when + + -- (2.2.2) there are millions of ENTITIES within a single DOMAIN. + + -- (2.2.3) there are millions of DOMAINS within the single + NAMESPACE. + + + + + + + +Day, et al. Informational [Page 5] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + -- (2.2.4) every single SUBSCRIBER has SUBSCRIPTIONS to hundreds + of PRESENTITIES. + + -- (2.2.5) hundreds of distinct SUBSCRIBERS have SUBSCRIPTIONS to + a single PRESENTITY. + + -- (2.2.6) every single SUBSCRIBER has SUBSCRIPTIONS to + PRESENTITIES in hundreds of distinct DOMAINS. + + These are protocol design goals; implementations may choose to place + lower limits. + +2.3. Access Control + + The PRINCIPAL controlling a PRESENTITY MUST be able to control + + -- (2.3.1) which WATCHERS can observe that PRESENTITY's PRESENCE + INFORMATION. + + -- (2.3.2) which WATCHERS can have SUBSCRIPTIONS to that + PRESENTITY's PRESENCE INFORMATION. + + -- (2.3.3) what PRESENCE INFORMATION a particular WATCHER will see + for that PRESENTITY, regardless of whether the WATCHER gets it + by fetching or NOTIFICATION. + + -- (2.3.4) which other PRINCIPALS, if any, can update the PRESENCE + INFORMATION of that PRESENTITY. + + The PRINCIPAL controlling an INSTANT INBOX MUST be able to control + + -- (2.3.5) which other PRINCIPALS, if any, can send INSTANT + MESSAGES to that INSTANT INBOX. + + -- (2.3.6) which other PRINCIPALS, if any, can read INSTANT + MESSAGES from that INSTANT INBOX. + + 2.3.7. Access control MUST be independent of presence: the PRESENCE + SERVICE MUST be able to make access control decisions even when the + PRESENTITY is OUT OF CONTACT. + +2.4. Network Topology + + Note that intermediaries such as PROXIES may be necessitated between + IP and non-IP networks, and by an end-user's desire to provide + anonymity and hide their IP address. + + + + + +Day, et al. Informational [Page 6] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + 2.4.1. The protocol MUST allow the creation of a SUBSCRIPTION both + directly and via intermediaries, such as PROXIES. + + 2.4.2. The protocol MUST allow the sending of a NOTIFICATION both + directly and via intermediaries, such as PROXIES. + + 2.4.3. The protocol MUST allow the sending of an INSTANT MESSAGE both + directly and via intermediaries, such as PROXIES. + + 2.4.4. The protocol proxying facilities and transport practices MUST + allow ADMINISTRATORS ways to enable and disable protocol activity + through existing and commonly-deployed FIREWALLS. The protocol MUST + specify how it can be effectively filtered by such FIREWALLS. + +2.5. Message Encryption and Authentication + + 2.5.1. The protocol MUST provide means to ensure confidence that a + received message (NOTIFICATION or INSTANT MESSAGE) has not been + corrupted or tampered with. + + 2.5.2. The protocol MUST provide means to ensure confidence that a + received message (NOTIFICATION or INSTANT MESSAGE) has not been + recorded and played back by an adversary. + + 2.5.3. The protocol MUST provide means to ensure that a sent message + (NOTIFICATION or INSTANT MESSAGE) is only readable by ENTITIES that + the sender allows. + + 2.5.4. The protocol MUST allow any client to use the means to ensure + non-corruption, non-playback, and privacy, but the protocol MUST NOT + require that all clients use these means at all times. + +3. Additional Requirements for PRESENCE INFORMATION + + The requirements in section 6 are applicable only to PRESENCE + INFORMATION and not to INSTANT MESSAGES. Additional constraints on + PRESENCE INFORMATION in a system supporting INSTANT MESSAGES appear + in Section 7.4. + +3.1. Common Presence Format + + 3.1.1. All ENTITIES MUST produce and consume at least a common base + format for PRESENCE INFORMATION. + + 3.1.2. The common presence format MUST include a means to uniquely + identify the PRESENTITY whose PRESENCE INFORMATION is reported. + + + + + +Day, et al. Informational [Page 7] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + 3.1.3. The common presence format MUST include a means to encapsulate + contact information for the PRESENTITY's PRINCIPAL (if applicable), + such as email address, telephone number, postal address, or the like. + + 3.1.4. There MUST be a means of extending the common presence format + to represent additional information not included in the common + format, without undermining or rendering invalid the fields of the + common format. + + 3.1.5. The working group must define the extension and registration + mechanisms for presence information schema, including new STATUS + conditions and new forms for OTHER PRESENCE MARKUP. + + 3.1.6. The presence format SHOULD be based on IETF standards such as + vCard [RFC 2426] if possible. + +3.2. Presence Lookup and Notification + + 3.2.1. A FETCHER MUST be able to fetch a PRESENTITY's PRESENCE + INFORMATION even when the PRESENTITY is OUT OF CONTACT. + + 3.2.2. A SUBSCRIBER MUST be able to request a SUBSCRIPTION to a + PRESENTITY's PRESENCE INFORMATION, even when the PRESENTITY is OUT OF + CONTACT. + + 3.2.3. If the PRESENCE SERVICE has SUBSCRIPTIONS for a PRESENTITY's + PRESENCE INFORMATION, and that PRESENCE INFORMATION changes, the + PRESENCE SERVICE MUST deliver a NOTIFICATION to each SUBSCRIBER, + unless prevented by the PRESENTITY's ACCESS RULES. + + 3.2.4. The protocol MUST provide a mechanism for detecting when a + PRESENTITY or SUBSCRIBER has gone OUT OF CONTACT. + + 3.2.5. The protocol MUST NOT depend on a PRESENTITY or SUBSCRIBER + gracefully telling the service that it will no longer be in + communication, since a PRESENTITY or SUBSCRIBER may go OUT OF CONTACT + due to unanticipated failures. + +3.3. Presence Caching and Replication + + 3.3.1. The protocol MUST include mechanisms to allow PRESENCE + INFORMATION to be cached. + + 3.3.2. The protocol MUST include mechanisms to allow cached PRESENCE + INFORMATION to be updated when the master copy changes. + + + + + + +Day, et al. Informational [Page 8] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + 3.3.3 The protocol caching facilities MUST NOT circumvent established + ACCESS RULES or restrict choice of authentication/encryption + mechanisms. + +3.4 Performance + + 3.4.1 When a PRESENTITY changes its PRESENCE INFORMATION, any + SUBSCRIBER to that information MUST be notified of the changed + information rapidly, except when such notification is entirely + prevented by ACCESS RULES. This requirement is met if each + SUBSCRIBER's NOTIFICATION is transported as rapidly as an INSTANT + MESSAGE would be transported to an INSTANT INBOX. + +4. Additional Requirements for INSTANT MESSAGES + + The requirements in section 4 are applicable only to INSTANT MESSAGES + and not to PRESENCE INFORMATION, with the exception of Section 4.4. + Section 4.4 describes constraints on PRESENCE INFORMATION that are + relevant only to systems that support both INSTANT MESSAGES and + PRESENCE INFORMATION. + +4.1. Common Message Format + + 4.1.1. All ENTITIES sending and receiving INSTANT MESSAGES MUST + implement at least a common base format for INSTANT MESSAGES. + + 4.1.2. The common base format for an INSTANT MESSAGE MUST identify + the sender and intended recipient. + + 4.1.3. The common message format MUST include a return address for + the receiver to reply to the sender with another INSTANT MESSAGE. + + 4.1.4. The common message format SHOULD include standard forms of + addresses or contact means for media other than INSTANT MESSAGES, + such as telephone numbers or email addresses. + + 4.1.5. The common message format MUST permit the encoding and + identification of the message payload to allow for non-ASCII or + encrypted content. + + 4.1.6. The protocol must reflect best current practices related to + internationalization. + + 4.1.7. The protocol must reflect best current practices related to + accessibility. + + + + + + +Day, et al. Informational [Page 9] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + 4.1.8. The working group MUST define the extension and registration + mechanisms for the message format, including new fields and new + schemes for INSTANT INBOX ADDRESSES. + + 4.1.9. The working group MUST determine whether the common message + format includes fields for numbering or identifying messages. If + there are such fields, the working group MUST define the scope within + which such identifiers are unique and the acceptable means of + generating such identifiers. + + 4.1.10. The common message format SHOULD be based on IETF-standard + MIME [RFC 2045]. + +4.2. Reliability + + 4.2.1. The protocol MUST include mechanisms so that a sender can be + informed of the SUCCESSFUL DELIVERY of an INSTANT MESSAGE or reasons + for failure. The working group must determine what mechanisms apply + when final delivery status is unknown, such as when a message is + relayed to non-IMPP systems. + +4.3 Performance + + 4.3.1. The transport of INSTANT MESSAGES MUST be sufficiently rapid + to allow for comfortable conversational exchanges of short messages. + +4.4 Presence Format + + 4.4.1. The common presence format MUST define a minimum standard + presence schema suitable for INSTANT MESSAGE SERVICES. + + 4.4.2. When used in a system supporting INSTANT MESSAGES, the common + presence format MUST include a means to represent the STATUS + conditions OPEN and CLOSED. + + 4.4.3. The STATUS conditions OPEN and CLOSED may also be applied to + messaging or communication modes other than INSTANT MESSAGE SERVICES. + + + + + + + + + + + + + + +Day, et al. Informational [Page 10] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + +5. Security Considerations + + Security considerations are addressed in section 2.3, Access Control, + and section 2.5, Message authentication and encryption. + + This section describes further security-related requirements that the + protocol must meet. + + The security requirements were derived from a set of all-encompassing + "security expectations" that were then evaluated for practicality and + implementability and translated into requirements. In the appendix, + we describe the expectations and the process used to transform them + into requirements. In this section, we simply list the consolidated + set of derived requirements. + + Note that in the requirements, ADMINISTRATORs may have privileges + beyond those allowed to PRINCIPALs referred to in the requirements. + (Unless otherwise noted, the individual expectations specifically + refer to PRINCIPALs.) It is up to individual implementations to + control administrative access and implement the security privileges + of ADMINISTRATORs without compromising the requirements made on + PRINCIPALs. + + Unless noted otherwise, A,B,C are all names of non-ADMINISTRATOR + PRINCIPALS. + +5.1. Requirements related to SUBSCRIPTIONS + + When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION: + + 5.1.1. The protocol MUST provide A means of identifying and + authenticating that the PRESENTITY subscribed to is controlled by B. + + 5.1.2. If A so chooses, the protocol SHOULD NOT make A's SUBSCRIPTION + to B obvious to a third party C. + + 5.1.3. The protocol MUST provide B with means of allowing an + unauthenticated subscription by A. + + 5.1.4. The protocol MUST provide A means of verifying the accurate + receipt of the content B chooses to disclose to A. + + 5.1.5. B MUST inform A if B refuses A's SUBSCRIPTION. Note that B may + choose to accept A's SUBSCRIPTION, but fail to deliver any + information to it (so-called "polite blocking"). See 5.1.15. + + 5.1.6. The protocol MUST NOT let any third party C force A to + subscribe to B's PRESENCE INFORMATION without A's consent. + + + +Day, et al. Informational [Page 11] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + 5.1.7. A MUST be able to cancel her SUBSCRIPTION to B's PRESENCE + INFORMATION at any time and for any reason. When A does so, the + PRESENCE SERVICE stops informing A of changes to B's PRESENCE + INFORMATION. + + 5.1.8. The protocol MUST NOT let an unauthorized party C cancel A's + SUBSCRIPTION to B. + + 5.1.9. If A's SUBSCRIPTION to B is cancelled, the service SHOULD + inform A of the cancellation. + + 5.1.10. A SHOULD be able to determine the status of A's SUBSCRIPTION + to B, at any time. + + 5.1.11. The protocol MUST provide B means of learning about A's + SUBSCRIPTION to B, both at the time of establishing the SUBSCRIPTION + and afterwards. + + 5.1.12. The protocol MUST provide B means of identifying and + authenticating the SUBSCRIBER's PRINCIPAL, A. + + 5.1.13. It MUST be possible for B to prevent any particular PRINCIPAL + from subscribing. + + 5.1.14. It MUST be possible for B to prevent anonymous PRINCIPALS + from subscribing. + + 5.1.15. It MUST be possible for B to configure the PRESENCE SERVICE + to deny A's subscription while appearing to A as if the subscription + has been granted (this is sometimes called "polite blocking"). The + protocol MUST NOT mandate the PRESENCE SERVICE to service + subscriptions that are treated in this manner. + + 5.1.16. B MUST be able to cancel A's subscription at will. + + 5.1.17. The protocol MUST NOT require A to reveal A's IP address to + B. + + 5.1.18 The protocol MUST NOT require B to reveal B's IP address to A. + +5.2. Requirements related to NOTIFICATION + + When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to + another PRINCIPAL A: + + 5.2.1. The protocol MUST provide means of ensuring that only the + PRINCIPAL A being sent the NOTIFICATION by B can read the + NOTIFICATION. + + + +Day, et al. Informational [Page 12] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + 5.2.2. A should receive all NOTIFICATIONS intended for her. + + 5.2.3. It MUST be possible for B to prevent A from receiving + notifications, even if A is ordinarily permitted to see such + notifications. It MUST be possible for B to, at its choosing, notify + different subscribers differently, through different notification + mechanisms or through publishing different content. This is a + variation on "polite blocking". + + 5.2.4. The protocol MUST provide means of protecting B from another + PRINCIPAL C "spoofing" notification messages about B. + + 5.2.5. The protocol MUST NOT require that A reveal A's IP address to + B. + + 5.2.6. The protocol MUST NOT require that B reveal B's IP address to + A. + +5.3. Requirements related to receiving a NOTIFICATION + + When a PRINCIPAL A receives a notification message from another + principal B, conveying PRESENCE INFORMATION, + + 5.3.1. The protocol MUST provide A means of verifying that the + presence information is accurate, as sent by B. + + 5.3.2. The protocol MUST ensure that A is only sent NOTIFICATIONS + from entities she has subscribed to. + + 5.3.3. The protocol MUST provide A means of verifying that the + notification was sent by B. + +5.4. Requirements related to INSTANT MESSAGES + + When a user A sends an INSTANT MESSAGE M to another user B, + + 5.4.1. A MUST receive confirmation of non-delivery. + + 5.4.2. If M is delivered, B MUST receive the message only once. + + 5.4.3. The protocol MUST provide B means of verifying that A sent the + message. + + 5.4.4. B MUST be able to reply to the message via another instant + message. + + 5.4.5. The protocol MUST NOT always require A to reveal A's IP + address, for A to send an instant message. + + + +Day, et al. Informational [Page 13] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + 5.4.6. The protocol MUST provide A means of ensuring that no other + PRINCIPAL C can see the content of M. + + 5.4.7. The protocol MUST provide A means of ensuring that no other + PRINCIPAL C can tamper with M, and B means to verify that no + tampering has occurred. + + 5.4.8. B must be able to read M. + + 5.4.9. The protocol MUST allow A to sign the message, using existing + standards for digital signatures. + + 5.4.10. B MUST be able to prevent A from sending him messages + +6. References + + [RFC 2778] Day, M., Rosenberg, J. and H. Sagano, "A Model for + Presence and Instant Messaging", RFC 2778, February 2000. + + [RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", + RFC 2426, September 1998. + + [RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) - Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + + + + + + + + + + + + + + + + + + + + +Day, et al. Informational [Page 14] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + +7. Authors' Addresses + + Mark Day + SightPath, Inc. + 135 Beaver Street + Waltham, MA 02452 + USA + + EMail: mday@alum.mit.edu + (Formerly Mark_Day@lotus.com) + + + Sonu Aggarwal + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + USA + + EMail: sonuag@microsoft.com + + + Gordon Mohr + + EMail: gojomo@usa.net + (Formerly gojomo@activerse.com) + + + Jesse Vincent + Into Networks, Inc. + 150 Cambridgepark Drive + Cambridge, MA 02140 + USA + + EMail: jesse@intonet.com + (Formerly jvincent@microsoft.com) + + + + + + + + + + + + + + + + +Day, et al. Informational [Page 15] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + +8. Appendix: Security Expectations and Deriving Requirements + + This appendix is based on the security expectations discussed on the + impp mailing list and assembled by Jesse Vincent. The original form + of numbering has been preserved in this appendix (so there are + several different items labeled B1, for example). The derived + requirements have new numbers that are consistent with the main body + of the document. This appendix is included to provide a connection + from discussions on the list to the requirements of Section 8, but it + is not intended to introduce any new requirements beyond those + presented in Sections 5 through 8. + +8.1. PRESENCE INFORMATION + + In the case of PRESENCE INFORMATION, the controlling PRINCIPAL's + privacy interests are paramount; we agreed that "polite blocking" + (denying without saying that the subscription is denied, or providing + false information) should be possible. + + 8.1.1. Subscription + + When a user Alice subscribes to another person, Bob's presence info, + Alice expects: + + A1. the PRESENTITY's PRINCIPAL, B, is identifiable and authenticated + + Discussion: Stands as a requirement. Note that the protocol + should provide Alice the capability of authenticating, without + requiring that Alice authenticate every SUBSCRIPTION. This + caveat is made necessary by performance concerns, among others, + and applies to many of the other requirements derived below. + [Requirement 5.1.1] + + A2. no third party will know that A has subscribed to B. + + Discussion: This is somewhat unreasonable to enforce as is. For + example, in some topologies, nothing can prevent someone doing + traffic analysis to deduce that A has subscribed to B. We should + merely require that the protocol not expose subscription + information in any obvious manner. [Requirement 5.1.2] + + + + + + + + + + + +Day, et al. Informational [Page 16] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + A3. A has the capability to subscribe to B's presence without B's + knowledge, if B permits anonymous subscriptions. + + Discussion: An "anonymous subscription" above can have two + implications - (i) B may allow an unauthenticated subscription by + A, and (ii) B may be unaware of A's stated identity. Requirement + (i) is reasonable [Requirement 8.1.3], but (ii) doesn't appear to + be a core requirement -- it can be adequately simulated via a + subscription pseudonym. + + A4. A will accurately receive what B chooses to disclose to A + regarding B's presence. + + Discussion: Stands as a requirement, with the "optional" + caveat. [Requirement 8.1.4] + + A5. B will inform A if B refuses A's subscription + + Discussion: Stands as a requirement. [Requirement 5.1.5] + + A6. No third party, C can force A to subscribe to B's presence + without A's consent. + + Discussion: Stands as a requirement. [Requirement 5.1.6] + + A7. A can cancel her subscription to B's presence at any time and for + any reason. When A does so, she will receive no further information + about B's presence information. + + Discussion: This essentially stands. However, implementations + may have to contend with a timing window where A receives, after + sending her cancellation request, a notification sent by B before + B received the cancellation request. Therefore, the requirement + should focus on B's ceasing to send presence information, rather + than A's ceasing to receive it. [Requirement 5.1.7] + + A8. no third party, C, can cancel A's subscription to B. + + Discussion: Stands, although the administrative exception does + apply. [Requirement 5.1.8] + + A9. A is notified if her subscription to B is cancelled for any + reason. + + Discussion: Although the intent is reasonable, there are a number + of scenarios (e.g. overburdened server, clogged network, server + crash) where delivering a notification to A of the cancellation + is undesirable or impossible. Therefore, the service should make + + + +Day, et al. Informational [Page 17] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + an attempt to inform, but this is not required. [Requirement + 5.1.9] + + Bob expects: + + B1. B will be informed that A subscribed to B's presence information, + as long as A has not subscribed anonymously. + + Discussion: This essentially stands. However, B can also choose + to determine A's subscription after the fact. [Requirement + 5.1.10] + + B2. A is identifiable and authenticated. + + Discussion: This stands as a requirement. [Requirement 5.1.11] + + B3. B can prevent a particular user, D, from subscribing. + + Discussion: This stands as a requirement. [Requirement 5.1.12] + + B4. B can prevent anonymous users from subscribing. + + Discussion: This stands as a requirement. [Requirement 5.1.13] + + B5. B's presence information is not republished by A to a third + party, E, who does not. + + Discussion: This is practically impossible to enforce, so it is + omitted from the requirement set. + + B6. B can deny A's subscription without letting A know that she's + been blocked. + + Discussion: This "polite blocking" capability essentially stands; + accepting a "denied" subscription should bear no implication on + servicing it for status notifications. [Requirement 5.1.14] + + B7. B can cancel A's subscription at will. + + Discussion: Stands as a requirement. [Requirement 5.1.15] + + Charlie, bob's network administrator expects: + + C1. C knows who is subscribed to B at all times. + + Discussion: Administrators should be able to determine who is + subscribed, but needn't be continuously informed of the list of + subscribers. Also, in some cases user agents (e.g. proxies) may + + + +Day, et al. Informational [Page 18] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + have subscribed on behalf of users, and in these cases the + administrator can only determine the identity of these agents, + not their users. [Requirement 5.1.16] + + C2. C can manage all aspects of A's presence information. + + Discussion: This stands as a requirement. [Requirement 5.1.17] + + C3. C can control who can access A's presence information and + exchange instant messages with A. + + Discussion: This stands in principle, but C should be able to + waive these capabilities if C desires. [Requirement 5.1.18] + + 8.1.2. Publication + + The publisher of status information, Bob, expects: + + B1. That information about B is not provided to any entity without + B's knowledge and consent. + + Discussion: This is nearly impossible to accomplish, so it is + omitted from the requirements. + + 8.1.3. Publication for Notification + + When information is published for notification, B expects: + + B1. only a person being sent a notification, A, can read the + notification. + + Discussion: Stands as a requirement. [Requirement 5.2.1] + + B2. A reliably receives all notifications intended for her. + + Discussion: This stands, although "Reliably" is a little strong + (e.g. network outages, etc.). [Requirement 5.2.2] + + B3. B can prevent A from receiving notifications, even if A is + ordinarily permitted to see such notifications. This is a variation + on "polite blocking." + + Discussion: This stands as a requirement. Also incorporated into + this requirement is the notifications equivalent of the next + expectation, B4. [Requirement 5.2.3] + + + + + + +Day, et al. Informational [Page 19] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + B4. B can provide two interested parties A and E with different + status information at the same time. (B could represent the same + event differently to different people.) + + Discussion: This stands as a requirement; it has been + incorporated into the corresponding requirement for B3 above. + + B5. B expects that malicious C cannot spoof notification messages + about B. + + Discussion: Stands in principle, but it should be optional for B. + [Requirement 5.2.4] + + 8.1.4. Receiving a Notification + + When Alice receives a notification, the recipient, Alice, expects: + + A1. That the notification information is accurate, truthful. + + Discussion: Stands in principle, although being "truthful" can't + be a requirement, and the verification is optional for Alice. + [Requirement 5.3.1] + + A2. That information about subscriptions remains private; people do + not learn that A's subscription to B's information exists by watching + notifications occur. + + Discussion: This is omitted from the requirements, as traffic + analysis, even of encrypted traffic, can convey this information + in some situations. + + A3. That she only receives notifications of things she's subscribed + to. + + Discussion: Stands as a requirement. [Requirement 5.3.2] + + A4. Notifications come from the apparent sender, B. + + Discussion: Stands in principle, although the verification should + be optional for A. [Requirement 5.3.3] + + A5. A can tell the difference between a message generated by the + user, and a message legitimately generated by the agent on behalf of + the user. + + Discussion: This could be quite difficult to enforce and could + unduly restrict usage scenarios; this is omitted from the + requirements. + + + +Day, et al. Informational [Page 20] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + A6. That information given by agents on behalf of users can also be + expected to be truthful, complete, and legitimately offered; the user + permitted the agent to publish these notifications. + + Discussion: This is difficult to enforce and is omitted from the + requirements. + + A7. A can prove that a notification from B was delivered in a timely + fashion and can prove exactly how long the message took to be + delivered. + + Discussion: This is difficult to enforce and is omitted from the + requirements. For example, such proof may entail global time + synchronization mechanisms (since any system clocks have + associated unreliability), which is outside the scope of this + effort. + + A8. A can prove that B was indeed the sender of a given message. + + Discussion: This is a duplication of expectation A4 above and is + reflected in the corresponding requirement 5.3.3. + +8.2. INSTANT MESSAGEs + + 8.2.1. Named Instant Messaging + + When a user Alice sends an instant message M to another user Bob: + + Alice expects that she: + + A1. will receive notification of non-delivery + + Discussion: Stands as a requirement. [Requirement 5.4.1] + + Alice expects that Bob: + + B1. will receive the message + + Discussion: covered by A1 and is reflected in the corresponding + requirement 5.4.1. + + B2. will receive the message quickly + + Discussion: Stands as a requirement, although this is also + covered elsewhere (in the non-security requirements), so this is + omitted from the security requirements. + + + + + +Day, et al. Informational [Page 21] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + B3. will receive the message only once + + Discussion: Stands as a requirement. [Requirement 5.4.2] + + B4. will be able to verify that Alice sent the message + + Discussion: Stands as a requirement. [Requirement 5.4.3] + + B5. will not know whether there were BCCs + + Discussion: Emulating e-mail conventions and social protocols is + not a core goal of this effort, and therefore references to + standard mail fields are omitted from the requirements. + + B6. will be able to reply to the message + + Discussion: Stands in principle; the recipient should be able to + reply via an instant message. [Requirement 5.4.4] + + B7. will know if he was a bcc recipient + + Discussion: Omitted, as noted above. + + B8. will not be able to determine any information about A (such as + her location or IP address) without A's knowledge and consent. + + Discussion: "Any information about A" is too general; the + requirement should focus on IP address. Further, "without A's + knowledge and consent" may be overkill. [Requirement 5.4.5] + + Alice expects that no other user Charlie will be able to: + + C1. see the content of M + + Discussion: Stands in principle, although this should not be + mandated for all IM communication. [Requirement 5.4.6] + + C2. tamper with M + + Discussion: Stands, with the same caveat as above. + [Requirement 5.4.7] + + C3. know that M was sent + + Discussion: It is impossible to prevent traffic analysis, and + this is therefore omitted from the requirements. + + + + + +Day, et al. Informational [Page 22] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + When a user Bob receives an instant message M from another user + Alice: + + Bob expects that Bob: + + D1. will be able to read M + + Discussion: Stands as a requirement. [Requirement 5.4.8] + + D2. will be able to verify M's authenticity (both Temporal and the + sender's identity) + + Discussion: As noted earlier, it is not reasonable to directly + require temporal checks. The protocol should, however, allow + signing messages using existing standards for signing. + [Requirement 5.4.9] + + D3. will be able to verify M's integrity + + Discussion: Stands as a requirement. [Requirement 5.4.10] + + D4. will be able to prevent A from sending him future messages + + Discussion: Stands as a requirement. [Requirement 5.4.11] + + Bob expects that Alice: + + E1. intended to send the message to Bob + + Discussion: This is covered by the corresponding requirement + 5.4.6 for C1 above. + + E2. informed Bob of all CCs. + + Discussion: As noted earlier, references to cc:'s are omitted + from the requirements. + + 8.2.2. Anonymous Instant Messaging + + Discussion: Anonymous instant messaging, as in "hiding the + identity of the sender", is not deemed to be a core requirement + of the protocol and references to it are therefore omitted from + the requirements. Implementations may provide facilities for + anonymous messaging if they wish, in ways that are consistent + with the other requirements. + + When a user Alice sends an anonymous instant message to another user + Bob: + + + +Day, et al. Informational [Page 23] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + Alice expects that Bob: + + B1. will receive the message + + B2. will receive the message quickly + + B3. will receive the message only once + + AB4.1. cannot know Alice sent it + + AB4.2. will know that the IM is anonymous, and not from a specific + named user + + AB4.3 may not allow anonymous IMs + + B5. will not know whether there were BCCs + + B6. will be able to reply to the message + + Alice expects that she: + + C1. will receive notification of non-delivery + + AC2. will receive an error if the IM was refused + + Bob expects that he: + + D1. will be able to read M + + D2. will be able to verify M's authenticity (both temporal and the + sender's identity) + + D3. will be able to verify M's integrity + + AD4. will know if an IM was sent anonymously + + AD5. will be able to automatically discard anonymous IM if desired + + AD6. will be able to control whether an error is sent to Alice if M + is discarded. + + 8.2.3. Administrator Expectations + + Charlie, Alice's network administrator expects: + + C1. that C will be able to send A instant messages at any time. + + C2. that A will receive any message he sends while A is online. + + + +Day, et al. Informational [Page 24] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + + C3. that A will not be able to refuse delivery of any instant + messages sent by C. + + Discussion for C1-C3: It is not clear this needs to be specially + handled at the protocol level; Administrators may accomplish the + above objectives through other means. For example, an + administrator may send a message to a user through the normal + mechanisms. This is therefore omitted from the requirements. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Day, et al. Informational [Page 25] + +RFC 2779 Instant Messaging/Presence Protocol February 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Day, et al. Informational [Page 26] + |