RFC 3261.
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.
9.5. Denial of Service Attacks Against Third Parties
Denial of Service (DOS) attacks are a critical problem for an open,
inter-domain, presence protocol. Unfortunately, presence is a good
candidate for Distributed DoS (DDOS) attacks because of its
amplification properties. A single SUBSCRIBE message could generate
a nearly unending stream of notifications, so long as a suitably
dynamic source of presence data can be found. Thus, a simple way to
launch an attack against a target is to send subscriptions to a large
number of users, and in the Contact header field (which is where
notifications are sent), place the address of the target. RFC 3265
provides some mechanisms to mitigate these attacks [2]. If a NOTIFY
is not acknowledged or was not wanted, the subscription that
generated it is removed. This eliminates the amplification
properties of providing false Contact addresses.
Authentication and authorization at the PA can also prevent these
attacks. Typically, authorization policy will not allow
subscriptions from unknown watchers. If the attacks are launched
from watchers unknown to the presentity (a common case), the attacks
are mitigated.
9.6. Denial Of Service Attacks Against Servers
Denial of service attacks can also be launched against a presence
agent itself, in order to disrupt service to a community of users.
SIP itself, along with RFC 3265 [2], describes several mechanisms to
mitigate these attacks.
A server can prevent SYN-attack style attacks through a four-way
handshake using digest authentication [1]. Even if the server does
not have a shared secret with the client, it can verify the source IP
address of the request using the "anonymous" user mechanism described
in Section 22.1 of RFC 3261 [1]. SIP also allows a server to
instruct a client to back-off from sending it requests, using the 503
response code (Section 21.5.4 of RFC 3261 [1]). This can be used to
fend off floods of SUBSCRIBE requests launched as a result of a
distributed denial of service attack.
10. IANA Considerations
This specification registers an event package, based on the
registration procedures defined in RFC 3265 [2]. The following is
the information required for such a registration:
Package Name: presence
Package or Template-Package: This is a package.
Published Document: RFC 3856
Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.
11. Contributors
The following individuals were part of the initial team that worked
through the technical design of this specification:
Jonathan Lennox
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
EMail: lennox@cs.columbia.edu
Robert Sparks
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024
EMail: rsparks@dynamicsoft.com
Ben Campbell
EMail: ben@nostrum.com
Dean Willis
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, Texas 75024
EMail: dwillis@dynamicsoft.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
EMail: schulzrinne@cs.columbia.edu
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: huitema@microsoft.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: bernarda@microsoft.com
David Gurle
Reuters Corporation
EMail: David.Gurle@reuters.com
David Oran
Cisco Systems
170 West Tasman Dr.
San Jose, CA 95134
EMail: oran@cisco.com
12. Acknowledgements
We would like to thank Rick Workman, Adam Roach, Sean Olson, Billy
Biggs, Stuart Barkley, Mauricio Arango, Richard Shockey, Jorgen
Bjorkner, Henry Sinnreich, Ronald Akers, Paul Kyzivat, Ya-Ching Tan,
Patrik Faltstrom, Allison Mankin and Hisham Khartabil for their
comments and support of this specification.
13. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004.
[4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Peterson, J., "Address Resolution for Instant Messaging and
Presence", RFC 3861, August 2004.
[6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)", RFC
3863, August 2004.
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[8] Rosenberg, J., "A Watcher Information Event Template-Package for
the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[9] Schulzrinne, H. Rosenberg, J., and P. Kyzivat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)",
RFC 3840, August 2004.
14. Informative References
[10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
[11] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)", Work in
Progress, May 2004.
[12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[13] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
Messaging / Presence Protocol Requirements", RFC 2779, February
2000.
[14] Gutmann, P., "Password-Based Encryption for CMS", RFC 3211,
December 2001.
15. Author’s Address
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054
EMail: jdrosen@dynamicsoft.com
16. 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-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.