|
Network Working Group Request for Comments: 2779 Category: Informational |
M. Day Lotus S. Aggarwal Microsoft G. Mohr Activerse J. Vincent Into Networks February 2000 |
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 © The Internet Society (2000). All Rights Reserved.
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.
1. Terminology
2. Shared Requirements
2.1. Namespace and Administration
2.2. Scalability
2.3. Access Control
2.4. Network Topology
2.5. Message Encryption and Authentication
3. Additional Requirements for PRESENCE INFORMATION
3.1. Common Presence Format
3.2. Presence Lookup and Notification
3.3. Presence Caching and Replication
3.4. Performance
4. Additional Requirements for INSTANT MESSAGES
4.1. Common Message Format
4.2. Reliability
4.3. Performance
4.4. Presence Format
5. Security Considerations
5.1. Requirements related to SUBSCRIPTIONS
5.2. Requirements related to NOTIFICATION
5.3. Requirements related to receiving a NOTIFICATION
5.4. Requirements related to INSTANT MESSAGES
6. References
7. Authors' Addresses
8. Appendix: Security Expectations and Deriving Requirements
8.1. Presence Information
8.1.1. Subscription
8.1.2. Publication
8.1.3. Publication for Notification
8.1.4. Receiving a Notification
8.2. Instant Messaging
8.2.1. Named Instant Messaging
8.2.2. Anonymous Instant Messaging
8.2.3. Administrator Expectations
Full Copyright Statement
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]).
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.
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
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.
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.
-- (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.
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.
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.
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.
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.
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.
When A establishes a SUBSCRIPTION to B's PRESENCE INFORMATION:
When a PRINCIPAL B publishes PRESENCE INFORMATION for NOTIFICATION to another PRINCIPAL A:
When a PRINCIPAL A receives a notification message from another principal B, conveying PRESENCE INFORMATION,
When a user A sends an INSTANT MESSAGE M to another user B,
[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.
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)
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.
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.
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]
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
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
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]
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.
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]
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]
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.
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.
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.
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.
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.
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:
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.
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.
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.
Copyright © 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.
Funding for the RFC Editor function is currently provided by the Internet Society.