Network Working Group P. M. Hallam-Baker Internet-Draft ThresholdSecrets.com Intended status: Informational 27 July 2020 Expires: 28 January 2021 Mathematical Mesh 3.0 Part XIII: Mesh Ceremonies draft-hallambaker-mesh-ceremonies-02 Abstract Ceremonies are security protocols that involve human participants as principal actors. Ceremonies for onboarding devices, establishing trust between parties and obtaining multi-factor authenticated responses from users are presented and analyzed with particular application to the Mathematical Mesh. https://mailarchive.ietf.org/arch/browse/mathmesh/ (http://whatever)Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at . Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 28 January 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Hallam-Baker Expires 28 January 2021 [Page 1] Internet-Draft Mesh Ceremonies July 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Related Specifications . . . . . . . . . . . . . . . . . 4 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 4 3. Ceremony Contexts . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Users . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Devices . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Connection Codes . . . . . . . . . . . . . . . . . . . . 6 3.4. Networks . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4.1. Wired Network Configuration . . . . . . . . . . . . . 7 3.4.2. WiFi Configuration . . . . . . . . . . . . . . . . . 7 3.4.3. Non-IP Configuration . . . . . . . . . . . . . . . . 8 4. Device Onboarding Ceremonies . . . . . . . . . . . . . . . . 8 4.1. Networked Computing Device . . . . . . . . . . . . . . . 9 4.1.1. Fingerprint Comparison . . . . . . . . . . . . . . . 9 4.1.2. Out of band one-time code . . . . . . . . . . . . . . 10 4.2. Network bootstrap . . . . . . . . . . . . . . . . . . . . 11 4.2.1. Dynamic Code From Administration Device . . . . . . . 11 4.2.2. Code From Target Device . . . . . . . . . . . . . . . 12 4.3. Proxy configuration . . . . . . . . . . . . . . . . . . . 13 5. Contact Establishment Ceremonies . . . . . . . . . . . . . . 13 5.1. In Person . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Registration . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Remote . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.4. Trusted Third Party Endorsement . . . . . . . . . . . . . 17 6. Authentication Ceremonies . . . . . . . . . . . . . . . . . . 17 6.1. Confirmation . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Confirmation with Personal Presence . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 10. Normative References . . . . . . . . . . . . . . . . . . . . 20 11. Informative References . . . . . . . . . . . . . . . . . . . 20 1. Introduction The consideration of ceremonies as an aspect of network protocol design was introduced by Carl Ellison in 2007 [Ellison]. Since then, consideration of ceremony design has provided a bridge between security practitioners focused on network protocol and human-computer interaction. Hallam-Baker Expires 28 January 2021 [Page 2] Internet-Draft Mesh Ceremonies July 2020 While the design of ceremonies is naturally connected to the design of the user experience, the former represents an abstraction of the latter. For example, the description ceremony might require that the user be able to distinguish between two states but not how this distinction is represented in the user experience. Failure to consider ceremony design in protocol design frequently leads to the user being consider able to avoid security breaches through clairvoyance. Consider the commonly given but unactionable advice that users 'take care' when opening email attachments. On what basis is the user supposed to exercise caution when standard SMTP email provides no means for determining the authenticity of a message? Formalizing the interactions of users in a protocol allows the designers to consider if the expectations being put on the users are likely to be met. It is easy for Web site operators to exhort users to use a strong, unique password, to change it frequently and not write it down. But there is not the slightest chance that users will follow this advice except on rare occasions because it is utterly unreasonable to expect them to remember a different password for each of the hundreds of services they use. Ceremonies formalize the interactions of humans with machines, but humans are not Turing machines. They do not interact in precise ways; they misunderstand information they are provided with and they fail to follow instructions. It is essential that ceremonies be designed with these constraints in mind. This document describes the ceremonies that are used to establish trust in the Mesh: * Onboarding devices to a Mesh profile * Contact endorsement and exchange * Authenticated response interactions While these particular ceremonies were designed to meet the design requirements of the Mesh, most are based on pre-existing interaction patterns that are widely used but not necessarily considered as a ceremony. 2. Definitions This section presents the related specifications and standard, the terms that are used as terms of art within the documents and the terms used as requirements language. Hallam-Baker Expires 28 January 2021 [Page 3] Internet-Draft Mesh Ceremonies July 2020 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.2. Defined Terms 2.3. Related Specifications 2.4. Implementation Status The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer]. 3. Ceremony Contexts A Mesh ceremony provides an abstract description of the interactions between users and devices. A Ceremony context describes the specific means by which the abstract ceremony is realized. The ceremony context may be considered the equivalent of the physical layer. Just as IP packets may be transferred using Ethernet or WiFi, the short codes used in many of the onboarding ceremonies may be exchanged using QR codes, Bluetooth, Near Field Communication or any other infrastructure that provides the necessary affordances. (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-ceremonies-02.html for artwork.) Figure 1 3.1. Users It is assumed that users are of average technical skill or less and that they are unwilling to read any instructions or follow any procedure more complex than that required to purchase the target device. The fact that a user is acting in an administrative role with respect to onboarding a device does not mean that they should be assumed to have administrative privileges on the machine they are using to perform that function. Hallam-Baker Expires 28 January 2021 [Page 4] Internet-Draft Mesh Ceremonies July 2020 3.2. Devices The term 'device' is used to refer to any machine involved in the ceremony that is capable of communicating. Back at the dawn of the Internet age, every device connected to the Internet was at least the size of a washing machine that one or more users would interact with by means of a terminal device with a keyboard and either a display or a printer. The range of affordances provided by modern devices is much broader. Today's desktop workstation provides essentially the same display, input an network affordances as those of a 'Personal Computer' sold in the mid-1990s. At the other end of the device capability spectrum, a 'smart' light bulb may offer only its light as a potential output and no inputs whatsoever. Accessibility is an important consideration in contemporary systems design. Many users cannot use a traditional keyboard or display. In the interests of clarity, we refer to user text input devices as 'keyboards' and text output devices as 'displays' while recognizing that these MAY be realized using other technologies. We recognize the following categories of device: Static Computer A server or personal computer which is connected to a wired network (e.g. Ethernet). A static computer provides a keyboard and display, but not (necessarily) a camera. Mobile Computer A laptop, tablet or smartphone device which supports use of a wireless network (e.g. WiFi, Cellular). A mobile computer provides a keyboard, display and a camera. Device with Display A device which contains an embedded computer with a display affordance and some form of network communication capability (e.g. WiFi, Thread, Zigbee, Z-Wave, etc.) but not a keyboard or a camera. Black Box Device A device which contains an embedded computer with some form of network communication capability (e.g. WiFi, Thread, Zigbee, Z-Wave, etc.) that does not provide input or output affordances to the user. These capabilities are summarized as follows: Hallam-Baker Expires 28 January 2021 [Page 5] Internet-Draft Mesh Ceremonies July 2020 +=============+===========+==========+=========+===============+ | Class | Keyboard? | Display? | Camera? | Network | | | | | | Configuration | +=============+===========+==========+=========+===============+ | Static | Yes | Yes | No | Automatic | | Computer | | | | | +-------------+-----------+----------+---------+---------------+ | Mobile | Yes | Yes | Yes | Required | | Computer | | | | | +-------------+-----------+----------+---------+---------------+ | Device with | No | No | No | Required | | Display | | | | | +-------------+-----------+----------+---------+---------------+ | Black Box | No | No | No | Required | | Device | | | | | +-------------+-----------+----------+---------+---------------+ Table 1 While there is a tendency for IoT devices to become more elaborate with succeeding generations, the expansion in the scope of IoT devices more than compensates for this effect. Thus just as there are more 8-bit CPUs manufactured today than at any point in history, the number of devices in the 'black box device' category will almost certainly increase over time rather than vanish. 3.3. Connection Codes A Connection Code is a compact data object, typically 50 characters or less that is passed from one party to another during a ceremony. Connection Codes MAY take many forms according to the capabilities of the devices involved. * QR Code * Serial communication using visible or Infra-Red light. * Near Field Communications 3.4. Networks IoT devices don't necessarily support IP Local network config - sufficient to connect to the Mesh to bootstrap VPN. Hallam-Baker Expires 28 January 2021 [Page 6] Internet-Draft Mesh Ceremonies July 2020 Wired Supports automatic configuration of the local network context via DHCP WiFi Requires an SSID to be specified and in some cases a password. Non-IP A large range of wired and wireless communication protocols that provide local communication. Includes RS485, CANBUS, Zigbee, etc. 3.4.1. Wired Network Configuration Wired networks such as Ethernet provide automated network configuration via DHCP. Can use this network as-is or as a bootstrap to establish a connection through a VPN. 3.4.2. WiFi Configuration WiFi networks support DHCP but this only acts after a device has connected to the WiFi network by specifying the correct SSID and providing the necessary credentials. It is therefore necessary for an onboarding process to initialize the WiFi settings before making use of the Internet. A secondary consideration is the need to update the WiFi settings on devices after the WiFi network configuration is changed or if the device is moved from one network operated by the user to another. To support these requirements we anticipate the use of at least three separate WiFi SSIDs types: The Public Network SSID The SSID used by the network that connects to the external Internet. The Device Hailing SSID An SSID that is monitored by a target device that is not connected to a Mesh to allow it to receive inbound connection initiation requests. The Mesh Hailing SSID An SSID that is monitored by a WiFi access point to allow devices previously connected to a Mesh to reconnect. This approach allows a device that has no preconfigured WiFi network configuration to be onboarded to a user's personal Mesh. Once accepted, the device can then connect to any WiFi network connected to the user's personal Mesh listening on the Mesh hailing SSID. Hallam-Baker Expires 28 January 2021 [Page 7] Internet-Draft Mesh Ceremonies July 2020 Support for this configuration MAY be deployed at the WiFi access point(s) for the network or by deploying a separate parallel WiFi access point dedicated to serving hailing requests. [Diagram: WiFi with hailing access point] (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-ceremonies-02.html for artwork.) Figure 2 3.4.3. Non-IP Configuration Configuration of non-IP networks is similar to that for WiFi with the important exception that some form of network gateway will be required to bridge the networks. (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-ceremonies-02.html for artwork.) Figure 3 4. Device Onboarding Ceremonies Devices Target device The device being onboarded Administration device A device that has the ability to authorize onboarding of the target device and cause the necessary credentials. Capture device A device that has the ability to capture a connection code from a target device. Combination device A device that combines the administration and capture device roles. Objectives * Provide bootstrap network connectivity to the target device. * Provision administrative axiom of trust to the target device. * Establish trustworthy private keys on the target device. * Provision credentials to the target device. Hallam-Baker Expires 28 January 2021 [Page 8] Internet-Draft Mesh Ceremonies July 2020 * The exchange of credentials MUST be mutually authenticated such that credentials are issued to a device if and only if it is the intended target device and it has received the intended administrative axiom of trust. 4.1. Networked Computing Device 4.1.1. Fingerprint Comparison Primary application: Target device is a static computer. Administration and target devices are in close proximity. (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-ceremonies-02.html for artwork.) Figure 4 Target Device Prompts user to enter account address and optional PIN User on [Target Device] Enters account address into target device Target Device Requests device connection to indicated Mesh Service account address Mesh Service Returns connection verification code to Target Device Posts connection request to indicated account Target Device Presents connection verification code to user Administration Device Synchronizes account to Mesh Service, receives pending connection request [Optional] Prompts user for attention User [Administration Device] Reviews pending connection requests on administration device Verifies that connection codes match, rejects request if they do not match Accepts request Administration Device Posts result of connection request to Mesh Service Mesh Service Appends results to for collection spool. Hallam-Baker Expires 28 January 2021 [Page 9] Internet-Draft Mesh Ceremonies July 2020 Target Device Requests results of connection request Mesh Service Returns results Target Device Decrypts result and completes configuration. 4.1.2. Out of band one-time code Primary application: Target device is a static computer. Administration and target devices are not in close proximity. (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-ceremonies-02.html for artwork.) Figure 5 Chief difference is that the User on [Administration Device] Requests PIN code Administration Device Generates PIN code Reports PIN code to user Posts to administration catalog to allow other administration devices to use code for verifying connection request Mesh Service Receives administration catalog entry. Target Device Prompts user to enter account address and optional PIN User on [Target Device] Enters account address and PIN into target device Target Device Requests device connection to indicated Mesh Service account address using PIN for authentication. Mesh Service Returns connection verification code to Target Device Posts connection request to indicated account Target Device Presents connection verification code to user Administration Device Synchronizes account to Mesh Service, receives pending connection request Hallam-Baker Expires 28 January 2021 [Page 10] Internet-Draft Mesh Ceremonies July 2020 Verifies one-time code has been correctly specified, has not been expired or previously used. If so, accepts connection request as pre-approved Posts result of connection request to Mesh Service Mesh Service Appends results to for collection spool. Target Device Requests results of connection request Mesh Service Returns results Target Device Decrypts result and completes configuration. 4.2. Network bootstrap Target device does not initially have network capability. Requires code capture mechanism 4.2.1. Dynamic Code From Administration Device Requires code capture capability on target device (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-ceremonies-02.html for artwork.) Figure 6 User on Administration Device Requests device connection code display User on Target device Scans code displayed on Administration device Target Device Acquires connection code Decodes local network bootstrap configuration and connection secret from connection code Acquires access to bootstrap network Posts connection request to service using connection secret for authentication. Mesh Service Returns connection verification code to Target Device Posts connection request to indicated account Hallam-Baker Expires 28 January 2021 [Page 11] Internet-Draft Mesh Ceremonies July 2020 Administration Device Synchronizes account to Mesh Service, receives pending connection request Verifies one-time code has been correctly specified, has not been expired or previously used. If so, accepts connection request as pre-approved Posts result of connection request to Mesh Service Mesh Service Appends results to for collection spool. Target Device Requests results of connection request Mesh Service Returns results Target Device Decrypts result and completes configuration. 4.2.2. Code From Target Device Requires code capture capability on administration device Code may be dynamic or static. Dynamic provides same security as for the Admnistration device display but requires the target device to have the display affordance. Static avoids need for a display, the code is physically printed on the device itself. In this case the code is static meaning that the connection secret allowing anyone who has handled the device to hijack the connection attempt. (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-ceremonies-02.html for artwork.) Figure 7 User on Target device Requests device connection code display Target device Presents device connection code User on Administration Device Scans code displayed on Target device Administration Device Acquires connection code Decodes connection secret and device bootstrap network configuration Hallam-Baker Expires 28 January 2021 [Page 12] Internet-Draft Mesh Ceremonies July 2020 Obtains device description and presents to user [*] User on Administration Device Accepts connection Administration Device Posts result of connection to device via device bootstrap network Target Device Receives connection result from Administration device Verifies that connection result is consistent with connection code posted. The device description MAY be acquired from either * The device itself (via the Device bootstrap network) * The Internet * In either case the UDF digest of the connection secret is used to form the locator. 4.3. Proxy configuration As before except that the administration functions are divided between the administration device and a separate capture device. (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-ceremonies-02.html for artwork.) Figure 8 5. Contact Establishment Ceremonies 5.1. In Person (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-ceremonies-02.html for artwork.) Figure 9 User Alice Opens contacts app, requests contact creation Alice's Device Presents connection code User Bob Scans connection code Bob's Device Opens contacts app, acquires connection code Hallam-Baker Expires 28 January 2021 [Page 13] Internet-Draft Mesh Ceremonies July 2020 Decodes Connection Secret and Alice's account address Posts connection request message to Bob's Mesh Service using connection secret as authenticator Bob's Mesh Service Receives connection request from Bob Forwards to Alice's account address Alice's Mesh Service Receives connection request from Bob Adds to Alice's inbound message spool Alice's Device Synchronizes to Alice's Mesh Service Receives message from Bob Verifies that message is authenticated by connection secret, if not abort. Presents Bob's contact information User Alice Accepts Bob's contact Alice's Device Generates contact response for Bob posts to Alice's Mesh Service using connection secret as authenticator Alice's Mesh Service Forwards connection response to Bob's Mesh service Bob's Mesh Service Receives connection response from Alice Adds to Bob's inbound message spool. Bob's device Synchronizes to Bob's Mesh Service Receives connection response Presents contact information to Bob User Bob Accepts Alice's contact information Bob's device Adds Alice's contact information to Bob's contacts catalog Since it is easy to delete a contact entry from the catalog, users may opt to accept contact information without explicit user verification. Hallam-Baker Expires 28 January 2021 [Page 14] Internet-Draft Mesh Ceremonies July 2020 The application SHOULD capture the circumstances in which the contact was acquired including the time and place (if available). For example, if Alice meets Bob at a conference for which there is an entry in their calendar, their contacts app might make use of this information to label the connection. As with any other type of connection, an in-person connection MAY be enrolled in a notary log to provide a fixed point in time. 5.2. Registration Registration is essentially a variant of the In-Person contact exchange ceremony in which Bob establishes evidence of attendance at an event such as a conference by means of his connected mobile device. The ceremony is identical to that of the In-Person contact exchange with the Roles 'Alice' and 'Alice's Device' replaced by 'Registrar' and 'Registrar's device' respectively. Registration at one or mode physical events MAY be used by trusted third parties as the basis for providing endorsements according to their published Endorsement Policies and Practices Statements. 5.3. Remote In the remote contact exchange scenario, Alice and Bob are not present in the same physical location and thus the risk of impersonation is inevitably increased. Despite this limitation, remote contact exchange allows participants to determine that they are interacting with the same person as in previous interactions. Which is sufficient for a wide number of purposes. (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-ceremonies-02.html for artwork.) Figure 10 Alice Receives Bob's Account Address out of band Opens contact management application Requests remote contact establishment with the user at Bob's Account address. Alice's Device Creates and signs the contact establishment request. Alice's Service Receives contact establishment request Hallam-Baker Expires 28 January 2021 [Page 15] Internet-Draft Mesh Ceremonies July 2020 Signs request and forwards to Bob's Service. Bob's Service Receives contact establishment request Verifies signature of Alice's Service, rejects if invalid Adds request to Bob's inbound spool. Bob's Device Synchronizes to Bob's Service Decrypts request Verifies signature of Alice's request, rejects if invalid, rejects if insufficiently authorized according to policy (i.e. spam prevention). Notifies Bob of pending request according to previously specified policy. Bob Reviews request from Alice Accepts or rejects request. Bob's Device If reject, abort. Otherwise add contact to Bob's contact catalog. Create and sign contact request for Alice including proof of knowledge of request secret. Bob's Service Receives contact establishment request Signs request and forwards to Alice's Service. Alice's Service Receives contact establishment request Verifies signature of Bob's Service, rejects if invalid Adds request to Alice's inbound spool. Alice's Device Synchronizes to Alice's Service Decrypts request Verifies signature of Bob's request, rejects if invalid, rejects if insufficiently authorized according to policy (i.e. spam prevention). Hallam-Baker Expires 28 January 2021 [Page 16] Internet-Draft Mesh Ceremonies July 2020 Verifies proof of knowledge of request secret. If invalid, ignore. Add's contact to Alice's contact catalog. 5.4. Trusted Third Party Endorsement Trusted third party endorsement MAY be used to improve the reliability of either the in-person or remote contact establishment ceremonies. (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-ceremonies-02.html for artwork.) Figure 11 The ceremony mechanics are unaffected except at the point where the contact information is accepted when the information from one (or more) trusted third parties MAY be presented to the user to assist them in their decision to accept or reject the contact information. Trusted Third Parties MAY provide an ongoing service, advising users of a change in the trustworthiness of contact data. 6. Authentication Ceremonies Second factor authentication by means of entering a one time code is widely used despite the obvious limitations of this approach: * A response code of four, six or even eight digits has a miniscule work factor compared to the industry benchmark of 2^(128) or greater. * The process of presenting a code is vulnerable to Man in the Middle attack. * Response codes are not bound to the context in which they are used and thus do not provide for non-repudiability. Modern mobile devices are both ubiquitous and offer sufficient affordances to provide user experience that is more satisfactory and offers substantially greater security. 6.1. Confirmation (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-ceremonies-02.html for artwork.) Hallam-Baker Expires 28 January 2021 [Page 17] Internet-Draft Mesh Ceremonies July 2020 Figure 12 Alice Attempts action requiring confirmation at Carol's Cloud Carol's Cloud Generates and signs confirmation request for Alice's Account Address Sends to Carol's Service Carol's Service Countersigns confirmation request and forwards to Alice's Service Alice's Service Verifies countersignature of Carol's service, if invalid, aborts Adds confirmation request to Alice's inbound spool. Alice's Device Synchronizes to Alice's Service Discards messages that are unauthorized according to entries in contacts catalog Decrypts confirmation request Notifies Alice according to policy. Alice Reads confirmation request Responds with Accept or Reject. Alice's Device Creates and signs/encrypts response including request data Appends to confirmation catalog. Forwards response to Alice's Service. Alice's Service Countersigns response, forwards to Carol's Service Carol's Service Verifies counter signature, rejects if invalid Appends response to Carol's inbound spool. Carol's Device Synchronizes to service. Decrypts response, acts accordingly. Hallam-Baker Expires 28 January 2021 [Page 18] Internet-Draft Mesh Ceremonies July 2020 Waiting for the response from Alice is essentially equivalent to waiting for input from Alice This description assumes that the devices poll the service to obtain notification of updates. Provision for push notifications will of course improve response. 6.2. Confirmation with Personal Presence In certain situations we would like to require that Alice be physically present when responding to a confirmation request. For example, when opening a door or logging in to a workstation at a facility. In these circumstances, a confirmation code is used to provide evidence that Alice is in the physical vicinity. Such codes may be presented by means of a QR code, Near Field Communications or any equivalent means. Noting of course that all proximity controls are inherently vulnerable to a relay attack. (Artwork only available as svg: No external link available, see draft-hallambaker-mesh-ceremonies-02.html for artwork.) Figure 13 Alice Attempts action requiring confirmation with physical presence at Dave's Door Dave's Door Generates unique connection code. Generates and signs confirmation request for Alice's Account Address Sends to Dave's Service Presents connection code to Alice's Device via local channel Alice's Device Reads Connection code Synchronizes to Alice's Service, no message pending (yet), waits. Dave's Service Countersigns confirmation request and forwards to Alice's Service Alice's Service Verifies countersignature of Dave's service, if invalid, aborts Adds confirmation request to Alice's inbound spool. Hallam-Baker Expires 28 January 2021 [Page 19] Internet-Draft Mesh Ceremonies July 2020 Alice's Device Synchronizes to Alice's Service Discards messages that are unauthorized according to entries in contacts catalog Decrypts confirmation request Notifies Alice according to policy. Alice Reads confirmation request Responds with Accept or Reject. Alice's Device Creates and signs/encrypts response including request data Appends to confirmation catalog. Forwards response to Alice's Service. Alice's Service Countersigns response, forwards to Dave's Service Dave's Service Verifies counter signature, rejects if invalid Appends response to Dave's inbound spool. Dave's Door Synchronizes to service. Decrypts response, acts accordingly. 7. Security Considerations 8. IANA Considerations This document requires no IANA actions. 9. Acknowledgements 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 11. Informative References Hallam-Baker Expires 28 January 2021 [Page 20] Internet-Draft Mesh Ceremonies July 2020 [draft-hallambaker-mesh-developer] Hallam-Baker, P., "Mathematical Mesh: Reference Implementation", Work in Progress, Internet-Draft, draft- hallambaker-mesh-developer-09, 23 October 2019, . [Ellison] Ellison, C., "Ceremony Design and Analysis", 2007. Hallam-Baker Expires 28 January 2021 [Page 21]