One document matched: draft-saintandre-strint-workshop-xmpp-02.xml

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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc compact="yes"?>
<?rfc iprnotified="no" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>

<rfc category="std" docName="draft-saintandre-strint-workshop-xmpp-02" ipr="trust200902">

  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <front>
    <title abbrev="STRINT XMPP">STRINT Workshop Position Paper: Strengthening the Extensible Messaging and Presence Protocol (XMPP)</title>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization>&yet</organization>
      <address>
        <email>ietf@stpeter.im</email>
      </address>
    </author>
    <author initials="T. P." surname="Alkemade" fullname="Thijs Alkemade">
      <address>
        <email>me@thijsalkema.de</email>
      </address>
    </author>
    <date/>
    <abstract>
      <t>This document describes existing and potential future efforts at strengthening the Extensible Messaging and Presence Protocol (XMPP), for discussion at the W3C/IAB workshop on Strengthening the Internet Against Pervasive Monitoring (STRINT).</t>
    </abstract>
  </front>

  <middle>

    <section title="Introduction" anchor='intro'>
      <t>The Extensible Messaging and Presence Protocol (XMPP) <xref target='RFC6120'/> (along with its precursor, the so-called "Jabber protocol") has been used since 1999 for instant messaging(IM), presence, and other forms of near-real-time communication.</t>
      <t>XMPP has a distributed client-server architecture, with one hop from a client to a server and one hop between any two servers, for a total of at most three hops on the communication path from a given client to another client.  Although XMPP has supported per-hop channel encryption using Transport Layer Security (TLS) <xref target='RFC5246'/> since 2004 through a STARTTLS upgrade mechanism on the standard XMPP ports (with a hardcoded TLS-only port for the client-to-server hop since 1999), in practice TLS has not been universally deployed for operational reasons.  In the last few months, operators of XMPP services have been working to deploy TLS more widely, and those efforts are summarized in this document.</t>
      <t>Given the client-server architecture of XMPP, per-hop encryption using TLS does not protect messages inside the application servers that are used for routing.  Therefore, various efforts have been made to provide end-to-end object encryption for the payloads of XMPP "stanzas".  To put it mildly, these efforts have been less than completely successful.  This document also summarizes the state of end-to-end encryption for XMPP.</t>
    </section>

    <section title="Terminology" anchor="terms">
      <t>Various security-related terms are to be understood in the sense defined in <xref target="RFC4949"/>.</t>
    </section>

    <section title="Per-Hop Encryption" anchor="perhop">
      <t>As mentioned, XMPP includes the ability to protect each hop in a communication path using Transport Layer Security (TLS). Although per-hop encryption does not protect XMPP payloads from attacks against XMPP servers (since absent end-to-end encryption the payloads would still be cleartext within the servers), it does protect against eavesdropping on the relevant XML streams.  Because eavesdropping on unprotected XML streams would reveal personally identifying information such as a user's contact list (which in XMPP is stored on the server) and the intended recipients of a user's messages, protecting all the hops in a communication path is critically important for maintaining the privacy and security of XMPP-based interactions.</t>
      <t>Until recently, client-to-server streams were widely protected on the XMPP network, but server-to-server streams were not. This state of affairs has had many causes:</t>
      <t>
        <list style='symbols'>
          <t>The lack of TLS protection was not as visible to end users or server administrators.</t>
          <t>Several major XMPP services did not offer or negotiate TLS over server-to-server streams.</t>
          <t>Deployment of proper certificates for authenticated encryption is operationally impossible in multi-tenanted environments.</t>
        </list>
      </t>
      <t>The last item deserves some explanation. Many instant messaging clients "hardcode" the connection hosts for multi-tenanted domains. For example, if the XMPP service for example.com is serviced by hosting.example.net (and example.net is a large enough service provider), many IM clients will provide a "wizard" interface that enables the end user to choose "example.net" as a service type or provider when configuring an account. As a result, the client software will hide the security details of the connection to example.com and override identity mismatches of the kind otherwise forbidden by the security considerations of the core XMPP specification <xref target='RFC6120'/> and the "CertID" specification <xref target='RFC6125'/>.  However, because these overrides are not applied on server-to-server streams, many existing implementations and deployments do not even attempt TLS negotiation for server-to-server streams.</t>
      <t>Although a technology like DANE/DNSSEC (see <xref target='I-D.ietf-dane-srv'/>) or POSH/HTTPS (see <xref target='I-D.ietf-xmpp-posh'/> and <xref target='I-D.ietf-xmpp-dna'/>) would provide means to overcome the operational limitations of authenticated encryption, neither is yet widely deployed. Thus, in practice, when server-to-server streams are being protected often the technology used is unauthenticated encryption via TLS and the XMPP Server Dialback extension <xref target='XEP-0220'/>.</t>
      <t>In late 2013, a number of service operators in the XMPP community committed to mandating encryption on all hops under their control, and a number of software developers committed to supporting the features needed to make such encryption possible. The goal is to enable such encryption permanently on May 19, 2014. So far, one test day has been held (on January 4, 2014) and another test day will be held (on February 22, 2014) before the date of the STRINT workshop. The test day revealed bugs in several XMPP software implementations and prompted security improvements at a number of deployed services.</t>
      <t>Also helpful has been the "IM Observatory" site at <eref target='https://xmpp.net/'/>.  Most IM clients allow end users to inspect their connection to determine whether it is encrypted or not.  However, users cannot easily determine the status of the other hops on the path to a user on a different server.  Thus the IM Observatory has multiple goals: to give end users a tool with which they can examine the security of the entire end-to-end path, to give service operators information about improvements they can make to their servers' security, and to give all XMPP developers helpful statistics about the entire network.</t>
    </section>

    <section title="End-to-End Encryption" anchor="e2e">
      <t>The XMPP community has experimented with a significant number of end-to-end encryption technologies, including OpenPGP <xref target='XEP-0027'/>, S/MIME <xref target='RFC3923'/>, SIGMA <xref target='XEP-0116'/>, end-to-end TLS <xref target='I-D.meyer-xmpp-e2e-encryption'/>, XML encryption (never publicly documented), CMS with JOSE formats <xref target='I-D.miller-xmpp-e2e'/>, and Off-the-Record (OTR) Messaging <eref target='https://otr.cypherpunks.ca/'/>.  Unfortunately, none of these technologies has been formalized through a standards development organization.  However OTR is the most widely implemented.</t>
    </section>

    <section title="IANA Considerations" anchor="iana">
      <t>This document requests no actions of the IANA.</t>
    </section>

    <section title="Security Considerations" anchor="security">
      <t>This entire document discusses security.</t>
    </section>

  </middle>

  <back>

    <references title="Normative References">

<reference anchor='RFC4949'>
<front>
<title>Internet Security Glossary, Version 2</title>
<author initials='R.' surname='Shirey' fullname='R. Shirey'>
<organization /></author>
<date year='2007' month='August' />
<abstract>
<t>This Glossary provides definitions, abbreviations, and explanations of terminology for information system security.  The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process (RFC 2026).  The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed.  This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='4949' />
<format type='TXT' octets='867626' target='http://www.rfc-editor.org/rfc/rfc4949.txt' />
</reference>

<reference anchor='RFC5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'>
<organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2008' month='August' />
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5246' />
<format type='TXT' octets='222395' target='http://www.rfc-editor.org/rfc/rfc5246.txt' />
</reference>

<reference anchor='RFC6120'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities.  This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions.  This document obsoletes RFC 3920. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6120' />
<format type='TXT' octets='451942' target='http://www.rfc-editor.org/rfc/rfc6120.txt' />
</reference>

<reference anchor='RFC6125'>
<front>
<title>Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<author initials='J.' surname='Hodges' fullname='J. Hodges'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS).  This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6125' />
<format type='TXT' octets='136507' target='http://www.rfc-editor.org/rfc/rfc6125.txt' />
</reference>

    </references>

    <references title="Informative References">

<reference anchor='I-D.ietf-dane-srv'>
<front>
<title>Using DNS-Based Authentication of Named Entities (DANE) TLSA records with SRV and MX records.</title>
<author initials='T' surname='Finch' fullname='Tony Finch'>
    <organization />
</author>
<author initials='M' surname='Miller' fullname='Matthew Miller'>
    <organization />
</author>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
    <organization />
</author>
<date month='February' day='11' year='2014' />
<abstract><t> The DANE specification (RFC 6698) describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate.  The association is secured with DNSSEC.  Some application protocols use SRV records (RFC 2782) to indirectly name the server hosts for a service domain (SMTP uses MX records for the same purpose).  This specification gives generic instructions for how these application protocols locate and use TLSA records when technologies such as SRV records are used.  Separate documents give the details that are specific to particular application protocols.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dane-srv-04' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-dane-srv-04.txt' />
</reference>

<reference anchor='I-D.ietf-xmpp-dna'>
<front>
<title>Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
    <organization />
</author>
<author initials='M' surname='Miller' fullname='Matthew Miller'>
    <organization />
</author>
<date month='February' day='4' year='2014' />
<abstract><t>This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways.  First, it specifies how "prooftypes" can establish a strong association between a domain name and an XML stream.  Second, it describes how to securely delegate a source domain to a derived domain, which is especially important in virtual hosting environments.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-xmpp-dna-05' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-xmpp-dna-05.txt' />
</reference>

<reference anchor='I-D.meyer-xmpp-e2e-encryption'>
<front>
<title>XTLS: End-to-End Encryption for the Extensible Messaging and Presence Protocol (XMPP) Using Transport Layer Security (TLS)</title>

<author initials='D' surname='Meyer' fullname='Dirk Meyer'>
    <organization />
</author>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
    <organization />
</author>
<date month='June' day='29' year='2009' />
<abstract><t>This document specifies "XTLS", a protocol for end-to-end encryption of Extensible Messaging and Presence Protocol (XMPP) traffic.  XTLS is an application-level usage of Transport Layer Security (TLS) that is set up using the XMPP Jingle extension for session negotiation and transported using any streaming transport as the data delivery mechanism.  Thus XTLS treats the end-to-end exchange of XML stanzas as a virtual transport and uses TLS to secure that transport, enabling XMPP entities to communicate in a way that is designed to ensure the confidentiality and integrity XML stanzas.  The protocol can be used for secure end-to-end messaging as well as other XMPP applications, such as file transfer.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-meyer-xmpp-e2e-encryption-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-meyer-xmpp-e2e-encryption-02.txt' />
</reference>

<reference anchor='I-D.ietf-xmpp-posh'>
<front>
<title>PKIX over Secure HTTP (POSH)</title>
<author initials='M' surname='Miller' fullname='Matthew Miller'>
    <organization />
</author>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
    <organization />
</author>
<date month='February' day='4' year='2014' />
<abstract><t>Experience has shown that it is extremely difficult to deploy proper PKIX certificates for TLS in multi-tenanted environments, since certification authorities will not issue certificates for hosted domains to hosting services, hosted domains do not want hosting services to hold their private keys, and hosting services wish to avoid liability for holding those keys.  As a result, domains hosted in multi-tenanted environments often deploy non-HTTP applications such as email and instant messaging using certificates that identify the hosting service, not the hosted domain.  Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in obvious security implications.  This document defines two methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols.  The first method enables the TLS client associated with a user agent or peer application server to obtain the end-entity certificate of a hosted domain over secure HTTP as an alternative to standard PKIX techniques.  The second method enables a hosted domain to securely delegate a non-HTTP application to a hosting service using redirects provided by HTTPS itself or by a pointer in a file served over HTTPS at the hosted domain.  While this approach is developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association prooftype, it can be applied to any non-HTTP application protocol.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-xmpp-posh-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-xmpp-posh-00.txt' />
</reference>

<reference anchor='I-D.miller-xmpp-e2e'>
<front>
<title>End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials='M' surname='Miller' fullname='Matthew Miller'>
    <organization />
</author>
<date month='June' day='13' year='2013' />
<abstract><t>This document defines two methods for securing objects (often referred to as stanzas) for the Extensible Messaging and Presence Protocol (XMPP), which allows for efficient asynchronous communication between two entities, each with might have multiple devices operating simultaneously.  One is a method to encrypt stanzas to provide confidentiality protection; another is a method to sign stanzas to provide authentication and integrity protection.  This document also defines a related protocol for entities to request the ephemeral session keys in use.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-miller-xmpp-e2e-06' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-miller-xmpp-e2e-06.txt' />
</reference>

<reference anchor='RFC3923'>
<front>
<title abbrev='XMPP E2E'>End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials='P.' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization>Jabber Software Foundation</organization>
<address>
<email>stpeter@jabber.org</email></address></author>
<date year='2004' month='October' />
<area>Applications</area>
<workgroup>XMPP Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XMPP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<keyword>IM</keyword>
<keyword>Instant Messaging</keyword>
<keyword>Presence</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP).</t></abstract></front>
<seriesInfo name='RFC' value='3923' />
<format type='TXT' octets='51828' target='http://www.rfc-editor.org/rfc/rfc3923.txt' />
<format type='HTML' octets='90605' target='http://xml.resource.org/public/rfc/html/rfc3923.html' />
<format type='XML' octets='72015' target='http://xml.resource.org/public/rfc/xml/rfc3923.xml' />
</reference>

<reference anchor="XEP-0027">
  <front>
    <title>Current Jabber OpenPGP Usage</title>
    <author initials="T." surname="Muldowney" fullname="Thomas Muldowney">
      <organization/>
      <address>
        <email>temas@jabber.org</email>
      </address>
    </author>
    <date day="29" month="November" year="2006"/>
  </front>
  <seriesInfo name="XSF XEP" value="0027"/>
  <format type="HTML" target="http://xmpp.org/extensions/xep-0027.html"/>
</reference>

<reference anchor="XEP-0116">
  <front>
    <title>Encrypted Session Negotiation</title>
    <author initials="I." surname="Paterson" fullname="Ian Paterson">
      <organization/>
      <address>
        <email>ian.paterson@clientside.co.uk</email>
      </address>
    </author>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
      <address>
        <email>stpeter@jabber.org</email>
      </address>
    </author>
    <author initials="D." surname="Smith" fullname="Dave Smith">
      <organization/>
      <address>
        <email>dizzyd@jabber.org</email>
      </address>
    </author>
    <date day="30" month="May" year="2007"/>
  </front>
  <seriesInfo name="XSF XEP" value="0116"/>
  <format type="HTML" target="http://xmpp.org/extensions/xep-0116.html"/>
</reference>

<reference anchor="XEP-0220">
  <front>
    <title>Server Dialback</title>
    <author initials="J." surname="Miller" fullname="Jeremie Miller">
      <organization/>
      <address>
        <email>jer@jabber.org</email>
      </address>
    </author>
    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization/>
      <address>
        <email>stpeter@jabber.org</email>
      </address>
    </author>
    <author initials="P." surname="Hancke" fullname="Philipp Hancke">
      <organization/>
      <address>
        <email/>
      </address>
    </author>
    <date day="27" month="September" year="2013"/>
  </front>
  <seriesInfo name="XSF XEP" value="0220"/>
  <format type="HTML" target="http://xmpp.org/extensions/xep-0220.html"/>
</reference>

    </references>

  </back>

</rfc>