idnits 2.17.1 draft-ietf-httpbis-http2-secondary-certs-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 14, 2020) is 1444 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) -- Looks like a reference, but probably isn't: '1' on line 1184 -- Looks like a reference, but probably isn't: '2' on line 1186 -- Looks like a reference, but probably isn't: '3' on line 1188 == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-11 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6844 (Obsoleted by RFC 8659) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. Bishop 3 Internet-Draft Akamai 4 Intended status: Standards Track N. Sullivan 5 Expires: November 15, 2020 Cloudflare 6 M. Thomson 7 Mozilla 8 May 14, 2020 10 Secondary Certificate Authentication in HTTP/2 11 draft-ietf-httpbis-http2-secondary-certs-06 13 Abstract 15 A use of TLS Exported Authenticators is described which enables 16 HTTP/2 clients and servers to offer additional certificate-based 17 credentials after the connection is established. The means by which 18 these credentials are used with requests is defined. 20 Note to Readers 22 Discussion of this draft takes place on the HTTP working group 23 mailing list (ietf-http-wg@w3.org), which is archived at 24 https://lists.w3.org/Archives/Public/ietf-http-wg/ [1]. 26 Working Group information can be found at http://httpwg.github.io/ 27 [2]; source code and issues list for this draft can be found at 28 https://github.com/httpwg/http-extensions/labels/secondary-certs [3]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on November 15, 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Server Certificate Authentication . . . . . . . . . . . . 4 66 1.2. Client Certificate Authentication . . . . . . . . . . . . 4 67 1.2.1. HTTP/1.1 Using TLS 1.2 and Earlier . . . . . . . . . 5 68 1.2.2. HTTP/1.1 Using TLS 1.3 . . . . . . . . . . . . . . . 6 69 1.2.3. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 6 70 1.3. HTTP-Layer Certificate Authentication . . . . . . . . . . 7 71 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 72 2. Discovering Additional Certificates at the HTTP/2 Layer . . . 8 73 2.1. Indicating Support for HTTP-Layer Certificate 74 Authentication . . . . . . . . . . . . . . . . . . . . . 9 75 2.2. Making Certificates or Requests Available . . . . . . . . 10 76 2.3. Requiring Certificate Authentication . . . . . . . . . . 11 77 2.3.1. Requiring Additional Server Certificates . . . . . . 11 78 2.3.2. Requiring Additional Client Certificates . . . . . . 12 79 3. Certificates Frames for HTTP/2 . . . . . . . . . . . . . . . 13 80 3.1. The CERTIFICATE_NEEDED Frame . . . . . . . . . . . . . . 13 81 3.2. The USE_CERTIFICATE Frame . . . . . . . . . . . . . . . . 15 82 3.3. The CERTIFICATE_REQUEST Frame . . . . . . . . . . . . . . 16 83 3.3.1. Exported Authenticator Request Characteristics . . . 17 84 3.4. The CERTIFICATE Frame . . . . . . . . . . . . . . . . . . 17 85 3.4.1. Exported Authenticator Characteristics . . . . . . . 19 86 4. Indicating Failures During HTTP-Layer Certificate 87 Authentication . . . . . . . . . . . . . . . . . . . . . . . 19 88 4.1. Misbehavior . . . . . . . . . . . . . . . . . . . . . . . 20 89 4.2. Invalid Certificates . . . . . . . . . . . . . . . . . . 20 90 5. Required Domain Certificate Extension . . . . . . . . . . . . 20 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 92 6.1. Impersonation . . . . . . . . . . . . . . . . . . . . . . 21 93 6.2. Fingerprinting . . . . . . . . . . . . . . . . . . . . . 22 94 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 22 95 6.4. Persistence of Service . . . . . . . . . . . . . . . . . 22 96 6.5. Confusion About State . . . . . . . . . . . . . . . . . . 23 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 98 7.1. HTTP/2 Settings . . . . . . . . . . . . . . . . . . . . . 23 99 7.2. New HTTP/2 Frames . . . . . . . . . . . . . . . . . . . . 24 100 7.3. New HTTP/2 Error Codes . . . . . . . . . . . . . . . . . 24 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 102 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 103 8.2. Informative References . . . . . . . . . . . . . . . . . 25 104 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26 105 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 106 A.1. Since draft-ietf-httpbis-http2-secondary-certs-04: . . . 26 107 A.2. Since draft-ietf-httpbis-http2-secondary-certs-03: . . . 26 108 A.3. Since draft-ietf-httpbis-http2-secondary-certs-02: . . . 26 109 A.4. Since draft-ietf-httpbis-http2-secondary-certs-01: . . . 26 110 A.5. Since draft-ietf-httpbis-http2-secondary-certs-00: . . . 27 111 A.6. Since draft-bishop-httpbis-http2-additional-certs-05: . . 27 112 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 115 1. Introduction 117 HTTP clients need to know that the content they receive on a 118 connection comes from the origin that they intended to retrieve it 119 from. The traditional form of server authentication in HTTP has been 120 in the form of a single X.509 certificate provided during the TLS 121 ([RFC5246], [RFC8446]) handshake. 123 Many existing HTTP [RFC7230] servers also have authentication 124 requirements for the resources they serve. Of the bountiful 125 authentication options available for authenticating HTTP requests, 126 client certificates present a unique challenge for resource-specific 127 authentication requirements because of the interaction with the 128 underlying TLS layer. 130 TLS 1.2 [RFC5246] supports one server and one client certificate on a 131 connection. These certificates may contain multiple identities, but 132 only one certificate may be provided. 134 Many HTTP servers host content from several origins. HTTP/2 permits 135 clients to reuse an existing HTTP connection to a server provided 136 that the secondary origin is also in the certificate provided during 137 the TLS handshake. In many cases, servers choose to maintain 138 separate certificates for different origins but still desire the 139 benefits of a shared HTTP connection. 141 1.1. Server Certificate Authentication 143 Section 9.1.1 of [RFC7540] describes how connections may be used to 144 make requests from multiple origins as long as the server is 145 authoritative for both. A server is considered authoritative for an 146 origin if DNS resolves the origin to the IP address of the server and 147 (for TLS) if the certificate presented by the server contains the 148 origin in the Subject Alternative Names field. 150 [RFC7838] enables a step of abstraction from the DNS resolution. If 151 both hosts have provided an Alternative Service at hostnames which 152 resolve to the IP address of the server, they are considered 153 authoritative just as if DNS resolved the origin itself to that 154 address. However, the server's one TLS certificate is still required 155 to contain the name of each origin in question. 157 [RFC8336] relaxes the requirement to perform the DNS lookup if 158 already connected to a server with an appropriate certificate which 159 claims support for a particular origin. 161 Servers which host many origins often would prefer to have separate 162 certificates for some sets of origins. This may be for ease of 163 certificate management (the ability to separately revoke or renew 164 them), due to different sources of certificates (a CDN acting on 165 behalf of multiple origins), or other factors which might drive this 166 administrative decision. Clients connecting to such origins cannot 167 currently reuse connections, even if both client and server would 168 prefer to do so. 170 Because the TLS SNI extension is exchanged in the clear, clients 171 might also prefer to retrieve certificates inside the encrypted 172 context. When this information is sensitive, it might be 173 advantageous to request a general-purpose certificate or anonymous 174 ciphersuite at the TLS layer, while acquiring the "real" certificate 175 in HTTP after the connection is established. 177 1.2. Client Certificate Authentication 179 For servers that wish to use client certificates to authenticate 180 users, they might request client authentication during or immediately 181 after the TLS handshake. However, if not all users or resources need 182 certificate-based authentication, a request for a certificate has the 183 unfortunate consequence of triggering the client to seek a 184 certificate, possibly requiring user interaction, network traffic, or 185 other time-consuming activities. During this time, the connection is 186 stalled in many implementations. Such a request can result in a poor 187 experience, particularly when sent to a client that does not expect 188 the request. 190 The TLS 1.3 CertificateRequest can be used by servers to give clients 191 hints about which certificate to offer. Servers that rely on 192 certificate-based authentication might request different certificates 193 for different resources. Such a server cannot use contextual 194 information about the resource to construct an appropriate TLS 195 CertificateRequest message during the initial handshake. 197 Consequently, client certificates are requested at connection 198 establishment time only in cases where all clients are expected or 199 required to have a single certificate that is used for all resources. 200 Many other uses for client certificates are reactive, that is, 201 certificates are requested in response to the client making a 202 request. 204 1.2.1. HTTP/1.1 Using TLS 1.2 and Earlier 206 In HTTP/1.1, a server that relies on client authentication for a 207 subset of users or resources does not request a certificate when the 208 connection is established. Instead, it only requests a client 209 certificate when a request is made to a resource that requires a 210 certificate. TLS 1.2 [RFC5246] accommodates this by permitting the 211 server to request a new TLS handshake, in which the server will 212 request the client's certificate. 214 Figure 1 shows the server initiating a TLS-layer renegotiation in 215 response to receiving an HTTP/1.1 request to a protected resource. 217 Client Server 218 -- (HTTP) GET /protected -------------------> *1 219 <---------------------- (TLS) HelloRequest -- *2 220 -- (TLS) ClientHello -----------------------> 221 <------------------ (TLS) ServerHello, ... -- 222 <---------------- (TLS) CertificateRequest -- *3 223 -- (TLS) ..., Certificate ------------------> *4 224 -- (TLS) Finished --------------------------> 225 <-------------------------- (TLS) Finished -- 226 <--------------------------- (HTTP) 200 OK -- *5 228 Figure 1: HTTP/1.1 reactive certificate authentication with TLS 1.2 230 In this example, the server receives a request for a protected 231 resource (at *1 on Figure 1). Upon performing an authorization 232 check, the server determines that the request requires authentication 233 using a client certificate and that no such certificate has been 234 provided. 236 The server initiates TLS renegotiation by sending a TLS HelloRequest 237 (at *2). The client then initiates a TLS handshake. Note that some 238 TLS messages are elided from the figure for the sake of brevity. 240 The critical messages for this example are the server requesting a 241 certificate with a TLS CertificateRequest (*3); this request might 242 use information about the request or resource. The client then 243 provides a certificate and proof of possession of the private key in 244 Certificate and CertificateVerify messages (*4). 246 When the handshake completes, the server performs any authorization 247 checks a second time. With the client certificate available, it then 248 authorizes the request and provides a response (*5). 250 1.2.2. HTTP/1.1 Using TLS 1.3 252 TLS 1.3 [RFC8446] introduces a new client authentication mechanism 253 that allows for clients to authenticate after the handshake has been 254 completed. For the purposes of authenticating an HTTP request, this 255 is functionally equivalent to renegotiation. Figure 2 shows the 256 simpler exchange this enables. 258 Client Server 259 -- (HTTP) GET /protected -------------------> 260 <---------------- (TLS) CertificateRequest -- 261 -- (TLS) Certificate, CertificateVerify, 262 Finished -----------------------> 263 <--------------------------- (HTTP) 200 OK -- 265 Figure 2: HTTP/1.1 reactive certificate authentication with TLS 1.3 267 TLS 1.3 does not support renegotiation, instead supporting direct 268 client authentication. In contrast to the TLS 1.2 example, in TLS 269 1.3, a server can simply request a certificate. 271 1.2.3. HTTP/2 273 An important part of the HTTP/1.1 exchange is that the client is able 274 to easily identify the request that caused the TLS renegotiation. 275 The client is able to assume that the next unanswered request on the 276 connection is responsible. The HTTP stack in the client is then able 277 to direct the certificate request to the application or component 278 that initiated that request. This ensures that the application has 279 the right contextual information for processing the request. 281 In HTTP/2, a client can have multiple outstanding requests. Without 282 some sort of correlation information, a client is unable to identify 283 which request caused the server to request a certificate. 285 Thus, the minimum necessary mechanism to support reactive certificate 286 authentication in HTTP/2 is an identifier that can be use to 287 correlate an HTTP request with a request for a certificate. Since 288 streams are used for individual requests, correlation with a stream 289 is sufficient. 291 [RFC7540] prohibits renegotiation after any application data has been 292 sent. This completely blocks reactive certificate authentication in 293 HTTP/2 using TLS 1.2. If this restriction were relaxed by an 294 extension or update to HTTP/2, such an identifier could be added to 295 TLS 1.2 by means of an extension to TLS. Unfortunately, many TLS 1.2 296 implementations do not permit application data to continue during a 297 renegotiation. This is problematic for a multiplexed protocol like 298 HTTP/2. 300 1.3. HTTP-Layer Certificate Authentication 302 This draft defines HTTP/2 frames to carry the relevant certificate 303 messages, enabling certificate-based authentication of both clients 304 and servers independent of TLS version. This mechanism can be 305 implemented at the HTTP layer without breaking the existing interface 306 between HTTP and applications above it. 308 This could be done in a naive manner by replicating the TLS messages 309 as HTTP/2 frames on each stream. However, this would create needless 310 redundancy between streams and require frequent expensive signing 311 operations. Instead, TLS Exported Authenticators 312 [I-D.ietf-tls-exported-authenticator] are exchanged on stream zero 313 and other frames incorporate them to particular requests by reference 314 as needed. 316 TLS Exported Authenticators are structured messages that can be 317 exported by either party of a TLS connection and validated by the 318 other party. Given an established TLS connection, a request can be 319 constructed which describes the desired certificate and an 320 authenticator message can be constructed proving possession of a 321 certificate and a corresponding private key. Both requests and 322 authenticators can be generated by either the client or the server. 323 Exported Authenticators use the message structures from Sections 324 4.3.2 and 4.4 of [RFC8446], but different parameters. 326 Each Authenticator is computed using a Handshake Context and Finished 327 MAC Key derived from the TLS session. The Handshake Context is 328 identical for both parties of the TLS connection, while the Finished 329 MAC Key is dependent on whether the Authenticator is created by the 330 client or the server. 332 Successfully verified Authenticators result in certificate chains, 333 with verified possession of the corresponding private key, which can 334 be supplied into a collection of available certificates. Likewise, 335 descriptions of desired certificates can be supplied into these 336 collections. 338 Section 2 describes how the feature is employed, defining means to 339 detect support in peers (Section 2.1), make certificates and requests 340 available (Section 2.2), and indicate when streams are blocked 341 waiting on an appropriate certificate (Section 2.3). Section 3 342 defines the required frame types, which parallel the TLS 1.3 message 343 exchange. Finally, Section 4 defines new error types which can be 344 used to notify peers when the exchange has not been successful. 346 1.4. Terminology 348 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 349 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 350 "OPTIONAL" in this document are to be interpreted as described in BCP 351 14 [RFC2119] [RFC8174] when, and only when, they appear in all 352 capitals, as shown here. 354 2. Discovering Additional Certificates at the HTTP/2 Layer 356 A certificate chain with proof of possession of the private key 357 corresponding to the end-entity certificate is sent as a sequence of 358 "CERTIFICATE" frames (see Section 3.4) on stream zero. Once the 359 holder of a certificate has sent the chain and proof, this 360 certificate chain is cached by the recipient and available for future 361 use. Clients can proactively indicate the certificate they intend to 362 use on each request using an unsolicited "USE_CERTIFICATE" frame, if 363 desired. The previously-supplied certificates are available for 364 reference without having to resend them. 366 Otherwise, the server uses a "CERTIFICATE_REQUEST" frame to describe 367 a class of certificates on stream zero, then uses 368 "CERTIFICATE_NEEDED" frames to associate these with individual 369 requests. The client responds with a "USE_CERTIFICATE" frame 370 indicating the certificate which should be used to satisfy the 371 request. 373 Data sent by each peer is correlated by the ID given in each frame. 374 This ID is unrelated to values used by the other peer, even if each 375 uses the same ID in certain cases. "USE_CERTIFICATE" frames indicate 376 whether they are sent proactively or are in response to a 377 "CERTIFICATE_NEEDED" frame. 379 2.1. Indicating Support for HTTP-Layer Certificate Authentication 381 Clients and servers that will accept requests for HTTP-layer 382 certificate authentication indicate this using the HTTP/2 383 "SETTINGS_HTTP_CLIENT_CERT_AUTH" (0xSETTING-TBD1) and 384 "SETTINGS_HTTP_SERVER_CERT_AUTH" (0xSETTING-TBD2) settings. 386 The initial value for both settings is 0, indicating that the peer 387 does not support HTTP-layer certificate authentication. If a peer 388 does support HTTP-layer certificate authentication, one or both of 389 the values is non-zero. "SETTINGS_HTTP_CLIENT_CERT_AUTH" indicates 390 that servers can use certificates for client authentication, while 391 "SETTINGS_HTTP_SERVER_CERT_AUTH" indicates that servers are able to 392 offer additional certificates to demonstrate control over other 393 origin hostnames. 395 In order to ensure that the TLS connection is direct to the server, 396 rather than via a TLS-terminating proxy, each side will separately 397 compute and confirm the value of these settings. The setting values 398 are derived from a TLS exporter (see Section 7.5 of [RFC8446] and 399 [RFC5705] for more details on exporters). Clients MUST NOT use an 400 early exporter during their 0-RTT flight, but MUST send an updated 401 SETTINGS frame using a regular exporter after the TLS handshake 402 completes. 404 The exporter is constructed with the following input: 406 o Label: 408 * "EXPORTER HTTP CERTIFICATE client" for clients 410 * "EXPORTER HTTP CERTIFICATE server" for servers 412 o Context: Empty 414 o Length: Eight bytes 416 The value of the exporter is split into two four-byte values. The 417 first four bytes are used for the "SETTINGS_HTTP_CLIENT_CERT_AUTH" 418 value, while the following four bytes are used for the 419 "SETTINGS_HTTP_SERVER_CERT_AUTH" value. 421 Each is converted to a setting value as: 423 Exporter fragment | 0x80000000 425 That is, the most significant bit will always be set, regardless of 426 the value of the exporter. Each endpoint will compute the expected 427 values from their peer. If the setting is not received, or if the 428 value received is not the expected value, the frames defined in this 429 document SHOULD NOT be sent in the indicated direction. 431 2.2. Making Certificates or Requests Available 433 When both peers have advertised support for HTTP-layer certificates 434 in a given direction as in Section 2.1, the indicated endpoint can 435 supply additional certificates into the connection at any time. That 436 is, if both endpoints have sent "SETTINGS_HTTP_SERVER_CERT_AUTH" and 437 validated the value received from the peer, the server may send 438 certificates. If both endpoints have sent 439 "SETTINGS_HTTP_CLIENT_CERT_AUTH" and validated the value received 440 from the peer, the client may send certificates. 442 Implementations which predict a certificate will be required could 443 supply the certificate before being asked. These certificates are 444 available for reference by future "USE_CERTIFICATE" frames. 446 Certificates supplied by servers can be considered by clients without 447 further action by the server. A server SHOULD NOT send certificates 448 which do not cover origins which it is prepared to service on the 449 current connection, but MAY use the ORIGIN frame [RFC8336] to 450 indicate that not all covered origins will be served. 452 Certificates supplied by clients MUST NOT be considered by servers 453 when processing a request unless the client explicitly authorizes 454 their use. Clients MAY send "USE_CERTIFICATE" frame with the 455 "UNSOLICITED" flag set to indicate that an available certificate 456 should be considered on a new request. 458 Client Server 459 <------------------ (stream 0) CERTIFICATE -- 460 ... 461 -- (stream N) GET /from-new-origin ---------> 462 <----------------------- (stream N) 200 OK -- 464 Figure 3: Proactive server authentication 466 Client Server 467 -- (stream 0) CERTIFICATE ------------------> 468 -- (stream 0) USE_CERTIFICATE (S=1) --------> 469 -- (stream 0) USE_CERTIFICATE (S=3) --------> 470 -- (streams 1,3) GET /protected ------------> 471 <-------------------- (streams 1,3) 200 OK -- 473 Figure 4: Proactive client authentication 475 Likewise, a party can supply a "CERTIFICATE_REQUEST" that outlines 476 parameters of a certificate they might request in the future. Upon 477 receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD provide a 478 corresponding certificate in anticipation of a request shortly being 479 blocked. Clients MAY wait for a "CERTIFICATE_NEEDED" frame to assist 480 in associating the certificate request with a particular HTTP 481 transaction. 483 2.3. Requiring Certificate Authentication 485 2.3.1. Requiring Additional Server Certificates 487 As defined in [RFC7540], when a client finds that an https:// origin 488 (or Alternative Service [RFC7838]) to which it needs to make a 489 request has the same IP address as a server to which it is already 490 connected, it MAY check whether the TLS certificate provided contains 491 the new origin as well, and if so, reuse the connection. 493 If the TLS certificate does not contain the new origin, but the 494 server has claimed support for that origin (with an ORIGIN frame, see 495 [RFC8336]) and advertised support for HTTP-layer server certificates 496 (see Section 2.1), the client MAY send a "CERTIFICATE_REQUEST" frame 497 describing the desired origin. The client then sends a 498 "CERTIFICATE_NEEDED" frame for stream zero referencing the request, 499 indicating that the connection cannot be used for that origin until 500 the certificate is provided. 502 If the server does not have the desired certificate, it MUST send an 503 Empty Authenticator, as described in Section 5 of 504 [I-D.ietf-tls-exported-authenticator], in a "CERTIFICATE" frame in 505 response to the request, followed by a "USE_CERTIFICATE" frame for 506 stream zero which references the Empty Authenticator. 508 If a server has not advertised support for HTTP-layer certificates, 509 fails to provide a requested certificate, or provides a certificate 510 which is unacceptable to the client, the client MUST NOT send any 511 requests for resources in that origin on the current connection. The 512 client MAY open a new connection in an effort to reach an 513 authoritative server. 515 Client Server 516 <----------------------- (stream 0) ORIGIN -- 517 -- (stream 0) CERTIFICATE_REQUEST ----------> 518 -- (stream 0) CERTIFICATE_NEEDED (S=0) -----> 519 <------------------ (stream 0) CERTIFICATE -- 520 <-------- (stream 0) USE_CERTIFICATE (S=0) -- 521 -- (stream N) GET /from-new-origin ---------> 522 <----------------------- (stream N) 200 OK -- 524 Figure 5: Client-requested certificate 526 If a client receives a "PUSH_PROMISE" referencing an origin for which 527 it has not yet received the server's certificate, this is a stream 528 error on the push stream; see section 8.2 of [RFC7540]. To avoid 529 this, servers MUST supply the associated certificates before pushing 530 resources from a different origin. 532 2.3.2. Requiring Additional Client Certificates 534 Likewise, the server sends a "CERTIFICATE_NEEDED" frame for each 535 stream where certificate authentication is required. The client 536 answers with a "USE_CERTIFICATE" frame indicating the certificate to 537 use on that stream. If the request parameters or the responding 538 certificate are not already available, they will need to be sent as 539 described in Section 2.2 as part of this exchange. 541 Client Server 542 <---------- (stream 0) CERTIFICATE_REQUEST -- 543 ... 544 -- (stream N) GET /protected ---------------> 545 <----- (stream 0) CERTIFICATE_NEEDED (S=N) -- 546 -- (stream 0) CERTIFICATE ------------------> 547 -- (stream 0) USE_CERTIFICATE (S=N) --------> 548 <----------------------- (stream N) 200 OK -- 550 Figure 6: Reactive certificate authentication 552 If the client does not have the desired certificate, it instead sends 553 an Empty Authenticator, as described in Section 5 of 554 [I-D.ietf-tls-exported-authenticator], in a "CERTIFICATE" frame in 555 response to the request, followed by a "USE_CERTIFICATE" frame which 556 references the Empty Authenticator. 558 If the client has not advertised support for HTTP-layer certificates, 559 fails to provide a requested certificate, or provides a certificate 560 the server is unable to verify, the server processes the request 561 based solely on the certificate provided during the TLS handshake, if 562 any. This might result in an error response via HTTP, such as a 563 status code 403 (Not Authorized). 565 3. Certificates Frames for HTTP/2 567 The "CERTIFICATE_REQUEST" and "CERTIFICATE_NEEDED" frames are 568 correlated by their "Request-ID" field. Subsequent 569 "CERTIFICATE_NEEDED" frames with the same "Request-ID" value MAY be 570 sent for other streams where the sender is expecting a certificate 571 with the same parameters. 573 The "CERTIFICATE", and "USE_CERTIFICATE" frames are correlated by 574 their "Cert-ID" field. Subsequent "USE_CERTIFICATE" frames with the 575 same "Cert-ID" MAY be sent in response to other "CERTIFICATE_NEEDED" 576 frames and refer to the same certificate. 578 "CERTIFICATE_NEEDED" and "USE_CERTIFICATE" frames are correlated by 579 the Stream ID they reference. Unsolicited "USE_CERTIFICATE" frames 580 are not responses to "CERTIFICATE_NEEDED" frames; otherwise, each 581 "USE_CERTIFICATE" frame for a stream is considered to respond to a 582 "CERTIFICATE_NEEDED" frame for the same stream in sequence. 584 +---------+ +---------+ 585 | REQUEST | | CERT | 586 +---------+ +---------+ 587 | | 588 | Request-ID | Cert-ID 589 | | 590 v v 591 +---------+ Stream ID +---------+ 592 | NEEDED |---------->| USE | 593 +---------+ +---------+ 595 Figure 7: Frame correlation 597 "Request-ID" and "Cert-ID" are independent and sender-local. The use 598 of the same value by the other peer or in the other context does not 599 imply any correlation between these frames. These values MUST be 600 unique per sender for each space over the lifetime of the connection. 602 3.1. The CERTIFICATE_NEEDED Frame 604 The "CERTIFICATE_NEEDED" frame (0xFRAME-TBD1) is sent on stream zero 605 to indicate that the HTTP request on the indicated stream is blocked 606 pending certificate authentication. The frame includes stream ID and 607 a request identifier which can be used to correlate the stream with a 608 previous "CERTIFICATE_REQUEST" frame sent on stream zero. The 609 "CERTIFICATE_REQUEST" describes the certificate the sender requires 610 to make progress on the stream in question. 612 0 1 2 3 613 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 614 +---------------------------------------------------------------+ 615 |R| Stream ID (31) | 616 +-------------------------------+-------------------------------+ 617 | Request-ID (16) | 618 +-------------------------------+ 620 Figure 8: CERTIFICATE_NEEDED frame payload 622 The "CERTIFICATE_NEEDED" frame contains 6 octets. The first four 623 octets indicate the Stream ID of the affected stream. The following 624 two octets are the authentication request identifier, "Request-ID". 625 A peer that receives a "CERTIFICATE_NEEDED" of any other length MUST 626 treat this as a stream error of type "PROTOCOL_ERROR". Frames with 627 identical request identifiers refer to the same 628 "CERTIFICATE_REQUEST". 630 A server MAY send multiple "CERTIFICATE_NEEDED" frames for the same 631 stream. If a server requires that a client provide multiple 632 certificates before authorizing a single request, each required 633 certificate MUST be indicated with a separate "CERTIFICATE_NEEDED" 634 frame, each of which MUST have a different request identifier 635 (referencing different "CERTIFICATE_REQUEST" frames describing each 636 required certificate). To reduce the risk of client confusion, 637 servers SHOULD NOT have multiple outstanding "CERTIFICATE_NEEDED" 638 frames for the same stream at any given time. 640 Clients MUST only send multiple "CERTIFICATE_NEEDED" frames for 641 stream zero. Multiple "CERTIFICATE_NEEDED" frames on any other 642 stream MUST be considered a stream error of type "PROTOCOL_ERROR". 644 The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a client which has 645 not advertised the "SETTINGS_HTTP_CLIENT_CERT_AUTH", or to a server 646 which has not advertised the "SETTINGS_HTTP_SERVER_CERT_AUTH" 647 setting. An endpoint which receives a "CERTIFICATE_NEEDED" frame but 648 did not advertise support MAY treat this as a connection error of 649 type "CERTIFICATE_WITHOUT_CONSENT". 651 The "CERTIFICATE_NEEDED" frame MUST NOT reference a stream in the 652 "half-closed (local)" or "closed" states [RFC7540]. A client that 653 receives a "CERTIFICATE_NEEDED" frame for a stream which is not in a 654 valid state SHOULD treat this as a stream error of type 655 "PROTOCOL_ERROR". 657 3.2. The USE_CERTIFICATE Frame 659 The "USE_CERTIFICATE" frame (0xFRAME-TBD4) is sent on stream zero to 660 indicate which certificate is being used on a particular request 661 stream. 663 The "USE_CERTIFICATE" frame defines a single flag: 665 UNSOLICITED (0x01): Indicates that no "CERTIFICATE_NEEDED" frame has 666 yet been received for this stream. 668 The payload of the "USE_CERTIFICATE" frame is as follows: 670 0 1 2 3 671 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 672 +---------------------------------------------------------------+ 673 |R| Stream ID (31) | 674 +-------------------------------+-------------------------------+ 675 | [Cert-ID (16)] | 676 +-------------------------------+ 678 Figure 9: USE_CERTIFICATE frame payload 680 The first four octets indicate the Stream ID of the affected stream. 681 The following two octets, if present, contain the two-octet "Cert-ID" 682 of the certificate the sender wishes to use. This MUST be the ID of 683 a certificate for which proof of possession has been presented in a 684 "CERTIFICATE" frame. Recipients of a "USE_CERTIFICATE" frame of any 685 other length MUST treat this as a stream error of type 686 "PROTOCOL_ERROR". Frames with identical certificate identifiers 687 refer to the same certificate chain. 689 A "USE_CERTIFICATE" frame which omits the Cert-ID refers to the 690 certificate provided at the TLS layer, if any. If no certificate was 691 provided at the TLS layer, the stream should be processed with no 692 authentication, likely returning an authentication-related error at 693 the HTTP level (e.g. 403) for servers or routing the request to a new 694 connection for clients. 696 The "UNSOLICITED" flag MAY be set by clients on the first 697 "USE_CERTIFICATE" frame referring to a given stream. This permits a 698 client to proactively indicate which certificate should be used when 699 processing a new request. When such an unsolicited indication refers 700 to a request that has not yet been received, servers SHOULD cache the 701 indication briefly in anticipation of the request. 703 Receipt of more than one unsolicited "USE_CERTIFICATE" frame or an 704 unsolicited "USE_CERTIFICATE" frame which is not the first in 705 reference to a given stream MUST be treated as a stream error of type 706 "CERTIFICATE_OVERUSED". 708 Each "USE_CERTIFICATE" frame which is not marked as unsolicited is 709 considered to respond in order to the "CERTIFICATE_NEEDED" frames for 710 the same stream. If a "USE_CERTIFICATE" frame is received for which 711 a "CERTIFICATE_NEEDED" frame has not been sent, this MUST be treated 712 as a stream error of type "CERTIFICATE_OVERUSED". 714 Receipt of a "USE_CERTIFICATE" frame with an unknown "Cert-ID" MUST 715 result in a stream error of type "PROTOCOL_ERROR". 717 The referenced certificate chain needs to conform to the requirements 718 expressed in the "CERTIFICATE_REQUEST" to the best of the sender's 719 ability, or the recipient is likely to reject it as unsuitable 720 despite properly validating the authenticator. If the recipient 721 considers the certificate unsuitable, it MAY at its discretion either 722 return an error at the HTTP semantic layer, or respond with a stream 723 error [RFC7540] on any stream where the certificate is used. 724 Section 4 defines certificate-related error codes which might be 725 applicable. 727 3.3. The CERTIFICATE_REQUEST Frame 729 The "CERTIFICATE_REQUEST" frame (id=0xFRAME-TBD2) provides an 730 exported authenticator request message from the TLS layer that 731 specifies a desired certificate. This describes the certificate the 732 sender wishes to have presented. 734 The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a client which 735 has not advertised the "SETTINGS_HTTP_CLIENT_CERT_AUTH", or to a 736 server which has not advertised the "SETTINGS_HTTP_SERVER_CERT_AUTH" 737 setting. 739 The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero. A 740 "CERTIFICATE_REQUEST" frame received on any other stream MUST be 741 rejected with a stream error of type "PROTOCOL_ERROR". 743 0 1 2 3 744 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 745 +-------------------------------+-------------------------------+ 746 | Request-ID (16) | Request (?) ... 747 +---------------------------------------------------------------+ 749 Figure 10: CERTIFICATE_REQUEST frame payload 751 The frame contains the following fields: 753 Request-ID: "Request-ID" is a 16-bit opaque identifier used to 754 correlate subsequent certificate-related frames with this request. 755 The identifier MUST be unique in the session for the sender. 757 Request: An exported authenticator request, generated using the 758 "request" API described in [I-D.ietf-tls-exported-authenticator]. 759 See Section 3.4.1 for more details on the input to this API. 761 3.3.1. Exported Authenticator Request Characteristics 763 The Exported Authenticator "request" API defined in 764 [I-D.ietf-tls-exported-authenticator] takes as input a set of desired 765 certificate characteristics and a "certificate_request_context", 766 which needs to be unpredictable. When generating exported 767 authenticators for use with this extension, the 768 "certificate_request_context" MUST contain both the two-octet 769 Request-ID as well as at least 96 bits of additional entropy. 771 Upon receipt of a "CERTIFICATE_REQUEST" frame, the recipient MUST 772 verify that the first two octets of the authenticator's 773 "certificate_request_context" matches the Request-ID presented in the 774 frame. 776 The TLS library on the authenticating peer will provide mechanisms to 777 select an appropriate certificate to respond to the transported 778 request. TLS libraries on servers MUST be able to recognize the 779 "server_name" extension ([RFC6066]) at a minimum. Clients MUST 780 always specify the desired origin using this extension, though other 781 extensions MAY also be included. 783 3.4. The CERTIFICATE Frame 785 The "CERTIFICATE" frame (id=0xFRAME-TBD3) provides an exported 786 authenticator message from the TLS layer that provides a chain of 787 certificates, associated extensions and proves possession of the 788 private key corresponding to the end-entity certificate. 790 The "CERTIFICATE" frame defines two flags: 792 TO_BE_CONTINUED (0x01): Indicates that the exported authenticator 793 spans more than one frame. 795 UNSOLICITED (0x02): Indicates that the exported authenticator does 796 not contain a Request-ID. 798 0 1 2 3 799 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 800 +-------------------------------+-------------------------------+ 801 | Cert-ID (16) | Request-ID (16) | 802 +-------------------------------+-------------------------------+ 803 | Authenticator Fragment (*) ... 804 +---------------------------------------------------------------+ 806 Figure 11: CERTIFICATE frame payload 808 The frame contains the following fields: 810 Cert-ID: "Cert-ID" is a 16-bit opaque identifier used to correlate 811 other certificate- related frames with this exported authenticator 812 fragment. 814 Request-ID: "Request-ID" is an optional 16-bit opaque identifier 815 used to correlate this exported authenticator with the request 816 which triggered it, if any. This field is present only if the 817 "UNSOLICITED" flag is not set. 819 Authenticator Fragment: A portion of the opaque data returned from 820 the TLS connection exported authenticator "authenticate" API. See 821 Section 3.4.1 for more details on the input to this API. 823 An exported authenticator is transported in zero or more 824 "CERTIFICATE" frames with the "TO_BE_CONTINUED" flag set, followed by 825 one "CERTIFICATE" frame with the "TO_BE_CONTINUED" flag unset. Each 826 of these frames contains the same "Cert-ID" field, permitting them to 827 be associated with each other. Receipt of any "CERTIFICATE" frame 828 with the same "Cert-ID" following the receipt of a "CERTIFICATE" 829 frame with "TO_BE_CONTINUED" unset MUST be treated as a connection 830 error of type "PROTOCOL_ERROR". 832 If the "UNSOLICITED" flag is not set, the "CERTIFICATE" frame also 833 contains a Request-ID indicating the certificate request which caused 834 this exported authenticator to be generated. The value of this flag 835 and the contents of the Request-ID field MUST NOT differ between 836 frames with the same Cert-ID. 838 Upon receiving a complete series of "CERTIFICATE" frames, the 839 receiver may validate the Exported Authenticator value by using the 840 exported authenticator API. This returns either an error indicating 841 that the message was invalid, or the certificate chain and extensions 842 used to create the message. 844 The "CERTIFICATE" frame MUST be sent on stream zero. A "CERTIFICATE" 845 frame received on any other stream MUST be rejected with a stream 846 error of type "PROTOCOL_ERROR". 848 3.4.1. Exported Authenticator Characteristics 850 The Exported Authenticator API defined in 851 [I-D.ietf-tls-exported-authenticator] takes as input a request, a set 852 of certificates, and supporting information about the certificate 853 (OCSP, SCT, etc.). The result is an opaque token which is used when 854 generating the "CERTIFICATE" frame. 856 Upon receipt of a "CERTIFICATE" frame, an endpoint MUST perform the 857 following steps to validate the token it contains: 859 o Verify that either the "UNSOLICITED" flag is set (clients only) or 860 that the Request-ID field contains the Request-ID of a previously- 861 sent "CERTIFICATE_REQUEST" frame. 863 o Using the "get context" API, retrieve the 864 "certificate_request_context" used to generate the authenticator, 865 if any. Verify that the "certificate_request_context" begins with 866 the supplied Request-ID, if any. 868 o Use the "validate" API to confirm the validity of the 869 authenticator with regard to the generated request (if any). 871 If the authenticator cannot be validated, this SHOULD be treated as a 872 connection error of type "CERTIFICATE_UNREADABLE". 874 Once the authenticator is accepted, the endpoint can perform any 875 other checks for the acceptability of the certificate itself. 876 Clients MUST NOT accept any end-entity certificate from an exported 877 authenticator which does not contain the Required Domain extension; 878 see Section 5 and Section 6.1. 880 4. Indicating Failures During HTTP-Layer Certificate Authentication 882 Because this draft permits certificates to be exchanged at the HTTP 883 framing layer instead of the TLS layer, several certificate-related 884 errors which are defined at the TLS layer might now occur at the HTTP 885 framing layer. 887 There are two classes of errors which might be encountered, and they 888 are handled differently. 890 4.1. Misbehavior 892 This category of errors could indicate a peer failing to follow 893 restrictions in this document, or might indicate that the connection 894 is not fully secure. These errors are fatal to stream or connection, 895 as appropriate. 897 CERTIFICATE_OVERUSED (0xERROR-TBD1): More certificates were used on 898 a request than were requested 900 CERTIFICATE_WITHOUT_CONSENT (0xERROR-TBD2): A CERTIFICATE_NEEDED 901 frame was received by a peer which did not indicate support for 902 this extension. 904 CERTIFICATE_UNREADABLE (0xERROR-TBD3): An exported authenticator 905 could not be validated. 907 4.2. Invalid Certificates 909 Unacceptable certificates (expired, revoked, or insufficient to 910 satisfy the request) are not treated as stream or connection errors. 911 This is typically not an indication of a protocol failure. Servers 912 SHOULD process requests with the indicated certificate, likely 913 resulting in a "4XX"-series status code in the response. Clients 914 SHOULD establish a new connection in an attempt to reach an 915 authoritative server. 917 5. Required Domain Certificate Extension 919 The Required Domain extension allows certificates to limit their use 920 with Secondary Certificate Authentication. A client MUST verify that 921 the server has proven ownership of the indicated identity before 922 accepting the limited certificate over Secondary Certificate 923 Authentication. 925 The identity in this extension is a restriction asserted by the 926 requester of the certificate and is not verified by the CA. 927 Conforming CAs SHOULD mark the requiredDomain extension as non- 928 critical. Conforming CAs MUST require the presence of a CAA record 929 [RFC6844] prior to issuing a certificate with this extension. 930 Because a Required Domain value of "*" has a much higher risk of 931 reuse if compromised, conforming Certificate Authorities are 932 encouraged to require more extensive verification prior to issuing 933 such a certificate. 935 The required domain is represented as a GeneralName, as specified in 936 Section 4.2.1.6 of [RFC5280]. Unlike the subject field, conforming 937 CAs MUST NOT issue certificates with a requiredDomain extension 938 containing empty GeneralName fields. Clients that encounter such a 939 certificate when processing a certification path MUST consider the 940 certificate invalid. 942 The wildcard character "_" MAY be used to represent that any 943 previously authenticated identity is acceptable. This character MUST 944 be the entirety of the name if used and MUST have a type of 945 "dNSName". (That is, "_" is acceptable, but "_.com" and 946 "w_.example.com" are not). 948 id-ce-requiredDomain OBJECT IDENTIFIER ::= { id-ce TBD1 } 950 RequiredDomain ::= GeneralName 952 6. Security Considerations 954 This mechanism defines an alternate way to obtain server and client 955 certificates other than in the initial TLS handshake. While the 956 signature of exported authenticator values is expected to be equally 957 secure, it is important to recognize that a vulnerability in this 958 code path is at least equal to a vulnerability in the TLS handshake. 960 6.1. Impersonation 962 This mechanism could increase the impact of a key compromise. Rather 963 than needing to subvert DNS or IP routing in order to use a 964 compromised certificate, a malicious server now only needs a client 965 to connect to _some_ HTTPS site under its control in order to present 966 the compromised certificate. Clients SHOULD consult DNS for 967 hostnames presented in secondary certificates if they would have done 968 so for the same hostname if it were present in the primary 969 certificate. 971 As recommended in [RFC8336], clients opting not to consult DNS ought 972 to employ some alternative means to increase confidence that the 973 certificate is legitimate. 975 One such means is the Required Domain certificate extension defined 976 in {extension}. Clients MUST require that server certificates 977 presented via this mechanism contain the Required Domain extension 978 and require that a certificate previously accepted on the connection 979 (including the certificate presented in TLS) lists the Required 980 Domain in the Subject field or the Subject Alternative Name 981 extension. 983 As noted in the Security Considerations of 984 [I-D.ietf-tls-exported-authenticator], it is difficult to formally 985 prove that an endpoint is jointly authoritative over multiple 986 certificates, rather than individually authoritative on each 987 certificate. As a result, clients MUST NOT assume that because one 988 origin was previously colocated with another, those origins will be 989 reachable via the same endpoints in the future. Clients MUST NOT 990 consider previous secondary certificates to be validated after TLS 991 session resumption. However, clients MAY proactively query for 992 previously-presented secondary certificates. 994 6.2. Fingerprinting 996 This draft defines a mechanism which could be used to probe servers 997 for origins they support, but opens no new attack versus making 998 repeat TLS connections with different SNI values. Servers SHOULD 999 impose similar denial-of-service mitigations (e.g. request rate 1000 limits) to "CERTIFICATE_REQUEST" frames as to new TLS connections. 1002 While the extensions in the "CERTIFICATE_REQUEST" frame permit the 1003 sender to enumerate the acceptable Certificate Authorities for the 1004 requested certificate, it might not be prudent (either for security 1005 or data consumption) to include the full list of trusted Certificate 1006 Authorities in every request. Senders, particularly clients, SHOULD 1007 send only the extensions that narrowly specify which certificates 1008 would be acceptable. 1010 Servers can also learn information about clients using this 1011 mechanism. The hostnames a user agent finds interesting and 1012 retrieves certificates for might indicate origins the user has 1013 previously accessed. 1015 6.3. Denial of Service 1017 Failure to provide a certificate for a stream after receiving 1018 "CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to 1019 standard timeouts used to guard against unresponsive peers. 1021 Validating a multitude of signatures can be computationally 1022 expensive, while generating an invalid signature is computationally 1023 cheap. Implementations will require checks for attacks from this 1024 direction. Invalid exported authenticators SHOULD be treated as a 1025 session error, to avoid further attacks from the peer, though an 1026 implementation MAY instead disable HTTP-layer certificates for the 1027 current connection instead. 1029 6.4. Persistence of Service 1031 CNAME records in the DNS are frequently used to delegate authority 1032 for an origin to a third-party provider. This delegation can be 1033 changed without notice, even to the third-party provider, simply by 1034 modifying the CNAME record in question. 1036 After the owner of the domain has redirected traffic elsewhere by 1037 changing the CNAME, new connections will not arrive for that origin, 1038 but connections which are properly directed to this provider for 1039 other origins would continue to claim control of this origin (via 1040 ORIGIN frame and Secondary Certificates). This is proper behavior 1041 based on the third-party provider's configuration, but would likely 1042 not be what is intended by the owner of the origin. 1044 This is not an issue which can be mitigated by the protocol, but 1045 something about which third-party providers SHOULD educate their 1046 customers before using the features described in this document. 1048 6.5. Confusion About State 1050 Implementations need to be aware of the potential for confusion about 1051 the state of a connection. The presence or absence of a validated 1052 certificate can change during the processing of a request, 1053 potentially multiple times, as "USE_CERTIFICATE" frames are received. 1054 A server that uses certificate authentication needs to be prepared to 1055 reevaluate the authorization state of a request as the set of 1056 certificates changes. 1058 7. IANA Considerations 1060 This draft adds entries in three registries. 1062 The feature negotiation settings is registered in Section 7.1. Four 1063 frame types are registered in Section 7.2. Six error codes are 1064 registered in Section 7.3. 1066 7.1. HTTP/2 Settings 1068 The SETTINGS_HTTP_CLIENT_CERT_AUTH and SETTINGS_HTTP_SERVER_CERT_AUTH 1069 settings are registered in the "HTTP/2 Settings" registry established 1070 in [RFC7540]. 1072 +-----------------------+----------------+----------+---------------+ 1073 | Name | Code | Initial | Specification | 1074 | | | Value | | 1075 +-----------------------+----------------+----------+---------------+ 1076 | HTTP_CLIENT_CERT_AUTH | 0xSETTING-TBD1 | 0 | Section 2.1 | 1077 | | | | | 1078 | HTTP_SERVER_CERT_AUTH | 0xSETTING-TBD2 | 0 | Section 2.1 | 1079 +-----------------------+----------------+----------+---------------+ 1081 7.2. New HTTP/2 Frames 1083 Four new frame types are registered in the "HTTP/2 Frame Types" 1084 registry established in [RFC7540]. The entries in the following 1085 table are registered by this document. 1087 +---------------------+--------------+---------------+ 1088 | Frame Type | Code | Specification | 1089 +---------------------+--------------+---------------+ 1090 | CERTIFICATE_NEEDED | 0xFRAME-TBD1 | Section 3.1 | 1091 | | | | 1092 | CERTIFICATE_REQUEST | 0xFRAME-TBD2 | Section 3.3 | 1093 | | | | 1094 | CERTIFICATE | 0xFRAME-TBD3 | Section 3.4 | 1095 | | | | 1096 | USE_CERTIFICATE | 0xFRAME-TBD4 | Section 3.2 | 1097 +---------------------+--------------+---------------+ 1099 7.3. New HTTP/2 Error Codes 1101 Six new error codes are registered in the "HTTP/2 Error Code" 1102 registry established in [RFC7540]. The entries in the following 1103 table are registered by this document. 1105 +-----------------------------+--------------+---------------+ 1106 | Name | Code | Specification | 1107 +-----------------------------+--------------+---------------+ 1108 | CERTIFICATE_OVERUSED | 0xERROR-TBD1 | Section 4 | 1109 | | | | 1110 | CERTIFICATE_WITHOUT_CONSENT | 0xERROR-TBD2 | Section 4 | 1111 | | | | 1112 | CERTIFICATE_UNREADABLE | 0xERROR-TBD3 | Section 4 | 1113 +-----------------------------+--------------+---------------+ 1115 8. References 1117 8.1. Normative References 1119 [I-D.ietf-tls-exported-authenticator] 1120 Sullivan, N., "Exported Authenticators in TLS", draft- 1121 ietf-tls-exported-authenticator-11 (work in progress), 1122 December 2019. 1124 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1125 Requirement Levels", BCP 14, RFC 2119, 1126 DOI 10.17487/RFC2119, March 1997, 1127 . 1129 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1130 (TLS) Protocol Version 1.2", RFC 5246, 1131 DOI 10.17487/RFC5246, August 2008, 1132 . 1134 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1135 Housley, R., and W. Polk, "Internet X.509 Public Key 1136 Infrastructure Certificate and Certificate Revocation List 1137 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1138 . 1140 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1141 Extensions: Extension Definitions", RFC 6066, 1142 DOI 10.17487/RFC6066, January 2011, 1143 . 1145 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 1146 Authority Authorization (CAA) Resource Record", RFC 6844, 1147 DOI 10.17487/RFC6844, January 2013, 1148 . 1150 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1151 Protocol (HTTP/1.1): Message Syntax and Routing", 1152 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1153 . 1155 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1156 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1157 DOI 10.17487/RFC7540, May 2015, 1158 . 1160 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1161 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1162 May 2017, . 1164 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1165 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1166 . 1168 8.2. Informative References 1170 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1171 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1172 March 2010, . 1174 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1175 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1176 April 2016, . 1178 [RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", 1179 RFC 8336, DOI 10.17487/RFC8336, March 2018, 1180 . 1182 8.3. URIs 1184 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 1186 [2] http://httpwg.github.io/ 1188 [3] https://github.com/httpwg/http-extensions/labels/secondary-certs 1190 Appendix A. Change Log 1192 *RFC Editor's Note:* Please remove this section prior to 1193 publication of a final version of this document. 1195 A.1. Since draft-ietf-httpbis-http2-secondary-certs-04: 1197 Editorial updates only. 1199 A.2. Since draft-ietf-httpbis-http2-secondary-certs-03: 1201 o "CERTIFICATE_REQUEST" frames contain the Request-ID, which MUST be 1202 checked against the "certificate_request_context" of the Exported 1203 Authenticator Request 1205 o "CERTIFICATE" frames contain the Request-ID to which they respond, 1206 unless the UNSOLICITED flag is set 1208 o The Required Domain extension is defined for certificates, which 1209 must be present for certificates presented by servers 1211 A.3. Since draft-ietf-httpbis-http2-secondary-certs-02: 1213 Editorial updates only. 1215 A.4. Since draft-ietf-httpbis-http2-secondary-certs-01: 1217 o Clients can send "CERTIFICATE_NEEDED" for stream 0 rather than 1218 speculatively reserving a stream for an origin. 1220 o Use SETTINGS to disable when a TLS-terminating proxy is present 1221 (#617,#651) 1223 A.5. Since draft-ietf-httpbis-http2-secondary-certs-00: 1225 o All frames sent on stream zero; replaced "AUTOMATIC_USE" on 1226 "CERTIFICATE" with "UNSOLICITED" on "USE_CERTIFICATE". (#482,#566) 1228 o Use Exported Requests from the TLS Exported Authenticators draft; 1229 eliminate facilities for expressing certificate requirements in 1230 "CERTIFICATE_REQUEST" frame. (#481) 1232 A.6. Since draft-bishop-httpbis-http2-additional-certs-05: 1234 o Adopted as draft-ietf-httpbis-http2-secondary-certs 1236 Acknowledgements 1238 Eric Rescorla pointed out several failings in an earlier revision. 1239 Andrei Popov contributed to the TLS considerations. 1241 A substantial portion of Mike's work on this draft was supported by 1242 Microsoft during his employment there. 1244 Authors' Addresses 1246 Mike Bishop 1247 Akamai 1249 Email: mbishop@evequefou.be 1251 Nick Sullivan 1252 Cloudflare 1254 Email: nick@cloudflare.com 1256 Martin Thomson 1257 Mozilla 1259 Email: martin.thomson@gmail.com