XEP-0450: Automatic Trust Management (ATM)

Abstract
This document specifies a way to automatically manage the trust in public long-term keys used by end-to-end encryption protocols.
Author
Melvin Keskin
Copyright
© 1999 – 2020 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

Experimental

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.
Type
Standards Track
Version
0.2.0 (2021-04-13)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Draft
  4. Final

1. Introduction

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.

ATM reduces the steps needed for authenticating or distrusting keys of endpoints between two identities (XMPP accounts / bare JIDs). It uses Trust Messages (XEP-0434) [1] 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.

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. It can be used especially for end-to-end encryption protocols such as OMEMO Encryption (XEP-0384) [2] that use one key per endpoint of the same identity.

2. Glossary

External glossary
The terms of Trust Messages (XEP-0434) [1]'s glossary are also relevant for this XEP.
Manual key authentication
Key authentication with user interaction (e.g., QR code scanning, fingerprint verification)
Automatic key authentication
Key authentication without user interaction (e.g., via ATM)
Initial key authentication
Key authentication needed for all further automatic key authentications made by ATM
Mutual key authentication
Key authentication in which two endpoints authenticate each other's key
Key distrusting
Revoking the trust in a key
Manual key distrusting
Key distrusting with user interaction (e.g., clicking a "Distrust" button)
Automatic key distrusting
Key distrusting without user interaction (e.g., via ATM)
Authentication message
Trust message that only contains key identifiers for authentication. 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.
Distrust message
Trust message that only contains key identifiers for distrusting. 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.

3. Details

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.

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.

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.

4. Use Cases

Everything that is RECOMMENDED by Trust Messages (XEP-0434) [1] MUST be applied. Trust Message URIs as specified by Trust Messages (XEP-0434) [1] SHOULD be used for the initial authentications.

The examples contain OMEMO Encryption (XEP-0384) [2] 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 Trust Messages (XEP-0434) [1].

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 only one key. Additionally, the trust messages are always sent to own endpoints because they use the same key as the sending endpoint. Therefore, the parts ..., to each (other) own endpoint with an already authenticated key. and ... as soon as X authenticated Y's key are not of interest.

Note that the examples in the following use cases are consecutive and therefore must be read chronologically to properly understand them. Since ATM uses Stanza Content Encryption (XEP-0420) [3], only the SCE <content/> elements are shown.

Alice would like to use OMEMO when communicating with Bob. Alice has the endpoints A1, A2 and A3. Bob has the endpoint B1. A1 has already authenticated A2's key. The other endpoints have not authenticated each other's key.

4.1 Authenticating the Key of a Contact's Endpoint

4.1.1 Sending

Example: Remember that A1 has already authenticated A2's key. A1 authenticates B1's key.

An endpoint that initially authenticates the key of a contact's endpoint MUST send an authentication message for ...

4.1.1.1 To Own Endpoints (OOK)

... the key that has been authenticated, to each own endpoint with an already authenticated key.

Example 1. A1 sends an authentication message for B1's key to A2
<content xmlns='urn:xmpp:sce:0'>
  <rpad>QHqW2arWFewoERL1a43wonBKpTmsrBWnc1d66HSDq85NgMLmjrDJV9lV</rpad>
  <time stamp='2020-01-01T12:00:00'/>
  <from jid='alice@example.org/A1'/>
  <to jid='alice@example.org'/>
  <payload>
    <trust-message xmlns='urn:xmpp:trust-messages:0' usage='urn:xmpp:atm:0' encryption='urn:xmpp:omemo:1'>
      <key-owner jid='bob@example.com'>
        <trust>623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f</trust>
      </key-owner>
    </trust-message>
  </payload>
</content>
4.1.1.2 To Contact's Endpoint

... each already authenticated key of all own endpoints, to the endpoint whose key has been authenticated.

Example 2. A1 sends an authentication message for A2's key to B1
<content xmlns='urn:xmpp:sce:0'>
  <rpad>Wvj25aDkNbAnSxMIDQo1pjIKRowIMGrF72hSJeXS</rpad>
  <time stamp='2020-01-01T12:00:01'/>
  <from jid='alice@example.org/A1'/>
  <to jid='bob@example.org'/>
  <payload>
    <trust-message xmlns='urn:xmpp:trust-messages:0' usage='urn:xmpp:atm:0' encryption='urn:xmpp:omemo:1'>
      <key-owner jid='alice@example.org'>
        <trust>6850019d7ed0feb6d3823072498ceb4f616c6025586f8f666dc6b9c81ef7e0a4</trust>
      </key-owner>
    </trust-message>
  </payload>
</content>

4.1.2 Receiving

An endpoint that receives an authentication message for a key of a contact's endpoint from ...

4.1.2.1 From Own Endpoint (OOK)

... an own endpoint ...

Example: A2 authenticates B1's key by the authentication message from A1 (see Example 1 for the corresponding authentication message) as soon as A2 authenticated A1's key.

4.1.2.2 From Contact's Endpoint

... or another endpoint of that contact ...

Example: B1 authenticates A2's key by the authentication message from A1 (see Example 2 for the corresponding authentication message) as soon as B1 authenticated A1's key.

... MUST authenticate the key as soon as the receiving endpoint authenticated the key of the endpoint that sent the authentication message.

4.2 Authenticating the Key of an Own Endpoint

4.2.1 Sending

Example: Remember that A2 has already authenticated A1's and B1's key. A2 authenticates A3's key.

An endpoint that initially authenticates the key of an own endpoint MUST send an authentication message for ...

4.2.1.1 To All Other Endpoints

... the key that has been authenticated to each other endpoint with an already authenticated key.

Example 3. A2 sends an authentication message for A3's key to B1 and by using Message Carbons also to A1
<content xmlns='urn:xmpp:sce:0'>
  <rpad>O2vRKkmtsXsKSk2hPDkrpQQ4Og272qFGB1Srp64vaDrMTNhrV6</rpad>
  <time stamp='2020-01-01T14:00:01'/>
  <from jid='alice@example.org/A2'/>
  <to jid='bob@example.org'/>
  <payload>
    <trust-message xmlns='urn:xmpp:trust-messages:0' usage='urn:xmpp:atm:0' encryption='urn:xmpp:omemo:1'>
      <key-owner jid='alice@example.org'>
        <trust>221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020</trust>
      </key-owner>
    </trust-message>
  </payload>
</content>
Example 4. A2 would send an authentication message for A3's key only to A1 if there were no contacts with authenticated keys
<content xmlns='urn:xmpp:sce:0'>
  <rpad>s5jP95kvpRNg92XLLo8OkLCvUDT53S</rpad>
  <time stamp='2020-01-01T14:00:00'/>
  <from jid='alice@example.org/A2'/>
  <to jid='alice@example.org'/>
  <payload>
    <trust-message xmlns='urn:xmpp:trust-messages:0' usage='urn:xmpp:atm:0' encryption='urn:xmpp:omemo:1'>
      <key-owner jid='alice@example.org'>
        <trust>221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020</trust>
      </key-owner>
    </trust-message>
  </payload>
</content>
4.2.1.2 To Endpoint Whose Key Has Been Authenticated

... each already authenticated key of all endpoints to the endpoint whose key has been authenticated.

Example 5. A2 sends an authentication message for A1's and B1's key to A3
<content xmlns='urn:xmpp:sce:0'>
  <rpad>98WA6U92twcVkAXM44UU</rpad>
  <time stamp='2020-01-01T14:00:02'/>
  <from jid='alice@example.org/A2'/>
  <to jid='bob@example.org'/>
  <payload>
    <trust-message xmlns='urn:xmpp:trust-messages:0' usage='urn:xmpp:atm:0' encryption='urn:xmpp:omemo:1'>
      <key-owner jid='alice@example.org'>
        <trust>f3cddd91f25502652483be2fd5faaaa00f80868ac0d51d7eebb1b08a3892e33d</trust>
      </key-owner>
      <key-owner jid='bob@example.com'>
        <trust>623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f</trust>
      </key-owner>
    </trust-message>
  </payload>
</content>

4.2.2 Receiving

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.

Example: A1 authenticates A3's key by the authentication message from A2 (see Example 3 or Example 4 for the corresponding authentication message) as soon as A1 authenticated A2's key.

4.3 Distrusting the Key of an Own Endpoint

4.3.1 Sending

Example: Remember that A1 has already authenticated A2's, A3's and B1's key. A1 distrusts A3's key.

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.

Example 6. A1 sends a distrust message for A3's key to B1 and by using Message Carbons also to A2
<content xmlns='urn:xmpp:sce:0'>
  <rpad>NF5MOJdt8TBbItt4AHXOUKWncRmw5B</rpad>
  <time stamp='2020-01-01T16:00:01'/>
  <from jid='alice@example.org/A1'/>
  <to jid='bob@example.org'/>
  <payload>
    <trust-message xmlns='urn:xmpp:trust-messages:0' usage='urn:xmpp:atm:0' encryption='urn:xmpp:omemo:1'>
      <key-owner jid='alice@example.org'>
        <distrust>221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020</distrust>
      </key-owner>
    </trust-message>
  </payload>
</content>
Example 7. A1 would send a distrust message for A3's key only to A2 if there were no contacts with authenticated keys
<content xmlns='urn:xmpp:sce:0'>
  <rpad>798BFSTQqPjVtiLok3EGtQ7VgB3GGP7eT9P4FhO5</rpad>
  <time stamp='2020-01-01T16:00:00'/>
  <from jid='alice@example.org/A1'/>
  <to jid='alice@example.org'/>
  <payload>
    <trust-message xmlns='urn:xmpp:trust-messages:0' usage='urn:xmpp:atm:0' encryption='urn:xmpp:omemo:1'>
      <key-owner jid='alice@example.org'>
        <distrust>221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020</distrust>
      </key-owner>
    </trust-message>
  </payload>
</content>

4.3.2 Receiving

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.

Example: A2 distrusts A3's key by the distrust message from A1 (see Example 6 or Example 7 for the corresponding distrust message) as soon as A2 authenticated A1's key.

4.4 Distrusting the Key of a Contact's Endpoint

4.4.1 Sending (OOK)

Example: Remember that A1 has already authenticated A2's and B1's key but distrusted A3's key. A1 distrusts B1's key.

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.

Example 8. A1 sends a distrust message for B1's key to A2
<content xmlns='urn:xmpp:sce:0'>
  <rpad>x4LJDawLHgnTJRC7T1mndKEQLPR658NQmXAPQRVnhM1QQ861ve</rpad>
  <time stamp='2020-01-01T18:00:00'/>
  <from jid='alice@example.org/A1'/>
  <to jid='alice@example.org'/>
  <payload>
    <trust-message xmlns='urn:xmpp:trust-messages:0' usage='urn:xmpp:atm:0' encryption='urn:xmpp:omemo:1'>
      <key-owner jid='bob@example.com'>
        <distrust>623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f</distrust>
      </key-owner>
    </trust-message>
  </payload>
</content>

4.4.2 Receiving

An endpoint that receives a distrust message for a key of a contact's endpoint from ...

4.4.2.1 From Contact's Endpoint

... another endpoint of that contact ...

Example: B1 distrusts A3's key by the distrust message from A1 (see Example 6 for the corresponding distrust message) as soon as B1 authenticated A1's key.

4.4.2.2 From Own Endpoint (OOK)

... or an own endpoint ...

Example: A2 distrusts B1's key by the distrust message from A1 (see Example 8) as soon as A2 authenticated A1's key.

... MUST distrust the key as soon as the receiving endpoint authenticated the key of the endpoint that sent the distrust message.

5. Implementation Notes

5.1 Storing Trust Message Information from Endpoints with 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.

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.

5.2 Storing Trust Message Information for Unknown Keys

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.

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.

5.3 GUI Considerations

A client that receives a trust message SHOULD NOT display its bare content to the user. Instead, the trust message SHOULD be hidden and the automatic authentication or distrusting SHOULD take place in the background.

6. Security Considerations

6.1 Notification and Confirmation

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.

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.

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.

7. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA).

8. XMPP Registrar Considerations

8.1 Protocol Namespaces

This specification defines the following XMPP namespaces:

8.2 Protocol Versioning

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.


Appendices

Appendix A: Document Information

Series
XEP
Number
0450
Publisher
XMPP Standards Foundation
Status
Experimental
Type
Standards Track
Version
0.2.0
Last Updated
2021-04-13
Approving Body
XMPP Council
Dependencies
XMPP Core, XEP-0001, XEP-0280, XEP-0334, XEP-0420, XEP-0434
Supersedes
None
Superseded By
None
Short Name
ATM
Source Control
HTML

This document in other formats: XML  PDF

Appendix B: Author Information

Melvin Keskin
Email
melvo@olomono.de
JabberID
melvo@olomono.de

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

Appendix D: Relation to XMPP

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.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. XEP-0434: Trust Messages <https://xmpp.org/extensions/xep-0434.html>.

2. XEP-0384: OMEMO Encryption <https://xmpp.org/extensions/xep-0384.html>.

3. XEP-0420: Stanza Content Encryption <https://xmpp.org/extensions/xep-0420.html>.

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

  1. Version 0.2.0 (2021-04-13)

    Add usage of Trust Message URIs, use more precise sentences, apply consistent formatting:

    melvo
  2. Version 0.1.0 (2020-12-15)
    Accepted by vote of Council on 2020-12-02
    XEP Editor (jsc)
  3. Version 0.0.1 (2020-11-05)

    First draft

    melvo

END

Appendix I: Bib(La)TeX Entry

@report{keskin2020ATM,
  title = {Automatic Trust Management (ATM)},
  version = {0.2.0},
  type = {XEP},
  number = {0450},
  author = {Keskin, Melvin},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0450.html},
  date = {2020-11-05/2021-04-13},
}