rfc2779.txt

RFC 的详细文档！


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: [e-mail]
   (Formerly [e-mail])


   Sonu Aggarwal
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052
   USA

   EMail: [e-mail]


   Gordon Mohr

   EMail: [e-mail]
   (Formerly [e-mail])


   Jesse Vincent
   Into Networks, Inc.
   150 Cambridgepark Drive
   Cambridge, MA 02140
   USA

   EMail: [e-mail]
   (Formerly [e-mail])
















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