idnits 2.17.00 (12 Aug 2021) /tmp/idnits34283/draft-ietf-tls-tls13-cert-with-extern-psk-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 22, 2019) is 881 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-hoffman-c2pq-06 == Outdated reference: A later version (-08) exists of draft-ietf-tls-external-psk-importer-02 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Housley 3 Internet-Draft Vigil Security 4 Intended status: Experimental December 22, 2019 5 Expires: June 24, 2020 7 TLS 1.3 Extension for Certificate-based Authentication with an External 8 Pre-Shared Key 9 draft-ietf-tls-tls13-cert-with-extern-psk-05 11 Abstract 13 This document specifies a TLS 1.3 extension that allows a server to 14 authenticate with a combination of a certificate and an external pre- 15 shared key (PSK). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 24, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 The TLS 1.3 [RFC8446] handshake protocol provides two mutually 52 exclusive forms of server authentication. First, the server can be 53 authenticated by providing a signature certificate and creating a 54 valid digital signature to demonstrate that it possesses the 55 corresponding private key. Second, the server can be authenticated 56 by demonstrating that it possesses a pre-shared key (PSK) that was 57 established by a previous handshake. A PSK that is established in 58 this fashion is called a resumption PSK. A PSK that is established 59 by any other means is called an external PSK. This document 60 specifies a TLS 1.3 extension permitting certificate-based server 61 authentication to be combined with an external PSK as an input to the 62 TLS 1.3 key schedule. 64 Several implementors wanted to gain more experience with this 65 specification before producing a standards-track RFC. As a result, 66 this specification is being published as an Experimental RFC to 67 enable interoperable implementations and gain deployment and 68 operational experience. 70 2. Terminology 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 74 "OPTIONAL" in this document are to be interpreted as described in 75 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 76 capitals, as shown here. 78 3. Motivation and Design Rationale 80 The development of a large-scale quantum computer would pose a 81 serious challenge for the cryptographic algorithms that are widely 82 deployed today, including the digital signature algorithms that are 83 used to authenticate the server in the TLS 1.3 handshake protocol. 84 It is an open question whether or not it is feasible to build a 85 large-scale quantum computer, and if so, when that might happen. 86 However, if such a quantum computer is invented, many of the 87 cryptographic algorithms and the security protocols that use them 88 would become vulnerable. 90 The TLS 1.3 handshake protocol employs key agreement algorithms and 91 digital signature algorithms that could be broken by the development 92 of a large-scale quantum computer [I-D.hoffman-c2pq]. The key 93 agreement algorithms include Diffie-Hellman (DH) [DH1977] and 94 Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]; the digital 95 signature algorithms inclue RSA [RFC8017] and Elliptic Curve Digital 96 Signature Algorithm (ECDSA) [FIPS186]. As a result, an adversary 97 that stores a TLS 1.3 handshake protocol exchange today could decrypt 98 the associated encrypted communications in the future when a large- 99 scale quantum computer becomes available. 101 In the near-term, this document describes TLS 1.3 extension to 102 protect today's communications from the future invention of a large- 103 scale quantum computer by providing a strong external PSK as an input 104 to the TLS 1.3 key schedule while preserving the authentication 105 provided by the existing certificate and digital signature 106 mechanisms. 108 4. Extension Overview 110 This section provides a brief overview of the 111 "tls_cert_with_extern_psk" extension. 113 The client includes the "tls_cert_with_extern_psk" extension in the 114 ClientHello message. The "tls_cert_with_extern_psk" extension MUST 115 be accompanied by the "key_share", "psk_key_exchange_modes", and 116 "pre_shared_key" extensions. The client MAY also find it useful to 117 include the "supported_groups" extension. Since the 118 "tls_cert_with_extern_psk" extension is intended to be used only with 119 initial handshakes, it MUST NOT be sent alongside the "early_data" 120 extension. These extensions are all described in Section 4.2 of 121 [RFC8446], which also requires the "pre_shared_key" extension to be 122 the last extension in the ClientHello message. 124 If the client includes both the "tls_cert_with_extern_psk" extension 125 and the "early_data" extension, then the server MUST terminate the 126 connection with an "illegal_parameter" alert. 128 If the server is willing to use one of the external PSKs listed in 129 the "pre_shared_key" extension and perform certificate-based 130 authentication, then the server includes the 131 "tls_cert_with_extern_psk" extension in the ServerHello message. The 132 "tls_cert_with_extern_psk" extension MUST be accompanied by the 133 "key_share" and "pre_shared_key" extensions. If none of the external 134 PSKs in the list provided by the client is acceptable to the server, 135 then the "tls_cert_with_extern_psk" extension is omitted from the 136 ServerHello message. 138 When the "tls_cert_with_extern_psk" extension is successfully 139 negotiated, the TLS 1.3 key schedule processing includes both the 140 selected external PSK and the (EC)DHE shared secret value. As a 141 result, the Early Secret, Handshake Secret, and Master Secret values 142 all depend upon the value of the selected external PSK. Of course, 143 the Early Secret does not depend upon the (EC)DHE shared secret. 145 The authentication of the server and optional authentication of the 146 client depend upon the ability to generate a signature that can be 147 validated with the public key in their certificates. The 148 authentication processing is not changed in any way by the selected 149 external PSK. 151 Each external PSK is associated with a single hash algorithm, which 152 is required by Section 4.2.11 of [RFC8446]. The hash algorithm MUST 153 be set when the PSK is established, with a default of SHA-256. 155 5. Certificate with External PSK Extension 157 This section specifies the "tls_cert_with_extern_psk" extension, 158 which MAY appear in the ClientHello message and ServerHello message. 159 It MUST NOT appear in any other messages. The 160 "tls_cert_with_extern_psk" extension MUST NOT appear in the 161 ServerHello message unless the "tls_cert_with_extern_psk" extension 162 appeared in the preceding ClientHello message. If an implementation 163 recognizes the "tls_cert_with_extern_psk" extension and receives it 164 in any other message, then the implementation MUST abort the 165 handshake with an "illegal_parameter" alert. 167 The general extension mechanisms enable clients and servers to 168 negotiate the use of specific extensions. Clients request extended 169 functionality from servers with the extensions field in the 170 ClientHello message. If the server responds with a HelloRetryRequest 171 message, then the client sends another ClientHello message as 172 described in Section 4.1.2 of [RFC8446], including the same 173 "tls_cert_with_extern_psk" extension as the original ClientHello 174 message, or aborts the handshake. 176 Many server extensions are carried in the EncryptedExtensions 177 message; however, the "tls_cert_with_extern_psk" extension is carried 178 in the ServerHello message. Successful negotiation of the 179 "tls_cert_with_extern_psk" extension affects the key used for 180 encryption, so it cannot be carried in the EncryptedExtensions 181 message. Therefore, the "tls_cert_with_extern_psk" extension is only 182 present in the ServerHello message if the server recognizes the 183 "tls_cert_with_extern_psk" extension and the server possesses one of 184 the external PSKs offered by the client in the "pre_shared_key" 185 extension in the ClientHello message. 187 The Extension structure is defined in [RFC8446]; it is repeated here 188 for convenience. 190 struct { 191 ExtensionType extension_type; 192 opaque extension_data<0..2^16-1>; 193 } Extension; 195 The "extension_type" identifies the particular extension type, and 196 the "extension_data" contains information specific to the particular 197 extension type. 199 This document specifies the "tls_cert_with_extern_psk" extension, 200 adding one new type to ExtensionType: 202 enum { 203 tls_cert_with_extern_psk(TBD), (65535) 204 } ExtensionType; 206 The "tls_cert_with_extern_psk" extension is relevant when the client 207 and server possess an external PSK in common that can be used as an 208 input to the TLS 1.3 key schedule. The "tls_cert_with_extern_psk" 209 extension is essentially a flag to use the external PSK in the key 210 schedule, and it has the following syntax: 212 struct { 213 select (Handshake.msg_type) { 214 case client_hello: Empty; 215 case server_hello: Empty; 216 }; 217 } CertWithExternPSK; 219 5.1. Companion Extensions 221 Section 4 lists the extensions that are required to accompany the 222 "tls_cert_with_extern_psk" extension. Most of those extension are 223 used in the usual manner. This section discusses the impacts on the 224 extensions that are affected the presence of the 225 "tls_cert_with_extern_psk" extension. 227 The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of 228 [RFC8446]. The "psk_key_exchange_modes" extension restricts the use 229 of both the PSKs offered in this ClientHello and those that the 230 server might supply via a subsequent NewSessionTicket. As a result, 231 when the "psk_key_exchange_modes" extension is included in the 232 ClientHello message, clients MUST include psk_dhe_ke mode. In 233 addition, clients MAY also include psk_ke mode to support a 234 subsequent NewSessionTicket. When the "psk_key_exchange_modes" 235 extension is included in the ServerHello message, servers MUST select 236 the psk_dhe_ke mode for the initial handshake. Servers MUST select a 237 key exchange mode that is listed by the client for subsequent 238 handshakes that include the resumption PSK from the initial 239 handshake. 241 The "pre_shared_key" extension is defined in Section 4.2.11 of 242 [RFC8446]. The syntax is repeated below for convenience. All of the 243 listed PSKs MUST be external PSKs. If a resumption PSK is listed 244 along with the "tls_cert_with_extern_psk" extension, the server MUST 245 abort the handshake with an "illegal_parameter" alert. 247 struct { 248 opaque identity<1..2^16-1>; 249 uint32 obfuscated_ticket_age; 250 } PskIdentity; 252 opaque PskBinderEntry<32..255>; 254 struct { 255 PskIdentity identities<7..2^16-1>; 256 PskBinderEntry binders<33..2^16-1>; 257 } OfferedPsks; 259 struct { 260 select (Handshake.msg_type) { 261 case client_hello: OfferedPsks; 262 case server_hello: uint16 selected_identity; 263 }; 264 } PreSharedKeyExtension; 266 The OfferedPsks contains the list of PSK identities and associated 267 binders for the external PSKs that the client is willing to use with 268 the server. 270 The identities are a list of external PSK identities that the client 271 is willing to negotiate with the server. Each external PSK has an 272 associated identity that is known to the client and the server; the 273 associated identities may be know to other parties as well. In 274 addition, the binder validation (see below) confirms that the client 275 and server have the same key associated with the identity. 277 The obfuscated_ticket_age is not used for external PSKs. As stated 278 in Section 4.2.11 of [RFC8446], clients SHOULD set this value to 0, 279 and servers MUST ignore the value. 281 The binders are a series of HMAC [RFC2104] values, one for each 282 external PSK offered by the client, in the same order as the 283 identities list. The HMAC value is computed using the binder_key, 284 which is derived from the external PSK, and a partial transcript of 285 the current handshake. Generation of the binder_key from the 286 external PSK is described in Section 7.1 of [RFC8446]. The partial 287 transcript of the current handshake includes a partial ClientHello up 288 to and including the PreSharedKeyExtension.identities field as 289 described in Section 4.2.11.2 of [RFC8446]. 291 The selected_identity contains the index of the external PSK identity 292 that the server selected from the list offered by the client. As 293 described in Section 4.2.11.2 of [RFC8446], the server MUST validate 294 the binder value that corresponds to the selected external PSK, and 295 if the binder does not validate, the server MUST abort the handshake 296 with an "illegal_parameter" alert. 298 5.2. Authentication 300 When the "tls_cert_with_extern_psk" extension is successfully 301 negotiated, authentication of the server depends upon the ability to 302 generate a signature that can be validated with the public key in the 303 server's certificate. This is accomplished by the server sending the 304 Certificate and CertificateVerify messages as described in Sections 305 4.4.2 and 4.4.3 of [RFC8446]. 307 TLS 1.3 does not permit the server to send a CertificateRequest 308 message when a PSK is being used. This restriction is removed when 309 the "tls_cert_with_extern_psk" extension is negotiated, allowing 310 certificate-based authentication for both the client and the server. 311 If certificate-based client authentication is desired, this is 312 accomplished by the client sending the Certificate and 313 CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 314 of [RFC8446]. 316 5.3. Keying Material 318 Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The 319 successful negotiation of the "tls_cert_with_extern_psk" extension 320 requires the key schedule processing to include both the external PSK 321 and the (EC)DHE shared secret value. 323 If the client and the server have different values associated with 324 the selected external PSK identifier, then the client and the server 325 will compute different values for every entry in the key schedule, 326 which will lead to the client aborting the handshake with a 327 "decrypt_error" alert. 329 6. IANA Considerations 331 IANA is requested to update the TLS ExtensionType Registry [IANA] to 332 include "tls_cert_with_extern_psk" with a value of TBD and the list 333 of messages "CH, SH" in which the "tls_cert_with_extern_psk" 334 extension may appear. 336 7. Security Considerations 338 The Security Considerations in [RFC8446] remain relevant. 340 TLS 1.3 [RFC8446] does not permit the server to send a 341 CertificateRequest message when a PSK is being used. This 342 restriction is removed when the "tls_cert_with_extern_psk" extension 343 is offered by the client and accepted by the server. However, TLS 344 1.3 does not permit an external PSK to be used in the same fashion as 345 a resumption PSK, and this extension does not alter those 346 restrictions. Thus, a certificate MUST NOT be used with a resumption 347 PSK. 349 Implementations must protect the external pre-shared key (PSK). 350 Compromise of the external PSK will make the encrypted session 351 content vulnerable to the future development of a large-scale quantum 352 computer. 354 Implementers should not transmit the same content on a connection 355 that is protected with an external PSK and a connection that is not. 356 Doing so may allow an eavesdropper to correlate the connections, 357 making the content vulnerable to the future invention of a large- 358 scale quantum computer. 360 Implementations must generate external PSKs with a secure key 361 management technique, such as pseudo-random generation of the key or 362 derivation of the key from one or more other secure keys. The use of 363 inadequate pseudo-random number generators (PRNGs) to generate 364 external PSKs can result in little or no security. An attacker may 365 find it much easier to reproduce the PRNG environment that produced 366 the external PSKs and search the resulting small set of 367 possibilities, rather than brute-force searching the whole key space. 368 The generation of quality random numbers is difficult. [RFC4086] 369 offers important guidance in this area. 371 If the external PSK is known to any party other than the client and 372 the server, then the external PSK MUST NOT be the sole basis for 373 authentication. The reasoning is explained in Section 4.2 of 374 [K2016]. When this extension is used, authentication is based on 375 certificates, not the external PSK. 377 In this extension, the external PSK preserves secrecy if the (EC)DH 378 key agreement is ever broken by cryptanalysis or the future invention 379 of a large-scale quantum computer. As long as the attacker does not 380 know the PSK and the key derivation algorithm remains unbroken, the 381 attacker cannot derive the session secrets even if they are able to 382 compute the (EC)DH shared secret. 384 TLS 1.3 key derivation makes use of the HKDF algorithm, which depends 385 upon the HMAC [RFC2104] construction and a hash function. This 386 extension provides the desired protection for the session secrets as 387 long as HMAC with the selected hash function is a pseudorandom 388 function (PRF) [GGM1986]. 390 In the future, if the (EC)DH key agreement is broken by cryptanalysis 391 or the invention of a large-scale quantum computer, the forward 392 secrecy advantages traditionally associated with ephemeral (EC)DH 393 keys will no longer be relevant. Although the ephemeral private keys 394 used during a given TLS session would be destroyed at the end of a 395 session, preventing the attacker from later accessing them, the 396 private keys would nevertheless be recoverable due to the break in 397 the algorithm. A more general notion of "secrecy after key material 398 is destroyed" would still be achievable using external PSKs, of 399 course, provided that they are managed in a way that ensures their 400 destruction when they are no longer needed, and with the assumption 401 that the algorithms that use the external PSKs remain quantum-safe. 403 This specification does not require that the external PSK is known 404 only by the client and server. The external PSK may be known to a 405 group. Since authentication depends on the public key in a 406 certificate, knowledge of the external PSK by other parties does not 407 enable impersonation. Since confidentiality depends on the shared 408 secret from (EC)DH, knowledge of the external PSK by other parties 409 does not enable eavesdropping. However, group members can record the 410 traffic of other members, and then decrypt it if they ever gain 411 access to a large-scale quantum computer. Also, when many parties 412 know the external PSK, there are many opportunities for theft of the 413 external PSK by an attacker. Once an attacker has the external PSK, 414 they can decrypt stored traffic if they ever gain access to a large- 415 scale quantum computer in the same manner as a legitimate group 416 member. 418 TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are 419 bound to a specific hash function and KDF. By contrast, TLS 1.2 420 [RFC5246] allows PSKs to be used with any hash function and the TLS 421 1.2 PRF. Thus, the safest approach is to use a PSK exclusively with 422 TLS 1.2 or exclusively with TLS 1.3. Given one PSK, one can derive a 423 PSK for exclusive use with TLS 1.2 and derive another PSK for 424 exclusive use with TLS 1.3 using the mechanism specified in 425 [I-D.ietf-tls-external-psk-importer]. 427 TLS 1.3 [RFC8446] has received careful security analysis, and some 428 informal reasoning shows that the addition of this extension does not 429 introduce any security defects. This extension requires the use of 430 certificates for authentication, but the processing of certificates 431 is unchanged by this extension. This extension places an external 432 PSK in the key schedule as part of the computation of the Early 433 Secret. In the initial handshake without this extension, the Early 434 Secret is computed as: 436 Early Secret = HKDF-Extract(0, 0) 438 With this extension, the Early Secret is computed as: 440 Early Secret = HKDF-Extract(External PSK, 0) 442 Any entropy contributed by the external PSK can only make the Early 443 Secret better; the External PSK cannot make it worse. For these two 444 reasons, TLS 1.3 continues to meet its security goals when this 445 extension is used. 447 8. Privacy Considerations 449 Appendix E.6 of [RFC8446] discusses identity exposure attacks on 450 PSKs. The guidance in this section remains relevant. 452 This extension makes use of external PSKs to improve resilience 453 against attackers that gain access to a large-scale quantum computer 454 in the future. This extension is always accompanied by the 455 "pre_shared_key" extension to provide the PSK identities in plaintext 456 in the ClientHello message. Passive observation of the these PSK 457 identities will aid an attacker to track users of this extension. 459 9. Acknowledgments 461 Many thanks to Liliya Akhmetzyanova, Christian Huitema, Ben Kaduk, 462 Geoffrey Keating, Hugo Krawczyk, Mirja Kuehlewind, Nikos 463 Mavrogiannopoulos, Nick Sullivan, Martin Thomson, and Peter Yee for 464 their review and comments; their efforts have improved this document. 466 10. References 468 10.1. Normative References 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, 472 DOI 10.17487/RFC2119, March 1997, 473 . 475 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 476 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 477 May 2017, . 479 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 480 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 481 . 483 10.2. Informative References 485 [DH1977] Diffie, W. and M. Hellman, "New Directions in 486 Cryptography", IEEE Transactions on Information 487 Theory V.IT-22 n.6, June 1977. 489 [FIPS186] National Institute of Standards and Technology, "Digital 490 Signature Standard (DSS)", Federal Information Processing 491 Standards Publication (FIPS PUB) 186-4, July 2013. 493 [GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to 494 construct random functions", J. ACM 1986 (33), pp. 495 792-807, 1986. 497 [I-D.hoffman-c2pq] 498 Hoffman, P., "The Transition from Classical to Post- 499 Quantum Cryptography", draft-hoffman-c2pq-06 (work in 500 progress), November 2019. 502 [I-D.ietf-tls-external-psk-importer] 503 Benjamin, D. and C. Wood, "Importing External PSKs for 504 TLS", draft-ietf-tls-external-psk-importer-02 (work in 505 progress), November 2019. 507 [IANA] "IANA Registry for TLS ExtensionType Values", n.d., 508 . 511 [IEEE1363] 512 Institute of Electrical and Electronics Engineers, "IEEE 513 Standard Specifications for Public-Key Cryptography", IEEE 514 Std 1363-2000, 2000. 516 [K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication 517 Compiler for Key Exchange (with Applications to Client 518 Authentication in TLS 1.3)", IACR ePrint 2016/711, August 519 2016. 521 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 522 Hashing for Message Authentication", RFC 2104, 523 DOI 10.17487/RFC2104, February 1997, 524 . 526 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 527 "Randomness Requirements for Security", BCP 106, RFC 4086, 528 DOI 10.17487/RFC4086, June 2005, 529 . 531 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 532 (TLS) Protocol Version 1.2", RFC 5246, 533 DOI 10.17487/RFC5246, August 2008, 534 . 536 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 537 "PKCS #1: RSA Cryptography Specifications Version 2.2", 538 RFC 8017, DOI 10.17487/RFC8017, November 2016, 539 . 541 Author's Address 543 Russ Housley 544 Vigil Security, LLC 545 516 Dranesville Road 546 Herndon, VA 20170 547 USA 549 Email: housley@vigilsec.com