XMPP Security

Version 1

    XMPP provides several levels of security at the protocol level. Since this security is built directly into the protocol it is globally supported by XMPP implementations.

     

    Identity

     

    Identity in XMPP is much stronger than other systems such as email. Users must authenticate to their host server and messages from that user cannot be spoofed by simply replacing headers as is possible with email. This eliminates or reduces the problem of spam. Additional identity verification can be obtained by requiring clients to have valid security certificates that confirm their identity. In addition, federation can be easily and tightly controlled by limiting the federated hosts to a small whitelist of allowed participants.

     

    Client-to-Server Encryption

     

    There are two types of encryption with XMPP. The first is encryption performed during connection establishment and authentication. SASL, an industry standard used by several protocols, is used during this phase. Once the connection is established, all transmissions between the client and server are encrypted using TLS, another industry standard that grew out of the older SSL protocol. These properties mean that XMPP is secure since both the connection establishment phase and the communication phase of the protocol are encrypted.

     

    Both types of encryption are optional in XMPP, but Wildfire can be configured to accept only encrypted connections. Once the connection is encrypted it stays that way and all messages sent between the client and server are encrypted.

     

    Secure Federation

     

    The principles used to secure client-to-server connections are extended for server-to-server connections used for federation. Like client-to-server connections, server-to-server connections can be configured so that only encrypted connections, using SASL and TLS, are accepted. In addition, server dialback can be used as a method to protect against domain spoofing.

     

    The set of servers that are allowed to federate with a particular domain can also be strictly controlled. Administrators can choose to federate with any other open XMPP server, with a set of specific XMPP servers, or with no other server. This feature of the protocol allows fine-grained federation control for different applications.

     

    Resources

     

    See RFC-3920 for an in-depth technical discussion of XMPP security. Sections 5, 6, 7 and 8 describe the uses of TLS, SASL and Server Dialback.