idnits 2.17.1 draft-housley-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 (September 26, 2018) is 2010 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == 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: Standards Track September 26, 2018 5 Expires: March 30, 2019 7 TLS 1.3 Extension for Certificate-based Authentication with an External 8 Pre-Shared Key 9 draft-housley-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 certificate while also providing a pre-shared key 15 (PSK) as an input to the key schedule. 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 March 30, 2019. 34 Copyright Notice 36 Copyright (c) 2018 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 either of these two types of PSK 62 as an input to the 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 BCP 69 14 [RFC2119] [RFC8174] when, and only when, they appear in all 70 capitals, as shown here. 72 3. Motivation and Design Rationale 74 The motivation for using a certificate with an external PSK is 75 different than the motivation for using a certificate with a 76 resumption PSK. 78 3.1. Certificate With External PSK 80 The invention of a large-scale quantum computer would pose a serious 81 challenge for the cryptographic algorithms that are widely deployed 82 today, including the digital signature algorithms that are used to 83 authenticate the server in the TLS 1.3 handshake protocol and key 84 agreement algorithm used to establish a pairwise shared secret 85 between the client and server. It is an open question whether or not 86 it is feasible to build a large-scale quantum computer, and if so, 87 when that might happen. However, if such a quantum computer is 88 invented, many of the cryptographic algorithms and the security 89 protocols that use them would become vulnerable. 91 The TLS 1.3 handshake protocol employs key agreement algorithms that 92 could be broken by the invention of a large-scale quantum computer 93 [I-D.hoffman-c2pq]. These algorithms include Diffie-Hellman (DH) 94 [DH] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]. As a 95 result, an adversary that stores a TLS 1.3 handshake protocol 96 exchange today could decrypt the associated encrypted communications 97 in the future when a large-scale quantum computer becomes available. 99 When a certificate is used for authentication and a strong external 100 PSK is used in conjunction with a key agreement algorithm, today's 101 communications can be protected from the future invention of a large- 102 scale quantum computer. The strong external PSK and the shared 103 secret from the key agreement algorithms are both provided as inputs 104 to the TLS 1.3 key schedule, which preserves the authentication 105 provided by the existing certificate and digital signature 106 mechanisms, and requires the attacker to learn the external PSK as 107 well as the shared secret to break confidentiality. 109 3.2. Certificate With Resumption PSK 111 There are two motivations for using a certificate with a resumption 112 PSK. 114 In the first situation, the client seeks corroboration that the 115 server has access to the private key associated with the certificate. 116 That is, the server uses the same certificate in this handshake as 117 was used to establish the resumption PSK. Successful completion of 118 the handshake requires the server to produce a valid signature in the 119 CertificateVerify handshake message. 121 In the second situation, the server wishes to use a different 122 certificate for the resumption handshake, which allows the resumed 123 session to be associated with a different server identity. 124 Successful completion of the handshake requires the server to produce 125 a valid signature in the CertificateVerify message that can be 126 validated with the public key in the certificate that is provided in 127 the Certificate handshake message. 129 3.3. Design Considerations With Early Data 131 When a client provides early data and makes use of a certificate with 132 a resumption PSK, the server MUST use the same certificate, public 133 key, and private key as in the original handshake. Doing otherwise 134 would create an ambiguity about the server identity that received the 135 early data. For this reason, the handshake fails if the client sends 136 early data and the server uses a different certificate with a 137 resumption PSK. 139 4. Extension Overview 141 This section provides a brief overview of the "tls_cert_with_psk" 142 extension. 144 The client includes the "tls_cert_with_psk" extension in the 145 ClientHello message. The "tls_cert_with_psk" extension MUST 146 accompanied by the "key_share", "psk_key_exchange_modes", and 147 "pre_shared_key" extensions. The "pre_shared_key" extension MUST be 148 the last extension in the ClientHello message, and it provides a list 149 of PSK identifiers that the client is willing to use with this 150 server. If the "tls_cert_with_psk" extension is used with a 151 resumption PSK and the "early_data" extension, then the client MUST 152 check that the server provided the same certificate as was used in 153 the initial handshake. These extensions are all described in 154 Section 4.2 of [RFC8446]. 156 If the server is willing to use one of the PSKs listed in the 157 "pre_shared_key" extension and perform certificate-based 158 authentication, then the server includes the "tls_cert_with_psk" 159 extension in the ServerHello message. The "tls_cert_with_psk" 160 extension MUST be accompanied by the "key_share" and "pre_shared_key" 161 extensions. If none of the PSKs in the list provided by the client 162 is acceptable to the server, then the "tls_cert_with_psk" extension 163 is omitted from the ServerHello message. 165 The successful negotiation of the "tls_cert_with_psk" extension 166 requires the TLS 1.3 key schedule processing to include both the 167 selected PSK and the (EC)DHE shared secret value. As a result, the 168 Early Secret, Handshake Secret, and Master Secret values all depend 169 upon the value of the selected PSK. 171 The authentication of the server and optional authentication of the 172 client depend upon the ability to generate a signature that can be 173 validated with the public key in their certificates. The 174 authentication processing is not changed in any way by the selected 175 PSK. 177 As required by Section 4.2.11 of [RFC8446], each external PSK is 178 associated with a single Hash algorithm. The hash algorithm MUST be 179 set when the external PSK is established, with a default of SHA-256 180 if no hash algorithm is specified during establishment. 182 Resumption PSKs are established via the ticket mechanism described in 183 Section 4.6.1 of [RFC8446]. The hash algorithm associated with the 184 resumption PSK MUST be the same KDF hash algorithm as that used to 185 establish the initial session. This is the KDF hash algorithm of the 186 session where the ticket was established. 188 5. Certificate with PSK Extension 190 This section specifies the "tls_cert_with_psk" extension, which MAY 191 appear in the ClientHello message and ServerHello message. It MUST 192 NOT appear in any other messages. The "tls_cert_with_psk" extension 193 MUST NOT appear in the ServerHello message unless "tls_cert_with_psk" 194 extension appeared in the preceding ClientHello message. If an 195 implementation recognizes the "tls_cert_with_psk" extension and 196 receives it in any other message, then the implementation MUST abort 197 the handshake with an "illegal_parameter" alert. 199 The TLS 1.3 general extension mechanisms enable clients and servers 200 to negotiate the use of specific extensions. Clients request 201 extended functionality from servers with the extensions field in the 202 ClientHello message. If the server responds with a HelloRetryRequest 203 message, then the client sends another ClientHello message as 204 described in Section 4.1.2 of [RFC8446], and it MUST include the same 205 "tls_cert_with_psk" extension as the original ClientHello message or 206 abort the handshake. 208 Many server extensions are carried in the EncryptedExtensions 209 message; however, the "tls_cert_with_psk" extension is carried in the 210 ServerHello message. It is only present in the ServerHello message 211 if the server recognizes the "tls_cert_with_psk" extension and the 212 server possesses one of the PSKs offered by the client in the 213 "pre_shared_key" extension in the ClientHello message. 215 The Extension structure is defined in [RFC8446]; it is repeated here 216 for convenience. 218 struct { 219 ExtensionType extension_type; 220 opaque extension_data<0..2^16-1>; 221 } Extension; 223 The "extension_type" identifies the particular extension type, and 224 the "extension_data" contains information specific to the particular 225 extension type. 227 This document specifies the "tls_cert_with_psk" extension, adding one 228 new type to ExtensionType: 230 enum { 231 tls_cert_with_psk(TBD), (65535) 232 } ExtensionType; 234 In an initial handshake, the "tls_cert_with_psk" extension is 235 relevant when the client and server possess an external PSK in common 236 that can be used as an input to the TLS 1.3 key schedule. In a 237 subsequent handshake, the "tls_cert_with_psk" extension is relevant 238 when the client and server possess a resumptions PSK in common and 239 server authentication with a certificate is desired. The 240 "tls_cert_with_psk" extension has the following syntax: 242 struct { 243 select (Handshake.msg_type) { 244 case client_hello: Empty; 245 case server_hello: Empty; 246 }; 247 } CertWithPSK; 249 To use a PSK with certificates, clients MUST provide the 250 "tls_cert_with_psk" extension, and it MUST be accompanied by the 251 "key_share", "psk_key_exchange_modes", and "pre_shared_key" 252 extensions in the ClientHello. If clients offer a 253 "tls_cert_with_psk" extension without all of these other extensions, 254 servers MUST abort the handshake. The client MAY also find it useful 255 to include the the "supported_groups" extension. If clients offer a 256 "early_data" extension during a resumption handshake, then clients 257 MUST confirm that the server uses the same certificate, public key, 258 and private key as in the handshake that established the resumption 259 PSK. Note that Section 4.2 of [RFC8446] allows extensions to appear 260 in any order, with the exception of the "pre_shared_key" extension, 261 which MUST be the last extension in the ClientHello. Also, there 262 MUST NOT be more than one instance of any extension in the 263 ClientHello message. 265 The "key_share" extension is defined in Section 4.2.8 of [RFC8446]. 267 The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of 268 [RFC8446]. The "psk_key_exchange_modes" extension restricts both the 269 use of PSKs offered in this ClientHello and those which the server 270 might supply via a subsequent NewSessionTicket. As a result, clients 271 MUST include the psk_dhe_ke mode for an initial handshake, and 272 servers MUST select the psk_dhe_ke mode for the initial handshake. 273 Servers MUST select a key exchange mode that is listed by the client 274 for subsequent handshakes that include the resumption PSK from the 275 initial handshake. 277 The "early_data" extension is defined in Section 4.2.10 of [RFC8446]. 279 The "supported_groups" extension is defined in Section 4.2.7 of 280 [RFC8446]. 282 The "pre_shared_key" extension is defined in Section 4.2.11 of 283 [RFC8446]. the syntax is repeated below for convenience. All of the 284 listed PSKs MUST be external PSKs. 286 struct { 287 opaque identity<1..2^16-1>; 288 uint32 obfuscated_ticket_age; 289 } PskIdentity; 291 opaque PskBinderEntry<32..255>; 293 struct { 294 PskIdentity identities<7..2^16-1>; 295 PskBinderEntry binders<33..2^16-1>; 296 } OfferedPsks; 298 struct { 299 select (Handshake.msg_type) { 300 case client_hello: OfferedPsks; 301 case server_hello: uint16 selected_identity; 302 }; 303 } PreSharedKeyExtension; 305 The OfferedPsks contains the list of PSK identities and associated 306 binders for the PSKs that the client is willing to use with the 307 server. 309 The identities are a list of PSK identities that the client is 310 willing to negotiate with the server. Each PSK has an associated 311 identity that is known to the client and the server. (The identity 312 is also referred to as an identifier or a label.) 314 The obfuscated_ticket_age is not used for external PSKs; clients 315 SHOULD set this value to 0, and servers MUST ignore the value. The 316 obfuscated_ticket_age is used for resumption PSKs, and 317 Section 4.2.11.1 of [RFC8446] describes how to form this value for 318 identities established via the NewSessionTicket message. 320 The binders are a series of HMAC values, one for each PSK offered by 321 the client, in the same order as the identities list. The HMAC value 322 is computed using the binder_key, which is derived from the PSK, and 323 a partial transcript of the current handshake. Generation of the 324 binder_key from the PSK is described in Section 7.1 of [RFC8446]. 326 The partial transcript of the current handshake includes a partial 327 ClientHello up to and including the PreSharedKeyExtension.identities 328 field as described in Section 4.2.11.2 of [RFC8446]. 330 The selected_identity contains the PSK identity that the server 331 selected from the list offered by the client. If none of the offered 332 PSKs in the list provided by the client are acceptable to the server, 333 then the "tls_cert_with_psk" extension MUST be omitted from the 334 ServerHello message. The server MUST validate the binder value that 335 corresponds to the selected PSK as described in Section 4.2.11.2 of 336 [RFC8446]. If the binder does not validate, the server MUST abort 337 the handshake with an "illegal_parameter" alert. Servers SHOULD NOT 338 attempt to validate multiple binders; rather they SHOULD select one 339 of the offered PSKs and validate only the binder that corresponds to 340 that PSK. 342 When the "tls_cert_with_psk" extension is successfully negotiated, 343 authentication of the server depends upon the ability to generate a 344 signature that can be validated with the public key in the server's 345 certificate. This is accomplished by the server sending the 346 Certificate and CertificateVerify messages as described in Sections 347 4.4.2 and 4.4.3 of [RFC8446]. 349 TLS 1.3 does not permit the server to send a CertificateRequest 350 message when a PSK is being used. This restriction is removed when 351 the "tls_cert_with_psk" extension is negotiated, allowing the 352 certificate-based authentication for both the client and the server. 353 If certificate-based client authentication is desired, this is 354 accomplished by the client sending the Certificate and 355 CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 356 of [RFC8446]. 358 Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The 359 successful negotiation of the "tls_cert_with_psk" extension requires 360 the key schedule processing in the initial handshake to include both 361 the external PSK and the (EC)DHE shared secret value. In a 362 resumption handshake, the resumption PSK MUST be used in the key 363 schedule, and the (EC)DHE shared secret MAY also be used. 365 If the client and the server have different values associated with 366 the selected PSK identifier, then the client and the server will 367 compute different values for every entry in the TLS 1.3 key schedule, 368 which will lead to the termination of the connection with a 369 "decrypt_error" alert. 371 6. IANA Considerations 373 IANA is requested to update the TLS ExtensionType Registry to include 374 "tls_cert_with_psk" with a value of TBD and the list of messages "CH, 375 SH" in which the "tls_cert_with_psk" extension may appear. 377 7. Security Considerations 379 The Security Considerations in [RFC8446] remain relevant. 381 TLS 1.3 [RFC8446] does not permit the server to send a 382 CertificateRequest message when a PSK is being used. This 383 restriction is removed when the "tls_cert_with_psk" extension is 384 offered by the client and accepted by the server. 386 Implementations need to protect the pre-shared key (PSK). Compromise 387 of the external PSK used in the initial handshake makes the encrypted 388 session content vulnerable to the future invention of a large-scale 389 quantum computer. Compromise of the resumption PSK makes the 390 encrypted session content associated with subsequent sessions 391 vulnerable to an attacker that knows the PSK, and it allows the 392 attacker to initiate new sessions which are also vunlerable. 394 Implementers should not transmit the same content on a connection 395 that is protected with an external PSK and a connection that is not. 396 Doing so may allow an eavesdropper to correlate the connections, 397 making the content vulnerable to the future invention of a large- 398 scale quantum computer. 400 Deployment of a pairwise external PSK between every client and server 401 is not practical. Instead, this specification envisions an external 402 PSK being distributed to a group of clients and group of severs. At 403 some point in the future a large-scale quantum computer might get 404 invented, and if any member of the group has access to it, then that 405 group member can recover the traffic associated with the PSK. 406 However, parties outside the group cannot recover the traffic because 407 the large-scale quantum computer does not assist with the discovery 408 of the external PSK of reasonable size. 410 Implementations must choose external PSKs with a secure key 411 management technique, such as pseudo-random generation of the key or 412 derivation of the key from one or more other secure keys. The use of 413 inadequate pseudo-random number generators (PRNGs) to generate 414 external PSKs can result in little or no security. An attacker may 415 find it much easier to reproduce the PRNG environment that produced 416 the external PSKs and searching the resulting small set of 417 possibilities, rather than brute force searching the whole key space. 419 The generation of quality random numbers is difficult. [RFC4086] 420 offers important guidance in this area. 422 TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are 423 bound to a specific hash function and KDF. By contrast, TLS 1.2 424 [RFC5246] allows PSKs to be used with any hash function and the TLS 425 1.2 PRF. Thus, the safest approach is to use a PSK with either TLS 426 1.2 or TLS 1.3. However, any PSK that might be used with both TLS 427 1.2 and TLS 1.3 must be used with only one hash function, which is 428 the one that is bound for use in TLS 1.3. This restriction is less 429 than optimal when users want to provision a single PSK. While the 430 constructions used in TLS 1.2 and TLS 1.3 are both based on HMAC 431 [RFC2104], the constructions are different, and there is no known way 432 in which reuse of the same PSK in TLS 1.2 and TLS 1.3 that would 433 produce related outputs. 435 8. Acknowledgments 437 Many thanks to Nikos Mavrogiannopoulos, Nick Sullivan, Martin 438 Thomson, and Peter Yee for their review and comments; their efforts 439 have improved this document. 441 9. References 443 9.1. Normative References 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, 447 DOI 10.17487/RFC2119, March 1997, 448 . 450 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 451 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 452 May 2017, . 454 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 455 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 456 . 458 9.2. Informative References 460 [DH] Diffie, W. and M. Hellman, "New Directions in 461 Cryptography", IEEE Transactions on Information 462 Theory V.IT-22 n.6, June 1977. 464 [I-D.hoffman-c2pq] 465 Hoffman, P., "The Transition from Classical to Post- 466 Quantum Cryptography", draft-hoffman-c2pq-04 (work in 467 progress), August 2018. 469 [IEEE1363] 470 Institute of Electrical and Electronics Engineers, "IEEE 471 Standard Specifications for Public-Key Cryptography", IEEE 472 Std 1363-2000, 2000. 474 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 475 Hashing for Message Authentication", RFC 2104, 476 DOI 10.17487/RFC2104, February 1997, 477 . 479 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 480 "Randomness Requirements for Security", BCP 106, RFC 4086, 481 DOI 10.17487/RFC4086, June 2005, 482 . 484 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 485 (TLS) Protocol Version 1.2", RFC 5246, 486 DOI 10.17487/RFC5246, August 2008, 487 . 489 Author's Address 491 Russ Housley 492 Vigil Security, LLC 493 918 Spring Knoll Drive 494 Herndon, VA 20170 495 USA 497 Email: housley@vigilsec.com