mirror of https://github.com/moparisthebest/xeps
432 lines
21 KiB
XML
432 lines
21 KiB
XML
<?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 <<link url='https://xmpp.org/extensions/xep-0384.html#glossary-general'>https://xmpp.org/extensions/xep-0384.html#glossary-general</link>>.</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-22</date>
|
|
<initials>mk</initials>
|
|
<remark><p>First draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>
|
|
ATT is used in conjunction with &xep0384; 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 an ordinary OMEMO message is used for transferring the information needed to authenticate a public identity key or revoke the trust in that key.
|
|
Additionally, it preserves the anonymity of the authentication and revocation since those messages are only sent to devices with authenticated public identity keys.
|
|
That means an attacker cannot detect whether an authentication or revocation took place.
|
|
</p>
|
|
<p>
|
|
End-to-end encryption without verifying the authenticity of the exchanged public identity keys only enables users to protect their communication against passive attacks.
|
|
This means an attacker cannot read encrypted messages in transit without actively intervening in the key exchange.
|
|
However, without any other precautions active attacks are still possible.
|
|
If an attacker replaces the exchanged keys with malicious ones, the end-to-end encrypted messages can be read and manipulated by the attacker.
|
|
</p>
|
|
<p>
|
|
When using OMEMO, 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 unique identity key.
|
|
For that reason it is not necessary to copy an existing private identity key to a new device enabling it to use end-to-end encryption.
|
|
Additionally, it can be used to stop encrypting for a specific device.
|
|
For example, that could be done automatically after a given number of sent messages without any reaction from the receiving device that would forward the double ratchet to ensure forward and backward secrecy.
|
|
</p>
|
|
<p>
|
|
However, the downside of that approach is that it increases the number of key authentications users need to do for each new device to be protected against active attacks.
|
|
Without ATT all n-1 mutual authentications per new key have to be done manually.
|
|
With ATT though, only one mutual manual authentication per new key is required.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Glossary' anchor='glossary'>
|
|
<dl>
|
|
<di>
|
|
<dt>OMEMO message</dt>
|
|
<dd>Message encrypted using 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>Verification 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., via ATT)</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Mutual key authentication</dt>
|
|
<dd>Key authentication in which two devices authenticate each other's key</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Key revocation</dt>
|
|
<dd>Revoking the trust in a key</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Manual key revocation</dt>
|
|
<dd>Key revocation with user interaction (e.g., clicking a "Revoke" button)</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Automatic key revocation</dt>
|
|
<dd>Key revocation without user interaction (e.g., via ATT)</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Trust message</dt>
|
|
<dd>
|
|
OMEMO message which indicates that specific keys can be trusted (authentication) or no longer trusted (revocation).
|
|
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.
|
|
</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Authentication message</dt>
|
|
<dd>
|
|
Trust message which only contains key identifiers for authentication.
|
|
If a trust message contains authentication and revocation parts, the term authentication message is used for referring to the trust message without revocation parts.
|
|
</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Revocation message</dt>
|
|
<dd>
|
|
Trust message which only contains key identifiers for revocation.
|
|
If a trust message contains authentication and revocation parts, the term revocation message is used for referring to the trust message without authentication parts.
|
|
</dd>
|
|
</di>
|
|
</dl>
|
|
</section1>
|
|
<section1 topic='Advantages' anchor='advantages'>
|
|
<p>
|
|
The goal of key authentication is to create an end-to-end encrypted communication network exclusively of devices with authenticated keys.
|
|
As a result every communication channel between those devices is resistant against active attacks.
|
|
</p>
|
|
<p>
|
|
The network of devices which authenticated each other's keys can be seen as a complete graph where each device is a node and each mutual authentication is an edge.
|
|
The number of edges grows for each new device by the number of existing nodes.
|
|
This is due to the fact that in order to sustain secure channels between all devices, a new key has to be authenticated by all n existing devices and vice versa.
|
|
</p>
|
|
<p>
|
|
One of those n mutual authentications requires user interaction like scanning each other's QR code or comparing each other's key identifier by hand.
|
|
That is the initial mutual manual authentication.
|
|
The remaining authentications can be automated relying on the secure channel established by the inital mutual manual authentication and the secure channels already created by the same procedure between the rest of the devices.
|
|
</p>
|
|
<p>
|
|
For creating the described complete graph with n nodes, a total of T(n) = (n*(n-1))/2 ∊ O(n²) mutual authentications are needed.
|
|
When using ATT, only T(n) = n-1 ∊ O(n) of them have to be made manually.
|
|
All remaining authentications can be performed automatically.
|
|
Thus, less user interaction is needed for authenticating all keys involved in the secure communication while preserving the same security level.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='General Procedure' anchor='general-procedure'>
|
|
<p>
|
|
This section explains the basic procedure of autmomatically authenticating or revoking a key by a trust message.
|
|
It does not specify the detailed behaviour which can be found in section <link url='#usecases'>Use Cases</link>.
|
|
Instead, this section should rather show the fundamental idea behind ATT.
|
|
</p>
|
|
<section2 topic='Authentication' anchor='general-procedure-authentication'>
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
Device 1 manually authenticates the key of device 2.
|
|
Device 1 automatically sends an authentication message for device 2's key to devices whose keys it has already authenticated and another authentication message for the keys of those devices to device 2.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Device 2 manually authenticates the key of device 1.
|
|
Device 2 automatically sends an authentication message for device 1's key to devices whose keys it has already authenticated and another authentication message for the keys of those devices to device 1.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Device 1 automatically authenticates the keys of the authentication message from device 2.
|
|
Each device receiving an authentication message from device 1 automatically authenticates device 2's key, if device 1's key has already been authenticated by it.
|
|
Each device receiving an authentication message from device 2 automatically authenticates the corresponding keys, if device 2's key has been authenticated by it.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Device 2 automatically authenticates the keys of the authentication message from device 1.
|
|
Each device receiving an authentication message from device 2 automatically authenticates device 1's key, if device 2's key has already been authenticated by it.
|
|
Each device receiving an authentication message from device 1 automatically authenticates the corresponding keys, if device 1's key has been authenticated by it.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
</section2>
|
|
<section2 topic='Revocation' anchor='general-procedure-revocation'>
|
|
<p>
|
|
Device 1 manually revokes the trust in the key of device 2.
|
|
Device 1 automatically sends a revocation message for device 2's key to devices whose keys it has already authenticated.
|
|
Each device receiving a revocation message from device 1 automatically revokes the trust in device 2's key, if device 1's key has already been authenticated by it.
|
|
</p>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Trust Message URI' anchor='trust-message-uri'>
|
|
<p>
|
|
A trust message contains an <cite>XMPP URI</cite> (see &xep0147;) 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>
|
|
</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 A2's key.
|
|
The other devices have not authenticated each other's key.
|
|
</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's Device' anchor='usecases-authentication-contact-device'>
|
|
<section3 topic='Sending' anchor='usecases-authentication-contact-device-sending'>
|
|
<p>
|
|
Example:
|
|
A1 authenticates B1's key.
|
|
</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 receiving device authenticated the key of the device which sent the authentication message.
|
|
</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:
|
|
A2 has already authenticated A1's and B1's key.
|
|
A2 authenticates A3's key.
|
|
</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:
|
|
A2 sends an authentication message for A3's key to A1 and B1.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
each already authenticated key of all devices to the device whose key has been authenticated.
|
|
</p>
|
|
<p>
|
|
Example:
|
|
A2 sends an authentication message for A1'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 receiving device authenticated the key of the device which sent the authentication message.
|
|
</p>
|
|
<p>
|
|
Example:
|
|
A1 authenticates A3's key by the authentication message from A2 as soon as A1 authenticated A2'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'>
|
|
<section2 topic='Storing Trust Message Information from Devices with Unauthenticated Keys' anchor='impl-storing-trust-message-information-unauthenticated-keys'>
|
|
<p>
|
|
A client MUST save the information of a trust message until the key of the device which sent the trust message is authenticated, so that the key can then be authenticated or revoked.
|
|
Afterwards the information of the trust message MAY be deleted.
|
|
</p>
|
|
<p>
|
|
Example:
|
|
When Alice's device A1 authenticates the key of Bob's device B1, A1 sends a trust message containing the keys of Alice's other device A2 to B1.
|
|
If B1 has not already authenticated A1's key, B1 stores the information provided by the trust message.
|
|
B1 authenticates A1's key and is then able to automatically authenticate A2's key.
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Storing Trust Message Information for Unknown Keys' anchor='impl-storing-trust-message-information-unknown-keys'>
|
|
<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>
|
|
Example:
|
|
Alice's device A1 receives an authentication message from Bob's device B1.
|
|
That authentication message contains the key for Bob's other device B2.
|
|
If A1 has not already fetched B2's key, A1 stores the information provided by the trust message.
|
|
A1 fetches B2's key and is then able to automatically authenticate A2's key.
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Reducing The Number of Trust Messages' anchor='impl-reducing-number-of-trust-messages'>
|
|
<section3 topic='Using URIs Containing Multiple Keys' anchor='impl-reducing-number-of-trust-messages-uris-multiple-keys'>
|
|
<p>
|
|
For reducing the number of trust messages sent to a device, a client MAY use a URI containing multiple keys that have been authenticated shortly after another.
|
|
</p>
|
|
<p>
|
|
Example:
|
|
Alice's device A1 authenticates the keys of Bob's devices B1 and B2 after scanning Bob's QR code containing their key identifiers.
|
|
A1 sends one authentication message for all of the authenticated keys.
|
|
</p>
|
|
</section3>
|
|
<section3 topic='Using Message Carbons' anchor='impl-reducing-number-of-trust-messages-message-carbons'>
|
|
<p>
|
|
Furthermore, a client MAY use &xep0280; for sending a trust message to all devices of a contact or to all own devices at once.
|
|
Then, by sending a trust message to the contact, each device of the contact and each own device gets the same trust message by the server.
|
|
Thus, a client needs to send the same trust message only once.
|
|
If not all devices of the contact should receive the trust message, the trust message MAY be sent to specific devices of the contact but for all own devices Message Carbons MAY be used and vice versa.
|
|
Even when a client does not already have a contact, the client MAY use Message Carbons for delivering a trust message to all own devices.
|
|
</p>
|
|
<p>
|
|
Example:
|
|
Alice's device A1 authenticates the key of her device A2.
|
|
A1 sends the trust message for A2's key only once to all of Alice's and Bob's devices by using Message Carbons.
|
|
</p>
|
|
<p>
|
|
Attention:
|
|
In that context, sending a trust message to all devices of a contact or to all own devices does not mean to encrypt it with the keys of all those devices.
|
|
Instead, it only means that all of those devices should receive the trust message even if it is not encrypted for some of them and thereby not decryptable by those devices.
|
|
Keep in mind that a trust message MUST only be encrypted for devices with authenticated keys.
|
|
</p>
|
|
<p>
|
|
The drawback of using Message Carbons is that clients may show a message to the user that an OMEMO message received which has not been encrypted for the corresponding device.
|
|
</p>
|
|
</section3>
|
|
</section2>
|
|
</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>
|