Internet DRAFT - draft-hallambaker-mesh-ceremonies
draft-hallambaker-mesh-ceremonies
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,
<https://www.rfc-editor.org/rfc/rfc2119>.
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,
<https://tools.ietf.org/html/draft-hallambaker-mesh-
developer-09>.
[Ellison] Ellison, C., "Ceremony Design and Analysis", 2007.
Hallam-Baker Expires 28 January 2021 [Page 21]
