rfc3857 a watcher information event template-package for.txt

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

   The NOTIFY tells Joe that user A currently has a pending
   subscription.  Joe then authorizes A's subscription through some
   means.  This causes a change in the status of the subscription (which
   moves from pending to active), and the delivery of another
   notification:

   NOTIFY sip:[e-mail] SIP/2.0
   Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
   From: sip:[e-mail];tag=xyzygg
   To: sip:[e-mail];tag=123aa9
   Call-ID: [e-mail]
   CSeq: 1289 NOTIFY
   Contact: sip:server19.example.com
   Event: presence.winfo
   Subscription-State: active
   Max-Forwards: 70
   Content-Type: application/watcherinfo+xml
   Content-Length: ...

   <?xml version="1.0"?>
   <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
                version="1" state="partial">
     <watcher-list resource="sip:[e-mail]" package="presence">
       <watcher id="77ajsyy76" event="approved"
                status="active">sip:[e-mail]</watcher>
     </watcher-list>
   </watcherinfo>

   B then responds with a 200 OK to the NOTIFY:

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
     ;received=192.0.2.7
   From: sip:[e-mail];tag=xyzygg
   To: sip:[e-mail];tag=123aa9
   Call-ID: [e-mail]
   CSeq: 1289 NOTIFY














Rosenberg                   Standards Track                    [Page 16]

RFC 3857                  Watcher Information                August 2004


6.  Security Considerations

6.1.  Denial of Service Attacks

   Watcher information generates notifications about changes in the
   state of watchers for a particular resource.  It is possible for a
   single resource to have many watchers, resulting in the possibility
   of a large volume of notifications.  This makes watcherinfo
   subscription a potential tool for denial of service attacks.
   Preventing these can be done through a combination of sensible
   authorization policies and good operating principles.

   First, when a resource has a lot of watchers, watcherinfo
   subscriptions to that resource should only be allowed from explicitly
   authorized entities, whose identity has been properly authenticated.
   That prevents a watcherinfo NOTIFY stream from being generated from
   subscriptions made by an attacker.

   Even when watcherinfo subscriptions are properly authenticated, there
   are still potential attacks.  For example, consider a valid user, T,
   who is to be the target of an attack.  T has subscribed to their own
   watcher information.  The attacker generates a large number of
   subscriptions (not watcherinfo subscriptions).  If the server creates
   subscription state for unauthenticated subscriptions, and reports
   those changes in watcherinfo notifications, user T would receive a
   flood of watcherinfo notifications.  In fact, if the server generates
   a watcherinfo notification when the subscription is created, and
   another when it is terminated, there will be an amplification by a
   factor of two.  The amplification would actually be substantial if
   the server generates full state in each watcherinfo notification.
   Indeed, the amount of data sent to T would be the square of the data
   generated by the attacker! Each of the N subscriptions generated by
   the attacker would result in a watcherinfo NOTIFY being sent to T,
   each of which would report on up to N watchers.  To avoid this,
   servers should never generate subscription state for unauthenticated
   SUBSCRIBE requests, and should never generate watcherinfo
   notifications for them either.

6.2.  Divulging Sensitive Information

   Watcher information indicates what users are interested in a
   particular resource.  Depending on the package and the resource, this
   can be very sensitive information.  For example, in the case of
   presence, the watcher information for some user represents the
   friends, family, and business relations of that person.  This
   information can be used for a variety of malicious purposes.





Rosenberg                   Standards Track                    [Page 17]

RFC 3857                  Watcher Information                August 2004


   One way in which this information can be revealed is eavesdropping.
   An attacker can observe watcherinfo notifications, and learn this
   information.  To prevent that, watchers MAY use the sips URI scheme
   when subscribing to a watcherinfo resource.  Notifiers for
   watcherinfo MUST support TLS and sips as if they were a proxy (see
   Section 26.3.1 of RFC 3261).

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

   Another way in which this information can be revealed is through
   spoofed subscriptions.  These attacks can be prevented by
   authenticating and authorizing all watcherinfo subscriptions.  In
   order for the notifier to authenticate the subscriber, 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.

7.  IANA Considerations

   This specification registers an event template package as specified
   in Section 6.2 of RFC 3265 [1].

   Package Name: winfo

   Template Package: yes

   Published Specification: RFC 3857

   Person to Contact: Jonathan Rosenberg, [e-mail].

8.  Acknowledgements

   The authors would like to thank Adam Roach, Allison Mankin and Brian
   Stucker for their detailed comments.

9.  Normative References

   [1]  Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

   [2]  Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Rosenberg, J., "An Extensible Markup Language (XML) Based Format
        for Watcher Information", RFC 3858, August 2004.





Rosenberg                   Standards Track                    [Page 18]

RFC 3857                  Watcher Information                August 2004


   [4]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

10.  Informative References

   [5]  Rosenberg, J., "A Presence Event Package for the Session
        Initiation Protocol (SIP)", RFC 3856, July 2004.

11.  Author's Address

   Jonathan Rosenberg
   dynamicsoft
   600 Lanidex Plaza
   Parsippany, NJ 07054

   EMail: [e-mail]


































Rosenberg                   Standards Track                    [Page 19]

RFC 3857                  Watcher Information                August 2004


12. Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.









Rosenberg                   Standards Track                    [Page 20]