idnits 2.17.1 draft-vanrein-tls-kdh-05.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == 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 236: '...which, to be eligable, MUST assure the...' RFC 2119 keyword, line 352: '...ese requirements MUST be met by a Tick...' RFC 2119 keyword, line 354: '... recipient SHOULD respond to it by r...' RFC 2119 keyword, line 366: '... qr_method MUST be set to kdh under ...' RFC 2119 keyword, line 370: '...affic, the peernameform MUST be set to...' (38 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 16, 2019) is 1715 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'GCM' is mentioned on line 622, but not defined == Missing Reference: 'RFC8439' is mentioned on line 623, but not defined == Missing Reference: 'RFC7748' is mentioned on line 632, but not defined == Unused Reference: 'RFC8446' is defined on line 650, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 6 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: Standards Track ARPA2.net 5 Expires: February 17, 2020 August 16, 2019 7 Quantum Relief for TLS with Kerberos 8 draft-vanrein-tls-kdh-05 10 Abstract 12 This specification adds Kerberos to the TLS protocol, both as a 13 method of authentication and to insert entropy into the key schedule 14 from a source that does not start in public key cryptography. 16 This brings relief from attacks by quantum computers, and that is 17 specified as part of a more general framework, to make it easier for 18 other technologies to achieve similar benefits. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 17, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Quantum Relief from Pre-Shared Keys . . . . . . . . . . . . . 3 56 3. The Design of TLS-KDH . . . . . . . . . . . . . . . . . . . . 4 57 4. New Data Structures and Procedures . . . . . . . . . . . . . 5 58 4.1. Extension quantum_relief . . . . . . . . . . . . . . . . 5 59 4.2. Ticket-based Encryption Procedure . . . . . . . . . . . . 7 60 4.3. Kerberos Ticket and TGT . . . . . . . . . . . . . . . . . 8 61 5. Changes to TLS Messages . . . . . . . . . . . . . . . . . . . 8 62 5.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 8 63 5.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 9 64 5.3. Server-sent VerifyRequest . . . . . . . . . . . . . . . . 10 65 5.4. Server-sent Certificate and CertificateVerify . . . . . . 10 66 5.5. Client-sent Certificate and CertificateVerify . . . . . . 10 67 5.6. Length of Finished . . . . . . . . . . . . . . . . . . . 11 68 5.7. Selection of Cipher Suites . . . . . . . . . . . . . . . 11 69 5.8. Tickets and Connection Timing . . . . . . . . . . . . . . 11 70 6. Cryptographic Updates . . . . . . . . . . . . . . . . . . . . 12 71 6.1. Quantum Relief for Encryption in TLS 1.3 . . . . . . . . 12 72 6.2. Quantum Relief for Encryption in TLS 1.2 . . . . . . . . 12 73 6.3. Kerberos Ticket as Certificate and CertificateVerify . . 13 74 7. KDH-Only Application Profile . . . . . . . . . . . . . . . . 13 75 8. Normative References . . . . . . . . . . . . . . . . . . . . 14 76 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Introduction 81 TLS protects many application protocols from many security problems. 82 To enable this, it habitually relies on public-key cryptography. But 83 in the foreseeable future, quantum computers are expected to destroy 84 these public-key underpinnings. This is not a current problem for 85 authentication, but it does endanger encrypted data being passed 86 today, which may be captured and stored, ready for decryption as soon 87 as quantum computers hit the playing field. 89 Most present-day applications of TLS are threatened by quantum 90 computers; some may not be able to live up to legal requirements for 91 long-term encryption. There even is a risk of future power 92 imbalances between those who have a quantum computer and those who 93 have not. 95 The solution is to not rely solely on public-key cryptography, but 96 instead mix in secret entropy that a future quantum computing entity 97 cannot decipher. In this light, Kerberos offers an interesting 98 perspective, as it builds a symmetric-key infrastructure including 99 cross-realm connectivity options. Kerberos is considered safe from 100 quantum computers, as long as its public-key extensions are avoided. 102 We therefore specify a quantum_relief extension that mixes secret 103 entropy form another source into the TLS key computations, and we 104 work out a concrete mechanism based on Kerberos. This concrete 105 mechanism, which relies on Kerberos for relief from quantum computing 106 and on (Elliptic-Curve) Diffie-Hellman for Perfect Forward Secrecy 107 and to stop the sphere of influence of the KDC administrator, shall 108 be referred to as Kerberised Diffie-Hellman or KDH. A definition is 109 included for a KDH-Only Appllication Profile, to facilitate small and 110 simple implementations. 112 In the the TLS 1.3 key schedule, the quantum_relief extension 113 replaces the input from a PSK; the two extensions are not considered 114 useful when combined. In TLS 1.2, a similar result is achieved by 115 enhancing the pre-master secret independently of the negotiated 116 cipher suite. 118 2. Quantum Relief from Pre-Shared Keys 120 The PSK mechanism in TLS 1.3 and 1.2 allows insertion of key material 121 which is referenced by name alone. A naming system is defined, but 122 its interpretation resides under local policy, which is enough for 123 internal use cases, but it is insufficient for general use between 124 any two parties. 126 Cryptographically however, the entropy from the PSK mechanism in TLS 127 1.3 is secret to external observers, and mixed with the DHE material 128 using a series of HKDF-Extract and -Expand operations. When used on 129 their own, the DHE material can be reversed by quantum computers and 130 any subsequent HKDF computations redone, uncovering the complete key 131 schedule of TLS. The extra source of entropy inserted for a PSK 132 however, will have to be uncovered separately, and this may not be 133 possible in all cases. 135 This specification therefore defines a quantum_relief extension that 136 replaces the locally useful PSK scheme with a generally usable 137 mechanism for insertion of secret entropy into the TLS 1.3 key 138 schedule in the position otherwise filled by the PSK. As a result, 139 TLS-KDH does not support 0-RTT data. 141 Sufficient conditions to make entropy provide Quantum Relief are: 143 o The amount of entropy must on its own suffice for the security 144 level of the TLS connection. 146 o The entropy must be secret, meaning invisible for outside 147 observers. 149 o Only quantum-proof mechanisms should be used in the processing of 150 the entropy. 152 In terms of algorithms that are commonplace today, the third 153 requirement is generally believed to be met by secure hashes and 154 symmetric encryption. The problem with these is sharing random 155 information secretely and at the same time controlling who has access 156 to these secrets. The infrastructure built by Kerberos provides a 157 good balance between these requirements, as a result of key 158 derivation to expand central secrets in an irreversible manner, so 159 that they may be distributed to various pairs of parties. 161 3. The Design of TLS-KDH 163 The flow of TLS 1.3 works best when encryption is provided early, and 164 authentication is provided late. These things are often the same in 165 Kerberos, but KDH splits these responsibilities to be closer to TLS. 166 The TLS-KDH flow uses ClientHello and ServerHello for a Kerberos- 167 protected exchange of entropy, but it completely ignores client 168 identity during this phase. This allows clients to use an anonymous 169 Ticket in the ClientHello message and consider authenticating with an 170 identifying Ticket in later client Certificate and CertificateVerify 171 messages. 173 Server identity however, is observed in all Tickets, so any use of 174 the Ticket's contained key by the server suffices as proof of its 175 identity. This renders the server Certificate and CertificateVerify 176 messages redundant if the server accepts the KDH extension, 177 especially in TLS 1.3 because the Finished message follows 178 immediately. But redundancy can be a feature; it is certainly 179 legitimate to still authenticate the server with an explicit Kerberos 180 Ticket, X.509 certificate or other. 182 When the server desires proof of client identity, it sends a 183 CertificateRequest. KDH introduces a certificate type for a Kerberos 184 Ticket, relying on a Kerberos Authenticator as CertificateVerify 185 message. The server is also able to use this to prove being able to 186 use a supplied Ticket with its identity. 188 The result offers almost-orthogonal Kerberos versions for (1) 189 additional secret entropy for encryption, (2) client authentication 190 through Kerberos Tickets and (3) server authentication through 191 Kerberos Tickets. All these aspects can independently provide 192 Quantum Relief. The only dependency between these is that the server 193 cannot initiate Kerberos, so (3) requires (1) or another Ticket 194 source. 196 Besides the customary client-to-server flow there is also support for 197 a peer-to-peer flow in TLS-KDH. When this is used, the ClientHello 198 requests a remote peer identity and sends a TGT, possibly with 199 anonymous client name. Without documenting it here, the TLS server 200 is assumed to have some method of locating the remote client and 201 proxying the entire TLS connection to its endpoint. The remote peer 202 then returns a Ticket based on the TGT, obtained through the user-to- 203 user flow of Kerberos. This return Ticket will reverse the client 204 and server role relative to TLS, but for peer-to-peer connectivity 205 that does not matter. The remote peer, which is now the one 206 processing the TLS connection from the server side, will authenticate 207 itself through its use of this return Ticket and it can decide 208 whether authentication of the initiating client is desired. When the 209 client would authenticate through a Kerberos Ticket, this would 210 follow the client and server roles of Kerberos; as before, for peer- 211 to-peer traffic this should not be problematic, even if it imposes a 212 requirement on cross-realm connections that they must be 213 bidirectional. 215 Whether a Ticket is supplied in the ClientHello or returned by a 216 remote peer in the ServerHello, it yields a key only to the two 217 connecting parties. This key is used in standard Kerberos encryption 218 of the concatenated random data from ClientHello and ServerHello. 219 This means that both parties influence the entropy gathered and can 220 derive a sequence of bytes that is invisible to anyone else. The 221 output from the encryption operation is plugged into the key schedule 222 instead of the PSK input parameter. This input is designed for this 223 kind of loose entropy of arbitrary size. 225 4. New Data Structures and Procedures 227 The following data structures are used to define Quantum Relief for 228 TLS 1.3 and 1.2, plus the more specific TLS-KDH form of Quantum 229 Relief. 231 4.1. Extension quantum_relief 233 The data passed during ClientHello and ServerHello are placed in an 234 extension called quantum_relief, of which KDH is currently the only 235 form. A QuantumReliefForm tag is defined to set KDH aside from 236 possible future forms which, to be eligable, MUST assure the 237 sufficient conditions for Quantum Relief Section 2. 239 enum { 240 kdh(0), 241 (65535) 242 } QuantumReliefMethod; 244 The value kdh is always used for the method of Quantum Relief 245 proposed herein, based on Kerberos. 247 The ClientHello can additionally specify a name for a remote peer, 248 for which various application-independent forms may be anticipated; 249 this is captured in yet another tag PeerNameForm, of which only a 250 form for unencrypted Kerberos names is currently defined. 252 enum { 253 none(0), 254 krb5princrealm(1), 255 (65535) 256 } PeerNameForm; 258 The value none is used for standard client-to-server TLS connections. 259 The value krb5princrealm is used in a ClientHello to indicate a 260 Kerberos PrincipalName and Realm [Section 5.2.2 of [RFC4120]] for the 261 remote peer sought behind the TLS server. 263 struct { 264 PeerNameForm peernameform; 265 select (peernameform) { 266 case none: 267 /* No peer name form */ 268 Empty; 269 case krb5princrealm: 270 /* PrincipalName and Realm, resp. */ 271 struct { 272 opaque krb5princ<3..1023>; 273 opaque krb5realm<3..1023>; 274 } krb5PrincipalRealm; 275 } 276 QuantumReliefMethod qr_method; 277 select (qr_method) { 278 case kdh: 279 /* Empty, ticket or TGT */ 280 opaque opt_ticket<0..65535>; 281 } 282 } QuantumReliefExtension; 284 This structure is used as extension_data following the quantum_relief 285 extension_type, registered by IANA under number TBD:QREXTTYPE, to 286 occur only during ClientHello and ServerHello. IANA also created 287 registries for the QuantumReliefMethod and PeerNameForm in their 288 TBD:TLSExtensionsRegistry. 290 4.2. Ticket-based Encryption Procedure 292 The TLS-KDH messages and cryptographic computations require the use 293 of the key concealed in a Ticket to produce a binary object that 294 cryptographically binds its input to the key. It is variably used as 295 a source of entropy and as proof, but it is always obtained through a 296 standard encryption procedure for Kerberos. 298 Signature: 299 o = Ticket-Encrypt (t, u, h) 301 Input: 302 - Ticket t 303 - KeyUsage u 304 - Hash h 306 Output: 307 - OctetString o 309 Steps: 310 1. base-key = t.enc-part.key 311 2. specific-key = rfc3961.key-derivation ( 312 base-key, u) 313 3. init-state = rfc3961.initial-cipher-state ( 314 specific-key, DIRECTION_ENCRYPT) 315 4. (state,o) = rfc3961.encrypt ( 316 specific-key, init-state) 318 Not shown in the procedure, there is a need to decrypt the enc-part 319 of the Ticket before the key concealed in it can be extracted. This 320 is where proof of identity comes into play; only the two parties 321 connected by the Ticket should be able to perform this decryption. 323 The name prefix rfc3961 points to the generic descriptions for 324 Kerberos key-based procedures [RFC3961] that are implemented with 325 various algorithms. Available algorithms are listed in the IANA 326 Registry of Kerberos Parameters. 328 The Key Usage values are numbers, for which the following are defined 329 by this specification. Their number ranges are deliberately chosen 330 to not clash with those of Kerberos, but otherwise compliant to the 331 application range [Section 7.5.1 of [RFC4120]]. The Key Usage values 332 are referenced by name elsewhere in this specification. 334 2008 = KEYUSAGE_TLS12KDH_PREMASTER_QR 335 2018 = KEYUSAGE_TLSKDH_CLIENT_QR 336 2019 = KEYUSAGE_TLSKDH_SERVER_QR 337 2020 = KEYUSAGE_TLSKDH_SERVER_VFY 338 2021 = KEYUSAGE_TLSKDH_CLIENT_VFY 340 4.3. Kerberos Ticket and TGT 342 Where this text speaks of a TGT, short for Ticket Granting Ticket, it 343 imposes the following requirements to the PrincipalName in the sname 344 field of a Ticket: 346 o The name-type is set to NT-SRV-INST or 2; 348 o The name-string consists of two component strings; 350 o The first name-string component string is the fixed string krbtgt. 352 To be a TGT, all these requirements MUST be met by a Ticket; a Ticket 353 that meets some but not all these conditions is badly formed and the 354 recipient SHOULD respond to it by reporting error TODO:WHICH and 355 closing the connection. 357 5. Changes to TLS Messages 359 There are a few modifications to TLS for the TLS-KDH message flow. 360 Unless specified otherwise, the modifications apply to TLS 1.3 and 361 1.2 alike. 363 5.1. ClientHello 365 When this message contains the quantum_relief extension, its 366 qr_method MUST be set to kdh under this specification. Further 367 requirements to this extension depend on the pattern of use being 368 client-to-server or peer-to-peer. 370 To initiate client-to-server traffic, the peernameform MUST be set to 371 none, and the opt_ticket MUST be a Ticket with the service name, host 372 or domain name and Kerberos realm of the addressed service. The 373 client name in the opt_ticket MAY be an anonymous identity and the 374 server MUST ignore the client identity in the opt_ticket. When the 375 server_name extension is also sent, there SHOULD be restrictions 376 enforced by the server on its relation with the service name in the 377 opt_ticket, but this may involve domain-to-hostname mappings, for 378 instance through DNS SRV records under DNSSEC protection. 380 To initiate peer-to-peer traffic that could be proxied through the 381 TLS server to end at a remote peer, the peernameform MUST NOT be set 382 to none, and the opt_ticket MUST be a TGT for the TLS client, suited 383 for the ticket granting service of the TLS server's realm; it is 384 permitted for the client to use an anonymous identity in this TGT and 385 the server MUST ignore the client identity in the opt_ticket. When 386 the peernameform is set to krb5princrealm, the krb5princ and 387 krb5realm fields MUST be set to the Kerberos PrincipalName and Realm 388 for the desired remote peer. Future extensions may introduce 389 alternative forms of remote peer identity and a TLS server SHOULD be 390 open to the general idea of identity. 392 When a ClientHello message contains a quantum_relief extension, it 393 MUST NOT include any references to a PSK. It MAY independently 394 negotiate client and server certificate types and cipher suites. 396 5.2. ServerHello 398 When the server accepts the quantum_relief extension, it replies with 399 its own quantum_relief extension and refrains from making any PSK 400 references. This specification defines a response to ClientHello 401 extensions with qr_method set to kdh, for which the ServerHello 402 extension MUST be set to kdh also. 404 When the ClientHello extension had its peernameform set to none, the 405 ServerHello extension responds to a client-to-server connection 406 request. The TLS data will be terminated on the server and the 407 response extension MUST set the opt_ticket field to a zero-length 408 byte string. 410 When the ClientHello extension had its peernameform set to another 411 value than none, then the TLS server MUST use this to locate a remote 412 peer, which may have registered through a mechanism not specified 413 herein, and proxy the TLS traffic to this remote peer. The TLS 414 server continues to proxy this traffic until it closes the 415 connection. 417 When a remote peer, possibly after registering with a TLS server as a 418 recipient for client-to-client TLS connections, receives a 419 ClientHello with a quantum_relief extension with qr_method set to kdh 420 and a peernameform and peername that it recognises as its own and 421 with a TGT in the opt_ticket field, it should engage in a user-to- 422 user ticket request with the ticket granting service for its realm. 423 It MUST reject the connection if this procedure fails. When a Ticket 424 is obtained, it constructs a ServerHello with a quantum_relief 425 extension, sets qr_method to kdh and peernameform to none, and 426 opt_ticket to the just-obtained Ticket. Furthermore, it continues to 427 act as though the client had contacted it directly, while being 428 forgiving to the proxied nature of the connection that carries the 429 TLS traffic. Specifically, there are no grounds for assuming 430 anything about the client identity, which may be undesirable in a 431 client-to-client connection. 433 5.3. Server-sent VerifyRequest 435 Since client identity is ignored by the server during ClientHello and 436 ServerHello and may indeed be toned down to an anonymous identity, 437 any server-side requiring to know its client MAY send a 438 VerifyRequest. When permitted by the TLS 1.3 client with the 439 post_handshake_auth extension, this MAY also be sent at any later 440 time. Under TLS 1.2, TLS renegotiation permits a similar facility 441 (with much broader impact). 443 The handshake is not encrypted in TLS 1.2, and for TLS 1.3 in peer- 444 to-peer mode the server-side identity is uncertain until the Finished 445 messages. In the interest of the privacy of client identity, it may 446 be desirable to add server-side authentication even when it is not 447 otherwise needed. 449 5.4. Server-sent Certificate and CertificateVerify 451 The Certificate and CertificateVerify messages are not always 452 required, because (1) the quantum_relief extension captures the 453 server identity, and (2) proof thereof is deferred to Finished, which 454 under TLS 1.3 is available to the client before it sends the client 455 Certificate. 457 Even in cases when it is not strictly required, a server MAY opt for 458 sending server Certificate and CertificateVerify, but in such cases 459 clients MUST NOT fail due to the messages being withheld. 461 The server_certificate_type extension may be used to negotiate any 462 form for these messages, including the Kerberos Ticket certificate 463 type defined herein. When not negotiated, the default form is X.509. 464 Note that a server cannot initiate a Kerberos exchange, so a Kerberos 465 form cannot be used when the server rejected the quantum_relief 466 extension or when the extension did not provide a Ticket or TGT such 467 as it does when the qr_method is kdh. 469 5.5. Client-sent Certificate and CertificateVerify 471 Under TLS 1.3, the server can request client authentication at any 472 time, provided that the client has sent the post_handshake_auth 473 extension. It is possible for servers to do this at any time, and 474 possibly multiple times; TLS 1.3 even defines how to handle 475 overlapping requests for client authentication. 477 The client_certificate_type extension may be used to negotiate any 478 form for these messages, including the Kerberos Ticket certificate 479 type define before. When not negotiated, the default form is X.509. 480 Note that a client can produce a Kerberos Ticket even when no 481 quantum_relief extension was negotiated during ClientHello and/or 482 ServerHello, or even when another qr_method than kdh was agreed. 484 5.6. Length of Finished 486 Under TLS 1.3, the Finished message is as long as the transcript 487 hash. Under TLS 1.2, this is negotiable. For TLS-KDH under TLS 1.2 488 the client MUST request the Finished message to be as long as the 489 hash being used to compute it and the server MUST accept this. 491 5.7. Selection of Cipher Suites 493 Under TLS 1.3, all cipher suites incorporate (Elliptic-Curve) Diffie- 494 Hellman. Under TLS 1.2 this is optional. For TLS-KDH under TLS 1.2 495 the client MUST offer cipher suites that include these forms of key 496 agreement and the server MUST NOT select a cipher suite without any 497 of these forms of key agreement. 499 5.8. Tickets and Connection Timing 501 Tickets in Kerberos represent a key-based connection between two 502 peers. The key material in a Ticket is time-limited in the 503 understanding the a client can always request a new Ticket if so 504 desired. Expiration of a Ticket SHOULD be matched with a teardown of 505 the service. In terms of TLS-KDH, that means that the connection 506 SHOULD NOT exist beyond the life time of a Ticket. Each side can 507 independently close down the TLS connection with an ERROR:WHICH 508 alert. 510 To avoid this, it is possible to request a new client Certificate and 511 CertificateVerify through a new VerifyRequest, best sent sometime 512 before expiry. The client then acquires a fresh or prolonged Ticket 513 and once exchanged the connection may continue up to the timeout of 514 the new Ticket. 516 The timeout is updated by every new Ticket supplied in the opt_ticket 517 field of a quantum_relief extension with qr_method set to kdh, or by 518 a Certificate of type Kerberos Ticket, provided that it is followed 519 by a valid CertificateVerify. 521 A server MUST NOT send data over a connection with a timed-out 522 Ticket, but SHOULD request a fresh one or disconnect. A client MUST 523 NOT send data over a connection with a timed-out Ticket, but MAY 524 await the arrival a fresh Ticket. It is a good precaution to request 525 a fresh Ticket a few minutes before the active one expires, to 526 compensate for clock skew between the client and server. 528 Kerberos supports Tickets with future validity times, intended for 529 such things as nightly batch jobs that require authentication. By 530 default, a TLS stack MUST reject such Tickets until they start being 531 valid. It is however possible for applications to override this 532 behaviour and treat the connection especially after being informed of 533 the future time at which it becomes valid. 535 6. Cryptographic Updates 537 The introduction of TLS-KDH leads to a few cryptographic changes to 538 the protocol and its implementation. Below, the three aspects 539 introduced by TLS-KDH are discussed independently. Separate 540 treatment for TLS 1.3 and 1.2 is only necessary for Quantum Relief 541 for encryption. 543 6.1. Quantum Relief for Encryption in TLS 1.3 545 Under client-to-server TLS-KDH, the opt_ticket in the quantum_relief 546 extension is used. Under peer-to-peer TLS-KDH, the TGT in the 547 opt_ticket supplies no shared key material to the client and server 548 (or remote peer), but the ServerHello returns a quantum_relief 549 extension with an opt_ticket field holding a Ticket that does supply 550 a shared key to use. 552 The key is used to compute Ticket-Encrypt (opt_ticket, usage, 553 ClientHello.random | ServerHello.random) where | signifies 554 concatenation and usage is either KEYUSAGE_TLSKDH_CLIENT_QR for a 555 Ticket supplied by the client, or KEYUSAGE_TLSKDH_SERVER_QR for a 556 Ticket supplied by the server side (or remote peer). The output of 557 this computation is provided instead of the PSK on the left of the 558 Key Schedule for TLS 1.3 [page 93 of [RFC8446]]. Since none of the 559 PSK facilities are used under TLS-KDH, this seeding does not arrive 560 too late for the unfolding of the protocol. 562 Other qr_method values than kdh are likely to come up with other 563 computations. There may be some that prefer to influence only the 564 master key by replacing the 0 value for key input as it is shown in 565 the TLS 1.3 key schedule. 567 6.2. Quantum Relief for Encryption in TLS 1.2 569 TLS 1.2 does not offer any form of encryption during the handshake, 570 so the kdh method for TLS 1.2 can only be used to strengthen the 571 Master Secret. When the quantum_relief extension is accepted by the 572 server, a Ticket is available while forming the ServerHello; it is in 573 the ClientHello for client-to-server mode and in the ServerHello for 574 peer-to-peer mode. This Ticket qrt is used to compute Ticket-Encrypt 575 (qrt, KEYUSAGE_TLS12KDH_PREMASTER_QR, ClientHello.random | 576 ServerHello.random), where | denotes concatenation. The output of 577 this procedure is a byte string. It is represented in a TLS type 579 opaque premaster_prefix<0..65535> 581 and, in that form, prepended to the pre-master secret that the cipher 582 suite defines. This prepended form is then used instead of the 583 normal pre-master secret during the computation of the master key. 584 Note that this is only done when client and server agreed to use the 585 quantum_relief extension with kdh as its method. 587 TODO: Tom, dit is arbitrair. Hergebruik van code of structuren kan 588 mogelijk soepeler, ik hoor het dan wel. 590 6.3. Kerberos Ticket as Certificate and CertificateVerify 592 IANA has added Kerberos Ticket with value TBD:KRBTKT-CERTTP to the 593 TLS Certificate Types list in the TLS Extensions Registry. This can 594 be negotiated independently as client_certificate_type and 595 server_certificate_type, though the latter is impossible without a 596 client certificate, even if it is anonymous or just a TGT; in TLS- 597 KDH, this is available when the server accepts the quantum_relief 598 extension. 600 The contents of the Certificate message when the certificate type is 601 negotiated as Kerberos Ticket is a Kerberos Ticket [RFC4120]. 603 The contents of the corresponding CertificateVerify message uses this 604 Ticket k5crt to compute Ticket-Encrypt (k5crt, KEYUSAGE_CLIENT_VFY, 605 th) for a client CertificateVerify message or Ticket-Encrypt (k5crt, 606 KEYUSAGE_SERVER_VFY, th) for a server CertificateVerify message, 607 where th is the customary hash up to and including the preceding 608 Certificate message. For TLS 1.3, this customary hash uses the 609 transcript hash; for TLS 1.2, the hash algorithm must match the 610 Certificate signing algorithm, which in case of a Kerberos Ticket 611 means its MAC hashing algorithm. 613 7. KDH-Only Application Profile 615 The default use of TLS involves X.509 certificate processing with RSA 616 keys, which may be a burden to some endpoints, especially when they 617 are very small or aim for simplicity. For this reason, this section 618 defines an alternative, KDH-Only Application Profile. 620 TLS-KDH-compliant applications MUST implement the 621 TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the 622 TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 623 [RFC8439] cipher suites. 625 TLS-KDH-compliant applications MUST support the Kerberos Ticket 626 certificate type. The also MUST treat X.509 as the default 627 certificate type, but they MAY refuse any attempt to use it, either 628 by negotiating it explicitly or failing to negotiate an alternative. 630 TLS-KDH-compliant applications MUST support key exchange with 631 secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 632 [RFC7748]. 634 TLS-KDH-compliant applications MUST support the quantum_relief 635 extension, for which the qr_method value kdh MUST be supported, and 636 the peernametype value none MUST and krb5princrealm SHOULD be 637 supported. 639 8. Normative References 641 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 642 Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February 643 2005, . 645 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 646 Kerberos Network Authentication Service (V5)", RFC 4120, 647 DOI 10.17487/RFC4120, July 2005, 648 . 650 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 651 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 652 . 654 Appendix A. Acknowledgements 656 This specification could not have matured without the insights of 657 various commenters. In order of appearance, we owe thanks to Simo 658 Sorce, Ilari Liusvaara, Watson Ladd, Benjamin Kaduk, Nikos 659 Mavragiannopoulos. 661 This work was conducted under a grant from the programme "[veilig] 662 door innovatie" from the government of the Netherlands. It has also 663 been liberally supported by the NLnet Foundation. 665 Authors' Addresses 667 Rick van Rein 668 ARPA2.net 669 Haarlebrink 5 670 Enschede, Overijssel 7544 WP 671 The Netherlands 673 Email: rick@openfortress.nl 675 Tom Vrancken 676 ARPA2.net 677 TODO 678 Eindhoven, Noord-Brabant TODO 679 The Netherlands 681 Email: TODO