moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

ProtoXEP Automatic Trust Transfer: First draft

Browse Source
This commit is contained in:
Melvin Keskin 2019-03-03 22:53:33 +01:00
parent f8075873f6
commit df74d74379
1 changed files with 340 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

340
inbox/automatic-trust-transfer.xml Normal file
View File

@ -0,0 +1,340 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
<!ENTITY omemo-glossary "<span class='ref'><link url='https://xmpp.org/extensions/xep-0384.html#glossary-general'>OMEMO glossary</link></span> <note>OMEMO glossary &lt;<link url='https://xmpp.org/extensions/xep-0384.html#glossary-general'>https://xmpp.org/extensions/xep-0384.html#glossary-general</link>&gt;.</note>" >
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Automatic Trust Transfer (ATT)</title>
<abstract>
ATT specifies an automatic transfer of trust in public identity keys used by the end-to-end encryption protocol OMEMO.
</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0001</spec>
<spec>XEP-0147</spec>
<spec>XEP-0384</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<author>
<firstname>Melvin</firstname>
<surname>Keskin</surname>
<email>melvo@olomono.de</email>
<jid>melvo@olomono.de</jid>
</author>
<revision>
<version>0.0.1</version>
<date>2019-03-03</date>
<initials>mk</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>
ATT is used for automatically establishing secure channels protected against active attacks between a new device and existing ones after a single mutual manual authentication between the new device and one of the existing ones.
It preserves the security level as if all devices had authenticated their keys manually.
A trusted third party is not required since a usual OMEMO message is used for transferring the information needed to authenticate a key or revoke the trust in that key.
Additionally, it will preserve the anonymity of the authentication and revocation since those messages are only sent to devices with authenticated keys.
That means that an attacker cannot detect whether an authentication or revocation took place.
</p>
<p>
End-to-end encryption without verifying the authenticity of the public keys enables users to protect their communication against passive attacks.
That means an attacker cannot read the transferred messages without manipulating the exchanged messages or key material.
But without any other precautions active attacks are still possible.
If the exchanged keys are replaced with the key of an attacker, the end-to-end encrypted messages can be read by the attacker.
</p>
<p>
When using &xep0384;, a public identity key is transmitted over a channel which is not protected against active attacks.
That key has to be authenticated by the receiving device over a channel which is protected against active attacks to maintain the confidentiality of sent OMEMO messages and ensuring the authenticity and integrity of received OMEMO messages.
</p>
<p>
When using OMEMO, each device has a different identity key.
That makes it possible for new devices to use end-to-end encryption protecting against passive attacks without transmitting the private key over a secure channel from an existing device to the new one.
However, the downside of this approach is that it increases the number of authentications.
</p>
<p>
The goal of key authentication is to build up an end-to-end encrypted communication network exclusively between devices with authenticated keys.
That network of devices trusting each other's keys can be seen as a complete graph with each device as a node and each authentication as an edge.
The number of edges grows for each new device by the number of existing nodes.
Without ATT all of those authentications have to be done manually.
With ATT though, only one mutal manual authentication is required.
</p>
<p>
This means that each communication channel between the devices is resistant against active attacks.
To sustain such a secure communication across all devices, the new key of an own device has to be authenticated by all n own devices and all m devices of a contact.
This leads to a total of n * m authentications.
Two of them require user interaction like scanning each other's QR codes or comparing the key identifiers by hand.
The remaining authentications can be automated relying on the secure channel established by the two inital authentications and the secure channels created by that procedure.
Thus, less user interaction is needed for authenticating all keys involved in the secure communication while preserving the same security level.
</p>
<p>
On the one hand, each new key has to be authenticated by a device that already belongs to the devices communicating with authenticated keys.
On the other hand, the device that introduces the new key has to authenticate the key of the device that already belongs to the devices communicating with authenticated keys.
</p>
<p>
More precisely, that means the following:
After device 1 manually authenticated the key of device 2, a message called authentication message for the key of device 2 is sent automatically from device 1 to devices with already authenticated keys.
They can use the authentication message for an automatic authentication of the key of device 2 after they authenticated the key of device 1.
</p>
<p>
When a key of an own device should not be trusted anymore by other own devices and devices of a contact, an appropriate message can be sent to those devices.
They can then revoke the trust in that key if the key of the sending device is already authenticated.
</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
<dl>
<di>
<dt>OMEMO message</dt>
<dd>Message encrypted with OMEMO</dd>
</di>
<di>
<dt>Device</dt>
<dd>See <cite>Device</cite> in &omemo-glossary;</dd>
</di>
<di>
<dt>Key</dt>
<dd>Public part of <cite>IdentityKey</cite> in &omemo-glossary;</dd>
</di>
<di>
<dt>Key identifier</dt>
<dd>Identifier for a key (e.g., a fingerprint or the key itself)</dd>
</di>
<di>
<dt>Key authentication</dt>
<dd>Verifying that a key received over an insecure channel is actually the one of the assumed device</dd>
</di>
<di>
<dt>Manual key authentication</dt>
<dd>Key authentication with user interaction (e.g., QR code scanning, fingerprint verification)</dd>
</di>
<di>
<dt>Automatic key authentication</dt>
<dd>Key authentication without user interaction (e.g., ATT)</dd>
</di>
<di>
<dt>Trust message</dt>
<dd>
OMEMO message which indicates that specific keys can be trusted or no longer trusted.
A trust message for a device's key sent to another device is a trust message that contains the key identifer of the given key for authentication or revocation.
If a trust message only contains key identifiers for authentication, it is called <cite>authentication message</cite>.
If it only contains keys identifiers for revocation, it is called <cite>revocation message</cite>.
</dd>
</di>
<di>
<dt>Authentication message</dt>
<dd>
An authentication message for a key is an OMEMO message which advises the receiving device to trust that key.
</dd>
</di>
<di>
<dt>Revocation message</dt>
<dd>
A revocation message for a key is an OMEMO message which advises the receiving device to not trust that key anymore.
</dd>
</di>
</dl>
</section1>
<section1 topic='Trust Message URI Types' anchor='trust-message'>
<section2 topic='Trust Message URI' anchor='trust-message'>
<p>
A trust message contains an XMPP URI defined by the following scheme:
</p>
<example caption='Scheme of a Trust Message URI'><![CDATA[xmpp:<bare-jid>?omemo-trust;<auth|revoke>=<key-identifier-1>;<auth|revoke>=<key-identifier-2>;<...>;<auth|revoke>=<key-identifier-n>]]></example>
<example caption='Example of a Trust Message URI'><![CDATA[xmpp:user@example.org?omemo-trust;auth=623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f;auth=d9f849b6b828309c5f2c8df4f38fd891887da5aaa24a22c50d52f69b4a80817e;revoke=b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413]]></example>
</section2>
<section2 topic='Authentication Message URI' anchor='authentication-message'>
<p>
An authentication message contains an XMPP URI defined by the following scheme:
</p>
<example caption='Scheme of an Authentication Message URI'><![CDATA[xmpp:<bare-jid>?omemo-trust;auth=<key-identifier-1>;auth=<key-identifier-2>;<...>;auth=<key-identifier-n>]]></example>
<example caption='Example of an Authentication Message URI'><![CDATA[xmpp:user@example.org?omemo-trust;auth=623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f;auth=d9f849b6b828309c5f2c8df4f38fd891887da5aaa24a22c50d52f69b4a80817e]]></example>
</section2>
<section2 topic='Revocation Message URI' anchor='revocation-message'>
<p>
A revocation message contains an XMPP URI defined by the following scheme:
</p>
<example caption='Scheme of a Revocation Message URI'><![CDATA[xmpp:<bare-jid>?omemo-trust;revoke=<key-identifier>;revoke=<key-identifier-2>;<...>;revoke=<key-identifier-n>]]></example>
<example caption='Example of a Revocation Message URI'><![CDATA[xmpp:user@example.org?omemo-trust;revoke=623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f;revoke=d9f849b6b828309c5f2c8df4f38fd891887da5aaa24a22c50d52f69b4a80817e]]></example>
</section2>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<p>
Alice would like to use OMEMO when communicating with Bob.
Alice has the devices A1, A2 and A3.
Bob has the device B1.
A1 has already authenticated the key of A2.
The other devices have not authenticated the keys of each other.
</p>
<p>
Note that the examples in the following use cases are consecutive and therefore must be read chronologically to properly understand them.
</p>
<section2 topic='Authenticating the Key of a Contact&apos;s Device' anchor='usecases-authentication-contact-device'>
<section3 topic='Sending' anchor='usecases-authentication-contact-device-sending'>
<p>
Example:
A1 authenticates the key of B1.
</p>
<p>
A device that manually authenticates the key of a contact's device MUST send an authentication message for
</p>
<ol>
<li>
<p>
the key that has been authenticated, to each own device with an already authenticated key.
</p>
<p>
Example:
A1 sends an authentication message for B1's key to A2.
</p>
</li>
<li>
<p>
each already authenticated key of all own devices, to the device whose key has been authenticated.
</p>
<p>
Example:
A1 sends an authentication message for A2's key to B1.
</p>
</li>
</ol>
</section3>
<section3 topic='Receiving' anchor='usecases-authentication-contact-device-receiving'>
<p>
A device that receives an authentication message for a key of a contact's device from
</p>
<ol>
<li>
<p>
an own device
</p>
<p>
Example:
A2 authenticates B1's key by the authentication message from A1 as soon as A2 authenticated A1's key.
</p>
</li>
<li>
<p>
or another device of that contact
</p>
<p>
Example:
B1 authenticates A2's key by the authentication message from A1 as soon as B1 authenticated A1's key.
</p>
</li>
</ol>
<p>
MUST authenticate the key as soon as the key of the author of the authentication message is authenticated by the receiving device.
</p>
</section3>
</section2>
<section2 topic='Authenticating the Key of an Own Device' anchor='usecases-authentication-own-device'>
<section3 topic='Sending' anchor='usecases-authentication-own-device-sending'>
<p>
Example:
A1 authenticates the key of A3.
</p>
<p>
A device that manually authenticates the key of an own device MUST send an authentication message for
</p>
<ol>
<li>
<p>
the key that has been authenticated to each other device with an already authenticated key.
</p>
<p>
Example:
A1 sends an authentication message for A3's key to A2 and B1.
</p>
</li>
<li>
<p>
each already authenticated key of all devices to the device whose key has been authenticated.
</p>
<p>
Example:
A1 sends an authentication message for A2's and B1's key to A3.
</p>
</li>
</ol>
</section3>
<section3 topic='Receiving' anchor='usecases-authentication-own-device-receiving'>
<p>
A device that receives an authentication message for a key of an own device from another own device MUST authenticate the key as soon as the key of the device that sent the authentication message is authenticated by the receiving device.
</p>
<p>
Example:
A2 authenticates A3's key by the authentication message from A1 as soon as A2 authenticated A1's key.
</p>
</section3>
</section2>
<section2 topic='Revoking the Trust in a Key' anchor='usecases-revocation'>
<p>
A client MAY send a revocation message for a key that is not trusted anymore by the sending client so that key will no longer be trusted by the receiving client.
A client receiving a revocation message SHOULD revoke the trust in the corresponding key.
</p>
<p>
// TODO Further discussion has to take place before finalizing this section.
</p>
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>
A client MUST save the information of a trust message until the key of the sending device of that message is authenticated, so that the key can then be authenticated or revoked.
Afterwards the information of the trust message can be deleted.
</p>
<p>
A client MUST save the information of a trust message until it has fetched the corresponding key so that the key can then be authenticated or revoked.
Afterwards the information of the trust message can be deleted.
</p>
<p>
It can happen, that device 1 manually authenticates the key of device 2 while device 1 is offline.
If then device 3 also manually authenticated the same key and sends authentication messages for it while device 1 is still offline, there would be, after device 1 got online again and sent its authentication messages, several authentication messages with the same content circulating.
That would lead to unnecessary network load.
Therefore, a client that receives an authentication message MAY stop the sending of an authentication message with the same content to the same recipients.
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<section2 topic='Notification' anchor='security-notification'>
<p>
A client that receives a trust message SHOULD NOT display its bare content to the user.
Instead, the message SHOULD be hidden and the automatic authentication or revocation SHOULD take place in the background.
After a successful authentication or revocation, the user MAY be informed of that event.
The client MAY offer an option for requesting the user's confirmation before any automatic authentication or automatic revocation is performed.
</p>
</section2>
<section2 topic='Recommended Security Policy' anchor='security-policy'>
<p>
It is more secure to be protected against passive attacks instead of not using any encryption.
If it is not possible to authenticate a key before encrypting with it but it is desired to communicate with the key's device, it is RECOMMENDED to blindly trust new keys until the first authentication has been made.
</p>
<p>
Even ATT cannot protect the user against an attacker with a blindly trusted and undetected malicious key.
For this reason it is important to take special care of the following security aspects.
</p>
<p>
If keys are blindly trusted until the first authentication, keys which are not authenticated by then MUST NOT be used any longer for encryption until they have been authenticated too.
New keys MUST also only be used for encryption after they have been authenticated.
Without these two additional precautions it is not possible to protect the user against attackers who introduced malicious keys before or after the first authentication.
</p>
</section2>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>REQUIRED.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>REQUIRED.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>REQUIRED for protocol specifications.</p>
</section1>
</xep>