idnits 2.17.1 draft-vanrein-tls-kdh-06.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 250: '...peer. This initiating peer MAY use an...' RFC 2119 keyword, line 283: '... to be eligable, MUST assure they meet...' RFC 2119 keyword, line 398: '...ese requirements MUST be met by a Tick...' RFC 2119 keyword, line 400: '...nd the recipient MUST respond to it by...' RFC 2119 keyword, line 422: '... "qh_method" MUST be set to "kdh" un...' (51 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 22, 2020) is 1557 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Section 3' is mentioned on line 278, but not defined == Missing Reference: 'Section 2' is mentioned on line 284, but not defined == Missing Reference: 'GCM' is mentioned on line 690, but not defined == Missing Reference: 'RFC8439' is mentioned on line 691, but not defined == Missing Reference: 'RFC7748' is mentioned on line 701, but not defined == Unused Reference: 'RFC5869' is defined on line 824, but no explicit reference was found in the text == Unused Reference: 'RFC8446' is defined on line 835, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Van Rein 3 Internet-Draft T. Vrancken 4 Intended status: Informational InternetWide.org 5 Expires: July 25, 2020 January 22, 2020 7 Quantum Relief with TLS and Kerberos 8 draft-vanrein-tls-kdh-06 10 Abstract 12 This specification describes a mechanism to use Kerberos 13 authentication within the TLS protocol. This gives users of TLS a 14 strong alternative to classic PKI-based authentication, and at the 15 same introduces a way to insert entropy into TLS' key schedule such 16 that the resulting protocol becomes resistant against attacks from 17 quantum computers. We call this Quantum Relief, and specify it as 18 part of a more general framework to make it easier for other 19 technologies to achieve similar benefits. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 25, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Quantum Relief as a General Mechanism . . . . . . . . . . . . 3 57 2.1. Peer-to-Peer Flow . . . . . . . . . . . . . . . . . . . . 4 58 3. TLS-KDH for Quantum Relief through Kerberos . . . . . . . . . 4 59 3.1. Injecting Kerberos-derived Entropy . . . . . . . . . . . 5 60 3.2. Client-to-Server Flow . . . . . . . . . . . . . . . . . . 5 61 3.3. Peer-to-Peer Flow . . . . . . . . . . . . . . . . . . . . 6 62 4. New Data Types and Procedures . . . . . . . . . . . . . . . . 6 63 4.1. Quantum Relief Extension . . . . . . . . . . . . . . . . 6 64 4.2. Ticket-based Encryption Procedure . . . . . . . . . . . . 8 65 4.3. Kerberos Ticket and TGT . . . . . . . . . . . . . . . . . 9 66 4.4. Certificate Types . . . . . . . . . . . . . . . . . . . . 9 67 5. Changes to TLS Messages and Behaviour . . . . . . . . . . . . 9 68 5.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.3. Server-sent CertificateRequest . . . . . . . . . . . . . 11 71 5.4. Server-sent Certificate and CertificateVerify . . . . . . 11 72 5.5. Client-sent Certificate and CertificateVerify . . . . . . 12 73 5.6. Length of Finished . . . . . . . . . . . . . . . . . . . 12 74 5.7. Selection of Cipher Suites . . . . . . . . . . . . . . . 12 75 5.8. Tickets and Connection Expiration . . . . . . . . . . . . 12 76 6. Cryptographic Modes . . . . . . . . . . . . . . . . . . . . . 13 77 6.1. Quantum Relief for Encryption in TLS 1.3 . . . . . . . . 13 78 6.2. Quantum Relief for Encryption in TLS 1.2 . . . . . . . . 14 79 6.3. Kerberos Ticket as Certificate and CertificateVerify . . 14 80 7. KDH-Only Application Profile . . . . . . . . . . . . . . . . 15 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 8.1. Encryption . . . . . . . . . . . . . . . . . . . . . . . 16 83 8.2. Server Authentication . . . . . . . . . . . . . . . . . . 16 84 8.3. Client Authentication . . . . . . . . . . . . . . . . . . 16 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 10. Normative References . . . . . . . . . . . . . . . . . . . . 18 87 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 TLS protects many application protocols from many security problems. 93 To enable this, it habitually relies on public-key cryptography. But 94 in the foreseeable future, quantum computers are expected to destroy 95 these public-key underpinnings. This endangers TLS, because 96 encrypted data may be captured and stored, ready for decryption as 97 soon as quantum computers hit the playing field. 99 With present-day applications of TLS threatened by quantum computers, 100 some may not be able to live up to user's legal requirements for 101 long-term encryption. There even is a risk of future power 102 imbalances between those who have a quantum computer and those who 103 have not. 105 One solution is to not rely solely on public-key cryptography, but 106 instead mix in secret entropy that a future quantum computing entity 107 cannot decipher. In this light, Kerberos offers an interesting 108 perspective, as it builds a symmetric-key infrastructure including 109 cross-realm connectivity options. Kerberos is considered safe from 110 quantum computers, as long as its public-key extensions are avoided. 112 Herein, we specify a quantum_relief extension that mixes secret 113 entropy from another source into the TLS key computations. This 114 concrete mechanism, which relies on Kerberos for relief against 115 quantum computing and on (Elliptic-Curve) Diffie-Hellman for Perfect 116 Forward Secrecy (and to stop the sphere of influence of the KDC 117 administrator), shall be referred to as Kerberised Diffie-Hellman or 118 KDH. A definition is included for a KDH-Only Application Profile, to 119 facilitate small and simple implementations. 121 2. Quantum Relief as a General Mechanism 123 The PSK mechanism in TLS 1.3 and 1.2 allows insertion of key material 124 which is referenced by name alone. A naming system is defined, but 125 its interpretation resides under local policy, which is enough for 126 internal use cases, but it is insufficient for general use between 127 any two parties. 129 Cryptographically however, the entropy from the PSK mechanism in TLS 130 1.3 is secret to external observers, and mixed with the DHE material 131 using a series of HKDF-Extract and -Expand operations [[RFC5869]]. 132 When used on their own, the DHE material can be reversed by quantum 133 computers and any subsequent HKDF computations redone, uncovering the 134 complete key schedule of TLS. The extra source of entropy inserted 135 for a PSK however, will have to be uncovered separately, and this 136 will not be possible in the general case. 138 This specification therefore defines a quantum_relief extension that 139 replaces the locally useful PSK scheme with a generally usable 140 mechanism for the insertion of secret entropy into the TLS 1.3 key 141 schedule at the position otherwise used by the PSK; this sacrifices 142 support for 0-RTT data in TLS 1.3. In TLS 1.2, an extension to the 143 computation of the master secret inserts the extra entropy. 145 In order to provide sufficient Quantum Relief the added entropy must 146 meet the following conditions: 148 o The amount of entropy must on its own suffice for the security 149 level of the TLS connection. 151 o The entropy should only be known to parties that are not expected 152 to operate a quantum computer (for example because they are 153 nearby, contractually bound or otherwise within batting range). 155 o Only quantum-proof mechanisms should be used for the generation of 156 the entropy. 158 In terms of algorithms that are commonplace today, the third 159 requirement is generally believed to be met by secure hashes and 160 symmetric encryption. The problem with these is sharing random 161 information secretely and at the same time controlling who has access 162 to these secrets. 164 2.1. Peer-to-Peer Flow 166 Besides the customary client-to-server flow there is also support for 167 a peer-to-peer flow under Quantum Relief. When this is used, the 168 ClientHello sent to a TLS server by an initiating peer holds a 169 peernametype other than "none" followed by a corresponding name for 170 the responding peer. 172 Without documenting it here, the TLS server is assumed to have some 173 method of locating a responding peer with this information, and 174 proxying the entire TLS connection to its endpoint. The only service 175 performed by the TLS server is relaying the literal TLS connection 176 between the initiating client/peer and this responding peer. The TLS 177 server is not involved in cryptographic computations for the TLS 178 connection. 180 3. TLS-KDH for Quantum Relief through Kerberos 182 TLS-KDH is a mode of using TLS that was designed to provide two 183 things, (1) an alternative to PKIX credentials in TLS [RFC5280] and 184 (2) Quantum Relief for TLS connections. 186 The infrastructure of Kerberos provides a good balance between the 187 requirements for a Quantum Relief mechanism, as a result of key 188 derivation to hierarchical expansion of locally controlled secrets. 190 In the TLS 1.3 key schedule, the quantum_relief extension replaces 191 the input from a PSK; the two extensions are not considered useful 192 when combined. In TLS 1.2, a similar result is achieved by enhancing 193 the pre-master secret independently of the negotiated cipher suite. 195 In addition to Quantum Relief, TLS-KDH can offer authentication based 196 on Kerberos tickets. This introduces new facilities into TLS, such 197 as deferred authentication, anonymous realm users and centralised 198 facilitation of realm crossover. 200 3.1. Injecting Kerberos-derived Entropy 202 Whether a Ticket is supplied in the ClientHello or returned by a 203 responding peer in the ServerHello, it yields a key only known to the 204 two connecting parties. This key is used in standard Kerberos 205 encryption of the concatenated random data from ClientHello and 206 ServerHello. This means that both parties influence the entropy 207 gathered and can derive a sequence of bytes that is unknown to anyone 208 else. The output from the encryption operation is plugged into the 209 key schedule instead of the PSK input parameter. This input is 210 suited for entropy of arbitrary size. 212 3.2. Client-to-Server Flow 214 The flow of TLS 1.3 works best when encryption is provided early, and 215 authentication is provided late. These aspects are often combined in 216 Kerberos, but KDH splits them to resemble TLS patterns more closely, 217 offering separate Kerberos-based protocol fragments for (1) 218 additional secret entropy for encryption, (2) client authentication 219 through Kerberos Tickets and (3) server authentication through 220 Kerberos Tickets. Only (1) provides Quantum Relief. The server 221 cannot initiate Kerberos, so (3) without (1) is not possible. When 222 (2) is used without (1), Quantum Relief is not achieved. 224 The TLS-KDH flow uses ClientHello and ServerHello for a Kerberos- 225 protected exchange of entropy, but it completely ignores the client 226 identity during this phase. This allows clients to use an anonymous 227 Ticket in the ClientHello message and consider authenticating with an 228 identifying Ticket in later client Certificate and CertificateVerify 229 messages. 231 Server identity however, is observed in all Tickets, so any use of 232 the Ticket's contained key by the server suffices as proof of its 233 identity. This renders the server Certificate and CertificateVerify 234 messages redundant if the server accepts the KDH extension, 235 especially in TLS 1.3 because the Finished message follows 236 immediately. But redundancy can be a feature; it is certainly 237 legitimate to also authenticate the server with an explicit Kerberos 238 Ticket, a PKIX certificate or other form. 240 When the server desires proof of client identity, it sends a 241 CertificateRequest. KDH introduces a certificate type for a Kerberos 242 Ticket, relying on a Kerberos Authenticator as CertificateVerify 243 message. The server is also able to use this to prove being able to 244 use a supplied Ticket with its identity. 246 3.3. Peer-to-Peer Flow 248 TLS-KDH supports the peer-to-peer flow when the QuantumRelief 249 extensions specifies "krb5princrealm" as peernametype, followed by a 250 TGT from the initiating peer. This initiating peer MAY use an 251 anonymous name for itself in the TGT. 253 The responding peer returns in its ServerHello a Ticket based on this 254 TGT, obtained through the user-to-user flow of Kerberos. This return 255 Ticket will reverse the client and server role for Kerberos compared 256 to TLS, but for peer-to-peer connectivity that is not an issue. The 257 responding peer will authenticate itself to the initiating peer 258 through its use of this return Ticket and it can decide whether 259 authentication of the initiating client is desired. 261 If and when the TLS client authenticates through a Kerberos Ticket, 262 it uses the responding peer name as the service name and its own name 263 as the client name, in line with the TLS roles for client and server. 265 4. New Data Types and Procedures 267 The following data structures are introduced to define the Quantum 268 Relief mechanism for TLS 1.3 and 1.2. Additionally, specific values 269 and procedures are defined for the TLS-KDH mechanism that implements 270 one specific form of quantum relief for TLS. 272 4.1. Quantum Relief Extension 274 This section defines a new TLS extension called quantum_relief that 275 enables quantum relief for TLS as defined in Section 2. The 276 extension is designed such that it can be applied generically. As a 277 concrete quantum relief implementation we herein define how this 278 exentions must be used for TLS-KDH [Section 3]. Future mechanisms 279 may extend this definition. 281 In order to distinguish between different Quantum Relief methods a 282 QuantumReliefMethod tag is defined to set KDH aside from possible 283 future forms which, to be eligable, MUST assure they meet the 284 conditions for providing proper entropy [Section 2]. 286 enum { 287 kdh(0), 288 (65535) 289 } QuantumReliefMethod; 291 The value "kdh" is used for the TLS-KDH form of Quantum Relief 292 defined herein. 294 A TLS ClientHello can additionally specify a name for a peer that it 295 wants to respond, for which various application-independent forms may 296 be anticipated. This is captured in yet another tag PeerNameType, of 297 which only a type for unencrypted Kerberos names is currently defined 298 (i.e. krb5princrealm). 300 enum { 301 none(0), 302 krb5princrealm(1), 303 (65535) 304 } PeerNameType; 306 The value "none" is used for client-to-server TLS connections. The 307 value "krb5princrealm" is used in a ClientHello to indicate a 308 Kerberos PrincipalName and Realm [Section 5.2.2 of [RFC4120]] for the 309 responding peer sought behind the TLS server in peer-to-peer TLS 310 connections. 312 The Quantum Relief Extension is now defined as follows: 314 struct { 315 PeerNameType peernametype; 316 select (peernametype) { 317 case none: 318 /* No peer name type */ 319 Empty; 320 case krb5princrealm: 321 /* PrincipalName and Realm, resp. */ 322 struct { 323 opaque krb5princ<3..1023>; 324 opaque krb5realm<3..1023>; 325 } krb5PrincipalRealm; 326 } 327 QuantumReliefMethod qh_method; 328 select (qh_method) { 329 case kdh: 330 /* Empty, ticket or TGT */ 331 opaque opt_ticket<0..65535>; 332 } 333 } QuantumRelief; 334 This structure is used as extension_data corresponding to the 335 quantum_relief(TBD:QREXTTYPE) extension_type, to occur only during 336 ClientHello and ServerHello. 338 4.2. Ticket-based Encryption Procedure 340 The TLS-KDH messages and cryptographic computations require the use 341 of the key concealed in a Ticket to produce a binary object that 342 cryptographically binds its input to the key. It is variably used as 343 a source of entropy and as proof, but it is always obtained through a 344 standard encryption procedure for Kerberos. 346 Signature: 347 o = Ticket-Encrypt (t, u, h) 349 Input: 350 - Ticket t 351 - KeyUsage u 352 - Hash h 354 Output: 355 - OctetString o 357 Steps: 358 1. base-key = t.enc-part.key 359 2. specific-key = rfc3961.key-derivation (base-key, u) 360 3. init-state = rfc3961.initial-cipher-state ( 361 specific-key, DIRECTION_ENCRYPT) 362 4. (state,o) = rfc3961.encrypt (specific-key, init-state) 364 Not shown in the procedure, there is a need to decrypt the enc-part 365 of the Ticket before the key concealed in it can be extracted. This 366 is where proof of identity comes into play; only the two parties 367 connected by the Ticket should be able to perform this decryption. 369 The name prefix "rfc3961" points to the generic descriptions for 370 Kerberos key-based procedures [RFC3961] that are implemented with 371 various algorithms. Available algorithms are listed in the IANA 372 Registry of Kerberos Parameters. 374 The Key Usage values are numbers, for which the following are defined 375 by this specification. Their number ranges are deliberately chosen 376 to not clash with those of Kerberos, but otherwise compliant to the 377 application range [Section 7.5.1 of [RFC4120]]. The Key Usage values 378 are referenced by name elsewhere in this specification. 380 2008 = KEYUSAGE_TLS12KDH_PREMASTER_QH 381 2018 = KEYUSAGE_TLSKDH_CLIENT_QH 382 2019 = KEYUSAGE_TLSKDH_SERVER_QH 383 2020 = KEYUSAGE_TLSKDH_SERVER_VFY 384 2021 = KEYUSAGE_TLSKDH_CLIENT_VFY 386 4.3. Kerberos Ticket and TGT 388 Where this text speaks of a TGT, short for Ticket Granting Ticket, it 389 imposes the following requirements to the PrincipalName in the sname 390 field of a Ticket: 392 o The name-type is set to NT-SRV-INST or 2 394 o The name-string consists of two component strings 396 o The first name-string component string is the fixed string krbtgt 398 To be a TGT, all these requirements MUST be met by a Ticket; a Ticket 399 that should be a TGT but does not meet all these conditions is badly 400 formed and the recipient MUST respond to it by reporting error 401 bad_certificate and closing the connection. 403 4.4. Certificate Types 405 In order to be able to negotiate Kerberos Tickets as certificate 406 types for the Certificate messages, a new certifcate type is 407 introduced that can be used in the "client_certificate_type" and 408 "server_certificate_type" extensions: 410 o Kerberos Ticket (TBD:KRBTKT-CERTTP) 412 5. Changes to TLS Messages and Behaviour 414 Although TLS-KDH does not introduce any new messages for TLS, there 415 are however a few modifications to the contents or the manner of 416 processing of existing messages. Unless specified otherwise, the 417 modifications apply to TLS 1.3 and 1.2 alike. 419 5.1. ClientHello 421 When this message contains the "quantum_relief" extension, its 422 "qh_method" MUST be set to "kdh" under this specification. Further 423 requirements to this extension depend on the pattern of use being 424 client-to-server [Section 3.2] or peer-to-peer [Section 3.3]. 426 To initiate client-to-server traffic, the "peernametype" MUST be set 427 to "none", and the "opt_ticket" MUST be a Ticket with the service 428 name, host or domain name and Kerberos realm of the addressed 429 service. The client name in the "opt_ticket" MAY be an anonymous 430 identity and the server MUST ignore the client identity in the 431 "opt_ticket". When the "server_name" extension is also sent, there 432 SHOULD be restrictions enforced by the server on its relation with 433 the service name in the "opt_ticket", but this may involve domain-to- 434 hostname mappings, for instance through DNS SRV records under DNSSEC 435 protection. 437 To initiate peer-to-peer traffic that could be proxied through the 438 TLS server to end at a responding peer, the "peernametype" MUST NOT 439 be set to "none", and the "opt_ticket" MUST be a TGT for the TLS 440 client, suited for the ticket granting service of the TLS server's 441 realm; it is permitted for the client to use an anonymous identity in 442 this TGT and the server MUST ignore the client identity in the 443 "opt_ticket". When the "peernametype" is set to "krb5princrealm", 444 the "krb5princ" and "krb5realm" fields MUST be set to the Kerberos 445 PrincipalName and Realm for the desired responding peer. Future 446 extensions may introduce alternative forms of responding peer 447 identity and a TLS server SHOULD be open to the general idea of 448 identity. 450 When a ClientHello message contains the "quantum_relief" extension, 451 it MUST NOT include any references to a PSK. It MAY independently 452 negotiate client and server certificate types [RFC7250] and cipher 453 suites. 455 5.2. ServerHello 457 When the server accepts the "quantum_relief" extension, it replies 458 with its own "quantum_relief" extension and refrains from making any 459 PSK references. This specification defines a response to ClientHello 460 extensions with "qh_method" set to "kdh", for which the ServerHello 461 extension MUST be set to "kdh" also. 463 When the ClientHello extension had its "peernametype" set to "none", 464 the ServerHello extension responds to a client-to-server connection 465 request. The TLS data will be procesed on the server and the 466 response extension MUST set the "opt_ticket" field to a zero-length 467 byte string. 469 When the ClientHello extension had its "peernametype" set to another 470 value than "none", then the TLS server SHOULD use this to locate a 471 responding peer, which may have registered through a mechanism not 472 specified herein, and proxy the TLS traffic to this responding peer. 473 The TLS server continues to proxy TLS traffic until the connection 474 closes. When such peer-to-peer connectivity is not supported by a 475 TLS server or when the peer name could not be resolved or when the 476 responding peer is unresponsible, the TLS server MUST send a 477 handshake_failure alert and close the connection. 479 When a responding peer, possibly after registering with a TLS server 480 as a recipient for peer-to-peer TLS connections, receives a 481 ClientHello with a "quantum_relief" extension with "qh_method" set to 482 "kdh" and a "peernametype" and "peername" that it recognises as its 483 own and with a TGT in the "opt_ticket" field, it should engage in a 484 user-to-user ticket request with the ticket granting service for its 485 realm. It MUST reject the connection if this procedure fails. When 486 a Ticket is obtained, it constructs a ServerHello with a 487 "quantum_relief" extension, sets "qh_method" to "kdh" and 488 "peernametype" to "none", and "opt_ticket" to the just-obtained 489 Ticket. Furthermore, it continues to act as though the client had 490 contacted it directly, while being forgiving to the proxied nature of 491 the connection that carries the TLS traffic. There are no grounds 492 for assuming anything about the client identity. 494 5.3. Server-sent CertificateRequest 496 Since client identity is ignored by the server or responding peer 497 during ClientHello and ServerHello and may indeed be toned down to an 498 anonymous identity, a server-side requiring to know its client MAY 499 send a CertificateRequest in order to verify the client's identity. 500 The CertificateRequest MUST be sent when a client_certificate_type 501 has been negotiated [RFC7250]. When permitted by the TLS 1.3 client 502 with the post_handshake_auth extension, this MAY also be sent at any 503 later time. Under TLS 1.2, TLS renegotiation permits a similar 504 facility. 506 5.4. Server-sent Certificate and CertificateVerify 508 The Certificate and CertificateVerify messages are not always 509 required, because (1) the "quantum_relief" extension captures the 510 server identity, and (2) proof thereof is deferred to Finished, which 511 under TLS 1.3 is available to the client before it sends the client 512 Certificate. Even in cases when it is not strictly required, a 513 server MAY opt for sending server Certificate and CertificateVerify. 515 The "server_certificate_type" extension may be used to negotiate any 516 supported type for these messages, including the Kerberos Ticket 517 certificate type defined herein. When not negotiated, the default 518 type is a PKIX certificate [RFC5280]. Note that a server cannot 519 initiate a Kerberos exchange, so a Kerberos type cannot be used when 520 the client did not send (or the server rejected) a "quantum_relief" 521 extension or when the extension did not provide a Ticket or TGT such 522 as it does when the "qh_method" is "kdh". 524 5.5. Client-sent Certificate and CertificateVerify 526 Under TLS 1.3, the server can request client authentication by 527 sending a CertificateRequest message. It is possible for servers to 528 do this at any time (provided that the client has sent the 529 "post_handshake_auth" extension), and possibly multiple times; TLS 530 1.3 even defines how to handle overlapping requests for client 531 authentication. 533 Clients MAY choose to respond to a CertificateRequest by sending a 534 Certificate and CertificateVerify, and the server MAY choose to close 535 the connection if the client chooses otherwise. 537 The "client_certificate_type" extension may be used to negotiate any 538 supported type for these messages, including the Kerberos Ticket 539 certificate type defined before. When not negotiated, the default 540 type is X.509. Note that a client can produce a Kerberos Ticket even 541 when no "quantum_relief" extension was negotiated during ClientHello 542 and/or ServerHello, or even when another "qh_method" than "kdh" was 543 agreed. However, a client MUST NOT send Certifcate and 544 CertificateVerify messages if it did not receive a CertificateRequest 545 from the server. 547 5.6. Length of Finished 549 Under TLS 1.3, the Finished message is as long as the transcript 550 hash. Under TLS 1.2, this is negotiable. For TLS-KDH under TLS 1.2 551 the client MUST request the "verify_data" length within the Finished 552 message to be as long as the output length of the hash being used to 553 compute it, and the server MUST accept this. 555 5.7. Selection of Cipher Suites 557 Under TLS 1.3, all current cipher suites incorporate (Elliptic-Curve) 558 Diffie-Hellman. Under TLS 1.2 this is optional. For TLS-KDH the 559 client MUST offer cipher suites that include these forms (i.e. 560 ECDHE) of key agreement and the server MUST NOT select a cipher suite 561 without any of these forms of key agreement. 563 5.8. Tickets and Connection Expiration 565 Tickets in Kerberos represent a key-based connection between two 566 peers. The key material in a Ticket is time-limited in the 567 understanding that a client can always request a new Ticket if so 568 desired. Expiration of a Ticket SHOULD be matched with a teardown of 569 the service. In terms of TLS-KDH, that means that the connection 570 SHOULD NOT exist beyond the life time of a Ticket. Each side can 571 independently close down the TLS connection with an 572 certificate_expired alert. 574 To avoid this, it is possible to request a new client Certificate and 575 CertificateVerify through a new CertificateRequest, best sent 576 sometime before expiry. The client then acquires a fresh or 577 prolonged Ticket and once exchanged the connection may continue up to 578 the timeout of the new Ticket. 580 The timeout is updated by every new Ticket supplied in the 581 "opt_ticket" field of a "quantum_relief" extension with "qh_method" 582 set to "kdh", or by a Certificate of type Kerberos Ticket, provided 583 that it is followed by a valid CertificateVerify. 585 A server MUST NOT send data over a connection with a timed-out 586 Ticket, but SHOULD request a fresh one or disconnect. A client MUST 587 NOT send data over a connection with a timed-out Ticket according to 588 its local clock, but it MAY await the arrival a fresh Ticket. Data 589 arriving over a connection with a timed-out Ticket is considered a 590 failure to refresh a ticket. It is a good precaution to request a 591 fresh Ticket a few minutes before the active one expires, to 592 compensate for clock skew between TLS end points. 594 Kerberos supports Tickets with future validity times, intended for 595 such things as nightly batch jobs that require authentication. By 596 default, a TLS stack MUST reject such Tickets until they start being 597 valid. It is however possible for applications to override this 598 behaviour and treat the connection especially after being informed of 599 the future time at which it becomes valid. 601 6. Cryptographic Modes 603 The introduction of the Quantum Relief extension (in combination with 604 TLS-KDH) leads to a few cryptographic changes to the TLS protocol. 605 Below, the three modes introduced are discussed independently. 606 Separate treatment for TLS 1.3 and 1.2 is only necessary for Quantum 607 Relief encryption. The aspects of client and server authentication 608 with Kerberos Tickets use the same data structures and are discussed 609 together. 611 6.1. Quantum Relief for Encryption in TLS 1.3 613 Under client-to-server TLS-KDH, the "opt_ticket" in the 614 "quantum_relief" extension in the ClientHello is used to supply 615 external (quantum proof) key material. Under peer-to-peer TLS-KDH, 616 the TGT in the "opt_ticket" supplies no shared key material to the 617 client and server (or responding peer), but the ServerHello returns a 618 "quantum_relief" extension with an "opt_ticket" field holding a 619 Ticket that does supply a shared key to use. 621 This key is used to compute Ticket-Encrypt (opt_ticket, usage, 622 ClientHello.random || ServerHello.random) where || signifies 623 concatenation, and usage is either KEYUSAGE_TLSKDH_CLIENT_QR for a 624 Ticket supplied by the client, or KEYUSAGE_TLSKDH_SERVER_QR for a 625 Ticket supplied by the server side (or responding peer). The output 626 of this computation is provided instead of the PSK on the left of the 627 Key Schedule for TLS 1.3 [page 93 of [RFC8446]]. Note how the 628 ServerHello is involved in this computation, and not just the 629 ClientHello; had PSK facilities been used, then this seeding would 630 have arrived too late to provide the binder_key, 631 client_early_traffic_secret and early_exporter_master_key. But 632 replacing the locally oriented PSK mechanism with TLS-KDH, means that 633 there is no facility for early data or other PSK facilities, so these 634 keys need not be computed. 636 Other "qh_method" values than "kdh" are likely to come up with other 637 computations. There may be some that prefer to influence only the 638 master key by replacing the 0 value for key input as it is shown in 639 the TLS 1.3 key schedule. 641 6.2. Quantum Relief for Encryption in TLS 1.2 643 TLS 1.2 does not offer any form of encryption during the handshake, 644 so Quantum Relief for TLS 1.2 can only be used to strengthen the 645 Master Secret. When the "quantum_relief" extension with the "kdh" 646 method is accepted by the server, a Ticket is available while forming 647 the ServerHello; it is in the ClientHello for client-to-server mode 648 and in the ServerHello for peer-to-peer mode. Call this Ticket qrt 649 and use it to compute Ticket-Encrypt (qrt, 650 KEYUSAGE_TLS12KDH_PREMASTER_QH, ClientHello.random || 651 ServerHello.random), where || denotes concatenation. The output of 652 this procedure is a octet string which is prepended to what the 653 cipher-suite defines as its pre-master secret. This prepended form 654 is then used instead of the normal pre-master secret during the 655 computation of the master key. 657 6.3. Kerberos Ticket as Certificate and CertificateVerify 659 Kerberos Tickets(TBD:KRBTKT-CERTTP) can be negotiated independently 660 as client_certificate_type and server_certificate_type [RFC7250], 661 though the latter is impossible without a client certificate; in TLS- 662 KDH, a client certificate is available when the server accepts the 663 client's quantum_relief extension. 665 The contents of the Certificate message when the certificate type is 666 negotiated as this "Kerberos" certificate type is a Kerberos Ticket 667 [RFC4120]. 669 The contents of the corresponding CertificateVerify message uses this 670 Ticket k5crt to compute Ticket-Encrypt (k5crt, KEYUSAGE_CLIENT_VFY, 671 th) for a client CertificateVerify message or Ticket-Encrypt (k5crt, 672 KEYUSAGE_SERVER_VFY, th) for a server CertificateVerify message, 673 where th is the customary hash up to and including the preceding 674 Certificate message. For TLS 1.3, this customary hash uses the 675 transcript hash; for TLS 1.2, the hash algorithm must match the 676 Certificate signing algorithm, which in case of a Kerberos Ticket 677 means its MAC hashing algorithm without reductions in the size of the 678 hash output. 680 7. KDH-Only Application Profile 682 The default use of TLS involves authentication based on X.509 683 certificates. In some scenarios such a PKI is not available or not 684 desirable. For this reason, the remainder of this section defines an 685 alternative, KDH-Only Application Profile as minimally being TLS-KDH 686 compliant. 688 TLS-KDH-compliant applications MUST implement the 689 TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the 690 TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 691 [RFC8439] cipher suites. 693 TLS-KDH-compliant applications MUST support the Kerberos Ticket 694 certificate type. They also MUST treat X.509 as the default 695 certificate type, but they MAY refuse any attempt to use it, either 696 by negotiating an explicit alternative or failing to negotiate an 697 alternative. 699 TLS-KDH-compliant applications MUST support key exchanges with 700 secp256r1 (NIST P-256) and SHOULD support key exchanges with X25519 701 [RFC7748]. 703 TLS-KDH-compliant applications MUST support the quantum_relief TLS 704 extension, for which the qh_method value "kdh" MUST be supported, and 705 the peernametype value "none" MUST and "krb5princrealm" SHOULD be 706 supported. 708 8. Security Considerations 710 Quantum Relief is an alternative to the PSK mechanism, which may have 711 similar benefits for local setups, but is not subject of discussion 712 here. The loss of PSK facilities means that no Early Data can be 713 sent, which can be resolved by sending the same data later. It is a 714 loss of efficiency, but not of security. 716 8.1. Encryption 718 To establish that encryption has successfully been established, a 719 party must validate encrypted data received from the other. This is 720 at least the case when a proper Finished message arrives, which 721 provides ample entropy to be certain, incorporating the identities 722 exchanged throughout the handshake. 724 In TLS 1.3, the parties may send encrypted data which may provide 725 ample entropy as well. The transcript hash does not include the 726 entropy derived with the Quantum Relief extension, and so 727 authentication cannot be used as proof of having established 728 encryption unless it is as a provider of verifiable entropy that is 729 wrapped in handshake encryption. 731 The late establishment of encryption has an impact on the privacy of 732 client identity. This identity is unprotected in TLS 1.2, but under 733 TLS 1.3 its privacy is protected with encryption. To ensure that the 734 right party is communicating remotely, the Finished message SHOULD be 735 processed before sending the client's Certificate. 737 8.2. Server Authentication 739 The identity of the server under generic Quantum Relief needs to wait 740 for the arrival of the server's Certificate and CertificateVery 741 messages. Specifically for TLS-KDH, the ability to decrypt a Ticket 742 (for the client-to-server flow) or to produce a Ticket from a TGT 743 (for the peer-to-peer flow) provides the same proof. Clients MAY use 744 this, but MUST also validate a Certificate and CertificateVerify if 745 the server sends them. 747 Under TLS-KDH, the server produces a Ticket with identities for both 748 client and server. The client MUST be able to extract the secret 749 from the Ticket, as an assurance that it is the designated receiver 750 for this identity claim. The verification of the CertificateVerify 751 assures this, as well as the binding to the TLS flow through the 752 transcript hash. 754 8.3. Client Authentication 756 The server MUST NOT process any client identity in the QuantumRelief 757 extension, because that may be either an anonymous identity or a 758 pseudonym, to avoid public visibility. When client identity is 759 needed by the server, it MUST ask for it with a CertificateRequest. 761 The client Certificate and CertificateVerify provide the proper 762 identity for the client, which MAY differ from any identity passed 763 before. 765 Under TLS-KDH, the client produces a Ticket with identities for both 766 client and server. The server MUST be able to extract the secret 767 from the Ticket, as an assurance that it is the designated receiver 768 for this identity claim. The verification of the CertificateVerify 769 assures this, as well as the binding to the TLS flow through the 770 transcript hash. 772 9. IANA Considerations 774 IANA adds the following TLS ExtensionType Value as part of their 775 Transport Layer Security Extensions registry: 777 Value Extension Name TLS 1.3 Recommended Reference 778 TBD:QREXTTYP quantum_relief CH, SH Y TBD:ThisSpec 780 IANA adds the following TLS Certificate Type as part of their 781 Transport Layer Security Extensions registry: 783 Value Name Recommended Reference 784 TBD:KRBTKT-CERTTP Kerberos Ticket Y TBD:ThisSpec 786 IANA creates a registry for the QuantumReliefMethod in the TBD: TLS 787 Extensions registry, with the following initial entries and new 788 entries to be assigned under a Specification Required policy. 790 Value Method Reference 791 ----------- ------------------------ ------------ 792 0 kdh TBD:ThisSpec 793 1-65281 Unassigned 794 65282-65535 Reserved for Private Use TBD:ThisSpec 796 IANA creates a registry for the PeerNameType in the TBD: TLS 797 Extensions registry, with the following initial entries and new 798 entries to be assigned under a Specification Required policy. 800 Value Name Type Reference 801 ----------- ------------------------ ------------ 802 0 none TBD:ThisSpec 803 1 krb5princrealm TBD:ThisSpec 804 2-65281 Unassigned 805 65282-65535 Reserved for Private Use TBD:ThisSpec 807 10. Normative References 809 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 810 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 811 2005, . 813 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 814 Kerberos Network Authentication Service (V5)", RFC 4120, 815 DOI 10.17487/RFC4120, July 2005, 816 . 818 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 819 Housley, R., and W. Polk, "Internet X.509 Public Key 820 Infrastructure Certificate and Certificate Revocation List 821 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 822 . 824 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 825 Key Derivation Function (HKDF)", RFC 5869, 826 DOI 10.17487/RFC5869, May 2010, 827 . 829 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 830 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 831 Transport Layer Security (TLS) and Datagram Transport 832 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 833 June 2014, . 835 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 836 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 837 . 839 Appendix A. Acknowledgements 841 This specification could not have matured without the insights of 842 various commenters. In order of appearance, we owe thanks to Simo 843 Sorce, Ilari Liusvaara, Watson Ladd, Benjamin Kaduk, Nikos 844 Mavragiannopoulos, Kenneth Raeburn. 846 Part of this work was conducted under a grant from the programme 847 "[veilig] door innovatie" from the government of the Netherlands. It 848 has also been liberally supported by the NLnet Foundation. 850 Authors' Addresses 851 Rick van Rein 852 InternetWide.org 853 Haarlebrink 5 854 Enschede, Overijssel 7544 WP 855 The Netherlands 857 Email: rick@openfortress.nl 859 Tom Vrancken 860 InternetWide.org 861 TBD:WHICH 862 Eindhoven, Noord-Brabant TBD:WHICH 863 The Netherlands 865 Email: tom.vrancken@arpa2.org