idnits 2.17.00 (12 Aug 2021) /tmp/idnits33317/draft-ietf-tls-tls13-cert-with-extern-psk-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (November 17, 2019) is 916 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2104' is defined on line 504, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-hoffman-c2pq-05 == Outdated reference: A later version (-08) exists of draft-ietf-tls-external-psk-importer-01 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 4 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 November 17, 2019 5 Expires: May 20, 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-03 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 May 20, 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 2. Terminology 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 68 "OPTIONAL" in this document are to be interpreted as described in 69 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 70 capitals, as shown here. 72 3. Motivation and Design Rationale 74 The development of a large-scale quantum computer would pose a 75 serious challenge for the cryptographic algorithms that are widely 76 deployed today, including the digital signature algorithms that are 77 used to authenticate the server in the TLS 1.3 handshake protocol. 78 It is an open question whether or not it is feasible to build a 79 large-scale quantum computer, and if so, when that might happen. 80 However, if such a quantum computer is invented, many of the 81 cryptographic algorithms and the security protocols that use them 82 would become vulnerable. 84 The TLS 1.3 handshake protocol employs key agreement algorithms and 85 digital signature algorithms that could be broken by the development 86 of a large-scale quantum computer [I-D.hoffman-c2pq]. The key 87 agreement algorithms include Diffie-Hellman (DH) [DH1977] and 88 Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]; the digital 89 signature algorithms inclue RSA [RFC8017] and Elliptic Curve Digital 90 Signature Algorithm (ECDSA) [FIPS186]. As a result, an adversary 91 that stores a TLS 1.3 handshake protocol exchange today could decrypt 92 the associated encrypted communications in the future when a large- 93 scale quantum computer becomes available. 95 In the near-term, this document describes TLS 1.3 extension to 96 protect today's communications from the future invention of a large- 97 scale quantum computer by providing a strong external PSK as an input 98 to the TLS 1.3 key schedule while preserving the authentication 99 provided by the existing certificate and digital signature 100 mechanisms. 102 4. Extension Overview 104 This section provides a brief overview of the 105 "tls_cert_with_extern_psk" extension. 107 The client includes the "tls_cert_with_extern_psk" extension in the 108 ClientHello message. The "tls_cert_with_extern_psk" extension MUST 109 be accompanied by the "key_share", "psk_key_exchange_modes", and 110 "pre_shared_key" extensions. The client MAY also find it useful to 111 include the "supported_groups" extension. Since the 112 "tls_cert_with_extern_psk" extension is intended to be used only with 113 initial handshakes, it MUST NOT be sent alongside the "early_data" 114 extension. These extensions are all described in Section 4.2 of 115 [RFC8446], which also requires the "pre_shared_key" extension to be 116 the last extension in the ClientHello message. 118 If the server is willing to use one of the external PSKs listed in 119 the "pre_shared_key" extension and perform certificate-based 120 authentication, then the server includes the 121 "tls_cert_with_extern_psk" extension in the ServerHello message. The 122 "tls_cert_with_extern_psk" extension MUST be accompanied by the 123 "key_share" and "pre_shared_key" extensions. If none of the external 124 PSKs in the list provided by the client is acceptable to the server, 125 then the "tls_cert_with_extern_psk" extension is omitted from the 126 ServerHello message. 128 When the "tls_cert_with_extern_psk" extension is successfully 129 negotiated, the TLS 1.3 key schedule processing includes both the 130 selected external PSK and the (EC)DHE shared secret value. As a 131 result, the Early Secret, Handshake Secret, and Master Secret values 132 all depend upon the value of the selected external PSK. Of course, 133 the Early Secret does not depend upon the (EC)DHE shared secret. 135 The authentication of the server and optional authentication of the 136 client depend upon the ability to generate a signature that can be 137 validated with the public key in their certificates. The 138 authentication processing is not changed in any way by the selected 139 external PSK. 141 Each external PSK is associated with a single hash algorithm, which 142 is required by Section 4.2.11 of [RFC8446]. The hash algorithm MUST 143 be set when the PSK is established, with a default of SHA-256. 145 5. Certificate with External PSK Extension 147 This section specifies the "tls_cert_with_extern_psk" extension, 148 which MAY appear in the ClientHello message and ServerHello message. 149 It MUST NOT appear in any other messages. The 150 "tls_cert_with_extern_psk" extension MUST NOT appear in the 151 ServerHello message unless the "tls_cert_with_extern_psk" extension 152 appeared in the preceding ClientHello message. If an implementation 153 recognizes the "tls_cert_with_extern_psk" extension and receives it 154 in any other message, then the implementation MUST abort the 155 handshake with an "illegal_parameter" alert. 157 The general extension mechanisms enable clients and servers to 158 negotiate the use of specific extensions. Clients request extended 159 functionality from servers with the extensions field in the 160 ClientHello message. If the server responds with a HelloRetryRequest 161 message, then the client sends another ClientHello message as 162 described in Section 4.1.2 of [RFC8446], including the same 163 "tls_cert_with_extern_psk" extension as the original ClientHello 164 message or abort the handshake. 166 Many server extensions are carried in the EncryptedExtensions 167 message; however, the "tls_cert_with_extern_psk" extension is carried 168 in the ServerHello message. Successful negotiation of the 169 "tls_cert_with_extern_psk" extension affects the key used for 170 encryption, so it cannot be carried in the EncryptedExtensions 171 message. Therefore, the "tls_cert_with_extern_psk" extension is only 172 present in the ServerHello message if the server recognizes the 173 "tls_cert_with_extern_psk" extension and the server possesses one of 174 the external PSKs offered by the client in the "pre_shared_key" 175 extension in the ClientHello message. 177 The Extension structure is defined in [RFC8446]; it is repeated here 178 for convenience. 180 struct { 181 ExtensionType extension_type; 182 opaque extension_data<0..2^16-1>; 183 } Extension; 185 The "extension_type" identifies the particular extension type, and 186 the "extension_data" contains information specific to the particular 187 extension type. 189 This document specifies the "tls_cert_with_extern_psk" extension, 190 adding one new type to ExtensionType: 192 enum { 193 tls_cert_with_extern_psk(TBD), (65535) 194 } ExtensionType; 196 The "tls_cert_with_extern_psk" extension is relevant when the client 197 and server possess an external PSK in common that can be used as an 198 input to the TLS 1.3 key schedule. The "tls_cert_with_extern_psk" 199 extension is essentially a flag to use the external PSK in the key 200 schedule, and it has the following syntax: 202 struct { 203 select (Handshake.msg_type) { 204 case client_hello: Empty; 205 case server_hello: Empty; 206 }; 207 } CertWithExternPSK; 209 5.1. Companion Extensions 211 Section 4 lists the extensions that are required to accompany the 212 "tls_cert_with_extern_psk" extension. Most of those extension are 213 not impacted in any way. This section discusses the impacts on the 214 other extensions. 216 The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of 217 [RFC8446]. The "psk_key_exchange_modes" extension restricts both the 218 use of PSKs offered in this ClientHello and those which the server 219 might supply via a subsequent NewSessionTicket. As a result, when 220 the "psk_key_exchange_modes" extension is included in the ClientHello 221 message, clients MUST include psk_dhe_ke mode. In addition, clients 222 MAY also include psk_ke mode to support a subsequent 223 NewSessionTicket. When the "psk_key_exchange_modes" extension is 224 included in the ServerHello message, servers MUST select the 225 psk_dhe_ke mode for the initial handshake. Servers MUST select a key 226 exchange mode that is listed by the client for subsequent handshakes 227 that include the resumption PSK from the initial handshake. 229 The "pre_shared_key" extension is defined in Section 4.2.11 of 230 [RFC8446]. The syntax is repeated below for convenience. All of the 231 listed PSKs MUST be external PSKs. If a resumption PSK is listed 232 along with the "tls_cert_with_extern_psk" extension, the server MUST 233 abort the handshake with an "illegal_parameter" alert. 235 struct { 236 opaque identity<1..2^16-1>; 237 uint32 obfuscated_ticket_age; 238 } PskIdentity; 240 opaque PskBinderEntry<32..255>; 242 struct { 243 PskIdentity identities<7..2^16-1>; 244 PskBinderEntry binders<33..2^16-1>; 245 } OfferedPsks; 247 struct { 248 select (Handshake.msg_type) { 249 case client_hello: OfferedPsks; 250 case server_hello: uint16 selected_identity; 251 }; 252 } PreSharedKeyExtension; 254 The OfferedPsks contains the list of PSK identities and associated 255 binders for the external PSKs that the client is willing to use with 256 the server. 258 The identities are a list of external PSK identities that the client 259 is willing to negotiate with the server. Each external PSK has an 260 associated identity that is known to the client and the server; the 261 associated identities may be know to other parties as well. In 262 addition, the binder validation (see below) confirms that the client 263 and server have the same key associated with the identity. 265 The obfuscated_ticket_age is not used for external PSKs. As stated 266 in Section 4.2.11 of [RFC8446], clients SHOULD set this value to 0, 267 and servers MUST ignore the value. 269 The binders are a series of HMAC values, one for each external PSK 270 offered by the client, in the same order as the identities list. The 271 HMAC value is computed using the binder_key, which is derived from 272 the external PSK, and a partial transcript of the current handshake. 273 Generation of the binder_key from the external PSK is described in 274 Section 7.1 of [RFC8446]. The partial transcript of the current 275 handshake includes a partial ClientHello up to and including the 276 PreSharedKeyExtension.identities field as described in 277 Section 4.2.11.2 of [RFC8446]. 279 The selected_identity contains the index of the external PSK identity 280 that the server selected from the list offered by the client. As 281 described in Section 4.2.11.2 of [RFC8446], the server MUST validate 282 the binder value that corresponds to the selected external PSK, and 283 if the binder does not validate, the server MUST abort the handshake 284 with an "illegal_parameter" alert. 286 5.2. Authentication 288 When the "tls_cert_with_extern_psk" extension is successfully 289 negotiated, authentication of the server depends upon the ability to 290 generate a signature that can be validated with the public key in the 291 server's certificate. This is accomplished by the server sending the 292 Certificate and CertificateVerify messages as described in Sections 293 4.4.2 and 4.4.3 of [RFC8446]. 295 TLS 1.3 does not permit the server to send a CertificateRequest 296 message when a PSK is being used. This restriction is removed when 297 the "tls_cert_with_extern_psk" extension is negotiated, allowing 298 certificate-based authentication for both the client and the server. 299 If certificate-based client authentication is desired, this is 300 accomplished by the client sending the Certificate and 301 CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 302 of [RFC8446]. 304 5.3. Keying Material 306 Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The 307 successful negotiation of the "tls_cert_with_extern_psk" extension 308 requires the key schedule processing to include both the external PSK 309 and the (EC)DHE shared secret value. 311 If the client and the server have different values associated with 312 the selected external PSK identifier, then the client and the server 313 will compute different values for every entry in the key schedule, 314 which will lead to the client aborting the handshake with a 315 "decrypt_error" alert. 317 6. IANA Considerations 319 IANA is requested to update the TLS ExtensionType Registry to include 320 "tls_cert_with_extern_psk" with a value of TBD and the list of 321 messages "CH, SH" in which the "tls_cert_with_extern_psk" extension 322 may appear. 324 7. Security Considerations 326 The Security Considerations in [RFC8446] remain relevant. 328 TLS 1.3 [RFC8446] does not permit the server to send a 329 CertificateRequest message when a PSK is being used. This 330 restriction is removed when the "tls_cert_with_extern_psk" extension 331 is offered by the client and accepted by the server. However, TLS 332 1.3 does not permit an external PSK to be used in the same fashion as 333 a resumption PSK, and this extension does not alter those 334 restrictions. Thus, a certificate MUST NOT be used with a resumption 335 PSK. 337 Implementations must protect the external pre-shared key (PSK). 338 Compromise of the external PSK will make the encrypted session 339 content vulnerable to the future development of a large-scale quantum 340 computer. 342 Implementers should not transmit the same content on a connection 343 that is protected with an external PSK and a connection that is not. 344 Doing so may allow an eavesdropper to correlate the connections, 345 making the content vulnerable to the future invention of a large- 346 scale quantum computer. 348 Implementations must generate external PSKs with a secure key 349 management technique, such as pseudo-random generation of the key or 350 derivation of the key from one or more other secure keys. The use of 351 inadequate pseudo-random number generators (PRNGs) to generate 352 external PSKs can result in little or no security. An attacker may 353 find it much easier to reproduce the PRNG environment that produced 354 the external PSKs and searching the resulting small set of 355 possibilities, rather than brute force searching the whole key space. 356 The generation of quality random numbers is difficult. [RFC4086] 357 offers important guidance in this area. 359 If the external PSK is known to any party other than the client and 360 the server, then the external PSK MUST NOT be the sole basis for 361 authentication. The reasoning is explained in [K2016] (see 362 Section 4.2). When this extension is used, authentication is based 363 on certificates, not the external PSK. 365 In this extension, the external PSK preserves secrecy if the (EC)DH 366 key agreement is ever broken by cryptanalysis or the future invention 367 of a large-scale quantum computer. As long as the attacker does not 368 know the PSK and the key derivation algorithm remains unbroken, the 369 attacker cannot derive the session secrets even if they are able to 370 compute the (EC)DH shared secret. 372 TLS 1.3 key derivation makes use of the HKDF algorithm, which depends 373 upon the HMAC construction and a hash function. This extension 374 provides the desired protection for the session secrets as long as 375 HMAC with the selected hash function is a pseudorandom function (PRF) 376 [GGM1986]. 378 In the future, if the (EC)DH key agreement is broken by cryptanalysis 379 or the invention of a large-scale quantum computer, the forward 380 secrecy advantages traditionally associated with ephemeral (EC)DH 381 keys will no longer be relevant. Although the ephemeral private keys 382 used during a given TLS session would be destroyed at the end of a 383 session, preventing the attacker from later accessing them, the 384 private keys would nevertheless be recoverable due to the break in 385 the algorithm. A more general notion of "secrecy after key material 386 is destroyed" would still be achievable using external PSKs, of 387 course, provided that they are managed in a way that ensures their 388 destruction when they are no longer needed, and with the assumption 389 that the algorithms that use the external PSKs remain quantum-safe. 391 This specification does not require that external PSK is known only 392 by the client and server. The external PSK may be known to a group. 393 Since authentication depends on the public key in a certificate, 394 knowledge of the external PSK by other parties does not enable 395 impersonation. Since confidentiality depends on the shared secret 396 from (EC)DH, knowledge of the external PSK by other parties does not 397 enable eavesdropping. However, group members can record the traffic 398 of other members, and then decrypt it if they ever gain access to a 399 large-scale quantum computer. Also, when many parties know the 400 external PSK, there are many opportunities for theft of the external 401 PSK by an attacker. Once an attacker has the external PSK, they can 402 decrypt stored traffic if they ever gain access to a large-scale 403 quantum computer in the same manner as a legitimate group member. 405 TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are 406 bound to a specific hash function and KDF. By contrast, TLS 1.2 407 [RFC5246] allows PSKs to be used with any hash function and the TLS 408 1.2 PRF. Thus, the safest approach is to use a PSK exclusively with 409 TLS 1.2 or exclusively with TLS 1.3. Given one PSK, one can derive a 410 PSK for exclusive use with TLS 1.2 and derive another PSK for 411 exclusive use with TLS 1.3 using the mechanism specified in 412 [I-D.ietf-tls-external-psk-importer]. 414 TLS 1.3 [RFC8446] has received careful security analysis, and some 415 informal reasoning shows that the addition of this extension does not 416 introduce any security defects. This extension requires the use of 417 certificates for authentication, but the processing of certificates 418 is unchanged by this extension. This extension places an external 419 PSK in the key schedule as part of the computation of the Early 420 Secret. In the initial handshake without this extension, the Early 421 Secret is computed as: 423 Early Secret = HKDF-Extract(0, 0) 425 With this extension, the Early Secret is computed as: 427 Early Secret = HKDF-Extract(External PSK, 0) 429 Any entropy contributed by the external PSK can only make the Early 430 Secret better; the External PSK cannot make it worse. For these two 431 reasons, TLS 1.3 continues to meet its security goals when this 432 extension is used. 434 8. Privacy Considerations 436 Appendix E.6 of [RFC8446] discusses identity exposure attacks on 437 PSKs. The guidance in this section remains relevant. 439 This extension makes use of external PSKs to improve resilience 440 against attackers that gain access to a large-scale quantum computer 441 in the future. This extension is always accompanied by the 442 "pre_shared_key" extension to provide the PSK identities in plaintext 443 in the ClientHello message. Passive observation of the these PSK 444 identities will aid an attacker to track users of this extension. 446 9. Acknowledgments 448 Many thanks to Liliya Akhmetzyanova, Christian Huitema, Ben Kaduk, 449 Geoffrey Keating, Hugo Krawczyk, Nikos Mavrogiannopoulos, Nick 450 Sullivan, Martin Thomson, and Peter Yee for their review and 451 comments; their efforts have improved this document. 453 10. References 455 10.1. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, 459 DOI 10.17487/RFC2119, March 1997, 460 . 462 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 463 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 464 May 2017, . 466 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 467 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 468 . 470 10.2. Informative References 472 [DH1977] Diffie, W. and M. Hellman, "New Directions in 473 Cryptography", IEEE Transactions on Information 474 Theory V.IT-22 n.6, June 1977. 476 [FIPS186] National Institute of Standards and Technology, "Digital 477 Signature Standard (DSS)", Federal Information Processing 478 Standards Publication (FIPS PUB) 186-4, July 2013. 480 [GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to 481 construct random functions", J. ACM 1986 (33), pp. 482 792-807, 1986. 484 [I-D.hoffman-c2pq] 485 Hoffman, P., "The Transition from Classical to Post- 486 Quantum Cryptography", draft-hoffman-c2pq-05 (work in 487 progress), May 2019. 489 [I-D.ietf-tls-external-psk-importer] 490 Benjamin, D. and C. Wood, "Importing External PSKs for 491 TLS", draft-ietf-tls-external-psk-importer-01 (work in 492 progress), October 2019. 494 [IEEE1363] 495 Institute of Electrical and Electronics Engineers, "IEEE 496 Standard Specifications for Public-Key Cryptography", IEEE 497 Std 1363-2000, 2000. 499 [K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication 500 Compiler for Key Exchange (with Applications to Client 501 Authentication in TLS 1.3)", IACR ePrint 2016/711, August 502 2016. 504 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 505 Hashing for Message Authentication", RFC 2104, 506 DOI 10.17487/RFC2104, February 1997, 507 . 509 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 510 "Randomness Requirements for Security", BCP 106, RFC 4086, 511 DOI 10.17487/RFC4086, June 2005, 512 . 514 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 515 (TLS) Protocol Version 1.2", RFC 5246, 516 DOI 10.17487/RFC5246, August 2008, 517 . 519 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 520 "PKCS #1: RSA Cryptography Specifications Version 2.2", 521 RFC 8017, DOI 10.17487/RFC8017, November 2016, 522 . 524 Author's Address 526 Russ Housley 527 Vigil Security, LLC 528 516 Dranesville Road 529 Herndon, VA 20170 530 USA 532 Email: housley@vigilsec.com