E2E Authentication in XMPP This specification describes how X.509 certificates can be used for end-to-end authentication in XMPP. This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF). Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. ## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ## In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages. This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA). 0416 Deferred Standards Track Standards Council XMPP Core XEP-0001 NOT_YET_ASSIGNED Evgeny Khramtsov ekhramtsov@process-one.net xram@zinid.ru 0.1.0 2019-03-06 XEP Editor (jsc) Accepted by vote of Council on 2019-02-27. 0.0.1 2019-02-08 evk

First draft.

X.509 version 3 certificates can be used to provide a strong cryptographic identity of an XMPP entity, i.e. an association of an XMPP address (RFC 7622 RFC 7622: Extensible Messaging and Presence Protocol (XMPP): Address Format <http://tools.ietf.org/html/rfc7622>.) with its cryptographic key (formally defined under Section 13.7.1.4 of RFC 6120 RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.). They were initially intended for the use in SASL EXTERNAL for c2s and mutual s2s authentication (see Best Practices for Use of SASL EXTERNAL (XEP-0178) XEP-0178: Best Practices for Use of SASL EXTERNAL <https://xmpp.org/extensions/xep-0178.html>.). This document extends their usage for end-to-end (e2e) authentication of any entities attached to the XMPP network. A separate document also defines how Certificate Signing Request (CSR) of an XMPP account can be issued and signed using the XMPP protocol (XEP-EAX-SIGN).

Example usages:

E2E encryption
For end-to-end encryption, XMPP clients may use certificates to mutually identify each other, i.e. check that the cryptographic key belongs to this exact XMPP address.
External services
An XMPP server may authenticate users of other servers at its local services, such as an HTTP Upload component (HTTP File Upload (XEP-0363) XEP-0363: HTTP File Upload <https://xmpp.org/extensions/xep-0363.html>.), e.g. for granting file uploads, or a TURN server (RFC 5766 RFC 5766: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) <http://tools.ietf.org/html/rfc5766>.).
XMPP Usage of RELOAD
XMPP entities attached to the XOR overlay (XEP-0415) are supposed to use certificates for mutual authentication.
SPAM protection
Since certificate authorities are required to be Sybil resistant (XEP-EAX-CAR), a spammer is limited in ability to create accounts massively. Thus it is expected that SPAM dissemination will fall to negligible levels.
Registration delegation
XMPP accounts registration typically creates a huge burden for operators of public servers. An operator may want to delegate a registration of accounts of its own server to a trusted CA. The CA will validate the users' identities and will issue certificates for them. The users can use these certificates in c2s SASL EXTERNAL authentication at the operator's server as well as for e2e authentication with other entities.

Note that an XMPP client may use the same certificate for different kinds of e2e authentication.

Conceptually, the idea is to build PKIX trees where in each tree a node corresponds to a certificate of a CA signing certificates of its successors. A leaf in the tree represents a certificate assigned to an XMPP account, a "leaf certificate". The leaf certificates are supposed to be used for (but not limited to) e2e authentication.

In the example above, XMPP servers of domains "capulet.lit" and "montague.lit" do not have associated certificate authorities, so Root CA 1 and Intermediate CA 2.1 sign certificates of "juliet@capulet.lit" and "romeo@montague.lit" directly. An XMPP server of domain "shakespeare.lit" has an associated CA (whose certificate is signed by Root CA N) and thus is able to sign certificates for users of "shakespeare.lit" (and only for them). As long as all root CAs are trusted by all parties, "juliet@capulet.lit", "romeo@montague.lit" and "bard@shakespeare.lit" may mutually authenticate each other using their certificates (for sharing resources, exchanging messages, etc).
CA
Certificate authority - an entity that issues X.509 certificates.
CSR
Certificate signing request - a message sent from an applicant to a certificate authority in order to apply for an X.509 certificate.
Leaf certificate
A certificate assigned to an XMPP account.
Domain-associated certificate
An intermediate certificate assigned for a particular XMPP domain. Such certificates can be used to sign leaf certificates associated with the same XMPP domain only.
Intermediate certificate
A non-root certificate used for signing any other certificates.
Root certificate
A self-signed certificate used for signing any other certificates.
  1. The leaf certificate MUST be compliant with c2s SASL EXTERNAL authentication (RFC 6120 RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>., Best Practices for Use of SASL EXTERNAL (XEP-0178) XEP-0178: Best Practices for Use of SASL EXTERNAL <https://xmpp.org/extensions/xep-0178.html>.).
  2. The leaf certificate MUST be compliant with RELOAD authentication (RFC 6940 RFC 6940: REsource LOcation And Discovery (RELOAD) Base Protocol <http://tools.ietf.org/html/rfc6940>.).

The following rules apply to any certificate:

  1. The certificate MUST conform to RFC 5280 RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile <http://tools.ietf.org/html/rfc5280>..
  2. The subject field MUST NOT be null.
  3. The certificate MUST contain a keyUsage extension with the digitalSignature bit set.
  4. The certificate SHOULD use Elliptic Curve Cryptography. FIXME: correctly define this statement.

The following rules apply to leaf certificates:

  1. The certificate MUST NOT contain a basicConstraints extension with the cA boolean set to TRUE.
  2. The certificate MUST include a CRL Distribution Points extension that specifies an URI of a Certificate Revocation List.
  3. The certificate MUST possess a single XMPP address represented as an XmppAddr as specified under Section 13.7.1.4 of RFC 6120 RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>..
  4. The SubjectAltName field in the certificate MUST contain a single RELOAD URI as specified under Section 14.15 of RFC 6940 RFC 6940: REsource LOcation And Discovery (RELOAD) Base Protocol <http://tools.ietf.org/html/rfc6940>. encoded as uniformResourceIdentifier type. The "destination" part of the URI MUST be a RELOAD Node-ID. The Node-ID MAY be hexadecimal-encoded. The "overlay" part of the URI MUST be "xmpp.org". The "specifier" part of the URI MUST be empty.
  5. If the XMPP address doesn't contain non-ASCII characters, it MUST be encoded in the SubjectAltName field as rfc822Name type.

Note that the rules for leaf certificates comply with the rules defined for client certificates under Sections 13.7.1.1 and 13.7.1.4 of RFC 6120 RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>.. Thus they can be used for c2s SASL EXTERNAL authentication.

The requirement to possess a RELOAD URI and an rfc822Name address makes it possible to use the certificate for RELOAD authentication. Even if XOR extension (XEP-0415) is unused, the RELOAD URI uniquely identifies a user device: a user MAY have several certificates assigned to their XMPP address but with different RELOAD URIs.

The following rules apply to domain-associated certificates:

  1. The certificate MUST contain a keyUsage extension with the keyCertSign bit set.
  2. The certificate MUST contain a basicConstraints extension with the cA boolean set to TRUE and pathLenConstraint set to 0 (zero).
  3. The certificate MUST include a CRL Distribution Points extension that specifies an URI of a Certificate Revocation List.
  4. The certificate MUST possess the associated domain name encoded as DNS-ID identifier type. The domain name MUST NOT contain the wildcard character '*'.

The following rules apply to intermediate certificates, excluding domain-associated certificates:

  1. The certificate MUST contain a keyUsage extension with the keyCertSign bit set.
  2. The certificate MUST contain a basicConstraints extension with the cA boolean set to TRUE.
  3. The certificate MUST include a CRL Distribution Points extension that specifies an URI of a Certificate Revocation List.

The following rules apply to root certificates:

  1. The certificate MUST contain a keyUsage extension with the keyCertSign bit set.
  2. The certificate MUST contain a basicConstraints extension with the cA boolean set to TRUE.

CA Requirements are outlined in XEP-EAX-CAR.

The certificate is considered valid if it follows the rules specified in Certificate Requirements and, in the case when it is signed by a domain-associated certificate, it is a leaf certificate and the domain from the domain-associated certificate matches the domain part of the XmppAddr of the certificate. Otherwise, the certificate MUST be considered invalid.

In the case of a certificate chain, the rules for certification path validation are applied (RFC 5280 RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile <http://tools.ietf.org/html/rfc5280>.).

An XMPP entity MAY maintain its own list of root certificates. However, in practice it's convenient to retrieve this list from a trusted source. For example, several organizations in the Internet maintain and provide such lists for certificates verification in the Web. This section specifies how the list of root certificates can be retrieved for the purpose of e2e authentication in XMPP.

Since the authentication is intended to be compliant with RELOAD and creating new document formats or DNS TXT records without exigency are in general discouraged, the Overlay Configuration document is reused to provide the list of root certificates (see Section 11.1 of RFC 6940 RFC 6940: REsource LOcation And Discovery (RELOAD) Base Protocol <http://tools.ietf.org/html/rfc6940>.). The root certificates are PEM-encoded (RFC 7468 RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures <http://tools.ietf.org/html/rfc7468>.) with encapsulation boundaries removed and are included in <root-cert/> elements of the Overlay Configuration.

In order to retrieve the Overlay Configuration, an HTTP GET request is performed to "https://xmpp.org/.well-known/reload-config". The requesting UA MUST be prepared to process HTTP redirects. In the case of a failure, the UA MAY repeat the request. In this case exponential backoff MUST be applied. Since the list of root certifcates is not a subject for frequent updates, under normal conditions, the UA SHOULD NOT request the Overlay Configuration more often than once per day. Usage of 'If-Modified-Since' is RECOMMENDED (RFC 7232 RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests <http://tools.ietf.org/html/rfc7232>.).

Further versions of this specification MAY extend the Overlay Configuration with new XML elements.

An XMPP entity MAY want to publish its certificate so other XMPP entities MAY retrieve it. The method to accomplish this depends on the usage:

None required.

None required.

TBD.

None required.

None required.

None required.