idnits 2.17.1 draft-ietf-httpbis-http2-secondary-certs-00.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 ([I-D.ietf-tls-exported-authenticator], [RFC7540], [I-D.ietf-tls-tls13]), 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 4, 2017) is 2328 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) == Unused Reference: 'RFC2459' is defined on line 907, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 917, but no explicit reference was found in the text == Unused Reference: 'X690' is defined on line 938, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-04 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-22 ** Obsolete normative reference: RFC 2459 (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' == Outdated reference: A later version (-06) exists of draft-ietf-httpbis-origin-frame-04 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 2 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: June 7, 2018 Cloudflare 6 M. Thomson 7 Mozilla 8 December 4, 2017 10 Secondary Certificate Authentication in HTTP/2 11 draft-ietf-httpbis-http2-secondary-certs-00 13 Abstract 15 TLS provides fundamental mutual authentication services for HTTP, 16 supporting up to one server certificate and up to one client 17 certificate associated to the session to prove client and server 18 identities as necessary. This draft provides mechanisms for 19 providing additional such certificates at the HTTP layer when these 20 constraints are not sufficient. 22 Many HTTP servers host content from several origins. HTTP/2 23 [RFC7540] permits clients to reuse an existing HTTP connection to a 24 server provided that the secondary origin is also in the certificate 25 provided during the TLS [I-D.ietf-tls-tls13] handshake. 27 In many cases, servers will wish to maintain separate certificates 28 for different origins but still desire the benefits of a shared HTTP 29 connection. Similarly, servers may require clients to present 30 authentication, but have different requirements based on the content 31 the client is attempting to access. 33 This document describes how TLS exported authenticators 34 [I-D.ietf-tls-exported-authenticator] can be used to provide proof of 35 ownership of additional certificates to the HTTP layer to support 36 both scenarios. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on June 7, 2018. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Server Certificate Authentication . . . . . . . . . . . . 3 74 1.2. Client Certificate Authentication . . . . . . . . . . . . 4 75 1.2.1. HTTP/1.1 using TLS 1.2 and previous . . . . . . . . . 5 76 1.2.2. HTTP/1.1 using TLS 1.3 . . . . . . . . . . . . . . . 6 77 1.2.3. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 6 78 1.3. HTTP-Layer Certificate Authentication . . . . . . . . . . 7 79 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 80 2. Discovering Additional Certificates at the HTTP/2 Layer . . . 8 81 2.1. Indicating support for HTTP-layer certificate 82 authentication . . . . . . . . . . . . . . . . . . . . . 8 83 2.2. Making certificates or requests available . . . . . . . . 8 84 2.3. Requiring certificate authentication . . . . . . . . . . 9 85 3. Certificates Frames for HTTP/2 . . . . . . . . . . . . . . . 11 86 3.1. The CERTIFICATE_NEEDED frame . . . . . . . . . . . . . . 11 87 3.2. The USE_CERTIFICATE Frame . . . . . . . . . . . . . . . . 12 88 3.3. The CERTIFICATE_REQUEST Frame . . . . . . . . . . . . . . 13 89 3.4. The CERTIFICATE Frame . . . . . . . . . . . . . . . . . . 14 90 3.4.1. Exported Authenticator Characteristics . . . . . . . 15 91 4. Indicating failures during HTTP-Layer Certificate 92 Authentication . . . . . . . . . . . . . . . . . . . . . . . 15 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 94 5.1. Impersonation . . . . . . . . . . . . . . . . . . . . . . 16 95 5.2. Fingerprinting . . . . . . . . . . . . . . . . . . . . . 17 96 5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 17 97 5.4. Confusion About State . . . . . . . . . . . . . . . . . . 17 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 99 6.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting . . . . . . . . . 18 100 6.2. New HTTP/2 Frames . . . . . . . . . . . . . . . . . . . . 18 101 6.3. New HTTP/2 Error Codes . . . . . . . . . . . . . . . . . 19 102 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 103 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 105 8.2. Informative References . . . . . . . . . . . . . . . . . 21 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 108 1. Introduction 110 HTTP clients need to know that the content they receive on a 111 connection comes from the origin that they intended to retrieve in 112 from. The traditional form of server authentication in HTTP has been 113 in the form of X.509 certificates provided during the TLS RFC5246 114 [I-D.ietf-tls-tls13] handshake. 116 Many existing HTTP [RFC7230] servers also have authentication 117 requirements for the resources they serve. Of the bountiful 118 authentication options available for authenticating HTTP requests, 119 client certificates present a unique challenge for resource-specific 120 authentication requirements because of the interaction with the 121 underlying TLS layer. 123 TLS 1.2 [RFC5246] supports one server and one client certificate on a 124 connection. These certificates may contain multiple identities, but 125 only one certificate may be provided. 127 1.1. Server Certificate Authentication 129 Section 9.1.1 of [RFC7540] describes how connections may be used to 130 make requests from multiple origins as long as the server is 131 authoritative for both. A server is considered authoritative for an 132 origin if DNS resolves the origin to the IP address of the server and 133 (for TLS) if the certificate presented by the server contains the 134 origin in the Subject Alternative Names field. 136 [RFC7838] enables a step of abstraction from the DNS resolution. If 137 both hosts have provided an Alternative Service at hostnames which 138 resolve to the IP address of the server, they are considered 139 authoritative just as if DNS resolved the origin itself to that 140 address. However, the server's one TLS certificate is still required 141 to contain the name of each origin in question. 143 [I-D.ietf-httpbis-origin-frame] relaxes the requirement to perform 144 the DNS lookup if already connected to a server with an appropriate 145 certificate which claims support for a particular origin. 147 Servers which host many origins often would prefer to have separate 148 certificates for some sets of origins. This may be for ease of 149 certificate management (the ability to separately revoke or renew 150 them), due to different sources of certificates (a CDN acting on 151 behalf of multiple origins), or other factors which might drive this 152 administrative decision. Clients connecting to such origins cannot 153 currently reuse connections, even if both client and server would 154 prefer to do so. 156 Because the TLS SNI extension is exchanged in the clear, clients 157 might also prefer to retrieve certificates inside the encrypted 158 context. When this information is sensitive, it might be 159 advantageous to request a general-purpose certificate or anonymous 160 ciphersuite at the TLS layer, while acquiring the "real" certificate 161 in HTTP after the connection is established. 163 1.2. Client Certificate Authentication 165 For servers that wish to use client certificates to authenticate 166 users, they might request client authentication during or immediately 167 after the TLS handshake. However, if not all users or resources need 168 certificate-based authentication, a request for a certificate has the 169 unfortunate consequence of triggering the client to seek a 170 certificate, possibly requiring user interaction, network traffic, or 171 other time-consuming activities. During this time, the connection is 172 stalled in many implementations. Such a request can result in a poor 173 experience, particularly when sent to a client that does not expect 174 the request. 176 The TLS 1.3 CertificateRequest can be used by servers to give clients 177 hints about which certificate to offer. Servers that rely on 178 certificate-based authentication might request different certificates 179 for different resources. Such a server cannot use contextual 180 information about the resource to construct an appropriate TLS 181 CertificateRequest message during the initial handshake. 183 Consequently, client certificates are requested at connection 184 establishment time only in cases where all clients are expected or 185 required to have a single certificate that is used for all resources. 186 Many other uses for client certificates are reactive, that is, 187 certificates are requested in response to the client making a 188 request. 190 1.2.1. HTTP/1.1 using TLS 1.2 and previous 192 In HTTP/1.1, a server that relies on client authentication for a 193 subset of users or resources does not request a certificate when the 194 connection is established. Instead, it only requests a client 195 certificate when a request is made to a resource that requires a 196 certificate. TLS 1.2 [RFC5246] accomodates this by permitting the 197 server to request a new TLS handshake, in which the server will 198 request the client's certificate. 200 Figure 1 shows the server initiating a TLS-layer renegotiation in 201 response to receiving an HTTP/1.1 request to a protected resource. 203 Client Server 204 -- (HTTP) GET /protected -------------------> *1 205 <---------------------- (TLS) HelloRequest -- *2 206 -- (TLS) ClientHello -----------------------> 207 <------------------ (TLS) ServerHello, ... -- 208 <---------------- (TLS) CertificateRequest -- *3 209 -- (TLS) ..., Certificate ------------------> *4 210 -- (TLS) Finished --------------------------> 211 <-------------------------- (TLS) Finished -- 212 <--------------------------- (HTTP) 200 OK -- *5 214 Figure 1: HTTP/1.1 Reactive Certificate Authentication with TLS 1.2 216 In this example, the server receives a request for a protected 217 resource (at *1 on Figure 1). Upon performing an authorization 218 check, the server determines that the request requires authentication 219 using a client certificate and that no such certificate has been 220 provided. 222 The server initiates TLS renegotiation by sending a TLS HelloRequest 223 (at *2). The client then initiates a TLS handshake. Note that some 224 TLS messages are elided from the figure for the sake of brevity. 226 The critical messages for this example are the server requesting a 227 certificate with a TLS CertificateRequest (*3); this request might 228 use information about the request or resource. The client then 229 provides a certificate and proof of possession of the private key in 230 Certificate and CertificateVerify messages (*4). 232 When the handshake completes, the server performs any authorization 233 checks a second time. With the client certificate available, it then 234 authorizes the request and provides a response (*5). 236 1.2.2. HTTP/1.1 using TLS 1.3 238 TLS 1.3 [I-D.ietf-tls-tls13] introduces a new client authentication 239 mechanism that allows for clients to authenticate after the handshake 240 has been completed. For the purposes of authenticating an HTTP 241 request, this is functionally equivalent to renegotiation. Figure 2 242 shows the simpler exchange this enables. 244 Client Server 245 -- (HTTP) GET /protected -------------------> 246 <---------------- (TLS) CertificateRequest -- 247 -- (TLS) Certificate, CertificateVerify, 248 Finished -----------------------> 249 <--------------------------- (HTTP) 200 OK -- 251 Figure 2: HTTP/1.1 Reactive Certificate Authentication with TLS 1.3 253 TLS 1.3 does not support renegotiation, instead supporting direct 254 client authentication. In contrast to the TLS 1.2 example, in TLS 255 1.3, a server can simply request a certificate. 257 1.2.3. HTTP/2 259 An important part of the HTTP/1.1 exchange is that the client is able 260 to easily identify the request that caused the TLS renegotiation. 261 The client is able to assume that the next unanswered request on the 262 connection is responsible. The HTTP stack in the client is then able 263 to direct the certificate request to the application or component 264 that initiated that request. This ensures that the application has 265 the right contextual information for processing the request. 267 In HTTP/2, a client can have multiple outstanding requests. Without 268 some sort of correlation information, a client is unable to identify 269 which request caused the server to request a certificate. 271 Thus, the minimum necessary mechanism to support reactive certificate 272 authentication in HTTP/2 is an identifier that can be use to 273 correlate an HTTP request with a request for a certificate. Since 274 streams are used for individual requests, correlation with a stream 275 is sufficient. 277 [RFC7540] prohibits renegotiation after any application data has been 278 sent. This completely blocks reactive certificate authentication in 279 HTTP/2 using TLS 1.2. If this restriction were relaxed by an 280 extension or update to HTTP/2, such an identifier could be added to 281 TLS 1.2 by means of an extension to TLS. Unfortunately, many TLS 1.2 282 implementations do not permit application data to continue during a 283 renegotiation. This is problematic for a multiplexed protocol like 284 HTTP/2. 286 1.3. HTTP-Layer Certificate Authentication 288 This draft defines HTTP/2 frames to carry the relevant certificate 289 messages, enabling certificate-based authentication of both clients 290 and servers independent of TLS version. This mechanism can be 291 implemented at the HTTP layer without breaking the existing interface 292 between HTTP and applications above it. 294 This could be done in a naive manner by replicating the TLS messages 295 as HTTP/2 frames on each stream. However, this would create needless 296 redundancy between streams and require frequent expensive signing 297 operations. Instead, TLS Exported Authenticators 298 [I-D.ietf-tls-exported-authenticator] are exchanged on stream zero 299 and the on-stream frames incorporate them by reference as needed. 301 TLS Exported Authenticators are structured messages that can be 302 exported by either party of a TLS connection and validated by the 303 other party. An authenticator message can be constructed by either 304 the client or the server given an established TLS connection, a 305 certificate, and a corresponding private key. Exported 306 Authenticators use the message structures from section 4.4 of 307 [I-D.ietf-tls-tls13], but different parameters. 309 Each Authenticator is computed using a Handshake Context and Finished 310 MAC Key derived from the TLS session. The Handshake Context is 311 identical for both parties of the TLS connection, while the Finished 312 MAC Key is dependent on whether the Authenticator is created by the 313 client or the server. 315 Successfully verified Authenticators result in certificate chains, 316 with verified possession of the corresponding private key, which can 317 be supplied into a collection of available certificates. Likewise, 318 descriptions of desired certificates can be supplied into these 319 collections. These pre-supplied elements are then available for 320 automatic use (in some situations) or for reference by individual 321 streams. 323 Section 2 describes how the feature is employed, defining means to 324 detect support in peers (Section 2.1), make certificates and requests 325 available (Section 2.2), and indicate when streams are blocked 326 waiting on an appropriate certificate (Section 2.3). Section 3 327 defines the required frame types, which parallel the TLS 1.3 message 328 exchange. Finally, Section 4 defines new error types which can be 329 used to notify peers when the exchange has not been successful. 331 1.4. Terminology 333 RFC 2119 [RFC2119] defines the terms "MUST", "MUST NOT", "SHOULD" and 334 "MAY". 336 2. Discovering Additional Certificates at the HTTP/2 Layer 338 A certificate chain with proof of possession of the private key 339 corresponding to the end-entity certificate is sent as a single 340 "CERTIFICATE" frame (see Section 3.4) on stream zero. Once the 341 holder of a certificate has sent the chain and proof, this 342 certificate chain is cached by the recipient and available for future 343 use. If the certificate is marked as "AUTOMATIC_USE", the 344 certificate may be used by the recipient to authorize any current or 345 future request. Otherwise, the recipient requests the required 346 certificate on each stream, but the previously-supplied certificates 347 are available for reference without having to resend them. 349 Likewise, the details of a request are sent on stream zero and stored 350 by the recipient. These details will be referenced by subsequent 351 "CERTIFICATE_NEEDED" frames. 353 Data sent by each peer is correlated by the ID given in each frame. 354 This ID is unrelated to values used by the other peer, even if each 355 uses the same ID in certain cases. 357 2.1. Indicating support for HTTP-layer certificate authentication 359 Clients and servers that will accept requests for HTTP-layer 360 certificate authentication indicate this using the HTTP/2 361 "SETTINGS_HTTP_CERT_AUTH" (0xSETTING-TBD) setting. 363 The initial value for the "SETTINGS_HTTP_CERT_AUTH" setting is 0, 364 indicating that the peer does not support HTTP-layer certificate 365 authentication. If a peer does support HTTP-layer certificate 366 authentication, the value is 1. 368 2.2. Making certificates or requests available 370 When a peer has advertised support for HTTP-layer certificates as in 371 Section 2.1, either party can supply additional certificates into the 372 connection at any time. These certificates then become available for 373 the peer to consider when deciding whether a connection is suitable 374 to transport a particular request. 376 Available certificates which have the "AUTOMATIC_USE" flag set MAY be 377 used by the recipient without further notice. This means that 378 clients or servers which predict a certificate will be required could 379 pre-supply the certificate without being asked. Regardless of 380 whether "AUTOMATIC_USE" is set, these certificates are available for 381 reference by future "USE_CERTIFICATE" frames. 383 Client Server 384 <-------- (stream 0) CERTIFICATE (AU flag) -- 385 ... 386 -- (stream N) GET /from-new-origin ---------> 387 <----------------------- (stream N) 200 OK -- 389 Figure 3: Proactive Server Certificate 391 Client Server 392 -- (stream 0) CERTIFICATE (AU flag) --------> 393 -- (streams 1,3) GET /protected ------------> 394 <-------------------- (streams 1,3) 200 OK -- 396 Figure 4: Proactive Client Certificate 398 Likewise, either party can supply a "CERTIFICATE_REQUEST" that 399 outlines parameters of a certificate they might request in the 400 future. It is important to note that this does not currently request 401 such a certificate, but makes the contents of the request available 402 for reference by a future "CERTIFICATE_NEEDED" frame. 404 2.3. Requiring certificate authentication 406 As defined in [RFC7540], when a client finds that a https:// origin 407 (or Alternative Service [RFC7838]) to which it needs to make a 408 request has the same IP address as a server to which it is already 409 connected, it MAY check whether the TLS certificate provided contains 410 the new origin as well, and if so, reuse the connection. 412 If the TLS certificate does not contain the new origin, but the 413 server has claimed support for that origin (with an ORIGIN frame, see 414 [I-D.ietf-httpbis-origin-frame]) and advertised support for HTTP- 415 layer certificates (see Section 2.1), it MAY send a 416 "CERTIFICATE_NEEDED" frame on the stream it will use to make the 417 request. (If the request parameters have not already been made 418 available using a "CERTIFICATE_REQUEST" frame, the client will need 419 to send the "CERTIFICATE_REQUEST" in order to generate the 420 "CERTIFICATE_NEEDED" frame.) The stream represents a pending request 421 to that origin which is blocked until a valid certificate is 422 processed. 424 The request is blocked until the server has responded with a 425 "USE_CERTIFICATE" frame pointing to a certificate for that origin. 426 If the certificate is already available, the server SHOULD 427 immediately respond with the appropriate "USE_CERTIFICATE" frame. 428 (If the certificate has not already been transmitted, the server will 429 need to make the certificate available as described in Section 2.2 430 before completing the exchange.) 432 If the server does not have the desired certificate, it MUST respond 433 with an empty "USE_CERTIFICATE" frame. In this case, or if the 434 server has not advertised support for HTTP-layer certificates, the 435 client MUST NOT send any requests for resources in that origin on the 436 current connection. 438 Client Server 439 <----------------------- (stream 0) ORIGIN -- 440 -- (stream 0) CERTIFICATE_REQUEST ----------> 441 ... 442 -- (stream N) CERTIFICATE_NEEDED -----------> 443 <------------------ (stream 0) CERTIFICATE -- 444 <-------------- (stream N) USE_CERTIFICATE -- 445 -- (stream N) GET /from-new-origin ---------> 446 <----------------------- (stream N) 200 OK -- 448 Figure 5: Client-Requested Certificate 450 Likewise, on each stream where certificate authentication is 451 required, the server sends a "CERTIFICATE_NEEDED" frame, which the 452 client answers with a "USE_CERTIFICATE" frame indicating the 453 certificate to use. If the request parameters or the responding 454 certificate are not already available, they will need to be sent as 455 described in Section 2.2 as part of this exchange. 457 Client Server 458 <---------- (stream 0) CERTIFICATE_REQUEST -- 459 ... 460 -- (stream N) GET /protected ---------------> 461 <----------- (stream N) CERTIFICATE_NEEDED -- 462 -- (stream 0) CERTIFICATE ------------------> 463 -- (stream N) USE_CERTIFICATE --------------> 464 <----------------------- (stream N) 200 OK -- 466 Figure 6: Reactive Certificate Authentication 468 A server SHOULD provide certificates for an origin before pushing 469 resources from it or supplying content referencing the origin. If a 470 client receives a "PUSH_PROMISE" referencing an origin for which it 471 has not yet received the server's certificate, the client MUST verify 472 the server's possession of an appropriate certificate by sending a 473 "CERTIFICATE_NEEDED" frame on the pushed stream to inform the server 474 that progress is blocked until the request is satisfied. The client 475 MUST NOT use the pushed resource until an appropriate certificate has 476 been received and validated. 478 3. Certificates Frames for HTTP/2 480 The "CERTIFICATE_REQUEST" and "CERTIFICATE_NEEDED" frames are 481 correlated by their "Request-ID" field. Subsequent 482 "CERTIFICATE_NEEDED" frames with the same "Request-ID" value MAY be 483 sent on other streams where the sender is expecting a certificate 484 with the same parameters. 486 The "CERTIFICATE", and "USE_CERTIFICATE" frames are correlated by 487 their "Cert-ID" field. Subsequent "USE_CERTIFICATE" frames with the 488 same "Cert-ID" MAY be sent in response to other "CERTIFICATE_NEEDED" 489 frames and refer to the same certificate. 491 "Request-ID" and "Cert-ID" are sender-local, and the use of the same 492 value by the other peer does not imply any correlation between their 493 frames. These values MUST be unique per sender over the lifetime of 494 the connection. 496 3.1. The CERTIFICATE_NEEDED frame 498 The "CERTIFICATE_NEEDED" frame (0xFRAME-TBD1) is sent to indicate 499 that the HTTP request on the current stream is blocked pending 500 certificate authentication. The frame includes a request identifier 501 which can be used to correlate the stream with a previous 502 "CERTIFICATE_REQUEST" frame sent on stream zero. The 503 "CERTIFICATE_REQUEST" describes the certificate the sender requires 504 to make progress on the stream in question. 506 The "CERTIFICATE_NEEDED" frame contains 2 octets, which is the 507 authentication request identifier, "Request-ID". A peer that 508 receives a "CERTIFICATE_NEEDED" of any other length MUST treat this 509 as a stream error of type "PROTOCOL_ERROR". Frames with identical 510 request identifiers refer to the same "CERTIFICATE_REQUEST". 512 A server MAY send multiple "CERTIFICATE_NEEDED" frames on the same 513 stream. If a server requires that a client provide multiple 514 certificates before authorizing a single request, each required 515 certificate MUST be indicated with a separate "CERTIFICATE_NEEDED" 516 frame, each of which MUST have a different request identifier 517 (referencing different "CERTIFICATE_REQUEST" frames describing each 518 required certificate). To reduce the risk of client confusion, 519 servers SHOULD NOT have multiple outstanding "CERTIFICATE_NEEDED" 520 frames on the same stream at any given time. 522 Clients MUST NOT send multiple "CERTIFICATE_NEEDED" frames on the 523 same stream. 525 The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a peer which has 526 not advertised support for HTTP-layer certificate authentication. 528 The "CERTIFICATE_NEEDED" frame MUST NOT be sent on stream zero, and 529 MUST NOT be sent on a stream in the "half-closed (local)" state 530 [RFC7540]. A client that receives a "CERTIFICATE_NEEDED" frame on a 531 stream which is not in a valid state SHOULD treat this as a stream 532 error of type "PROTOCOL_ERROR". 534 3.2. The USE_CERTIFICATE Frame 536 The "USE_CERTIFICATE" frame (0xFRAME-TBD4) is sent in response to a 537 "CERTIFICATE_NEEDED" frame to indicate which certificate is being 538 used to satisfy the requirement. 540 A "USE_CERTIFICATE" frame with no payload refers to the certificate 541 provided at the TLS layer, if any. If no certificate was provided at 542 the TLS layer, the stream should be processed with no authentication, 543 likely returning an authentication-related error at the HTTP level 544 (e.g. 403) for servers or routing the request to a new connection for 545 clients. 547 Otherwise, the "USE_CERTIFICATE" frame contains the two-octet "Cert- 548 ID" of the certificate the sender wishes to use. This MUST be the ID 549 of a certificate for which proof of possession has been presented in 550 a "CERTIFICATE" frame. Recipients of a "USE_CERTIFICATE" frame of 551 any other length MUST treat this as a stream error of type 552 "PROTOCOL_ERROR". Frames with identical certificate identifiers 553 refer to the same certificate chain. 555 The "USE_CERTIFICATE" frame MUST NOT be sent on stream zero or a 556 stream on which a "CERTIFICATE_NEEDED" frame has not been received. 557 Receipt of a "USE_CERTIFICATE" frame in these circumstances SHOULD be 558 treated as a stream error of type "PROTOCOL_ERROR". Each 559 "USE_CERTIFICATE" frame should reference a preceding "CERTIFICATE" 560 frame. Receipt of a "USE_CERTIFICATE" frame before the necessary 561 frames have been received on stream zero MUST also result in a stream 562 error of type "PROTOCOL_ERROR". 564 The referenced certificate chain MUST conform to the requirements 565 expressed in the "CERTIFICATE_REQUEST" to the best of the sender's 566 ability. Specifically, if the "CERTIFICATE_REQUEST" contained a non- 567 empty "Cert-Extensions" element, the end-entity certificate MUST 568 match with regard to the extensions recognized by the sender. 570 If these requirements are not satisfied, the recipient MAY at its 571 discretion either return an error at the HTTP semantic layer, or 572 respond with a stream error [RFC7540] on any stream where the 573 certificate is used. Section 4 defines certificate-related error 574 codes which might be applicable. 576 3.3. The CERTIFICATE_REQUEST Frame 578 TLS 1.3 defines the "CertificateRequest" message, which prompts the 579 client to provide a certificate which conforms to certain properties 580 specified by the server. This draft defines the 581 "CERTIFICATE_REQUEST" frame (0xFRAME-TBD2), which uses the same set 582 of extensions to specify a desired certificate, but can be sent over 583 any TLS version and can be sent by either peer. 585 The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a peer which 586 has not advertised support for HTTP-layer certificate authentication. 588 The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero. A 589 "CERTIFICATE_REQUEST" frame received on any other stream MUST be 590 rejected with a stream error of type "PROTOCOL_ERROR". 592 0 1 2 3 593 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 594 +-------------------------------+-------------------------------+ 595 | Request-ID (16) | Extension-Count (16) | 596 +-------------------------------+-------------------------------+ 597 | Extensions(?) ... 598 +---------------------------------------------------------------+ 600 Figure 7: CERTIFICATE_REQUEST frame payload 602 The frame contains the following fields: 604 Request-ID: "Request-ID" is a 16-bit opaque identifier used to 605 correlate subsequent certificate-related frames with this request. 606 The identifier MUST be unique in the session for the sender. 608 Extension-Count and Extensions: A list of certificate selection 609 criteria, represented in a series of "Extension" structures (see 610 [I-D.ietf-tls-tls13] section 4.2). This criteria MUST be used in 611 certificate selection as described in [I-D.ietf-tls-tls13]. The 612 number of "Extension" structures is given by the 16-bit 613 "Extension-Count" field, which MAY be zero. 615 Some extensions used for certificate selection allow multiple values 616 (e.g. oid_filters on Extended Key Usage). If the sender has 617 included a non-empty Extensions list, the certificate MUST match all 618 criteria specified by extensions the recipient recognizes. However, 619 the recipient MUST ignore and skip any unrecognized certificate 620 selection extensions. 622 Servers MUST be able to recognize the "server_name" extension 623 ([RFC6066]) at a minimum. Clients MUST always specify the desired 624 origin using this extension, though other extensions MAY also be 625 included. 627 3.4. The CERTIFICATE Frame 629 The "CERTIFICATE" frame (id=0xFRAME-TBD3) provides a exported 630 authenticator message from the TLS layer that provides a chain of 631 certificates, associated extensions and proves possession of the 632 private key corresponding to the end-entity certificate. 634 The "CERTIFICATE" frame defines two flags: 636 AUTOMATIC_USE (0x01): Indicates that the certificate can be used 637 automatically on future requests. 639 TO_BE_CONTINUED (0x02): Indicates that the exported authenticator 640 spans more than one frame. 642 0 1 2 3 643 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 644 +-------------------------------+-------------------------------+ 645 | Cert-ID (16) | Authenticator Fragment (*)... 646 +---------------------------------------------------------------+ 648 Figure 8: CERTIFICATE frame payload 650 The "Exported Authenticator Fragment" field contains a portion of the 651 opaque data returned from the TLS connection exported authenticator 652 "authenticate" API. See Section 3.4.1 for more details on the input 653 to this API. 655 This opaque data is transported in zero or more "CERTIFICATE" frames 656 with the "TO_BE_CONTINUED" flag set, followed by one "CERTIFICATE" 657 frame with the "TO_BE_CONTINUED" flag unset. Each of these frames 658 contains the same "Cert-ID" field, permitting them to be associated 659 with each other. Receipt of any "CERTIFICATE" frame with the same 660 "Cert-ID" following the receipt of a "CERTIFICATE" frame with 661 "TO_BE_CONTINUED" unset MUST be treated as a connection error of type 662 "PROTOCOL_ERROR". 664 If the "AUTOMATIC_USE" flag is set, the recipient MAY omit sending 665 "CERTIFICATE_NEEDED" frames on future streams which would require a 666 similar certificate and use the referenced certificate for 667 authentication without further notice to the holder. This behavior 668 is optional, and receipt of a "CERTIFICATE_NEEDED" frame does not 669 imply that previously-presented certificates were unacceptable, even 670 if "AUTOMATIC_USE" was set. Servers MUST set the "AUTOMATIC_USE" 671 flag when sending a "CERTIFICATE" frame. A server MUST NOT send 672 certificates for origins which it is not prepared to service on the 673 current connection. 675 Upon receiving a complete series of "CERTIFICATE" frames, the 676 receiver may validate the Exported Authenticator value by using the 677 exported authenticator API. This returns either an error indicating 678 that the message was invalid, or the certificate chain and extensions 679 used to create the message. 681 The "CERTIFICATE" frame MUST be sent on stream zero. A "CERTIFICATE" 682 frame received on any other stream MUST be rejected with a stream 683 error of type "PROTOCOL_ERROR". 685 3.4.1. Exported Authenticator Characteristics 687 The Exported Authenticator API defined in 688 [I-D.ietf-tls-exported-authenticator] takes as input a certificate, 689 supporting information about the certificate (OCSP, SCT, etc.), and 690 an optional "certificate_request_context". When generating exported 691 authenticators for use with this extension, the 692 "certificate_request_context" MUST be the two-octet Cert-ID. 694 Upon receipt of a completed authenticator, an endpoint MUST check 695 that: 697 o the "validate" API confirms the validity of the authenticator 698 itself 700 o the "certificate_request_context" matches the Cert-ID of the 701 frame(s) in which it was received 703 Once the authenticator is accepted, the endpoint can perform any 704 other checks for the acceptability of the certificate itself. 706 4. Indicating failures during HTTP-Layer Certificate Authentication 708 Because this draft permits certificates to be exchanged at the HTTP 709 framing layer instead of the TLS layer, several certificate-related 710 errors which are defined at the TLS layer might now occur at the HTTP 711 framing layer. In this section, those errors are restated and added 712 to the HTTP/2 error code registry. 714 BAD_CERTIFICATE (0xERROR-TBD1): A certificate was corrupt, contained 715 signatures that did not verify correctly, etc. 717 UNSUPPORTED_CERTIFICATE (0xERROR-TBD2): A certificate was of an 718 unsupported type or did not contain required extensions 720 CERTIFICATE_REVOKED (0xERROR-TBD3): A certificate was revoked by its 721 signer 723 CERTIFICATE_EXPIRED (0xERROR-TBD4): A certificate has expired or is 724 not currently valid 726 CERTIFICATE_GENERAL (0xERROR-TBD5): Any other certificate-related 727 error 729 As described in [RFC7540], implementations MAY choose to treat a 730 stream error as a connection error at any time. Of particular note, 731 a stream error cannot occur on stream 0, which means that 732 implementations cannot send non-session errors in response to 733 "CERTIFICATE_REQUEST", and "CERTIFICATE" frames. Implementations 734 which do not wish to terminate the connection MAY either send 735 relevant errors on any stream which references the failing 736 certificate in question or process the requests as unauthenticated 737 and provide error information at the HTTP semantic layer. 739 5. Security Considerations 741 This mechanism defines an alternate way to obtain server and client 742 certificates other than in the initial TLS handshake. While the 743 signature of exported authenticator values is expected to be equally 744 secure, it is important to recognize that a vulnerability in this 745 code path is at least equal to a vulnerability in the TLS handshake. 747 5.1. Impersonation 749 This mechanism could increase the impact of a key compromise. Rather 750 than needing to subvert DNS or IP routing in order to use a 751 compromised certificate, a malicious server now only needs a client 752 to connect to _some_ HTTPS site under its control in order to present 753 the compromised certificate. As recommended in 754 [I-D.ietf-httpbis-origin-frame], clients opting not to consult DNS 755 ought to employ some alternative means to increase confidence that 756 the certificate is legitimate. 758 As noted in the Security Considerations of 759 [I-D.ietf-tls-exported-authenticator], it difficult to formally prove 760 that an endpoint is jointly authoritative over multiple certificates, 761 rather than individually authoritative on each certificate. As a 762 result, clients MUST NOT assume that because one origin was 763 previously colocated with another, those origins will be reachable 764 via the same endpoints in the future. Clients MUST NOT consider 765 previous secondary certificates to be validated after TLS session 766 resumption. However, clients MAY proactively query for previously- 767 presented secondary certificates. 769 5.2. Fingerprinting 771 This draft defines a mechanism which could be used to probe servers 772 for origins they support, but opens no new attack versus making 773 repeat TLS connections with different SNI values. Servers SHOULD 774 impose similar denial-of-service mitigations (e.g. request rate 775 limits) to "CERTIFICATE_REQUEST" frames as to new TLS connections. 777 While the extensions in the "CERTIFICATE_REQUEST" frame permit the 778 sender to enumerate the acceptable Certificate Authorities for the 779 requested certificate, it might not be prudent (either for security 780 or data consumption) to include the full list of trusted Certificate 781 Authorities in every request. Senders, particularly clients, SHOULD 782 send only the extensions that narrowly specify which certificates 783 would be acceptable. 785 5.3. Denial of Service 787 Failure to provide a certificate on a stream after receiving 788 "CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to 789 standard timeouts used to guard against unresponsive peers. 791 Validating a multitude of signatures can be computationally 792 expensive, while generating an invalid signature is computationally 793 cheap. Implementations will require checks for attacks from this 794 direction. Invalid exported authenticators SHOULD be treated as a 795 session error, to avoid further attacks from the peer, though an 796 implementation MAY instead disable HTTP-layer certificates for the 797 current connection instead. 799 5.4. Confusion About State 801 Implementations need to be aware of the potential for confusion about 802 the state of a connection. The presence or absence of a validated 803 certificate can change during the processing of a request, 804 potentially multiple times, as "USE_CERTIFICATE" frames are received. 805 A server that uses certificate authentication needs to be prepared to 806 reevaluate the authorization state of a request as the set of 807 certificates changes. 809 Client implementations need to carefully consider the impact of 810 setting the "AUTOMATIC_USE" flag. This flag is a performance 811 optimization, permitting the client to avoid a round-trip on each 812 request where the server checks for certificate authentication. 813 However, once this flag has been sent, the client has zero knowledge 814 about whether the server will use the referenced cert for any future 815 request, or even for an existing request which has not yet completed. 816 Clients MUST NOT set this flag on any certificate which is not 817 appropriate for currently-in-flight requests, and MUST NOT make any 818 future requests on the same connection which they are not willing to 819 have associated with the provided certificate. 821 6. IANA Considerations 823 This draft adds entries in three registries. 825 The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in 826 Section 6.1. Four frame types are registered in Section 6.2. Six 827 error codes are registered in Section 6.3. 829 6.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting 831 The SETTINGS_HTTP_CERT_AUTH setting is registered in the "HTTP/2 832 Settings" registry established in [RFC7540]. 834 Name: SETTINGS_HTTP_CERT_AUTH 836 Code: 0xSETTING-TBD 838 Initial Value: 0 840 Specification: This document. 842 6.2. New HTTP/2 Frames 844 Four new frame types are registered in the "HTTP/2 Frame Types" 845 registry established in [RFC7540]. The entries in the following 846 table are registered by this document. 848 +---------------------+--------------+---------------+ 849 | Frame Type | Code | Specification | 850 +---------------------+--------------+---------------+ 851 | CERTIFICATE_NEEDED | 0xFRAME-TBD1 | Section 3.1 | 852 | | | | 853 | CERTIFICATE_REQUEST | 0xFRAME-TBD2 | Section 3.3 | 854 | | | | 855 | CERTIFICATE | 0xFRAME-TBD3 | Section 3.4 | 856 | | | | 857 | USE_CERTIFICATE | 0xFRAME-TBD4 | Section 3.2 | 858 +---------------------+--------------+---------------+ 860 6.3. New HTTP/2 Error Codes 862 Five new error codes are registered in the "HTTP/2 Error Code" 863 registry established in [RFC7540]. The entries in the following 864 table are registered by this document. 866 +-------------------------+--------------+---------------+ 867 | Name | Code | Specification | 868 +-------------------------+--------------+---------------+ 869 | BAD_CERTIFICATE | 0xERROR-TBD1 | Section 4 | 870 | | | | 871 | UNSUPPORTED_CERTIFICATE | 0xERROR-TBD2 | Section 4 | 872 | | | | 873 | CERTIFICATE_REVOKED | 0xERROR-TBD3 | Section 4 | 874 | | | | 875 | CERTIFICATE_EXPIRED | 0xERROR-TBD4 | Section 4 | 876 | | | | 877 | CERTIFICATE_GENERAL | 0xERROR-TBD5 | Section 4 | 878 +-------------------------+--------------+---------------+ 880 7. Acknowledgements 882 Eric Rescorla pointed out several failings in an earlier revision. 883 Andrei Popov contributed to the TLS considerations. 885 A substantial portion of Mike's work on this draft was supported by 886 Microsoft during his employment there. 888 8. References 890 8.1. Normative References 892 [I-D.ietf-tls-exported-authenticator] 893 Sullivan, N., "Exported Authenticators in TLS", draft- 894 ietf-tls-exported-authenticator-04 (work in progress), 895 October 2017. 897 [I-D.ietf-tls-tls13] 898 Rescorla, E., "The Transport Layer Security (TLS) Protocol 899 Version 1.3", draft-ietf-tls-tls13-22 (work in progress), 900 November 2017. 902 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 903 Requirement Levels", BCP 14, RFC 2119, 904 DOI 10.17487/RFC2119, March 1997, 905 . 907 [RFC2459] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet 908 X.509 Public Key Infrastructure Certificate and CRL 909 Profile", RFC 2459, DOI 10.17487/RFC2459, January 1999, 910 . 912 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 913 (TLS) Protocol Version 1.2", RFC 5246, 914 DOI 10.17487/RFC5246, August 2008, 915 . 917 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 918 Housley, R., and W. Polk, "Internet X.509 Public Key 919 Infrastructure Certificate and Certificate Revocation List 920 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 921 . 923 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 924 Extensions: Extension Definitions", RFC 6066, 925 DOI 10.17487/RFC6066, January 2011, 926 . 928 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 929 Protocol (HTTP/1.1): Message Syntax and Routing", 930 RFC 7230, DOI 10.17487/RFC7230, June 2014, 931 . 933 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 934 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 935 DOI 10.17487/RFC7540, May 2015, 936 . 938 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 939 Specification of Basic Encoding Rules (BER), Canonical 940 Encoding Rules (CER) and Distinguished Encoding Rules 941 (DER)", ISO ISO/IEC 8825-1:2002, 2002, 942 . 945 8.2. Informative References 947 [I-D.ietf-httpbis-origin-frame] 948 Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", 949 draft-ietf-httpbis-origin-frame-04 (work in progress), 950 August 2017. 952 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 953 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 954 April 2016, . 956 Authors' Addresses 958 Mike Bishop 959 Akamai 961 Email: mbishop@evequefou.be 963 Nick Sullivan 964 Cloudflare 966 Email: nick@cloudflare.com 968 Martin Thomson 969 Mozilla 971 Email: martin.thomson@gmail.com