idnits 2.17.1 draft-hallambaker-mesh-ceremonies-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 July 2020) is 1340 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Optional' is mentioned on line 410, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. M. Hallam-Baker 3 Internet-Draft ThresholdSecrets.com 4 Intended status: Informational 27 July 2020 5 Expires: 28 January 2021 7 Mathematical Mesh 3.0 Part XIII: Mesh Ceremonies 8 draft-hallambaker-mesh-ceremonies-02 10 Abstract 12 Ceremonies are security protocols that involve human participants as 13 principal actors. Ceremonies for onboarding devices, establishing 14 trust between parties and obtaining multi-factor authenticated 15 responses from users are presented and analyzed with particular 16 application to the Mathematical Mesh. 18 https://mailarchive.ietf.org/arch/browse/mathmesh/ 19 (http://whatever)Discussion of this draft should take place on the 20 MathMesh mailing list (mathmesh@ietf.org), which is archived at . 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 28 January 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 55 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 56 2.3. Related Specifications . . . . . . . . . . . . . . . . . 4 57 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 4 58 3. Ceremony Contexts . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Users . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Devices . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Connection Codes . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Networks . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.4.1. Wired Network Configuration . . . . . . . . . . . . . 7 64 3.4.2. WiFi Configuration . . . . . . . . . . . . . . . . . 7 65 3.4.3. Non-IP Configuration . . . . . . . . . . . . . . . . 8 66 4. Device Onboarding Ceremonies . . . . . . . . . . . . . . . . 8 67 4.1. Networked Computing Device . . . . . . . . . . . . . . . 9 68 4.1.1. Fingerprint Comparison . . . . . . . . . . . . . . . 9 69 4.1.2. Out of band one-time code . . . . . . . . . . . . . . 10 70 4.2. Network bootstrap . . . . . . . . . . . . . . . . . . . . 11 71 4.2.1. Dynamic Code From Administration Device . . . . . . . 11 72 4.2.2. Code From Target Device . . . . . . . . . . . . . . . 12 73 4.3. Proxy configuration . . . . . . . . . . . . . . . . . . . 13 74 5. Contact Establishment Ceremonies . . . . . . . . . . . . . . 13 75 5.1. In Person . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5.2. Registration . . . . . . . . . . . . . . . . . . . . . . 15 77 5.3. Remote . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 5.4. Trusted Third Party Endorsement . . . . . . . . . . . . . 17 79 6. Authentication Ceremonies . . . . . . . . . . . . . . . . . . 17 80 6.1. Confirmation . . . . . . . . . . . . . . . . . . . . . . 17 81 6.2. Confirmation with Personal Presence . . . . . . . . . . . 19 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 85 10. Normative References . . . . . . . . . . . . . . . . . . . . 20 86 11. Informative References . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 The consideration of ceremonies as an aspect of network protocol 91 design was introduced by Carl Ellison in 2007 [Ellison]. Since then, 92 consideration of ceremony design has provided a bridge between 93 security practitioners focused on network protocol and human-computer 94 interaction. 96 While the design of ceremonies is naturally connected to the design 97 of the user experience, the former represents an abstraction of the 98 latter. For example, the description ceremony might require that the 99 user be able to distinguish between two states but not how this 100 distinction is represented in the user experience. 102 Failure to consider ceremony design in protocol design frequently 103 leads to the user being consider able to avoid security breaches 104 through clairvoyance. Consider the commonly given but unactionable 105 advice that users 'take care' when opening email attachments. On 106 what basis is the user supposed to exercise caution when standard 107 SMTP email provides no means for determining the authenticity of a 108 message? 110 Formalizing the interactions of users in a protocol allows the 111 designers to consider if the expectations being put on the users are 112 likely to be met. It is easy for Web site operators to exhort users 113 to use a strong, unique password, to change it frequently and not 114 write it down. But there is not the slightest chance that users will 115 follow this advice except on rare occasions because it is utterly 116 unreasonable to expect them to remember a different password for each 117 of the hundreds of services they use. 119 Ceremonies formalize the interactions of humans with machines, but 120 humans are not Turing machines. They do not interact in precise 121 ways; they misunderstand information they are provided with and they 122 fail to follow instructions. It is essential that ceremonies be 123 designed with these constraints in mind. 125 This document describes the ceremonies that are used to establish 126 trust in the Mesh: 128 * Onboarding devices to a Mesh profile 130 * Contact endorsement and exchange 132 * Authenticated response interactions 134 While these particular ceremonies were designed to meet the design 135 requirements of the Mesh, most are based on pre-existing interaction 136 patterns that are widely used but not necessarily considered as a 137 ceremony. 139 2. Definitions 141 This section presents the related specifications and standard, the 142 terms that are used as terms of art within the documents and the 143 terms used as requirements language. 145 2.1. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 2.2. Defined Terms 153 2.3. Related Specifications 155 2.4. Implementation Status 157 The implementation status of the reference code base is described in 158 the companion document [draft-hallambaker-mesh-developer]. 160 3. Ceremony Contexts 162 A Mesh ceremony provides an abstract description of the interactions 163 between users and devices. A Ceremony context describes the specific 164 means by which the abstract ceremony is realized. 166 The ceremony context may be considered the equivalent of the physical 167 layer. Just as IP packets may be transferred using Ethernet or WiFi, 168 the short codes used in many of the onboarding ceremonies may be 169 exchanged using QR codes, Bluetooth, Near Field Communication or any 170 other infrastructure that provides the necessary affordances. 172 (Artwork only available as svg: No external link available, see 173 draft-hallambaker-mesh-ceremonies-02.html for artwork.) 175 Figure 1 177 3.1. Users 179 It is assumed that users are of average technical skill or less and 180 that they are unwilling to read any instructions or follow any 181 procedure more complex than that required to purchase the target 182 device. 184 The fact that a user is acting in an administrative role with respect 185 to onboarding a device does not mean that they should be assumed to 186 have administrative privileges on the machine they are using to 187 perform that function. 189 3.2. Devices 191 The term 'device' is used to refer to any machine involved in the 192 ceremony that is capable of communicating. Back at the dawn of the 193 Internet age, every device connected to the Internet was at least the 194 size of a washing machine that one or more users would interact with 195 by means of a terminal device with a keyboard and either a display or 196 a printer. 198 The range of affordances provided by modern devices is much broader. 199 Today's desktop workstation provides essentially the same display, 200 input an network affordances as those of a 'Personal Computer' sold 201 in the mid-1990s. At the other end of the device capability 202 spectrum, a 'smart' light bulb may offer only its light as a 203 potential output and no inputs whatsoever. 205 Accessibility is an important consideration in contemporary systems 206 design. Many users cannot use a traditional keyboard or display. In 207 the interests of clarity, we refer to user text input devices as 208 'keyboards' and text output devices as 'displays' while recognizing 209 that these MAY be realized using other technologies. 211 We recognize the following categories of device: 213 Static Computer A server or personal computer which is connected to 214 a wired network (e.g. Ethernet). A static computer provides a 215 keyboard and display, but not (necessarily) a camera. 217 Mobile Computer A laptop, tablet or smartphone device which supports 218 use of a wireless network (e.g. WiFi, Cellular). A mobile 219 computer provides a keyboard, display and a camera. 221 Device with Display A device which contains an embedded computer 222 with a display affordance and some form of network communication 223 capability (e.g. WiFi, Thread, Zigbee, Z-Wave, etc.) but not a 224 keyboard or a camera. 226 Black Box Device A device which contains an embedded computer with 227 some form of network communication capability (e.g. WiFi, Thread, 228 Zigbee, Z-Wave, etc.) that does not provide input or output 229 affordances to the user. 231 These capabilities are summarized as follows: 233 +=============+===========+==========+=========+===============+ 234 | Class | Keyboard? | Display? | Camera? | Network | 235 | | | | | Configuration | 236 +=============+===========+==========+=========+===============+ 237 | Static | Yes | Yes | No | Automatic | 238 | Computer | | | | | 239 +-------------+-----------+----------+---------+---------------+ 240 | Mobile | Yes | Yes | Yes | Required | 241 | Computer | | | | | 242 +-------------+-----------+----------+---------+---------------+ 243 | Device with | No | No | No | Required | 244 | Display | | | | | 245 +-------------+-----------+----------+---------+---------------+ 246 | Black Box | No | No | No | Required | 247 | Device | | | | | 248 +-------------+-----------+----------+---------+---------------+ 250 Table 1 252 While there is a tendency for IoT devices to become more elaborate 253 with succeeding generations, the expansion in the scope of IoT 254 devices more than compensates for this effect. Thus just as there 255 are more 8-bit CPUs manufactured today than at any point in history, 256 the number of devices in the 'black box device' category will almost 257 certainly increase over time rather than vanish. 259 3.3. Connection Codes 261 A Connection Code is a compact data object, typically 50 characters 262 or less that is passed from one party to another during a ceremony. 264 Connection Codes MAY take many forms according to the capabilities of 265 the devices involved. 267 * QR Code 269 * Serial communication using visible or Infra-Red light. 271 * Near Field Communications 273 3.4. Networks 275 IoT devices don't necessarily support IP 277 Local network config - sufficient to connect to the Mesh to bootstrap 278 VPN. 280 Wired Supports automatic configuration of the local network context 281 via DHCP 283 WiFi Requires an SSID to be specified and in some cases a password. 285 Non-IP A large range of wired and wireless communication protocols 286 that provide local communication. Includes RS485, CANBUS, Zigbee, 287 etc. 289 3.4.1. Wired Network Configuration 291 Wired networks such as Ethernet provide automated network 292 configuration via DHCP. 294 Can use this network as-is or as a bootstrap to establish a 295 connection through a VPN. 297 3.4.2. WiFi Configuration 299 WiFi networks support DHCP but this only acts after a device has 300 connected to the WiFi network by specifying the correct SSID and 301 providing the necessary credentials. 303 It is therefore necessary for an onboarding process to initialize the 304 WiFi settings before making use of the Internet. 306 A secondary consideration is the need to update the WiFi settings on 307 devices after the WiFi network configuration is changed or if the 308 device is moved from one network operated by the user to another. 310 To support these requirements we anticipate the use of at least three 311 separate WiFi SSIDs types: 313 The Public Network SSID The SSID used by the network that connects 314 to the external Internet. 316 The Device Hailing SSID An SSID that is monitored by a target device 317 that is not connected to a Mesh to allow it to receive inbound 318 connection initiation requests. 320 The Mesh Hailing SSID An SSID that is monitored by a WiFi access 321 point to allow devices previously connected to a Mesh to 322 reconnect. 324 This approach allows a device that has no preconfigured WiFi network 325 configuration to be onboarded to a user's personal Mesh. Once 326 accepted, the device can then connect to any WiFi network connected 327 to the user's personal Mesh listening on the Mesh hailing SSID. 329 Support for this configuration MAY be deployed at the WiFi access 330 point(s) for the network or by deploying a separate parallel WiFi 331 access point dedicated to serving hailing requests. 333 [Diagram: WiFi with hailing access point] 335 (Artwork only available as svg: No external link available, see 336 draft-hallambaker-mesh-ceremonies-02.html for artwork.) 338 Figure 2 340 3.4.3. Non-IP Configuration 342 Configuration of non-IP networks is similar to that for WiFi with the 343 important exception that some form of network gateway will be 344 required to bridge the networks. 346 (Artwork only available as svg: No external link available, see 347 draft-hallambaker-mesh-ceremonies-02.html for artwork.) 349 Figure 3 351 4. Device Onboarding Ceremonies 353 Devices 355 Target device The device being onboarded 357 Administration device A device that has the ability to authorize 358 onboarding of the target device and cause the necessary 359 credentials. 361 Capture device A device that has the ability to capture a connection 362 code from a target device. 364 Combination device A device that combines the administration and 365 capture device roles. 367 Objectives 369 * Provide bootstrap network connectivity to the target device. 371 * Provision administrative axiom of trust to the target device. 373 * Establish trustworthy private keys on the target device. 375 * Provision credentials to the target device. 377 * The exchange of credentials MUST be mutually authenticated such 378 that credentials are issued to a device if and only if it is the 379 intended target device and it has received the intended 380 administrative axiom of trust. 382 4.1. Networked Computing Device 384 4.1.1. Fingerprint Comparison 386 Primary application: Target device is a static computer. 387 Administration and target devices are in close proximity. 389 (Artwork only available as svg: No external link available, see 390 draft-hallambaker-mesh-ceremonies-02.html for artwork.) 392 Figure 4 394 Target Device Prompts user to enter account address and optional PIN 396 User on [Target Device] Enters account address into target device 398 Target Device Requests device connection to indicated Mesh Service 399 account address 401 Mesh Service Returns connection verification code to Target Device 403 Posts connection request to indicated account 405 Target Device Presents connection verification code to user 407 Administration Device Synchronizes account to Mesh Service, receives 408 pending connection request 410 [Optional] Prompts user for attention 412 User [Administration Device] Reviews pending connection requests on 413 administration device 415 Verifies that connection codes match, rejects request if they do 416 not match 418 Accepts request 420 Administration Device Posts result of connection request to Mesh 421 Service 423 Mesh Service Appends results to for collection spool. 425 Target Device Requests results of connection request 427 Mesh Service Returns results 429 Target Device Decrypts result and completes configuration. 431 4.1.2. Out of band one-time code 433 Primary application: Target device is a static computer. 434 Administration and target devices are not in close proximity. 436 (Artwork only available as svg: No external link available, see 437 draft-hallambaker-mesh-ceremonies-02.html for artwork.) 439 Figure 5 441 Chief difference is that the 443 User on [Administration Device] Requests PIN code 445 Administration Device Generates PIN code 447 Reports PIN code to user 449 Posts to administration catalog to allow other administration 450 devices to use code for verifying connection request 452 Mesh Service Receives administration catalog entry. 454 Target Device Prompts user to enter account address and optional PIN 456 User on [Target Device] Enters account address and PIN into target 457 device 459 Target Device Requests device connection to indicated Mesh Service 460 account address using PIN for authentication. 462 Mesh Service Returns connection verification code to Target Device 464 Posts connection request to indicated account 466 Target Device Presents connection verification code to user 468 Administration Device Synchronizes account to Mesh Service, receives 469 pending connection request 470 Verifies one-time code has been correctly specified, has not been 471 expired or previously used. 473 If so, accepts connection request as pre-approved 475 Posts result of connection request to Mesh Service 477 Mesh Service Appends results to for collection spool. 479 Target Device Requests results of connection request 481 Mesh Service Returns results 483 Target Device Decrypts result and completes configuration. 485 4.2. Network bootstrap 487 Target device does not initially have network capability. 489 Requires code capture mechanism 491 4.2.1. Dynamic Code From Administration Device 493 Requires code capture capability on target device 495 (Artwork only available as svg: No external link available, see 496 draft-hallambaker-mesh-ceremonies-02.html for artwork.) 498 Figure 6 500 User on Administration Device Requests device connection code 501 display 503 User on Target device Scans code displayed on Administration device 505 Target Device Acquires connection code 507 Decodes local network bootstrap configuration and connection 508 secret from connection code 510 Acquires access to bootstrap network 512 Posts connection request to service using connection secret for 513 authentication. 515 Mesh Service Returns connection verification code to Target Device 517 Posts connection request to indicated account 519 Administration Device Synchronizes account to Mesh Service, receives 520 pending connection request 522 Verifies one-time code has been correctly specified, has not been 523 expired or previously used. 525 If so, accepts connection request as pre-approved 527 Posts result of connection request to Mesh Service 529 Mesh Service Appends results to for collection spool. 531 Target Device Requests results of connection request 533 Mesh Service Returns results 535 Target Device Decrypts result and completes configuration. 537 4.2.2. Code From Target Device 539 Requires code capture capability on administration device 541 Code may be dynamic or static. 543 Dynamic provides same security as for the Admnistration device 544 display but requires the target device to have the display 545 affordance. 547 Static avoids need for a display, the code is physically printed on 548 the device itself. In this case the code is static meaning that the 549 connection secret allowing anyone who has handled the device to 550 hijack the connection attempt. 552 (Artwork only available as svg: No external link available, see 553 draft-hallambaker-mesh-ceremonies-02.html for artwork.) 555 Figure 7 557 User on Target device Requests device connection code display 559 Target device Presents device connection code 561 User on Administration Device Scans code displayed on Target device 563 Administration Device Acquires connection code 565 Decodes connection secret and device bootstrap network 566 configuration 567 Obtains device description and presents to user [*] 569 User on Administration Device Accepts connection 571 Administration Device Posts result of connection to device via 572 device bootstrap network 574 Target Device Receives connection result from Administration device 576 Verifies that connection result is consistent with connection code 577 posted. 579 The device description MAY be acquired from either 581 * The device itself (via the Device bootstrap network) 583 * The Internet 585 * In either case the UDF digest of the connection secret is used to 586 form the locator. 588 4.3. Proxy configuration 590 As before except that the administration functions are divided 591 between the administration device and a separate capture device. 593 (Artwork only available as svg: No external link available, see 594 draft-hallambaker-mesh-ceremonies-02.html for artwork.) 596 Figure 8 598 5. Contact Establishment Ceremonies 600 5.1. In Person 602 (Artwork only available as svg: No external link available, see 603 draft-hallambaker-mesh-ceremonies-02.html for artwork.) 605 Figure 9 607 User Alice Opens contacts app, requests contact creation 609 Alice's Device Presents connection code 611 User Bob Scans connection code 613 Bob's Device Opens contacts app, acquires connection code 614 Decodes Connection Secret and Alice's account address 616 Posts connection request message to Bob's Mesh Service using 617 connection secret as authenticator 619 Bob's Mesh Service Receives connection request from Bob 621 Forwards to Alice's account address 623 Alice's Mesh Service Receives connection request from Bob 625 Adds to Alice's inbound message spool 627 Alice's Device Synchronizes to Alice's Mesh Service 629 Receives message from Bob 631 Verifies that message is authenticated by connection secret, if 632 not abort. 634 Presents Bob's contact information 636 User Alice Accepts Bob's contact 638 Alice's Device Generates contact response for Bob posts to Alice's 639 Mesh Service using connection secret as authenticator 641 Alice's Mesh Service Forwards connection response to Bob's Mesh 642 service 644 Bob's Mesh Service Receives connection response from Alice 646 Adds to Bob's inbound message spool. 648 Bob's device Synchronizes to Bob's Mesh Service 650 Receives connection response 652 Presents contact information to Bob 654 User Bob Accepts Alice's contact information 656 Bob's device Adds Alice's contact information to Bob's contacts 657 catalog 659 Since it is easy to delete a contact entry from the catalog, users 660 may opt to accept contact information without explicit user 661 verification. 663 The application SHOULD capture the circumstances in which the contact 664 was acquired including the time and place (if available). For 665 example, if Alice meets Bob at a conference for which there is an 666 entry in their calendar, their contacts app might make use of this 667 information to label the connection. 669 As with any other type of connection, an in-person connection MAY be 670 enrolled in a notary log to provide a fixed point in time. 672 5.2. Registration 674 Registration is essentially a variant of the In-Person contact 675 exchange ceremony in which Bob establishes evidence of attendance at 676 an event such as a conference by means of his connected mobile 677 device. 679 The ceremony is identical to that of the In-Person contact exchange 680 with the Roles 'Alice' and 'Alice's Device' replaced by 'Registrar' 681 and 'Registrar's device' respectively. 683 Registration at one or mode physical events MAY be used by trusted 684 third parties as the basis for providing endorsements according to 685 their published Endorsement Policies and Practices Statements. 687 5.3. Remote 689 In the remote contact exchange scenario, Alice and Bob are not 690 present in the same physical location and thus the risk of 691 impersonation is inevitably increased. Despite this limitation, 692 remote contact exchange allows participants to determine that they 693 are interacting with the same person as in previous interactions. 694 Which is sufficient for a wide number of purposes. 696 (Artwork only available as svg: No external link available, see 697 draft-hallambaker-mesh-ceremonies-02.html for artwork.) 699 Figure 10 701 Alice Receives Bob's Account Address out of band 703 Opens contact management application 705 Requests remote contact establishment with the user at Bob's 706 Account address. 708 Alice's Device Creates and signs the contact establishment request. 710 Alice's Service Receives contact establishment request 711 Signs request and forwards to Bob's Service. 713 Bob's Service Receives contact establishment request 715 Verifies signature of Alice's Service, rejects if invalid 717 Adds request to Bob's inbound spool. 719 Bob's Device Synchronizes to Bob's Service 721 Decrypts request 723 Verifies signature of Alice's request, rejects if invalid, rejects 724 if insufficiently authorized according to policy (i.e. spam 725 prevention). 727 Notifies Bob of pending request according to previously specified 728 policy. 730 Bob Reviews request from Alice 732 Accepts or rejects request. 734 Bob's Device If reject, abort. 736 Otherwise add contact to Bob's contact catalog. 738 Create and sign contact request for Alice including proof of 739 knowledge of request secret. 741 Bob's Service Receives contact establishment request 743 Signs request and forwards to Alice's Service. 745 Alice's Service Receives contact establishment request 747 Verifies signature of Bob's Service, rejects if invalid 749 Adds request to Alice's inbound spool. 751 Alice's Device Synchronizes to Alice's Service 753 Decrypts request 755 Verifies signature of Bob's request, rejects if invalid, rejects 756 if insufficiently authorized according to policy (i.e. spam 757 prevention). 759 Verifies proof of knowledge of request secret. If invalid, 760 ignore. 762 Add's contact to Alice's contact catalog. 764 5.4. Trusted Third Party Endorsement 766 Trusted third party endorsement MAY be used to improve the 767 reliability of either the in-person or remote contact establishment 768 ceremonies. 770 (Artwork only available as svg: No external link available, see 771 draft-hallambaker-mesh-ceremonies-02.html for artwork.) 773 Figure 11 775 The ceremony mechanics are unaffected except at the point where the 776 contact information is accepted when the information from one (or 777 more) trusted third parties MAY be presented to the user to assist 778 them in their decision to accept or reject the contact information. 780 Trusted Third Parties MAY provide an ongoing service, advising users 781 of a change in the trustworthiness of contact data. 783 6. Authentication Ceremonies 785 Second factor authentication by means of entering a one time code is 786 widely used despite the obvious limitations of this approach: 788 * A response code of four, six or even eight digits has a miniscule 789 work factor compared to the industry benchmark of 2^(128) or 790 greater. 792 * The process of presenting a code is vulnerable to Man in the 793 Middle attack. 795 * Response codes are not bound to the context in which they are used 796 and thus do not provide for non-repudiability. 798 Modern mobile devices are both ubiquitous and offer sufficient 799 affordances to provide user experience that is more satisfactory and 800 offers substantially greater security. 802 6.1. Confirmation 804 (Artwork only available as svg: No external link available, see 805 draft-hallambaker-mesh-ceremonies-02.html for artwork.) 806 Figure 12 808 Alice Attempts action requiring confirmation at Carol's Cloud 810 Carol's Cloud Generates and signs confirmation request for Alice's 811 Account Address 813 Sends to Carol's Service 815 Carol's Service Countersigns confirmation request and forwards to 816 Alice's Service 818 Alice's Service Verifies countersignature of Carol's service, if 819 invalid, aborts 821 Adds confirmation request to Alice's inbound spool. 823 Alice's Device Synchronizes to Alice's Service 825 Discards messages that are unauthorized according to entries in 826 contacts catalog 828 Decrypts confirmation request 830 Notifies Alice according to policy. 832 Alice Reads confirmation request 834 Responds with Accept or Reject. 836 Alice's Device Creates and signs/encrypts response including request 837 data 839 Appends to confirmation catalog. 841 Forwards response to Alice's Service. 843 Alice's Service Countersigns response, forwards to Carol's Service 845 Carol's Service Verifies counter signature, rejects if invalid 847 Appends response to Carol's inbound spool. 849 Carol's Device Synchronizes to service. 851 Decrypts response, acts accordingly. 853 Waiting for the response from Alice is essentially equivalent to 854 waiting for input from Alice 856 This description assumes that the devices poll the service to obtain 857 notification of updates. Provision for push notifications will of 858 course improve response. 860 6.2. Confirmation with Personal Presence 862 In certain situations we would like to require that Alice be 863 physically present when responding to a confirmation request. For 864 example, when opening a door or logging in to a workstation at a 865 facility. 867 In these circumstances, a confirmation code is used to provide 868 evidence that Alice is in the physical vicinity. Such codes may be 869 presented by means of a QR code, Near Field Communications or any 870 equivalent means. Noting of course that all proximity controls are 871 inherently vulnerable to a relay attack. 873 (Artwork only available as svg: No external link available, see 874 draft-hallambaker-mesh-ceremonies-02.html for artwork.) 876 Figure 13 878 Alice Attempts action requiring confirmation with physical presence 879 at Dave's Door 881 Dave's Door Generates unique connection code. 883 Generates and signs confirmation request for Alice's Account 884 Address 886 Sends to Dave's Service 888 Presents connection code to Alice's Device via local channel 890 Alice's Device Reads Connection code 892 Synchronizes to Alice's Service, no message pending (yet), waits. 894 Dave's Service Countersigns confirmation request and forwards to 895 Alice's Service 897 Alice's Service Verifies countersignature of Dave's service, if 898 invalid, aborts 900 Adds confirmation request to Alice's inbound spool. 902 Alice's Device Synchronizes to Alice's Service 904 Discards messages that are unauthorized according to entries in 905 contacts catalog 907 Decrypts confirmation request 909 Notifies Alice according to policy. 911 Alice Reads confirmation request 913 Responds with Accept or Reject. 915 Alice's Device Creates and signs/encrypts response including request 916 data 918 Appends to confirmation catalog. 920 Forwards response to Alice's Service. 922 Alice's Service Countersigns response, forwards to Dave's Service 924 Dave's Service Verifies counter signature, rejects if invalid 926 Appends response to Dave's inbound spool. 928 Dave's Door Synchronizes to service. 930 Decrypts response, acts accordingly. 932 7. Security Considerations 934 8. IANA Considerations 936 This document requires no IANA actions. 938 9. Acknowledgements 940 10. Normative References 942 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 943 Requirement Levels", BCP 14, RFC 2119, 944 DOI 10.17487/RFC2119, March 1997, 945 . 947 11. Informative References 949 [draft-hallambaker-mesh-developer] 950 Hallam-Baker, P., "Mathematical Mesh: Reference 951 Implementation", Work in Progress, Internet-Draft, draft- 952 hallambaker-mesh-developer-09, 23 October 2019, 953 . 956 [Ellison] Ellison, C., "Ceremony Design and Analysis", 2007.