tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6120

 
 
 

Extensible Messaging and Presence Protocol (XMPP): Core

Part 7 of 9, p. 148 to 172
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 148 
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.

Top      Up      ToC       Page 149 
   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

Top      Up      ToC       Page 150 
   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.

Top      Up      ToC       Page 151 
      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

Top      Up      ToC       Page 152 
   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.

Top      Up      ToC       Page 153 
   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.

Top      Up      ToC       Page 154 
   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."

Top      Up      ToC       Page 155 
   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"

Top      Up      ToC       Page 156 
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.

Top      Up      ToC       Page 157 
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).

Top      Up      ToC       Page 158 
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.

Top      Up      ToC       Page 159 
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.

Top      Up      ToC       Page 160 
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

Top      Up      ToC       Page 161 
   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.

Top      Up      ToC       Page 162 
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.

Top      Up      ToC       Page 163 
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.

Top      Up      ToC       Page 164 
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.

Top      Up      ToC       Page 165 
   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.

Top      Up      ToC       Page 166 
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

Top      Up      ToC       Page 167 
   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

Top      Up      ToC       Page 168 
       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].

Top      Up      ToC       Page 169 
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.

Top      Up      ToC       Page 170 
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>

Top      Up      ToC       Page 171 
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

Top      Up      ToC       Page 172 
   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)

Next RFC Part