idnits 2.17.1 draft-bishop-httpbis-http2-additional-certs-03.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 ([RFC7540], [I-D.sullivan-tls-exported-authenticator], [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 (March 28, 2017) is 2587 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: 'RFC5705' is defined on line 923, but no explicit reference was found in the text == Unused Reference: 'RFC7627' is defined on line 937, but no explicit reference was found in the text == Unused Reference: 'FIPS-186-4' is defined on line 952, but no explicit reference was found in the text == Unused Reference: 'I-D.josefsson-eddsa-ed25519' is defined on line 958, but no explicit reference was found in the text == Unused Reference: 'RFC2560' is defined on line 966, but no explicit reference was found in the text == Unused Reference: 'RFC6962' is defined on line 972, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-19 ** 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' -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Hypertext Transfer Protocol M. Bishop 3 Internet-Draft Microsoft 4 Intended status: Standards Track N. Sullivan 5 Expires: September 29, 2017 Cloudflare 6 M. Thomson 7 Mozilla 8 March 28, 2017 10 Secondary Certificate Authentication in HTTP/2 11 draft-bishop-httpbis-http2-additional-certs-03 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.sullivan-tls-exported-authenticator] can be used to provide 35 proof of ownership of additional certificates to the HTTP layer to 36 support 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 http://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 September 29, 2017. 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 (http://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 . . . . . . . . . 4 76 1.2.2. HTTP/1.1 using TLS 1.3 . . . . . . . . . . . . . . . 5 77 1.2.3. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 6 78 1.3. HTTP-Layer Certificate Authentication . . . . . . . . . . 6 79 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 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 4. Indicating failures during HTTP-Layer Certificate 91 Authentication . . . . . . . . . . . . . . . . . . . . . . . 15 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 93 5.1. Impersonation . . . . . . . . . . . . . . . . . . . . . . 16 94 5.2. Fingerprinting . . . . . . . . . . . . . . . . . . . . . 17 95 5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 17 96 5.4. Confusion About State . . . . . . . . . . . . . . . . . . 18 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 98 6.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting . . . . . . . . . 18 99 6.2. New HTTP/2 Frames . . . . . . . . . . . . . . . . . . . . 18 100 6.3. New HTTP/2 Error Codes . . . . . . . . . . . . . . . . . 19 101 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 102 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 104 8.2. Informative References . . . . . . . . . . . . . . . . . 21 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 107 1. Introduction 109 HTTP clients need to know that the content they receive on a 110 connection comes from the origin that they intended to retrieve in 111 from. The traditional form of server authentication in HTTP has been 112 in the form of X.509 certificates provided during the TLS RFC5246 113 [I-D.ietf-tls-tls13] handshake. 115 Many existing HTTP [RFC7230] servers also have authentication 116 requirements for the resources they serve. Of the bountiful 117 authentication options available for authenticating HTTP requests, 118 client certificates present a unique challenge for resource-specific 119 authentication requirements because of the interaction with the 120 underlying TLS layer. 122 TLS 1.2 [RFC5246] supports one server and one client certificate on a 123 connection. These certificates may contain multiple identities, but 124 only one certificate may be provided. 126 1.1. Server Certificate Authentication 128 Section 9.1.1 of [RFC7540] describes how connections may be used to 129 make requests from multiple origins as long as the server is 130 authoritative for both. A server is considered authoritative for an 131 origin if DNS resolves the origin to the IP address of the server and 132 (for TLS) if the certificate presented by the server contains the 133 origin in the Subject Alternative Names field. 135 [RFC7838] enables a step of abstraction from the DNS resolution. If 136 both hosts have provided an Alternative Service at hostnames which 137 resolve to the IP address of the server, they are considered 138 authoritative just as if DNS resolved the origin itself to that 139 address. However, the server's one TLS certificate is still required 140 to contain the name of each origin in question. 142 Servers which host many origins often would prefer to have separate 143 certificates for some sets of origins. This may be for ease of 144 certificate management (the ability to separately revoke or renew 145 them), due to different sources of certificates (a CDN acting on 146 behalf of multiple origins), or other factors which might drive this 147 administrative decision. Clients connecting to such origins cannot 148 currently reuse connections, even if both client and server would 149 prefer to do so. 151 Because the TLS SNI extension is exchanged in the clear, clients 152 might also prefer to retrieve certificates inside the encrypted 153 context. When this information is sensitive, it might be 154 advantageous to request a general-purpose certificate or anonymous 155 ciphersuite at the TLS layer, while acquiring the "real" certificate 156 in HTTP after the connection is established. 158 1.2. Client Certificate Authentication 160 For servers that wish to use client certificates to authenticate 161 users, they might request client authentication during or immediately 162 after the TLS handshake. However, if not all users or resources need 163 certificate-based authentication, a request for a certificate has the 164 unfortunate consequence of triggering the client to seek a 165 certificate, possibly requiring user interaction, network traffic, or 166 other time-consuming activities. During this time, the connection is 167 stalled in many implementations. Such a request can result in a poor 168 experience, particularly when sent to a client that does not expect 169 the request. 171 The TLS 1.3 CertificateRequest can be used by servers to give clients 172 hints about which certificate to offer. Servers that rely on 173 certificate-based authentication might request different certificates 174 for different resources. Such a server cannot use contextual 175 information about the resource to construct an appropriate TLS 176 CertificateRequest message during the initial handshake. 178 Consequently, client certificates are requested at connection 179 establishment time only in cases where all clients are expected or 180 required to have a single certificate that is used for all resources. 181 Many other uses for client certificates are reactive, that is, 182 certificates are requested in response to the client making a 183 request. 185 1.2.1. HTTP/1.1 using TLS 1.2 and previous 187 In HTTP/1.1, a server that relies on client authentication for a 188 subset of users or resources does not request a certificate when the 189 connection is established. Instead, it only requests a client 190 certificate when a request is made to a resource that requires a 191 certificate. TLS 1.2 [RFC5246] accomodates this by permitting the 192 server to request a new TLS handshake, in which the server will 193 request the client's certificate. 195 Figure 1 shows the server initiating a TLS-layer renegotiation in 196 response to receiving an HTTP/1.1 request to a protected resource. 198 Client Server 199 -- (HTTP) GET /protected -------------------> *1 200 <---------------------- (TLS) HelloRequest -- *2 201 -- (TLS) ClientHello -----------------------> 202 <------------------ (TLS) ServerHello, ... -- 203 <---------------- (TLS) CertificateRequest -- *3 204 -- (TLS) ..., Certificate ------------------> *4 205 -- (TLS) Finished --------------------------> 206 <-------------------------- (TLS) Finished -- 207 <--------------------------- (HTTP) 200 OK -- *5 209 Figure 1: HTTP/1.1 Reactive Certificate Authentication with TLS 1.2 211 In this example, the server receives a request for a protected 212 resource (at *1 on Figure 1). Upon performing an authorization 213 check, the server determines that the request requires authentication 214 using a client certificate and that no such certificate has been 215 provided. 217 The server initiates TLS renegotiation by sending a TLS HelloRequest 218 (at *2). The client then initiates a TLS handshake. Note that some 219 TLS messages are elided from the figure for the sake of brevity. 221 The critical messages for this example are the server requesting a 222 certificate with a TLS CertificateRequest (*3); this request might 223 use information about the request or resource. The client then 224 provides a certificate and proof of possession of the private key in 225 Certificate and CertificateVerify messages (*4). 227 When the handshake completes, the server performs any authorization 228 checks a second time. With the client certificate available, it then 229 authorizes the request and provides a response (*5). 231 1.2.2. HTTP/1.1 using TLS 1.3 233 TLS 1.3 [I-D.ietf-tls-tls13] introduces a new client authentication 234 mechanism that allows for clients to authenticate after the handshake 235 has been completed. For the purposes of authenticating an HTTP 236 request, this is functionally equivalent to renegotiation. Figure 2 237 shows the simpler exchange this enables. 239 Client Server 240 -- (HTTP) GET /protected -------------------> 241 <---------------- (TLS) CertificateRequest -- 242 -- (TLS) Certificate, CertificateVerify, 243 Finished -----------------------> 244 <--------------------------- (HTTP) 200 OK -- 246 Figure 2: HTTP/1.1 Reactive Certificate Authentication with TLS 1.3 248 TLS 1.3 does not support renegotiation, instead supporting direct 249 client authentication. In contrast to the TLS 1.2 example, in TLS 250 1.3, a server can simply request a certificate. 252 1.2.3. HTTP/2 254 An important part of the HTTP/1.1 exchange is that the client is able 255 to easily identify the request that caused the TLS renegotiation. 256 The client is able to assume that the next unanswered request on the 257 connection is responsible. The HTTP stack in the client is then able 258 to direct the certificate request to the application or component 259 that initiated that request. This ensures that the application has 260 the right contextual information for processing the request. 262 In HTTP/2, a client can have multiple outstanding requests. Without 263 some sort of correlation information, a client is unable to identify 264 which request caused the server to request a certificate. 266 Thus, the minimum necessary mechanism to support reactive certificate 267 authentication in HTTP/2 is an identifier that can be use to 268 correlate an HTTP request with a request for a certificate. Since 269 streams are used for individual requests, correlation with a stream 270 is sufficient. 272 [RFC7540] prohibits renegotiation after any application data has been 273 sent. This completely blocks reactive certificate authentication in 274 HTTP/2 using TLS 1.2. If this restriction were relaxed by an 275 extension or update to HTTP/2, such an identifier could be added to 276 TLS 1.2 by means of an extension to TLS. Unfortunately, many TLS 1.2 277 implementations do not permit application data to continue during a 278 renegotiation. This is problematic for a multiplexed protocol like 279 HTTP/2. 281 1.3. HTTP-Layer Certificate Authentication 283 This draft defines HTTP/2 frames to carry the relevant certificate 284 messages, enabling certificate-based authentication of both clients 285 and servers independent of TLS version. This mechanism can be 286 implemented at the HTTP layer without breaking the existing interface 287 between HTTP and applications above it. 289 This could be done in a naive manner by replicating the TLS messages 290 as HTTP/2 frames on each stream. However, this would create needless 291 redundancy between streams and require frequent expensive signing 292 operations. Instead, TLS Exported Authenticators 293 [I-D.sullivan-tls-exported-authenticator] are exchanged on stream 294 zero and the on-stream frames incorporate them by reference as 295 needed. 297 TLS Exported Authenticators are structured messages that can be 298 exported by either party of a TLS connection and validated by the 299 other party. An authenticator message can be constructed by either 300 the client or the server given an established TLS connection, a 301 certificate, and a corresponding private key. Exported 302 Authenticators use the message structures from section 4.4 of 303 [I-D.ietf-tls-tls13], but different parameters. 305 Each Authenticator is computed using a Handshake Context and Finished 306 MAC Key derived from the TLS session. The Handshake Context is 307 identical for both parties of the TLS connection, while the Finished 308 MAC Key is dependent on whether the Authenticator is created by the 309 client or the server. 311 Successfully verified Authenticators result in certificate chains, 312 with verified possession of the corresponding private key, which can 313 be supplied into a collection of available certificates. Likewise, 314 descriptions of desired certificates can be supplied into these 315 collections. These pre-supplied elements are then available for 316 automatic use (in some situations) or for reference by individual 317 streams. 319 Section 2 describes how the feature is employed, defining means to 320 detect support in peers (Section 2.1), make certificates and requests 321 available (Section 2.2), and indicate when streams are blocked 322 waiting on an appropriate certificate (Section 2.3). Section 3 323 defines the required frame types, which parallel the TLS 1.3 message 324 exchange. Finally, Section 4 defines new error types which can be 325 used to notify peers when the exchange has not been successful. 327 1.4. Terminology 329 RFC 2119 [RFC2119] defines the terms "MUST", "MUST NOT", "SHOULD" and 330 "MAY". 332 2. Discovering Additional Certificates at the HTTP/2 Layer 334 A certificate chain with proof of possesion of the private key 335 corresponding to the end-entity certificate is sent as a single 336 "CERTIFICATE" frame (see Section 3.4) on stream zero. Once the 337 holder of a certificate has sent the chain and proof, this 338 certificate chain is cached by the recipient and available for future 339 use. If the certificate is marked as "AUTOMATIC_USE", the 340 certificate may be used by the recipient to authorize any current or 341 future request. Otherwise, the recipient requests the required 342 certificate on each stream, but the previously-supplied certificates 343 are available for reference without having to resend them. 345 Likewise, the details of a request are sent on stream zero and stored 346 by the recipient. These details will be referenced by subsequent 347 "CERTIFICATE_NEEDED" frames. 349 Data sent by each peer is correlated by the ID given in each frame. 350 This ID is unrelated to values used by the other peer, even if each 351 uses the same ID in certain cases. 353 2.1. Indicating support for HTTP-layer certificate authentication 355 Clients and servers that will accept requests for HTTP-layer 356 certificate authentication indicate this using the HTTP/2 357 "SETTINGS_HTTP_CERT_AUTH" (0xSETTING-TBD) setting. 359 The initial value for the "SETTINGS_HTTP_CERT_AUTH" setting is 0, 360 indicating that the peer does not support HTTP-layer certificate 361 authentication. If a peer does support HTTP-layer certificate 362 authentication, the value is 1. 364 2.2. Making certificates or requests available 366 When a peer has advertised support for HTTP-layer certificates as in 367 Section 2.1, either party can supply additional certificates into the 368 connection at any time. These certificates then become available for 369 the peer to consider when deciding whether a connection is suitable 370 to transport a particular request. 372 Available certificates which have the "AUTOMATIC_USE" flag set MAY be 373 used by the recipient without further notice. This means that 374 clients or servers which predict a certificate will be required could 375 pre-supply the certificate without being asked. Regardless of 376 whether "AUTOMATIC_USE" is set, these certificates are available for 377 reference by future "USE_CERTIFICATE" frames. 379 Client Server 380 <-------- (stream 0) CERTIFICATE (AU flag) -- 381 ... 382 -- (stream N) GET /from-new-origin ---------> 383 <----------------------- (stream N) 200 OK -- 385 Figure 3: Proactive Server Certificate 387 Client Server 388 -- (stream 0) CERTIFICATE (AU flag) --------> 389 -- (streams 1,3) GET /protected ------------> 390 <-------------------- (streams 1,3) 200 OK -- 392 Figure 4: Proactive Client Certificate 394 Likewise, either party can supply a "CERTIFICATE_REQUEST" that 395 outlines parameters of a certificate they might request in the 396 future. It is important to note that this does not currently request 397 such a certificate, but makes the contents of the request available 398 for reference by a future "CERTIFICATE_NEEDED" frame. 400 2.3. Requiring certificate authentication 402 As defined in [RFC7540], when a client finds that a https:// origin 403 (or Alternative Service [RFC7838]) to which it needs to make a 404 request has the same IP address as a server to which it is already 405 connected, it MAY check whether the TLS certificate provided contains 406 the new origin as well, and if so, reuse the connection. 408 If the TLS certificate does not contain the new origin, but the 409 server has advertised support for HTTP-layer certificates (see 410 Section 2.1), it MAY send a "CERTIFICATE_NEEDED" frame on the stream 411 it will use to make the request. (If the request parameters have not 412 already been made available using a "CERTIFICATE_REQUEST" frame, the 413 client will need to send the "CERTIFICATE_REQUEST" in order to 414 generate the "CERTIFICATE_NEEDED" frame.) The stream represents a 415 pending request to that origin which is blocked until a valid 416 certificate is processed. 418 The request is blocked until the server has responded with a 419 "USE_CERTIFICATE" frame pointing to a certificate for that origin. 420 If the certificate is already available, the server SHOULD 421 immediately respond with the appropriate "USE_CERTIFICATE" frame. 422 (If the certificate has not already been transmitted, the server will 423 need to make the certificate available as described in Section 2.2 424 before completing the exchange.) 425 If the server does not have the desired certificate or cannot produce 426 a signature compatible with the client's advertised settings, it MUST 427 respond with an empty "USE_CERTIFICATE" frame. In this case, or if 428 the server has not advertised support for HTTP-layer certificates, 429 the client MUST NOT send any requests for resources in that origin on 430 the current connection. 432 Client Server 433 -- (stream 0) CERTIFICATE_REQUEST ----------> 434 ... 435 -- (stream N) CERTIFICATE_NEEDED -----------> 436 <------------------ (stream 0) CERTIFICATE -- 437 <-------------- (stream N) USE_CERTIFICATE -- 438 -- (stream N) GET /from-new-origin ---------> 439 <----------------------- (stream N) 200 OK -- 441 Figure 5: Client-Requested Certificate 443 Likewise, on each stream where certificate authentication is 444 required, the server sends a "CERTIFICATE_NEEDED" frame, which the 445 client answers with a "USE_CERTIFICATE" frame indicating the 446 certificate to use. If the request parameters or the responding 447 certificate are not already available, they will need to be sent as 448 described in Section 2.2 as part of this exchange. 450 Client Server 451 <---------- (stream 0) CERTIFICATE_REQUEST -- 452 ... 453 -- (stream N) GET /protected ---------------> 454 <----------- (stream N) CERTIFICATE_NEEDED -- 455 -- (stream 0) CERTIFICATE ------------------> 456 -- (stream N) USE_CERTIFICATE --------------> 457 <----------------------- (stream N) 200 OK -- 459 Figure 6: Reactive Certificate Authentication 461 A server SHOULD provide certificates for an origin before pushing 462 resources from it. If a client receives a "PUSH_PROMISE" referencing 463 an origin for which it has not yet received the server's certificate, 464 the client MUST verify the server's possession of an appropriate 465 certificate by sending a "CERTIFICATE_NEEDED" frame on the pushed 466 stream to inform the server that progress is blocked until the 467 request is satisfied. The client MUST NOT use the pushed resource 468 until an appropriate certificate has been received and validated. 470 3. Certificates Frames for HTTP/2 472 The "CERTIFICATE_REQUEST" and "CERTIFICATE_NEEDED" frames are 473 correlated by their "Request-ID" field. Subsequent 474 "CERTIFICATE_NEEDED" frames with the same "Request-ID" value MAY be 475 sent on other streams where the sender is expecting a certificate 476 with the same parameters. 478 The "CERTIFICATE", and "USE_CERTIFICATE" frames are correlated by 479 their "Cert-ID" field. Subsequent "USE_CERTIFICATE" frames with the 480 same "Cert-ID" MAY be sent in response to other "CERTIFICATE_NEEDED" 481 frames and refer to the same certificate. 483 "Request-ID" and "Cert-ID" are sender-local, and the use of the same 484 value by the other peer does not imply any correlation between their 485 frames. 487 3.1. The CERTIFICATE_NEEDED frame 489 The "CERTIFICATE_NEEDED" frame (0xFRAME-TBD1) is sent to indicate 490 that the HTTP request on the current stream is blocked pending 491 certificate authentication. The frame includes a request identifier 492 which can be used to correlate the stream with a previous 493 "CERTIFICATE_REQUEST" frame sent on stream zero. The 494 "CERTIFICATE_REQUEST" describes the certificate the sender requires 495 to make progress on the stream in question. 497 The "CERTIFICATE_NEEDED" frame contains 1 octet, which is the 498 authentication request identifier, "Request-ID". A peer that 499 receives a "CERTIFICATE_NEEDED" of any other length MUST treat this 500 as a stream error of type "PROTOCOL_ERROR". Frames with identical 501 request identifiers refer to the same "CERTIFICATE_REQUEST". 503 A server MAY send multiple "CERTIFICATE_NEEDED" frames on the same 504 stream. If a server requires that a client provide multiple 505 certificates before authorizing a single request, each required 506 certificate MUST be indicated with a separate "CERTIFICATE_NEEDED" 507 frame, each of which MUST have a different request identifier 508 (referencing different "CERTIFICATE_REQUEST" frames describing each 509 required certificate). To reduce the risk of client confusion, 510 servers SHOULD NOT have multiple outstanding "CERTIFICATE_NEEDED" 511 frames on the same stream at any given time. 513 Clients MUST NOT send multiple "CERTIFICATE_NEEDED" frames on the 514 same stream. 516 The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a peer which has 517 not advertised support for HTTP-layer certificate authentication. 519 The "CERTIFICATE_NEEDED" frame MUST NOT be sent on stream zero, and 520 MUST NOT be sent on a stream in the "half-closed (local)" state 521 [RFC7540]. A client that receives a "CERTIFICATE_NEEDED" frame on a 522 stream which is not in a valid state SHOULD treat this as a stream 523 error of type "PROTOCOL_ERROR". 525 3.2. The USE_CERTIFICATE Frame 527 The "USE_CERTIFICATE" frame (0xFRAME-TBD4) is sent in response to a 528 "CERTIFICATE_NEEDED" frame to indicate which certificate is being 529 used to satisfy the requirement. 531 A "USE_CERTIFICATE" frame with no payload refers to the certificate 532 provided at the TLS layer, if any. If no certificate was provided at 533 the TLS layer, the stream should be processed with no authentication, 534 likely returning an authentication-related error at the HTTP level 535 (e.g. 403) for servers or routing the request to a new connection for 536 clients. 538 Otherwise, the "USE_CERTIFICATE" frame contains the "Cert-ID" of the 539 certificate the sender wishes to use. This MUST be the ID of a 540 certificate for which proof of possession has been presented in a 541 "CERTIFICATE" frame. Recipients of a "USE_CERTIFICATE" frame of any 542 other length MUST treat this as a stream error of type 543 "PROTOCOL_ERROR". Frames with identical certificate identifiers 544 refer to the same certificate chain. 546 The "USE_CERTIFICATE" frame MUST NOT be sent on stream zero or a 547 stream on which a "CERTIFICATE_NEEDED" frame has not been received. 548 Receipt of a "USE_CERTIFICATE" frame in these circmustances SHOULD be 549 treated as a stream error of type "PROTOCOL_ERROR". Each 550 "USE_CERTIFICATE" frame should reference a preceding "CERTIFICATE" 551 frame. Receipt of a "USE_CERTIFICATE" frame before the necessary 552 frames have been received on stream zero MUST also result in a stream 553 error of type "PROTOCOL_ERROR". 555 The referenced certificate chain MUST conform to the requirements 556 expressed in the "CERTIFICATE_REQUEST" to the best of the sender's 557 ability. Specifically: 559 o If the "CERTIFICATE_REQUEST" contained a non-empty "Certificate- 560 Authorities" element, one of the certificates in the chain SHOULD 561 be signed by one of the listed CAs. 563 o If the "CERTIFICATE_REQUEST" contained a non-empty "Cert- 564 Extensions" element, the end-entity certificate MUST match with 565 regard to the extension OIDs recognized by the sender. 567 If these requirements are not satisfied, the recipient MAY at its 568 discretion either return an error at the HTTP semantic layer, or 569 respond with a stream error [RFC7540] on any stream where the 570 certificate is used. Section 4 defines certificate-related error 571 codes which might be applicable. 573 3.3. The CERTIFICATE_REQUEST Frame 575 TLS 1.3 defines the "CertificateRequest" message, which prompts the 576 client to provide a certificate which conforms to certain properties 577 specified by the server. This draft defines the 578 "CERTIFICATE_REQUEST" frame (0xFRAME-TBD2), which contains the same 579 contents as a TLS 1.3 "CertificateRequest" message, but can be sent 580 over any TLS version. 582 The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a peer which 583 has not advertised support for HTTP-layer certificate authentication. 585 The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero. A 586 "CERTIFICATE_REQUEST" frame received on any other stream MUST be 587 rejected with a stream error of type "PROTOCOL_ERROR". 589 0 1 2 3 590 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 591 +-------------------------------+---------------+---------------+ 592 | Request-ID (8)| CA-Count (16) | 593 +-----------------------------------------------+---------------+ 594 | Certificate-Authorities (?) ... 595 +---------------------------------------------------------------+ 596 | Cert-Extension-Count (16) | Cert-Extensions(?) ... 597 +---------------------------------------------------------------+ 599 Figure 7: CERTIFICATE_REQUEST frame payload 601 The frame contains the following fields: 603 Request-ID: "Request-ID" is an 8-bit opaque identifier used to 604 correlate subsequent certificate-related frames with this request. 605 The identifier MUST be unique in the session for the sender. 607 CA-Count and Certificate-Authorities: "Certificate-Authorities" is a 608 series of distinguished names of acceptable certificate 609 authorities, represented in DER-encoded [X690] format. These 610 distinguished names may specify a desired distinguished name for a 611 root CA or for a subordinate CA; thus, this message can be used to 612 describe known roots as well as a desired authorization space. 613 The number of such structures is given by the 16-bit "CA-Count" 614 field, which MAY be zero. If the "CA-Count" field is zero, then 615 the recipient MAY send any certificate that meets the rest of the 616 selection criteria in the "CERTIFICATE_REQUEST", unless there is 617 some external arrangement to the contrary. 619 Cert-Extension-Count and Cert-Extensions: A list of certificate 620 extension OIDs [RFC5280] with their allowed values, represented in 621 a series of "CertificateExtension" structures (see 622 [I-D.ietf-tls-tls13] section 6.3.5). The list of OIDs MUST be 623 used in certificate selection as described in 624 [I-D.ietf-tls-tls13]. The number of Cert-Extension structures is 625 given by the 16-bit "Cert-Extension-Count" field, which MAY be 626 zero. 628 Some certificate extension OIDs allow multiple values (e.g. Extended 629 Key Usage). If the sender has included a non-empty Cert-Extensions 630 list, the certificate MUST contain all of the specified extension 631 OIDs that the recipient recognizes. For each extension OID 632 recognized by the recipient, all of the specified values MUST be 633 present in the certificate (but the certificate MAY have other values 634 as well). However, the recipient MUST ignore and skip any 635 unrecognized certificate extension OIDs. 637 Servers MUST be able to recognize the "subjectAltName" extension 638 ([RFC2459] section 4.2.1.7) at a minimum. Clients MUST always 639 specify the desired origin using this extension, though other 640 extensions MAY also be included. 642 PKIX RFCs define a variety of certificate extension OIDs and their 643 corresponding value types. Depending on the type, matching 644 certificate extension values are not necessarily bitwise-equal. It 645 is expected that implementations will rely on their PKI libraries to 646 perform certificate selection using these certificate extension OIDs. 648 3.4. The CERTIFICATE Frame 650 The "CERTIFICATE" frame (id=0xFRAME-TBD3) provides a exported 651 authenticator message ([I-D.sullivan-tls-exported-authenticator]) 652 from the TLS layer that provides a chain of certificates, associated 653 extensions and proves possession of the private key corresponding to 654 the end-entity certificate. 656 The "CERTIFICATE" frame defines one flag: 658 AUTOMATIC_USE (0x01): Indicates that the certificate can be used 659 automatically on future requests. 661 0 1 2 3 662 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 663 +-------------------------------+-------------------------------+ 664 | Cert-ID (8) | Exported Authenticator (*) ... 665 +---------------------------------------------------------------+ 667 Figure 8: CERTIFICATE frame payload 669 The "CERTIFICATE" frame (0xFRAME-TBD4) contains an "Exported 670 Authenticator" field which corresponds to the value returned from the 671 TLS connection exported authenticator API when provided with a 672 certificate, a valid certificate chain for the connection and 673 associated extensions (OCSP, SCT, etc.), and a connection-unique 674 8-byte certificate_request_context value. 676 If the "AUTOMATIC_USE" flag is set, the recipient MAY omit sending 677 "CERTIFICATE_NEEDED" frames on future streams which would require a 678 similar certificate and use the referenced certificate for 679 authentication without further notice to the holder. This behavior 680 is optional, and receipt of a "CERTIFICATE_NEEDED" frame does not 681 imply that previously-presented certificates were unacceptable, even 682 if "AUTOMATIC_USE" was set. Servers MUST set the "AUTOMATIC_USE" 683 flag when sending a "CERTIFICATE" frame. A server MUST NOT send 684 certificates for origins which it is not prepared to service on the 685 current connection. 687 Upon recieving a CERTIFICATE frame, the reciever may validate the 688 Exported Authenticator value by using the exported authenticator API. 689 This returns either an error indicating that the message was invalid, 690 or the certificate chain and extensions used to create the message. 692 It is possible that a large certificate chain might be too large to 693 fit in a single HTTP/2 frame (see [RFC7540] section 4.2). Senders 694 unable to transfer a requested certificate due to the recipient's 695 "SETTINGS_MAX_FRAME_SIZE" value SHOULD terminate affected streams 696 with "CERTIFICATE_TOO_LARGE". 698 The "CERTIFICATE" frame MUST be sent on stream zero. A "CERTIFICATE" 699 frame received on any other stream MUST be rejected with a stream 700 error of type "PROTOCOL_ERROR". 702 4. Indicating failures during HTTP-Layer Certificate Authentication 704 Because this draft permits certificates to be exchanged at the HTTP 705 framing layer instead of the TLS layer, several certificate-related 706 errors which are defined at the TLS layer might now occur at the HTTP 707 framing layer. In this section, those errors are restated and added 708 to the HTTP/2 error code registry. 710 BAD_CERTIFICATE (0xERROR-TBD1): A certificate was corrupt, contained 711 signatures that did not verify correctly, etc. 713 UNSUPPORTED_CERTIFICATE (0xERROR-TBD2): A certificate was of an 714 unsupported type or did not contain required extensions 716 CERTIFICATE_REVOKED (0xERROR-TBD3): A certificate was revoked by its 717 signer 719 CERTIFICATE_EXPIRED (0xERROR-TBD4): A certificate has expired or is 720 not currently valid 722 CERTIFICATE_TOO_LARGE (0xERROR-TBD5): The certificate cannot be 723 transferred due to the recipient's "SETTINGS_MAX_FRAME_SIZE" 725 CERTIFICATE_GENERAL (0xERROR-TBD6): Any other certificate-related 726 error 728 As described in [RFC7540], implementations MAY choose to treat a 729 stream error as a connection error at any time. Of particular note, 730 a stream error cannot occur on stream 0, which means that 731 implementations cannot send non-session errors in response to 732 "CERTIFICATE_REQUEST", and "CERTIFICATE" frames. Implementations 733 which do not wish to terminate the connection MAY either send 734 relevant errors on any stream which references the failing 735 certificate in question or process the requests as unauthenticated 736 and provide error information at the HTTP semantic layer. 738 5. Security Considerations 740 This mechanism defines an alternate way to obtain server and client 741 certificates other than in the initial TLS handshake. While the 742 signature of exported authenticator values is expected to be equally 743 secure, it is important to recognize that a vulnerability in this 744 code path is at least equal to a vulnerability in the TLS handshake. 746 5.1. Impersonation 748 This mechanism could increase the impact of a key compromise. Rather 749 than needing to subvert DNS or IP routing in order to use a 750 compromised certificate, a malicious server now only needs a client 751 to connect to _some_ HTTPS site under its control in order to present 752 the compromised certificate. Clients MUST continue to validate that 753 the destination IP address is valid for the origin either by direct 754 DNS resolution or resolution of a validated Alternative Service. 755 (Future work could include a mechanism for a server to offer proofs.) 756 As noted in the Security Considerations of 757 [I-D.sullivan-tls-exported-authenticator], it difficult to formally 758 prove that an endpoint is jointly authoritative over multiple 759 certificates, rather than individually authoritative on each 760 certificate. As a result, clients MUST NOT assume that because one 761 origin was previously colocated with another, those origins will be 762 reachable via the same endpoints in the future. Clients MUST NOT 763 consider previous secondary certificates to be validated after TLS 764 session resumption. However, clients MAY query for previously- 765 presented secondary certificates after first repeating the validation 766 of the endpoint's IP address against fresh DNS and Alt-Svc 767 information. 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 "CERTIFICATE_REQUEST" frame permits the sender to enumerate 778 the acceptable Certificate Authorities for the requested certificate, 779 it might not be prudent (either for security or data consumption) to 780 include the full list of trusted Certificate Authorities in every 781 request. Senders, particularly clients, SHOULD send an empty 782 "Certificate-Authorities" element unless they are expecting a 783 certificate to be signed by a particular CA or one of a small set of 784 CAs. 786 5.3. Denial of Service 788 Failure to provide a certificate on a stream after receiving 789 "CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to 790 standard timeouts used to guard against unresponsive peers. 792 Validating a multitude of signatures can be computationally 793 expensive, while generating an invalid signature is computationally 794 cheap. Implementations will require checks for attacks from this 795 direction. Signature proofs SHOULD NOT be validated until a stream 796 requires the certificate to make progress. A signature which is not 797 valid based on the asserted public key SHOULD be treated as a session 798 error, to avoid further attacks from the peer, though an 799 implementation MAY instead disable HTTP-layer certificates for the 800 current connection instead. 802 5.4. Confusion About State 804 Implementations need to be aware of the potential for confusion about 805 the state of a connection. The presence or absence of a validated 806 certificate can change during the processing of a request, 807 potentially multiple times, as "USE_CERTIFICATE" frames are received. 808 A server that uses certificate authentication needs to be prepared to 809 reevaluate the authorization state of a request as the set of 810 certificates changes. 812 Client implementations need to carefully consider the impact of 813 setting the "AUTOMATIC_USE" flag. This flag is a performance 814 optimization, permitting the client to avoid a round-trip on each 815 request where the server checks for certificate authentication. 816 However, once this flag has been sent, the client has zero knowledge 817 about whether the server will use the referenced cert for any future 818 request, or even for an existing request which has not yet completed. 819 Clients MUST NOT set this flag on any certificate which is not 820 appropriate for currently-in-flight requests, and MUST NOT make any 821 future requests on the same connection which they are not willing to 822 have associated with the provided certificate. 824 6. IANA Considerations 826 This draft adds entries in three registries. 828 The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in 829 Section 6.1. Four frame types are registered in Section 6.2. Six 830 error codes are registered in Section 6.3. 832 6.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting 834 The SETTINGS_HTTP_CERT_AUTH setting is registered in the "HTTP/2 835 Settings" registry established in [RFC7540]. 837 Name: SETTINGS_HTTP_CERT_AUTH 839 Code: 0xSETTING-TBD 841 Initial Value: 0 843 Specification: This document. 845 6.2. New HTTP/2 Frames 847 Four new frame types are registered in the "HTTP/2 Frame Types" 848 registry established in [RFC7540]. The entries in the following 849 table are registered by this document. 851 +---------------------+--------------+---------------+ 852 | Frame Type | Code | Specification | 853 +---------------------+--------------+---------------+ 854 | CERTIFICATE_NEEDED | 0xFRAME-TBD1 | Section 3.1 | 855 | | | | 856 | CERTIFICATE_REQUEST | 0xFRAME-TBD2 | Section 3.3 | 857 | | | | 858 | CERTIFICATE | 0xFRAME-TBD3 | Section 3.4 | 859 | | | | 860 | USE_CERTIFICATE | 0xFRAME-TBD4 | Section 3.2 | 861 +---------------------+--------------+---------------+ 863 6.3. New HTTP/2 Error Codes 865 Five new error codes are registered in the "HTTP/2 Error Code" 866 registry established in [RFC7540]. The entries in the following 867 table are registered by this document. 869 +-------------------------+--------------+---------------+ 870 | Name | Code | Specification | 871 +-------------------------+--------------+---------------+ 872 | BAD_CERTIFICATE | 0xERROR-TBD1 | Section 4 | 873 | | | | 874 | UNSUPPORTED_CERTIFICATE | 0xERROR-TBD2 | Section 4 | 875 | | | | 876 | CERTIFICATE_REVOKED | 0xERROR-TBD3 | Section 4 | 877 | | | | 878 | CERTIFICATE_EXPIRED | 0xERROR-TBD4 | Section 4 | 879 | | | | 880 | CERTIFICATE_GENERAL | 0xERROR-TBD5 | Section 4 | 881 +-------------------------+--------------+---------------+ 883 7. Acknowledgements 885 Eric Rescorla pointed out several failings in an earlier revision. 886 Andrei Popov contributed to the TLS considerations. 888 8. References 890 8.1. Normative References 892 [I-D.ietf-tls-tls13] 893 Rescorla, E., "The Transport Layer Security (TLS) Protocol 894 Version 1.3", draft-ietf-tls-tls13-19 (work in progress), 895 March 2017. 897 [I-D.sullivan-tls-exported-authenticator] 898 Sullivan, N., "Exported Authenticators in TLS", draft- 899 sullivan-tls-exported-authenticator-01 (work in progress), 900 March 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 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 924 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 925 March 2010, . 927 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 928 Protocol (HTTP/1.1): Message Syntax and Routing", 929 RFC 7230, DOI 10.17487/RFC7230, June 2014, 930 . 932 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 933 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 934 DOI 10.17487/RFC7540, May 2015, 935 . 937 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 938 Langley, A., and M. Ray, "Transport Layer Security (TLS) 939 Session Hash and Extended Master Secret Extension", 940 RFC 7627, DOI 10.17487/RFC7627, September 2015, 941 . 943 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 944 Specification of Basic Encoding Rules (BER), Canonical 945 Encoding Rules (CER) and Distinguished Encoding Rules 946 (DER)", ISO ISO/IEC 8825-1:2002, 2002, 947 . 950 8.2. Informative References 952 [FIPS-186-4] 953 National Institute of Standards and Technology, "Digital 954 Signature Standard (DSS)", FIPS 186-4, July 2013, 955 . 958 [I-D.josefsson-eddsa-ed25519] 959 Josefsson, S. and N. Moller, "EdDSA and Ed25519", draft- 960 josefsson-eddsa-ed25519-03 (work in progress), May 2015. 962 [PKCS.1.1991] 963 RSA Laboratories, "RSA Encryption Standard, Version 1.1", 964 PKCS 1, June 1991. 966 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 967 Adams, "X.509 Internet Public Key Infrastructure Online 968 Certificate Status Protocol - OCSP", RFC 2560, 969 DOI 10.17487/RFC2560, June 1999, 970 . 972 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 973 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 974 . 976 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 977 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 978 April 2016, . 980 Authors' Addresses 982 Mike Bishop 983 Microsoft 985 Email: michael.bishop@microsoft.com 986 Nick Sullivan 987 Cloudflare 989 Email: nick@cloudflare.com 991 Martin Thomson 992 Mozilla 994 Email: martin.thomson@gmail.com