idnits 2.17.1 draft-ietf-tls-tls13-cert-with-extern-psk-06.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 23, 2019) is 1585 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 23, 2019 5 Expires: June 25, 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-06 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 25, 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. However, the generation, distribution, and management of 353 the external PSKs is out of scope for this specification. 355 Implementers should not transmit the same content on a connection 356 that is protected with an external PSK and a connection that is not. 357 Doing so may allow an eavesdropper to correlate the connections, 358 making the content vulnerable to the future invention of a large- 359 scale quantum computer. 361 Implementations must generate external PSKs with a secure key 362 management technique, such as pseudo-random generation of the key or 363 derivation of the key from one or more other secure keys. The use of 364 inadequate pseudo-random number generators (PRNGs) to generate 365 external PSKs can result in little or no security. An attacker may 366 find it much easier to reproduce the PRNG environment that produced 367 the external PSKs and search the resulting small set of 368 possibilities, rather than brute-force searching the whole key space. 369 The generation of quality random numbers is difficult. [RFC4086] 370 offers important guidance in this area. 372 If the external PSK is known to any party other than the client and 373 the server, then the external PSK MUST NOT be the sole basis for 374 authentication. The reasoning is explained in Section 4.2 of 375 [K2016]. When this extension is used, authentication is based on 376 certificates, not the external PSK. 378 In this extension, the external PSK preserves confidentiality if the 379 (EC)DH key agreement is ever broken by cryptanalysis or the future 380 invention of a large-scale quantum computer. As long as the attacker 381 does not know the PSK and the key derivation algorithm remains 382 unbroken, the attacker cannot derive the session secrets even if they 383 are able to compute the (EC)DH shared secret. Should the attacker be 384 able compute the (EC)DH shared secret, the forward secrecy advantages 385 traditionally associated with ephemeral (EC)DH keys will no longer be 386 relevant. Although the ephemeral private keys used during a given 387 TLS session are destroyed at the end of a session, preventing the 388 attacker from later accessing them, these private keys would 389 nevertheless be recoverable due to the break in the algorithm. 390 However, a more general notion of "secrecy after key material is 391 destroyed" would still be achievable using external PSKs, if they are 392 managed in a way that ensures their destruction when they are no 393 longer needed, and with the assumption that the algorithms that use 394 the external PSKs remain quantum-safe. 396 TLS 1.3 key derivation makes use of the HKDF algorithm, which depends 397 upon the HMAC [RFC2104] construction and a hash function. This 398 extension provides the desired protection for the session secrets as 399 long as HMAC with the selected hash function is a pseudorandom 400 function (PRF) [GGM1986]. 402 This specification does not require that the external PSK is known 403 only by the client and server. The external PSK may be known to a 404 group. Since authentication depends on the public key in a 405 certificate, knowledge of the external PSK by other parties does not 406 enable impersonation. Since confidentiality depends on the shared 407 secret from (EC)DH, knowledge of the external PSK by other parties 408 does not enable eavesdropping. However, group members can record the 409 traffic of other members, and then decrypt it if they ever gain 410 access to a large-scale quantum computer. Also, when many parties 411 know the external PSK, there are many opportunities for theft of the 412 external PSK by an attacker. Once an attacker has the external PSK, 413 they can decrypt stored traffic if they ever gain access to a large- 414 scale quantum computer in the same manner as a legitimate group 415 member. 417 TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are 418 bound to a specific hash function and KDF. By contrast, TLS 1.2 419 [RFC5246] allows PSKs to be used with any hash function and the TLS 420 1.2 PRF. Thus, the safest approach is to use a PSK exclusively with 421 TLS 1.2 or exclusively with TLS 1.3. Given one PSK, one can derive a 422 PSK for exclusive use with TLS 1.2 and derive another PSK for 423 exclusive use with TLS 1.3 using the mechanism specified in 424 [I-D.ietf-tls-external-psk-importer]. 426 TLS 1.3 [RFC8446] has received careful security analysis, and some 427 informal reasoning shows that the addition of this extension does not 428 introduce any security defects. This extension requires the use of 429 certificates for authentication, but the processing of certificates 430 is unchanged by this extension. This extension places an external 431 PSK in the key schedule as part of the computation of the Early 432 Secret. In the initial handshake without this extension, the Early 433 Secret is computed as: 435 Early Secret = HKDF-Extract(0, 0) 437 With this extension, the Early Secret is computed as: 439 Early Secret = HKDF-Extract(External PSK, 0) 441 Any entropy contributed by the external PSK can only make the Early 442 Secret better; the External PSK cannot make it worse. For these two 443 reasons, TLS 1.3 continues to meet its security goals when this 444 extension is used. 446 8. Privacy Considerations 448 Appendix E.6 of [RFC8446] discusses identity exposure attacks on 449 PSKs. The guidance in this section remains relevant. 451 This extension makes use of external PSKs to improve resilience 452 against attackers that gain access to a large-scale quantum computer 453 in the future. This extension is always accompanied by the 454 "pre_shared_key" extension to provide the PSK identities in plaintext 455 in the ClientHello message. Passive observation of the these PSK 456 identities will aid an attacker to track users of this extension. 458 9. Acknowledgments 460 Many thanks to Liliya Akhmetzyanova, Roman Danyliw, Christian 461 Huitema, Ben Kaduk, Geoffrey Keating, Hugo Krawczyk, Mirja 462 Kuehlewind, Nikos Mavrogiannopoulos, Nick Sullivan, Martin Thomson, 463 and Peter Yee for their review and comments; their efforts have 464 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