idnits 2.17.1 draft-housley-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 (March 1, 2018) is 2249 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 (-28) exists of draft-ietf-tls-tls13-24 == Outdated reference: A later version (-07) exists of draft-hoffman-c2pq-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 March 1, 2018 5 Expires: September 2, 2018 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-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 2, 2018. 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 [I-D.ietf-tls-tls13] handshake protocol provides two 52 mutually exclusive forms of server authentication. First, the server 53 can be authenticated by providing a signature certificate and 54 demonstrating that it possesses the corresponding private key by 55 creating a valid digital signature. Second, the server can be 56 authenticated by demonstrating that it possesses a pre-shared key 57 (PSK) that was established by a previous handshake. A PSK that is 58 established in this fashion is called a resumption PSK. A PSK that 59 is established by any other means is called an external PSK. This 60 document specifies a TLS 1.3 extension permitting certificate-based 61 server authentication to be combined with an external PSK as an input 62 to the TLS 1.3 key schedule. 64 The invention of a large-scale quantum computer would pose a serious 65 challenge for the cryptographic algorithms that are widely deployed 66 today, including the digital signature algorithms that are used to 67 authenticate the server in the TLS 1.3 handshake protocol. It is an 68 open question whether or not it is feasible to build a large-scale 69 quantum computer, and if so, when that might happen. However, if 70 such a quantum computer is invented, many of the cryptographic 71 algorithms and the security protocols that use them would become 72 vulnerable. 74 The TLS 1.3 handshake protocol employs key agreement algorithms that 75 could be broken by the invention of a large-scale quantum computer 76 [I-D.hoffman-c2pq]. These algorithms include Diffie-Hellman (DH) 77 [DH] and Elliptic Curve Diffie-Hellman (ECDH) [IEEE1363]. As a 78 result, an adversary that stores a TLS 1.3 handshake protocol 79 exchange today could decrypt the associated encrypted communications 80 in the future when a large-scale quantum computer becomes available. 82 In the near-term, this document describes TLS 1.3 extension to 83 protect today's communications from the future invention of a large- 84 scale quantum computer by providing a strong external PSK as an input 85 to the TLS 1.3 key schedule while preserving the authentication 86 provided by the existing certificate and digital signature 87 mechanisms. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 3. Extension Overview 99 This section provides a brief overview of the 100 "tls_cert_with_extern_psk" extension. 102 The client includes the "tls_cert_with_extern_psk" extension in the 103 ClientHello message. The "tls_cert_with_extern_psk" extension MUST 104 accompanied by the "key_share", "psk_key_exchange_modes", and 105 "pre_shared_key" extensions. The "pre_shared_key" extension MUST be 106 the last extension in the ClientHello message, and it provides a list 107 of external PSK identifiers that the client is willing to use with 108 this server. Since tls_cert_with_extern_psk" extension is intended 109 to be used only with initial handshakes, it MUST NOT be sent 110 alongside the "early_data" extension. These extension are all 111 described in Section 4.2 of [I-D.ietf-tls-tls13]. 113 If the server is willing to use one of the external PSKs listed in 114 the "pre_shared_key" extension and perform certificate-based 115 authentication, then the server includes the 116 "tls_cert_with_extern_psk" extension in the ServerHello message. The 117 "tls_cert_with_extern_psk" extension MUST accompanied by the 118 "key_share" and "pre_shared_key" extensions. If none of the external 119 PSKs in the list provided by the client is acceptable to the server, 120 then the "tls_cert_with_extern_psk" extension is omitted from the 121 ServerHello message. 123 The successful negotiation of the "tls_cert_with_extern_psk" 124 extension requires the TLS 1.3 key schedule processing to include 125 both the selected external PSK and the (EC)DHE shared secret value. 126 As a result, the Early Secret, Handshake Secret, and Master Secret 127 values all depend upon the value of the selected external PSK. 129 The authentication of the server and optional authentication of the 130 client depend upon the ability to generate a signature that can be 131 validated with the public key in their certificates. The 132 authentication processing is not changed in any way by the selected 133 external PSK. 135 Each external PSK is associated with a single Hash algorithm. The 136 hash algorithm MUST be set when the PSK is established, with a 137 default of SHA-256 if no hash algorithm is specified during 138 establishment. 140 4. Certificate with External PSK Extension 142 This section specifies the "tls_cert_with_extern_psk" extension, 143 which MAY appear in the ClientHello message and ServerHello message. 144 It MUST NOT appear in any other messages. The 145 "tls_cert_with_extern_psk" extension MUST NOT appear in the 146 ServerHello message unless "tls_cert_with_extern_psk" extension 147 appeared in the preceding ClientHello message. If an implementation 148 recognizes the "tls_cert_with_extern_psk" extension and receives it 149 in any other message, then the implementation MUST abort the 150 handshake with an "illegal_parameter" alert. 152 The general extension mechanisms enable clients and servers to 153 negotiate the use of specific extensions. Clients request extended 154 functionality from servers with the extensions field in the 155 ClientHello message. If the server responds with a HelloRetryRequest 156 message, then the client sends another ClientHello message as 157 described in Section 4.1.2 of [I-D.ietf-tls-tls13], and it MUST 158 include the same "tls_cert_with_extern_psk" extension as the original 159 ClientHello message or abort the handshake. 161 Many server extensions are carried in the EncryptedExtensions 162 message; however, the "tls_cert_with_extern_psk" extension is carried 163 in the ServerHello message. It is only present in the ServerHello 164 message if the server recognizes the "tls_cert_with_extern_psk" 165 extension and the server possesses one of the external PSKs offered 166 by the client in the "pre_shared_key" extension in the ClientHello 167 message. 169 The Extension structure is defined in [I-D.ietf-tls-tls13]; it is 170 repeated here for convenience. 172 struct { 173 ExtensionType extension_type; 174 opaque extension_data<0..2^16-1>; 175 } Extension; 177 The "extension_type" identifies the particular extension type, and 178 the "extension_data" contains information specific to the particular 179 extension type. 181 This document specifies the "tls_cert_with_extern_psk" extension, 182 adding one new type to ExtensionType: 184 enum { 185 tls_cert_with_extern_psk(TBD), (65535) 186 } ExtensionType; 188 The "tls_cert_with_extern_psk" extension is relevant when the client 189 and server possess an external PSK in common that can be used as an 190 input to the TLS 1.3 key schedule. 192 To use an external PSK with certificates, clients MUST provide the 193 "tls_cert_with_extern_psk" extension, and it MUST be accompanied by 194 the "key_share", "psk_key_exchange_modes", and "pre_shared_key" 195 extensions in the ClientHello. If clients offer a 196 "tls_cert_with_extern_psk" extension without all of these other 197 extensions, servers MUST abort the handshake. The client MAY also 198 find it useful to include the the "supported_groups" extension. Note 199 that Section 4.2 of [I-D.ietf-tls-tls13] allows extensions to appear 200 in any order, with the exception of the "pre_shared_key" extension, 201 which MUST be the last extension in the ClientHello. Also, there 202 MUST NOT be more than one instance of each extension in the 203 ClientHello message. 205 The "key_share" extension is defined in Section 4.2.8 of 206 [I-D.ietf-tls-tls13]. 208 The "psk_key_exchange_modes" extension is defined in Section 4.2.9 of 209 [I-D.ietf-tls-tls13]. The "psk_key_exchange_modes" extension 210 restricts both the use of PSKs offered in this ClientHello and those 211 which the server might supply via a subsequent NewSessionTicket. As 212 a result, clients MUST include the psk_dhe_ke mode, and clients MAY 213 also include the psk_ke mode to support a subsequent 214 NewSessionTicket. Servers MUST select the psk_dhe_ke mode for the 215 initial handshake. Servers MUST select a key exchange mode that is 216 listed by the client for subsequent handshakes that include the 217 resumption PSK from the initial handshake. 219 The "supported_groups" extension is defined in Section 4.2.7 of 220 [I-D.ietf-tls-tls13]. 222 The "pre_shared_key" extension is defined in Section 4.2.11 of 223 [I-D.ietf-tls-tls13]. the syntax is repeated below for convenience. 224 All of the listed PSKs MUST be external PSKs. 226 struct { 227 opaque identity<1..2^16-1>; 228 uint32 obfuscated_ticket_age; 229 } PskIdentity; 231 opaque PskBinderEntry<32..255>; 233 struct { 234 PskIdentity identities<7..2^16-1>; 235 PskBinderEntry binders<33..2^16-1>; 236 } OfferedPsks; 238 struct { 239 select (Handshake.msg_type) { 240 case client_hello: OfferedPsks; 241 case server_hello: uint16 selected_identity; 242 }; 243 } PreSharedKeyExtension; 245 The OfferedPsks contains the list of PSK identities and associated 246 binders for the external PSKs that the client is willing to use with 247 the server. 249 The identities are a list of external PSK identities that the client 250 is willing to negotiate with the server. Each external PSK has an 251 associated identity that is known to the client and the server. (The 252 identity is also referred to as an identifier or a label.) 254 The obfuscated_ticket_age is not used for external PSKs; clients 255 SHOULD set this value to 0, and servers MUST ignore the value. 257 The binders are a series of HMAC values, one for each external PSK 258 offered by the client, in the same order as the identities list. The 259 HMAC value is computed using the binder_key, which is derived from 260 the external PSK, and a partial transcript of the current handshake. 261 Generation of the binder_key from the external PSK is described in 262 Section 7.1 of [I-D.ietf-tls-tls13]. The partial transcript of the 263 current handshake includes a partial ClientHello up to and including 264 the PreSharedKeyExtension.identities field as described in 265 Section 4.2.11.2 of [I-D.ietf-tls-tls13]. 267 The selected_identity contains the external PSK identity that the 268 server selected from the list offered by the client. If none of the 269 offered external PSKs in the list provided by the client are 270 acceptable to the server, then the "tls_cert_with_extern_psk" 271 extension MUST be omitted from the ServerHello message. The server 272 MUST validate the binder value that corresponds to the selected 273 external PSK as described in Section 4.2.11.2 of 274 [I-D.ietf-tls-tls13]. If the binder does not validate, the server 275 MUST abort the handshake with an "illegal_parameter" alert. Servers 276 SHOULD NOT attempt to validate multiple binders; rather they SHOULD 277 select one of the offered external PSKs and validate only the binder 278 that corresponds to that external PSK. 280 When the "tls_cert_with_extern_psk" extension is successfully 281 negotiated, authentication of the server depends upon the ability to 282 generate a signature that can be validated with the public key in the 283 server's certificate. This is accomplished by the server sending the 284 Certificate and CertificateVerify messages as described in Sections 285 4.4.2 and 4.4.3 of [I-D.ietf-tls-tls13]. 287 TLS 1.3 does not permit the server to send a CertificateRequest 288 message when a PSK is being used. This restriction is removed when 289 the "tls_cert_with_extern_psk" extension is negotiated, allowing the 290 certificate-based authentication for both the client and the server. 291 If certificate-based client authentication is desired, this is 292 accomplished by the client sending the Certificate and 293 CertificateVerify messages as described in Sections 4.4.2 and 4.4.3 294 of [I-D.ietf-tls-tls13]. 296 Section 7.1 of [I-D.ietf-tls-tls13] specifies the TLS 1.3 Key 297 Schedule. The successful negotiation of the 298 "tls_cert_with_extern_psk" extension requires the key schedule 299 processing to include both the external PSK and the (EC)DHE shared 300 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 5. 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 6. Security Considerations 317 The Security Considerations in [I-D.ietf-tls-tls13] remain relevant. 319 TLS 1.3 [I-D.ietf-tls-tls13] 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 7. Acknowledgments 352 Many thanks to Peter Yee for his review and comments on an early 353 draft of this document. 355 8. References 357 8.1. Normative References 359 [I-D.ietf-tls-tls13] 360 Rescorla, E., "The Transport Layer Security (TLS) Protocol 361 Version 1.3", draft-ietf-tls-tls13-24 (work in progress), 362 February 2018. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, 366 DOI 10.17487/RFC2119, March 1997, 367 . 369 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 370 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 371 May 2017, . 373 8.2. Informative References 375 [DH] Diffie, W. and M. Hellman, "New Directions in 376 Cryptography", IEEE Transactions on Information 377 Theory V.IT-22 n.6, June 1977. 379 [I-D.hoffman-c2pq] 380 Hoffman, P., "The Transition from Classical to Post- 381 Quantum Cryptography", draft-hoffman-c2pq-03 (work in 382 progress), February 2018. 384 [IEEE1363] 385 Institute of Electrical and Electronics Engineers, "IEEE 386 Standard Specifications for Public-Key Cryptography", IEEE 387 Std 1363-2000, 2000. 389 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 390 "Randomness Requirements for Security", BCP 106, RFC 4086, 391 DOI 10.17487/RFC4086, June 2005, 392 . 394 Author's Address 396 Russ Housley 397 Vigil Security, LLC 398 918 Spring Knoll Drive 399 Herndon, VA 20170 400 USA 402 Email: housley@vigilsec.com