RFC 6189 [3], developed by Phil Zimmermann, the inventor of "Pretty Good Privacy" (PGP). Although negotiation of ZRTP mainly occurs in the media channel rather than the signalling channel, the ZRTP specification defines one SDP attribute called "zrtp-hash" (this communicates the ZRTP version supported as well as a hash of the Hello message). Inclusion of this information is OPTIONAL in both SIP/SDP and Jingle.
The SDP format is shown below.
a=zrtp-hash:zrtp-version zrtp-hash-value
An example follows.
a=zrtp-hash:1.10 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df
This SDP attribute can be translated into Jingle as a <zrtp-hash/> element qualified by the 'urn:xmpp:jingle:apps:rtp:zrtp:1' namespace, as shown below.
<zrtp-hash version='zrtp-version' xmlns='urn:xmpp:jingle:apps:rtp:zrtp:1'>zrtp-hash-value</zrtp-hash>
An example follows.
<zrtp-hash version='1.10' xmlns='urn:xmpp:jingle:apps:rtp:zrtp:1'> fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df </zrtp-hash>
The <zrtp-hash/> element is sent as a child of the <encryption/> element defined in Jingle RTP Sessions (XEP-0167) [1].
If the Jingle initiator wishes to use ZRTP, it includes the <zrtp-hash/> element in its session invitation (where it hashes over its own Hello message as described in the ZRTP specification).
<iq from='[email protected]/orchard'
id='uz61v4m4'
to='[email protected]/balcony'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-initiate'
initiator='[email protected]/orchard'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='voice'>
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
<payload-type id='96' name='speex' clockrate='16000'/>
<payload-type id='97' name='speex' clockrate='8000'/>
<payload-type id='18' name='G729'/>
<payload-type id='103' name='L16' clockrate='16000' channels='2'/>
<payload-type id='98' name='x-ISAC' clockrate='8000'/>
<encryption required='true'>
<zrtp-hash xmlns='urn:xmpp:jingle:apps:rtp:zrtp:1' version='1.10'>
fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df
</zrtp-hash>
</encryption>
</description>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='asd88fgpdd777uzjYhagZg'
ufrag='8hhy'>
<candidate component='1'
foundation='1'
generation='0'
id='el0747fg11'
ip='10.0.1.1'
network='1'
port='8998'
priority='2130706431'
protocol='udp'
type='host'/>
<candidate component='1'
foundation='2'
generation='0'
id='y3s2b30v3r'
ip='192.0.2.3'
network='1'
port='45664'
priority='1694498815'
protocol='udp'
rel-addr='10.0.1.1'
rel-port='8998'
type='srflx'/>
</transport>
</content>
</jingle>
</iq>
If the receiving party wishes to proceed with ZRTP negotiation, it also includes the <zrtp-hash/> element in its session-accept message (where it hashes over its own Hello message as described in the ZRTP specification).
<iq from='[email protected]/balcony'
id='pn2va48j'
to='[email protected]/orchard'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-accept'
initiator='[email protected]/orchard'
responder='[email protected]/balcony'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='voice'>
<description xmlns='urn:xmpp:jingle:apps:rtp:1' media='audio'>
<payload-type id='97' name='speex' clockrate='8000'/>
<payload-type id='18' name='G729'/>
<encryption>
<zrtp-hash xmlns='urn:xmpp:jingle:apps:rtp:zrtp:1' version='1.10'>
badfbe66ff87fe135750377509b09b0babd1c3ec25fa4314565e2bf7ccc30299
</zrtp-hash>
</encryption>
</description>
<transport xmlns='urn:xmpp:jingle:transports:ice-udp:1'
pwd='YH75Fviy6338Vbrhrlp8Yh'
ufrag='9uB6'>
<candidate component='1'
foundation='1'
generation='0'
id='or2ii2syr1'
ip='192.0.2.1'
network='0'
port='3478'
priority='2130706431'
protocol='udp'
type='host'/>
</transport>
</content>
</jingle>
</iq>
Note that a unique zrtp-hash is needed for each media stream, since the hash for each stream is computed from a different ZRTP Hello message (e.g., if a session includes both audio and video then the value of the <zrtp-hash/> element included in the <description/> element for the audio stream will be different from the value for the video stream).
If an entity supports the use of ZRTP in Jingle as described in this document, it MUST advertise that fact in its responses to Service Discovery (XEP-0030) [4] information ("disco#info") requests by returning a feature of "urn:xmpp:jingle:apps:rtp:zrtp:1":
<iq type='get'
from='[email protected]/lab'
to='[email protected]/home'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
<iq type='result'
from='[email protected]/home'
to='[email protected]/lab'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:jingle:1'/>
<feature var='urn:xmpp:jingle:apps:rtp:zrtp:1'/>
</query>
</iq>
In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in Entity Capabilities (XEP-0115) [5]. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
Security considerations for ZRTP itself are provided in RFC 6189 [3].
XMPP stanzas such as Jingle invite 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 ZRTP and therefore denying the parties an opportunity to use ZRTP. However, because the zrtp-hash is mostly advisory, the parties could still use ZRTP even if the signalling channel is compromised.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [6].
Thanks to Werner Dittmann and Emil Ivov for their implementation feedback.
This specification defines the following XML namespace:
If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:jingle:apps:rtp:zrtp:1'
xmlns='urn:xmpp:jingle:apps:rtp:zrtp:1'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-0262: http://www.xmpp.org/extensions/xep-0262.html
</xs:documentation>
</xs:annotation>
<xs:element name='zrtp-hash'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute name='version' type='xs:string' use='required'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
This document in other formats: XML CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) 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.
There exists a special venue for discussion related to the technology described in this document: the <[email protected]> list might also be appropriate.
Errata can be sent to <[email protected]>.
The following requirements keywords as used in this document are to be interpreted as described in http://tools.ietf.org/html/rfc6189>.
4. XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0053.html>.
Note: Older versions of this specification might be available at 0.2 (2010-08-09)¶
In harmony with the ZRTP spec, moved communication of <zrtp-hash/> element from Jingle session-info message to jingle-invite, specifically as a child of the <encryption/> element from XEP-0167; increased protocol version from zero to one.
First draft, copied from XEP-0167.
@report{saint-andre2009jingle-zrtp,
title = {Use of ZRTP in Jingle RTP Sessions},
author = {Saint-Andre, Peter},
type = {XEP},
number = {0262},
version = {1.0},
institution = {XMPP Standards Foundation},
url = {https://xmpp.org/extensions/xep-0262.html},
date = {2009-02-17/2011-06-15},
}END