GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc2779

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
  1. - (2.2.2) there are millions of ENTITIES within a single DOMAIN.
  1. - (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

  1. - (2.2.4) every single SUBSCRIBER has SUBSCRIPTIONS to hundreds

of PRESENTITIES.

  1. - (2.2.5) hundreds of distinct SUBSCRIBERS have SUBSCRIPTIONS to

a single PRESENTITY.

  1. - (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
  1. - (2.3.1) which WATCHERS can observe that PRESENTITY's PRESENCE

INFORMATION.

  1. - (2.3.2) which WATCHERS can have SUBSCRIPTIONS to that

PRESENTITY's PRESENCE INFORMATION.

  1. - (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.
  1. - (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
  1. - (2.3.5) which other PRINCIPALS, if any, can send INSTANT

MESSAGES to that INSTANT INBOX.

  1. - (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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2779.txt · Last modified: 2000/02/22 19:02 (external edit)