idnits 2.17.1 draft-housley-tls-tls13-cert-with-extern-psk-03.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 (November 8, 2018) is 1989 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 November 8, 2018 5 Expires: May 12, 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-03 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 May 12, 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 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 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 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. 194 To use an external PSK with certificates, clients MUST provide the 195 "tls_cert_with_extern_psk" extension, and it MUST be accompanied by 196 the "key_share", "psk_key_exchange_modes", and "pre_shared_key" 197 extensions in the ClientHello. If clients offer a 198 "tls_cert_with_extern_psk" extension without all of these other 199 extensions, servers MUST abort the handshake. The client MAY also 200 find it useful to include the the "supported_groups" extension. Note 201 that Section 4.2 of [RFC8446] allows extensions to appear in any 202 order, with the exception of the "pre_shared_key" extension, which 203 MUST be the last extension in the ClientHello. Also, there MUST NOT 204 be more than one instance of each extension in the ClientHello 205 message. 207 The "key_share" extension is defined in Section 4.2.8 of [RFC8446]. 209 The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of 210 [RFC8446]. The "psk_key_exchange_modes" extension restricts both the 211 use of PSKs offered in this ClientHello and those which the server 212 might supply via a subsequent NewSessionTicket. As a result, clients 213 MUST include the psk_dhe_ke mode, and clients MAY also include the 214 psk_ke mode to support a subsequent NewSessionTicket. Servers MUST 215 select the psk_dhe_ke mode for the initial handshake. Servers MUST 216 select a key exchange mode that is listed by the client for 217 subsequent handshakes that include the resumption PSK from the 218 initial handshake. 220 The "supported_groups" extension is defined in Section 4.2.7 of 221 [RFC8446]. 223 The "pre_shared_key" extension is defined in Section 4.2.11 of 224 [RFC8446]. the syntax is repeated below for convenience. All of the 225 listed PSKs MUST be external PSKs. 227 struct { 228 opaque identity<1..2^16-1>; 229 uint32 obfuscated_ticket_age; 230 } PskIdentity; 232 opaque PskBinderEntry<32..255>; 234 struct { 235 PskIdentity identities<7..2^16-1>; 236 PskBinderEntry binders<33..2^16-1>; 237 } OfferedPsks; 239 struct { 240 select (Handshake.msg_type) { 241 case client_hello: OfferedPsks; 242 case server_hello: uint16 selected_identity; 243 }; 244 } PreSharedKeyExtension; 246 The OfferedPsks contains the list of PSK identities and associated 247 binders for the external PSKs that the client is willing to use with 248 the server. 250 The identities are a list of external PSK identities that the client 251 is willing to negotiate with the server. Each external PSK has an 252 associated identity that is known to the client and the server. (The 253 identity is also referred to as an identifier or a label.) 255 The obfuscated_ticket_age is not used for external PSKs; clients 256 SHOULD set this value to 0, and servers MUST ignore the value. 258 The binders are a series of HMAC values, one for each external PSK 259 offered by the client, in the same order as the identities list. The 260 HMAC value is computed using the binder_key, which is derived from 261 the external PSK, and a partial transcript of the current handshake. 262 Generation of the binder_key from the external PSK is described in 263 Section 7.1 of [RFC8446]. The partial transcript of the current 264 handshake includes a partial ClientHello up to and including the 265 PreSharedKeyExtension.identities field as described in 266 Section 4.2.11.2 of [RFC8446]. 268 The selected_identity contains the external PSK identity that the 269 server selected from the list offered by the client. If none of the 270 offered external PSKs in the list provided by the client are 271 acceptable to the server, then the "tls_cert_with_extern_psk" 272 extension MUST be omitted from the ServerHello message. The server 273 MUST validate the binder value that corresponds to the selected 274 external PSK as described in Section 4.2.11.2 of [RFC8446]. If the 275 binder does not validate, the server MUST abort the handshake with an 276 "illegal_parameter" alert. Servers SHOULD NOT attempt to validate 277 multiple binders; rather they SHOULD select one of the offered 278 external PSKs and validate only the binder that corresponds to that 279 external PSK. 281 When the "tls_cert_with_extern_psk" extension is successfully 282 negotiated, authentication of the server depends upon the ability to 283 generate a signature that can be validated with the public key in the 284 server's certificate. This is accomplished by the server sending the 285 Certificate and CertificateVerify messages as described in Sections 286 4.4.2 and 4.4.3 of [RFC8446]. 288 TLS 1.3 does not permit the server to send a CertificateRequest 289 message when a PSK is being used. This restriction is removed when 290 the "tls_cert_with_extern_psk" extension is negotiated, allowing the 291 certificate-based authentication for both the client and the server. 292 If certificate-based client authentication is desired, this is 293 accomplished by the client sending the Certificate and 294 CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 295 of [RFC8446]. 297 Section 7.1 of [RFC8446] specifies the TLS 1.3 Key Schedule. The 298 successful negotiation of the "tls_cert_with_extern_psk" extension 299 requires the key schedule processing to include both the external PSK 300 and the (EC)DHE shared secret value. 302 If the client and the server have different values associated with 303 the selected external PSK identifier, then the client and the server 304 will compute different values for every entry in the key schedule, 305 which will lead to the termination of the connection with a 306 "decrypt_error" alert. 308 6. IANA Considerations 310 IANA is requested to update the TLS ExtensionType Registry to include 311 "tls_cert_with_extern_psk" with a value of TBD and the list of 312 messages "CH, SH" in which the "tls_cert_with_extern_psk" extension 313 may appear. 315 7. Security Considerations 317 The Security Considerations in [RFC8446] remain relevant. 319 TLS 1.3 [RFC8446] does not permit the server to send a 320 CertificateRequest message when a PSK is being used. This 321 restriction is removed when the "tls_cert_with_extern_psk" extension 322 is offered by the client and accepted by the server. However, TLS 323 1.3 does not permit an external PSK to be used in the same fashion as 324 a resumption PSK, and this extension does not alter those 325 restrictions. Thus, a certificate MUST NOT be used with a resumption 326 PSK. 328 Implementations must protect the external pre-shared key (PSK). 329 Compromise of the external PSK will make the encrypted session 330 content vulnerable to the future invention of a large-scale quantum 331 computer. 333 Implementers should not transmit the same content on a connection 334 that is protected with an external PSK and a connection that is not. 335 Doing so may allow an eavesdropper to correlate the connections, 336 making the content vulnerable to the future invention of a large- 337 scale quantum computer. 339 Implementations must choose external PSKs with a secure key 340 management technique, such as pseudo-random generation of the key or 341 derivation of the key from one or more other secure keys. The use of 342 inadequate pseudo-random number generators (PRNGs) to generate 343 external PSKs can result in little or no security. An attacker may 344 find it much easier to reproduce the PRNG environment that produced 345 the external PSKs and searching the resulting small set of 346 possibilities, rather than brute force searching the whole key space. 347 The generation of quality random numbers is difficult. [RFC4086] 348 offers important guidance in this area. 350 TLS 1.3 [RFC8446] takes a conservative approach to PSKs; they are 351 bound to a specific hash function and KDF. By contrast, TLS 1.2 352 [RFC5246] allows PSKs to be used with any hash function and the TLS 353 1.2 PRF. Thus, the safest approach is to use a PSK with either TLS 354 1.2 or TLS 1.3. However, any PSK that might be used with both TLS 355 1.2 and TLS 1.3 must be used with only one hash function, which is 356 the one that is bound for use in TLS 1.3. This restriction is less 357 than optimal when users want to provision a single PSK. While the 358 constructions used in TLS 1.2 and TLS 1.3 are both based on HMAC 359 [RFC2104], the constructions are different, and there is no known way 360 in which reuse of the same PSK in TLS 1.2 and TLS 1.3 that would 361 produce related outputs. 363 8. Acknowledgments 365 Many thanks to Nikos Mavrogiannopoulos, Nick Sullivan, Martin 366 Thomson, and Peter Yee for their review and comments; their efforts 367 have improved this document. 369 9. References 371 9.1. Normative References 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, 375 DOI 10.17487/RFC2119, March 1997, 376 . 378 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 379 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 380 May 2017, . 382 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 383 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 384 . 386 9.2. Informative References 388 [DH] Diffie, W. and M. Hellman, "New Directions in 389 Cryptography", IEEE Transactions on Information 390 Theory V.IT-22 n.6, June 1977. 392 [I-D.hoffman-c2pq] 393 Hoffman, P., "The Transition from Classical to Post- 394 Quantum Cryptography", draft-hoffman-c2pq-04 (work in 395 progress), August 2018. 397 [IEEE1363] 398 Institute of Electrical and Electronics Engineers, "IEEE 399 Standard Specifications for Public-Key Cryptography", IEEE 400 Std 1363-2000, 2000. 402 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 403 Hashing for Message Authentication", RFC 2104, 404 DOI 10.17487/RFC2104, February 1997, 405 . 407 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 408 "Randomness Requirements for Security", BCP 106, RFC 4086, 409 DOI 10.17487/RFC4086, June 2005, 410 . 412 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 413 (TLS) Protocol Version 1.2", RFC 5246, 414 DOI 10.17487/RFC5246, August 2008, 415 . 417 Author's Address 419 Russ Housley 420 Vigil Security, LLC 421 918 Spring Knoll Drive 422 Herndon, VA 20170 423 USA 425 Email: housley@vigilsec.com