rfc3856 a presence event package for the session initiation protocol.txt

有关IMS SIP及Presence应用的RFC文档包

   the PA can act as an aggregator and redistributor of those documents.
   The PA, in this case, would take the presence documents received from
   each PUA for the same presentity, and merge the tuples across all of
   those PUA into a single presence document.  Typically, this
   aggregation would be accomplished through administrator or user
   defined policies about how the aggregation should be done.

   The specific means by which a presence document is uploaded to a
   presence agent are outside the scope of this specification.  When a
   PUA wishes to have direct manipulation of the presence that is
   distributed to subscribers, direct uploading of presence documents is
   RECOMMENDED.

8.  Example Message Flow

   This message flow illustrates how the presence server can be
   responsible for sending notifications for a presentity.  This flow
   assumes that the watcher has previously been authorized to subscribe
   to this resource at the server.

   In this flow, the PUA informs the server about the updated presence
   information through some non-SIP means.

   When the value of the Content-Length header field is "..." this means
   that the value should be whatever the computed length of the body is.


















Rosenberg                   Standards Track                    [Page 17]

RFC 3856                      SIP Presence                   August 2004


   Watcher             Server                 PUA
      | F1 SUBSCRIBE      |                    |
      |------------------>|                    |
      | F2 200 OK         |                    |
      |<------------------|                    |
      | F3 NOTIFY         |                    |
      |<------------------|                    |
      | F4 200 OK         |                    |
      |------------------>|                    |
      |                   |                    |
      |                   |   Update presence  |
      |                   |<------------------ |
      |                   |                    |
      | F5 NOTIFY         |                    |
      |<------------------|                    |
      | F6 200 OK         |                    |
      |------------------>|                    |


   Message Details

   F1 SUBSCRIBE   watcher->example.com server

      SUBSCRIBE sip:[e-mail] SIP/2.0
      Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
      To: <sip:[e-mail]>
      From: <sip:[e-mail]>;tag=xfg9
      Call-ID: [e-mail]
      CSeq: 17766 SUBSCRIBE
      Max-Forwards: 70
      Event: presence
      Accept: application/pidf+xml
      Contact: <sip:[e-mail]>
      Expires: 600
      Content-Length: 0
















Rosenberg                   Standards Track                    [Page 18]

RFC 3856                      SIP Presence                   August 2004


   F2 200 OK   example.com server->watcher

      SIP/2.0 200 OK
      Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
        ;received=192.0.2.1
      To: <sip:[e-mail]>;tag=ffd2
      From: <sip:[e-mail]>;tag=xfg9
      Call-ID: [e-mail]
      CSeq: 17766 SUBSCRIBE
      Expires: 600
      Contact: sip:server.example.com
      Content-Length: 0

   F3 NOTIFY  example.com server-> watcher

      NOTIFY sip:[e-mail] SIP/2.0
      Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
      From: <sip:[e-mail]>;tag=ffd2
      To: <sip:[e-mail]>;tag=xfg9
      Call-ID: [e-mail]
      Event: presence
      Subscription-State: active;expires=599
      Max-Forwards: 70
      CSeq: 8775 NOTIFY
      Contact: sip:server.example.com
      Content-Type: application/pidf+xml
      Content-Length: ...

      [PIDF Document]

   F4 200 OK watcher-> example.com server

      SIP/2.0 200 OK
      Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
        ;received=192.0.2.2
      From: <sip:[e-mail]>;tag=ffd2
      To: <sip:[e-mail]>;tag=xfg9
      Call-ID: [e-mail]
      CSeq: 8775 NOTIFY
      Content-Length: 0











Rosenberg                   Standards Track                    [Page 19]

RFC 3856                      SIP Presence                   August 2004


   F5 NOTIFY example.com server -> watcher

      NOTIFY sip:[e-mail] SIP/2.0
      Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl
      From: <sip:[e-mail]>;tag=ffd2
      To: <sip:[e-mail]>;tag=xfg9
      Call-ID: [e-mail]
      CSeq: 8776 NOTIFY
      Event: presence
      Subscription-State: active;expires=543
      Max-Forwards: 70
      Contact: sip:server.example.com
      Content-Type: application/pidf+xml
      Content-Length: ...

      [New PIDF Document]

   F6 200 OK

      SIP/2.0 200 OK
      Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl
       ;received=192.0.2.2
      From: <sip:[e-mail]>;tag=ffd2
      To: <sip:[e-mail]>;tag=xfg9
      Call-ID: [e-mail]
      CSeq: 8776 NOTIFY
      Content-Length: 0

9.  Security Considerations

   There are numerous security considerations for presence.  RFC 2779
   [13] outlines many of them, and they are discussed above.  This
   section considers them issue by issue.

9.1.  Confidentiality

   Confidentiality encompasses many aspects of a presence system:

      o  Subscribers may not want to reveal the fact that they have
         subscribed to certain users

      o  Users may not want to reveal that they have accepted
         subscriptions from certain users

      o  Notifications (and fetch results) may contain sensitive data
         which should not be revealed to anyone but the subscriber





Rosenberg                   Standards Track                    [Page 20]

RFC 3856                      SIP Presence                   August 2004


   Confidentiality is provided through a combination of hop-by-hop
   encryption and end-to-end encryption.  The hop-by-hop mechanisms
   provide scalable confidentiality services, disable attacks involving
   traffic analysis, and hide all aspects of presence messages.
   However, they operate based on transitivity of trust, and they cause
   message content to be revealed to proxies.  The end-to-end mechanisms
   do not require transitivity of trust, and reveal information only to
   the desired recipient.  However, end-to-end encryption cannot hide
   all information, and is susceptible to traffic analysis.  Strong
   end-to-end authentication and encryption can be done using public
   keys, and end-to-end encryption can be done using private keys [14].
   Both hop-by-hop and end-to-end mechanisms will likely be needed for
   complete privacy services.

   SIP allows any hop by hop encryption scheme, but TLS is mandatory to
   implement for servers.  Therefore, it is RECOMMENDED that TLS [7] be
   used between elements to provide this function.  The details for
   usage of TLS for server-to-server and client-to-server security are
   detailed in Section 26.3.2 of RFC 3261 [1].

   SIP encryption, using S/MIME, MAY be used end-to-end for the
   transmission of both SUBSCRIBE and NOTIFY requests.

9.2.  Message Integrity and Authenticity

   It is important for the message recipient to ensure that the message
   contents are actually what was sent by the originator, and that the
   recipient of the message be able to determine who the originator
   really is.  This applies to both requests and responses of SUBSCRIBE
   and NOTIFY.  NOTIFY requests are particularly important.  Without
   authentication and integrity, presence documents could be forged or
   modified, fooling the watcher into believing incorrect presence
   information.

   RFC 3261 provides many mechanisms to provide these features.  In
   order for the PA to authenticate the watcher, it MAY use HTTP Digest
   (Section 22 of RFC 3261).  As a result, all watchers MUST support
   HTTP Digest.  This is a redundant requirement, however, since all SIP
   user agents are mandated to support it by RFC 3261.  To provide
   authenticity and integrity services, a watcher MAY use the SIPS
   scheme when subscribing to the presentity.  To support this, all PA
   MUST support TLS and SIPS as if they were a proxy (see Section 26.3.1
   of RFC 3261).

   Furthermore, SMIME MAY be used for integrity and authenticity of
   SUBSCRIBE and NOTIFY requests.  This is described in Section 23 of
   RFC 3261.




Rosenberg                   Standards Track                    [Page 21]

RFC 3856                      SIP Presence                   August 2004


9.3.  Outbound Authentication

   When local proxies are used for transmission of outbound messages,
   proxy authentication is RECOMMENDED.  This is useful to verify the
   identity of the originator, and prevent spoofing and spamming at the
   originating network.

9.4.  Replay Prevention

   Replay attacks can be used by an attacker to fool a watcher into
   believing an outdated presence state for a presentity.  For example,
   a document describing a presentity as being "offline" can be
   replayed, fooling watchers into thinking that the user is never
   online.  This may effectively block communications with the
   presentity.

   SIP S/MIME can provide message integrity and authentication over SIP
   request bodies.  Watchers and PAs MAY implement S/MIME signatures to
   prevent these replay attacks.  When it is used for that purpose, the
   presence document carried in the NOTIFY request MUST contain a
   timestamp.  In the case of PIDF, this is accomplished using the
   timestamp element, as described in Section 6 of [6].  Tuples whose
   timestamp is older than the timestamp of the most recently received
   presence document SHOULD be considered stale, and discarded.

   Finally, HTTP digest authentication (which MUST be implemented by
   watchers and PAs) MAY be used to prevent replay attacks, when there
   is a shared secret between the PA and the watcher.  In such a case,
   the watcher can challenge the NOTIFY requests with the auth-int
   quality of protection.