idnits 2.17.1 draft-ietf-tls-tls13-cert-with-extern-psk-04.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 19, 2019) is 1584 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 19, 2019 5 Expires: June 21, 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-04 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 21, 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 client includes both the "tls_cert_with_extern_psk" extension 119 and the "early_data" extension, then the server MUST terminate the 120 connection with an "illegal_parameter" alert. 122 If the server is willing to use one of the external PSKs listed in 123 the "pre_shared_key" extension and perform certificate-based 124 authentication, then the server includes the 125 "tls_cert_with_extern_psk" extension in the ServerHello message. The 126 "tls_cert_with_extern_psk" extension MUST be accompanied by the 127 "key_share" and "pre_shared_key" extensions. If none of the external 128 PSKs in the list provided by the client is acceptable to the server, 129 then the "tls_cert_with_extern_psk" extension is omitted from the 130 ServerHello message. 132 When the "tls_cert_with_extern_psk" extension is successfully 133 negotiated, the TLS 1.3 key schedule processing includes both the 134 selected external PSK and the (EC)DHE shared secret value. As a 135 result, the Early Secret, Handshake Secret, and Master Secret values 136 all depend upon the value of the selected external PSK. Of course, 137 the Early Secret does not depend upon the (EC)DHE shared secret. 139 The authentication of the server and optional authentication of the 140 client depend upon the ability to generate a signature that can be 141 validated with the public key in their certificates. The 142 authentication processing is not changed in any way by the selected 143 external PSK. 145 Each external PSK is associated with a single hash algorithm, which 146 is required by Section 4.2.11 of [RFC8446]. The hash algorithm MUST 147 be set when the PSK is established, with a default of SHA-256. 149 5. Certificate with External PSK Extension 151 This section specifies the "tls_cert_with_extern_psk" extension, 152 which MAY appear in the ClientHello message and ServerHello message. 153 It MUST NOT appear in any other messages. The 154 "tls_cert_with_extern_psk" extension MUST NOT appear in the 155 ServerHello message unless the "tls_cert_with_extern_psk" extension 156 appeared in the preceding ClientHello message. If an implementation 157 recognizes the "tls_cert_with_extern_psk" extension and receives it 158 in any other message, then the implementation MUST abort the 159 handshake with an "illegal_parameter" alert. 161 The general extension mechanisms enable clients and servers to 162 negotiate the use of specific extensions. Clients request extended 163 functionality from servers with the extensions field in the 164 ClientHello message. If the server responds with a HelloRetryRequest 165 message, then the client sends another ClientHello message as 166 described in Section 4.1.2 of [RFC8446], including the same 167 "tls_cert_with_extern_psk" extension as the original ClientHello 168 message or aborts the handshake. 170 Many server extensions are carried in the EncryptedExtensions 171 message; however, the "tls_cert_with_extern_psk" extension is carried 172 in the ServerHello message. Successful negotiation of the 173 "tls_cert_with_extern_psk" extension affects the key used for 174 encryption, so it cannot be carried in the EncryptedExtensions 175 message. Therefore, the "tls_cert_with_extern_psk" extension is only 176 present in the ServerHello message if the server recognizes the 177 "tls_cert_with_extern_psk" extension and the server possesses one of 178 the external PSKs offered by the client in the "pre_shared_key" 179 extension in the ClientHello message. 181 The Extension structure is defined in [RFC8446]; it is repeated here 182 for convenience. 184 struct { 185 ExtensionType extension_type; 186 opaque extension_data<0..2^16-1>; 187 } Extension; 189 The "extension_type" identifies the particular extension type, and 190 the "extension_data" contains information specific to the particular 191 extension type. 193 This document specifies the "tls_cert_with_extern_psk" extension, 194 adding one new type to ExtensionType: 196 enum { 197 tls_cert_with_extern_psk(TBD), (65535) 198 } ExtensionType; 200 The "tls_cert_with_extern_psk" extension is relevant when the client 201 and server possess an external PSK in common that can be used as an 202 input to the TLS 1.3 key schedule. The "tls_cert_with_extern_psk" 203 extension is essentially a flag to use the external PSK in the key 204 schedule, and it has the following syntax: 206 struct { 207 select (Handshake.msg_type) { 208 case client_hello: Empty; 209 case server_hello: Empty; 210 }; 211 } CertWithExternPSK; 213 5.1. Companion Extensions 215 Section 4 lists the extensions that are required to accompany the 216 "tls_cert_with_extern_psk" extension. Most of those extension are 217 used in the usual manner. This section discusses the impacts on the 218 extensions that are affected the presence of the 219 "tls_cert_with_extern_psk" extension. 221 The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of 222 [RFC8446]. The "psk_key_exchange_modes" extension restricts the use 223 of both the PSKs offered in this ClientHello and those that the 224 server might supply via a subsequent NewSessionTicket. As a result, 225 when the "psk_key_exchange_modes" extension is included in the 226 ClientHello message, clients MUST include psk_dhe_ke mode. In 227 addition, clients MAY also include psk_ke mode to support a 228 subsequent NewSessionTicket. When the "psk_key_exchange_modes" 229 extension is included in the ServerHello message, servers MUST select 230 the psk_dhe_ke mode for the initial handshake. Servers MUST select a 231 key exchange mode that is listed by the client for subsequent 232 handshakes that include the resumption PSK from the initial 233 handshake. 235 The "pre_shared_key" extension is defined in Section 4.2.11 of 236 [RFC8446]. The syntax is repeated below for convenience. All of the 237 listed PSKs MUST be external PSKs. If a resumption PSK is listed 238 along with the "tls_cert_with_extern_psk" extension, the server MUST 239 abort the handshake with an "illegal_parameter" alert. 241 struct { 242 opaque identity<1..2^16-1>; 243 uint32 obfuscated_ticket_age; 244 } PskIdentity; 246 opaque PskBinderEntry<32..255>; 248 struct { 249 PskIdentity identities<7..2^16-1>; 250 PskBinderEntry binders<33..2^16-1>; 251 } OfferedPsks; 253 struct { 254 select (Handshake.msg_type) { 255 case client_hello: OfferedPsks; 256 case server_hello: uint16 selected_identity; 257 }; 258 } PreSharedKeyExtension; 260 The OfferedPsks contains the list of PSK identities and associated 261 binders for the external PSKs that the client is willing to use with 262 the server. 264 The identities are a list of external PSK identities that the client 265 is willing to negotiate with the server. Each external PSK has an 266 associated identity that is known to the client and the server; the 267 associated identities may be know to other parties as well. In 268 addition, the binder validation (see below) confirms that the client 269 and server have the same key associated with the identity. 271 The obfuscated_ticket_age is not used for external PSKs. As stated 272 in Section 4.2.11 of [RFC8446], clients SHOULD set this value to 0, 273 and servers MUST ignore the value. 275 The binders are a series of HMAC [RFC2104] values, one for each 276 external PSK offered by the client, in the same order as the 277 identities list. The HMAC value is computed using the binder_key, 278 which is derived from the external PSK, and a partial transcript of 279 the current handshake. Generation of the binder_key from the 280 external PSK is described in Section 7.1 of [RFC8446]. The partial 281 transcript of the current handshake includes a partial ClientHello up 282 to and including the PreSharedKeyExtension.identities field as 283 described in Section 4.2.11.2 of [RFC8446]. 285 The selected_identity contains the index of the external PSK identity 286 that the server selected from the list offered by the client. As 287 described in Section 4.2.11.2 of [RFC8446], the server MUST validate 288 the binder value that corresponds to the selected external PSK, and 289 if the binder does not validate, the server MUST abort the handshake 290 with an "illegal_parameter" alert. 292 5.2. Authentication 294 When the "tls_cert_with_extern_psk" extension is successfully 295 negotiated, authentication of the server depends upon the ability to 296 generate a signature that can be validated with the public key in the 297 server's certificate. This is accomplished by the server sending the 298 Certificate and CertificateVerify messages as described in Sections 299 4.4.2 and 4.4.3 of [RFC8446]. 301 TLS 1.3 does not permit the server to send a CertificateRequest 302 message when a PSK is being used. This restriction is removed when 303 the "tls_cert_with_extern_psk" extension is negotiated, allowing 304 certificate-based authentication for both the client and the server. 305 If certificate-based client authentication is desired, this is 306 accomplished by the client sending the Certificate and 307 CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 308 of [RFC8446]. 310 5.3. Keying Material 312 Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The 313 successful negotiation of the "tls_cert_with_extern_psk" extension 314 requires the key schedule processing to include both the external PSK 315 and the (EC)DHE shared secret value. 317 If the client and the server have different values associated with 318 the selected external PSK identifier, then the client and the server 319 will compute different values for every entry in the key schedule, 320 which will lead to the client aborting the handshake with a 321 "decrypt_error" alert. 323 6. IANA Considerations 325 IANA is requested to update the TLS ExtensionType Registry [IANA] to 326 include "tls_cert_with_extern_psk" with a value of TBD and the list 327 of messages "CH, SH" in which the "tls_cert_with_extern_psk" 328 extension may appear. 330 7. Security Considerations 332 The Security Considerations in [RFC8446] remain relevant. 334 TLS 1.3 [RFC8446] does not permit the server to send a 335 CertificateRequest message when a PSK is being used. This 336 restriction is removed when the "tls_cert_with_extern_psk" extension 337 is offered by the client and accepted by the server. However, TLS 338 1.3 does not permit an external PSK to be used in the same fashion as 339 a resumption PSK, and this extension does not alter those 340 restrictions. Thus, a certificate MUST NOT be used with a resumption 341 PSK. 343 Implementations must protect the external pre-shared key (PSK). 344 Compromise of the external PSK will make the encrypted session 345 content vulnerable to the future development of a large-scale quantum 346 computer. 348 Implementers should not transmit the same content on a connection 349 that is protected with an external PSK and a connection that is not. 350 Doing so may allow an eavesdropper to correlate the connections, 351 making the content vulnerable to the future invention of a large- 352 scale quantum computer. 354 Implementations must generate external PSKs with a secure key 355 management technique, such as pseudo-random generation of the key or 356 derivation of the key from one or more other secure keys. The use of 357 inadequate pseudo-random number generators (PRNGs) to generate 358 external PSKs can result in little or no security. An attacker may 359 find it much easier to reproduce the PRNG environment that produced 360 the external PSKs and search the resulting small set of 361 possibilities, rather than brute-force searching the whole key space. 362 The generation of quality random numbers is difficult. [RFC4086] 363 offers important guidance in this area. 365 If the external PSK is known to any party other than the client and 366 the server, then the external PSK MUST NOT be the sole basis for 367 authentication. The reasoning is explained in Section 4.2 of 368 [K2016]. When this extension is used, authentication is based on 369 certificates, not the external PSK. 371 In this extension, the external PSK preserves secrecy if the (EC)DH 372 key agreement is ever broken by cryptanalysis or the future invention 373 of a large-scale quantum computer. As long as the attacker does not 374 know the PSK and the key derivation algorithm remains unbroken, the 375 attacker cannot derive the session secrets even if they are able to 376 compute the (EC)DH shared secret. 378 TLS 1.3 key derivation makes use of the HKDF algorithm, which depends 379 upon the HMAC [RFC2104] construction and a hash function. This 380 extension provides the desired protection for the session secrets as 381 long as HMAC with the selected hash function is a pseudorandom 382 function (PRF) [GGM1986]. 384 In the future, if the (EC)DH key agreement is broken by cryptanalysis 385 or the invention of a large-scale quantum computer, the forward 386 secrecy advantages traditionally associated with ephemeral (EC)DH 387 keys will no longer be relevant. Although the ephemeral private keys 388 used during a given TLS session would be destroyed at the end of a 389 session, preventing the attacker from later accessing them, the 390 private keys would nevertheless be recoverable due to the break in 391 the algorithm. A more general notion of "secrecy after key material 392 is destroyed" would still be achievable using external PSKs, of 393 course, provided that they are managed in a way that ensures their 394 destruction when they are no longer needed, and with the assumption 395 that the algorithms that use the external PSKs remain quantum-safe. 397 This specification does not require that the external PSK is known 398 only by the client and server. The external PSK may be known to a 399 group. Since authentication depends on the public key in a 400 certificate, knowledge of the external PSK by other parties does not 401 enable impersonation. Since confidentiality depends on the shared 402 secret from (EC)DH, knowledge of the external PSK by other parties 403 does not enable eavesdropping. However, group members can record the 404 traffic of other members, and then decrypt it if they ever gain 405 access to a large-scale quantum computer. Also, when many parties 406 know the external PSK, there are many opportunities for theft of the 407 external PSK by an attacker. Once an attacker has the external PSK, 408 they can decrypt stored traffic if they ever gain access to a large- 409 scale quantum computer in the same manner as a legitimate group 410 member. 412 TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are 413 bound to a specific hash function and KDF. By contrast, TLS 1.2 414 [RFC5246] allows PSKs to be used with any hash function and the TLS 415 1.2 PRF. Thus, the safest approach is to use a PSK exclusively with 416 TLS 1.2 or exclusively with TLS 1.3. Given one PSK, one can derive a 417 PSK for exclusive use with TLS 1.2 and derive another PSK for 418 exclusive use with TLS 1.3 using the mechanism specified in 419 [I-D.ietf-tls-external-psk-importer]. 421 TLS 1.3 [RFC8446] has received careful security analysis, and some 422 informal reasoning shows that the addition of this extension does not 423 introduce any security defects. This extension requires the use of 424 certificates for authentication, but the processing of certificates 425 is unchanged by this extension. This extension places an external 426 PSK in the key schedule as part of the computation of the Early 427 Secret. In the initial handshake without this extension, the Early 428 Secret is computed as: 430 Early Secret = HKDF-Extract(0, 0) 432 With this extension, the Early Secret is computed as: 434 Early Secret = HKDF-Extract(External PSK, 0) 436 Any entropy contributed by the external PSK can only make the Early 437 Secret better; the External PSK cannot make it worse. For these two 438 reasons, TLS 1.3 continues to meet its security goals when this 439 extension is used. 441 8. Privacy Considerations 443 Appendix E.6 of [RFC8446] discusses identity exposure attacks on 444 PSKs. The guidance in this section remains relevant. 446 This extension makes use of external PSKs to improve resilience 447 against attackers that gain access to a large-scale quantum computer 448 in the future. This extension is always accompanied by the 449 "pre_shared_key" extension to provide the PSK identities in plaintext 450 in the ClientHello message. Passive observation of the these PSK 451 identities will aid an attacker to track users of this extension. 453 9. Acknowledgments 455 Many thanks to Liliya Akhmetzyanova, Christian Huitema, Ben Kaduk, 456 Geoffrey Keating, Hugo Krawczyk, Mirja Kuehlewind, Nikos 457 Mavrogiannopoulos, Nick Sullivan, Martin Thomson, and Peter Yee for 458 their review and comments; their efforts have improved this document. 460 10. References 462 10.1. Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, 466 DOI 10.17487/RFC2119, March 1997, 467 . 469 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 470 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 471 May 2017, . 473 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 474 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 475 . 477 10.2. Informative References 479 [DH1977] Diffie, W. and M. Hellman, "New Directions in 480 Cryptography", IEEE Transactions on Information 481 Theory V.IT-22 n.6, June 1977. 483 [FIPS186] National Institute of Standards and Technology, "Digital 484 Signature Standard (DSS)", Federal Information Processing 485 Standards Publication (FIPS PUB) 186-4, July 2013. 487 [GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to 488 construct random functions", J. ACM 1986 (33), pp. 489 792-807, 1986. 491 [I-D.hoffman-c2pq] 492 Hoffman, P., "The Transition from Classical to Post- 493 Quantum Cryptography", draft-hoffman-c2pq-06 (work in 494 progress), November 2019. 496 [I-D.ietf-tls-external-psk-importer] 497 Benjamin, D. and C. Wood, "Importing External PSKs for 498 TLS", draft-ietf-tls-external-psk-importer-02 (work in 499 progress), November 2019. 501 [IANA] "IANA Registry for TLS ExtensionType Values", n.d., 502 . 505 [IEEE1363] 506 Institute of Electrical and Electronics Engineers, "IEEE 507 Standard Specifications for Public-Key Cryptography", IEEE 508 Std 1363-2000, 2000. 510 [K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication 511 Compiler for Key Exchange (with Applications to Client 512 Authentication in TLS 1.3)", IACR ePrint 2016/711, August 513 2016. 515 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 516 Hashing for Message Authentication", RFC 2104, 517 DOI 10.17487/RFC2104, February 1997, 518 . 520 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 521 "Randomness Requirements for Security", BCP 106, RFC 4086, 522 DOI 10.17487/RFC4086, June 2005, 523 . 525 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 526 (TLS) Protocol Version 1.2", RFC 5246, 527 DOI 10.17487/RFC5246, August 2008, 528 . 530 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 531 "PKCS #1: RSA Cryptography Specifications Version 2.2", 532 RFC 8017, DOI 10.17487/RFC8017, November 2016, 533 . 535 Author's Address 537 Russ Housley 538 Vigil Security, LLC 539 516 Dranesville Road 540 Herndon, VA 20170 541 USA 543 Email: housley@vigilsec.com