idnits 2.17.1 draft-ietf-tls-tls13-cert-with-extern-psk-01.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 9, 2019) is 1814 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-hoffman-c2pq-04 -- 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 9, 2019 5 Expires: November 10, 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-01 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 November 10, 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 [DH] 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. 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; clients 266 SHOULD set this value to 0, and servers MUST ignore the value. 268 The binders are a series of HMAC values, one for each external PSK 269 offered by the client, in the same order as the identities list. The 270 HMAC value is computed using the binder_key, which is derived from 271 the external PSK, and a partial transcript of the current handshake. 272 Generation of the binder_key from the external PSK is described in 273 Section 7.1 of [RFC8446]. The partial transcript of the current 274 handshake includes a partial ClientHello up to and including the 275 PreSharedKeyExtension.identities field as described in 276 Section 4.2.11.2 of [RFC8446]. 278 The selected_identity contains the external PSK identity that the 279 server selected from the list offered by the client. If none of the 280 offered external PSKs in the list provided by the client are 281 acceptable to the server, then the "tls_cert_with_extern_psk" 282 extension MUST be omitted from the ServerHello message. The server 283 MUST validate the binder value that corresponds to the selected 284 external PSK as described in Section 4.2.11.2 of [RFC8446]. If the 285 binder does not validate, the server MUST abort the handshake with an 286 "illegal_parameter" alert. Servers SHOULD NOT attempt to validate 287 multiple binders; rather they SHOULD select one of the offered 288 external PSKs and validate only the binder that corresponds to that 289 external PSK. 291 When the "tls_cert_with_extern_psk" extension is successfully 292 negotiated, authentication of the server depends upon the ability to 293 generate a signature that can be validated with the public key in the 294 server's certificate. This is accomplished by the server sending the 295 Certificate and CertificateVerify messages as described in Sections 296 4.4.2 and 4.4.3 of [RFC8446]. 298 TLS 1.3 does not permit the server to send a CertificateRequest 299 message when a PSK is being used. This restriction is removed when 300 the "tls_cert_with_extern_psk" extension is negotiated, allowing 301 certificate-based authentication for both the client and the server. 302 If certificate-based client authentication is desired, this is 303 accomplished by the client sending the Certificate and 304 CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 305 of [RFC8446]. 307 Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The 308 successful negotiation of the "tls_cert_with_extern_psk" extension 309 requires the key schedule processing to include both the external PSK 310 and the (EC)DHE shared secret value. 312 If the client and the server have different values associated with 313 the selected external PSK identifier, then the client and the server 314 will compute different values for every entry in the key schedule, 315 which will lead to the termination of the connection with a 316 "decrypt_error" alert. 318 6. IANA Considerations 320 IANA is requested to update the TLS ExtensionType Registry to include 321 "tls_cert_with_extern_psk" with a value of TBD and the list of 322 messages "CH, SH" in which the "tls_cert_with_extern_psk" extension 323 may appear. 325 7. Security Considerations 327 The Security Considerations in [RFC8446] remain relevant. 329 TLS 1.3 [RFC8446] does not permit the server to send a 330 CertificateRequest message when a PSK is being used. This 331 restriction is removed when the "tls_cert_with_extern_psk" extension 332 is offered by the client and accepted by the server. However, TLS 333 1.3 does not permit an external PSK to be used in the same fashion as 334 a resumption PSK, and this extension does not alter those 335 restrictions. Thus, a certificate MUST NOT be used with a resumption 336 PSK. 338 Implementations must protect the external pre-shared key (PSK). 339 Compromise of the external PSK will make the encrypted session 340 content vulnerable to the future invention of a large-scale quantum 341 computer. 343 Implementers should not transmit the same content on a connection 344 that is protected with an external PSK and a connection that is not. 345 Doing so may allow an eavesdropper to correlate the connections, 346 making the content vulnerable to the future invention of a large- 347 scale quantum computer. 349 Implementations must generate external PSKs with a secure key 350 management technique, such as pseudo-random generation of the key or 351 derivation of the key from one or more other secure keys. The use of 352 inadequate pseudo-random number generators (PRNGs) to generate 353 external PSKs can result in little or no security. An attacker may 354 find it much easier to reproduce the PRNG environment that produced 355 the external PSKs and searching the resulting small set of 356 possibilities, rather than brute force searching the whole key space. 357 The generation of quality random numbers is difficult. [RFC4086] 358 offers important guidance in this area. 360 TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are 361 bound to a specific hash function and KDF. By contrast, TLS 1.2 362 [RFC5246] allows PSKs to be used with any hash function and the TLS 363 1.2 PRF. Thus, the safest approach is to use a PSK with either TLS 364 1.2 or TLS 1.3. However, any PSK that might be used with both TLS 365 1.2 and TLS 1.3 must be used with only one hash function, which is 366 the one that is bound for use in TLS 1.3. This restriction is less 367 than optimal when users want to provision a single PSK. While the 368 constructions used in TLS 1.2 and TLS 1.3 are both based on HMAC 369 [RFC2104], the constructions are different, and there is no known way 370 in which reuse of the same PSK in TLS 1.2 and TLS 1.3 that would 371 produce related outputs. 373 TLS 1.3 [RFC8446] has received careful security analysis, and some 374 informal reasoning shows that the addition of this extension does not 375 introduce any security defects. This extension requires the use of 376 certificates for authentication, but the processing of certificates 377 is unchanged by this extension. This extension places an external 378 PSK in the key schedule as part of the computation of the Early 379 Secret. In the initial handshake without this extension, the Early 380 Secret is computed as: 382 Early Secret = HKDF-Extract(0, 0) 384 With this extension, the Early Secret is computed as: 386 Early Secret = HKDF-Extract(External PSK, 0) 388 Any entropy contributed by the external PSK can only make the Early 389 Secret better; the External PSK cannot make it worse. For these two 390 reasons, TLS 1.3 continues to meet its security goals when this 391 extension is used. 393 8. Acknowledgments 395 Many thanks to Nikos Mavrogiannopoulos, Nick Sullivan, Martin 396 Thomson, and Peter Yee for their review and comments; their efforts 397 have improved this document. 399 9. References 401 9.1. Normative References 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, 405 DOI 10.17487/RFC2119, March 1997, 406 . 408 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 409 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 410 May 2017, . 412 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 413 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 414 . 416 9.2. Informative References 418 [DH] Diffie, W. and M. Hellman, "New Directions in 419 Cryptography", IEEE Transactions on Information 420 Theory V.IT-22 n.6, June 1977. 422 [I-D.hoffman-c2pq] 423 Hoffman, P., "The Transition from Classical to Post- 424 Quantum Cryptography", draft-hoffman-c2pq-04 (work in 425 progress), August 2018. 427 [IEEE1363] 428 Institute of Electrical and Electronics Engineers, "IEEE 429 Standard Specifications for Public-Key Cryptography", IEEE 430 Std 1363-2000, 2000. 432 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 433 Hashing for Message Authentication", RFC 2104, 434 DOI 10.17487/RFC2104, February 1997, 435 . 437 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 438 "Randomness Requirements for Security", BCP 106, RFC 4086, 439 DOI 10.17487/RFC4086, June 2005, 440 . 442 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 443 (TLS) Protocol Version 1.2", RFC 5246, 444 DOI 10.17487/RFC5246, August 2008, 445 . 447 Author's Address 449 Russ Housley 450 Vigil Security, LLC 451 516 Dranesville Road 452 Herndon, VA 20170 453 USA 455 Email: housley@vigilsec.com