idnits 2.17.1 draft-ietf-tls-exported-authenticator-15.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 (4 March 2022) is 784 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS N. Sullivan 3 Internet-Draft Cloudflare Inc. 4 Intended status: Standards Track 4 March 2022 5 Expires: 5 September 2022 7 Exported Authenticators in TLS 8 draft-ietf-tls-exported-authenticator-15 10 Abstract 12 This document describes a mechanism that builds on Transport Layer 13 Security (TLS) or Datagram Transport Layer Security (DTLS) and 14 enables peers to provide a proof of ownership of an identity, such as 15 an X.509 certificate. This proof can be exported by one peer, 16 transmitted out-of-band to the other peer, and verified by the 17 receiving peer. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 5 September 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 54 3. Message Sequences . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Authenticator Request . . . . . . . . . . . . . . . . . . . . 4 56 5. Authenticator . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5.1. Authenticator Keys . . . . . . . . . . . . . . . . . . . 6 58 5.2. Authenticator Construction . . . . . . . . . . . . . . . 7 59 5.2.1. Certificate . . . . . . . . . . . . . . . . . . . . . 8 60 5.2.2. CertificateVerify . . . . . . . . . . . . . . . . . . 8 61 5.2.3. Finished . . . . . . . . . . . . . . . . . . . . . . 10 62 5.2.4. Authenticator Creation . . . . . . . . . . . . . . . 10 63 6. Empty Authenticator . . . . . . . . . . . . . . . . . . . . . 10 64 7. API considerations . . . . . . . . . . . . . . . . . . . . . 11 65 7.1. The "request" API . . . . . . . . . . . . . . . . . . . . 11 66 7.2. The "get context" API . . . . . . . . . . . . . . . . . . 11 67 7.3. The "authenticate" API . . . . . . . . . . . . . . . . . 11 68 7.4. The "validate" API . . . . . . . . . . . . . . . . . . . 12 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 8.1. Update of the TLS ExtensionType Registry . . . . . . . . 13 71 8.2. Update of the TLS Exporter Labels Registry . . . . . . . 13 72 8.3. Update of the TLS HandshakeType Registry . . . . . . . . 13 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 11.2. Informative References . . . . . . . . . . . . . . . . . 15 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 80 1. Introduction 82 This document provides a way to authenticate one party of a Transport 83 Layer Security (TLS) or Datagram Transport Layer Security (DTLS) 84 connection to its peer using authentication messages created after 85 the session has been established. This allows both the client and 86 server to prove ownership of additional identities at any time after 87 the handshake has completed. This proof of authentication can be 88 exported and transmitted out-of-band from one party to be validated 89 by its peer. 91 This mechanism provides two advantages over the authentication that 92 TLS and DTLS natively provide: 94 multiple identities - Endpoints that are authoritative for multiple 95 identities - but do not have a single certificate that includes 96 all of the identities - can authenticate additional identities 97 over a single connection. 99 spontaneous authentication - Endpoints can authenticate after a 100 connection is established, in response to events in a higher-layer 101 protocol, as well as integrating more context (such as context 102 from the application). 104 Versions of TLS prior to TLS 1.3 used renegotiation as a way to 105 enable post-handshake client authentication given an existing TLS 106 connection. The mechanism described in this document may be used to 107 replace the post-handshake authentication functionality provided by 108 renegotiation. Unlike renegotiation, exported Authenticator-based 109 post-handshake authentication does not require any changes at the TLS 110 layer. 112 Post-handshake authentication is defined in section 4.6.3 of TLS 1.3 113 [RFC8446], but it has the disadvantage of requiring additional state 114 to be stored as part of the TLS state machine. Furthermore, the 115 authentication boundaries of TLS 1.3 post-handshake authentication 116 align with TLS record boundaries, which are often not aligned with 117 the authentication boundaries of the higher-layer protocol. For 118 example, multiplexed connection protocols like HTTP/2 [RFC7540] do 119 not have a notion of which TLS record a given message is a part of. 121 Exported Authenticators are meant to be used as a building block for 122 application protocols. Mechanisms such as those required to 123 advertise support and handle authentication errors are not handled by 124 TLS (or DTLS). 126 The minimum version of TLS and DTLS required to implement the 127 mechanisms decribed in this document are TLS 1.2 [RFC6347] and DTLS 128 1.2 [RFC5246]. 130 2. Conventions and Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 This document uses terminology such as client, server, connection, 139 handshake, endpoint, peer that are defined in section 1.1 of 140 [RFC8446]. The term "initial connection" refers to the (D)TLS 141 connection from which the exported authenticator messages are 142 derived. 144 3. Message Sequences 146 There are two types of messages defined in this document: 147 Authenticator Requests and Authenticators. These can be combined in 148 the following three sequences: 150 Client Authentication 152 * Server generates Authenticator Request 154 * Client generates Authenticator from Server's Authenticator Request 156 * Server validates Client's Authenticator 158 Server Authentication 160 * Client generates Authenticator Request 162 * Server generates Authenticator from Client's Authenticator Request 164 * Client validates Server's Authenticator 166 Spontaneous Server Authentication 168 * Server generates Authenticator 170 * Client validates Server's Authenticator 172 4. Authenticator Request 174 The authenticator request is a structured message that can be created 175 by either party of a (D)TLS connection using data exported from that 176 connection. It can be transmitted to the other party of the (D)TLS 177 connection at the application layer. The application layer protocol 178 used to send the authenticator request SHOULD use a secure transport 179 channel with equivalent security to TLS, such as QUIC [RFC9001], as 180 its underlying transport to keep the request confidential. The 181 application MAY use the existing (D)TLS connection to transport the 182 authenticator. 184 An authenticator request message can be constructed by either the 185 client or the server. Server-generated authenticator requests use 186 the CertificateRequest message from Section 4.3.2 of [RFC8446]. 187 Client-generated authenticator requests use a new message, called the 188 ClientCertificateRequest, which uses the same structure as 189 CertificateRequest. (Note that the latter is not a request for a 190 client certificate, but rather a certificate request generated by the 191 client.) These message structures are used even if the connection 192 protocol is TLS 1.2 or DTLS 1.2. 194 The CertificateRequest and ClientCertificateRequest messages are used 195 to define the parameters in a request for an authenticator. These 196 are encoded as TLS handshake messages, including length and type 197 fields. They do not include any TLS record layer framing and are not 198 encrypted with a handshake or application-data key. 200 The structures are defined to be: 202 struct { 203 opaque certificate_request_context<0..2^8-1>; 204 Extension extensions<2..2^16-1>; 205 } ClientCertificateRequest; 207 struct { 208 opaque certificate_request_context<0..2^8-1>; 209 Extension extensions<2..2^16-1>; 210 } CertificateRequest; 212 certificate_request_context: An opaque string which identifies the 213 authenticator request and which will be echoed in the 214 authenticator message. A certificate_request_context value MUST 215 be unique for each authenticator request within the scope of a 216 connection (preventing replay and context confusion). The 217 certificate_request_context SHOULD be chosen to be unpredictable 218 to the peer (e.g., by randomly generating it) in order to prevent 219 an attacker who has temporary access to the peer's private key 220 from pre-computing valid authenticators. For example, the 221 application may choose this value to correspond to a value used in 222 an existing datastructure in the software to simplify 223 implementation. 225 extensions: The set of extensions allowed in the CertificateRequest 226 structure and the ClientCertificateRequest structure are those 227 defined in the TLS ExtensionType Values IANA registry [RFC8447] 228 containing CR in the TLS 1.3 column. In addition, the set of 229 extensions in the ClientCertificateRequest structure MAY include 230 the server_name [RFC6066] extension. 232 The uniqueness requirements of the certificate_request_context apply 233 only to CertificateRequest and ClientCertificateRequest messages that 234 are used as part of authenticator requests, but do apply across 235 CertificateRequest and ClientCertificateRequest messages. A 236 certificate_request_context value used in a ClientCertificateRequest 237 cannot be used in an authenticator CertificateRequest on the same 238 connection, and vice versa. There is no impact if the value of a 239 certificate_request_context used in an authenticator request matches 240 the value of a certificate_request_context in the handshake or in a 241 post-handshake message. 243 5. Authenticator 245 The authenticator is a structured message that can be exported from 246 either party of a (D)TLS connection. It can be transmitted to the 247 other party of the (D)TLS connection at the application layer. The 248 application layer protocol used to send the authenticator SHOULD use 249 a secure transport channel with equivalent security to TLS, such as 250 QUIC [RFC9001], as its underlying transport to keep the authenticator 251 confidential. The application MAY use the existing (D)TLS connection 252 to transport the authenticator. 254 An authenticator message can be constructed by either the client or 255 the server given an established (D)TLS connection, an identity, such 256 as an X.509 certificate, and a corresponding private key. Clients 257 MUST NOT send an authenticator without a preceding authenticator 258 request; for servers an authenticator request is optional. For 259 authenticators that do not correspond to authenticator requests, the 260 certificate_request_context is chosen by the server. 262 5.1. Authenticator Keys 264 Each authenticator is computed using a Handshake Context and Finished 265 MAC Key derived from the (D)TLS connection. These values are derived 266 using an exporter as described in Section 4 of [RFC5705] (for (D)TLS 267 1.2) or Section 7.5 of [RFC8446] (for (D)TLS 1.3). For (D)TLS 1.3, 268 the exporter_master_secret MUST be used, not the 269 early_exporter_master_secret. These values use different labels 270 depending on the role of the sender: 272 * The Handshake Context is an exporter value that is derived using 273 the label "EXPORTER-client authenticator handshake context" or 274 "EXPORTER-server authenticator handshake context" for 275 authenticators sent by the client or server respectively. 277 * The Finished MAC Key is an exporter value derived using the label 278 "EXPORTER-client authenticator finished key" or "EXPORTER-server 279 authenticator finished key" for authenticators sent by the client 280 or server respectively. 282 The context_value used for the exporter is empty (zero length) for 283 all four values. There is no need to include additional context 284 information at this stage since the application-supplied context is 285 included in the authenticator itself. The length of the exported 286 value is equal to the length of the output of the hash function 287 associated with the selected cipher suite (for TLS 1.3) or the hash 288 function used for the pseudorandom function (PRF) (for (D)TLS 1.2). 289 Exported authenticators cannot be used with (D)TLS 1.2 cipher suites 290 that do not use the TLS PRF and with TLS 1.3 cipher suites that do 291 not have an associated hash function. This hash is referred to as 292 the authenticator hash. 294 To avoid key synchronization attacks, Exported Authenticators MUST 295 NOT be generated or accepted on (D)TLS 1.2 connections that did not 296 negotiate the extended master secret extension [RFC7627]. 298 5.2. Authenticator Construction 300 An authenticator is formed from the concatenation of TLS 1.3 301 [RFC8446] Certificate, CertificateVerify, and Finished messages. 302 These messages are encoded as TLS handshake messages, including 303 length and type fields. They do not include any TLS record layer 304 framing and are not encrypted with a handshake or application-data 305 key. 307 If the peer populating the certificate_request_context field in an 308 authenticator's Certificate message has already created or correctly 309 validated an authenticator with the same value, then no authenticator 310 should be constructed. If there is no authenticator request, the 311 extensions are chosen from those presented in the (D)TLS handshake's 312 ClientHello. Only servers can provide an authenticator without a 313 corresponding request. 315 ClientHello extensions are used to determine permissible extensions 316 in the server's unsolicited Certificate message in order to follow 317 the general model for extensions in (D)TLS in which extensions can 318 only be included as part of a Certificate message if they were 319 previously sent as part of a CertificateRequest message or 320 ClientHello message. This ensures that the recipient will be able to 321 process such extensions. 323 5.2.1. Certificate 325 The Certificate message contains the identity to be used for 326 authentication, such as the end-entity certificate and any supporting 327 certificates in the chain. This structure is defined in [RFC8446], 328 Section 4.4.2. 330 The Certificate message contains an opaque string called 331 certificate_request_context, which is extracted from the 332 authenticator request if present. If no authenticator request is 333 provided, the certificate_request_context can be chosen arbitrarily 334 but MUST be unique within the scope of the connection and be 335 unpredictable to the peer. 337 Certificates chosen in the Certificate message MUST conform to the 338 requirements of a Certificate message in the negotiated version of 339 (D)TLS. In particular, the entries of certificate_list MUST be valid 340 for the signature algorithms indicated by the peer in the 341 "signature_algorithms" and "signature_algorithms_cert" extension, as 342 described in Section 4.2.3 of [RFC8446] for (D)TLS 1.3 or from 343 Sections 7.4.2 and 7.4.6 of [RFC5246] for (D)TLS 1.2. 345 In addition to "signature_algorithms" and 346 "signature_algorithms_cert", the "server_name" [RFC6066], 347 "certificate_authorities" (Section 4.2.4. of [RFC8446]), and 348 "oid_filters" (Section 4.2.5. of [RFC8446]) extensions are used to 349 guide certificate selection. 351 Only the X.509 certificate type defined in [RFC8446] is supported. 352 Alternative certificate formats such as [RFC7250] Raw Public Keys are 353 not supported in this version of the specification and their use in 354 this context has not yet been analysed. 356 If an authenticator request was provided, the Certificate message 357 MUST contain only extensions present in the authenticator request. 358 Otherwise, the Certificate message MUST contain only extensions 359 present in the (D)TLS ClientHello. Unrecognized extensions in the 360 authenticator request MUST be ignored. 362 5.2.2. CertificateVerify 364 This message is used to provide explicit proof that an endpoint 365 possesses the private key corresponding to its identity. The format 366 of this message is taken from TLS 1.3: 368 struct { 369 SignatureScheme algorithm; 370 opaque signature<0..2^16-1>; 371 } CertificateVerify; 373 The algorithm field specifies the signature algorithm used (see 374 Section 4.2.3 of [RFC8446] for the definition of this field). The 375 signature is a digital signature using that algorithm. 377 The signature scheme MUST be a valid signature scheme for TLS 1.3. 378 This excludes all RSASSA-PKCS1-v1_5 algorithms and combinations of 379 ECDSA and hash algorithms that are not supported in TLS 1.3. 381 If an authenticator request is present, the signature algorithm MUST 382 be chosen from one of the signature schemes present in the 383 "signature_algorithms" extensino of the authenticator request. 384 Otherwise, with spontaneous server authentication, the signature 385 algorithm used MUST be chosen from the "signature_algorithms" sent by 386 the peer in the ClientHello of the (D)TLS handshake. If there are no 387 available signature algorithms, then no authenticator should be 388 constructed. 390 The signature is computed using the chosen signature scheme over the 391 concatenation of: 393 * A string that consists of octet 32 (0x20) repeated 64 times 395 * The context string "Exported Authenticator" (which is not NUL- 396 terminated) 398 * A single 0 octet which serves as the separator 400 * The hashed authenticator transcript 402 The authenticator transcript is the hash of the concatenated 403 Handshake Context, authenticator request (if present), and 404 Certificate message: 406 Hash(Handshake Context || authenticator request || Certificate) 408 Where Hash is the authenticator hash defined in section 4.1. If the 409 authenticator request is not present, it is omitted from this 410 construction, i.e., it is zero-length. 412 If the party that generates the exported authenticator does so with a 413 different connection than the party that is validating it, then the 414 Handshake Context will not match, resulting in a CertificateVerify 415 message that does not validate. This includes situations in which 416 the application data is sent via TLS-terminating proxy. Given a 417 failed CertificateVerify validation, it may be helpful for the 418 application to confirm that both peers share the same connection 419 using a value derived from the connection secrets (such as the 420 Handshake Context) before taking a user-visible action. 422 5.2.3. Finished 424 An HMAC [HMAC] over the hashed authenticator transcript, which is the 425 concatenation of the Handshake Context, authenticator request (if 426 present), Certificate, and CertificateVerify. The HMAC is computed 427 using the authenticator hash, using the Finished MAC Key as a key. 429 Finished = HMAC(Finished MAC Key, Hash(Handshake Context || 430 authenticator request || Certificate || CertificateVerify)) 432 5.2.4. Authenticator Creation 434 An endpoint constructs an authenticator by serializing the 435 Certificate, CertificateVerify, and Finished as TLS handshake 436 messages and concatenating the octets: 438 Certificate || CertificateVerify || Finished 440 An authenticator is valid if the CertificateVerify message is 441 correctly constructed given the authenticator request (if used) and 442 the Finished message matches the expected value. When validating an 443 authenticator, constant-time comparisons SHOULD be used for signature 444 and MAC validation. 446 6. Empty Authenticator 448 If, given an authenticator request, the endpoint does not have an 449 appropriate identity or does not want to return one, it constructs an 450 authenticated refusal called an empty authenticator. This is a 451 Finished message sent without a Certificate or CertificateVerify. 452 This message is an HMAC over the hashed authenticator transcript with 453 a Certificate message containing no CertificateEntries and the 454 CertificateVerify message omitted. The HMAC is computed using the 455 authenticator hash, using the Finished MAC Key as a key. This 456 message is encoded as a TLS handshake message, including length and 457 type field. It does not include TLS record layer framing and is not 458 encrypted with a handshake or application-data key. 460 Finished = HMAC(Finished MAC Key, Hash(Handshake Context || 461 authenticator request || Certificate)) 463 7. API considerations 465 The creation and validation of both authenticator requests and 466 authenticators SHOULD be implemented inside the (D)TLS library even 467 if it is possible to implement it at the application layer. (D)TLS 468 implementations supporting the use of exported authenticators SHOULD 469 provide application programming interfaces by which clients and 470 servers may request and verify exported authenticator messages. 472 Notwithstanding the success conditions described below, all APIs MUST 473 fail if: 475 * the connection uses a (D)TLS version of 1.1 or earlier, or 477 * the connection is (D)TLS 1.2 and the extended master secret 478 extension [RFC7627] was not negotiated 480 The following sections describe APIs that are considered necessary to 481 implement exported authenticators. These are informative only. 483 7.1. The "request" API 485 The "request" API takes as input: 487 * certificate_request_context (from 0 to 255 octets) 489 * set of extensions to include (this MUST include 490 signature_algorithms) and the contents thereof 492 It returns an authenticator request, which is a sequence of octets 493 that comprises a CertificateRequest or ClientCertificateRequest 494 message. 496 7.2. The "get context" API 498 The "get context" API takes as input: 500 * authenticator or authenticator request 502 It returns the certificate_request_context. 504 7.3. The "authenticate" API 506 The "authenticate" API takes as input: 508 * a reference to the initial connection 509 * an identity, such as a set of certificate chains and associated 510 extensions (OCSP [RFC6960], SCT [RFC6962], etc.) 512 * a signer (either the private key associated with the identity, or 513 interface to perform private key operations) for each chain 515 * an authenticator request or certificate_request_context (from 0 to 516 255 octets) 518 It returns either the exported authenticator or an empty 519 authenticator as a sequence of octets. It is recommended that the 520 logic for selecting the certificates and extensions to include in the 521 exporter is implemented in the TLS library. Implementing this in the 522 TLS library lets the implementer take advantage of existing extension 523 and certificate selection logic and more easily remember which 524 extensions were sent in the ClientHello. 526 It is also possible to implement this API outside of the TLS library 527 using TLS exporters. This may be preferable in cases where the 528 application does not have access to a TLS library with these APIs or 529 when TLS is handled independently of the application layer protocol. 531 7.4. The "validate" API 533 The "validate" API takes as input: 535 * a reference to the initial connection 537 * an optional authenticator request 539 * an authenticator 541 * a function for validating a certificate chain 543 It returns a status to indicate whether the authenticator is valid or 544 not after applying the function for validating the certificate chain 545 to the chain contained in the authenticator. If validation is 546 successful, it also returns the identity, such as the certificate 547 chain and its extensions. 549 The API should return a failure if the certificate_request_context of 550 the authenticator was used in a different authenticator that was 551 previously validated. Well-formed empty authenticators are returned 552 as invalid. 554 When validating an authenticator, constant-time comparison should be 555 used. 557 8. IANA Considerations 559 8.1. Update of the TLS ExtensionType Registry 561 IANA is requested to update the entry for server_name(0) in the 562 registry for ExtensionType (defined in [RFC8446]) by replacing the 563 value in the "TLS 1.3" column with the value "CH, EE, CR" and adding 564 this document in the "Reference" column. 566 IANA is also requested to add the following note to the registry: 568 The addition of the "CR" to the "TLS 1.3" column for the 569 server_name(0) extension only marks the extension as valid in a 570 ClientCertificateRequest created as part of client-generated 571 authenticator requests. 573 8.2. Update of the TLS Exporter Labels Registry 575 IANA is requested to add the following entries to the registry for 576 Exporter Labels (defined in [RFC5705]): "EXPORTER-client 577 authenticator handshake context", "EXPORTER-server authenticator 578 handshake context", "EXPORTER-client authenticator handshake 579 context", "EXPORTER-client authenticator finished key" and "EXPORTER- 580 server authenticator finished key" with "DTLS-OK" and "Recommended" 581 set to "Y" and this document added to the "Reference" column. 583 8.3. Update of the TLS HandshakeType Registry 585 IANA is requested to add the following entry to the registry for 586 HandshakeType (defined in [RFC8446]): "client_certificate_request" 587 with "DTLS-OK" and "Recommended" set to "Y" and this document added 588 to the "Reference" column with the following in the "Note" column: 589 "Used in TLS versions prior to 1.3." 591 9. Security Considerations 593 The Certificate/Verify/Finished pattern intentionally looks like the 594 TLS 1.3 pattern which now has been analyzed several times. For 595 example, [SIGMAC] presents a relevant framework for analysis, and 596 section 10. of [RFC8446] contains a conprehensive set of references. 598 Authenticators are independent and unidirectional. There is no 599 explicit state change inside TLS when an authenticator is either 600 created or validated. The application in possession of a validated 601 authenticator can rely on any semantics associated with data in the 602 certificate_request_context. 604 * This property makes it difficult to formally prove that a server 605 is jointly authoritative over multiple identities, rather than 606 individually authoritative over each. 608 * There is no indication in (D)TLS about which point in time an 609 authenticator was computed. Any feedback about the time of 610 creation or validation of the authenticator should be tracked as 611 part of the application layer semantics if required. 613 The signatures generated with this API cover the context string 614 "Exported Authenticator" and therefore cannot be transplanted into 615 other protocols. 617 In TLS 1.3 the client can not explicitly learn from the TLS layer 618 whether its Finished message was accepted. Because the application 619 traffic keys are not dependent on the client's final flight, 620 receiving messages from the server does not prove that the server 621 received the client's Finished. To avoid disagreement between the 622 client and server on the authentication status of EAs, servers MUST 623 verify the client Finished before sending an EA or processing a 624 received EA. 626 10. Acknowledgements 628 Comments on this proposal were provided by Martin Thomson. 629 Suggestions for Section 9 were provided by Karthikeyan Bhargavan. 631 11. References 633 11.1. Normative References 635 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 636 Hashing for Message Authentication", RFC 2104, 637 DOI 10.17487/RFC2104, February 1997, 638 . 640 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 641 Requirement Levels", BCP 14, RFC 2119, 642 DOI 10.17487/RFC2119, March 1997, 643 . 645 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 646 (TLS) Protocol Version 1.2", RFC 5246, 647 DOI 10.17487/RFC5246, August 2008, 648 . 650 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 651 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 652 March 2010, . 654 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 655 Extensions: Extension Definitions", RFC 6066, 656 DOI 10.17487/RFC6066, January 2011, 657 . 659 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 660 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 661 January 2012, . 663 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 664 Langley, A., and M. Ray, "Transport Layer Security (TLS) 665 Session Hash and Extended Master Secret Extension", 666 RFC 7627, DOI 10.17487/RFC7627, September 2015, 667 . 669 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 670 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 671 May 2017, . 673 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 674 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 675 . 677 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 678 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 679 . 681 11.2. Informative References 683 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 684 Galperin, S., and C. Adams, "X.509 Internet Public Key 685 Infrastructure Online Certificate Status Protocol - OCSP", 686 RFC 6960, DOI 10.17487/RFC6960, June 2013, 687 . 689 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 690 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 691 . 693 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 694 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 695 Transport Layer Security (TLS) and Datagram Transport 696 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 697 June 2014, . 699 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 700 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 701 DOI 10.17487/RFC7540, May 2015, 702 . 704 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 705 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 706 . 708 [SIGMAC] Krawczyk, H., "A Unilateral-to-Mutual Authentication 709 Compiler for Key Exchange (with Applications to Client 710 Authentication in TLS 1.3)", 2016, 711 . 713 Author's Address 715 Nick Sullivan 716 Cloudflare Inc. 717 Email: nick@cloudflare.com