RFC 6120
Extensible Messaging and Presence Protocol (XMPP): Core
Pages: 211
Proposed Standard
→ Errata
Obsoletes: 3920
Updated by: 7590 8553
Proposed Standard
→ Errata
Obsoletes: 3920
Updated by: 7590 8553
Part 7 of 9 – Pages 148 to 172
13. Security Considerations
13.1. Fundamentals
XMPP technologies are typically deployed using a decentralized client-server architecture. As a result, several paths are possible when two XMPP entities need to communicate: 1. Both entities are servers. In this case, the entities can establish a direct server-to-server stream between themselves.
2. One entity is a server and the other entity is a client whose
account is hosted on that server. In this case, the entities can
establish a direct client-to-server stream between themselves.
3. Both entities are clients whose accounts are hosted on the same
server. In this case, the entities cannot establish a direct
stream between themselves, but there is only one intermediate
entity between them, whose policies they might understand and in
which they might have some level of trust (e.g., the server might
require the use of Transport Layer Security for all client
connections).
4. Both entities are clients but their accounts are hosted on
different servers. In this case, the entities cannot establish a
direct stream between themselves and there are two intermediate
entities between them; each client might have some trust in the
server that hosts its account but might know nothing about the
policies of the server to which the other client connects.
This specification covers only the security of a direct XML stream
between two servers or between a client and a server (cases #1 and
#2), where each stream can be considered a single "hop" along a
communication path. The goal of security for a multi-hop path (cases
#3 and #4), although very desirable, is out of scope for this
specification.
In accordance with [SEC-GUIDE], this specification covers
communication security (confidentiality, data integrity, and peer
entity authentication), non-repudiation, and systems security
(unauthorized usage, inappropriate usage, and denial of service). We
also discuss common security issues such as information leaks,
firewalls, and directory harvesting, as well as best practices
related to the reuse of technologies such as base 64, DNS,
cryptographic hash functions, SASL, TLS, UTF-8, and XML.
13.2. Threat Model
The threat model for XMPP is in essence the standard "Internet Threat
Model" described in [SEC-GUIDE]. Attackers are assumed to be
interested in and capable of launching the following attacks against
unprotected XMPP systems:
o Eavesdropping
o Sniffing passwords
o Breaking passwords through dictionary attacks
o Discovering usernames through directory harvesting attacks o Replaying, inserting, deleting, or modifying stanzas o Spoofing users o Gaining unauthorized entry to a server or account o Using a server or account inappropriately o Denying service to other entities o Subverting communication streams through man-in-the-middle attacks o Gaining control over on-path servers Where appropriate, the following sections describe methods for protecting against these threats.13.3. Order of Layers
The order of layers in which protocols MUST be stacked is as follows: 1. TCP 2. TLS 3. SASL 4. XMPP This order has important security implications, as described throughout these security considerations. Within XMPP, XML stanzas are further ordered on top of XML streams, as described under Section 4.13.4. Confidentiality and Integrity
The use of Transport Layer Security (TLS) with appropriate ciphersuites provides a reliable mechanism to ensure the confidentiality and integrity of data exchanged between a client and a server or between two servers. Therefore, TLS can help to protect against eavesdropping, password sniffing, man-in-the-middle attacks, and stanza replays, insertion, deletion, and modification over an XML stream. XMPP clients and servers MUST support TLS as defined under Section 5.
Informational Note: The confidentiality and integrity of a stream
can be protected by methods other than TLS, e.g., by means of a
SASL mechanism that involves negotiation of a security layer.
Security Warning: The use of TLS in XMPP applies to a single
stream. Because XMPP is typically deployed using a distributed
client-server architecture (as explained under Section 2.5), a
stanza might traverse multiple streams, and not all of those
streams might be TLS-protected. For example, a stanza sent from a
client with a session at one server (e.g.,
<romeo@example.net/orchard>) and intended for delivery to a client
with a session at another server (e.g.,
<juliet@example.com/balcony>) will traverse three streams: (1) the
stream from the sender's client to its server, (2) the stream from
the sender's server to the recipient's server, and (3) the stream
from the recipient's server to the recipient's client.
Furthermore, the stanza will be processed as cleartext within the
sender's server and the recipient's server. Therefore, even if
the stream from the sender's client to its server is protected,
the confidentiality and integrity of a stanza sent over that
protected stream cannot be guaranteed when the stanza is processed
by the sender's server, sent from the sender's server to the
recipient's server, processed by the recipient's server, or sent
from the recipient's server to the recipient's client. Only a
robust technology for end-to-end encryption could ensure the
confidentiality and integrity of a stanza as it traverses all of
the "hops" along a communication path (e.g., a technology that
meets the requirements defined in [E2E-REQS]). Unfortunately, the
XMPP community has so far failed to produce an end-to-end
encryption technology that might be suitable for widespread
implementation and deployment, and definition of such a technology
is out of scope for this document.
13.5. Peer Entity Authentication
The use of the Simple Authentication and Security Layer (SASL) for
authentication provides a reliable mechanism for peer entity
authentication. Therefore, SASL helps to protect against user
spoofing, unauthorized usage, and man-in-the middle attacks. XMPP
clients and servers MUST support SASL as defined under Section 6.
13.6. Strong Security
[STRONGSEC] defines "strong security" and its importance to
communication over the Internet. For the purpose of XMPP
communication over client-to-server and server-to-server streams, the
term "strong security" refers to the use of security technologies
that provide both mutual authentication and integrity checking (e.g., a combination of TLS encryption and SASL authentication using appropriate SASL mechanisms). Implementations MUST support strong security. Service provisioning SHOULD use strong security. An implementation SHOULD make it possible for an end user or service administrator to provision a deployment with specific trust anchors for the certificate presented by a connecting entity (either client or server); when an application is thus provisioned, it MUST NOT use a generic PKI trust store to authenticate the connecting entity. More detailed rules and guidelines regarding certificate validation are provided in the next section. The initial stream and the response stream MUST be secured separately, although security in both directions MAY be established via mechanisms that provide mutual authentication.13.7. Certificates
Channel encryption of an XML stream using Transport Layer Security as described under Section 5, and in some cases also authentication as described under Section 6, is commonly based on a PKIX certificate presented by the receiving entity (or, in the case of mutual certificate authentication, both the receiving entity and the initiating entity). This section describes best practices regarding the generation of PKIX certificates to be presented by XMPP entities and the verification of PKIX certificates presented by XMPP entities. In general, the following sections rely on and extend the rules and guidelines provided in the [PKIX] profile of [X509], and in [TLS-CERTS]. The reader is referred to those specifications for a detailed understanding of PKIX certificates and their use in TLS.13.7.1. Certificate Generation
13.7.1.1. General Considerations
The following rules apply to end entity public key certificates that are issued to XMPP servers or clients: 1. The certificate MUST conform to [PKIX]. 2. The certificate MUST NOT contain a basicConstraints extension with the cA boolean set to TRUE. 3. The subject field MUST NOT be null.
4. The signatureAlgorithm SHOULD be the PKCS #1 version 1.5
signature algorithm with SHA-256 as defined by [PKIX-ALGO], or a
stronger algorithm if available.
5. The certificate SHOULD include an Authority Information Access
(AIA) extension that specifies the address of an Online
Certificate Status Protocol [OCSP] responder (if not, a relying
party would need to fall back on the use of Certificate
Revocation Lists (CRLs) as described in [PKIX]).
The following rules apply to certification authority (CA)
certificates that are used by issuers of XMPP end entity
certificates:
1. The certificate MUST conform to [PKIX].
2. The certificate MUST contain a keyUsage extension with the
digitalSignature bit set.
3. The subject field MUST NOT be null.
4. The signatureAlgorithm SHOULD be the PKCS #1 version 1.5
signature algorithm with SHA-256 as defined by [PKIX-ALGO], or a
stronger algorithm if available.
5. For issuers of public key certificates, the issuer's certificate
MUST contain a basicConstraints extension with the cA boolean set
to TRUE.
13.7.1.2. Server Certificates
13.7.1.2.1. Rules
In a PKIX certificate to be presented by an XMPP server (i.e., a
"server certificate"), the certificate SHOULD include one or more
XMPP addresses (i.e., domainparts) associated with XMPP services
hosted at the server. The rules and guidelines defined in
[TLS-CERTS] apply to XMPP server certificates, with the following
XMPP-specific considerations:
o Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP
client and server software implementations. Certification
authorities that issue XMPP-specific certificates MUST support the
DNS-ID identifier type. XMPP service providers SHOULD include the
DNS-ID identifier type in certificate requests.
o Support for the SRV-ID identifier type [PKIX-SRV] is REQUIRED for XMPP client and server software implementations (for verification purposes XMPP client implementations need to support only the "_xmpp-client" service type, whereas XMPP server implementations need to support both the "_xmpp-client" and "_xmpp-server" service types). Certification authorities that issue XMPP-specific certificates SHOULD support the SRV-ID identifier type. XMPP service providers SHOULD include the SRV-ID identifier type in certificate requests. o Support for the XmppAddr identifier type (specified under Section 13.7.1.4) is encouraged in XMPP client and server software implementations for the sake of backward-compatibility, but is no longer encouraged in certificates issued by certification authorities or requested by XMPP service providers. o DNS domain names in server certificates MAY contain the wildcard character '*' as the complete left-most label within the identifier.13.7.1.2.2. Examples
For our first (relatively simple) example, consider a company called "Example Products, Inc." It hosts an XMPP service at "im.example.com" (i.e., user addresses at the service are of the form "user@im.example.com"), and SRV lookups for the xmpp-client and xmpp- server services at "im.example.com" yield one machine, called "x.example.com", as follows: _xmpp-client._tcp.im.example.com. 400 IN SRV 20 0 5222 x.example.com _xmpp-server._tcp.im.example.com. 400 IN SRV 20 0 5269 x.example.com The certificate presented by x.example.com contains the following representations: o An otherName type of SRVName (id-on-dnsSRV) containing an IA5String (ASCII) string of "_xmpp-client.im.example.com" o An otherName type of SRVName (id-on-dnsSRV) containing an IA5String (ASCII) string of "_xmpp-server.im.example.com" o A dNSName containing an ASCII string of "im.example.com" o An otherName type of XmppAddr (id-on-xmppAddr) containing a UTF-8 string of "im.example.com" o A CN containing an ASCII string of "Example Products, Inc."
For our second (more complex) example, consider an ISP called
"Example Internet Services". It hosts an XMPP service at
"example.net" (i.e., user addresses at the service are of the form
"user@example.net"), but SRV lookups for the xmpp-client and xmpp-
server services at "example.net" yield two machines ("x1.example.net"
and "x2.example.net"), as follows:
_xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x1.example.net.
_xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x2.example.net.
_xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5269 x1.example.net.
_xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5269 x2.example.net.
Example Internet Services also hosts chatrooms at chat.example.net,
and provides an xmpp-server SRV record for that service as well (thus
enabling entities from remote domains to access that service). It
also might provide other such services in the future, so it wishes to
represent a wildcard in its certificate to handle such growth.
The certificate presented by either x1.example.net or x2.example.net
contains the following representations:
o An otherName type of SRVName (id-on-dnsSRV) containing an
IA5String (ASCII) string of "_xmpp-client.example.net"
o An otherName type of SRVName (id-on-dnsSRV) containing an
IA5String (ASCII) string of "_xmpp-server.example.net"
o An otherName type of SRVName (id-on-dnsSRV) containing an
IA5String (ASCII) string of "_xmpp-server.chat.example.net"
o A dNSName containing an ASCII string of "example.net"
o A dNSName containing an ASCII string of "*.example.net"
o An otherName type of XmppAddr (id-on-xmppAddr) containing a UTF-8
string of "example.net"
o An otherName type of XmppAddr (id-on-xmppAddr) containing a UTF-8
string of "chat.example.net"
o A CN containing an ASCII string of "Example Internet Services"
13.7.1.3. Client Certificates
In a PKIX certificate to be presented by an XMPP client controlled by a human user (i.e., a "client certificate"), it is RECOMMENDED for the certificate to include one or more JIDs associated with an XMPP user. If included, a JID MUST be represented as an XmppAddr as specified under Section 13.7.1.4.13.7.1.4. XmppAddr Identifier Type
The XmppAddr identifier type is a UTF8String within an otherName entity inside the subjectAltName, using the [ASN.1] Object Identifier "id-on-xmppAddr" specified below. id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) } id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 } XmppAddr ::= UTF8String As an alternative to the "id-on-xmppAddr" notation, this Object Identifier MAY be represented in dotted display format (i.e., "1.3.6.1.5.5.7.8.5") or in the Uniform Resource Name notation specified in [URN-OID] (i.e., "urn:oid:1.3.6.1.5.5.7.8.5"). Thus for example the JID <juliet@im.example.com> as included in a certificate could be formatted in any of the following three ways: id-on-xmppAddr: subjectAltName=otherName:id-on-xmppAddr;UTF8:juliet@im.example.com dotted display format: subjectAltName=otherName: 1.3.6.1.5.5.7.8.5;UTF8:juliet@im.example.com URN notation: subjectAltName=otherName:urn:oid: 1.3.6.1.5.5.7.8.5;UTF8:juliet@im.example.com Use of the "id-on-xmppAddr" format is RECOMMENDED in the generation of certificates, but all three formats MUST be supported for the purpose of certificate validation. The "id-on-xmppAddr" object identifier MAY be used in conjunction with the extended key usage extension specified in Section 4.2.1.12 of [PKIX] in order to explicitly define and limit the intended use of a certificate to the XMPP network.
13.7.2. Certificate Validation
When an XMPP entity is presented with a server certificate or client certificate by a peer for the purpose of encryption or authentication of XML streams as described under Section 5 and Section 6, the entity MUST attempt to validate the certificate to determine if the certificate will be considered a "trusted certificate", i.e., a certificate that is acceptable for encryption and/or authentication in accordance with the XMPP entity's local service policies or configured settings. For both server certificates and client certificates, the validating entity MUST do the following: 1. Attempt to verify the integrity of the certificate. 2. Attempt to verify that the certificate has been properly signed by the issuing Certificate Authority. 3. Attempt to validate the full certification path. 4. Check the rules for end entity public key certificates and certification authority certificates specified under Section 13.7.1.1 for the general case and under either Section 13.7.1.2 or Section 13.7.1.3 for XMPP server or client certificates, respectively. 5. Check certificate revocation messages via Certificate Revocation Lists (CRLs), the Online Certificate Status Protocol [OCSP], or both. If any of those validation attempts fail, the validating entity MUST unilaterally terminate the session. The following sections describe the additional identity verification rules that apply to server-to-server and client-to-server streams. Once the identity of the stream peer has been validated, the validating entity SHOULD also correlate the validated identity with the 'from' address (if any) of the stream header it received from the peer. If the two identities do not match, the validating entity SHOULD terminate the connection attempt (however, there might be good reasons why the identities do not match, as described under Section 4.7.1).
13.7.2.1. Server Certificates
For server certificates, the rules and guidelines defined in [TLS-CERTS] apply, with the proviso that the XmppAddr identifier specified under Section 13.7.1.4 is allowed as a reference identifier. The identities to be checked are set as follows: o The initiating entity sets the source domain of its reference identifiers to the 'to' address it communicates in the initial stream header; i.e., this is the identity it expects the receiving entity to provide in a PKIX certificate. o The receiving entity sets the source domain of its reference identifiers to the 'from' address communicated by the initiating entity in the initial stream header; i.e., this is the identity that the initiating entity is trying to assert. In the case of server-to-server communication, the matching procedure described in [TLS-CERTS] can be performed by an application server (receiving entity) when verifying an incoming server-to-server connection from a peer server (initiating entity). In this case, the receiving entity verifies the identity of the initiating entity and uses as the source domain of its reference identifiers the DNS domain name asserted by the initiating entity in the 'from' attribute of the initial stream header. However, the matching procedure described in [TLS-CERTS] remains unchanged and is applied in the same way.13.7.2.2. Client Certificates
When an XMPP server validates a certificate presented by a client, there are three possible cases, as discussed in the following sections. The identities to be checked are set as follows: o The client sets the source domain of its reference identifiers to the 'to' address it communicates in the initial stream header; i.e., this is the identity it expects the server to provide in a PKIX certificate. o The server sets the bare JID of its reference identifiers to the 'from' address communicated by the initiating entity in the initial stream header; i.e., this is the identity that the client is trying to assert.
13.7.2.2.1. Case #1
If the client certificate appears to be certified by a certification path terminating in a trust anchor (as described in Section 6.1 of [PKIX]), the server MUST check the certificate for any instances of the XmppAddr as described under Section 13.7.1.4. There are three possible sub-cases: Sub-Case #1: The server finds one XmppAddr for which the domainpart of the represented JID matches one of the configured FQDNs of the server; the server SHOULD use this represented JID as the validated identity of the client. Sub-Case #2: The server finds more than one XmppAddr for which the domainpart of the represented JID matches one of the configured FQDNs of the server; the server SHOULD use one of these represented JIDs as the validated identity of the client, choosing among them based on the bare JID contained in the 'from' address of the initial stream header (if any), based on the domainpart contained in the 'to' address of the initial stream header, or in accordance with local service policies (such as a lookup in a user database based on other information contained in the client certificate). Sub-Case #3: The server finds no XmppAddrs, or finds at least one XmppAddr but the domainpart of the represented JID does not match one of the configured FQDNs of the server; the server MUST NOT use the represented JID (if any) as the validated identity of the client but instead MUST validate the identity of the client using other means in accordance with local service policies (such as a lookup in a user database based on other information contained in the client certificate). If the identity cannot be so validated, the server MAY abort the validation process and terminate the TLS negotiation.13.7.2.2.2. Case #2
If the client certificate is certified by a Certificate Authority not known to the server, the server MUST proceed as under Case #1, Sub- Case #3.13.7.2.2.3. Case #3
If the client certificate is self-signed, the server MUST proceed as under Case #1, Sub-Case #3.
13.7.2.3. Checking of Certificates in Long-Lived Streams
Because XMPP uses long-lived XML streams, it is possible that a certificate presented during stream negotiation might expire or be revoked while the stream is still live (this is especially relevant in the context of server-to-server streams). Therefore, each party to a long-lived stream SHOULD: 1. Cache the expiration date of the certificate presented by the other party and any certificates on which that certificate depends (such as a root or intermediate certificate for a certification authority), and close the stream when any such certificate expires, with a stream error of <reset/> (Section 4.9.3.16). 2. Periodically query the Online Certificate Status Protocol [OCSP] responder listed in the Authority Information Access (AIA) extension of the certificate presented by the other party and any certificates on which that certificate depends (such as a root or intermediate certificate for a certification authority), and close the stream if any such certificate has been revoked, with a stream error of <reset/> (Section 4.9.3.16). It is RECOMMENDED to query the OSCP responder at or near the time communicated via the nextUpdate field received in the OCSP response or, if the nextUpdate field is not set, to query every 24 hours. After the stream is closed, the initiating entity from the closed stream will need to reconnect and the receiving entity will need to authenticate the initiating entity based on whatever certificate it presents during negotiation of the new stream.13.7.2.4. Use of Certificates in XMPP Extensions
Certificates MAY be used in extensions to XMPP for the purpose of application-layer encryption or authentication above the level of XML streams (e.g., for end-to-end encryption). Such extensions will define their own certificate handling rules. At a minimum, such extensions are encouraged to remain consistent with the rules defined in this specification, specifying additional rules only when necessary.13.8. Mandatory-to-Implement TLS and SASL Technologies
The following TLS ciphersuites and SASL mechanisms are mandatory-to- implement (naturally, implementations MAY support other ciphersuites and mechanisms as well). For security considerations related to TLS ciphersuites, see Section 13.9.4 and [TLS]. For security
considerations related to SASL mechanisms, see Section 13.9.4, [SASL], and specifications for particular SASL mechanisms such as [SCRAM], [DIGEST-MD5], and [PLAIN].13.8.1. For Authentication Only
For authentication only, servers and clients MUST support the SASL Salted Challenge Response Authentication Mechanism [SCRAM] -- in particular, the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS variants. Security Warning: Even though it is possible to complete authentication only without confidentiality, it is RECOMMENDED for servers and clients to protect the stream with TLS before attempting authentication with SASL, both to help protect the information exchanged during SASL negotiation and to help prevent certain downgrade attacks as described under Section 13.9.4 and Section 13.9.5. Even if TLS is used, implementations SHOULD also enforce channel binding as described under Section 13.9.4. Interoperability Note: The SCRAM-SHA-1 or SASL-SCRAM-SHA-1-PLUS variants of the SCRAM mechanism replace the SASL DIGEST-MD5 mechanism as XMPP's mandatory-to-implement password-based method for authentication only. For backward-compatibility with existing deployed infrastructure, implementations are encouraged to continue supporting the DIGEST-MD5 mechanism as specified in [DIGEST-MD5]; however, there are known interoperability issues with DIGEST-MD5 that make it impractical in the long term.13.8.2. For Confidentiality Only
For confidentiality only, servers MUST support TLS with the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. Security Warning: Because a connection with confidentiality only has weaker security properties than a connection with both confidentiality and authentication, it is RECOMMENDED for servers and clients to prefer connections with both qualities (e.g., by protecting the stream with TLS before attempting authentication with SASL). In practice, confidentiality only is employed merely for server-to-server connections when the peer server does not present a trusted certificate and the servers use Server Dialback [XEP-0220] for weak identity verification, but TLS with confidentiality only is still desirable to protect the connection against casual eavesdropping.
13.8.3. For Confidentiality and Authentication with Passwords
For both confidentiality and authentication with passwords, servers and clients MUST implement TLS with the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus SASL SCRAM, in particular the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS variants (with SCRAM-SHA1-PLUS being preferred, as described under Section 13.9.4). As further explained in the following Security Warning, in certain circumstances a server MAY offer TLS with the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus SASL PLAIN when it is not possible to offer more secure alternatives; in addition, clients SHOULD implement PLAIN over TLS in order to maximize interoperability with servers that are not able to deploy more secure alternatives. Security Warning: In practice, many servers offer, and many clients use, TLS plus SASL PLAIN. The SCRAM-SHA-1 and especially SCRAM-SHA-1-PLUS variants of the SCRAM mechanism are strongly preferred over the PLAIN mechanism because of their superior security properties (including for SCRAM-SHA-1-PLUS the ability to enforce channel binding as described under Section 13.9.4). A client SHOULD treat TLS plus SASL PLAIN as a technology of last resort to be used only when interacting with a server that does not offer SCRAM (or other alternatives that are more secure than TLS plus SASL PLAIN), MUST prefer more secure mechanisms (e.g., EXTERNAL, SCRAM-SHA-1-PLUS, SCRAM-SHA-1, or the older DIGEST-MD5 mechanism) to the PLAIN mechanism, and MUST NOT use the PLAIN mechanism if the stream does not at a minimum have confidentiality and integrity protection via TLS with full certificate validation as described under Section 13.7.2.1. A server MUST NOT offer SASL PLAIN if the confidentiality and integrity of the stream are not protected via TLS or an equivalent security layer. A server SHOULD NOT offer TLS plus SASL PLAIN unless it is unable to offer some variant of SASL SCRAM (or other alternatives that are more secure than TLS plus SASL PLAIN), e.g., because the XMPP service depends for authentication purposes on a database or directory that is not under the control of the XMPP administrators, such as Pluggable Authentication Modules (PAM), an Lightweight Directory Access Protocol (LDAP) directory [LDAP], or an Authentication, Authorization, and Accounting (AAA) key management protocol (for guidance, refer to [AAA]). However, offering TLS plus SASL PLAIN even when the server supports more secure alternatives might be appropriate if the server needs to enable interoperability with an installed base of clients that do not yet support SCRAM or other alternatives that are more secure than TLS plus SASL PLAIN.
13.8.4. For Confidentiality and Authentication without Passwords
For both confidentiality and authentication without passwords, servers MUST and clients SHOULD implement TLS with the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus the SASL EXTERNAL mechanism (see Appendix A of [SASL]) with PKIX certificates.13.9. Technology Reuse
13.9.1. Use of Base 64 in SASL
Both the client and the server MUST verify any base 64 data received during SASL negotiation (Section 6). An implementation MUST reject (not ignore) any characters that are not explicitly allowed by the base 64 alphabet; this helps to guard against creation of a covert channel that could be used to "leak" information. An implementation MUST NOT break on invalid input and MUST reject any sequence of base 64 characters containing the pad ('=') character if that character is included as something other than the last character of the data (e.g., "=AAA" or "BBBB=CCC"); this helps to guard against buffer overflow attacks and other attacks on the implementation. While base 64 encoding visually hides otherwise easily recognized information (such as passwords), it does not provide any computational confidentiality. All uses of base 64 encoding MUST follow the definition in Section 4 of [BASE64] and padding bits MUST be set to zero.13.9.2. Use of DNS
XMPP typically relies on the Domain Name System (specifically [DNS-SRV] records) to resolve a fully qualified domain name to an IP address before a client connects to a server or before a peer server connects to another server. Before attempting to negotiate an XML stream, the initiating entity MUST NOT proceed until it has resolved the DNS domain name of the receiving entity as specified under Section 3 (although it is not necessary to resolve the DNS domain name before each connection attempt, because DNS resolution results can be temporarily cached in accordance with time-to-live values). However, in the absence of a secure DNS option (e.g., as provided by [DNSSEC]), a malicious attacker with access to the DNS server data, or able to cause spoofed answers to be cached in a recursive resolver, can potentially cause the initiating entity to connect to any XMPP server chosen by the attacker. Deployment and validation of server certificates help to prevent such attacks.
13.9.3. Use of Hash Functions
XMPP itself does not directly mandate the use of any particular cryptographic hash function. However, technologies on which XMPP depends (e.g., TLS and particular SASL mechanisms), as well as various XMPP extensions, might make use of cryptographic hash functions. Those who implement XMPP technologies or who develop XMPP extensions are advised to closely monitor the state of the art regarding attacks against cryptographic hash functions in Internet protocols as they relate to XMPP. For helpful guidance, refer to [HASHES].13.9.4. Use of SASL
Because the initiating entity chooses an acceptable SASL mechanism from the list presented by the receiving entity, the initiating entity depends on the receiving entity's list for authentication. This dependency introduces the possibility of a downgrade attack if an attacker can gain control of the channel and therefore present a weak list of mechanisms. To mitigate this attack, the parties SHOULD protect the channel using TLS before attempting SASL negotiation and either perform full certificate validation as described under Section 13.7.2.1 or use a SASL mechanism that provides channel bindings, such as SCRAM-SHA-1-PLUS. (Protecting the channel via TLS with full certificate validation can help to ensure the confidentiality and integrity of the information exchanged during SASL negotiation.) The SASL framework itself does not provide a method for binding SASL authentication to a security layer providing confidentiality and integrity protection that was negotiated at a lower layer (e.g., TLS). Such a binding is known as a "channel binding" (see [CHANNEL]). Some SASL mechanisms provide channel bindings, which in the case of XMPP would typically be a binding to TLS (see [CHANNEL-TLS]). If a SASL mechanism provides a channel binding (e.g., this is true of [SCRAM]), then XMPP entities using that mechanism SHOULD prefer the channel binding variant (e.g., preferring "SCRAM-SHA-1-PLUS" over "SCRAM-SHA-1"). If a SASL mechanism does not provide a channel binding, then the mechanism cannot provide a way to verify that the source and destination end points to which the lower layer's security is bound are equivalent to the end points that SASL is authenticating; furthermore, if the end points are not identical, then the lower layer's security cannot be trusted to protect data transmitted between the SASL-authenticated entities. In such a situation, a SASL security layer SHOULD be negotiated that effectively ignores the presence of the lower-layer security.
Many deployed XMPP services authenticate client connections by means of passwords. It is well known that most human users choose relatively weak passwords. Although service provisioning is out of scope for this document, XMPP servers that allow password-based authentication SHOULD enforce minimal criteria for password strength to help prevent dictionary attacks. Because all password-based authentication mechanisms are susceptible to password guessing attacks, XMPP servers MUST limit the number of retries allowed during SASL authentication, as described under Section 6.4.5. Some SASL mechanisms (e.g., [ANONYMOUS]) do not provide strong peer entity authentication of the client to the server. Service administrators are advised to enable such mechanisms with caution. Best practices for the use of the SASL ANONYMOUS mechanism in XMPP are described in [XEP-0175].13.9.5. Use of TLS
Implementations of TLS typically support multiple versions of the Transport Layer Security protocol as well as the older Secure Sockets Layer (SSL) protocol. Because of known security vulnerabilities, XMPP servers and clients MUST NOT request, offer, or use SSL 2.0. For further details, see Appendix E.2 of [TLS] along with [TLS-SSL2]. To prevent man-in-the-middle attacks, the TLS client (which might be an XMPP client or an XMPP server) MUST verify the certificate of the TLS server and MUST check its understanding of the server FQDN against the server's identity as presented in the TLS Certificate message as described under Section 13.7.2.1 (for further details, see [TLS-CERTS]. Support for TLS renegotiation is strictly OPTIONAL. However, implementations that support TLS renegotiation MUST implement and use the TLS Renegotiation Extension [TLS-NEG]. Further details are provided under Section 5.3.5.13.9.6. Use of UTF-8
The use of UTF-8 makes it possible to transport non-ASCII characters, and thus enables character "spoofing" scenarios, in which a displayed value appears to be something other than it is. Furthermore, there are known attack scenarios related to the decoding of UTF-8 data. On both of these points, refer to [UTF-8] for more information.
13.9.7. Use of XML
Because XMPP is an application profile of the Extensible Markup Language [XML], many of the security considerations described in [XML-MEDIA] and [XML-GUIDE] also apply to XMPP. Several aspects of XMPP mitigate the risks described there, such as the prohibitions specified under Section 11.1 and the lack of external references to style sheets or transformations, but these mitigating factors are by no means comprehensive.13.10. Information Leaks
13.10.1. IP Addresses
A client's IP address and method of access MUST NOT be made public by a server (e.g., as typically occurs in [IRC]).13.10.2. Presence Information
One of the core aspects of XMPP is presence: information about the network availability of an XMPP entity (i.e., whether the entity is currently online or offline). A "presence leak" occurs when an entity's network availability is inadvertently and involuntarily revealed to a second entity that is not authorized to know the first entity's network availability. Although presence is discussed more fully in [XMPP-IM], it is important to note that an XMPP server MUST NOT leak presence. In particular at the core XMPP level, real-time addressing and network availability is associated with a specific connected resource; therefore, any disclosure of a connected resource's full JID comprises a presence leak. To help prevent such a presence leak, a server MUST NOT return different stanza errors depending on whether a potential attacker sends XML stanzas to the entity's bare JID (<localpart@domainpart>) or full JID (<localpart@domainpart/resourcepart>).13.11. Directory Harvesting
If a server generates an error stanza in response to receiving a stanza for a user account that does not exist, using the <service- unavailable/> stanza error condition (Section 8.3.3.19) can help protect against directory harvesting attacks, since this is the same error condition that is returned if, for instance, the namespace of an IQ child element is not understood, or if "offline message storage" ([XEP-0160]) or message forwarding is not enabled for a domain. However, subtle differences in the exact XML of error stanzas, as well as in the timing with which such errors are
returned, can enable an attacker to determine the network presence of a user when more advanced blocking technologies are not used (see for instance [XEP-0016] and [XEP-0191]). Therefore, a server that exercises a higher level of caution might not return any error at all in response to certain kinds of received stanzas, so that a non- existent user appears to behave like a user that has no interest in conversing with the sender.13.12. Denial of Service
[DOS] defines denial of service as follows: A denial-of-service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work. The victim can be a network server, client or router, a network link or an entire network, an individual Internet user or a company doing business using the Internet, an Internet Service Provider (ISP), country, or any combination of or variant on these. Some considerations discussed in this document help to prevent denial-of-service attacks (e.g., the mandate that a server MUST NOT process XML stanzas from clients that have not yet provided appropriate authentication credentials and MUST NOT process XML stanzas from peer servers whose identity it has not either authenticated via SASL or weakly verified via Server Dialback). In addition, [XEP-0205] provides a detailed discussion of potential denial-of-service attacks against XMPP systems along with best practices for preventing such attacks. The recommendations include: 1. A server implementation SHOULD enable a server administrator to limit the number of TCP connections that it will accept from a given IP address at any one time. If an entity attempts to connect but the maximum number of TCP connections has been reached, the receiving server MUST NOT allow the new connection to proceed. 2. A server implementation SHOULD enable a server administrator to limit the number of TCP connection attempts that it will accept from a given IP address in a given time period. If an entity attempts to connect but the maximum number of connection attempts has been reached, the receiving server MUST NOT allow the new connection to proceed. 3. A server implementation SHOULD enable a server administrator to limit the number of connected resources it will allow an account to bind at any one time. If a client attempts to bind a resource
but it has already reached the configured number of allowable
resources, the receiving server MUST return a <resource-
constraint/> stanza error (Section 8.3.3.18).
4. A server implementation SHOULD enable a server administrator to
limit the size of stanzas it will accept from a connected client
or peer server (where "size" is inclusive of all XML markup as
defined in Section 2.4 of [XML], from the opening "<" character
of the stanza to the closing ">" character). A deployed server's
maximum stanza size MUST NOT be smaller than 10000 bytes, which
reflects a reasonable compromise between the benefits of
expressiveness for originating entities and the costs of stanza
processing for servers. A server implementation SHOULD NOT
blindly set 10000 bytes as the value for all deployments but
instead SHOULD enable server administrators to set their own
limits. If a connected resource or peer server sends a stanza
that violates the upper limit, the receiving server MUST either
return a <policy-violation/> stanza error (Section 8.3.3.12),
thus allowing the sender to recover, or close the stream with a
<policy-violation/> stream error (Section 4.9.3.14).
5. A server implementation SHOULD enable a server administrator to
limit the number of XML stanzas that a connected client is
allowed to send to distinct recipients within a given time
period. If a connected client sends too many stanzas to distinct
recipients in a given time period, the receiving server SHOULD
NOT process the stanza and instead SHOULD return a <policy-
violation/> stanza error (Section 8.3.3.12).
6. A server implementation SHOULD enable a server administrator to
limit the amount of bandwidth it will allow a connected client or
peer server to use in a given time period.
7. A server implementation MAY enable a server administrator to
limit the types of stanzas (based on the extended content
"payload") that it will allow a connected resource or peer server
send over an active connection. Such limits and restrictions are
a matter of deployment policy.
8. A server implementation MAY refuse to route or deliver any stanza
that it considers to be abusive, with or without returning an
error to the sender.
For more detailed recommendations regarding denial-of-service attacks
in XMPP systems, refer to [XEP-0205].
13.13. Firewalls
Although DNS SRV records can instruct connecting entities to use TCP ports other than 5222 (client-to-server) and 5269 (server-to-server), communication using XMPP typically occurs over those ports, which are registered with the IANA (see Section 14). Use of these well-known ports allows administrators to easily enable or disable XMPP activity through existing and commonly deployed firewalls.13.14. Interdomain Federation
The term "federation" is commonly used to describe communication between two servers. Because service provisioning is a matter of policy, it is OPTIONAL for any given server to support federation. If a particular server enables federation, it SHOULD enable strong security as previously described to ensure both authentication and confidentiality; compliant implementations SHOULD support TLS and SASL for this purpose. Before RFC 3920 defined TLS plus SASL EXTERNAL with certificates for encryption and authentication of server-to-server streams, the only method for weak identity verification of a peer server was Server Dialback as defined in [XEP-0220]. Even when [DNSSEC] is used, Server Dialback provides only weak identity verification and provides no confidentiality or integrity. At the time of writing, Server Dialback is still the most widely used technique for some level of assurance over server-to-server streams. This reality introduces the possibility of a downgrade attack from TLS + SASL EXTERNAL to Server Dialback if an attacker can gain control of the channel and therefore convince the initiating server that the receiving server does not support TLS or does not have an appropriate certificate. To help prevent this attack, the parties SHOULD protect the channel using TLS before proceeding, even if the presented certificates are self-signed or otherwise untrusted.13.15. Non-Repudiation
Systems that provide both peer entity authentication and data integrity have the potential to enable an entity to prove to a third party that another entity intended to send particular data. Although XMPP systems can provide both peer entity authentication and data integrity, XMPP was never designed to provide non-repudiation.
14. IANA Considerations
The following subsections update the registrations provided in [RFC3920]. This section is to be interpreted according to [IANA-GUIDE].14.1. XML Namespace Name for TLS Data
A URN sub-namespace for STARTTLS negotiation data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].) URI: urn:ietf:params:xml:ns:xmpp-tls Specification: RFC 6120 Description: This is the XML namespace name for STARTTLS negotiation data in the Extensible Messaging and Presence Protocol (XMPP) as defined by RFC 6120. Registrant Contact: IESG <iesg@ietf.org>14.2. XML Namespace Name for SASL Data
A URN sub-namespace for SASL negotiation data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].) URI: urn:ietf:params:xml:ns:xmpp-sasl Specification: RFC 6120 Description: This is the XML namespace name for SASL negotiation data in the Extensible Messaging and Presence Protocol (XMPP) as defined by RFC 6120. Registrant Contact: IESG <iesg@ietf.org>14.3. XML Namespace Name for Stream Errors
A URN sub-namespace for stream error data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].) URI: urn:ietf:params:xml:ns:xmpp-streams Specification: RFC 6120 Description: This is the XML namespace name for stream error data in the Extensible Messaging and Presence Protocol (XMPP) as defined by RFC 6120. Registrant Contact: IESG <iesg@ietf.org>
14.4. XML Namespace Name for Resource Binding
A URN sub-namespace for resource binding in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].) URI: urn:ietf:params:xml:ns:xmpp-bind Specification: RFC 6120 Description: This is the XML namespace name for resource binding in the Extensible Messaging and Presence Protocol (XMPP) as defined by RFC 6120. Registrant Contact: IESG <iesg@ietf.org>14.5. XML Namespace Name for Stanza Errors
A URN sub-namespace for stanza error data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].) URI: urn:ietf:params:xml:ns:xmpp-stanzas Specification: RFC 6120 Description: This is the XML namespace name for stanza error data in the Extensible Messaging and Presence Protocol (XMPP) as defined by RFC 6120. Registrant Contact: IESG <iesg@ietf.org>14.6. GSSAPI Service Name
The IANA has registered "xmpp" as a [GSS-API] service name, as defined under Section 6.6.14.7. Port Numbers and Service Names
The IANA has registered "xmpp-client" and "xmpp-server" as keywords for [TCP] ports 5222 and 5269, respectively. In accordance with [IANA-PORTS], this document updates the existing registration, as follows. Service Name: xmpp-client Transport Protocol: TCP Description: A service offering support for connections by XMPP client applications Registrant: IETF XMPP Working Group Contact: IESG <iesg@ietf.org> Reference: RFC 6120 Port Number: 5222
Service Name: xmpp-server
Transport Protocol: TCP
Description: A service offering support for connections by XMPP
server applications
Registrant: IETF XMPP Working Group
Contact: IESG <iesg@ietf.org>
Reference: RFC 6120
Port Number: 5269
(page 172 continued on part 8)