xeps/xep-0035.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>

<xep>

<header>
  <title>SSL/TLS Integration</title>
  <abstract>NOTE WELL: this specification was retracted on 2003-11-05 since the topic is addressed definitively in XMPP Core. Please refer to XMPP Core for further information.</abstract>
  &LEGALNOTICE;
  <number>0035</number>
  <status>Retracted</status>
  <type>Standards Track</type>
  <jig>Standards</jig>
  <dependencies>None</dependencies>
  <supersedes>None</supersedes>
  <supersededby>XMPP Core</supersededby>
  <shortname>N/A</shortname>
  <author>
    <firstname>Robert</firstname>
    <surname>Norris</surname>
    <email>rob@cataclysm.cx</email>
    <jid>rob@cataclysm.cx</jid>
  </author>
  <revision>
    <version>0.2</version>
    <date>2003-11-05</date>
    <initials>psa</initials>
    <remark>The status of this specification has been changed to Retracted since it has been superseded by &xmppcore;. This document will not be considered further by the Jabber Software Foundation and should not be used as a basis for implementations.</remark>
  </revision>
  <revision>
    <version>0.1</version>
    <date>2002-06-14</date>
    <initials>rn</initials>
    <remark>Initial version.</remark>
  </revision>
</header>

<section1 topic='Introduction'>
  <p>The TLS protocol <note><link url="http://www.ietf.org/rfc/rfc2246.txt">RFC 2246</link></note> (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. <note>See <link url="http://www.ietf.org/rfc/rfc1704.txt">RFC 1704</link>, "On Internet Authentication."</note><note>This paragraph adapted from <link url="http://www.ietf.org/rfc/rfc2595.txt">RFC 2595</link>, section 1.</note></p>

  <p>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 <note>The Internet Assigned Numbers Authority defines jabber-client (port 5222) and jabber-server (port 5269) as the standard Jabber ports; see <link url='http://www.iana.org/assignments/port-numbers'>http://www.iana.org/assignments/port-numbers</link>.</note> (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 <link url="http://www.ietf.org/rfc/rfc2595.txt">RFC 2595</link>. Accordingly, the use of port 5223 and port 5270 for secure sessions is deprecated.</p>

  <p>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 <link url="http://www.ietf.org/rfc/rfc2595.txt">RFC 2595</link>, which describes the STARTTLS extension for the IMAP <note><link url="http://www.ietf.org/rfc/rfc2060">RFC 2060</link></note>, POP3 <note><link url="http://www.ietf.org/rfc/rfc1939">RFC 1939</link></note> and ACAP <note><link url="http://www.ietf.org/rfc/rfc2244">RFC 2244</link></note> protocols. A future document (or an addition to this document) will define TLS support within server-to-server streams.</p>
</section1>

<section1 topic='Protocol'>

  <section2 topic="Overview">
    <p>This protocol operates over the standard Jabber client connection on port 5222.</p>

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

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

    <p>
    </p>
  </section2>

  <section2 topic="Stream initialization">
    <p>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:</p>

    <example caption="Stream initialization">
C: &lt;stream:stream xmlns=&apos;jabber:client&apos;
                  xmlns:stream=&apos;http://etherx.jabber.org/streams&apos;
                  xmlns:tls=&apos;http://www.ietf.org/rfc/rfc2595.txt&apos;
                  to=&apos;jabber.org&apos;&gt;
S: &lt;stream:stream xmlns=&apos;jabber:client&apos;
                  xmlns:stream=&apos;http://etherx.jabber.org/streams&apos;
                  xmlns:tls=&apos;http://www.ietf.org/rfc/rfc2595.txt&apos;
                  id=&apos;12345678&apos;&gt;
    </example>

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

    <example caption="Stream initialization; server not supporting STARTTLS">
C: &lt;stream:stream xmlns=&apos;jabber:client&apos;
                  xmlns:stream=&apos;http://etherx.jabber.org/streams&apos;
                  xmlns:tls=&apos;http://www.ietf.org/rfc/rfc2595.txt&apos;
                  to=&apos;jabber.org&apos;&gt;
S: &lt;stream:stream xmlns=&apos;jabber:client&apos;
                  xmlns:stream=&apos;http://etherx.jabber.org/streams&apos;
                  id=&apos;12345678&apos;&gt;
    </example>
  </section2>

  <section2 topic="TLS negotiation">
    <p>To begin the TLS negotiation, the client issues the STARTTLS command:</p>

    <example caption="STARTTLS request">
C: &lt;tls:starttls/&gt;
    </example>

    <p>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:</p>

    <example caption="STARTTLS response">
S: &lt;/stream:stream&gt;
    </example>

    <p>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:</p>

    <example caption="Stream initialization">
C: &lt;stream:stream xmlns=&apos;jabber:client&apos;
                  xmlns:stream=&apos;http://etherx.jabber.org/streams&apos;
                  to=&apos;jabber.org&apos;&gt;
S: &lt;stream:stream xmlns=&apos;jabber:client&apos;
                  xmlns:stream=&apos;http://etherx.jabber.org/streams&apos;
                  id=&apos;12345678&apos;&gt;
    </example>

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

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

</section1>

<section1 topic="Certificate-based authentication">
  <p>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 (see &xep0034;) and the EXTERNAL mechanism.</p>

  <p>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 &rfc2222; and <cite>XEP-0034</cite> for more information.</p>
  
  <p>Servers implementing STARTTLS functionality are not required to implement certificate-based authentication.</p>
</section1>

</xep>