XEP-xxxx: XMPP Transport Layer Security

This document specifies the XMPP Transport Layer Security (XTLS) protocol. XTLS, which provides communications privacy for the Extensible Messaging and Presence Protocol (XMPP), enables XMPP applications to communicate in a way that is designed to prevent eavesdropping, tampering, and forgery of XML stanzas. XTLS is based on Transport Layer Security (TLS) and provides equivalent security guarantees. The protocol sends standard TLS handshake data via the existing XMPP extension for In-Band Bytestreams (IBB).

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document must not be referred to as an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://www.xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.

Document Information

Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: Standards Track
Version: 0.0.6
Last Updated: 2008-06-06
Approving Body: XMPP Council
Dependencies: XMPP Core, RFC 4346, XEP-0047
Supersedes: None
Superseded By: None
Short Name: NOT_YET_ASSIGNED

Author Information

Dirk Meyer

Email: dmeyer@tzi.de
JabberID: dmeyer@jabber.org

Peter Saint-Andre

JabberID: stpeter@jabber.org
URI: https://stpeter.im/

Justin Karneges

Email: justin@affinix.com
JabberID: justin@andbit.net

Legal Notices

Copyright

This XMPP Extension Protocol is copyright (c) 1999 - 2008 by the XMPP Standards Foundation (XSF).

Permissions

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.

Disclaimer of Warranty

## 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 shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##

Limitation of Liability

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 out of the use or inability to use 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.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

Discussion Venue

The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.

Given that this XMPP Extension Protocol normatively references IETF technologies, discussion on the XSF-IETF list may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/jsf-ietf> for details).

Errata may be sent to <editor@xmpp.org>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Table of Contents


1. Introduction
2. Requirements
3. Protocol
    3.1. Agreeing to Use XTLS
    3.2. Creating an XTLS Bytestream
    3.3. TLS Handshake
    3.4. Sending Encrypted Stanzas
    3.5. Closing the XTLS Bytestream
4. Requirements Analysis
5. Determining Support
6. Security Considerations
    6.1. Mandatory-to-Implement Technologies
    6.2. Certificates
    6.3. Denial of Service
7. IANA Considerations
8. XMPP Registrar Considerations
    8.1. Protocol Namespaces
9. XML Schema
10. Acknowledgements
Notes
Revision History

1. Introduction

End-to-end encryption of traffic sent over the Extensible Messaging and Presence Protocol (XMPP) is a desirable goal. The Jabber/XMPP developer community has experimented with several such technologies, including OpenPGP (Current Jabber OpenPGP Usage [1]), S/MIME (RFC 3923 [2]), and encrypted sessions or "ESessions" (Bootstrapping Implementation of Encrypted Sessions [3]). For various reasons, these technologies have not been widely implemented and deployed. When the XMPP Standards Foundation (XSF) [4] asked various Internet security experts to complete a security review of encrypted sessions, it was recommended to explore the possibility of instead using the Transport Layer Security (TLS; see RFC 4346 [5]) as the base technology for XMPP. That possibility is explored in this document.

TLS is the most widely implemented protocol for securing network traffic. In addition to applications in the email infrastructure, the World Wide Web (HTTP Over TLS; see RFC 2818 [6]), and datagram transport for multimedia session negotiation (DTLS; see RFC 4347 [7]), TLS is used in XMPP to secure TCP connections from client to server and from server to server, as specified in XMPP Core [8]. Therefore TLS is already a familiar technology for many XMPP developers.

The basic idea behind XTLS is that two XMPP entities negotiate an encrypted "tunnel" between themselves over XMPP. The tunnel is negotiated using standard TLS handshake data, encapsulated in In-Band Bytestreams [9]. The entities can then exchange TLS-encrypted XMPP stanzas over that tunnel.

XTLS is not limited to client-to-client encryption, since it can be used between two XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream, such as a Multi-User Chat [10] chatroom), or between two remote XMPP services.

2. Requirements

It is intended that this specification will address the requirements specified in Requirements for Encrypted Sessions [11], or some reasonable subset thereof (yet to be defined). However, there is no guarantee that this specification addresses those requirements in its current form. Detailed analysis will need to be performed in order to determine whether XTLS meets the full requirements for end-to-end encryption of XMPP communications.

3. Protocol

3.1 Agreeing to Use XTLS

To start the use of XTLS, the initiator sends an IQ-set containing an empty <xtls/> element qualified by the 'urn:xmpp:tmp:xtls' namespace (see Protocol Namespaces regarding issuance of one or more permanent namespaces) and possessing a 'sid' attribute that specifies a unique Session ID for the XTLS session.

Example 1. Initiating XTLS

<iq from='romeo@montague.net/orchard'
    id='xtls_1'
    to='juliet@capulet.com/balcony'
    type='set'>
  <xtls xmlns='urn:xmpp:tmp:xtls'
        sid='MySid'/>
</iq>

Note: It is not possible to initiate XTLS by sending the <xtls/> element as a child of the IBB <open/> element, because XMPP Core [12] specifies that child elements qualified by unknown namespaces shall be ignored. Sending an initial IQ-set before beginning the IBB negotiation adds a round trip to the protocol flow, but this is preferable to beginning XTLS negotiation with entities that do not in fact support the protocol. Naturally, support SHOULD be determined ahead of time as described under Determining Support, but it is possible that such data could be corrupted or intercepted.

If the responder supports XTLS and agrees to start the use of XTLS, it returns an empty IQ-result.

Example 2. Responder Agrees to Use XTLS

<iq from='juliet@capulet.com/balcony'
    id='xtls_1'
    to='romeo@montague.net/orchard'
    type='result'/>

If the responder does not support XTLS, in accordance with core XMPP semantics it MUST return a <service-unavailable/> error.

Example 3. Responder Does Not Support XTLS

<iq from='juliet@capulet.com/balcony'
    id='xtls_1'
    to='romeo@montague.net/orchard'
    type='error'>
  <error type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

If the responder supports XTLS but does not wish to proceed with the use of XTLS, it MUST return a <not-acceptable/> error.

Example 4. Responder Does Not Wish to Use XTLS

<iq from='juliet@capulet.com/balcony'
    id='xtls_1'
    to='romeo@montague.net/orchard'
    type='error'>
  <error type='cancel'>
    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

It is possible that both parties may attempt to start the use of XTLS at the same time [13], in which case one party may receive an XTLS start stanza from the other party after it has sent such an XTLS start stanza but before receiving a response. In this case, one of the initiation requests shall be considered to have higher priority than the other, and the party that receives the lower priority initiation request shall return a <conflict/> stanza error in response to the lower priority request. The higher priority request MUST be considered the request that is generated by the party whose JID is sorted before the other party when the JIDs of both parties are sorted using "i;octet" collation as specified in Section 9.3 of RFC 4790 [14].

In this example, juliet@capulet.com/balcony is sorted before romeo@montague.net/orchard and therefore her XTLS start stanza has a higher priority. Therefore she would return a conflict error to Romeo if they both send an XTLS start stanza at the same time.

Example 5. Higher Priority Party Returns Conflict Error

<iq from='juliet@capulet.com/balcony'
    id='xtls_1'
    to='romeo@montague.net/orchard'
    type='error'>
  <error type='cancel'>
    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

3.2 Creating an XTLS Bytestream

If the responder indicates that it agrees to use XTLS, the initiator sends a request to open an in-band bytestream, as described in XEP-0047. The 'sid' attribute of the IBB <open/> element MUST match that provided on the <xtls/> element.

Example 6. Opening the XTLS bytestream

<iq from='romeo@montague.net/orchard'
    id='xtls_2'
    to='juliet@capulet.com/balcony'
    type='set'>
  <open xmlns='http://jabber.org/protocol/ibb'
        block-size='4096'
        sid='MySid'/>
</iq>

If the responder supports IBB, it responds with an empty result, in accordance with XEP-0047

Example 7. IBB Success Response

<iq from='juliet@capulet.com/balcony'
    id='xtls_2'
    to='romeo@montague.net/orchard'
    type='result'/>

If the responder does not support IBB, it responds with an <service-unavailable/> error.

Example 8. Responder Does Not Support IBB

<iq from='juliet@capulet.com/balcony'
    id='xtls_2'
    to='romeo@montague.net/orchard'
    type='error'/>
  <error type='cancel'>
    <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

3.3 TLS Handshake

Before sending encrypted data, the parties MUST perform a TLS handshake over the in-band bytestream. The TLS library in use handles the in-band bytestream like a normal stream and performs the handhake over the bytestream. During the handshake, the entity acting as the TLS server SHOULD send a CertificateRequest, since mutual authentication is desired.

Note: It is possible that IBB stanzas will not respect TLS message boundaries; therefore the number of IBB messages depends on the TLS implementation.

Example 9. TLS Handshake (1)

<iq from='romeo@montague.lit/orchard'
    id='xtls_3'
    to='juliet@capulet.lit/chamber'
    type='set'>
  <data xmlns='http://jabber.org/protocol/ibb' sid='MySid' seq='0'>
    base_64(TLS-Handshake-Messages)
  </data>
</iq>

The receiver than acknowledges the IBB message and, if the stream contains the complete ClientHello message, it continues with the TLS handshake. Otherwise it will wait for more messages from the initiator.

Example 10. TLS Handshake (2)

<iq from='juliet@capulet.lit/chamber'
    id='xtls_3'
    to='romeo@montague.lit/orchard'
    type='result'/>

<iq from='juliet@capulet.lit/chamber'
    id='xtls_4'
    to='romeo@montague.lit/orchard'
    type='set'>
  <data xmlns='http://jabber.org/protocol/ibb' sid='MySid' seq='0'>
    base_64(TLS-Server-Handshake-Messages)
  </data>
</iq>

3.4 Sending Encrypted Stanzas

After the TLS handshake has been completed, the parties exchange encrypted data over the bytestream. Because the routing information is already present in the IQ stanzas used by IBB, the stanzas encapsulated in the XTLS stream MAY exclude the routing information (i.e., the 'from' and 'to' attributes). In that case, the responder MUST supply the 'from' and 'to' addresses of the IQ stanza that contains the encrypted data.

Example 11. A Stanza to Send

<message 
    from='romeo@montague.lit/orchard'
    to='juliet@capulet.lit//chamber'
    type='chat'>
  <thread>act2scene2chat1</thread>
  <body>
    I take thee at thy word:
    Call me but love, and I'll be new baptized;
    Henceforth I never will be Romeo.
  </body>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>

The sender's client would strip off the routing information.

Example 12. A Stanza to Send (No Routing)

<message type='chat'>
  <thread>act2scene2chat1</thread>
  <body>
    I take thee at thy word:
    Call me but love, and I'll be new baptized;
    Henceforth I never will be Romeo.
  </body>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>

This message is then encrypted and sent in one or more stanzas over the in-band bytestream.

Example 13. Sender Generates In-Band Bytestream Data

<iq from='romeo@montague.lit/orchard'
    id='xtls_3'
    to='juliet@capulet.lit/chamber'
    type='set'>
  <data xmlns='http://jabber.org/protocol/ibb' sid='MySid' seq='5'>
    base_64(TLS-Encrypted-Message)
  </data>
</iq>

3.5 Closing the XTLS Bytestream

The in-band bytestream can be closed according to XEP-0047. However, it is RECOMMENDED that the stream shall be kept open until one entity leaves the XMPP network if the entities have mutual presence subscription. Keeping the XTLS tunnel open does not require much resources and will prevent a new TLS handshake.

4. Requirements Analysis

As mentioned, XTLS is intended to address the requirements specified in XEP-0210 (or a reasonable subset thereof). This section compares XTLS against the requirements and points out gaps that may need to be filled with changes to XTLS or to TLS itself.

  1. Confidentiality means that an XMPP stanza cannot be understood by a third party that might intercept the stanza.
  2. Offline Sessions are not supported because In-Band Bytestreams uses either message stanzas (which should not be spooled on the server) or IQ stanzas (which are not stored offline).

5. Determining Support

If an entity wishes to request the use of XTLS, it SHOULD first determine whether the intended responder supports the protocol. This can be done directly via Service Discovery [15] or indirectly via Entity Capabilities [16].

If an entity supports XTLS, it MUST report that by including a service discovery feature of "urn:xmpp:tmp:xtls" in response to disco#info requests (see Protocol Namespaces regarding issuance of one or more permanent namespaces).

Example 14. Initial Service Discovery Information Request

<iq from='romeo@montague.lit/orchard'
    id='disco1'
    to='juliet@capulet.lit/chamber'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

Example 15. Service Discovery Information Response

<iq from='juliet@capulet.lit/chamber'
    id='disco1'
    to='romeo@montague.lit/orchard'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='urn:xmpp:tmp:xtls'/>
    ...
  </query>
</iq>

Both service discovery and entity capabilities information could be corrupted or intercepted; for details, see the Denial of Service section of this document.

6. Security Considerations

This entire document addresses security. Particular security-related issues are discussed in the following sections.

6.1 Mandatory-to-Implement Technologies

An implementation MUST at a minimum support the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher. An implementation MAY support other ciphers as well.

6.2 Certificates

As noted, XTLS can be used between XMPP clients, between an XMPP client and a remote XMPP service (i.e., a service with which a client does not have a direct XML stream), or between remote XMPP services. Therefore, a party to an XTLS bytestream will present either a client certificate or a server certificate as appropriate. Such certificates MUST be generated and validated in accordance with the certificate guidelines guidelines provided in rfc3920bis [17].

A future version of this specification may provide additional guidelines regarding certificate validation in the context of client-to-client encryption.

6.3 Denial of Service

The XTLS start stanzas and IBB initiation stanzas are not encrypted or signed; the same is true of service discovery exchanges and entity capabilities data. Therefore it is possible for an attacker to intercept these stanzas and modify them (e.g., by spuriously returning a <service-unavailable/> error), thus convincing the initiator that the responder does not support XTLS and therefore denying the parties an opportunity to use XTLS.

A future version of this specification may address this problem.

7. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [18].

8. XMPP Registrar Considerations

8.1 Protocol Namespaces

Until this specification advances to a status of Draft, its associated namespace shall be "urn:xmpp:tmp:xtls"; upon advancement of this specification, the XMPP Registrar [19] shall issue a permanent namespace in accordance with the process defined in Section 4 of XMPP Registrar Function [20]. The namespace "urn:xmpp:xtls" is requested and is thought to be unique per the XMPP Registrar's requirements.

9. XML Schema

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:xmpp:tmp:xtls'
    xmlns='urn:xmpp:tmp:xtls'
    elementFormDefault='qualified'>

  <xs:element name='xtls'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='sid' type='xs:string' use='required'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>

10. Acknowledgements

The authors wish to thank Eric Rescorla for initial suggestions regarding the use of TLS for application-layer encryption in XMPP. Thanks also to Jakob Schröter for early implementation feedback.

Notes

1. XEP-0027: Current Jabber OpenPGP Usage <http://www.xmpp.org/extensions/xep-0027.html>.

2. RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) <http://tools.ietf.org/html/rfc3923>.

3. XEP-0218: Bootstrapping Implementation of Encrypted Sessions <http://www.xmpp.org/extensions/xep-0218.html>.

4. The XMPP Standards Foundation (XSF) is an independent, non-profit membership organization that develops open extensions to the IETF's Extensible Messaging and Presence Protocol (XMPP). For further information, see <http://www.xmpp.org/xsf/>.

5. RFC 4346: The Transport Layer Security (TLS) Protocol Version 1.1 <http://tools.ietf.org/html/rfc4346>.

6. RFC 2818: HTTP Over TLS <http://tools.ietf.org/html/rfc2818>.

7. RFC 4347: Datagram Transport Layer Security <http://tools.ietf.org/html/rfc4347>.

8. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.

9. XEP-0047: In-Band Bytestreams <http://www.xmpp.org/extensions/xep-0047.html>.

10. XEP-0045: Multi-User Chat <http://www.xmpp.org/extensions/xep-0045.html>.

11. XEP-0210: Requirements for Encrypted Sessions <http://www.xmpp.org/extensions/xep-0210.html>.

12. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.

13. For example, the applications might automatically open an XTLS tunnel based on presence information.

14. RFC 4790: Internet Application Protocol Collation Registry <http://tools.ietf.org/html/rfc4790>.

15. XEP-0030: Service Discovery <http://www.xmpp.org/extensions/xep-0030.html>.

16. XEP-0115: Entity Capabilities <http://www.xmpp.org/extensions/xep-0115.html>.

17. rfc3920bis: proposed revisions to Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/draft-saintandre-rfc3920bis>. (work in progress)

18. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

19. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://www.xmpp.org/registrar/>.

20. XEP-0053: XMPP Registrar Function <http://www.xmpp.org/extensions/xep-0053.html>.

Revision History

Version 0.0.6 (2008-06-06)

Added sid to <xtls/> element.

(dm/psa)

Version 0.0.5 (2008-06-06)

(psa)

Version 0.0.4 (2008-06-06)

(dm)

Version 0.0.3 (2008-06-05)

Modified to use In-Band Bytestreams as the transport.

(dm/jk)

Version 0.0.2 (2008-06-05)

(dm/jk)

Version 0.0.1 (2007-10-30)

First draft, based on suggestions from Eric Rescorla.

(psa)

END