| Internet-Draft | Mesh Ceremonies | July 2020 |
| Hallam-Baker | Expires 28 January 2021 | [Page] |
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/Discussion of this draft should take place on the MathMesh mailing list (mathmesh@ietf.org), which is archived at .¶
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 (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.¶
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.¶
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:¶
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.¶
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.¶
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].¶
The implementation status of the reference code base is described in the companion document [draft-hallambaker-mesh-developer].¶
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.¶
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.¶
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:¶
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.¶
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.¶
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.¶
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:¶
| Class | Keyboard? | Display? | Camera? | Network Configuration |
|---|---|---|---|---|
| Static Computer | Yes | Yes | No | Automatic |
| Mobile Computer | Yes | Yes | Yes | Required |
| Device with Display | No | No | No | Required |
| Black Box Device | No | No | No | Required |
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.¶
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.¶
IoT devices don't necessarily support IP¶
Local network config - sufficient to connect to the Mesh to bootstrap VPN.¶
Supports automatic configuration of the local network context via DHCP¶
Requires an SSID to be specified and in some cases a password.¶
A large range of wired and wireless communication protocols that provide local communication. Includes RS485, CANBUS, Zigbee, etc.¶
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.¶
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 SSID used by the network that connects to the external Internet.¶
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.¶
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.¶
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]¶
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.¶
Devices¶
The device being onboarded¶
A device that has the ability to authorize onboarding of the target device and cause the necessary credentials.¶
A device that has the ability to capture a connection code from a target device.¶
A device that combines the administration and capture device roles.¶
Objectives¶
Primary application: Target device is a static computer. Administration and target devices are in close proximity.¶
Prompts user to enter account address and optional PIN¶
Enters account address into target device¶
Requests device connection to indicated Mesh Service account address¶
Returns connection verification code to Target Device¶
Posts connection request to indicated account¶
Presents connection verification code to user¶
Synchronizes account to Mesh Service, receives pending connection request¶
[Optional] Prompts user for attention¶
Reviews pending connection requests on administration device¶
Verifies that connection codes match, rejects request if they do not match¶
Accepts request¶
Posts result of connection request to Mesh Service¶
Appends results to for collection spool.¶
Requests results of connection request¶
Returns results¶
Decrypts result and completes configuration.¶
Primary application: Target device is a static computer. Administration and target devices are not in close proximity.¶
Chief difference is that the¶
Requests PIN code¶
Generates PIN code¶
Reports PIN code to user¶
Posts to administration catalog to allow other administration devices to use code for verifying connection request¶
Receives administration catalog entry.¶
Prompts user to enter account address and optional PIN¶
Enters account address and PIN into target device¶
Requests device connection to indicated Mesh Service account address using PIN for authentication.¶
Returns connection verification code to Target Device¶
Posts connection request to indicated account¶
Presents connection verification code to user¶
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¶
Appends results to for collection spool.¶
Requests results of connection request¶
Returns results¶
Decrypts result and completes configuration.¶
Target device does not initially have network capability.¶
Requires code capture mechanism¶
Requires code capture capability on target device¶
Requests device connection code display¶
Scans code displayed on Administration 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.¶
Returns connection verification code to Target Device¶
Posts connection request to indicated account¶
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¶
Appends results to for collection spool.¶
Requests results of connection request¶
Returns results¶
Decrypts result and completes configuration.¶
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.¶
Requests device connection code display¶
Presents device connection code¶
Scans code displayed on Target device¶
Acquires connection code¶
Decodes connection secret and device bootstrap network configuration¶
Obtains device description and presents to user [*]¶
Accepts connection¶
Posts result of connection to device via device bootstrap network¶
Receives connection result from Administration device¶
Verifies that connection result is consistent with connection code posted.¶
The device description MAY be acquired from either¶
As before except that the administration functions are divided between the administration device and a separate capture device.¶
Opens contacts app, requests contact creation¶
Presents connection code¶
Scans connection code¶
Opens contacts app, acquires connection code¶
Decodes Connection Secret and Alice's account address¶
Posts connection request message to Bob's Mesh Service using connection secret as authenticator¶
Receives connection request from Bob¶
Forwards to Alice's account address¶
Receives connection request from Bob¶
Adds to Alice's inbound message spool¶
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¶
Accepts Bob's contact¶
Generates contact response for Bob posts to Alice's Mesh Service using connection secret as authenticator¶
Forwards connection response to Bob's Mesh service¶
Receives connection response from Alice¶
Adds to Bob's inbound message spool.¶
Synchronizes to Bob's Mesh Service¶
Receives connection response¶
Presents contact information to Bob¶
Accepts Alice's contact information¶
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.¶
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.¶
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.¶
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.¶
Receives Bob's Account Address out of band¶
Opens contact management application¶
Requests remote contact establishment with the user at Bob's Account address.¶
Creates and signs the contact establishment request.¶
Receives contact establishment request¶
Signs request and forwards to Bob's Service.¶
Receives contact establishment request¶
Verifies signature of Alice's Service, rejects if invalid¶
Adds request to Bob's inbound spool.¶
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.¶
Reviews request from Alice¶
Accepts or rejects request.¶
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.¶
Receives contact establishment request¶
Signs request and forwards to Alice's Service.¶
Receives contact establishment request¶
Verifies signature of Bob's Service, rejects if invalid¶
Adds request to Alice's inbound spool.¶
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).¶
Verifies proof of knowledge of request secret. If invalid, ignore.¶
Add's contact to Alice's contact catalog.¶
Trusted third party endorsement MAY be used to improve the reliability of either the in-person or remote contact establishment ceremonies.¶
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.¶
Second factor authentication by means of entering a one time code is widely used despite the obvious limitations of this approach:¶
Modern mobile devices are both ubiquitous and offer sufficient affordances to provide user experience that is more satisfactory and offers substantially greater security.¶
Attempts action requiring confirmation at Carol's Cloud¶
Generates and signs confirmation request for Alice's Account Address¶
Sends to Carol's Service¶
Countersigns confirmation request and forwards to Alice's Service¶
Verifies countersignature of Carol's service, if invalid, aborts¶
Adds confirmation request to Alice's inbound spool.¶
Synchronizes to Alice's Service¶
Discards messages that are unauthorized according to entries in contacts catalog¶
Decrypts confirmation request¶
Notifies Alice according to policy.¶
Reads confirmation request¶
Responds with Accept or Reject.¶
Creates and signs/encrypts response including request data¶
Appends to confirmation catalog.¶
Forwards response to Alice's Service.¶
Countersigns response, forwards to Carol's Service¶
Verifies counter signature, rejects if invalid¶
Appends response to Carol's inbound spool.¶
Synchronizes to service.¶
Decrypts response, acts accordingly.¶
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.¶
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.¶
Attempts action requiring confirmation with physical presence at 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¶
Reads Connection code¶
Synchronizes to Alice's Service, no message pending (yet), waits.¶
Countersigns confirmation request and forwards to Alice's Service¶
Verifies countersignature of Dave's service, if invalid, aborts¶
Adds confirmation request to Alice's inbound spool.¶
Synchronizes to Alice's Service¶
Discards messages that are unauthorized according to entries in contacts catalog¶
Decrypts confirmation request¶
Notifies Alice according to policy.¶
Reads confirmation request¶
Responds with Accept or Reject.¶
Creates and signs/encrypts response including request data¶
Appends to confirmation catalog.¶
Forwards response to Alice's Service.¶
Countersigns response, forwards to Dave's Service¶
Verifies counter signature, rejects if invalid¶
Appends response to Dave's inbound spool.¶
Synchronizes to service.¶
Decrypts response, acts accordingly.¶
This document requires no IANA actions.¶