idnits 2.17.1 draft-ietf-httpbis-http2-secondary-certs-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The 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 (October 31, 2019) is 1632 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 1140 -- Looks like a reference, but probably isn't: '2' on line 1142 -- Looks like a reference, but probably isn't: '3' on line 1144 == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-09 ** 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: May 3, 2020 Cloudflare 6 M. Thomson 7 Mozilla 8 October 31, 2019 10 Secondary Certificate Authentication in HTTP/2 11 draft-ietf-httpbis-http2-secondary-certs-05 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 May 3, 2020. 47 Copyright Notice 49 Copyright (c) 2019 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 . . . . . . . . 9 76 2.3. Requiring Certificate Authentication . . . . . . . . . . 10 77 2.3.1. Requiring Additional Server Certificates . . . . . . 10 78 2.3.2. Requiring Additional Client Certificates . . . . . . 11 79 3. Certificates Frames for HTTP/2 . . . . . . . . . . . . . . . 12 80 3.1. The CERTIFICATE_NEEDED Frame . . . . . . . . . . . . . . 13 81 3.2. The USE_CERTIFICATE Frame . . . . . . . . . . . . . . . . 14 82 3.3. The CERTIFICATE_REQUEST Frame . . . . . . . . . . . . . . 15 83 3.3.1. Exported Authenticator Request Characteristics . . . 16 84 3.4. The CERTIFICATE Frame . . . . . . . . . . . . . . . . . . 17 85 3.4.1. Exported Authenticator Characteristics . . . . . . . 18 86 4. Indicating Failures During HTTP-Layer Certificate 87 Authentication . . . . . . . . . . . . . . . . . . . . . . . 19 88 5. Required Domain Certificate Extension . . . . . . . . . . . . 19 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 90 6.1. Impersonation . . . . . . . . . . . . . . . . . . . . . . 20 91 6.2. Fingerprinting . . . . . . . . . . . . . . . . . . . . . 21 92 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 21 93 6.4. Persistence of Service . . . . . . . . . . . . . . . . . 21 94 6.5. Confusion About State . . . . . . . . . . . . . . . . . . 22 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 97 7.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting . . . . . . . . . 22 98 7.2. New HTTP/2 Frames . . . . . . . . . . . . . . . . . . . . 22 99 7.3. New HTTP/2 Error Codes . . . . . . . . . . . . . . . . . 23 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 102 8.2. Informative References . . . . . . . . . . . . . . . . . 24 103 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 105 A.1. Since draft-ietf-httpbis-http2-secondary-certs-04: . . . 25 106 A.2. Since draft-ietf-httpbis-http2-secondary-certs-03: . . . 25 107 A.3. Since draft-ietf-httpbis-http2-secondary-certs-02: . . . 25 108 A.4. Since draft-ietf-httpbis-http2-secondary-certs-01: . . . 25 109 A.5. Since draft-ietf-httpbis-http2-secondary-certs-00: . . . 26 110 A.6. Since draft-bishop-httpbis-http2-additional-certs-05: . . 26 111 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 114 1. Introduction 116 HTTP clients need to know that the content they receive on a 117 connection comes from the origin that they intended to retrieve it 118 from. The traditional form of server authentication in HTTP has been 119 in the form of a single X.509 certificate provided during the TLS 120 ([RFC5246], [RFC8446]) handshake. 122 Many existing HTTP [RFC7230] servers also have authentication 123 requirements for the resources they serve. Of the bountiful 124 authentication options available for authenticating HTTP requests, 125 client certificates present a unique challenge for resource-specific 126 authentication requirements because of the interaction with the 127 underlying TLS layer. 129 TLS 1.2 [RFC5246] supports one server and one client certificate on a 130 connection. These certificates may contain multiple identities, but 131 only one certificate may be provided. 133 Many HTTP servers host content from several origins. HTTP/2 permits 134 clients to reuse an existing HTTP connection to a server provided 135 that the secondary origin is also in the certificate provided during 136 the TLS handshake. In many cases, servers choose to maintain 137 separate certificates for different origins but still desire the 138 benefits of a shared HTTP connection. 140 1.1. Server Certificate Authentication 142 Section 9.1.1 of [RFC7540] describes how connections may be used to 143 make requests from multiple origins as long as the server is 144 authoritative for both. A server is considered authoritative for an 145 origin if DNS resolves the origin to the IP address of the server and 146 (for TLS) if the certificate presented by the server contains the 147 origin in the Subject Alternative Names field. 149 [RFC7838] enables a step of abstraction from the DNS resolution. If 150 both hosts have provided an Alternative Service at hostnames which 151 resolve to the IP address of the server, they are considered 152 authoritative just as if DNS resolved the origin itself to that 153 address. However, the server's one TLS certificate is still required 154 to contain the name of each origin in question. 156 [RFC8336] relaxes the requirement to perform the DNS lookup if 157 already connected to a server with an appropriate certificate which 158 claims support for a particular origin. 160 Servers which host many origins often would prefer to have separate 161 certificates for some sets of origins. This may be for ease of 162 certificate management (the ability to separately revoke or renew 163 them), due to different sources of certificates (a CDN acting on 164 behalf of multiple origins), or other factors which might drive this 165 administrative decision. Clients connecting to such origins cannot 166 currently reuse connections, even if both client and server would 167 prefer to do so. 169 Because the TLS SNI extension is exchanged in the clear, clients 170 might also prefer to retrieve certificates inside the encrypted 171 context. When this information is sensitive, it might be 172 advantageous to request a general-purpose certificate or anonymous 173 ciphersuite at the TLS layer, while acquiring the "real" certificate 174 in HTTP after the connection is established. 176 1.2. Client Certificate Authentication 178 For servers that wish to use client certificates to authenticate 179 users, they might request client authentication during or immediately 180 after the TLS handshake. However, if not all users or resources need 181 certificate-based authentication, a request for a certificate has the 182 unfortunate consequence of triggering the client to seek a 183 certificate, possibly requiring user interaction, network traffic, or 184 other time-consuming activities. During this time, the connection is 185 stalled in many implementations. Such a request can result in a poor 186 experience, particularly when sent to a client that does not expect 187 the request. 189 The TLS 1.3 CertificateRequest can be used by servers to give clients 190 hints about which certificate to offer. Servers that rely on 191 certificate-based authentication might request different certificates 192 for different resources. Such a server cannot use contextual 193 information about the resource to construct an appropriate TLS 194 CertificateRequest message during the initial handshake. 196 Consequently, client certificates are requested at connection 197 establishment time only in cases where all clients are expected or 198 required to have a single certificate that is used for all resources. 199 Many other uses for client certificates are reactive, that is, 200 certificates are requested in response to the client making a 201 request. 203 1.2.1. HTTP/1.1 Using TLS 1.2 and Earlier 205 In HTTP/1.1, a server that relies on client authentication for a 206 subset of users or resources does not request a certificate when the 207 connection is established. Instead, it only requests a client 208 certificate when a request is made to a resource that requires a 209 certificate. TLS 1.2 [RFC5246] accommodates this by permitting the 210 server to request a new TLS handshake, in which the server will 211 request the client's certificate. 213 Figure 1 shows the server initiating a TLS-layer renegotiation in 214 response to receiving an HTTP/1.1 request to a protected resource. 216 Client Server 217 -- (HTTP) GET /protected -------------------> *1 218 <---------------------- (TLS) HelloRequest -- *2 219 -- (TLS) ClientHello -----------------------> 220 <------------------ (TLS) ServerHello, ... -- 221 <---------------- (TLS) CertificateRequest -- *3 222 -- (TLS) ..., Certificate ------------------> *4 223 -- (TLS) Finished --------------------------> 224 <-------------------------- (TLS) Finished -- 225 <--------------------------- (HTTP) 200 OK -- *5 227 Figure 1: HTTP/1.1 reactive certificate authentication with TLS 1.2 229 In this example, the server receives a request for a protected 230 resource (at *1 on Figure 1). Upon performing an authorization 231 check, the server determines that the request requires authentication 232 using a client certificate and that no such certificate has been 233 provided. 235 The server initiates TLS renegotiation by sending a TLS HelloRequest 236 (at *2). The client then initiates a TLS handshake. Note that some 237 TLS messages are elided from the figure for the sake of brevity. 239 The critical messages for this example are the server requesting a 240 certificate with a TLS CertificateRequest (*3); this request might 241 use information about the request or resource. The client then 242 provides a certificate and proof of possession of the private key in 243 Certificate and CertificateVerify messages (*4). 245 When the handshake completes, the server performs any authorization 246 checks a second time. With the client certificate available, it then 247 authorizes the request and provides a response (*5). 249 1.2.2. HTTP/1.1 Using TLS 1.3 251 TLS 1.3 [RFC8446] introduces a new client authentication mechanism 252 that allows for clients to authenticate after the handshake has been 253 completed. For the purposes of authenticating an HTTP request, this 254 is functionally equivalent to renegotiation. Figure 2 shows the 255 simpler exchange this enables. 257 Client Server 258 -- (HTTP) GET /protected -------------------> 259 <---------------- (TLS) CertificateRequest -- 260 -- (TLS) Certificate, CertificateVerify, 261 Finished -----------------------> 262 <--------------------------- (HTTP) 200 OK -- 264 Figure 2: HTTP/1.1 reactive certificate authentication with TLS 1.3 266 TLS 1.3 does not support renegotiation, instead supporting direct 267 client authentication. In contrast to the TLS 1.2 example, in TLS 268 1.3, a server can simply request a certificate. 270 1.2.3. HTTP/2 272 An important part of the HTTP/1.1 exchange is that the client is able 273 to easily identify the request that caused the TLS renegotiation. 274 The client is able to assume that the next unanswered request on the 275 connection is responsible. The HTTP stack in the client is then able 276 to direct the certificate request to the application or component 277 that initiated that request. This ensures that the application has 278 the right contextual information for processing the request. 280 In HTTP/2, a client can have multiple outstanding requests. Without 281 some sort of correlation information, a client is unable to identify 282 which request caused the server to request a certificate. 284 Thus, the minimum necessary mechanism to support reactive certificate 285 authentication in HTTP/2 is an identifier that can be use to 286 correlate an HTTP request with a request for a certificate. Since 287 streams are used for individual requests, correlation with a stream 288 is sufficient. 290 [RFC7540] prohibits renegotiation after any application data has been 291 sent. This completely blocks reactive certificate authentication in 292 HTTP/2 using TLS 1.2. If this restriction were relaxed by an 293 extension or update to HTTP/2, such an identifier could be added to 294 TLS 1.2 by means of an extension to TLS. Unfortunately, many TLS 1.2 295 implementations do not permit application data to continue during a 296 renegotiation. This is problematic for a multiplexed protocol like 297 HTTP/2. 299 1.3. HTTP-Layer Certificate Authentication 301 This draft defines HTTP/2 frames to carry the relevant certificate 302 messages, enabling certificate-based authentication of both clients 303 and servers independent of TLS version. This mechanism can be 304 implemented at the HTTP layer without breaking the existing interface 305 between HTTP and applications above it. 307 This could be done in a naive manner by replicating the TLS messages 308 as HTTP/2 frames on each stream. However, this would create needless 309 redundancy between streams and require frequent expensive signing 310 operations. Instead, TLS Exported Authenticators 311 [I-D.ietf-tls-exported-authenticator] are exchanged on stream zero 312 and other frames incorporate them to particular requests by reference 313 as needed. 315 TLS Exported Authenticators are structured messages that can be 316 exported by either party of a TLS connection and validated by the 317 other party. Given an established TLS connection, a request can be 318 constructed which describes the desired certificate and an 319 authenticator message can be constructed proving possession of a 320 certificate and a corresponding private key. Both requests and 321 authenticators can be generated by either the client or the server. 322 Exported Authenticators use the message structures from Sections 323 4.3.2 and 4.4 of [RFC8446], but different parameters. 325 Each Authenticator is computed using a Handshake Context and Finished 326 MAC Key derived from the TLS session. The Handshake Context is 327 identical for both parties of the TLS connection, while the Finished 328 MAC Key is dependent on whether the Authenticator is created by the 329 client or the server. 331 Successfully verified Authenticators result in certificate chains, 332 with verified possession of the corresponding private key, which can 333 be supplied into a collection of available certificates. Likewise, 334 descriptions of desired certificates can be supplied into these 335 collections. 337 Section 2 describes how the feature is employed, defining means to 338 detect support in peers (Section 2.1), make certificates and requests 339 available (Section 2.2), and indicate when streams are blocked 340 waiting on an appropriate certificate (Section 2.3). Section 3 341 defines the required frame types, which parallel the TLS 1.3 message 342 exchange. Finally, Section 4 defines new error types which can be 343 used to notify peers when the exchange has not been successful. 345 1.4. Terminology 347 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 348 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 349 "OPTIONAL" in this document are to be interpreted as described in BCP 350 14 [RFC2119] [RFC8174] when, and only when, they appear in all 351 capitals, as shown here. 353 2. Discovering Additional Certificates at the HTTP/2 Layer 355 A certificate chain with proof of possession of the private key 356 corresponding to the end-entity certificate is sent as a sequence of 357 "CERTIFICATE" frames (see Section 3.4) on stream zero. Once the 358 holder of a certificate has sent the chain and proof, this 359 certificate chain is cached by the recipient and available for future 360 use. Clients can proactively indicate the certificate they intend to 361 use on each request using an unsolicited "USE_CERTIFICATE" frame, if 362 desired. The previously-supplied certificates are available for 363 reference without having to resend them. 365 Otherwise, the server uses a "CERTIFICATE_REQUEST" frame to describe 366 a class of certificates on stream zero, then uses 367 "CERTIFICATE_NEEDED" frames to associate these with individual 368 requests. The client responds with a "USE_CERTIFICATE" frame 369 indicating the certificate which should be used to satisfy the 370 request. 372 Data sent by each peer is correlated by the ID given in each frame. 373 This ID is unrelated to values used by the other peer, even if each 374 uses the same ID in certain cases. "USE_CERTIFICATE" frames indicate 375 whether they are sent proactively or are in response to a 376 "CERTIFICATE_NEEDED" frame. 378 2.1. Indicating Support for HTTP-Layer Certificate Authentication 380 Clients and servers that will accept requests for HTTP-layer 381 certificate authentication indicate this using the HTTP/2 382 "SETTINGS_HTTP_CERT_AUTH" (0xSETTING-TBD) setting. 384 The initial value for the "SETTINGS_HTTP_CERT_AUTH" setting is 0, 385 indicating that the peer does not support HTTP-layer certificate 386 authentication. If a peer does support HTTP-layer certificate 387 authentication, the value is non-zero. 389 In order to ensure that the TLS connection is direct to the server, 390 rather than via a TLS-terminating proxy, each side will separately 391 compute and confirm the value of this setting. The setting is 392 derived from a TLS exporter (see Section 7.5 of [RFC8446] and 393 [RFC5705] for more details on exporters). Clients MUST NOT use an 394 early exporter during their 0-RTT flight, but MUST send an updated 395 SETTINGS frame using a regular exporter after the TLS handshake 396 completes. 398 The exporter is constructed with the following input: 400 o Label: 402 * "EXPORTER HTTP CERTIFICATE client" for clients 404 * "EXPORTER HTTP CERTIFICATE server" for servers 406 o Context: Empty 408 o Length: Four bytes 410 The resulting exporter is converted to a setting value as: 412 (Exporter & 0x3fffffff) | 0x80000000 414 That is, the most significant bit will always be set, regardless of 415 the value of the exporter. Each endpoint will compute the expected 416 value from their peer. If the setting is not received, or if the 417 value received is not the expected value, the frames defined in this 418 document SHOULD NOT be sent. 420 2.2. Making Certificates or Requests Available 422 When both peers have advertised support for HTTP-layer certificates 423 as in Section 2.1, either party can supply additional certificates 424 into the connection at any time. This means that clients or servers 425 which predict a certificate will be required could supply the 426 certificate before being asked. These certificates are available for 427 reference by future "USE_CERTIFICATE" frames. 429 Certificates supplied by servers can be considered by clients without 430 further action by the server. A server SHOULD NOT send certificates 431 which do not cover origins which it is prepared to service on the 432 current connection, but MAY use the ORIGIN frame [RFC8336] to 433 indicate that not all covered origins will be served. 435 Client Server 436 <------------------ (stream 0) CERTIFICATE -- 437 ... 438 -- (stream N) GET /from-new-origin ---------> 439 <----------------------- (stream N) 200 OK -- 441 Figure 3: Proactive server authentication 443 Client Server 444 -- (stream 0) CERTIFICATE ------------------> 445 -- (stream 0) USE_CERTIFICATE (S=1) --------> 446 -- (stream 0) USE_CERTIFICATE (S=3) --------> 447 -- (streams 1,3) GET /protected ------------> 448 <-------------------- (streams 1,3) 200 OK -- 450 Figure 4: Proactive client authentication 452 Likewise, either party can supply a "CERTIFICATE_REQUEST" that 453 outlines parameters of a certificate they might request in the 454 future. Upon receipt of a "CERTIFICATE_REQUEST", endpoints SHOULD 455 provide a corresponding certificate in anticipation of a request 456 shortly being blocked. Clients MAY wait for a "CERTIFICATE_NEEDED" 457 frame to assist in associating the certificate request with a 458 particular HTTP transaction. 460 2.3. Requiring Certificate Authentication 462 2.3.1. Requiring Additional Server Certificates 464 As defined in [RFC7540], when a client finds that an https:// origin 465 (or Alternative Service [RFC7838]) to which it needs to make a 466 request has the same IP address as a server to which it is already 467 connected, it MAY check whether the TLS certificate provided contains 468 the new origin as well, and if so, reuse the connection. 470 If the TLS certificate does not contain the new origin, but the 471 server has claimed support for that origin (with an ORIGIN frame, see 473 [RFC8336]) and advertised support for HTTP-layer certificates (see 474 Section 2.1), the client MAY send a "CERTIFICATE_REQUEST" frame 475 describing the desired origin. The client then sends a 476 "CERTIFICATE_NEEDED" frame for stream zero referencing the request, 477 indicating that the connection cannot be used for that origin until 478 the certificate is provided. 480 If the server does not have the desired certificate, it MUST send an 481 Empty Authenticator, as described in Section 5 of 482 [I-D.ietf-tls-exported-authenticator], in a "CERTIFICATE" frame in 483 response to the request, followed by a "USE_CERTIFICATE" frame for 484 stream zero which references the Empty Authenticator. In this case, 485 or if the server has not advertised support for HTTP-layer 486 certificates, the client MUST NOT send any requests for resources in 487 that origin on the current connection. 489 Client Server 490 <----------------------- (stream 0) ORIGIN -- 491 -- (stream 0) CERTIFICATE_REQUEST ----------> 492 -- (stream 0) CERTIFICATE_NEEDED (S=0) -----> 493 <------------------ (stream 0) CERTIFICATE -- 494 <-------- (stream 0) USE_CERTIFICATE (S=0) -- 495 -- (stream N) GET /from-new-origin ---------> 496 <----------------------- (stream N) 200 OK -- 498 Figure 5: Client-requested certificate 500 If a client receives a "PUSH_PROMISE" referencing an origin for which 501 it has not yet received the server's certificate, this is a fatal 502 connection error (see section 8.2 of [RFC7540]). To avoid this, 503 servers MUST supply the associated certificates before pushing 504 resources from a different origin. 506 2.3.2. Requiring Additional Client Certificates 508 Likewise, the server sends a "CERTIFICATE_NEEDED" frame for each 509 stream where certificate authentication is required. The client 510 answers with a "USE_CERTIFICATE" frame indicating the certificate to 511 use on that stream. If the request parameters or the responding 512 certificate are not already available, they will need to be sent as 513 described in Section 2.2 as part of this exchange. 515 Client Server 516 <---------- (stream 0) CERTIFICATE_REQUEST -- 517 ... 518 -- (stream N) GET /protected ---------------> 519 <----- (stream 0) CERTIFICATE_NEEDED (S=N) -- 520 -- (stream 0) CERTIFICATE ------------------> 521 -- (stream 0) USE_CERTIFICATE (S=N) --------> 522 <----------------------- (stream N) 200 OK -- 524 Figure 6: Reactive certificate authentication 526 If the client does not have the desired certificate, it instead sends 527 an Empty Authenticator, as described in Section 5 of 528 [I-D.ietf-tls-exported-authenticator], in a "CERTIFICATE" frame in 529 response to the request, followed by a "USE_CERTIFICATE" frame which 530 references the Empty Authenticator. In this case, or if the client 531 has not advertised support for HTTP-layer certificates, the server 532 processes the request based solely on the certificate provided during 533 the TLS handshake, if any. This might result in an error response 534 via HTTP, such as a status code 403 (Not Authorized). 536 3. Certificates Frames for HTTP/2 538 The "CERTIFICATE_REQUEST" and "CERTIFICATE_NEEDED" frames are 539 correlated by their "Request-ID" field. Subsequent 540 "CERTIFICATE_NEEDED" frames with the same "Request-ID" value MAY be 541 sent for other streams where the sender is expecting a certificate 542 with the same parameters. 544 The "CERTIFICATE", and "USE_CERTIFICATE" frames are correlated by 545 their "Cert-ID" field. Subsequent "USE_CERTIFICATE" frames with the 546 same "Cert-ID" MAY be sent in response to other "CERTIFICATE_NEEDED" 547 frames and refer to the same certificate. 549 "CERTIFICATE_NEEDED" and "USE_CERTIFICATE" frames are correlated by 550 the Stream ID they reference. Unsolicited "USE_CERTIFICATE" frames 551 are not responses to "CERTIFICATE_NEEDED" frames; otherwise, each 552 "USE_CERTIFICATE" frame for a stream is considered to respond to a 553 "CERTIFICATE_NEEDED" frame for the same stream in sequence. 555 +---------+ +---------+ 556 | REQUEST | | CERT | 557 +---------+ +---------+ 558 | | 559 | Request-ID | Cert-ID 560 | | 561 v v 562 +---------+ Stream ID +---------+ 563 | NEEDED |---------->| USE | 564 +---------+ +---------+ 566 Figure 7: Frame correlation 568 "Request-ID" and "Cert-ID" are independent and sender-local. The use 569 of the same value by the other peer or in the other context does not 570 imply any correlation between these frames. These values MUST be 571 unique per sender for each space over the lifetime of the connection. 573 3.1. The CERTIFICATE_NEEDED Frame 575 The "CERTIFICATE_NEEDED" frame (0xFRAME-TBD1) is sent on stream zero 576 to indicate that the HTTP request on the indicated stream is blocked 577 pending certificate authentication. The frame includes stream ID and 578 a request identifier which can be used to correlate the stream with a 579 previous "CERTIFICATE_REQUEST" frame sent on stream zero. The 580 "CERTIFICATE_REQUEST" describes the certificate the sender requires 581 to make progress on the stream in question. 583 0 1 2 3 584 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 585 +---------------------------------------------------------------+ 586 |R| Stream ID (31) | 587 +-------------------------------+-------------------------------+ 588 | Request-ID (16) | 589 +-------------------------------+ 591 Figure 8: CERTIFICATE_NEEDED frame payload 593 The "CERTIFICATE_NEEDED" frame contains 6 octets. The first four 594 octets indicate the Stream ID of the affected stream. The following 595 two octets are the authentication request identifier, "Request-ID". 596 A peer that receives a "CERTIFICATE_NEEDED" of any other length MUST 597 treat this as a stream error of type "PROTOCOL_ERROR". Frames with 598 identical request identifiers refer to the same 599 "CERTIFICATE_REQUEST". 601 A server MAY send multiple "CERTIFICATE_NEEDED" frames for the same 602 stream. If a server requires that a client provide multiple 603 certificates before authorizing a single request, each required 604 certificate MUST be indicated with a separate "CERTIFICATE_NEEDED" 605 frame, each of which MUST have a different request identifier 606 (referencing different "CERTIFICATE_REQUEST" frames describing each 607 required certificate). To reduce the risk of client confusion, 608 servers SHOULD NOT have multiple outstanding "CERTIFICATE_NEEDED" 609 frames for the same stream at any given time. 611 Clients MUST only send multiple "CERTIFICATE_NEEDED" frames for 612 stream zero. Multiple "CERTIFICATE_NEEDED" frames on any other 613 stream MUST be considered a stream error of type "PROTOCOL_ERROR". 615 The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a peer which has 616 not advertised support for HTTP-layer certificate authentication. 618 The "CERTIFICATE_NEEDED" frame MUST NOT reference a stream in the 619 "half-closed (local)" or "closed" states [RFC7540]. A client that 620 receives a "CERTIFICATE_NEEDED" frame for a stream which is not in a 621 valid state SHOULD treat this as a stream error of type 622 "PROTOCOL_ERROR". 624 3.2. The USE_CERTIFICATE Frame 626 The "USE_CERTIFICATE" frame (0xFRAME-TBD4) is sent on stream zero to 627 indicate which certificate is being used on a particular request 628 stream. 630 The "USE_CERTIFICATE" frame defines a single flag: 632 UNSOLICITED (0x01): Indicates that no "CERTIFICATE_NEEDED" frame has 633 yet been received for this stream. 635 The payload of the "USE_CERTIFICATE" frame is as follows: 637 0 1 2 3 638 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 639 +---------------------------------------------------------------+ 640 |R| Stream ID (31) | 641 +-------------------------------+-------------------------------+ 642 | [Cert-ID (16)] | 643 +-------------------------------+ 645 Figure 9: USE_CERTIFICATE frame payload 647 The first four octets indicate the Stream ID of the affected stream. 648 The following two octets, if present, contain the two-octet "Cert-ID" 649 of the certificate the sender wishes to use. This MUST be the ID of 650 a certificate for which proof of possession has been presented in a 651 "CERTIFICATE" frame. Recipients of a "USE_CERTIFICATE" frame of any 652 other length MUST treat this as a stream error of type 653 "PROTOCOL_ERROR". Frames with identical certificate identifiers 654 refer to the same certificate chain. 656 A "USE_CERTIFICATE" frame which omits the Cert-ID refers to the 657 certificate provided at the TLS layer, if any. If no certificate was 658 provided at the TLS layer, the stream should be processed with no 659 authentication, likely returning an authentication-related error at 660 the HTTP level (e.g. 403) for servers or routing the request to a new 661 connection for clients. 663 The "UNSOLICITED" flag MAY be set by clients on the first 664 "USE_CERTIFICATE" frame referring to a given stream. This permits a 665 client to proactively indicate which certificate should be used when 666 processing a new request. When such an unsolicited indication refers 667 to a request that has not yet been received, servers SHOULD cache the 668 indication briefly in anticipation of the request. 670 Receipt of more than one unsolicited "USE_CERTIFICATE" frames or an 671 unsolicited "USE_CERTIFICATE" frame which is not the first in 672 reference to a given stream MUST be treated as a stream error of type 673 "CERTIFICATE_OVERUSED". 675 Each "USE_CERTIFICATE" frame which is not marked as unsolicited is 676 considered to respond in order to the "CERTIFICATE_NEEDED" frames for 677 the same stream. If a "USE_CERTIFICATE" frame is received for which 678 a "CERTIFICATE_NEEDED" frame has not been sent, this MUST be treated 679 as a stream error of type "CERTIFICATE_OVERUSED". 681 Receipt of a "USE_CERTIFICATE" frame with an unknown "Cert-ID" MUST 682 result in a stream error of type "PROTOCOL_ERROR". 684 The referenced certificate chain needs to conform to the requirements 685 expressed in the "CERTIFICATE_REQUEST" to the best of the sender's 686 ability, or the recipient is likely to reject it as unsuitable 687 despite properly validating the authenticator. If the recipient 688 considers the certificate unsuitable, it MAY at its discretion either 689 return an error at the HTTP semantic layer, or respond with a stream 690 error [RFC7540] on any stream where the certificate is used. 691 Section 4 defines certificate-related error codes which might be 692 applicable. 694 3.3. The CERTIFICATE_REQUEST Frame 696 The "CERTIFICATE_REQUEST" frame (id=0xFRAME-TBD2) provides an 697 exported authenticator request message from the TLS layer that 698 specifies a desired certificate. This describes the certificate the 699 sender wishes to have presented. 701 The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a peer which 702 has not advertised support for HTTP-layer certificate authentication. 704 The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero. A 705 "CERTIFICATE_REQUEST" frame received on any other stream MUST be 706 rejected with a stream error of type "PROTOCOL_ERROR". 708 0 1 2 3 709 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 710 +-------------------------------+-------------------------------+ 711 | Request-ID (16) | Request (?) ... 712 +---------------------------------------------------------------+ 714 Figure 10: CERTIFICATE_REQUEST frame payload 716 The frame contains the following fields: 718 Request-ID: "Request-ID" is a 16-bit opaque identifier used to 719 correlate subsequent certificate-related frames with this request. 720 The identifier MUST be unique in the session for the sender. 722 Request: An exported authenticator request, generated using the 723 "request" API described in [I-D.ietf-tls-exported-authenticator]. 724 See Section 3.4.1 for more details on the input to this API. 726 3.3.1. Exported Authenticator Request Characteristics 728 The Exported Authenticator "request" API defined in 729 [I-D.ietf-tls-exported-authenticator] takes as input a set of desired 730 certificate characteristics and a "certificate_request_context", 731 which needs to be unpredictable. When generating exported 732 authenticators for use with this extension, the 733 "certificate_request_context" MUST contain both the two-octet 734 Request-ID as well as at least 96 bits of additional entropy. 736 Upon receipt of a "CERTIFICATE_REQUEST" frame, the recipient MUST 737 verify that the first two octets of the authenticator's 738 "certificate_request_context" matches the Request-ID presented in the 739 frame. 741 The TLS library on the authenticating peer will provide mechanisms to 742 select an appropriate certificate to respond to the transported 743 request. TLS libraries on servers MUST be able to recognize the 744 "server_name" extension ([RFC6066]) at a minimum. Clients MUST 745 always specify the desired origin using this extension, though other 746 extensions MAY also be included. 748 3.4. The CERTIFICATE Frame 750 The "CERTIFICATE" frame (id=0xFRAME-TBD3) provides an exported 751 authenticator message from the TLS layer that provides a chain of 752 certificates, associated extensions and proves possession of the 753 private key corresponding to the end-entity certificate. 755 The "CERTIFICATE" frame defines two flags: 757 TO_BE_CONTINUED (0x01): Indicates that the exported authenticator 758 spans more than one frame. 760 UNSOLICITED (0x02): Indicates that the exported authenticator does 761 not contain a Request-ID. 763 0 1 2 3 764 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 765 +-------------------------------+-------------------------------+ 766 | Cert-ID (16) | Request-ID (16) | 767 +-------------------------------+-------------------------------+ 768 | Authenticator Fragment (*) ... 769 +---------------------------------------------------------------+ 771 Figure 11: CERTIFICATE frame payload 773 The frame contains the following fields: 775 Cert-ID: "Cert-ID" is a 16-bit opaque identifier used to correlate 776 other certificate- related frames with this exported authenticator 777 fragment. 779 Request-ID: "Request-ID" is an optional 16-bit opaque identifier 780 used to correlate this exported authenticator with the request 781 which triggered it, if any. This field is present only if the 782 "UNSOLICITED" flag is not set. 784 Authenticator Fragment: A portion of the opaque data returned from 785 the TLS connection exported authenticator "authenticate" API. See 786 Section 3.4.1 for more details on the input to this API. 788 An exported authenticator is transported in zero or more 789 "CERTIFICATE" frames with the "TO_BE_CONTINUED" flag set, followed by 790 one "CERTIFICATE" frame with the "TO_BE_CONTINUED" flag unset. Each 791 of these frames contains the same "Cert-ID" field, permitting them to 792 be associated with each other. Receipt of any "CERTIFICATE" frame 793 with the same "Cert-ID" following the receipt of a "CERTIFICATE" 794 frame with "TO_BE_CONTINUED" unset MUST be treated as a connection 795 error of type "PROTOCOL_ERROR". 797 If the "UNSOLICITED" flag is not set, the "CERTIFICATE" frame also 798 contains a Request-ID indicating the certificate request which caused 799 this exported authenticator to be generated. The value of this flag 800 and the contents of the Request-ID field MUST NOT differ between 801 frames with the same Cert-ID. 803 Upon receiving a complete series of "CERTIFICATE" frames, the 804 receiver may validate the Exported Authenticator value by using the 805 exported authenticator API. This returns either an error indicating 806 that the message was invalid, or the certificate chain and extensions 807 used to create the message. 809 The "CERTIFICATE" frame MUST be sent on stream zero. A "CERTIFICATE" 810 frame received on any other stream MUST be rejected with a stream 811 error of type "PROTOCOL_ERROR". 813 3.4.1. Exported Authenticator Characteristics 815 The Exported Authenticator API defined in 816 [I-D.ietf-tls-exported-authenticator] takes as input a request, a set 817 of certificates, and supporting information about the certificate 818 (OCSP, SCT, etc.). The result is an opaque token which is used when 819 generating the "CERTIFICATE" frame. 821 Upon receipt of a "CERTIFICATE" frame, an endpoint MUST perform the 822 following steps to validate the token it contains: 824 o Verify that either the "UNSOLICITED" flag is set (clients only) or 825 that the Request-ID field contains the Request-ID of a previously- 826 sent "CERTIFICATE_REQUEST" frame. 828 o Using the "get context" API, retrieve the 829 "certificate_request_context" used to generate the authenticator, 830 if any. Verify that the "certificate_request_context" begins with 831 the supplied Request-ID, if any. 833 o Use the "validate" API to confirm the validity of the 834 authenticator with regard to the generated request (if any). 836 Once the authenticator is accepted, the endpoint can perform any 837 other checks for the acceptability of the certificate itself. 838 Clients MUST NOT accept any end-entity certificate from an exported 839 authenticator which does not contain the Required Domain extension; 840 see Section 5 and Section 6.1. 842 4. Indicating Failures During HTTP-Layer Certificate Authentication 844 Because this draft permits certificates to be exchanged at the HTTP 845 framing layer instead of the TLS layer, several certificate-related 846 errors which are defined at the TLS layer might now occur at the HTTP 847 framing layer. In this section, those errors are restated and added 848 to the HTTP/2 error code registry. 850 BAD_CERTIFICATE (0xERROR-TBD1): A certificate was corrupt, contained 851 signatures that did not verify correctly, etc. 853 UNSUPPORTED_CERTIFICATE (0xERROR-TBD2): A certificate was of an 854 unsupported type or did not contain required extensions 856 CERTIFICATE_REVOKED (0xERROR-TBD3): A certificate was revoked by its 857 signer 859 CERTIFICATE_EXPIRED (0xERROR-TBD4): A certificate has expired or is 860 not currently valid 862 CERTIFICATE_GENERAL (0xERROR-TBD5): Any other certificate-related 863 error 865 CERTIFICATE_OVERUSED (0xERROR-TBD6): More certificates were used on 866 a request than were requested 868 As described in [RFC7540], implementations MAY choose to treat a 869 stream error as a connection error at any time. Of particular note, 870 a stream error cannot occur on stream 0, which means that 871 implementations cannot send non-session errors in response to 872 "CERTIFICATE_REQUEST", and "CERTIFICATE" frames. Implementations 873 which do not wish to terminate the connection MAY either send 874 relevant errors on any stream which references the failing 875 certificate in question or process the requests as unauthenticated 876 and provide error information at the HTTP semantic layer. 878 5. Required Domain Certificate Extension 880 The Required Domain extension allows certificates to limit their use 881 with Secondary Certificate Authentication. A client MUST verify that 882 the server has proven ownership of the indicated identity before 883 accepting the limited certificate over Secondary Certificate 884 Authentication. 886 The identity in this extension is a restriction asserted by the 887 requester of the certificate and is not verified by the CA. 888 Conforming CAs SHOULD mark the requiredDomain extension as non- 889 critical. Conforming CAs MUST require the presence of a CAA record 891 [RFC6844] prior to issuing a certificate with this extension. 892 Because a Required Domain value of "*" has a much higher risk of 893 reuse if compromised, conforming Certificate Authorities are 894 encouraged to require more extensive verification prior to issuing 895 such a certificate. 897 The required domain is represented as a GeneralName, as specified in 898 Section 4.2.1.6 of [RFC5280]. Unlike the subject field, conforming 899 CAs MUST NOT issue certificates with a requiredDomain extension 900 containing empty GeneralName fields. Clients that encounter such a 901 certificate when processing a certification path MUST consider the 902 certificate invalid. 904 The wildcard character "_" MAY be used to represent that any 905 previously authenticated identity is acceptable. This character MUST 906 be the entirety of the name if used and MUST have a type of 907 "dNSName". (That is, "_" is acceptable, but "_.com" and 908 "w_.example.com" are not). 910 id-ce-requiredDomain OBJECT IDENTIFIER ::= { id-ce TBD1 } 912 RequiredDomain ::= GeneralName 914 6. Security Considerations 916 This mechanism defines an alternate way to obtain server and client 917 certificates other than in the initial TLS handshake. While the 918 signature of exported authenticator values is expected to be equally 919 secure, it is important to recognize that a vulnerability in this 920 code path is at least equal to a vulnerability in the TLS handshake. 922 6.1. Impersonation 924 This mechanism could increase the impact of a key compromise. Rather 925 than needing to subvert DNS or IP routing in order to use a 926 compromised certificate, a malicious server now only needs a client 927 to connect to _some_ HTTPS site under its control in order to present 928 the compromised certificate. As recommended in [RFC8336], clients 929 opting not to consult DNS ought to employ some alternative means to 930 increase confidence that the certificate is legitimate. 932 One such means is the Required Domain certificate extension defined 933 in {extension}. Clients MUST require that server certificates 934 presented via this mechanism contain the Required Domain extension 935 and require that a certificate previously accepted on the connection 936 (including the certificate presented in TLS) lists the Required 937 Domain in the Subject field or the Subject Alternative Name 938 extension. 940 As noted in the Security Considerations of 941 [I-D.ietf-tls-exported-authenticator], it is difficult to formally 942 prove that an endpoint is jointly authoritative over multiple 943 certificates, rather than individually authoritative on each 944 certificate. As a result, clients MUST NOT assume that because one 945 origin was previously colocated with another, those origins will be 946 reachable via the same endpoints in the future. Clients MUST NOT 947 consider previous secondary certificates to be validated after TLS 948 session resumption. However, clients MAY proactively query for 949 previously-presented secondary certificates. 951 6.2. Fingerprinting 953 This draft defines a mechanism which could be used to probe servers 954 for origins they support, but opens no new attack versus making 955 repeat TLS connections with different SNI values. Servers SHOULD 956 impose similar denial-of-service mitigations (e.g. request rate 957 limits) to "CERTIFICATE_REQUEST" frames as to new TLS connections. 959 While the extensions in the "CERTIFICATE_REQUEST" frame permit the 960 sender to enumerate the acceptable Certificate Authorities for the 961 requested certificate, it might not be prudent (either for security 962 or data consumption) to include the full list of trusted Certificate 963 Authorities in every request. Senders, particularly clients, SHOULD 964 send only the extensions that narrowly specify which certificates 965 would be acceptable. 967 6.3. Denial of Service 969 Failure to provide a certificate for a stream after receiving 970 "CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to 971 standard timeouts used to guard against unresponsive peers. 973 Validating a multitude of signatures can be computationally 974 expensive, while generating an invalid signature is computationally 975 cheap. Implementations will require checks for attacks from this 976 direction. Invalid exported authenticators SHOULD be treated as a 977 session error, to avoid further attacks from the peer, though an 978 implementation MAY instead disable HTTP-layer certificates for the 979 current connection instead. 981 6.4. Persistence of Service 983 CNAME records in the DNS are frequently used to delegate authority 984 for an origin to a third-party provider. This delegation can be 985 changed without notice, even to the third-party provider, simply by 986 modifying the CNAME record in question. 988 After the owner of the domain has redirected traffic elsewhere by 989 changing the CNAME, new connections will not arrive for that origin, 990 but connections which are properly directed to this provider for 991 other origins would continue to claim control of this origin (via 992 ORIGIN frame and Secondary Certificates). This is proper behavior 993 based on the third-party provider's configuration, but would likely 994 not be what is intended by the owner of the origin. 996 This is not an issue which can be mitigated by the protocol, but 997 something about which third-party providers SHOULD educate their 998 customers before using the features described in this document. 1000 6.5. Confusion About State 1002 Implementations need to be aware of the potential for confusion about 1003 the state of a connection. The presence or absence of a validated 1004 certificate can change during the processing of a request, 1005 potentially multiple times, as "USE_CERTIFICATE" frames are received. 1006 A server that uses certificate authentication needs to be prepared to 1007 reevaluate the authorization state of a request as the set of 1008 certificates changes. 1010 7. IANA Considerations 1012 This draft adds entries in three registries. 1014 The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in 1015 Section 7.1. Four frame types are registered in Section 7.2. Six 1016 error codes are registered in Section 7.3. 1018 7.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting 1020 The SETTINGS_HTTP_CERT_AUTH setting is registered in the "HTTP/2 1021 Settings" registry established in [RFC7540]. 1023 Name: SETTINGS_HTTP_CERT_AUTH 1025 Code: 0xSETTING-TBD 1027 Initial Value: 0 1029 Specification: This document. 1031 7.2. New HTTP/2 Frames 1033 Four new frame types are registered in the "HTTP/2 Frame Types" 1034 registry established in [RFC7540]. The entries in the following 1035 table are registered by this document. 1037 +---------------------+--------------+---------------+ 1038 | Frame Type | Code | Specification | 1039 +---------------------+--------------+---------------+ 1040 | CERTIFICATE_NEEDED | 0xFRAME-TBD1 | Section 3.1 | 1041 | | | | 1042 | CERTIFICATE_REQUEST | 0xFRAME-TBD2 | Section 3.3 | 1043 | | | | 1044 | CERTIFICATE | 0xFRAME-TBD3 | Section 3.4 | 1045 | | | | 1046 | USE_CERTIFICATE | 0xFRAME-TBD4 | Section 3.2 | 1047 +---------------------+--------------+---------------+ 1049 7.3. New HTTP/2 Error Codes 1051 Six new error codes are registered in the "HTTP/2 Error Code" 1052 registry established in [RFC7540]. The entries in the following 1053 table are registered by this document. 1055 +-------------------------+--------------+---------------+ 1056 | Name | Code | Specification | 1057 +-------------------------+--------------+---------------+ 1058 | BAD_CERTIFICATE | 0xERROR-TBD1 | Section 4 | 1059 | | | | 1060 | UNSUPPORTED_CERTIFICATE | 0xERROR-TBD2 | Section 4 | 1061 | | | | 1062 | CERTIFICATE_REVOKED | 0xERROR-TBD3 | Section 4 | 1063 | | | | 1064 | CERTIFICATE_EXPIRED | 0xERROR-TBD4 | Section 4 | 1065 | | | | 1066 | CERTIFICATE_GENERAL | 0xERROR-TBD5 | Section 4 | 1067 | | | | 1068 | CERTIFICATE_OVERUSED | 0xERROR-TBD6 | Section 4 | 1069 +-------------------------+--------------+---------------+ 1071 8. References 1073 8.1. Normative References 1075 [I-D.ietf-tls-exported-authenticator] 1076 Sullivan, N., "Exported Authenticators in TLS", draft- 1077 ietf-tls-exported-authenticator-09 (work in progress), May 1078 2019. 1080 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1081 Requirement Levels", BCP 14, RFC 2119, 1082 DOI 10.17487/RFC2119, March 1997, 1083 . 1085 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1086 (TLS) Protocol Version 1.2", RFC 5246, 1087 DOI 10.17487/RFC5246, August 2008, 1088 . 1090 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1091 Housley, R., and W. Polk, "Internet X.509 Public Key 1092 Infrastructure Certificate and Certificate Revocation List 1093 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1094 . 1096 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1097 Extensions: Extension Definitions", RFC 6066, 1098 DOI 10.17487/RFC6066, January 2011, 1099 . 1101 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 1102 Authority Authorization (CAA) Resource Record", RFC 6844, 1103 DOI 10.17487/RFC6844, January 2013, 1104 . 1106 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1107 Protocol (HTTP/1.1): Message Syntax and Routing", 1108 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1109 . 1111 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 1112 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 1113 DOI 10.17487/RFC7540, May 2015, 1114 . 1116 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1117 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1118 May 2017, . 1120 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1121 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1122 . 1124 8.2. Informative References 1126 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 1127 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 1128 March 2010, . 1130 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 1131 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 1132 April 2016, . 1134 [RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", 1135 RFC 8336, DOI 10.17487/RFC8336, March 2018, 1136 . 1138 8.3. URIs 1140 [1] https://lists.w3.org/Archives/Public/ietf-http-wg/ 1142 [2] http://httpwg.github.io/ 1144 [3] https://github.com/httpwg/http-extensions/labels/secondary-certs 1146 Appendix A. Change Log 1148 *RFC Editor's Note:* Please remove this section prior to 1149 publication of a final version of this document. 1151 A.1. Since draft-ietf-httpbis-http2-secondary-certs-04: 1153 Editorial updates only. 1155 A.2. Since draft-ietf-httpbis-http2-secondary-certs-03: 1157 o "CERTIFICATE_REQUEST" frames contain the Request-ID, which MUST be 1158 checked against the "certificate_request_context" of the Exported 1159 Authenticator Request 1161 o "CERTIFICATE" frames contain the Request-ID to which they respond, 1162 unless the UNSOLICITED flag is set 1164 o The Required Domain extension is defined for certificates, which 1165 must be present for certificates presented by servers 1167 A.3. Since draft-ietf-httpbis-http2-secondary-certs-02: 1169 Editorial updates only. 1171 A.4. Since draft-ietf-httpbis-http2-secondary-certs-01: 1173 o Clients can send "CERTIFICATE_NEEDED" for stream 0 rather than 1174 speculatively reserving a stream for an origin. 1176 o Use SETTINGS to disable when a TLS-terminating proxy is present 1177 (#617,#651) 1179 A.5. Since draft-ietf-httpbis-http2-secondary-certs-00: 1181 o All frames sent on stream zero; replaced "AUTOMATIC_USE" on 1182 "CERTIFICATE" with "UNSOLICITED" on "USE_CERTIFICATE". (#482,#566) 1184 o Use Exported Requests from the TLS Exported Authenticators draft; 1185 eliminate facilities for expressing certificate requirements in 1186 "CERTIFICATE_REQUEST" frame. (#481) 1188 A.6. Since draft-bishop-httpbis-http2-additional-certs-05: 1190 o Adopted as draft-ietf-httpbis-http2-secondary-certs 1192 Acknowledgements 1194 Eric Rescorla pointed out several failings in an earlier revision. 1195 Andrei Popov contributed to the TLS considerations. 1197 A substantial portion of Mike's work on this draft was supported by 1198 Microsoft during his employment there. 1200 Authors' Addresses 1202 Mike Bishop 1203 Akamai 1205 Email: mbishop@evequefou.be 1207 Nick Sullivan 1208 Cloudflare 1210 Email: nick@cloudflare.com 1212 Martin Thomson 1213 Mozilla 1215 Email: martin.thomson@gmail.com