Merge branches 'feature/xep-0391', 'feature/xep-0060', 'feature/protoxep-cap' and 'feature/protoxep-jet-omemo'

This commit is contained in:
Jonas Wielicki 2017-10-10 08:32:42 +02:00
commit 746cbc7f38
3 changed files with 300 additions and 53 deletions

View File

@ -22,6 +22,18 @@
<supersededby/> <supersededby/>
<shortname>cap</shortname> <shortname>cap</shortname>
&flow; &flow;
<revision>
<version>0.0.3</version>
<date>2017-10-06</date>
<initials>fs</initials>
<remark><p>Use a custom item value (CAP-V).</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2017-08-25</date>
<initials>fs</initials>
<remark><p>Use PubSub publish-options preconditions.</p></remark>
</revision>
<revision> <revision>
<version>0.0.1</version> <version>0.0.1</version>
<date>2017-04-20</date> <date>2017-04-20</date>
@ -50,28 +62,91 @@
<section1 topic='Compare-And-Publish PubSub Items' anchor='cap'> <section1 topic='Compare-And-Publish PubSub Items' anchor='cap'>
<p>In order to atomically compare-and-publish an item, a client <section2 topic='PubSub Item Compare-And-Publish Value (CAP-V)' anchor='cap-v'>
sends an &IQ; with a 'pubsub' element qualified by the
'urn:xmpp:pubsub:cap:0' namespace. The element MUST contain the same
attributes and elements as the &lt;publish/&gt; element defined in
&xep0060; <em>and</em> it MUST contain a previd attribute containing
an item ID.</p>
<p>The PubSub service MUST only publish the item if the node's <p>PubSub services supporting the Compare-And-Publish PubSub extension MUST include a Comapre-and-Publish value
latest item ID is equal to the ID found in the 'previd' (CAP-V) for every item in every response. The CAP-V value MUST change if the content of the item changed and
attribute.</p> different item content under the same node MUST NOT yield the same CAP-V. A simple computation of the CAP-ID would
be to hash the String representation of the item's content.</p>
<example caption='Publisher publishes an item using Compare-And-Publish'><![CDATA[ <p>CAP-Vs are assoicated with PubSub node's items via the item ID. The maping information is placed by the PubSub
service in a &lt;cap-v-map/&gt; extension element, qualified by the 'urn:xmpp:pubsub:cap:0' namespace, as child
element of the &lt;items/&gt; element. The &lt;cap-v-map/&gt; element contains one or more &lt;cap-v-map-entry/&gt;
elements, of which each MUST have a 'item-id' and a 'cap-value' attribute. The former contains the PubSub item ID
value and the later contains the according CAP-V of the item.</p>
<example caption='Service returns some items and their according CAP-Vs'><![CDATA[
<iq type='result'
from='pubsub.shakespeare.lit'
to='francisco@denmark.lit/barracks'
id='items1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='princely_musings'>
<item id='368866411b877c30064a5f62b917cffe'>
<entry xmlns='http://www.w3.org/2005/Atom'>
<title>The Uses of This World</title>
<summary>
O, that this too too solid flesh would melt
Thaw and resolve itself into a dew!
</summary>
</entry>
</item>
<item id='3300659945416e274474e469a1f0154c'>
<entry xmlns='http://www.w3.org/2005/Atom'>
<title>Ghostly Encounters</title>
<summary>
O all you host of heaven! O earth! what else?
And shall I couple hell? O, fie! Hold, hold, my heart;
And you, my sinews, grow not instant old,
But bear me stiffly up. Remember thee!
</summary>
</entry>
</item>
<item id='4e30f35051b7b8b42abe083742187228'>
<entry xmlns='http://www.w3.org/2005/Atom'>
<title>Alone</title>
<summary>
Now I am alone.
O, what a rogue and peasant slave am I!
</summary>
</entry>
</item>
<cap-v-map xmlns='urn:xmpp:pubsub:cap:0'>
<cap-value-map-entry
item-id='368866411b877c30064a5f62b917cffe'
cap-value='35a204c2-5d6c-43a2-8e0d-a235a627b04a'/>
<cap-value-map-entry
item-id='3300659945416e274474e469a1f0154c'
cap-value='166b7c04-ed4d-4872-aa56-a58268da84e2'/>
<cap-value-map-entry
item-id='4e30f35051b7b8b42abe083742187228'
cap-value='67f7f792-f2ee-4918-8894-36a3c4a6dd5f'/>
</cap-v-map>
</items>
</pubsub>
</iq>
]]></example>
</section2>
<section2 topic='PubSub publishing using Compare-And-Publish'>
<p>In order to atomically compare-and-publish an item, a client sends a <cite>XEP-0060</cite> &lt;publish/&gt; IQ
with a 'pubsub#prev_item_cap_value' precondition publishing option, set to the value of the currently assumed CAP-V
of the latest item of the node.</p>
<p>The PubSub service MUST only publish the item if the node's latest item CAP-V is equal to the
CAP-V found in the 'pubsub#prev_item_cap_value' field.</p>
<example caption='Atomically publishing with Compare-And-Publish'><![CDATA[
<iq type='set' <iq type='set'
from='hamlet@denmark.lit/blogbot' from='hamlet@denmark.lit/blogbot'
to='pubsub.shakespeare.lit' to='pubsub.shakespeare.lit'
id='compare-and-publish1'> id='pub1'>
<pubsub xmlns='urn:xmpp:pubsub:cap:0'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
<compare-and-publish <publish node='princely_musings'>
node='princely_musings' <item id='2'>
previd='1'> <entry xmlns='https://example.org'>
<item>
<entry xmlns='http://www.w3.org/2005/Atom'>
<title>Soliloquy</title> <title>Soliloquy</title>
<summary> <summary>
To be, or not to be: that is the question: To be, or not to be: that is the question:
@ -80,63 +155,73 @@ The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles, Or to take arms against a sea of troubles,
And by opposing end them? And by opposing end them?
</summary> </summary>
<link rel='alternate' type='text/html'
href='http://denmark.lit/2003/12/13/atom03'/>
<id>tag:denmark.lit,2003:entry-32397</id>
<published>2003-12-13T18:30:02Z</published>
<updated>2003-12-13T18:30:02Z</updated>
</entry> </entry>
</item> </item>
</publish> </publish>
<publish-options>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
<value>http://jabber.org/protocol/pubsub#publish-options</value>
</field>
<field var='pubsub#prev_item_cap_value'>
<value>1</value>
</field>
</x>
</publish-options>
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<section2 topic='Successfully published an item using Compare-And-Publish'>
<p>If the 'previd' matched the latest item's ID and if the service
was able to successfully process the request then the protocol
continues as defined in <cite>XEP-0060 7.1.2</cite>.</p>
</section2> </section2>
<section2 topic='Could not publish because newest item ID did not match'> <section2 topic='Could not publish because newest item ID did not match'>
<p>In case the Compare-And-Publish operation failed because the <p>In case the Compare-And-Publish operation failed because the latest node id is not the same
latest node id is not the same as given in the 'previd' attribute as given in the 'previd' attribute in the request, the server returns an &lt;conflict/&gt; error
in the request, the server returns an &IQ; result with 'pubsub' of type 'modify' which a pubsub-specific condition of &lt;precondition-not-met/&gt; and a
element qualified by the 'urn:xmpp:pubsub:cap:0' namespace which &lt;compare-and-publish-failed/&gt; element qualifed by the 'urn:xmpp:pubsub:cap:0'
contains a &lt;compare-and-publish-failed/&gt; element. The namespace. The element MUST have a 'cap-id' attribute with the CAP-V of the lastest item.</p>
element MUST have a 'id' attribute with the ID of the lastest
item.</p>
<example caption='Service returns IQ response notifying of failed Compare-And-Publish operation'><![CDATA[ <example caption='Service returns IQ response notifying of failed Compare-And-Publish operation'><![CDATA[
<iq type='result' <iq type='error'
from='pubsub.shakespeare.lit' from='pubsub.shakespeare.lit'
to='hamlet@denmark.lit/blogbot' to='hamlet@denmark.lit/elsinore'
id='compare-and-ublish1'> id='retract1'>
<pubsub xmlns='urn:xmpp:pubsub:cap:0'> <error type='modify'>
<compare-and-publish-failed id='2'/> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</pubsub> <precondition-not-met xmlns='http://jabber.org/protocol/pubsub#errors'/>
<compare-and-publish-failed xmlns='urn:xmpp:pubsub:cap:0' cap-id='2'/>
</error>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
<section2 topic='Error cases'> </section1>
<p>All other error cases are handled as specified in <section1 topic='Rationale' anchor='rationale'>
<cite>XEP-0060 § 7.1.3</cite></p>
</section2> <p>Unfortunately it was not possible to re-use the PubSub item ID for the "Atomically
Compare-And-Publish" purpose. This is mostly due <cite>XEP-0060 § 12.8</cite> stating that:</p>
<p class='box'>
"If a publisher publishes an item and the ItemID
matches that of an existing item, the pubsub service MUST overwrite the existing item and generate a new event
notification."
</p>
<p> Which means that the content of an item could change without its ID, rendering the item ID
unusable for CAP. </p>
<p>Injecting a "cap"-namespaced attribute carrying the item's CAP-V into PubSub's &lt;item/&gt;
would be a very elegant approach to assign CAP-Vs to PubSub items (and the favored one of the
XEP's author). But the usage of namespaces attributes within XMPP is controversial. Therefore this
XEP resorts to using the &lt;cap-v-map/&gt; approach for now.</p>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>This extension protocol does not add any further security <p>This extension protocol does not add any further security considerations to the ones mentioned
considerations to the ones mentioned in <cite>XEP-0060 § in <cite>XEP-0060 § 14.</cite>.</p>
14.</cite>.</p>
</section1> </section1>
@ -153,17 +238,39 @@ And by opposing end them?
<ul> <ul>
<li>urn:xmpp:pubsub:cap:0</li> <li>urn:xmpp:pubsub:cap:0</li>
</ul> </ul>
<code caption='Registry Submission'><![CDATA[ <code caption='Registry Submission'><![CDATA[
<var> <var>
<name>urn:xmpp:pubsub:cap:0</name> <name>urn:xmpp:pubsub:cap:0</name>
<desc>Indicates support for Compare-And-Publish</desc> <desc>Indicates support for Compare-And-Publish</desc>
<doc>XEP-XXXX</doc> <doc>XEP-XXXX</doc>
</var>]]></code> </var>]]></code>
<p>This specification defines the following &lt;publish-options/&gt; fields:</p>
<ul>
<li>pubsub#prev_item_cap_value</li>
</ul>
<code caption='Registry Submission'><![CDATA[
<field var='pubsub#prev_item_cap_value'
type='text-single'
label='Precondition: The assumed value of the latest item&apos; CAP-V of the node'/>]]></code>
</section1> </section1>
<section1 topic='XML Schema' anchor='schema'> <section1 topic='XML Schema' anchor='schema'>
<p>TODO: Add after the XEP leaves the 'experimental' state.</p> <p>TODO: Add after the XEP leaves the 'experimental' state.</p>
</section1> </section1>
<section1 topic='Acknowledgements' anchor='acknowledgements'>
<p>Thanks to Kim Alvefur and Dave Cridland for their feedback.</p>
</section1>
</xep> </xep>
<!-- Local Variables: -->
<!-- fill-column: 100 -->
<!-- indent-tabs-mode: nil -->
<!-- End: -->

133
inbox/jet-omemo.xml Normal file
View File

@ -0,0 +1,133 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY secret "&lt;secret/&gt;">
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Jingle Encrypted Transports - OMEMO</title>
<abstract>Extension for JET introducing OMEMO End-to-End Encrypted Jingle Transports.</abstract>
&LEGALNOTICE;
<number>XXXX</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XEP-0391</spec>
<spec>XEP-0234</spec>
<spec>XEP-0384</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>jet-omemo</shortname>
<schemaloc>
<ns>jingle</ns>
<url>http://xmpp.org/schemas/jingle.xsd</url>
</schemaloc>
<schemaloc>
<ns>jingle:errors</ns>
<url>http://xmpp.org/schemas/jingle-errors.xsd</url>
</schemaloc>
<registry/>
<discuss>jingle</discuss>
<author>
<firstname>Paul</firstname>
<surname>Schaub</surname>
<email>vanitasvitae@riseup.net</email>
<jid>vanitasvitae@jabberhead.tk</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2017-10-06</date>
<initials>vv</initials>
<remark><p>First draft</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&xep0391; can be used to utilize different end-to-end encryption methods to secure Jingle Transports, eg. in the context of &xep0234;. This document aims to extend &xep0391; to allow the use of OMEMO encryption with Jingle transports. To achieve this goal, this protocol extension makes use of OMEMOs <link url='https://xmpp.org/extensions/xep-0384.html#usecases-keysend'>KeyTransportElements</link>.</p>
</section1>
<section1 topic='Mappings' anchor='mappings'>
<p>Conveniently the OMEMO protocol already provides a way to transport key material to another entity. So called KeyTransportElements are basically normal OMEMO MessageElements, but without a payload, so the contained key can be used for something else (See Section 4.6 of <cite>XEP-0384</cite>). This extension uses the key encrypted in the KeyTransportMessages &lt;key&gt; attribute and initialization vector from the &lt;iv&gt; attribute to secure Jingle Transports. The key corresponds to the <cite>Transport Key</cite> of <cite>XEP-0391</cite>, while the iv corresponds to the <cite>Initialization Vector</cite>. The KeyTransportMessage is the equivalent to the <cite>Envelope Element</cite>. Note that within the Envelope Element, the Transport Key is encrypted with the OMEMO ratchet.</p>
</section1>
<section1 topic='Limitaions' anchor='limitations'>
<p>Unfortunately &xep0384; determines the type of the transported key to be AES-128-GCM-NoPadding, so no other configuration can be used in the context of this extension.</p>
<p>Since OMEMO deviceIds are not bound to XMPP resources, the initiator MUST encrypt the Transport Key for every device of the recipient.</p>
</section1>
<section1 topic='Key Transport' anchor='transport'>
<p>In order to transport a key to the responder, the initiator creates a fresh AES-128-GCM-NoPadding Transport Key and Initialization Vector and generates an OMEMO KeyTransportElement from it as described in <cite>XEP-0384</cite>. This is then added as a child of the JET &lt;security&gt; element. The 'cipher' attribute MUST be set to 'aes-128-gcm-nopadding:0' (see the <link url='https://xmpp.org/extensions/xep-0391.html#ciphers'>ciphers</link> section of <cite>XEP-0391</cite>). The value of the 'type' attribute must be set to the namespace of the used version of <cite>XEP-0384</cite> &VNOTE;.</p>
<p></p>
<example caption="Romeo initiates an OMEMO encrypted file offer"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
id='nzu25s8'
to='juliet@capulet.example/yn0cl4bnw0yr3vym'
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-initiate'
initiator='romeo@montague.example/dr4hcr0st3lup4c'
sid='851ba2'>
<content creator='initiator' name='a-file-offer' senders='initiator'>
<description xmlns='urn:xmpp:jingle:apps:file-transfer:5'>
<file>
<date>1969-07-21T02:56:15Z</date>
<desc>This is a test. If this were a real file...</desc>
<media-type>text/plain</media-type>
<name>test.txt</name>
<range/>
<size>6144</size>
<hash xmlns='urn:xmpp:hashes:2'
algo='sha-1'>w0mcJylzCn+AfvuGdqkty2+KP48=</hash>
</file>
</description>
<transport xmlns='urn:xmpp:jingle:transports:s5b:1'
mode='tcp'
sid='vj3hs98y'>
<candidate cid='hft54dqy'
host='192.168.4.1'
jid='romeo@montague.example/dr4hcr0st3lup4c'
port='5086'
priority='8257636'
type='direct'/>
</transport>
<security xmlns='urn:xmpp:jingle:jet:0'
name='a-file-offer'
cipher='urn:xmpp:ciphers:aes-128-gcm-nopadding'
type='eu.siacs.conversations.axolotl'>
<encrypted xmlns='eu.siacs.conversations.axolotl'>
<header sid='27183'>
<key rid='31415'>BASE64ENCODED...</key>
<key prekey="true" rid='12321'>BASE64ENCODED...</key>
<!-- ... -->
<iv>BASE64ENCODED...</iv>
</header>
</encrypted>
</security>
</content>
</jingle>
</iq>]]></example>
<p>The recipient decrypts the OMEMO KeyTransportElement to retrieve the Transport Secret. Transport Key and Initialization Vector are later used to encrypt/decrypt data as described in &xep0391;.</p>
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>To advertise its support for JET-OMEMO, when replying to service discovery information ("disco#info") requests an entity MUST return URNs for any version of this extension, as well as of the JET extension that the entity supports -- e.g., "urn:xmpp:jingle:jet-omemo:0" for this version, or "urn:xmpp:jingle:jet:0" for &xep0391; &VNOTE;.</p>
<example caption="Service discovery information request"><![CDATA[
<iq from='romeo@montague.example/dr4hcr0st3lup4c'
id='uw72g176'
to='juliet@capulet.example/yn0cl4bnw0yr3vym'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>]]></example>
<example caption="Service discovery information response"><![CDATA[
<iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
id='uw72g176'
to='romeo@montague.example/dr4hcr0st3lup4c'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:jingle:jet:0'/>
<feature var='urn:xmpp:jingle:jet-omemo:0'/>
</query>
</iq>]]></example>
<p>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 &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
</section1>
</xep>

View File

@ -20,6 +20,7 @@
<spec>XMPP Core</spec> <spec>XMPP Core</spec>
<spec>XEP-0004</spec> <spec>XEP-0004</spec>
<spec>XEP-0030</spec> <spec>XEP-0030</spec>
<spec>XEP-0059</spec>
<spec>XEP-0068</spec> <spec>XEP-0068</spec>
<spec>XEP-0082</spec> <spec>XEP-0082</spec>
<spec>XEP-0131</spec> <spec>XEP-0131</spec>
@ -49,6 +50,12 @@
&stpeter; &stpeter;
&ralphm; &ralphm;
<revision>
<version>1.13.8</version>
<date>2017-10-10</date>
<initials>fs (XEP Editor: jwi)</initials>
<remark><p>Add missing dependency on XEP-0059.</p></remark>
</revision>
<revision> <revision>
<version>1.13.7</version> <version>1.13.7</version>
<date>2017-08-24</date> <date>2017-08-24</date>