idnits 2.17.1 draft-ietf-tls-tls13-cert-with-extern-psk-02.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 (May 31, 2019) is 1791 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-hoffman-c2pq-05 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 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 May 31, 2019 5 Expires: December 2, 2019 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-02 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 December 2, 2019. 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 invention of a large-scale quantum computer would pose a serious 75 challenge for the cryptographic algorithms that are widely deployed 76 today, including the digital signature algorithms that are used to 77 authenticate the server in the TLS 1.3 handshake protocol. It is an 78 open question whether or not it is feasible to build a large-scale 79 quantum computer, and if so, when that might happen. However, if 80 such a quantum computer is invented, many of the cryptographic 81 algorithms and the security protocols that use them would become 82 vulnerable. 84 The TLS 1.3 handshake protocol employs key agreement algorithms that 85 could be broken by the invention of a large-scale quantum computer 86 [I-D.hoffman-c2pq]. These algorithms include Diffie-Hellman (DH) 87 [DH1977] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]. As a 88 result, an adversary that stores a TLS 1.3 handshake protocol 89 exchange today could decrypt the associated encrypted communications 90 in the future when a large-scale quantum computer becomes available. 92 In the near-term, this document describes TLS 1.3 extension to 93 protect today's communications from the future invention of a large- 94 scale quantum computer by providing a strong external PSK as an input 95 to the TLS 1.3 key schedule while preserving the authentication 96 provided by the existing certificate and digital signature 97 mechanisms. 99 4. Extension Overview 101 This section provides a brief overview of the 102 "tls_cert_with_extern_psk" extension. 104 The client includes the "tls_cert_with_extern_psk" extension in the 105 ClientHello message. The "tls_cert_with_extern_psk" extension MUST 106 be accompanied by the "key_share", "psk_key_exchange_modes", and 107 "pre_shared_key" extensions. The "pre_shared_key" extension MUST be 108 the last extension in the ClientHello message, and it provides a list 109 of external PSK identifiers that the client is willing to use with 110 this server. Since the "tls_cert_with_extern_psk" extension is 111 intended to be used only with initial handshakes, it MUST NOT be sent 112 alongside the "early_data" extension. These extensions are all 113 described in Section 4.2 of [RFC8446]. 115 If the server is willing to use one of the external PSKs listed in 116 the "pre_shared_key" extension and perform certificate-based 117 authentication, then the server includes the 118 "tls_cert_with_extern_psk" extension in the ServerHello message. The 119 "tls_cert_with_extern_psk" extension MUST be accompanied by the 120 "key_share" and "pre_shared_key" extensions. If none of the external 121 PSKs in the list provided by the client is acceptable to the server, 122 then the "tls_cert_with_extern_psk" extension is omitted from the 123 ServerHello message. 125 The successful negotiation of the "tls_cert_with_extern_psk" 126 extension requires the TLS 1.3 key schedule processing to include 127 both the selected external PSK and the (EC)DHE shared secret value. 128 As a result, the Early Secret, Handshake Secret, and Master Secret 129 values all depend upon the value of the selected external PSK. 131 The authentication of the server and optional authentication of the 132 client depend upon the ability to generate a signature that can be 133 validated with the public key in their certificates. The 134 authentication processing is not changed in any way by the selected 135 external PSK. 137 Each external PSK is associated with a single hash algorithm, which 138 is required by Section 4.2.11 of [RFC8446]. The hash algorithm MUST 139 be set when the PSK is established, with a default of SHA-256 if no 140 hash algorithm is specified during establishment. 142 5. Certificate with External PSK Extension 144 This section specifies the "tls_cert_with_extern_psk" extension, 145 which MAY appear in the ClientHello message and ServerHello message. 146 It MUST NOT appear in any other messages. The 147 "tls_cert_with_extern_psk" extension MUST NOT appear in the 148 ServerHello message unless the "tls_cert_with_extern_psk" extension 149 appeared in the preceding ClientHello message. If an implementation 150 recognizes the "tls_cert_with_extern_psk" extension and receives it 151 in any other message, then the implementation MUST abort the 152 handshake with an "illegal_parameter" alert. 154 The general extension mechanisms enable clients and servers to 155 negotiate the use of specific extensions. Clients request extended 156 functionality from servers with the extensions field in the 157 ClientHello message. If the server responds with a HelloRetryRequest 158 message, then the client sends another ClientHello message as 159 described in Section 4.1.2 of [RFC8446], and it MUST include the same 160 "tls_cert_with_extern_psk" extension as the original ClientHello 161 message or abort the handshake. 163 Many server extensions are carried in the EncryptedExtensions 164 message; however, the "tls_cert_with_extern_psk" extension is carried 165 in the ServerHello message. It is only present in the ServerHello 166 message if the server recognizes the "tls_cert_with_extern_psk" 167 extension and the server possesses one of the external PSKs offered 168 by the client in the "pre_shared_key" extension in the ClientHello 169 message. 171 The Extension structure is defined in [RFC8446]; it is repeated here 172 for convenience. 174 struct { 175 ExtensionType extension_type; 176 opaque extension_data<0..2^16-1>; 177 } Extension; 179 The "extension_type" identifies the particular extension type, and 180 the "extension_data" contains information specific to the particular 181 extension type. 183 This document specifies the "tls_cert_with_extern_psk" extension, 184 adding one new type to ExtensionType: 186 enum { 187 tls_cert_with_extern_psk(TBD), (65535) 188 } ExtensionType; 190 The "tls_cert_with_extern_psk" extension is relevant when the client 191 and server possess an external PSK in common that can be used as an 192 input to the TLS 1.3 key schedule. The "tls_cert_with_extern_psk" 193 extension is essentially a flag to use the external PSK in the key 194 schedule, and it has the following syntax: 196 struct { 197 select (Handshake.msg_type) { 198 case client_hello: Empty; 199 case server_hello: Empty; 200 }; 201 } CertWithExternPSK; 203 To use an external PSK with certificates, clients MUST provide the 204 "tls_cert_with_extern_psk" extension, and it MUST be accompanied by 205 the "key_share", "psk_key_exchange_modes", and "pre_shared_key" 206 extensions in the ClientHello. If clients offer a 207 "tls_cert_with_extern_psk" extension without all of these other 208 extensions, servers MUST abort the handshake. The client MAY also 209 find it useful to include the "supported_groups" extension. Note 210 that Section 4.2 of [RFC8446] allows extensions to appear in any 211 order, with the exception of the "pre_shared_key" extension, which 212 MUST be the last extension in the ClientHello. Also, there MUST NOT 213 be more than one instance of each extension in the ClientHello 214 message. 216 The "key_share" extension is defined in Section 4.2.8 of [RFC8446]. 218 The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of 219 [RFC8446]. The "psk_key_exchange_modes" extension restricts both the 220 use of PSKs offered in this ClientHello and those which the server 221 might supply via a subsequent NewSessionTicket. As a result, clients 222 MUST include the psk_dhe_ke mode, and clients MAY also include the 223 psk_ke mode to support a subsequent NewSessionTicket. Servers MUST 224 select the psk_dhe_ke mode for the initial handshake. Servers MUST 225 select a key exchange mode that is listed by the client for 226 subsequent handshakes that include the resumption PSK from the 227 initial handshake. 229 The "supported_groups" extension is defined in Section 4.2.7 of 230 [RFC8446]. 232 The "pre_shared_key" extension is defined in Section 4.2.11 of 233 [RFC8446]. The syntax is repeated below for convenience. All of the 234 listed PSKs MUST be external PSKs. 236 struct { 237 opaque identity<1..2^16-1>; 238 uint32 obfuscated_ticket_age; 239 } PskIdentity; 241 opaque PskBinderEntry<32..255>; 243 struct { 244 PskIdentity identities<7..2^16-1>; 245 PskBinderEntry binders<33..2^16-1>; 246 } OfferedPsks; 248 struct { 249 select (Handshake.msg_type) { 250 case client_hello: OfferedPsks; 251 case server_hello: uint16 selected_identity; 252 }; 253 } PreSharedKeyExtension; 255 The OfferedPsks contains the list of PSK identities and associated 256 binders for the external PSKs that the client is willing to use with 257 the server. 259 The identities are a list of external PSK identities that the client 260 is willing to negotiate with the server. Each external PSK has an 261 associated identity that is known to the client and the server; the 262 associated identities may be know to other parties as well. In 263 addition, the binder validation (see below) confirms that the client 264 and server have the same key associated with the identity. 266 The obfuscated_ticket_age is not used for external PSKs; clients 267 SHOULD set this value to 0, 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 external PSK identity that the 280 server selected from the list offered by the client. If none of the 281 offered external PSKs in the list provided by the client are 282 acceptable to the server, then the "tls_cert_with_extern_psk" 283 extension MUST be omitted from the ServerHello message. The server 284 MUST validate the binder value that corresponds to the selected 285 external PSK as described in Section 4.2.11.2 of [RFC8446]. If the 286 binder does not validate, the server MUST abort the handshake with an 287 "illegal_parameter" alert. Servers SHOULD NOT attempt to validate 288 multiple binders; rather they SHOULD select one of the offered 289 external PSKs and validate only the binder that corresponds to that 290 external PSK. 292 When the "tls_cert_with_extern_psk" extension is successfully 293 negotiated, authentication of the server depends upon the ability to 294 generate a signature that can be validated with the public key in the 295 server's certificate. This is accomplished by the server sending the 296 Certificate and CertificateVerify messages as described in Sections 297 4.4.2 and 4.4.3 of [RFC8446]. 299 TLS 1.3 does not permit the server to send a CertificateRequest 300 message when a PSK is being used. This restriction is removed when 301 the "tls_cert_with_extern_psk" extension is negotiated, allowing 302 certificate-based authentication for both the client and the server. 303 If certificate-based client authentication is desired, this is 304 accomplished by the client sending the Certificate and 305 CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 306 of [RFC8446]. 308 Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The 309 successful negotiation of the "tls_cert_with_extern_psk" extension 310 requires the key schedule processing to include both the external PSK 311 and the (EC)DHE shared secret value. 313 If the client and the server have different values associated with 314 the selected external PSK identifier, then the client and the server 315 will compute different values for every entry in the key schedule, 316 which will lead to the termination of the connection with a 317 "decrypt_error" alert. 319 6. IANA Considerations 321 IANA is requested to update the TLS ExtensionType Registry to include 322 "tls_cert_with_extern_psk" with a value of TBD and the list of 323 messages "CH, SH" in which the "tls_cert_with_extern_psk" extension 324 may appear. 326 7. Security Considerations 328 The Security Considerations in [RFC8446] remain relevant. 330 TLS 1.3 [RFC8446] does not permit the server to send a 331 CertificateRequest message when a PSK is being used. This 332 restriction is removed when the "tls_cert_with_extern_psk" extension 333 is offered by the client and accepted by the server. However, TLS 334 1.3 does not permit an external PSK to be used in the same fashion as 335 a resumption PSK, and this extension does not alter those 336 restrictions. Thus, a certificate MUST NOT be used with a resumption 337 PSK. 339 Implementations must protect the external pre-shared key (PSK). 340 Compromise of the external PSK will make the encrypted session 341 content vulnerable to the future invention of a large-scale quantum 342 computer. 344 Implementers should not transmit the same content on a connection 345 that is protected with an external PSK and a connection that is not. 346 Doing so may allow an eavesdropper to correlate the connections, 347 making the content vulnerable to the future invention of a large- 348 scale quantum computer. 350 Implementations must generate external PSKs with a secure key 351 management technique, such as pseudo-random generation of the key or 352 derivation of the key from one or more other secure keys. The use of 353 inadequate pseudo-random number generators (PRNGs) to generate 354 external PSKs can result in little or no security. An attacker may 355 find it much easier to reproduce the PRNG environment that produced 356 the external PSKs and searching the resulting small set of 357 possibilities, rather than brute force searching the whole key space. 358 The generation of quality random numbers is difficult. [RFC4086] 359 offers important guidance in this area. 361 If the external PSK is known to any party other than the client and 362 the server, then the external PSK MUST NOT be the sole basis for 363 authentication. The reasoning is explained in [K2016] (see 364 Section 4.2). When this extension is used, authentication is based 365 on certificates, not the external PSK. 367 In this extension, the external PSK preserves secrecy if the (EC)DH 368 key agreement is ever broken by cryptanalysis or the future invention 369 of a large-scale quantum computer. As long as the attacker does not 370 know the PSK and the key derivation algorithm remains unbroken, the 371 attacker cannot derive the session secrets even if they are able to 372 compute the (EC)DH shared secret. 374 TLS 1.3 key derivation makes use of the HKDF algorithm, which depends 375 upon the HMAC construction and a hash function. This extension 376 provides the desired protection for the session secrets as long as 377 HMAC with the selected hash function is a pseudorandom function (PRF) 378 [GGM1986]. 380 In the future, if the (EC)DH key agreement is broken by cryptanalysis 381 or the invention of a large-scale quantum computer, the forward 382 secrecy advantages traditionally associated with ephemeral (EC)DH 383 keys will no longer be relevant. Although the ephemeral private keys 384 used during a given TLS session would be destroyed at the end of a 385 session, preventing the attacker from later accessing them, the 386 private keys would nevertheless be recoverable due to the break in 387 the algorithm. A more general notion of "secrecy after key material 388 is destroyed" would still be achievable using external PSKs, of 389 course, provided that they are managed in a way that ensures their 390 destruction when they are no longer needed, and with the assumption 391 that the algorithms that use the external PSKs remain quantum-safe. 393 This specification does not require that external PSK is known only 394 by the client and server. The external PSK may be known to a group. 395 Since authentication depends on the public key in a certificate, 396 knowledge of the external PSK by other parties does not enable 397 impersonation. Since confidentiality depends on the shared secret 398 from (EC)DH, knowledge of the external PSK by other parties does not 399 enable eavesdropping. However, group members can record the traffic 400 of other members, and then decrypt it if they ever gain access to a 401 large-scale quantum computer. Also, when many parties know the 402 external PSK, there are many opportunities for theft of the external 403 PSK by an attacker. Once an attacker has the external PSK, they can 404 decrypt stored traffic if they ever gain access to a large-scale 405 quantum computer in the same manner as a legitimate group member. 407 TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are 408 bound to a specific hash function and KDF. By contrast, TLS 1.2 409 [RFC5246] allows PSKs to be used with any hash function and the TLS 410 1.2 PRF. Thus, the safest approach is to use a PSK with either TLS 411 1.2 or TLS 1.3. However, any PSK that might be used with both TLS 412 1.2 and TLS 1.3 must be used with only one hash function, which is 413 the one that is bound for use in TLS 1.3. This restriction is less 414 than optimal when users want to provision a single PSK. While the 415 constructions used in TLS 1.2 and TLS 1.3 are both based on HMAC 416 [RFC2104], the constructions are different, and there is no known way 417 in which reuse of the same PSK in TLS 1.2 and TLS 1.3 that would 418 produce related outputs. 420 TLS 1.3 [RFC8446] has received careful security analysis, and some 421 informal reasoning shows that the addition of this extension does not 422 introduce any security defects. This extension requires the use of 423 certificates for authentication, but the processing of certificates 424 is unchanged by this extension. This extension places an external 425 PSK in the key schedule as part of the computation of the Early 426 Secret. In the initial handshake without this extension, the Early 427 Secret is computed as: 429 Early Secret = HKDF-Extract(0, 0) 431 With this extension, the Early Secret is computed as: 433 Early Secret = HKDF-Extract(External PSK, 0) 435 Any entropy contributed by the external PSK can only make the Early 436 Secret better; the External PSK cannot make it worse. For these two 437 reasons, TLS 1.3 continues to meet its security goals when this 438 extension is used. 440 8. Privacy Considerations 442 Appendix E.6 of [RFC8446] discusses identity exposure attacks on 443 PSKs. The guidance in this section remains relevant. 445 This extension makes use of external PSKs to improve resilience 446 against attackers that gain access to a large-scale quantum computer 447 in the future. This extension is always accompanied by the 448 "pre_shared_key" extension to provide the PSK identities in plaintext 449 in the ClientHello message. Passive observation of the these PSK 450 identities will aid an attacker to track users of this extension. 452 9. Acknowledgments 454 Many thanks to Liliya Akhmetzyanova, Christian Huitema, Geoffrey 455 Keating, Hugo Krawczyk, Nikos Mavrogiannopoulos, Nick Sullivan, 456 Martin Thomson, and Peter Yee for their review and comments; their 457 efforts have improved this document. 459 10. References 461 10.1. Normative References 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, 465 DOI 10.17487/RFC2119, March 1997, 466 . 468 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 469 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 470 May 2017, . 472 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 473 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 474 . 476 10.2. Informative References 478 [DH1977] Diffie, W. and M. Hellman, "New Directions in 479 Cryptography", IEEE Transactions on Information 480 Theory V.IT-22 n.6, June 1977. 482 [GGM1986] Goldreich, O., Goldwasser, S., and S. Micali, "How to 483 construct random functions", J. ACM 1986 (33), pp. 484 792-807, 1986. 486 [I-D.hoffman-c2pq] 487 Hoffman, P., "The Transition from Classical to Post- 488 Quantum Cryptography", draft-hoffman-c2pq-05 (work in 489 progress), May 2019. 491 [IEEE1363] 492 Institute of Electrical and Electronics Engineers, "IEEE 493 Standard Specifications for Public-Key Cryptography", IEEE 494 Std 1363-2000, 2000. 496 [K2016] Krawczyk, H., "A Unilateral-to-Mutual Authentication 497 Compiler for Key Exchange (with Applications to Client 498 Authentication in TLS 1.3)", IACR ePrint 2016/711, August 499 2016. 501 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 502 Hashing for Message Authentication", RFC 2104, 503 DOI 10.17487/RFC2104, February 1997, 504 . 506 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 507 "Randomness Requirements for Security", BCP 106, RFC 4086, 508 DOI 10.17487/RFC4086, June 2005, 509 . 511 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 512 (TLS) Protocol Version 1.2", RFC 5246, 513 DOI 10.17487/RFC5246, August 2008, 514 . 516 Author's Address 518 Russ Housley 519 Vigil Security, LLC 520 516 Dranesville Road 521 Herndon, VA 20170 522 USA 524 Email: housley@vigilsec.com