This document defines a recommended suite of XMPP protocols to be supported by applications that wish to communicate in a secure fashion.
WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document must not be referred to as an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://www.xmpp.org/extensions/> and announced on the <firstname.lastname@example.org> mailing list.
Publisher: XMPP Standards Foundation
Type: Standards Track
Last Updated: 2007-01-29
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM
Superseded By: None
Short Name: N/A
This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy <http://www.xmpp.org/extensions/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
Basic IM Protocol Suite  and Intermediate IM Protocol Suite  introduced the concept of a "protocol suite". While those documents and the specifications on which they depend define some fundamental features for instant messaging and presence, they do not highlight the security aspects of the relevant protocols. This document is intended to provide more detailed guidelines for developers of XMPP-based clients and servers, with a focus on security.
There are many aspects of security, from physical security through advanced cryptographic techniques. No one document can provide comprehensive recommendations regarding all aspects of security, even in the restricted realm of real-time communication using XMPP. This document merely provides an overview of the relevant security considerations and technologies; developers must understand the specifications to which this document refers in order to correctly and completely implement the recommendations described herein.
This document does not contain a detailed analysis of threats against XMPP-based communications. However, potential threats include:
The foregoing list is not necessarily exhaustive, but provides an overview of some actual and potential threats.
In order to help combat the foregoing threats, XMPP-based clients and servers should implement the following features.
|Man in the middle attacks||Transport Layer Security, Encrypted Sessions|
|Unauthenticated users||Simple Authentication and Security Layer|
|Rogue clients and servers||Robot Challenges, Best Practices to Discourage Denial of Service Attacks, SPIM Reporting|
|Faked addresses||Enforcement of 'from' addresses, Best Practices to Prevent JID Mimicking|
|Denial of service attacks||Best Practices to Discourage Denial of Service Attacks|
|Phishing||Best Practices to Prevent JID Mimicking, best industry practices for handling of non-XMPP URIs (e.g., HTTP URLs)|
|Malware||Permit file transfers only from known entities, proper handling of images (e.g., XHTML-IM|
|Presence and information leaks||Security considerations in RFC 3920, RFC 3921, etc.|
|Unwanted communications||Robot Challenges, SPIM Reporting|
|Inappropriate archiving||Message Archiving, Chat Session Negotiation|
|Code security||Best industry practices|
This entire document addresses security.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) .
This document requires no interaction with the XMPP Registrar .
3. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
4. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://www.xmpp.org/registrar/>.