%ents; ]>
SSL/TLS Integration NOTE WELL: this JEP was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information. &LEGALNOTICE; 0035 Retracted Standards Track Standards None None XMPP Core N/A Robert Norris rob@cataclysm.cx rob@cataclysm.cx 0.2 2003-11-05 psa The status of this JEP has been changed to Retracted since it has been superseded by &xmppcore;. This JEP will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations. 0.1 2002-06-14 rn Initial version.

The TLS protocol RFC 2246 (formerly known as SSL) provides a way to secure an application protocol from tampering and eavesdropping. The option of using such security is desirable for Jabber due to common connection eavesdropping and hijacking attacks. See RFC 1704, "On Internet Authentication."This paragraph adapted from RFC 2595, section 1.

Traditionally, Jabber servers has supported TLS by utilising a "wrapper" around the standard protocol stream. This wrapper usually listens on a port other than those listed in the IANA registry The Internet Assigned Numbers Authority defines jabber-client (port 5222) and jabber-server (port 5269) as the standard Jabber ports; see http://www.iana.org/assignments/port-numbers. (commonly 5223 for client-to-server communications and 5270 for server-to-server communications). In the case of client-to-server communications, clients must initiate a TLS session immediately after connecting, before beginning the normal XML stream. This method of utilising TLS is typical of many servers that implement stream-based protocols, but has a number of flaws, which are outlined in section 7 of RFC 2595. Accordingly, the use of port 5223 and port 5270 for secure sessions is deprecated.

This document describes an extension to the Jabber XML stream that provides a "STARTTLS" command which clients may invoke on an insecure stream to secure it. This extension is modelled on RFC 2595, which describes the STARTTLS extension for the IMAP RFC 2060, POP3 RFC 1939 and ACAP RFC 2244 protocols. A future document (or an addition to this document) will define TLS support within server-to-server streams.

This protocol operates over the standard Jabber client connection on port 5222.

The namespace identifier for this protocol is http://www.ietf.org/rfc/rfc2595.txt.

The following examples show the dialogue between a client [C] and a server [S].

The client begins by requesting the use of STARTTLS as part of the normal Jabber stream negotiation. The server responds by informing the client whether or not it supports STARTTLS. It does this in the normal stream negotiation response:

C: <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' xmlns:tls='http://www.ietf.org/rfc/rfc2595.txt' to='jabber.org'> S: <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' xmlns:tls='http://www.ietf.org/rfc/rfc2595.txt' id='12345678'>

In the event that a server does not support the STARTTLS extension, it will respond with the normal stream negotiation response:

C: <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' xmlns:tls='http://www.ietf.org/rfc/rfc2595.txt' to='jabber.org'> S: <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='12345678'>

To begin the TLS negotiation, the client issues the STARTTLS command:

C: <tls:starttls/>

When the server is ready to begin the TLS negotiation, it will close the XML stream, but will keep the underlying connection to the client open:

S: </stream:stream>

The client now begins a normal TLS negotiation by sending the TLS ClientHello command. Upon completion of the TLS negotiation, the client reissues the XML stream initialization:

C: <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='jabber.org'> S: <stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='12345678'>

This is necessary, since any information about the stream presented by the server or the client may have been modified by an attacker.

Note that once the secure channel has been established, the server must not advertise or allow the use of the STARTTLS command.

TLS allows clients to be authenticated by verifying the certificate that they present during the TLS negotiation. This can be done in conjunction with the Jabber SASL profile JEP-0034 and the EXTERNAL mechanism.

If a client authenticates with a certificate using the TLS authentication, and the client requests the use of SASL in the second XML stream negotiation (over the secure channel), servers supporting certificate-based authentication should add the EXTERNAL mechanism to the list of supported authentication mechanisms. If the client then requests this mechanism, the server should automatically inform the user that authentication was successful. See RFC 2222 and JEP-0034 for more information.

Servers implementing STARTTLS functionality are not required to implement certificate-based authentication.