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