idnits 2.17.1 draft-celi-wiggers-tls-authkem-00.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 195 has weird spacing: '...y_share v Exc...' == Line 283 has weird spacing: '...y_share v Exc...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If this extension is not present, the "kem_encapsulation" extension MUST not be present as well. If present, it will be ignored. -- The document date (12 July 2021) is 991 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCTBD' is mentioned on line 456, but not defined == Unused Reference: 'RFC5280' is defined on line 884, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-tls-subcerts-10 == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-10 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tls S. Celi 3 Internet-Draft Cloudflare 4 Intended status: Informational P. Schwabe 5 Expires: 13 January 2022 Radboud University & MPI S&P 6 D. Stebila 7 University of Waterloo 8 N. Sullivan 9 Cloudflare 10 T. Wiggers 11 Radboud University 12 12 July 2021 14 KEM-based Authentication for TLS 1.3 15 draft-celi-wiggers-tls-authkem-00 17 Abstract 19 This document gives a construction for KEM-based authentication in 20 TLS 1.3. The overall design approach is a simple: usage of Key 21 Encapsulation Mechanisms (KEM) for certificate-based authentication. 23 Discussion Venues 25 This note is to be removed before publishing as an RFC. 27 Discussion of this document takes place on the mailing list (), which 28 is archived at . 30 Source for this draft and an issue tracker can be found at 31 https://github.com/claucece/draft-celi-wiggers-tls-authkem. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 13 January 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Key Encapsulation Mechanisms . . . . . . . . . . . . . . 4 70 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 71 4.1. Prior-knowledge KEM-Auth . . . . . . . . . . . . . . . . 6 72 5. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 6. Handshake protocol . . . . . . . . . . . . . . . . . . . . . 8 74 6.1. Key Exchange Messages . . . . . . . . . . . . . . . . . . 9 75 6.1.1. Client Hello . . . . . . . . . . . . . . . . . . . . 9 76 6.1.2. Server Hello . . . . . . . . . . . . . . . . . . . . 10 77 6.1.3. Hello Retry Request . . . . . . . . . . . . . . . . . 10 78 6.1.4. Extensions . . . . . . . . . . . . . . . . . . . . . 10 79 6.1.5. Implicit Authentication Messages . . . . . . . . . . 12 80 6.1.6. Certificate . . . . . . . . . . . . . . . . . . . . . 13 81 6.1.7. KEM Encapsulation . . . . . . . . . . . . . . . . . . 13 82 6.1.8. Explicit Authentication Messages . . . . . . . . . . 14 83 7. Cryptographic Computations . . . . . . . . . . . . . . . . . 15 84 7.1. Key schedule . . . . . . . . . . . . . . . . . . . . . . 15 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 8.1. Implicit authentication . . . . . . . . . . . . . . . . . 18 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 89 9.2. Informative References . . . . . . . . . . . . . . . . . 19 90 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 DISCLAIMER: This is a work-in-progress draft. 97 This document gives a construction for KEM-based authentication in 98 TLS 1.3. The overall design approach is a simple: usage of Key 99 Encapsulation Mechanisms (KEM) for certificate-based authentication. 100 Authentication happens via asymmetric cryptography by the usage of 101 KEMs advertised as the long-term KEM public keys in the Certificate. 103 TLS 1.3 is in essence a signed key exchange protocol (if using 104 certificate-based authentication). Authentication in TLS 1.3 is 105 achieved by signing the handshake transcript. KEM-based 106 authentication provides authentication by deriving a shared secret 107 that is encapsulated against the public key contained in the 108 certificate. Only the holder of the private key corresponding to the 109 certificate's public key can derive the same shared secret and thus 110 decrypt it's peers messages. 112 This approach is appropriate for endpoints that have KEM public keys. 113 Though this is currently rare, certificates could be issued with 114 (EC)DH public keys as specified for instance in [RFC8410], or using a 115 delegation mechanism, such as delegated credentials 116 [I-D.ietf-tls-subcerts]. 118 In this proposal we use the DH-based KEMs from [I-D.irtf-cfrg-hpke]. 119 We believe KEMs are especially worth discussing in the context of the 120 TLS protocol because NIST is in the process of standardizing post- 121 quantum KEM algorithms to replace "classic" key exchange (based on 122 elliptic curve or finite-field Diffie-Hellman [NISTPQC]). 124 This proposal draws inspiration from [I-D.ietf-tls-semistatic-dh], 125 which is in turn based on the OPTLS proposal for TLS 1.3 [KW16]. 126 However, these proposals require a non-interactive key exchange: they 127 combine the client's public key with the server's long-term key. 128 This imposes a requirement that the ephemeral and static keys use the 129 same algorithm, which this proposal does not require. Additionally, 130 there are no post-quantum proposals for a non-interactive key 131 exchange currently considered for standardization, while several KEMs 132 are on the way. 134 2. Requirements Notation 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in 139 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 140 capitals, as shown here. 142 3. Terminology 144 The following terms are used as they are in [RFC8446] 146 client: The endpoint initiating the TLS connection. 148 connection: A transport-layer connection between two endpoints. 150 endpoint: Either the client or server of the connection. 152 handshake: An initial negotiation between client and server that 153 establishes the parameters of their subsequent interactions within 154 TLS. 156 peer: An endpoint. When discussing a particular endpoint, "peer" 157 refers to the endpoint that is not the primary subject of discussion. 159 receiver: An endpoint that is receiving records. 161 sender: An endpoint that is transmitting records. 163 server: The endpoint that this did initiate the TLS connection. i.e. 164 the peer of the client. 166 3.1. Key Encapsulation Mechanisms 168 As this proposal relies heavily on KEMs, which are not originally 169 used by TLS, we will provide a brief overview of this primitive. 171 A Key Encapsulation Mechanism (KEM), defined as in 172 [I-D.irtf-cfrg-hpke] as an internal API, is a cryptographic primitive 173 that defines the methods "Encap" and "Decap": 175 "Encap(pkR)": Takes a public key, and produces a shared secret and 176 encapsulation. 178 "Decap(enc, skR)": Takes the encapsulation and the private key. 179 Returns the shared secret. 181 Note that we are using the internal API for KEMs as defined in 182 [I-D.irtf-cfrg-hpke]. 184 4. Protocol Overview 186 Figure 1 below shows the basic full KEM-authentication handshake: 188 Client Server 190 Key ^ ClientHello 191 Exch | + key_share 192 v + (kem)signature_algorithms 193 --------> 194 ServerHello ^ Key 195 + key_share v Exch 196 ^ Server 197 v Params 198 ^ ^ 199 Auth | | Auth 200 | {Certificate} --------> | 201 | <-------- {KEMEncapsulation} | 202 | {Finished} --------> | 203 | [Application Data*] --------> | 204 v <------- {Finished} | 205 v 206 [Application Data] <-------> [Application Data] 208 + Indicates noteworthy extensions sent in the 209 previously noted message. 210 * Indicates optional or situation-dependent 211 messages/extensions that are not always sent. 212 <> Indicates messages protected using keys 213 derived from a [sender]_handshake_traffic_secret. 214 {} Indicates messages protected using keys 215 derived from a 216 [sender]_authenticated_handshake_traffic_secret. 217 [] Indicates messages protected using keys 218 derived from [sender]_application_traffic_secret_N. 220 Figure 1: Message Flow for KEM-Authentication Handshake 222 When using KEMs for authentication, the handshake can be thought of 223 in four phases compared to the three ones from TLS 1.3. It achieves 224 both confidentiality and authentication (certificate-based). 226 After the Key Exchange and Server Parameters phase of TLS 1.3 227 handshake, the client and server exchange implicitly authenticated 228 messages. KEM-based authentication uses the same set of messages 229 every time that certificate-based authentication is needed. 230 Specifically: 232 * Certificate: The certificate of the endpoint and any per- 233 certificate extensions. This message is omitted by the client if 234 the server did not send CertificateRequest (thus indicating that 235 the client should not authenticate with a certificate). The 236 Certificate MUST include the long-term KEM public key. 238 * KEMEncapsulation: A key encapsulation against the certificate's 239 long-term public key, which yields an implicitly authenticated 240 shared secret. 242 Upon receiving the server's messages, the client responds with its 243 Authentication messages, namely Certificate and KEMEncapsulation (if 244 requested). If client authentication was not requested, the Client 245 sends its Finished message. 247 Upon receiving the client's messages, the server responds with its 248 Finished message, which achieves explicit authentication. Upon 249 receiving the server's Finished message, the client achieves explicit 250 authentication. 252 Application Data MUST NOT be sent prior to sending the Finished 253 message, except as specified in Section 2.3 of [RFC8446]. Note that 254 while the client may send Application Data prior to receiving the 255 server's last explicit Authentication message, any data sent at that 256 point is, of course, being sent to an implicitly authenticated peer. 257 It is worth noting that Application Data sent prior to receiving the 258 server's last Authentication message can be subject to a client 259 downgrade attack. Full downgrade resilience is only achieved when 260 explicit authentication is achieved: when the Client receives the 261 Finished message from the Server. 263 4.1. Prior-knowledge KEM-Auth 265 Given the added number of round-trips of KEM-based auth compared to 266 the TLS 1.3, the handshake can be improved by the usage of pre- 267 distributed KEM authentication keys to achieve explicit 268 authentication and full downgrade resilience as early as possible. A 269 peer's long-term KEM authentication key can be cached in advance, as 270 well. 272 Figure 2 below shows a pair of handshakes in which the first 273 handshake establishes cached information and the second handshake 274 uses it: 276 Client Server 278 Key ^ ClientHello 279 Exch | + key_share 280 v + (kem)signature_algorithms 281 --------> 282 ServerHello ^ Key 283 + (kem)key_share v Exch 284 ^ Server 285 v Params 286 ^ ^ 287 Auth | | Auth 288 | {Certificate} --------> | 289 | <-------- {KEMEncapsulation} | 290 | {Finished} --------> | 291 | [Cached Server Certificate] | 292 | [Application Data*] --------> | 293 v <------- {Finished} | 294 v 295 [Application Data] <-------> [Application Data] 297 Client Server 299 Key ^ ClientHello 300 Exch | + key_share 301 & | + stored_auth_key_extension 302 Auth | + kem_encapsulation_extension 303 | + (kem)signature_algorithms 304 | --------> ServerHello ^ Key 305 | + (kem)key_share | Exch, 306 | + {stored_auth_key_extension} | Auth & 307 | {EncryptedExtensions} | Server 308 | {KEMEncapsulation} | Params 309 | <-------- {Finished} v 310 | <-------- [Application Data*] 311 v {Finished} --------> 313 [Application Data] <-------> [Application Data] 315 In some applications, such as in a VPN, the client already knows that 316 the server will require mutual authentication. This means that a 317 client can proactively authenticate by sending its certificate as 318 early in the handshake as possible. The client's certificate has to 319 be sent encrypted by using the shared secret derived from the 320 kem_encapsulation message. 322 5. Negotiation 324 Clients will indicate support for this mode by negotiating it as if 325 it were a signature scheme (part of the "SignatureScheme" extension). 326 We thus add these new signature scheme values (even though, they are 327 not signature schemes) for the KEMs defined in [I-D.irtf-cfrg-hpke] 328 Section 7.1. Note that we will be only using their internal KEM's 329 API defined there. 331 enum { 332 dhkem_p256_sha256 => TBD, 333 dhkem_p384_sha384 => TBD, 334 dhkem_p521_sha512 => TBD, 335 dhkem_x25519_sha256 => TBD, 336 dhkem_x448_sha512 => TBD, 337 } 339 When present in the "signature_algorithms" extension, these values 340 indicate KEM-Auth with the specified key exchange mode. These values 341 MUST NOT appear in "signature_algorithms_cert". 343 In order to be used for KEM-Auth, this algorithms have to be added to 344 the "SignatureScheme" extension sent in the ClientHello message, and 345 supported by the server. 347 6. Handshake protocol 349 The handshake protocol is used to negotiate the security parameters 350 of a connection, as in TLS 1.3. It uses the same messages, expect 351 for the addition of a "KEMEncapsulation" message and does not use the 352 "CertificateVerify" one. 354 enum { 355 ... 356 encrypted_extensions(8), 357 certificate(11), 358 kem_encapsulation(tbd), 359 certificate_request(13), 360 ... 361 message_hash(254), 362 (255) 363 } HandshakeType; 365 struct { 366 HandshakeType msg_type; /* handshake type */ 367 uint24 length; /* remaining bytes in message */ 368 select (Handshake.msg_type) { 369 ... 370 case encrypted_extensions: EncryptedExtensions; 371 case certificate_request: CertificateRequest; 372 case certificate: Certificate; 373 case kem_encapsulation: KEMEncapsulation; 374 ... 375 }; 376 } Handshake; 378 Protocol messages MUST be sent in the order defined in Section 4. A 379 peer which receives a handshake message in an unexpected order MUST 380 abort the handshake with an "unexpected_message" alert. 382 6.1. Key Exchange Messages 384 KEM-Auth uses the same key exchange messages as TLS 1.3 with this 385 exceptions: 387 * Two extensions can be added to the "ClientHello" message: 388 "stored_auth_key" and "kem_encapsulation". 390 * One extensions can be added to the "ServerHello" message: 391 "stored_auth_key". 393 KEM-Auth preserves the same cryptographic negotiation with the 394 addition of the KEM algorithms to the "signature_algorithms". 396 6.1.1. Client Hello 398 KEM-Auth uses the "ClientHello" message as described for TLS 1.3. 399 When used in a pre-distributed mode, however, two extensions are 400 mandatory: "stored_auth_key" and "kem_encapsulation" for server 401 authentication. This extensions are described later in the document. 403 Note that in KEM-Auth with pre-distributed information, the client's 404 "Certificate" message gets send alongside the "ClientHello" one for 405 mutual authentication. 407 6.1.2. Server Hello 409 KEM-Auth uses the "ServerHello" message as described for TLS 1.3. 410 When used in a pre-distributed mode, however, one extension is 411 mandatory: "stored_auth_key" for server authentication. This 412 extension is described later in the document. 414 When the ServerHello message is received: 416 * the client and server derive handshake traffic secrets 417 "client_handshake_traffic_secret" and 418 "server_handshake_traffic_secret" which are used to encrypt 419 subsequent flows in the handshake 421 * the "handshake secret" is derived: "dHS" which is kept as the 422 current secret state of the key schedule. 424 Refer to Section 8.1 for information on how to derive this secrets. 426 6.1.3. Hello Retry Request 428 KEM-Auth uses the "ServerHello" message as described for TLS 1.3. 429 When used in a pre-distributed mode for mutual authentication, a 430 "HelloRetryRequest" message can be sent, but the client's 431 "Certificate" message is ignored. 433 6.1.4. Extensions 435 A number of KEM-Auth messages contain tag-length-value encoded 436 extensions structures. We are adding those extensions to the 437 "ExtensionType" list from TLS 1.3. 439 enum { 440 ... 441 signature_algorithms_cert(50), /* RFC 8446 */ 442 key_share(51), /* RFC 8446 */ 443 kem_encapsulation (TBD), /* RFC TBD */ 444 stored_auth_key(TBD), /* RFC TBD */ 445 (65535) 446 } ExtensionType; 448 The table below indicates the messages where a given extension may 449 appear: 451 +---------------------------------------+-------------+ 452 | Extension | KEM-Auth | 453 +---------------------------------------+-------------+ 454 | stored_auth_key [RFCTBD] | CH, SH | 455 | | | 456 | kem_encapsulation [RFCTBD] | CH | 457 | | | 458 +---------------------------------------+-------------+ 460 6.1.4.1. Stored Auth Key 462 This document defines a new extension type ("stored_auth_key(TBD)"), 463 which is used in ClientHello and ServerHello messages. The extension 464 type is specified as follows. 466 struct { 467 stored_auth_key(TBD), (65535) 468 } ExtensionType; 470 The extension_data field of this extension, when included in the 471 ClientHello, MUST contain the "StoredInformation" structure. The 472 client MAY send multiple StoredObjects of the same 473 "StoredInformationType". This may, for example, be the case when the 474 client has cached multiple public keys from the server. 476 enum { 477 uint8 pub_key = 0; 478 } StoredInformationType; 480 struct { 481 select (type) { 482 case client: 483 StoredInformationType type; 484 opaque hash_value<1..255>; 485 case server: 486 StoredInformationType type; 487 } body; 488 } StoredObject; 490 struct { 491 StoredObject stored_auth_key<1..2^16-1>; 492 } StoredInformation; 494 This document defines the following type: 496 * 'pub_key' type for not sending the complete server certificate 497 message: With the type field set to 'pub_key', the client MUST 498 include the fingerprint of the Public Key of the end-entity 499 certificate in the hash_value field. For this type, the 500 fingerprint MUST be calculated using the procedure below, using 501 the Public Key (represented using the Subject Public Key Info 502 representation, as defined in [RFC5869], Section 4.1.2.7) as the 503 input data. 505 The fingerprint calculation proceeds this way: 507 1. Compute the SHA-256 hash of the input data. Note that the 508 computed hash only covers the input data structure (and not any 509 type and length information of the record layer). 511 2. Use the output of the SHA-256 hash. 513 The purpose of the fingerprint provided by the client is to help the 514 server select the correct information. The fingerprint identifies 515 the server public key (and the corresponding private key) for use 516 with the rest of the handshake. 518 If this extension is not present, the "kem_encapsulation" extension 519 MUST not be present as well. If present, it will be ignored. 521 6.1.5. Implicit Authentication Messages 523 As discussed, KEM-Auth generally uses a common set of messages for 524 implicit authentication and key confirmation: Certificate and 525 KEMEncapsulation. The CertificateVerify message MUST NOT be sent. 527 The computations for the Authentication messages take the following 528 inputs: 530 * The certificate and authentication key to be used. 532 * A Handshake Context consisting of the set of messages to be 533 included in the transcript hash. 535 * A Shared Secret Key (from the key exchange operations) to be used 536 to compute an authenticated handshake shared key. 538 * A Handshake Context consisting of the set of messages to be 539 included in the transcript hash. 541 Based on these inputs, the messages then contain: 543 Certificate: The certificate to be used for authentication, and any 544 supporting certificates in the chain. 546 KEMEncapsulation: The KEM encapsulation against the end-entity 547 certificate's public key(s). 549 KEM-Auth follows the TLS 1.3 key schedule, which applies a sequence 550 of HKDF operations to the Handshake Secret Keys and the handshake 551 context to derive: 553 * the client and server authenticated handshake traffic secrets 554 "client_handshake_authenticated_traffic_secret" and 555 "server_handshake_authenticated_traffic_secret" which are used to 556 encrypt subsequent flows in the handshake 558 * updated secret state "dAHS" of the key schedule. 560 * a Master Key. 562 6.1.6. Certificate 564 KEM-Auth uses the same "Certificate" message as TLS 1.3. 566 The end-entity "Certificate" or the "RawPublicKey" MUST contain or be 567 a KEM public key. 569 Note that we are only specifying here the algorithms in the end- 570 entity "Certificate". All certificates provided by the server or 571 client MUST be signed by an authentication algorithm advertised by 572 the server or client. 574 6.1.7. KEM Encapsulation 576 This message is used to provide implicit proof that an endpoint 577 possesses the private key(s) corresponding to its certificate by 578 sending the appropriate parameters that will be used to calculate the 579 implicitly authenticated shared secret. 581 The calculation of the shared secret also provides integrity for the 582 handshake up to this point. Servers MUST send this message when 583 authenticating via a certificate. Clients MUST send this message 584 whenever authenticating via a certificate (i.e., when the 585 "Certificate" message is non-empty). When sent, this message MUST 586 appear immediately after the "Certificate" message has been received 587 and prior to the "Finished" message. 589 Structure of this message: 591 struct { 592 opaque encapsulation<0..2^16-1>; 593 } KEMEncapsulation; 595 The encapsulation field is the result of a "Encaps(pkR)" function. 596 The Encapsulation() function will also result on a shared secret 597 ("ssS" or "ssC", depending on the Server or Client executing it 598 respectively) which is used to derive the "AHS" or "MS" secrets. 600 If the KEMEncapsulation message is sent by a server, the 601 authentication algorithm MUST be one offered in the client's 602 "signature_algorithms" extension unless no valid certificate chain 603 can be produced without unsupported algorithms. 605 If sent by a client, the authentication algorithm used in the 606 signature MUST be one of those present in the 607 "supported_signature_algorithms" field of the "signature_algorithms" 608 extension in the CertificateRequest message. 610 In addition, the authentication algorithm MUST be compatible with the 611 key(s) in the sender's end-entity certificate. 613 The receiver of a "KEMEncapsulation" message MUST perform the 614 "Decap(enc, skR)" operation by using the sent encapsulation and the 615 private key of the public key advertised in the end-entity 616 certificate sent. The "Decap(enc, skR)" function will also result on 617 a shared secret ("ssS" or "ssC", depending on the Server or Client 618 executing it respectively) which is used to derive the "AHS" or "MS" 619 secrets. 621 6.1.8. Explicit Authentication Messages 623 As discussed, KEM-Auth generally uses a message for explicit 624 authentication: Finished message. Note that in the non pre- 625 distributed mode, KEM-Auth achieves explicit authentication only when 626 the server sends the final "Finished" message (the client is only 627 implicitly authenticated when they send their "Finished" message). 628 In a pre-distributed mode, the server achieves explicit 629 authentication when sending their "Finished" message (one round-trip 630 earlier) and the client, in turn, when they send their "Finished" 631 message (one round-trip earlier). Full downgrade resilience and 632 forward secrecy is achieved once the KEM-Auth handshake completes. 634 The key used to compute the Finished message is computed from the 635 Master Key using HKDF. Specifically: 637 server/client_finished_key = 638 HKDF-Expand-Label(MasterKey, 639 server/client_label, 640 "", Hash.length) 641 server_label = "tls13 server finished" 642 client_label = "tls13 client finished" 643 Structure of this message: 645 struct { 646 opaque verify_data[Hash.length]; 647 } Finished; 649 The verify_data value is computed as follows: 651 server/client_verify_data = 652 HMAC(server/client_finished_key, 653 Transcript-Hash(Handshake Context, 654 Certificate*, 655 KEMEncapsulation*, 656 Finished**) 658 * Only included if present. ** The party who last sends the finished 659 message in terms of flights includes the other party's Finished 660 message. 662 Any records following a Finished message MUST be encrypted under the 663 appropriate application traffic key as described in TLS 1.3. In 664 particular, this includes any alerts sent by the server in response 665 to client Certificate and KEMEncapsulation messages. 667 7. Cryptographic Computations 669 The KEM-Auth handshake establishes three input secrets which are 670 combined to create the actual working keying material, as detailed 671 below. The key derivation process incorporates both the input 672 secrets and the handshake transcript. Note that because the 673 handshake transcript includes the random values from the Hello 674 messages, any given handshake will have different traffic secrets, 675 even if the same input secrets are used. 677 7.1. Key schedule 679 KEM-Auth uses the same HKDF-Extract and HKDF-Expand functions as 680 defined by TLS 1.3, in turn defined by [RFC5869]. 682 Keys are derived from two input secrets using the HKDF-Extract and 683 Derive-Secret functions. The general pattern for adding a new secret 684 is to use HKDF-Extract with the Salt being the current secret state 685 and the Input Keying Material (IKM) being the new secret to be added. 687 The key schedule proceeds as follows: 689 0 690 | 691 v 692 PSK -> HKDF-Extract = Early Secret 693 | 694 +--> Derive-Secret(., "ext binder" | "res binder", "") 695 | = binder_key 696 | 697 +--> Derive-Secret(., "c e traffic", ClientHello) 698 | = client_early_traffic_secret 699 | 700 +--> Derive-Secret(., "e exp master", ClientHello) 701 | = early_exporter_master_secret 702 v 703 Derive-Secret(., "derived", "") 704 | 705 v 706 (EC)DHE -> HKDF-Extract = Handshake Secret 707 | 708 +--> Derive-Secret(., "c hs traffic", 709 | ClientHello...ServerHello) 710 | = client_handshake_traffic_secret 711 | 712 +--> Derive-Secret(., "s hs traffic", 713 | ClientHello...ServerHello) 714 | = server_handshake_traffic_secret 715 v 716 Derive-Secret(., "derived", "") = dHS 717 | 718 v 719 SSs -> HKDF-Extract = Authenticated Handshake Secret 720 | 721 +--> Derive-Secret(., "c ahs traffic", 722 | ClientHello...KEMEncapsulation) 723 | = client_handshake_authenticated_traffic_secret 724 | 725 +--> Derive-Secret(., "s ahs traffic", 726 | ClientHello...KEMEncapsulation) 727 | = server_handshake_authenticated_traffic_secret 728 v 729 Derive-Secret(., "derived", "") = AHS 730 | 731 v 732 SSc||0 * -> HKDF-Extract = Master Secret 733 | 734 +--> Derive-Secret(., "c ap traffic", 735 | ClientHello...server Finished) 736 | = client_application_traffic_secret_0 737 | 738 +--> Derive-Secret(., "s ap traffic", 739 | ClientHello...server Finished) 740 | = server_application_traffic_secret_0 741 | 742 +--> Derive-Secret(., "exp master", 743 | ClientHello...server Finished) 744 | = exporter_master_secret 745 | 746 +--> Derive-Secret(., "res master", 747 ClientHello...client Finished) 748 = resumption_master_secret 750 The * means that if client authentication was requested the `SSc` value should 751 be used. Otherwise, the `0` value is used. 753 The operations to compute "SSs" or "SSc" from the client are: 755 SSs, encapsulation <- Encap(public_key_server) 756 SSc <- Decap(encapsulation, private_key_client) 758 The operations to compute "SSs" or "SSc" from the server are: 760 SSs <- Decap(encapsulation, priavte_key_server) 761 SSc, encapsulation <- Encap(public_key_client) 763 8. Security Considerations 765 * The academic works proposing KEM-Auth contain a in-depth technical 766 discussion of and a proof of the security of the handshake 767 protocol without client authentication [KEMTLS]. The work 768 proposing the variant protocol [KEMTLSPDK] with pre-distributed 769 public keys has a proof for both unilaterally and mutually 770 authenticated handshakes. 772 * Application Data sent prior to receiving the server's last 773 explicit authentication message (the Finished message) can be 774 subject to a client downgrade attack, and has weaker forward 775 secrecy compared to TLS 1.3. Full downgrade resilience and 776 forward secrecy is achieved once the handshake completes. 778 * The client's certificate is kept secret from active observers by 779 the derivation of the "client_authenticated_handshake_secret", 780 which ensures that only the intended server can read the client's 781 identity. 783 * When the client opportunistically sends its certificate, it is not 784 encrypted under a forward-secure key. This has similar 785 considerations and trade-offs as 0-RTT data. If it is a replayed 786 message, there are no expected consequences for security as the 787 malicious replayer will not be able to decapsulate the shared 788 secret. 790 * A client that opportunistically sends its certificate, SHOULD send 791 it encrypted with a ciphertext that it knows the server will 792 accept. Otherwise, it will fail. 794 8.1. Implicit authentication 796 Because preserving a 1/1.5RTT handshake in KEM-Auth requires the 797 client to send its request in the same flight when the "ServerHello" 798 message is received, it can not yet have explicitly authenticated the 799 server. However, through the inclusion of the key encapsulated to 800 the server's long-term secret, only an authentic server should be 801 able to decrypt these messages. 803 However, the client can not have received confirmation that the 804 server's choices for symmetric encryption, as specified in the 805 "ServerHello" message, were authentic. These are not authenticated 806 until the "Finished" message from the server arrived. This may allow 807 an adversary to downgrade the symmetric algorithms, but only to what 808 the client is willing to accept. If such an attack occurs, the 809 handshake will also never successfully complete and no data can be 810 sent back. 812 If the client trusts the symmetric algorithms advertised in its 813 "ClientHello" message, this should not be a concern. A client MUST 814 NOT accept any cryptographic parameters it does not include in its 815 own "ClientHello" message. 817 If client authentication is used, explicit authentication is reached 818 before any application data, on either client or server side, is 819 transmitted. 821 9. References 823 9.1. Normative References 825 [I-D.ietf-tls-semistatic-dh] 826 Rescorla, E., Sullivan, N., and C. A. Wood, "Semi-Static 827 Diffie-Hellman Key Establishment for TLS 1.3", Work in 828 Progress, Internet-Draft, draft-ietf-tls-semistatic-dh-01, 829 7 March 2020, . 832 [I-D.ietf-tls-subcerts] 833 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 834 "Delegated Credentials for TLS", Work in Progress, 835 Internet-Draft, draft-ietf-tls-subcerts-10, 24 January 836 2021, . 839 [I-D.irtf-cfrg-hpke] 840 Barnes, R. L., Bhargavan, K., Lipp, B., and C. A. Wood, 841 "Hybrid Public Key Encryption", Work in Progress, 842 Internet-Draft, draft-irtf-cfrg-hpke-10, 7 July 2021, 843 . 846 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 847 Requirement Levels", BCP 14, RFC 2119, 848 DOI 10.17487/RFC2119, March 1997, 849 . 851 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 852 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 853 May 2017, . 855 [RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for 856 Ed25519, Ed448, X25519, and X448 for Use in the Internet 857 X.509 Public Key Infrastructure", RFC 8410, 858 DOI 10.17487/RFC8410, August 2018, 859 . 861 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 862 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 863 . 865 9.2. Informative References 867 [KEMTLS] Stebila, D., Schwabe, P., and T. Wiggers, "Post-Quantum 868 TLS without Handshake Signatures", 869 DOI 10.1145/3372297.3423350, IACR 870 ePrint https://ia.cr/2020/534, November 2020, 871 . 873 [KEMTLSPDK] 874 Stebila, D., Schwabe, P., and T. Wiggers, "More Efficient 875 KEMTLS with Pre-Shared Keys", May 2021. 877 [KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3", 878 Proceedings of Euro S"P 2016 , 2016, 879 . 881 [NISTPQC] NIST, ., "Post-Quantum Cryptography Standardization", 882 2020. 884 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 885 Housley, R., and W. Polk, "Internet X.509 Public Key 886 Infrastructure Certificate and Certificate Revocation List 887 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 888 . 890 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 891 Key Derivation Function (HKDF)", RFC 5869, 892 DOI 10.17487/RFC5869, May 2010, 893 . 895 Appendix A. Acknowledgements 897 This work has been supported by the European Research Council through 898 Starting Grant No. 805031 (EPOQUE). 900 Authors' Addresses 902 SofĂ­a Celi 903 Cloudflare 905 Email: cherenkov@riseup.net 907 Peter Schwabe 908 Radboud University & MPI S&P 910 Email: peter@cryptojedi.org 912 Douglas Stebila 913 University of Waterloo 915 Email: dstebila@uwaterloo.ca 917 Nick Sullivan 918 Cloudflare 920 Email: nick@cloudflare.com 922 Thom Wiggers 923 Radboud University 924 Email: thom@thomwiggers.nl