idnits 2.17.1 draft-hallambaker-mesh-cryptography-08.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 (5 August 2021) is 966 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 5 August 2021 4 Intended status: Informational 5 Expires: 6 February 2022 7 Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms 8 draft-hallambaker-mesh-cryptography-08 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. 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 6 February 2022. 46 Copyright Notice 48 Copyright (c) 2021 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 (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 63 2.3. Related Specifications . . . . . . . . . . . . . . . . . 4 64 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 4 65 3. Recommended and Required Algorithms . . . . . . . . . . . . . 4 66 3.1. Mesh Device . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Constrained Device . . . . . . . . . . . . . . . . . . . 5 68 4. Multi-Party Cryptography . . . . . . . . . . . . . . . . . . 6 69 4.1. Application to Diffie Hellman (not normative) . . . . . . 6 70 4.2. Multi-Party Key Generation . . . . . . . . . . . . . . . 6 71 4.3. Multi-Party Decryption . . . . . . . . . . . . . . . . . 7 72 4.4. Mutually Authenticated Key Exchange. . . . . . . . . . . 7 73 4.5. Implementation . . . . . . . . . . . . . . . . . . . . . 7 74 4.5.1. Implementation for Ed25519 and Ed448 . . . . . . . . 8 75 4.5.2. Implementation for X25519 and X448 . . . . . . . . . 8 76 5. Multi-Party Key Generation . . . . . . . . . . . . . . . . . 9 77 6. Multi-Party Decryption . . . . . . . . . . . . . . . . . . . 9 78 6.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 11 79 6.2. Implementation . . . . . . . . . . . . . . . . . . . . . 12 80 6.2.1. Group Creation . . . . . . . . . . . . . . . . . . . 12 81 6.2.2. Provisioning a Member . . . . . . . . . . . . . . . . 13 82 6.2.3. Message Encryption and Decryption . . . . . . . . . . 13 83 7. Mutually Authenticated Key Agreement . . . . . . . . . . . . 14 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 87 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 11.1. Key Combination . . . . . . . . . . . . . . . . . . . . 15 89 11.1.1. Ed25519 . . . . . . . . . . . . . . . . . . . . . . 16 90 11.1.2. Ed448 . . . . . . . . . . . . . . . . . . . . . . . 16 91 11.1.3. X25519 . . . . . . . . . . . . . . . . . . . . . . . 16 92 11.1.4. X448 . . . . . . . . . . . . . . . . . . . . . . . . 16 93 11.2. Group Encryption . . . . . . . . . . . . . . . . . . . . 16 94 11.2.1. X25519 . . . . . . . . . . . . . . . . . . . . . . . 16 95 11.2.2. X448 . . . . . . . . . . . . . . . . . . . . . . . . 16 96 12. Normative References . . . . . . . . . . . . . . . . . . . . 16 97 13. Informative References . . . . . . . . . . . . . . . . . . . 17 99 1. Introduction 101 This document describes the cryptographic algorithm suites used in 102 the Mesh and the implementation of Multi-Party Encryption and Multi- 103 Party Key Generation used in the Mesh. 105 To allow use of Mesh capabilities on the least capable computing 106 devices currently in use, separate schedules of recommended and 107 required algorithms are specified for Standard Devices and 108 Constrained Devices. 110 The Constrained device class may be considered to include most 8-bit 111 CPUs equipped with sufficient memory to support the necessary 112 operations. For example an Ardunino Mega 2560 which can perform ECDH 113 key agreement and signature operations in times ranging from 3 to 8 114 seconds. While such a device is clearly not suited to perform such 115 operations routinely, a one-time connection process that takes 116 several minutes to complete need not be of major concern. 118 The Standard device class may be considered to include the vast 119 majority of general purpose and personal computing devices 120 manufactured since 2010. Even a Raspberry Pi Zero which currently 121 retails at $5 is capable of performing the cryptographic functions 122 required to implement the Mesh with negligible impact on the user. 124 2. Definitions 126 This section presents the related specifications and standard, the 127 terms that are used as terms of art within the documents and the 128 terms used as requirements language. 130 2.1. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2.2. Defined Terms 138 The terms of art used in this document are described in the _Mesh 139 Architecture Guide_ [draft-hallambaker-mesh-architecture]. 141 2.3. Related Specifications 143 The architecture of the Mathematical Mesh is described in the _Mesh 144 Architecture Guide_ [draft-hallambaker-mesh-architecture]. The Mesh 145 documentation set and related specifications are described in this 146 document. 148 2.4. Implementation Status 150 The implementation status of the reference code base is described in 151 the companion document [draft-hallambaker-mesh-developer]. 153 3. Recommended and Required Algorithms 155 To allow implementation of Mesh capabilities on the widest possible 156 range of devices, separate algorithm requirements and recommendations 157 are specified for four classes of device: 159 Administration Device A general-purpose computing device that is 160 used for Mesh administration functions. 162 Mesh Device A general-purpose computing device that is not used for 163 Mesh administration functions with sufficient memory and 164 processing power to perform public key cryptography operations 165 without paying particular attention to the impact on performance. 167 Constrained Device An embedded computing device with limited memory 168 and computing power that offers sufficient processing capabilities 169 to perform occasional public key operations (e.g. during device 170 initialization) but is not suited to repeated operations. 172 Bridge Device A trusted device that enables Mesh Devices to 173 interoperate with Constrained devices. 175 Since Administration Devices and Mesh Devices MUST support 176 communication with Mesh Devices and Constrained devices, they MUST 177 meet all the REQUIRED algorithms for both types of device. 179 3.1. Mesh Device 181 Support for the following algorithms is REQUIRED: 183 * SHA-2-512 [SHA-2] 185 * HMAC-SHA-2-512 [RFC2104] 187 * HMAC-based Extract-and-Expand Key Derivation Function [RFC5869] 188 * AES-CBC-256 Encryption [FIPS197] 190 * Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] 192 * Montgomery Curve Diffie-Hellman Key Agreement X25519 and X448 193 [RFC7748] 195 * Edwards-Curve Digital Signature Algorithm Ed25519 and Ed448 196 [RFC8032] 198 Support for the following algorithms is RECOMMENDED: 200 * AES-GCM-256 Encryption [AES-GCM] 202 * SHA-3-512 [SHA-3] 204 * KMAC SHA-3-512 [SHA-3-Derived] 206 While the use of GCM is generally preferred over CBC mode in IETF 207 security protocols, this mode is not currently supported by the 208 reference implementation platform. 210 3.2. Constrained Device 212 Support for the following algorithms is REQUIRED: 214 * SHA-2-512 [SHA-2] 216 * HMAC-SHA-2-512 [RFC2104] 218 * HMAC-based Extract-and-Expand Key Derivation Function [RFC5869] 220 * Poly1035 Authenticated Encryption [RFC8439] 222 * ChaCha20 Encryption [RFC8439] 224 * Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394] 226 * Edwards-Curve Digital Signature Algorithm Ed25519 [RFC8032] 228 * Edwards-Curve Diffie-Hellman Key Agreement Ed25519 [RFC8032] 230 Use of the Edwards Curves for Signature and Key Agreement allows both 231 functions to be supported by a single library with no reduction in 232 security. 234 4. Multi-Party Cryptography 236 The multi-party key generation and multi-party decryption mechanisms 237 used in the Mesh protocols are made possible by the fact that Diffie 238 Hellman key agreement and elliptic curve variants thereof support 239 properties we call the Key Combination Law and the Result Combination 240 Law. 242 Let {_X_, _x_}, {_Y_, _y_}, {_E_, _e_} be {public, private} key 243 pairs. 245 The Key Combination law states that we can define an operator ? such 246 that there is a keypair {_Z_, _z_} such that: 248 _Z_ = _X_ ? _Y_ and _z_ = (_x_ + _y_) mod _o_ (where _o_ is the order 249 of the group) 251 The Result Combination Law states that we can define an operator ? 252 such that: 254 (_x_ ? _E_) ? (_y_ ? _E_) = (_z_ ? _E_) = (_e_ ? _Z_). 256 4.1. Application to Diffie Hellman (not normative) 258 For the Diffie Hellman system in a modular field p, o = p-1 and _a_? 259 _b_ = _a_? _b_ = _a_._b_mod _p_. 261 _Proof:_ 263 By definition, X = e^x mod p, Y = e^y mod p, and Z = e^zmod p. 265 Therefore, 267 Z = e^z mod p = e^(x+y) mod p = (e^xe^y) mod p = e^xmod p.e^y mod p = 268 X.Y 270 A similar proof may be constructed for the operator ?. 272 4.2. Multi-Party Key Generation 274 The Key Combination Law provides the basis for the Key Co-Generation 275 technique used to ensure that the cryptographic keys used in devices 276 connected to a Mesh profile are sufficiently random and have not been 277 compromised by malware or other 'backdoor' compromise to the machine 278 during or after manufacture. 280 For the Diffie Hellman system, the Key Combination law provides all 281 the mechanism needed to implement a Key Co-Generation mechanism. If 282 the Device key is {_X_, _x_}, the administration device can generate 283 a Co-Generation Key Pair {_Y_, _y_} and generate a Device Connection 284 Assertion for the final public key E calculated from knowledge of X 285 and Y alone. Passing the value _y_ to the device (using a secure 286 channel) allows it to calculate the corresponding private key _e_ 287 required to make use of the Device Connection Assertion. 289 This approach ensures that a party with knowledge of either _x_ or 290 _y_ but not both obtains no knowledge of _e_. 292 Section REF _Ref5309729 \w \h 5 describes the implementation of these 293 schemes in the Mesh 295 4.3. Multi-Party Decryption 297 The Key Combination Law and Result Combination Law provide the basis 298 for the Multi-Party Decryption technique used to support Mesh 299 Encryption Groups. 301 Section REF _Ref5309538 \w \h 6 describes the application of this 302 technique in the Mesh 304 4.4. Mutually Authenticated Key Exchange. 306 The Result Combination Law is used to provide a Key Exchange 307 mechanism that provides mutual authentication of the parties while 308 preserving forward secrecy. 310 4.5. Implementation 312 For elliptic curve cryptosystems, the operators ? and ? are point 313 addition. 315 Implementing a robust Key Co-Generation for the Elliptic Curve 316 Cryptography schemes described in [RFC7748] and [RFC8032] requires 317 some additional considerations to be addressed. 319 * The secret scalar used in the EdDSA algorithm is calculated from 320 the private key using a digest function. It is therefore 321 necessary to specify the Key Co-Generation mechanism by reference 322 to operations on the secret scalar values rather than operations 323 on the private keys. 325 * The Montgomery Ladder traditionally used to perform X25519 and 326 X448 point multiplication does not require implementation of a 327 function to add two arbitrary points. While the steps required to 328 create such a function are fully constrained by the specification, 329 the means of satisfying the constraints is not. 331 4.5.1. Implementation for Ed25519 and Ed448 333 The data structures used to implement co-generation of public keys 334 are defined in the main Mesh Reference Guide. This document 335 describes only the additional implementation details. 337 Note that the 'private key' described in [RFC8032] is in fact a seed 338 used to generate a 'secret scalar' value that is the value that has 339 the function of being the private key in the ECDH algorithm. 341 To provision a new public key to a device, the provisioning device: 343 0. Obtains the device profile of the device(s) to be provisioned to 344 determine the type of key to perform co-generation for. Let the 345 device {public, private} key be {D, d}. 347 1. Generates a private key _m_ with the specified number of bytes 348 (32 or 57]. 350 2. Calculates the corresponding public key _M_. 352 3. Calculates the Application public key A = D+M where + is point 353 addition. 355 4. Constructs the application device entry containing the private 356 key value m and encrypts under the device encryption key d. 358 On receipt, the device may at its option use its knowledge of the 359 secret scalar corresponding to d and m to calculate the application 360 secret scalar a or alternatively maintain the two secrets separately 361 and make use of the result combination law to perform private key 362 operations. 364 4.5.2. Implementation for X25519 and X448 366 While the point addition function can be defined for any elliptic 367 curve system, it is not necessary to implement point addition to 368 support ECDH key agreement. 370 In particular, point multiplication using the Montgomery ladder 371 technique over Montgomery curves only operate on the x co-ordinate 372 and only require point doubling operations. 374 For expediency, the current implementation of the Mesh reference code 375 uses the Edwards curves for both signature and encryption pending 376 announcement of platform support for both algorithms. 378 5. Multi-Party Key Generation 380 Multi-Party Key Generation is a capability that is used in the Mesh 381 to enable provisioning of application specific private key pairs to 382 connected devices without revealing any information concerning the 383 application private key of the device. 385 For example, Alice provisions the confirmation service to her watch. 386 The provisioning device could generate a signature key for the device 387 and encrypt it under the encryption key of the device. But this 388 means that we cannot attribute signatures to the watch with absolute 389 certainty as the provisioning device has had knowledge of the watch 390 signature key. Nor do we wish to use the device signature key for 391 the confirmation service. 393 Multi-Party Key Generation allows an administration device to 394 provision a connected device with an application specific private key 395 that is specific to that application and no other such that the 396 application can determine the public key of the device but has no 397 knowledge of the private key. 399 Provisioning an application private key to a device requires the 400 administration device to: 402 * Generate a new application public key for the device. 404 * Construct and publish whatever application specific credentials 405 the device requires to use the application. 407 * Providing the information required to make use of the private key 408 to the device. 410 Note that while the administration device needs to know the device 411 application public key, it does not require knowledge of the device 412 application private key. 414 6. Multi-Party Decryption 416 A key limitation of most deployed messaging systems is that true end- 417 to-end confidentiality is only achieved for a limited set of 418 communication patterns. Specifically, bilateral communications 419 (Alice sends a message to Bob) or broadcast communications to a known 420 set of recipients (Alice sends a message to Bob, Carol and Doug). 421 These capabilities do not support communication patterns where the 422 set of recipients changes over time or is confidential. Yet such 423 requirements commonly occur in situations such as sending a message 424 to a mailing list whose membership isn't known to the sender, or 425 creating a spreadsheet whose readership is to be limited to 426 authorized members of the 'accounting' team. 428 The mathematical approach that makes key co-generation possible may 429 be applied to support a public key encryption mode in which 430 encryption is performed as usual but decryption requires the use of 431 multiple keys. This approach is variously described in the 432 literature as distributed key generation and proxy re-encryption 433 [Blaze98]. 435 The approach specified in this document borrows aspects of both these 436 techniques. This combined approach is called 'recryption'. Using 437 recryption allows a sender to send a message to a group of users 438 whose membership is not known to the sender at the time the message 439 is sent and can change at any time. 441 Proxy re-encryption provides a technical capability that meets the 442 needs of such communication patterns. Conventional symmetric key 443 cryptography uses a single key to encrypt and decrypt data. Public 444 key cryptography uses two keys, the key used to encrypt data is 445 separate from the key used to decrypt. Proxy re-encryption 446 introduces a third key (the recryption key) that allows a party to 447 permit an encrypted data packet to be decrypted using a different key 448 without permitting the data to be decrypted. 450 The introduction of a recryption key permits end-to-end 451 confidentiality to be preserved when a communication pattern requires 452 that some part of the communication be supported by a service. 454 The introduction of a third type of key, the recryption key permits 455 two new roles to be established, that of an administrator and 456 recryption service. There are thus four parties: 458 Administrator Holder of Decryption Key, Creator of Recryption Keys 460 Sender Holder of Encryption Key 462 Recryption Service Holder of Recryption keys 464 Receiver Holder of personal decryption key 465 The information stored at the recryption service is necessary but not 466 sufficient to decrypt the message. Thus, no disclosure of the 467 message plaintext occurs even in the event that an attacker gains 468 full knowledge of all the information stored by the recryption 469 service. 471 6.1. Mechanism 473 The mechanism used to support recryption is the same as the mechanism 474 used to support key co-generation except that this time, instead of 475 combining two keys to create one, the private component of a 476 decryption key (i.e. the private key) is split into two parts, a 477 recryption key and a decryption key. 479 Recall that the key combination law for Diffie Hellman crypto-systems 480 states that we can add two private keys to get a third. It follows 481 that we can split the private key portion of a keypair {_G_, _g_} 482 into two parts by choosing a random number that is less than the 483 order of the Diffie-Hellman group to be our first key _x_. Our second 484 key is _y_ = _g_ - _r_ mod _o_, where _o_ is the order of the group. 486 Having generated _x_, _y_, we can use these to perform private key 487 agreement operations on a public key _E_ and then use the result 488 combination law to obtain the same result that we would have obtained 489 using _g_. 491 One means of applying this mechanism to recryption would be to 492 generate a different random value x for each member of the group and 493 store it at the recryption service and communicate the value y to the 494 member via a secure channel. Applying this approach, we can clearly 495 see that the recryption service gains no information about the value 496 of the private key since the only information it holds is a random 497 number which could have been generated without any knowledge of the 498 group private key. 500 [RFC8032] requires that implementations derive the scalar secret by 501 taking a cryptographic digest of the private key. This means that 502 either the client or the service must use a non-compliant 503 implementation. Given this choice, it is preferable to require that 504 the non-standard implementation be required at the service rather 505 than the client. This limits the scope of the non-conformant key 506 derivation approach to the specialist recryption service and ensures 507 that the client enforce the requirement to generate the private key 508 component by means of a digest. 510 6.2. Implementation 512 Implementation of recryption in the Mesh has four parts: 514 * Creation and management of the recryption group. 516 * Provisioning of members to a recryption group. 518 * Message encryption. 520 * Message decryption. 522 These operations are all performed using the same catalog and 523 messaging infrastructure provided by the Mesh for other purposes. 525 Each recryption group has its own independent Mesh account. This has 526 many advantages: 528 * Administration of the recryption group may be spread across 529 multiple Mesh users or transferred from one user to another 530 without requiring specification of a separate management protocol 531 to support these operations. 533 * The recryption account address can be used by Mesh applications 534 such as group messaging, conferencing, etc. as a contact address. 536 * The contact request service can be used to notify members that 537 they have been granted membership in the group. 539 6.2.1. Group Creation 541 Creation of a Recryption group requires the steps of: 543 * Generating the recryption group key pair 545 * Creating the recryption group account 547 * Generating administrator record for each administrator. 549 * Publishing the administrator records to the recryption catalog. 551 Note that in principle, we could make use of the key combination law 552 to enable separation of duties controls on administrators so that 553 provisioning of members required multiple administrators to 554 participate in the process. This is left to future versions. 556 6.2.2. Provisioning a Member 558 To provision a user as a member of the recryption group, the 559 administrator requires their current recryption profile. The 560 administrator MAY obtain this by means of a contact service request. 561 As with any contact service request, this request is subject to 562 access control and MAY require authorization by the intended user 563 before the provisioning can proceed. 565 Having obtained the user's recryption profile, the administration 566 tool generates a decryption private key for the user and encrypts it 567 under the member's key to create the encrypted decryption key entry. 569 The administration tool then computes the secret scalar from the 570 private key and uses this together with the secret scalar of the 571 recryption group to compute the recryption key for the member. This 572 value and the encrypted decryption key entry are combined to form the 573 recryption group membership record which is published to the catalog. 575 6.2.3. Message Encryption and Decryption 577 Encryption of a messages makes use of DARE Message in exactly the 578 same manner as any other encryption. The sole difference being that 579 the recipient entry for the recryption operation MUST specify the 580 recryption group address an not just the key fingerprint. This 581 allows the recipient to determine which recryption service to contact 582 to perform the recryption operation. 584 To decrypt a message, the recipient makes an authenticated recryption 585 request to the specified recryption service specifying: 587 * The recipient entry to be used for decryption 589 * The fingerprint of the decryption key(s) the device would like to 590 make use of. 592 * Whether or not the encrypted decryption key entry should be 593 returned. 595 The recryption service searches the catalog for the corresponding 596 recryption group to find a matching entry. If found and if the 597 recipient and proposed decryption key are dully authorized for the 598 purpose, the service performs the key agreement operation using the 599 recryption key specified in the entry and returns the result to the 600 recipient. 602 The recipient then decrypts the recryption data entry using its 603 device decryption key and uses the group decryption key to calculate 604 the other half of the result. The two halves of the result are then 605 added to obtain the key agreement value that is then used to decrypt 606 the message. 608 7. Mutually Authenticated Key Agreement 610 Diffie Hellman key agreement using the authenticated public keys of 611 the principals provides mutual authentication of those principals. 613 For example, if Alice's key pair is {_a_, _A_} and Bob's key pair is 614 {_b_, _B_}, the Diffie Hellman key agreement value _DH_ (_a_, _B_) = 615 _DH_ (_b_, _A_) can only be generated from the public information if 616 _a_ or _b_ is known. 618 The chief disadvantage of this approach is that it only allows Alice 619 and Bob to establish a single shared secret that will never vary and 620 does not provide forward secrecy. To avoid this, cryptographic 621 protocols usually perform the key agreement against an ephemeral key 622 and either accept that the client key is not authenticated or perform 623 multiple key agreements and combine the results. 625 Using the Result Combination Law allows a key agreement mechanism to 626 combine the benefits of mutual authentication with the use of 627 ephemeral keys without the need for multiple private key operations 628 or additional round trips. 630 In its simplest form, the key exchange has two parties which we refer 631 to as the client and the server. The client being the party that 632 initiates the protocol exchange and the server being the party that 633 responds. Let the public key pair of the client be {_a_, _A_} and 634 that of the server {_b_, _B_}. 636 Two versions of the key agreement mechanism are specified: 638 Client ephemeral The client contributes an ephemeral key pair 639 {_n_A_, _N_A_}. The effective public key of the client is _A_ ? 640 _N_A_. 642 The server uses its public key _B_. 644 The key agreement value is _DH_(_a_ + _n_A_, B) = _DH_ (_b_, _A_ ? 645 _N_A_) 647 Dual ephemeral The client contributes an ephemeral key pair {_n_A_, 648 _N_A_}. The effective public key of the client is _A_ ? _N_A_. 650 The server contributes an ephemeral key pair {_n_B_, _N_B_}. The 651 effective public key of the client is _B_ ? _N_B_. 653 The key agreement value is _DH_(_a_ + _n_A_, _B_ ? _N_B_) = _DH_ 654 (_b_ + _n_B_, _A_ ? _N_A_) 656 The function of the ephemeral key is effectively that of a nonce but 657 it is shared with the counter-party as a public key value. 659 The dual ephemeral approach has the advantage that it limits the 660 scope for side channel attacks as both sides have contributed unknown 661 information to the key agreement value. The disadvantage of this 662 approach is that the key agreement value can only be calculated after 663 the server has provided its ephemeral. 665 Implementations MAY take advantage of the result combination law to 666 enable private key operations involving the authenticated key (or a 667 contribution to it) to be performed in trustworthy hardware. 669 An advantage of this key exchange mechanism over the traditional TLS 670 key exchange approach is that no signature operation is involved, 671 thus ensuring that either party can repudiate the exchange and thus 672 the claim that they were in communication. 674 The master secret is calculated from the key agreement value in the 675 usual fashion. For ECDH algorithms, this comprises the steps of 676 converting the key agreement value to an octet string which forms the 677 input to a Key Derivation Function. 679 8. Security Considerations 681 The security considerations for use and implementation of Mesh 682 services and applications are described in the Mesh Security 683 Considerations guide [draft-hallambaker-mesh-security]. 685 9. IANA Considerations 687 This document requires no IANA actions. 689 10. Acknowledgements 691 A list of people who have contributed to the design of the Mesh is 692 presented in [draft-hallambaker-mesh-architecture]. 694 11. Examples 696 11.1. Key Combination 697 11.1.1. Ed25519 699 11.1.2. Ed448 701 11.1.3. X25519 703 11.1.4. X448 705 11.2. Group Encryption 707 11.2.1. X25519 709 11.2.2. X448 711 12. Normative References 713 [AES-GCM] Dworkin, M. J., "Recommendation for Block Cipher Modes of 714 Operation: Galois/Counter Mode (GCM) and GMAC", November 715 2007. 717 [draft-hallambaker-mesh-architecture] 718 Hallam-Baker, P., "Mathematical Mesh 3.0 Part I: 719 Architecture Guide", Work in Progress, Internet-Draft, 720 draft-hallambaker-mesh-architecture-16, 13 January 2021, 721 . 724 [draft-hallambaker-mesh-security] 725 Hallam-Baker, P., "Mathematical Mesh 3.0 Part VII: 726 Security Considerations", Work in Progress, Internet- 727 Draft, draft-hallambaker-mesh-security-06, 2 November 728 2020, . 731 [FIPS197] NIST, "Advanced Encryption Standard (AES)", November 2001. 733 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 734 Hashing for Message Authentication", RFC 2104, 735 DOI 10.17487/RFC2104, February 1997, 736 . 738 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, 740 DOI 10.17487/RFC2119, March 1997, 741 . 743 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 744 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 745 September 2002, . 747 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 748 Key Derivation Function (HKDF)", RFC 5869, 749 DOI 10.17487/RFC5869, May 2010, 750 . 752 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 753 for Security", RFC 7748, DOI 10.17487/RFC7748, January 754 2016, . 756 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 757 Signature Algorithm (EdDSA)", RFC 8032, 758 DOI 10.17487/RFC8032, January 2017, 759 . 761 [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 762 Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, 763 . 765 [SHA-2] NIST, "Secure Hash Standard", August 2015. 767 [SHA-3] Dworkin, M. J., "SHA-3 Standard: Permutation-Based Hash 768 and Extendable-Output Functions", August 2015. 770 [SHA-3-Derived] 771 Kelsey, J. M., Chang, S. H., and R. A. Perlner, "SHA-3 772 Derived Functions: cSHAKE, KMAC, TupleHash and 773 ParallelHash SHARE", December 2016. 775 13. Informative References 777 [Blaze98] "[Reference Not Found!]". 779 [draft-hallambaker-mesh-developer] 780 Hallam-Baker, P., "Mathematical Mesh: Reference 781 Implementation", Work in Progress, Internet-Draft, draft- 782 hallambaker-mesh-developer-10, 27 July 2020, 783 .