idnits 2.17.1 draft-hallambaker-mesh-cryptography-03.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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2019) is 1644 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 929 -- Looks like a reference, but probably isn't: '2' on line 932 -- Looks like a reference, but probably isn't: '3' on line 935 -- Looks like a reference, but probably isn't: '4' on line 938 -- Looks like a reference, but probably isn't: '5' on line 941 -- Looks like a reference, but probably isn't: '6' on line 944 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hallam-Baker 3 Internet-Draft October 23, 2019 4 Intended status: Informational 5 Expires: April 25, 2020 7 Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms 8 draft-hallambaker-mesh-cryptography-03 10 Abstract 12 The Mathematical Mesh 'The Mesh' is an infrastructure that 13 facilitates the exchange of configuration and credential data between 14 multiple user devices and provides end-to-end security. This 15 document describes the cryptographic algorithm suites used in the 16 Mesh and the implementation of Multi-Party Encryption and Multi-Party 17 Key Generation used in the Mesh. 19 [Note to Readers] 21 Discussion of this draft takes place on the MATHMESH mailing list 22 (mathmesh@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/search/?email_list=mathmesh. 25 This document is also available online at 26 http://mathmesh.com/Documents/draft-hallambaker-mesh- 27 cryptography.html [1] . 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 25, 2020. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 66 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. Related Specifications . . . . . . . . . . . . . . . . . 4 68 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 4 69 3. Recommended and Required Algorithms . . . . . . . . . . . . . 4 70 3.1. Mesh Device . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Constrained Device . . . . . . . . . . . . . . . . . . . 5 72 4. Multi-Party Cryptography . . . . . . . . . . . . . . . . . . 6 73 4.1. Application to Diffie Hellman (not normative) . . . . . . 6 74 4.2. Multi-Party Key Generation . . . . . . . . . . . . . . . 7 75 4.3. Multi-Party Decryption . . . . . . . . . . . . . . . . . 7 76 4.4. Mutually Authenticated Key Exchange. . . . . . . . . . . 7 77 4.5. Implementation . . . . . . . . . . . . . . . . . . . . . 7 78 4.5.1. Implementation for Ed25519 and Ed448 . . . . . . . . 8 79 4.5.2. Implementation for X25519 and X448 . . . . . . . . . 9 80 5. Multi-Party Key Generation . . . . . . . . . . . . . . . . . 9 81 5.1. Example: Provisioning the Confirmation Service . . . . . 10 82 6. Multi-Party Decryption . . . . . . . . . . . . . . . . . . . 11 83 6.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 12 84 6.2. Implementation . . . . . . . . . . . . . . . . . . . . . 13 85 6.2.1. Group Creation . . . . . . . . . . . . . . . . . . . 14 86 6.2.2. Provisioning a Member . . . . . . . . . . . . . . . . 14 87 6.2.3. Message Encryption and Decryption . . . . . . . . . . 15 88 6.3. Example: Messaging group . . . . . . . . . . . . . . . . 15 89 7. Mutually Authenticated Key Agreement . . . . . . . . . . . . 17 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 93 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 11.1. Key Combination . . . . . . . . . . . . . . . . . . . . 19 95 11.1.1. Ed25519 . . . . . . . . . . . . . . . . . . . . . . 19 96 11.1.2. Ed448 . . . . . . . . . . . . . . . . . . . . . . . 19 97 11.1.3. X25519 . . . . . . . . . . . . . . . . . . . . . . . 19 98 11.1.4. X448 . . . . . . . . . . . . . . . . . . . . . . . . 19 99 11.2. Group Encryption . . . . . . . . . . . . . . . . . . . . 19 100 11.2.1. X25519 . . . . . . . . . . . . . . . . . . . . . . . 19 101 11.2.2. X448 . . . . . . . . . . . . . . . . . . . . . . . . 19 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 104 12.2. Informative References . . . . . . . . . . . . . . . . . 20 105 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 108 1. Introduction 110 This document describes the cryptographic algorithm suites used in 111 the Mesh and the implementation of Multi-Party Encryption and Multi- 112 Party Key Generation used in the Mesh. 114 To allow use of Mesh capabilities on the least capable computing 115 devices currently in use, separate schedules of recommended and 116 required algorithms are specified for Standard Devices and 117 Constrained Devices. 119 The Constrained device class may be considered to include most 8-bit 120 CPUs equipped with sufficient memory to support the necessary 121 operations. For example an Ardunino Mega 2560 which can perform ECDH 122 key agreement and signature operations in times ranging from 3 to 8 123 seconds. While such a device is clearly not suited to perform such 124 operations routinely, a one-time connection process that takes 125 several minutes to complete need not be of major concern. 127 The Standard device class may be considered to include the vast 128 majority of general purpose and personal computing devices 129 manufactured since 2010. Even a Raspberry Pi Zero which currently 130 retails at $5 is capable of performing the cryptographic functions 131 required to implement the Mesh with negligible impact on the user. 133 2. Definitions 135 This section presents the related specifications and standard, the 136 terms that are used as terms of art within the documents and the 137 terms used as requirements language. 139 2.1. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119] . 145 2.2. Defined Terms 147 The terms of art used in this document are described in the Mesh 148 Architecture Guide [draft-hallambaker-mesh-architecture] . 150 2.3. Related Specifications 152 The architecture of the Mathematical Mesh is described in the Mesh 153 Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh 154 documentation set and related specifications are described in this 155 document. 157 2.4. Implementation Status 159 The implementation status of the reference code base is described in 160 the companion document [draft-hallambaker-mesh-developer] . 162 3. Recommended and Required Algorithms 164 To allow implementation of Mesh capabilities on the widest possible 165 range of devices, separate algorithm requirements and recommendations 166 are specified for four classes of device: 168 Administration Device A general-purpose computing device that is 169 used for Mesh administration functions. 171 Mesh Device A general-purpose computing device that is not used for 172 Mesh administration functions with sufficient memory and 173 processing power to perform public key cryptography operations 174 without paying particular attention to the impact on performance. 176 Constrained Device An embedded computing device with limited memory 177 and computing power that offers sufficient processing capabilities 178 to perform occasional public key operations (e.g. during device 179 initialization) but is not suited to repeated operations. 181 Bridge Device A trusted device that enables Mesh Devices to 182 interoperate with Constrained devices. 184 Since Administration Devices and Mesh Devices MUST support 185 communication with Mesh Devices and Constrained devices, they MUST 186 meet all the REQUIRED algorithms for both types of device. 188 3.1. Mesh Device 190 Support for the following algorithms is REQUIRED: 192 o SHA-2-512 [SHA-2] 194 o HMAC-SHA-2-512 [RFC2104] 196 o HMAC-based Extract-and-Expand Key Derivation Function [RFC5869] 198 o AES-CBC-256 Encryption [FIPS197] 200 o Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] 202 o Montgomery Curve Diffie-Hellman Key Agreement X25519 and X448 203 [RFC7748] 205 o Edwards-Curve Digital Signature Algorithm Ed25519 and Ed448 206 [RFC8032] 208 Support for the following algorithms is RECOMMENDED: 210 o AES-GCM-256 Encryption [AES-GCM] 212 o SHA-3-512 [SHA-3] 214 o KMAC SHA-3-512 [SHA-3-Derived] 216 While the use of GCM is generally preferred over CBC mode in IETF 217 security protocols, this mode is not currently supported by the 218 reference implementation platform. 220 3.2. Constrained Device 222 Support for the following algorithms is REQUIRED: 224 o SHA-2-512 [SHA-2] 226 o HMAC-SHA-2-512 [RFC2104] 228 o HMAC-based Extract-and-Expand Key Derivation Function [RFC5869] 230 o Poly1035 Authenticated Encryption [RFC8439] 232 o ChaCha20 Encryption [RFC8439] 234 o Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] 235 o Edwards-Curve Digital Signature Algorithm Ed25519 [RFC8032] 237 o Edwards-Curve Diffie-Hellman Key Agreement Ed25519 [RFC8032] 239 Use of the Edwards Curves for Signature and Key Agreement allows both 240 functions to be supported by a single library with no reduction in 241 security. 243 4. Multi-Party Cryptography 245 The multi-party key generation and multi-party decryption mechanisms 246 used in the Mesh protocols are made possible by the fact that Diffie 247 Hellman key agreement and elliptic curve variants thereof support 248 properties we call the Key Combination Law and the Result Combination 249 Law. 251 Let {X, x}, {Y, y}, {E, e} be {public, private} key pairs. 253 The Key Combination law states that we can define an operator ? such 254 that there is a keypair {Z, z} such that: 256 Z = X ? Y and z = (x + y) mod o (where o is the order of the group) 258 The Result Combination Law states that we can define an operator ? 259 such that: 261 (x ? E) ? (y ? E) = (z ? E) = (e ? Z). 263 4.1. Application to Diffie Hellman (not normative) 265 For the Diffie Hellman system in a modular field p, o = p-1 and a ? b 266 = a ? b = a.b mod p. 268 Proof: 270 By definition, X = e^x mod p, Y = e^y mod p, and Z = e^z mod p. 272 Therefore, 274 Z = e^z mod p = e^x+y mod p = (e^xe^y) mod p = e^x mod p.e^y mod p = 275 X.Y 277 A similar proof may be constructed for the operator ?. 279 4.2. Multi-Party Key Generation 281 The Key Combination Law provides the basis for the Key Co-Generation 282 technique used to ensure that the cryptographic keys used in devices 283 connected to a Mesh profile are sufficiently random and have not been 284 compromised by malware or other 'backdoor' compromise to the machine 285 during or after manufacture. 287 For the Diffie Hellman system, the Key Combination law provides all 288 the mechanism needed to implement a Key Co-Generation mechanism. If 289 the Device key is {X, x}, the administration device can generate a 290 Co-Generation Key Pair {Y, y} and generate a Device Connection 291 Assertion for the final public key E calculated from knowledge of X 292 and Y alone. Passing the value y to the device (using a secure 293 channel) allows it to calculate the corresponding private key e 294 required to make use of the Device Connection Assertion. 296 This approach ensures that a party with knowledge of either x or y 297 but not both obtains no knowledge of e. 299 Section REF _Ref5309729 \w \h 5 describes the implementation of these 300 schemes in the Mesh 302 4.3. Multi-Party Decryption 304 The Key Combination Law and Result Combination Law provide the basis 305 for the Multi-Party Decryption technique used to support Mesh 306 Encryption Groups. 308 Section REF _Ref5309538 \w \h 6 describes the application of this 309 technique in the Mesh 311 4.4. Mutually Authenticated Key Exchange. 313 The Result Combination Law is used to provide a Key Exchange 314 mechanism that provides mutual authentication of the parties while 315 preserving forward secrecy. 317 4.5. Implementation 319 For elliptic curve cryptosystems, the operators ? and ? are point 320 addition. 322 Implementing a robust Key Co-Generation for the Elliptic Curve 323 Cryptography schemes described in [RFC7748] and [RFC8032] requires 324 some additional considerations to be addressed. 326 o The secret scalar used in the EdDSA algorithm is calculated from 327 the private key using a digest function. It is therefore 328 necessary to specify the Key Co-Generation mechanism by reference 329 to operations on the secret scalar values rather than operations 330 on the private keys. 332 o The Montgomery Ladder traditionally used to perform X25519 and 333 X448 point multiplication does not require implementation of a 334 function to add two arbitrary points. While the steps required to 335 create such a function are fully constrained by the specification, 336 the means of satisfying the constraints is not. 338 4.5.1. Implementation for Ed25519 and Ed448 340 The data structures used to implement co-generation of public keys 341 are defined in the main Mesh Reference Guide. This document 342 describes only the additional implementation details. 344 Note that the 'private key' described in [RFC8032] is in fact a seed 345 used to generate a 'secret scalar' value that is the value that has 346 the function of being the private key in the ECDH algorithm. 348 To provision a new public key to a device, the provisioning device: 350 1. Obtains the device profile of the device(s) to be provisioned to 351 determine the type of key to perform co-generation for. Let the 352 device {public, private} key be {D, d}. 354 2. Generates a private key m with the specified number of bytes (32 355 or 57]. 357 3. Calculates the corresponding public key M. 359 4. Calculates the Application public key A = D+M where + is point 360 addition. 362 5. Constructs the application device entry containing the private 363 key value m and encrypts under the device encryption key d. 365 On receipt, the device may at its option use its knowledge of the 366 secret scalar corresponding to d and m to calculate the application 367 secret scalar a or alternatively maintain the two secrets separately 368 and make use of the result combination law to perform private key 369 operations. 371 4.5.2. Implementation for X25519 and X448 373 While the point addition function can be defined for any elliptic 374 curve system, it is not necessary to implement point addition to 375 support ECDH key agreement. 377 In particular, point multiplication using the Montgomery ladder 378 technique over Montgomery curves only operate on the x co-ordinate 379 and only require point doubling operations. 381 For expediency, the current implementation of the Mesh reference code 382 uses the Edwards curves for both signature and encryption pending 383 announcement of platform support for both algorithms. 385 5. Multi-Party Key Generation 387 Multi-Party Key Generation is a capability that is used in the Mesh 388 to enable provisioning of application specific private key pairs to 389 connected devices without revealing any information concerning the 390 application private key of the device. 392 For example, Alice provisions the confirmation service to her watch. 393 The provisioning device could generate a signature key for the device 394 and encrypt it under the encryption key of the device. But this 395 means that we cannot attribute signatures to the watch with absolute 396 certainty as the provisioning device has had knowledge of the watch 397 signature key. Nor do we wish to use the device signature key for 398 the confirmation 400 service. 402 Multi-Party Key Generation allows an administration device to 403 provision a connected device with an application specific private key 404 that is specific to that application and no other such that the 405 application can determine the public key of the device but has no 406 knowledge of the private key. 408 Provisioning an application private key to a device requires the 409 administration device to: 411 o Generate a new application public key for the device. 413 o Construct and publish whatever application specific credentials 414 the device requires to use the application. 416 o Providing the information required to make use of the private key 417 to the device. 419 Note that while the administration device needs to know the device 420 application public key, it does not require knowledge of the device 421 application private key. 423 [[This figure is not viewable in this format. The figure is 424 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 425 cryptography.html [2].]] 427 Two party key pair generation. 429 5.1. Example: Provisioning the Confirmation Service 431 For example, Alice provisions the confirmation service to her watch. 432 The device profile of the watch specifies an Ed25519 signature key. 433 Note that for production use, Ed448 is almost certainly prefered but 434 Ed25519 has the advantage of more compact presentation. 436 TBS: 438 The provisioning device could generate a signature key for the device 439 and encrypt it under the encryption key of the device. But this 440 means that we cannot attribute signatures to the watch with absolute 441 certainty as the provisioning device has had knowledge of the watch 442 signature key. Nor do we wish to use the device signature key for 443 the confirmation service. 445 Instead, the provisioning device generates a companion keypair. A 446 random seed is generated. 448 TBS: 450 A key derrivation function (HKDF) is used to derrive a 255 bit secret 451 scalar. 453 TBS: 455 The provisioning device can calculate the public key of the composite 456 keypair by adding the public keys of the device profile and the 457 companion public key: 459 TBS: 461 The provisioning device encrypts the private key of the comanion 462 keypair under the encryption key of the device. 464 TBS: 466 The provisioning device calculates the private key of the composite 467 keypair by adding the two private key values and verifies that scalar 468 multiplication of the base point returns the composite public key 469 value. 471 6. Multi-Party Decryption 473 A key limitation of most deployed messaging systems is that true end- 474 to-end confidentiality is only achieved for a limited set of 475 communication patterns. Specifically, bilateral communications 476 (Alice sends a message to Bob) or broadcast communications to a known 477 set of recipients (Alice sends a message to Bob, Carol and Doug). 478 These capabilities do not support communication patterns where the 479 set of recipients changes over time or is confidential. Yet such 480 requirements commonly occur in situations such as sending a message 481 to a mailing list whose membership isn't known to the sender, or 482 creating a spreadsheet whose readership is to be limited to 483 authorized members of the 'accounting' team. 485 [[This figure is not viewable in this format. The figure is 486 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 487 cryptography.html [3].]] 489 Traditional End-to-End Encryption is static. 491 The mathematical approach that makes key co-generation possible may 492 be applied to support a public key encryption mode in which 493 encryption is performed as usual but decryption requires the use of 494 multiple keys. This approach is variously described in the 495 literature as distributed key generation and proxy re- 496 encryption [Blaze98] . 498 The approach specified in this document borrows aspects of both these 499 techniques. This combined approach is called 'recryption'. Using 500 recryption allows a sender to send a message to a group of users 501 whose membership is not known to the sender at the time the message 502 is sent and can change at any time. 504 [[This figure is not viewable in this format. The figure is 505 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 506 cryptography.html [4].]] 508 Recryption supports End-to-End Encryption in dynamic groups. 510 Proxy re-encryption provides a technical capability that meets the 511 needs of such communication patterns. Conventional symmetric key 512 cryptography uses a single key to encrypt and decrypt data. Public 513 key cryptography uses two keys, the key used to encrypt data is 514 separate from the key used to decrypt. Proxy re-encryption 515 introduces a third key (the recryption key) that allows a party to 516 permit an encrypted data packet to be decrypted using a different key 517 without permitting the data to be decrypted. 519 The introduction of a recryption key permits end-to-end 520 confidentiality to be preserved when a communication pattern requires 521 that some part of the communication be supported by a service. 523 The introduction of a third type of key, the recryption key permits 524 two new roles to be established, that of an administrator and 525 recryption service. There are thus four parties: 527 Administrator Holder of Decryption Key, Creator of Recryption Keys 529 Sender Holder of Encryption Key 531 Recryption Service Holder of Recryption keys 533 Receiver Holder of personal decryption key 535 The communication between these parties is shown in Figure X below: 537 [[This figure is not viewable in this format. The figure is 538 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 539 cryptography.html [5].]] 541 Mesh/Recrypt Parties 543 The information stored at the recryption service is necessary but not 544 sufficient to decrypt the message. Thus, no disclosure of the 545 message plaintext occurs even in the event that an attacker gains 546 full knowledge of all the information stored by the recryption 547 service. 549 6.1. Mechanism 551 The mechanism used to support recryption is the same as the mechanism 552 used to support key co-generation except that this time, instead of 553 combining two keys to create one, the private component of a 554 decryption key (i.e. the private key) is split into two parts, a 555 recryption key and a decryption key. 557 Recall that the key combination law for Diffie Hellman crypto-systems 558 states that we can add two private keys to get a third. It follows 559 that we can split the private key portion of a keypair {G, g} into 560 two parts by choosing a random number that is less than the order of 561 the Diffie-Hellman group to be our first key x. Our second key is y 562 = g - r mod o, where o is the order of the group. 564 Having generated x, y, we can use these to perform private key 565 agreement operations on a public key E and then use the result 566 combination law to obtain the same result that we would have obtained 567 using g. 569 One means of applying this mechanism to recryption would be to 570 generate a different random value x for each member of the group and 571 store it at the recryption service and communicate the value y to the 572 member via a secure channel. Applying this approach, we can clearly 573 see that the recryption service gains no information about the value 574 of the private key since the only information it holds is a random 575 number which could have been generated without any knowledge of the 576 group private key. 578 [RFC8032] requires that implementations derive the scalar secret by 579 taking a cryptographic digest of the private key. This means that 580 either the client or the service must use a non-compliant 581 implementation. Given this choice, it is preferable to require that 582 the non-standard implementation be required at the service rather 583 than the client. This limits the scope of the non-conformant key 584 derivation approach to the specialist recryption service and ensures 585 that the client enforce the requirement to generate the private key 586 component by means of a digest. 588 6.2. Implementation 590 Implementation of recryption in the Mesh has four parts: 592 o Creation and management of the recryption group. 594 o Provisioning of members to a recryption group. 596 o Message encryption. 598 o Message decryption. 600 These operations are all performed using the same catalog and 601 messaging infrastructure provided by the Mesh for other purposes. 603 Each recryption group has its own independent Mesh account. This has 604 many advantages: 606 o Administration of the recryption group may be spread across 607 multiple Mesh users or transferred from one user to another 608 without requiring specification of a separate management protocol 609 to support these operations. 611 o The recryption account address can be used by Mesh applications 612 such as group messaging, conferencing, etc. as a contact address. 614 o The contact request service can be used to notify members that 615 they have been granted membership in the group. 617 6.2.1. Group Creation 619 Creation of a Recryption group requires the steps of: 621 o Generating the recryption group key pair 623 o Creating the recryption group account 625 o Generating administrator record for each administrator. 627 o Publishing the administrator records to the recryption catalog. 629 Note that in principle, we could make use of the key combination law 630 to enable separation of duties controls on administrators so that 631 provisioning of members required multiple administrators to 632 participate in the process. This is left to future versions. 634 6.2.2. Provisioning a Member 636 To provision a user as a member of the recryption group, the 637 administrator requires their current recryption profile. The 638 administrator MAY obtain this by means of a contact service request. 639 As with any contact service request, this request is subject to 640 access control and MAY require authorization by the intended user 641 before the provisioning can proceed. 643 Having obtained the user's recryption profile, the administration 644 tool generates a decryption private key for the user and encrypts it 645 under the member's key to create the encrypted decryption key entry. 647 The administration tool then computes the secret scalar from the 648 private key and uses this together with the secret scalar of the 649 recryption group to compute the recryption key for the member. This 650 value and the encrypted decryption key entry are combined to form the 651 recryption group membership record which is published to the catalog. 653 6.2.3. Message Encryption and Decryption 655 Encryption of a messages makes use of DARE Message in exactly the 656 same manner as any other encryption. The sole difference being that 657 the recipient entry for the recryption operation MUST specify the 658 recryption group address an not just the key fingerprint. This 659 allows the recipient to determine which recryption service to contact 660 to perform the recryption operation. 662 To decrypt a message, the recipient makes an authenticated recryption 663 request to the specified recryption service specifying: 665 o The recipient entry to be used for decryption 667 o The fingerprint of the decryption key(s) the device would like to 668 make use of. 670 o Whether or not the encrypted decryption key entry should be 671 returned. 673 [[This figure is not viewable in this format. The figure is 674 available at http://mathmesh.com/Documents/draft-hallambaker-mesh- 675 cryptography.html [6].]] 677 Two key decryption. 679 The recryption service searches the catalog for the corresponding 680 recryption group to find a matching entry. If found and if the 681 recipient and proposed decryption key are dully authorized for the 682 purpose, the service performs the key agreement operation using the 683 recryption key specified in the entry and returns the result to the 684 recipient. 686 The recipient then decrypts the recryption data entry using its 687 device decryption key and uses the group decryption key to calculate 688 the other half of the result. The two halves of the result are then 689 added to obtain the key agreement value that is then used to decrypt 690 the message. 692 6.3. Example: Messaging group 694 Alice creates a recryption group. The group encryption and signature 695 key parameters are: 697 TBS: 699 To verify the proper function of the group, Alice creates a test 700 message and encrypts it under the group key. 702 TBS: 703 TBS: 705 Alice decides to add Bob to the group. Bob's recryption profile is: 707 TBS: 709 The decryption key is specified in the same way as any other Ed25519 710 private key using the hash of a private key seed value: 712 TBS: 714 The the recryption key is the group secret scalar minus (mod p) the 715 secret scalar of Bob's private key: 717 TBS: 719 The Recryption entry consists of Bob's address, the recryption key 720 and the decryption key encrypted under Bob's encryption key: 722 TBS: 724 The group administration tool creates a notification request to tell 725 Bob that he has been made a member of the new group and signs it 726 using the group signature key. The recryption entry and the 727 notification are then sent to the recryption service: 729 TBS: 731 The notification message contains a link to the test message. When 732 he accepts membership of the group, Bob clicks on the link to test 733 that his membership has been fully provisioned. Providing an 734 explicit test mechanism avoids the problem that might otherwise occur 735 in which the message spool fills up with test messages being posted. 737 Bob's Web browser requests the recryption data for the test message. 738 The request is authenticated and encrypted under Bob's device keys. 739 The plaintext of the message is: 741 TBS: 743 The plaintext of the response contains the additional information 744 Bob's Web browser needs to complete the decryption process: 746 TBS: 748 The Web browser decrypts the private key and uses it to calculate the 749 decryption value: 751 TBS: 753 The key agreement value is obtained by point addition of the 754 recryption and decryption values: 756 TBS: 758 This value allows the test message to be decrypted. 760 7. Mutually Authenticated Key Agreement 762 Diffie Hellman key agreement using the authenticated public keys of 763 the principals provides mutual authentication of those principals. 765 For example, if Alice's key pair is {a, A} and Bob's key pair is {b, 766 B}, the Diffie Hellman key agreement value DH (a, B) = DH (b, A) can 767 only be generated from the public information if a or b is known. 769 The chief disadvantage of this approach is that it only allows Alice 770 and Bob to establish a single shared secret that will never vary and 771 does not provide forward secrecy. To avoid this, cryptographic 772 protocols usually perform the key agreement against an ephemeral key 773 and either accept that the client key is not authenticated or perform 774 multiple key agreements and combine the results. 776 Using the Result Combination Law allows a key agreement mechanism to 777 combine the benefits of mutual authentication with the use of 778 ephemeral keys without the need for multiple private key operations 779 or additional round trips. 781 In its simplest form, the key exchange has two parties which we refer 782 to as the client and the server. The client being the party that 783 initiates the protocol exchange and the server being the party that 784 responds. Let the public key pair of the client be {a, A} and that 785 of the server {b, B}. 787 Two versions of the key agreement mechanism are specified: 789 Client ephemeral The client contributes an ephemeral key pair {n_A, 790 N_A}. The effective public key of the client is A ? N_A. 792 The server uses its public key B. 794 The key agreement value is DH (a + n_A, B) = DH (b, A ? N_A) 796 Dual ephemeral The client contributes an ephemeral key pair {n_A, 797 N_A}. The effective public key of the client is A ? N_A. 799 The server contributes an ephemeral key pair {n_B, N_B}. The 800 effective public key of the client is B ? N_B. 802 The key agreement value is DH (a + n_A, B ? N_B) = DH (b + n_B, A 803 ? N_A) 805 The function of the ephemeral key is effectively that of a nonce but 806 it is shared with the counter-party as a public key value. 808 The dual ephemeral approach has the advantage that it limits the 809 scope for side channel attacks as both sides have contributed unknown 810 information to the key agreement value. The disadvantage of this 811 approach is that the key agreement value can only be calculated after 812 the server has provided its ephemeral. 814 Implementations MAY take advantage of the result combination law to 815 enable private key operations involving the authenticated key (or a 816 contribution to it) to be performed in trustworthy hardware. 818 An advantage of this key exchange mechanism over the traditional TLS 819 key exchange approach is that no signature operation is involved, 820 thus ensuring that either party can repudiate the exchange and thus 821 the claim that they were in communication. 823 The master secret is calculated from the key agreement value in the 824 usual fashion. For ECDH algorithms, this comprises the steps of 825 converting the key agreement value to an octet string which forms the 826 input to a Key Derivation Function. 828 8. Security Considerations 830 The security considerations for use and implementation of Mesh 831 services and applications are described in the Mesh Security 832 Considerations guide [draft-hallambaker-mesh-security] . 834 9. IANA Considerations 836 This document requires no IANA actions. 838 10. Acknowledgements 840 A list of people who have contributed to the design of the Mesh is 841 presented in [draft-hallambaker-mesh-architecture] . 843 11. Examples 845 11.1. Key Combination 847 11.1.1. Ed25519 849 11.1.2. Ed448 851 11.1.3. X25519 853 11.1.4. X448 855 11.2. Group Encryption 857 11.2.1. X25519 859 11.2.2. X448 861 12. References 863 12.1. Normative References 865 [AES-GCM] Dworkin, M., "Recommendation for Block Cipher Modes of 866 Operation: Galois/Counter Mode (GCM) and GMAC", November 867 2007. 869 [draft-hallambaker-mesh-architecture] 870 Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: 871 Architecture Guide", draft-hallambaker-mesh- 872 architecture-10 (work in progress), August 2019. 874 [draft-hallambaker-mesh-security] 875 Hallam-Baker, P., "Mathematical Mesh Part VII: Security 876 Considerations", draft-hallambaker-mesh-security-01 (work 877 in progress), July 2019. 879 [FIPS197] NIST, "Advanced Encryption Standard (AES)", November 2001. 881 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 882 Hashing for Message Authentication", RFC 2104, 883 DOI 10.17487/RFC2104, February 1997. 885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 886 Requirement Levels", BCP 14, RFC 2119, 887 DOI 10.17487/RFC2119, March 1997. 889 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 890 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 891 September 2002. 893 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 894 Key Derivation Function (HKDF)", RFC 5869, 895 DOI 10.17487/RFC5869, May 2010. 897 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 898 for Security", RFC 7748, DOI 10.17487/RFC7748, January 899 2016. 901 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 902 Signature Algorithm (EdDSA)", RFC 8032, 903 DOI 10.17487/RFC8032, January 2017. 905 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 906 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018. 908 [SHA-2] NIST, "Secure Hash Standard", August 2015. 910 [SHA-3] Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and 911 Extendable-Output Functions", August 2015. 913 [SHA-3-Derived] 914 Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived 915 Functions: cSHAKE, KMAC, TupleHash and ParallelHash 916 SHARE", December 2016. 918 12.2. Informative References 920 [Blaze98] "[Reference Not Found!]". 922 [draft-hallambaker-mesh-developer] 923 Hallam-Baker, P., "Mathematical Mesh: Reference 924 Implementation", draft-hallambaker-mesh-developer-08 (work 925 in progress), April 2019. 927 12.3. URIs 929 [1] http://mathmesh.com/Documents/draft-hallambaker-mesh- 930 cryptography.html 932 [2] http://mathmesh.com/Documents/draft-hallambaker-mesh- 933 cryptography.html 935 [3] http://mathmesh.com/Documents/draft-hallambaker-mesh- 936 cryptography.html 938 [4] http://mathmesh.com/Documents/draft-hallambaker-mesh- 939 cryptography.html 941 [5] http://mathmesh.com/Documents/draft-hallambaker-mesh- 942 cryptography.html 944 [6] http://mathmesh.com/Documents/draft-hallambaker-mesh- 945 cryptography.html 947 Author's Address 949 Phillip Hallam-Baker 951 Email: phill@hallambaker.com