One document matched: draft-meyer-xmpp-e2e-encryption-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<rfc category="std" docName="draft-meyer-xmpp-e2e-encryption-00" ipr="trust200902">
<front>
<title abbrev='XTLS'>Extensible Messaging and Presence Protocol (XMPP) End-to-End Encryption Using Transport Layer Security ("XTLS")</title>
<author initials="D." surname="Meyer" fullname="Dirk Meyer">
<organization>Universitaet Bremen TZI</organization>
<address>
<email>dmeyer@tzi.de</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<email>psaintan@cisco.com</email>
</address>
</author>
<date year="2009" month="February" day="28"/>
<area>Applications</area>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>XMPP</keyword>
<keyword>Jabber</keyword>
<keyword>encryption</keyword>
<abstract>
<t>This document specifies "XTLS", a protocol for end-to-end encryption of Extensible Messaging and Presence Protocol (XMPP) traffic via an application-level usage of Transport Layer Security (TLS). XTLS treats the end-to-end exchange of XML stanzas as a virtual transport and uses TLS to secure that transport, thus enabling XMPP entities to communicate in a way that is designed to prevent eavesdropping, tampering, and forgery of XML stanzas. The protocol can be used for secure end-to-end messaging as well as any others application such as file transfer.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>End-to-end encryption of traffic sent over the Extensible Messaging and Presence Protocol (XMPP) is a desirable goal. Since 1999, the Jabber/XMPP developer community has experimented with several such technologies, including OpenPGP <xref target='XEP-0027'/>, S/MIME (<xref target='RFC3923'/>, and encrypted sessions or "ESessions" <xref target='XEP-0218'/>. For various reasons, these technologies have not been widely implemented and deployed. When the XMPP Standards Foundation 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 <xref target='TLS'/> as the base technology for XMPP. That possibility is explored in this document.</t>
<t>TLS is the most widely implemented protocol for securing network traffic. In addition to applications in the email infrastructure, the World Wide Web <xref target='HTTP-TLS'/>, and datagram transport for multimedia session negotiation <xref target='DTLS'/>, TLS is used in XMPP to secure TCP connections from client to server and from server to server, as specified in <xref target='rfc3920bis'/>. Therefore TLS is already familiar to XMPP developers.</t>
<t>This specification, called "XTLS", defines a method whereby any XMPP entity that supports the XMPP Jingle negotiation framework <xref target='XEP-0166'/> can use TLS semantics for end-to-end encryption, whether the application data is sent over a streaming transport (like TCP) or a datagram transport (like UDP). The basic use case is to tunnel XMPP stanzas between two IM users for end-to-end secure chat using end-to-end XML streams. However, XTLS is not limited to encryption of one-to-one text chat, since it can be used between two XMPP clients for encryption of any XMPP payloads, 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 <xref target='XEP-0045'/> chatroom), or between two remote XMPP services. Furthermore, XTLS can be used for encrypted file transfer using <xref target='XEP-0234'/>, for encrypted voice or video sessions using <xref target='XEP-0167'/> and <xref target='DTLS-SRTP'/>, and other applications.</t>
</section>
<section title='Requirements' anchor='req'>
<t>This specification is intended to meet the requirements defined in <xref target='XEP-0210'/> using building blocks that are already widely supported in XMPP clients, such as TLS, XML streams, Jingle, and in-band bytestreams <xref target='XEP-0047'/>. It is possible that some of those requirements can be met only with particular TLS cipher suites, or cannot be met at all without defining extensions to TLS itself. A full gap analysis has not yet been completed.</t>
</section>
<section title='Approach' anchor='approach'>
<t>In broad outline, XTLS takes the following approach to end-to-end encryption of XMPP traffic:</t>
<t>
<list style='numbers'>
<t>We assume that all XMPP entities will have X.509 certificates, typically self-signed and automatically generated by an XMPP client (although CA-issued certificates are acceptable).</t>
<t>We use the XMPP Jingle extensions as the negotiation framework.</t>
<t>We define a <security/> element that can be included in any Jingle negotiation, and a new "security-info" Jingle action for sending security-related information.</t>
<t>When an entity wishes to encrypt its communications with a second entity, it sends a Jingle session-initiate request that specifies the desired application type (e.g., file transfer), a possible transport (e.g., SOCKS5 bytestreams), and security information such as the sender's X.509 fingerprint and supported TLS methods (e.g., secure remote password).</t>
<t>If both parties support XTLS, the first data sent over the negotiated transport is TLS handshake data, not application data. Once the TLS handshake has finished, the parties can then send application data over the now-encrypted transport.</t>
<t>The simplest scenario is end-to-end encryption of traditional XMPP text chat using end-to-end XML streams, in-band bytestreams, and previously-accepted X.509 certificates.</t>
<t>On first use of end-to-end encryption between two entities, it is encouraged to use secure remote passwords rather than leap-of-faith to bootstrap the subsequent use of the client-generated X.509 certificates.</t>
<t>More complex scenarios are theoretically supported (e.g., encrypted file transfer using SOCKS5 bytestreams and encrypted voice chat using DTLS-SRTP) but have not yet been fully defined.</t>
<t>XTLS theoretically can be used to establish a TLS-encrypted streaming transport or a DTLS-encrypted datagram transport, but integration with DTLS <xref target='DTLS'/> has not yet been prototyped so use with streaming transports is the more stable scenario.</t>
</list>
</t>
<t>We expand on this approach in the following section.</t>
</section>
<section title='XTLS Protocol Flow' anchor='proto'>
<t>The basic flow for an XTLS session is as follows, where traffic represented by single dashes (---) is sent over the XMPP signalling channel and traffic represented by double lines (===) is sent over the negotiated transport.</t>
<figure>
<artwork><![CDATA[
Initiator Responder
| |
| session-initiate |
| (with security info) |
|--------------------------->|
| ack |
|<---------------------------|
| session-accept |
|<---------------------------|
| ack |
|--------------------------->|
| open transport |
|<==========================>|
| TLS ClientHello |
|===========================>|
| TLS ServerHello, [...] |
|<===========================|
| TLS [...], Finished |
|===========================>|
| TLS [...], Finished |
|<===========================|
| application data |
|<==========================>|
| session-terminate |
|<---------------------------|
| ack |
|--------------------------->|
| |
]]></artwork>
</figure>
<t>To simplify the description we assume here that the parties already trust each other's certificates. See discussion under <xref target='bootstrapping'/> for information about bootstrapping of certificate trust on the first communication.</t>
<t>First the initiator sends a Jingle session-initiate request (here the simple case of an end-to-end text chat session using in-band bytestreams <xref target='XEP-0047'/>. This request includes a <security/> element that contains the fingerprint of the certificate that the initiator will use during the TLS negotiation.</t>
<figure>
<artwork><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='xn28s7gk'
to='juliet@capulet.lit/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:0'>
action='session-initiate'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='xmlstream'>
<description xmlns='urn:xmpp:jingle:apps:xmlstream:0'/>
<transport xmlns='urn:xmpp:jingle:transports:ibb:0'
block-size='4096'
sid='ch3d9s71'/>
<security xmlns='urn:xmpp:jingle:security:xtls:0'>
<fingerprint>RomeoX509CertificateHash</fingerprint>
<method name='x509'/>
<method name='srp'/>
</security>
</content>
</jingle>
</iq>
]]></artwork>
</figure>
<t>The responder immediately acknowledges receipt of the session-initiate by sending an IQ stanza of type "result" (not shown here).</t>
<t>Depending on the application type, a user agent controlled by a human user might need to wait for the user to affirm a desire to proceed with the session before continuing. When the user agent has received such affirmation (or if the user agent can automatically proceed for any reason, e.g. because no human intervention is expected or because a human user has configured the user agent to automatically accept sessions with a given entity), it returns a Jingle session-accept message. This message will typically contain the offered application type, transport method, and a <security/> element that includes the fingerprint of the responder's X.509 certificate as well as the responder's supported TLS methods.</t>
<figure>
<artwork><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='hf64hl'
to='romeo@montague.net/orchard'
type='set'>
<jingle xmlns='urn:xmpp:jingle:0'>
action='session-accept'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='xmlstream'>
<description xmlns='urn:xmpp:jingle:apps:xmlstream:0'/>
<transport xmlns='urn:xmpp:jingle:transports:ibb:0'
block-size='4096'
sid='ch3d9s71'/>
<security xmlns='urn:xmpp:jingle:security:xtls:0'/>
<fingerprint>JulietX509CertificateHash</fingerprint>
<method name='x509'/>
<method name='srp'/>
</security>
</content>
</jingle>
</iq>
]]></artwork>
</figure>
<t>The following rules apply to the responder's handling of the session-initiate message:</t>
<t>
<list style='numbers'>
<t>If the responder does not support Jingle-XTLS it will silently ignore the <security/> element in the offer and therefore will return a session-accept message without a <security/> element.</t>
<t>If the responder supports Jingle-XTLS it SHOULD return a session-accept message that contains a <security/> element.</t>
<t>If the responder thinks it will be able to verify the initiator's certificate, it MUST include the fingerprint for the responder's certificate in the <security/> element of the session-accept message. This is the "happy path" and will occur when the parties have already verified each other's certificates.</t>
<t>If the responder thinks it will not be able to verify the initiator's certificate, it MAY omit the fingerprint for the responder's certificate in the <security/> element of the session-accept message. This indicates that certificate-based authentication is not possible. In this case the responder SHOULD signal that it wishes to use some other authentication method, such as secure remote passwords (see discussion under <xref target='bootstrapping'/>).</t>
<t>If the responding client cannot verify the initiator's certificate, it SHOULD ask the responding user if a password was exchanged between the parties that can be used for TLS-SRP. If this is not the case, setting up a mutually-authenticated link will fail and the responder MAY terminate the session. Alternatively it could send its own fingerprint knowing it cannot authenticate the initiator, in which case the responder has to trust that there is no man-in-the-middle (see discussion under <xref target='bootstrapping'/>).</t>
</list>
</t>
<t>When the responder sends the session-accept message, the initiator acknowledges receipt by sending an IQ stanza of type "result" (not shown here).</t>
<t>The following rules apply to the initiator's handling of the session-accept message:</t>
<t>
<list style='numbers'>
<t>If the initiator receives a session-accept without a <security/> element, setting up a secure transport layer has failed. The initiator MAY terminate the session at this point or instead proceed without securing the transport. The client SHOULD ask the initiating user how to processed. This depends on the Jingle application and the initiator's preferences: it makes no sense to use end-to-end XML streams without encryption, but the initiator might continue a file transfer without encryption.</t>
<t>If the initiating client cannot verify the responder's certificate it SHOULD ask the initiating user if a password was exchanged between the parties that can be used for TLS-SRP. If this is not the case, setting up a mutually-authenticated link will fail and the responder MAY terminate the session or proceed with leap-of-faith (see discussion under <xref target='bootstrapping'/>).</t>
</list>
</t>
<t>The initiator can now determine if X.509 certificate based authentication will work or if TLS-SRP will be used. It sends an additional security-info message to the responder to signal its choice. This step is not really necessary because the responder will see the initiator's choice in the first message of the TLS handshake, but it can help an implementation to set up its TLS library properly. Because in this section we assume that the parties already have validated each other's certificates, the security method signalled here is "x509".</t>
<figure>
<artwork><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='hf749j'
to='juliet@capulet.lit/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:0'>
action='security-info'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='xmlstream'>
<security xmlns='urn:xmpp:jingle:security:xtls:0'>
<method name='x509'/>
</security>
</content>
</jingle>
</iq>
]]></artwork>
</figure>
<t>The responder acknowledges receipt by sending an IQ stanza of type "result" (not shown here).</t>
<t>Parallel to the security-info exchange, the clients negotiate a transport for the Jingle session (here the transport is an in-band bytestream as defined in <xref target='XEP-0047'/>, for which the Jingle negotiation process is specified in <xref target='XEP-0261'/>; however other transports could be used, for example SOCKS5 bytestreams as defined in <xref target='XEP-0065'/> and negotiated for Jingle as specified in <xref target='XEP-0260'/>). Because the parties wish to establish end-to-end encryption, they do not send application data over the transport until the transport has been secured. Therefore the first data that they exchange over the transport consists of the standard four-way TLS handshake, encoded in accordance with the negotiated transport method.</t>
<t><list style='empty'><t>Note: Each transport MUST define a specific time when both cients know that the transport is secured. When XTLS is not used, the Jingle implementation would signal to the using application that the transport is open when the session-accept is sent or received, or when connectivity checks determine media can flow over one of the transport candidates. When XTLS is used, the Jingle implementation starts a TLS handshake on the transport and signals to the using application that the transport is open only after the TLS handshake has finished successfully.</t></list></t>
<t>During the TLS handshake, the responder MUST take the role of the TLS server and the initiator MUST take the role of the TLS client. Because the transport is an in-band bytestream, the TLS handshake data is prepared as described in <xref target='XEP-0047'/> (i.e., Base64-encoded). First the initiator (acting as the TLS client) constructs a TLS ClientHello, encodes it according to IBB, and sends it to the responder.</t>
<figure>
<artwork><![CDATA[
<iq from='romeo@montague.net/orchard'
id='vh38s618'
to='juliet@capulet.com/balcony'
type='set'>
<data xmlns='http://jabber.org/protocol/ibb'
seq='0'
sid='vj3hs98y'>
Base64-encoded-TLS-data
</data>
</iq>
]]></artwork>
</figure>
<t>The responder (acting as the TLS server) then acknowledges receipt by sending an IQ stanza of type "result" (not shown here).</t>
<t>The responder then constructs an appropriate TLS message or messages, such as a ServerHello and a CertificateRequest.</t>
<t><list style='empty'><t>Note: The responder MUST send a CertificateRequest to the initiator.</t></list></t>
<figure>
<artwork><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='xyw516d0'
from='romeo@montague.net/orchard'
type='set'>
<data xmlns='http://jabber.org/protocol/ibb'
seq='0'
sid='vj3hs98y'>
Base64-encoded-TLS-data
</data>
</iq>
]]></artwork>
</figure>
<t>(Because in-band bytestreams are bidirectional and this data is sent from the responder to the initiator, the IBB 'seq' attribute has a value of zero, not 1.)</t>
<t>The initiator then acknowledges receipt by sending an IQ stanza of type "result" (not shown here).</t>
<t>After some number of TLS messages, the initiator eventually sends a TLS Finished message to the responder.</t>
<figure>
<artwork><![CDATA[
<iq from='romeo@montague.net/orchard'
id='s91vd527'
to='juliet@capulet.com/balcony'
type='set'>
<data xmlns='http://jabber.org/protocol/ibb'
seq='3'
sid='vj3hs98y'>
Base64-encoded-TLS-data
</data>
</iq>
]]></artwork>
</figure>
<t>The responder then acknowledges receipt by sending an IQ stanza of type "result" (not shown here).</t>
<t>The responder then also sends a TLS Finished message.</t>
<figure>
<artwork><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='z71gs73t'
from='romeo@montague.net/orchard'
type='set'>
<data xmlns='http://jabber.org/protocol/ibb'
seq='3'
sid='vj3hs98y'>
Base64-encoded-TLS-data
</data>
</iq>
]]></artwork>
</figure>
<t>The initiator then acknowledges receipt by sending an IQ stanza of type "result" (not shown here).</t>
<t>If the TLS negotiation has finished successfully, then the Jingle implementation shall signal to the using application that the transport has been secured and is ready to be used. The parties can then begin to exchange application data over the encrypted transport.</t>
</section>
<section title='End-to-End Streams over XTLS Protocol Flow' anchor='streamproto'>
<t>For end-to-end encryption of XMPP traffic, the application data is an end-to-end XML stream. After the XTLS session is set up, the peers open an XML stream to excahnge messages. The XML streams are sent though the XTLS connection. In this example the streams are sent over TLS over IBB.</t>
<t>First the initiator constructs an initial stream header.</t>
<figure>
<artwork><![CDATA[
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='romeo@montague.lit/orchard'
to='juliet@capulet.lit/balcony'
version='1.0'>
]]></artwork>
</figure>
<t>Note: In accordance with <xref target='rfc3920bis'/>, the initial stream header SHOULD include the 'to' and 'from' attributes, which SHOULD specify the full JIDs of the clients. The initiator SHOULD include the version='1.0' flag as shown in the previous example.</t>
<t>The initiator then sends the stream header through the TLS stream and encodes the TLS data in IBB and sends it to the responder.</t>
<figure>
<artwork><![CDATA[
<iq from='romeo@montague.net/orchard'
id='ur73n153'
to='juliet@capulet.com/balcony'
type='set'>
<data xmlns='http://jabber.org/protocol/ibb'
seq='4'
sid='vj3hs98y'>
Base64-TLS-data-of-the-stream-header
</data>
</iq>
]]></artwork>
</figure>
<t>The responder then acknowledges receipt by sending an IQ stanza of type "result" (not shown here).</t>
<t>The responder then constructs a response stream header back to the initiator.</t>
<figure>
<artwork><![CDATA[
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='juliet@capulet.lit/balcony'
id='hs91gh1836d8s717'
to='romeo@montague.lit/orchard'
version='1.0'>
]]></artwork>
</figure>
<t>The responder then sends the response stream header over the TLS link it to the initiator.</t>
<figure>
<artwork><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='pd61g397'
to='romeo@montague.net/orchard'
type='set'>
<data xmlns='http://jabber.org/protocol/ibb'
seq='4'
sid='vj3hs98y'>
Base64-TLS-data-of-the-responce-stream-header
</data>
</iq>
]]></artwork>
</figure>
<t>The initiator then acknowledges receipt by sending an IQ stanza of type "result" (not shown here).</t>
<t>Once the streams are established over the bytestreams, either entity then can send XMPP message, presence, and IQ stanzas, with or without 'to' and 'from' addresses.</t>
<t>For example, the initiator could construct an XMPP message.</t>
<figure>
<artwork><![CDATA[
<message from='romeo@montague.lit/orchard'
to='juliet@capulet.lit/balcony'>
<body>
M'lady, I would be pleased to make your acquaintance.
</body>
</message>
]]></artwork>
</figure>
<t>The initiator then sends the message over the XTLS connection to the responder.</t>
<figure>
<artwork><![CDATA[
<iq from='romeo@montague.net/orchard'
id='iq7dh294'
to='juliet@capulet.com/balcony'
type='set'>
<data xmlns='http://jabber.org/protocol/ibb'
seq='5'
sid='vj3hs98y'>
Base64-TLS-data
</data>
</iq>
]]></artwork>
</figure>
<t>The responder then acknowledges receipt by sending an IQ stanza of type "result" (not shown here).</t>
<t>The responder could then construct a reply.</t>
<figure>
<artwork><![CDATA[
<message from='juliet@capulet.lit/balcony'
to='romeo@montague.lit/orchard'>
<body>Art thou not Romeo, and a Montague?</body>
</message>
]]></artwork>
</figure>
<t>The responder then sends the reply over the XTLS connection to the initiator.</t>
<figure>
<artwork><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='hr91hd63'
to='romeo@montague.net/orchard'
type='set'>
<data xmlns='http://jabber.org/protocol/ibb'
seq='5'
sid='vj3hs98y'>
Base64-TLS-data
</data>
</iq>
]]></artwork>
</figure>
<t>The initiator then acknowledges receipt by sending an IQ stanza of type "result" (not shown here).</t>
<t>To close the end-to-end XML stream, either party (here the responder) constructs a closing </stream:stream> element.</t>
<figure>
<artwork><![CDATA[
</stream:stream>
]]></artwork>
</figure>
<t>The client sends the closing element to the peer over the XTLS connection.</t>
<figure>
<artwork><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='kr91n475'
to='romeo@montague.net/orchard'
type='set'>
<data xmlns='http://jabber.org/protocol/ibb'
seq='6'
sid='vj3hs98y'>
Base64-TLS-data
</data>
</iq>
]]></artwork>
</figure>
<t>The peer then acknowledges receipt by sending an IQ stanza of type "result" (not shown here).</t>
<t>However, even after the application-level XML stream is terminated, the negotiated Jingle transport (here in-band bytestream) continues and could be re-used. To completely terminate the Jingle session, the terminating party would then also send a Jingle session-terminate message.</t>
<figure>
<artwork><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='psy617r4'
to='romeo@montague.lit/orchard'
type='set'>
<jingle xmlns='urn:xmpp:jingle:0'
action='session-terminate'
initiator='romeo@montague.lit/orchard'
sid='851ba2'/>
</iq>
]]></artwork>
</figure>
<t>The other party then acknowledges the Jingle session-terminate by sending an IQ stanza of type "result" (not shown here).</t>
</section>
<section title='Bootstrapping Trust on First Communication' anchor='bootstrapping'>
<t>When two parties first attempt to use XTLS, their certificates might not be accepted (e.g., because they are self-signed or issued by unknown certification authorities). Therefore each party needs to accept the other's certificate for use in future communication sessions. There are several ways to do so:</t>
<t>
<list style='symbols'>
<t>Leap of faith. The recipient can hope that there is no man-in-the-middle during the first communication session. If the certificate does not change in future sessions, the recipient at least knows that it is talking with the same entity it talked with during the first session. However, that entity might be a man-in-the-middle rather than the assumed communication partner. Therefore, leap of faith is discouraged.</t>
<t>Check fingerprints. The parties could validate the certificate fingerprints via some trusted means outside the XMPP band, such as in person, via encrypted email, or over the phone. This is not user-friendly because certificate fingerprints consist of long strings of letters and numbers. As a result, few humans check certificate fingerprints in protocols such as Secure Shell.</t>
<t>One-time password. The parties can exchange a user-friendly password known only to themselves and verify it out of band before the TLS handshake finishes. For this purpose, it is REQUIRED for implementations to support at least one TLS cipher that uses Secure Remote Password (SRP) as defined in <xref target='SRP'/>.</t>
<t>Channel binding. It is possible that a future version will describe how to use an appropriate Simple Authentication and Security Layer (SASL) mechanism, such as <xref target='SCRAM'/>, to authenticate the XTLS channel after the TLS handshake finishes using the concept of channel bindings (see <xref target='RFC5056'/>).</t>
</list>
</t>
<t>If the parties use a password or channel binding via SASL, the process needs to be completed only once. After the clients have authenticated with the shared secret, they can exchange their certificates for future communication.</t>
<section title='Exchanging Certificates' anchor='exchange'>
<t>To retrieve the certificate of the peer for future communications, a client SHOULD request the certificate according to <xref target='XEP-0189'/> over the secure connection. This works only if XTLS was used to set up an end-to-end secure XML stream; exchanging certificates if XTLS was used for other purposes like file transfer is not possible. A client MUST NOT request the certificate over the insecure stream based on the connection to the XMPP server.</t>
<figure>
<artwork><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='hf7634k4'
to='juliet@capulet.lit/balcony'
type='get'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey'/>
</iq>
]]></artwork>
</figure>
<t>The peer MUST return its own client certificate. If the user has different clients with different client certificates and one user certificate, the user certificate SHOULD also be returned. The user certificate allows it to verify other client certificates using public key retrieval described in <xref target='XEP-0189'/>.</t>
<figure>
<artwork><![CDATA[
<iq from='juliet@capulet.com/balcony'
id='hf7634k4'
to='romeo@montague.lit/orchard'
type='result'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey'>
<keyinfo>
<name>JulietX509CertificateHash</name>
<x509cert>
MIICCTCCAXKgAwIBAgIJALhU0Id6xxwQMA0GCSqGSIb3DQEBBQUAMA4xDDAKBgNV
BAMTA2ZvbzAeFw0wNzEyMjgyMDA1MTRaFw0wODEyMjcyMDA1MTRaMA4xDDAKBgNV
BAMTA2ZvbzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0DPcfeJzKWLGE22p
RMINLKr+CxqozF14DqkXkLUwGzTqYRi49yK6aebZ9ssFspTTjqa2uNpw1U32748t
qU6bpACWHbcC+eZ/hm5KymXBhL3Vjfb/dW0xrtxjI9JRFgrgWAyxndlNZUpN2s3D
hKDfVgpPSx/Zp8d/ubbARxqZZZkCAwEAAaNvMG0wHQYDVR0OBBYEFJWwFqmSRGcx
YXmQfdF+XBWkeML4MD4GA1UdIwQ3MDWAFJWwFqmSRGcxYXmQfdF+XBWkeML4oRKk
EDAOMQwwCgYDVQQDEwNmb2+CCQC4VNCHesccEDAMBgNVHRMEBTADAQH/MA0GCSqG
SIb3DQEBBQUAA4GBAIhlUeGZ0d0msNVxYWAXg2lRsJt9INHJQTCJMmoUeTtaRjyp
ffJtuopguNNBDn+MjrEp2/+zLNMahDYLXaTVmBf6zvY0hzB9Ih0kNTh23Fb5j+yK
QChPXQUo0EGCaODWhfhKRNdseUozfNWOz9iTgMGw8eYNLllQRL//iAOfOr/8
</x509cert>
</keyinfo>
</pubkeys>
</iq>
]]></artwork>
</figure>
</section>
<section title='Verification of Non-Human Parties' anchor='bootstrap-bot'>
<t>If one of the parties is a "bot" (e.g., an automated service or a device such as a set-top box), the password exchange is a bit more complicated. It is similar to Bluetooth peering if the user has access to both clients at the same time. One of the following scenarios might apply:</t>
<t>
<list style='symbols'>
<t>The bot can be controlled via a remote control input device. The human user can enter the same password or "PIN" on both the bot and the XMPP client.</t>
<t>If the bot has no user input but does have a small display, it could display a random password. The human user can then enter the provided password on the XMPP client.</t>
<t>The bot might have not enough buttons for input and has no output device. In that case the password is fixed. Similar to Bluetooth peering with simple devices such as a headset, the password will be written in the manual or printed on the device. For security reasons the device SHOULD NOT use password-based authentication without any user input. Many Bluetooth devices have at least one button to set the device into peering mode.</t>
<t>A bot may be associated with a web service and could display a random password when the user has logged in to the web site using HTTPS. This assumes that an attacker does not have control over the web server and can perform a man-in-the-middle attack on XMPP level at the same time. If the web service knows the GPG-key of the user (e.g. launchpad) it could send an encrypted email.</t>
</list>
</t>
<t>A user might have different X.509 certificates for each device. <xref target='XEP-0189'/> can be used to manage the user's certificates. A client SHOULD check the peer's PubSub node for certificates. This makes it possible to use the password method only once between two users even if one or both users switch clients. A user can also communicate with a friend's bots: they first open a secure link between two chat clients with a password and exchange the user certificates. After that each device of a user can verify all devices of the other without the need of a password.</t>
<t>The retrieved certificate from the PubSub node may be signed by a CA the client can verify. In that case the client MAY skip the password authentication and rely on the X.509 certificate chain. The client SHOULD ask the user if the certificate should be accepted or if a password exchange is desired.</t>
</section>
</section>
<section title='Session Termination' anchor='terminate'>
<t>If either client cannot verify the certificate of the peer or receives an invalid message on the TLS layer, it MUST terminate the Jingle session immediately by sending a Jingle session-terminate message that includes a Jingle reason of <security-error/>.</t>
<figure>
<artwork><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='hz81vf48'
to='juliet@capulet.lit/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:0'
action='session-terminate'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
<reason><security-error/></reason>
</jingle>
</iq>
]]></artwork>
</figure>
<t>The other party then acknowledges the session-terminate by sending an IQ stanza of type "result" (not shown here), and the Jingle session is finished.</t>
</section>
<section title='Determining Support' anchor='support'>
<t>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 <xref target='XEP-0030'/> or indirectly via <xref target='XEP-0115'/>.</t>
<t>If an entity supports XTLS, it MUST report that by including a service discovery feature of "urn:xmpp:jingle:security:xtls:0" in response to disco#info requests.</t>
<figure>
<artwork><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='disco1'
to='juliet@capulet.lit/chamber'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
<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:jingle:security:xtls:0'/>
<feature var='urn:xmpp:jingle:apps:xmlstream:0'/>
</query>
</iq>
]]></artwork>
</figure>
<t>Both service discovery and entity capabilities information could be corrupted or intercepted; for details, see under <xref target='security-dos'/>.</t>
</section>
<section title='Security Considerations' anchor='security'>
<t>This entire document addresses security. Particular security-related issues are discussed in the following sections.</t>
<section title='Mandatory-to-Implement Technologies' anchor='security-mti'>
<t>An implementation MUST at a minimum support the "srp" and "x509" methods. A future version of this specification will document mandatory-to-implement TLS ciphers.</t>
</section>
<section title='Certificates' anchor='security-certs'>
<t>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 <xref target='rfc3920bis'/>.</t>
<t>A future version of this specification might provide additional guidelines regarding certificate validation in the context of client-to-client encryption.</t>
</section>
<section title='Denial of Service' anchor='security-dos'>
<t>Currently XMPP stanzas such as Jingle negotiation messages and service discovery exchanges are not encrypted or signed. As a result, it is possible for an attacker to intercept these stanzas and modify them, thus convincing one party that the other party does not support XTLS and therefore denying the parties an opportunity to use XTLS.</t>
<t>This is a more general problem with XMPP technologies and needs to be addressed at the core XMPP layer.</t>
</section>
</section>
<section title='IANA Considerations' anchor='iana'>
<t>It might be helpful to create a registry of TLS methods that can be used in the context of XTLS (e.g., "openpgp" for use of <xref target='RFC5081'/>, "srp" for use of <xref target='SRP'/>, and "x509" for use of <xref target='TLS'/> with certificates). The registry could be maintained by the IANA or by the XMPP Registrar. A future version of this specification will provide more detailed information about the registration requirements.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='rfc3920bis'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<date month='October' day='16' year='2008' />
<abstract><t>This document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements for the purpose of exchanging structured information in close to real time between any two or more network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions. This document also specifies the format for XMPP addresses, which are fully internationalizable. This document obsoletes RFC 3920.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-saintandre-rfc3920bis-08' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-saintandre-rfc3920bis-08.txt' />
</reference>
<reference anchor='TLS'>
<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='ftp://ftp.isi.edu/in-notes/rfc5246.txt' />
</reference>
<reference anchor="XEP-0047">
<front>
<title>In-Band Bytestreams (IBB)</title>
<author initials="J." surname="Karneges" fullname="Justin Karneges">
<organization/>
<address>
<email>justin@affinix.com</email>
</address>
</author>
<date day="21" month="November" year="2006"/>
</front>
<seriesInfo name="XSF XEP" value="0047"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0047.html"/>
</reference>
<reference anchor="XEP-0166">
<front>
<title>Jingle</title>
<author initials="S." surname="Ludwig" fullname="Scott Ludwig">
<organization/>
<address>
<email>scottlu@google.com</email>
</address>
</author>
<author initials="J." surname="Beda" fullname="Joe Beda">
<organization/>
<address>
<email>jbeda@google.com</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="R." surname="McQueen" fullname="Robert McQueen">
<organization/>
<address>
<email>robert.mcqueen@collabora.co.uk</email>
</address>
</author>
<author initials="S." surname="Egan" fullname="Sean Egan">
<organization/>
<address>
<email>seanegan@google.com</email>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
<email>jhildebrand@jabber.com</email>
</address>
</author>
<date day="18" month="December" year="2008"/>
</front>
<seriesInfo name="XSF XEP" value="0166"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0166.html"/>
</reference>
<reference anchor="XEP-0210">
<front>
<title>Requirements for Encrypted Sessions</title>
<author initials="I." surname="Paterson" fullname="Ian Paterson">
<organization/>
<address>
<email>ian.paterson@clientside.co.uk</email>
</address>
</author>
<date day="30" month="May" year="2007"/>
</front>
<seriesInfo name="XSF XEP" value="0210"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0210.html"/>
</reference>
</references>
<references title="Informative References">
<reference anchor='DTLS'>
<front>
<title>Datagram Transport Layer Security</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<author initials='N.' surname='Modadugu' fullname='N. Modadugu'>
<organization /></author>
<date year='2006' month='April' />
<abstract>
<t>This document specifies Version 1.0 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4347' />
<format type='TXT' octets='56014' target='ftp://ftp.isi.edu/in-notes/rfc4347.txt' />
</reference>
<reference anchor='DTLS-SRTP'>
<front>
<title>Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)</title>
<author initials='D' surname='McGrew' fullname='David McGrew'>
<organization />
</author>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<date month='October' day='29' year='2008' />
<abstract><t>This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for secure RTP (SRTP) and secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-avt-dtls-srtp-06' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-avt-dtls-srtp-06.txt' />
</reference>
<reference anchor='HTTP-TLS'>
<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2000' month='May' />
<abstract>
<t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='2818' />
<format type='TXT' octets='15170' target='ftp://ftp.isi.edu/in-notes/rfc2818.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='ftp://ftp.isi.edu/in-notes/rfc3923.txt' />
<format type='HTML' octets='77480' target='http://xml.resource.org/public/rfc/html/rfc3923.html' />
<format type='XML' octets='71879' target='http://xml.resource.org/public/rfc/xml/rfc3923.xml' />
</reference>
<reference anchor='RFC5056'>
<front>
<title>On the Use of Channel Bindings to Secure Channels</title>
<author initials='N.' surname='Williams' fullname='N. Williams'>
<organization /></author>
<date year='2007' month='November' />
<abstract>
<t>The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits.</t><t> This document discusses and formalizes the concept of channel binding to secure channels. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5056' />
<format type='TXT' octets='49995' target='ftp://ftp.isi.edu/in-notes/rfc5056.txt' />
</reference>
<reference anchor='RFC5081'>
<front>
<title>Using OpenPGP Keys for Transport Layer Security (TLS) Authentication</title>
<author initials='N.' surname='Mavrogiannopoulos' fullname='N. Mavrogiannopoulos'>
<organization /></author>
<date year='2007' month='November' />
<abstract>
<t>This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. This memo defines an Experimental Protocol for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='5081' />
<format type='TXT' octets='15300' target='ftp://ftp.isi.edu/in-notes/rfc5081.txt' />
</reference>
<reference anchor='SRP'>
<front>
<title>Using the Secure Remote Password (SRP) Protocol for TLS Authentication</title>
<author initials='D.' surname='Taylor' fullname='D. Taylor'>
<organization /></author>
<author initials='T.' surname='Wu' fullname='T. Wu'>
<organization /></author>
<author initials='N.' surname='Mavrogiannopoulos' fullname='N. Mavrogiannopoulos'>
<organization /></author>
<author initials='T.' surname='Perrin' fullname='T. Perrin'>
<organization /></author>
<date year='2007' month='November' />
<abstract>
<t>This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='5054' />
<format type='TXT' octets='44445' target='ftp://ftp.isi.edu/in-notes/rfc5054.txt' />
</reference>
<reference anchor='SCRAM'>
<front>
<title>Salted Challenge Response (SCRAM) SASL Mechanism</title>
<author initials='A' surname='Menon-Sen' fullname='Abhijit Menon-Sen'>
<organization /></author>
<author initials='A' surname='Melnikov' fullname='Alexey Melnikov'>
<organization /></author>
<author initials='C' surname='Newman' fullname='Chris Newman'>
<organization /></author>
<date month='January' day='31' year='2009' />
<abstract>
<t>The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use. This specification describes a family of authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status-quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards.</t></abstract></front>
<seriesInfo name='Internet-Draft' value='draft-newman-auth-scram-08' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-newman-auth-scram-08.txt' />
</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://www.xmpp.org/extensions/xep-0027.html"/>
</reference>
<reference anchor="XEP-0030">
<front>
<title>Service Discovery</title>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
<email>jhildebrand@jabber.com</email>
</address>
</author>
<author initials="P." surname="Millard" fullname="Peter Millard">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="R." surname="Eatmon" fullname="Ryan Eatmon">
<organization/>
<address>
<email>reatmon@jabber.org</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<date day="06" month="June" year="2008"/>
</front>
<seriesInfo name="XSF XEP" value="0030"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0030.html"/>
</reference>
<reference anchor="XEP-0045">
<front>
<title>Multi-User Chat</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<date day="16" month="July" year="2008"/>
</front>
<seriesInfo name="XSF XEP" value="0045"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0045.html"/>
</reference>
<reference anchor="XEP-0065">
<front>
<title>SOCKS5 Bytestreams</title>
<author initials="D." surname="Smith" fullname="Dave Smith">
<organization/>
<address>
<email>dizzyd@jabber.org</email>
</address>
</author>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization/>
<address>
<email>linuxwolf@outer-planes.net</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<date day="21" month="May" year="2007"/>
</front>
<seriesInfo name="XSF XEP" value="0065"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0065.html"/>
</reference>
<reference anchor="XEP-0115">
<front>
<title>Entity Capabilities</title>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
<email>jhildebrand@jabber.com</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="R." surname="Tronçon" fullname="Remko Tronçon">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="J." surname="Konieczny" fullname="Jacek Konieczny">
<organization/>
<address>
<email>jajcus@jajcus.net</email>
</address>
</author>
<date day="26" month="February" year="2008"/>
</front>
<seriesInfo name="XSF XEP" value="0115"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0115.html"/>
</reference>
<reference anchor="XEP-0167">
<front>
<title>Jingle RTP Sessions</title>
<author initials="S." surname="Ludwig" fullname="Scott Ludwig">
<organization/>
<address>
<email>scottlu@google.com</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="S." surname="Egan" fullname="Sean Egan">
<organization/>
<address>
<email>seanegan@google.com</email>
</address>
</author>
<author initials="R." surname="McQueen" fullname="Robert McQueen">
<organization/>
<address>
<email>robert.mcqueen@collabora.co.uk</email>
</address>
</author>
<author initials="D." surname="Cionoiu" fullname="Diana Cionoiu">
<organization/>
<address>
<email>diana@null.ro</email>
</address>
</author>
<date day="19" month="December" year="2008"/>
</front>
<seriesInfo name="XSF XEP" value="0167"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0167.html"/>
</reference>
<reference anchor="XEP-0189">
<front>
<title>Public Key Publishing</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/>
</address>
</author>
<author initials="D." surname="Meyer" fullname="Dirk Meyer">
<organization/>
<address>
<email>dmeyer@tzi.de</email>
</address>
</author>
<date day="08" month="September" year="2008"/>
</front>
<seriesInfo name="XSF XEP" value="0189"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0189.html"/>
</reference>
<reference anchor="XEP-0218">
<front>
<title>Bootstrapping Implementation of Encrypted Sessions</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="I." surname="Paterson" fullname="Ian Paterson">
<organization/>
<address>
<email>ian.paterson@clientside.co.uk</email>
</address>
</author>
<date day="30" month="May" year="2007"/>
</front>
<seriesInfo name="XSF XEP" value="0218"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0218.html"/>
</reference>
<reference anchor="XEP-0234">
<front>
<title>Jingle File Transfer</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<date day="19" month="February" year="2009"/>
</front>
<seriesInfo name="XSF XEP" value="0234"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0234.html"/>
</reference>
<reference anchor="XEP-0260">
<front>
<title>Jingle SOCKS5 Bytestreams Transport Method</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="D." surname="Meyer" fullname="Dirk Meyer">
<organization/>
<address>
<email>dmeyer@tzi.de</email>
</address>
</author>
<date day="19" month="February" year="2009"/>
</front>
<seriesInfo name="XSF XEP" value="0260"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0260.html"/>
</reference>
<reference anchor="XEP-0261">
<front>
<title>Jingle In-Band Bytestreams Transport</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<date day="19" month="February" year="2009"/>
</front>
<seriesInfo name="XSF XEP" value="0261"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0261.html"/>
</reference>
</references>
<section title='XML Schema' anchor='schema'>
<t>The XML schema will be provided in a later version of this document.</t>
</section>
<section title="Copying Conditions" anchor="copying">
<t>Regarding this entire document or any portion of it, the authors make no guarantees and are not responsible for any damage resulting from its use. The authors grant irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information. Derivative works need not be licensed under similar terms.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 00:14:35 |