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