End-to-end encryption can easily be used to protect most of the communication nowadays.
However, the management of trust in long-term keys used for encryption is still a manual task.
With ATM, many steps that can be automated for the trust management are no longer a manual task the users have to take care of.
</p>
<p>
ATM reduces the steps needed for authenticating or distrusting keys of endpoints between two identities (XMPP accounts / bare JIDs).
It uses &xep0434; for automatically establishing secure channels protected against active attacks between a new endpoint and existing ones after an initial mutual authentication between the new endpoint and one of the existing ones.
</p>
<p>
Trust messages are sent encrypted only to endpoints with authenticated keys.
ATM preserves the security level as if all endpoints of the two identities authenticated or distrusted their keys manually.
If a trust message contains authentication and distrusting parts, the term authentication message is used for referring to the trust message without the distrusting parts.
If a trust message contains authentication and distrusting parts, the term distrust message is used for referring to the trust message without the authentication parts.
</dd>
</di>
</dl>
</section1>
<section1topic='Details'anchor='details'>
<p>
The goal of key authentication is to create an end-to-end encrypted communication network exclusively of endpoints with authenticated keys.
As a result, every communication channel between those endpoints is resistant against active attacks.
The network of endpoints that authenticated each other's keys can be seen as a complete graph where each endpoint is a node and each mutual authentication is an edge.
The number of edges grows for each new endpoint by the number of existing nodes.
This is due to the fact that in order to sustain secure channels between all endpoints, a new key has to be authenticated by all n existing endpoints and vice versa.
</p>
<p>
One of those n mutual authentications requires a third party or user interaction like scanning each other's QR code or comparing each other's key identifier by hand.
That is the initial mutual authentication.
A trusted third party MAY be used for the initial authentication but a manual authentication SHOULD be preferred since it does not depend on the trust in the third party.
The remaining authentications can be automated relying on the secure channel established by the initial mutual authentication and the secure channels already created by the same procedure between the rest of the endpoints.
</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 ATM, only T(n) = n-1 ∊ O(n) of them have to be made as initial mutual authentications.
All remaining authentications can be performed automatically by ATM.
Thus, less user interaction is needed for authenticating all keys involved in the secure communication while preserving the same security level as the manual authentication.
The examples contain &xep0384; as the encryption protocol because it uses one key per endpoint of the same identity.
Nevertheless, other encryption protocols MAY be used as stated in &xep0434;.
</p>
<p>
If the encryption protocol used with ATM involves only one key for all endpoints of the same identity, only the use cases for authenticating and distrusting keys of a contact's endpoint are relevant.
Those use cases are marked with OOK for <em>only one key</em>.
Additionally, the trust messages are always sent to own endpoints because they use the same key as the sending endpoint.
Therefore, the parts <em>..., to each (other) own endpoint with an already authenticated key.</em> and <em>... as soon as X authenticated Y's key</em> are not of interest.
</p>
<p>
Note that the examples in the following use cases are consecutive and therefore must be read chronologically to properly understand them.
<section4topic='From Own Endpoint (OOK)'anchor='use-case-authentication-contact-endpoint-receiving-from-own-endpoint'>
<p>
... an own endpoint ...
</p>
<p>
Example:
A2 authenticates B1's key by the authentication message from A1 (see <linkurl='#example-1'>Example 1</link> for the corresponding authentication message) as soon as A2 authenticated A1's key.
B1 authenticates A2's key by the authentication message from A1 (see <linkurl='#example-2'>Example 2</link> for the corresponding authentication message) as soon as B1 authenticated A1's key.
An endpoint that receives an authentication message for a key of an own endpoint from another own endpoint MUST authenticate the key as soon as the receiving endpoint authenticated the key of the endpoint that sent the authentication message.
A1 authenticates A3's key by the authentication message from A2 (see <linkurl='#example-3'>Example 3</link> or <linkurl='#example-4'>Example 4</link> for the corresponding authentication message) as soon as A1 authenticated A2's key.
</p>
</section3>
</section2>
<section2topic='Distrusting the Key of an Own Endpoint'anchor='use-case-distrusting-own-endpoint'>
An endpoint that initially distrusts the key of an own endpoint MUST send a distrust message for that key to each other endpoint with an already authenticated key.
An endpoint that receives a distrust message for a key of an own endpoint from another own endpoint MUST distrust the key as soon as the receiving endpoint authenticated the key of the endpoint that sent the distrust message.
A2 distrusts A3's key by the distrust message from A1 (see <linkurl='#example-6'>Example 6</link> or <linkurl='#example-7'>Example 7</link> for the corresponding distrust message) as soon as A2 authenticated A1's key.
</p>
</section3>
</section2>
<section2topic='Distrusting the Key of a Contact's Endpoint'anchor='use-case-distrusting-contact-endpoint'>
An endpoint that distrusts the key of a contact's endpoint MUST send a distrust message for that key to each other own endpoint with an authenticated key.
B1 distrusts A3's key by the distrust message from A1 (see <linkurl='#example-6'>Example 6</link> for the corresponding distrust message) as soon as B1 authenticated A1's key.
</p>
</section4>
<section4topic='From Own Endpoint (OOK)'anchor='use-case-distrusting-contact-endpoint-receiving-from-own-endpoint'>
<p>
... or an own endpoint ...
</p>
<p>
Example:
A2 distrusts B1's key by the distrust message from A1 (see <linkurl='#example-8'>Example 8</link>) as soon as A2 authenticated A1's key.
<section2topic='Storing Trust Message Information from Endpoints with Unauthenticated Keys'anchor='implementation-notes-storing-trust-message-information-unauthenticated-keys'>
A client MUST save the information of a trust message until the key of the endpoint that sent the trust message is authenticated, so that the key can then be authenticated or revoked.
Storing data of a trust message from an endpoint with an unauthenticated key is necessary because the receiving endpoint can only use that data after authenticating the sending endpoint's key and that data might not be received again.
Afterwards the information of the trust message MAY be deleted.
</p>
<p>
Example:
When Alice's endpoint A1 authenticates the key of Bob's endpoint B1, A1 sends a trust message containing the keys of Alice's other endpoint 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>
<section2topic='Storing Trust Message Information for Unknown Keys'anchor='implementation-notes-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 endpoint A1 receives an authentication message from Bob's endpoint B1.
That authentication message contains the key for Bob's other endpoint 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.
<section2topic='Notification and Confirmation'anchor='security-considerations-notification-and-confirmation'>
<p>
After a successful authentication or distrusting, 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 distrusting is performed.
</p>
</section2>
<section2topic='Recommended Security Policy - Trust Only Authenticated Keys After First Authentication (TOAKAFA)'anchor='security-considerations-recommended-security-policy-trust-only-authenticated-keys-after-first-authentication-toakafa'>
<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 endpoint, it is RECOMMENDED to automatically trust new keys until the first authentication has been made.
</p>
<p>
Even ATM cannot protect the user against an attacker with an automatically trusted and undetected malicious key.
For this reason it is important to take special care of the following security aspects.
If keys are automatically trusted until the first authentication, keys that are not authenticated by then SHOULD NOT be used any longer for encryption until they have been authenticated too.
New keys SHOULD 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.
