idnits 2.17.1 draft-bishop-httpbis-http2-additional-certs-04.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 (May 19, 2017) is 2524 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 921, but no explicit reference was found in the text == Unused Reference: 'RFC7627' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'FIPS-186-4' is defined on line 950, but no explicit reference was found in the text == Unused Reference: 'I-D.josefsson-eddsa-ed25519' is defined on line 956, but no explicit reference was found in the text == Unused Reference: 'RFC2560' is defined on line 964, but no explicit reference was found in the text == Unused Reference: 'RFC6962' is defined on line 970, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-tls-exported-authenticator-00 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-20 ** 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 (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. Bishop 3 Internet-Draft Microsoft 4 Intended status: Standards Track N. Sullivan 5 Expires: November 20, 2017 Cloudflare 6 M. Thomson 7 Mozilla 8 May 19, 2017 10 Secondary Certificate Authentication in HTTP/2 11 draft-bishop-httpbis-http2-additional-certs-04 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 a 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 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 November 20, 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.ietf-tls-exported-authenticator] are exchanged on stream zero 294 and the on-stream frames incorporate them by reference as needed. 296 TLS Exported Authenticators are structured messages that can be 297 exported by either party of a TLS connection and validated by the 298 other party. An authenticator message can be constructed by either 299 the client or the server given an established TLS connection, a 300 certificate, and a corresponding private key. Exported 301 Authenticators use the message structures from section 4.4 of 302 [I-D.ietf-tls-tls13], but different parameters. 304 Each Authenticator is computed using a Handshake Context and Finished 305 MAC Key derived from the TLS session. The Handshake Context is 306 identical for both parties of the TLS connection, while the Finished 307 MAC Key is dependent on whether the Authenticator is created by the 308 client or the server. 310 Successfully verified Authenticators result in certificate chains, 311 with verified possession of the corresponding private key, which can 312 be supplied into a collection of available certificates. Likewise, 313 descriptions of desired certificates can be supplied into these 314 collections. These pre-supplied elements are then available for 315 automatic use (in some situations) or for reference by individual 316 streams. 318 Section 2 describes how the feature is employed, defining means to 319 detect support in peers (Section 2.1), make certificates and requests 320 available (Section 2.2), and indicate when streams are blocked 321 waiting on an appropriate certificate (Section 2.3). Section 3 322 defines the required frame types, which parallel the TLS 1.3 message 323 exchange. Finally, Section 4 defines new error types which can be 324 used to notify peers when the exchange has not been successful. 326 1.4. Terminology 328 RFC 2119 [RFC2119] defines the terms "MUST", "MUST NOT", "SHOULD" and 329 "MAY". 331 2. Discovering Additional Certificates at the HTTP/2 Layer 333 A certificate chain with proof of possesion of the private key 334 corresponding to the end-entity certificate is sent as a single 335 "CERTIFICATE" frame (see Section 3.4) on stream zero. Once the 336 holder of a certificate has sent the chain and proof, this 337 certificate chain is cached by the recipient and available for future 338 use. If the certificate is marked as "AUTOMATIC_USE", the 339 certificate may be used by the recipient to authorize any current or 340 future request. Otherwise, the recipient requests the required 341 certificate on each stream, but the previously-supplied certificates 342 are available for reference without having to resend them. 344 Likewise, the details of a request are sent on stream zero and stored 345 by the recipient. These details will be referenced by subsequent 346 "CERTIFICATE_NEEDED" frames. 348 Data sent by each peer is correlated by the ID given in each frame. 349 This ID is unrelated to values used by the other peer, even if each 350 uses the same ID in certain cases. 352 2.1. Indicating support for HTTP-layer certificate authentication 354 Clients and servers that will accept requests for HTTP-layer 355 certificate authentication indicate this using the HTTP/2 356 "SETTINGS_HTTP_CERT_AUTH" (0xSETTING-TBD) setting. 358 The initial value for the "SETTINGS_HTTP_CERT_AUTH" setting is 0, 359 indicating that the peer does not support HTTP-layer certificate 360 authentication. If a peer does support HTTP-layer certificate 361 authentication, the value is 1. 363 2.2. Making certificates or requests available 365 When a peer has advertised support for HTTP-layer certificates as in 366 Section 2.1, either party can supply additional certificates into the 367 connection at any time. These certificates then become available for 368 the peer to consider when deciding whether a connection is suitable 369 to transport a particular request. 371 Available certificates which have the "AUTOMATIC_USE" flag set MAY be 372 used by the recipient without further notice. This means that 373 clients or servers which predict a certificate will be required could 374 pre-supply the certificate without being asked. Regardless of 375 whether "AUTOMATIC_USE" is set, these certificates are available for 376 reference by future "USE_CERTIFICATE" frames. 378 Client Server 379 <-------- (stream 0) CERTIFICATE (AU flag) -- 380 ... 381 -- (stream N) GET /from-new-origin ---------> 382 <----------------------- (stream N) 200 OK -- 384 Figure 3: Proactive Server Certificate 386 Client Server 387 -- (stream 0) CERTIFICATE (AU flag) --------> 388 -- (streams 1,3) GET /protected ------------> 389 <-------------------- (streams 1,3) 200 OK -- 391 Figure 4: Proactive Client Certificate 393 Likewise, either party can supply a "CERTIFICATE_REQUEST" that 394 outlines parameters of a certificate they might request in the 395 future. It is important to note that this does not currently request 396 such a certificate, but makes the contents of the request available 397 for reference by a future "CERTIFICATE_NEEDED" frame. 399 2.3. Requiring certificate authentication 401 As defined in [RFC7540], when a client finds that a https:// origin 402 (or Alternative Service [RFC7838]) to which it needs to make a 403 request has the same IP address as a server to which it is already 404 connected, it MAY check whether the TLS certificate provided contains 405 the new origin as well, and if so, reuse the connection. 407 If the TLS certificate does not contain the new origin, but the 408 server has advertised support for HTTP-layer certificates (see 409 Section 2.1), it MAY send a "CERTIFICATE_NEEDED" frame on the stream 410 it will use to make the request. (If the request parameters have not 411 already been made available using a "CERTIFICATE_REQUEST" frame, the 412 client will need to send the "CERTIFICATE_REQUEST" in order to 413 generate the "CERTIFICATE_NEEDED" frame.) The stream represents a 414 pending request to that origin which is blocked until a valid 415 certificate is processed. 417 The request is blocked until the server has responded with a 418 "USE_CERTIFICATE" frame pointing to a certificate for that origin. 419 If the certificate is already available, the server SHOULD 420 immediately respond with the appropriate "USE_CERTIFICATE" frame. 421 (If the certificate has not already been transmitted, the server will 422 need to make the certificate available as described in Section 2.2 423 before completing the exchange.) 424 If the server does not have the desired certificate or cannot produce 425 a signature compatible with the client's advertised settings, it MUST 426 respond with an empty "USE_CERTIFICATE" frame. In this case, or if 427 the server has not advertised support for HTTP-layer certificates, 428 the client MUST NOT send any requests for resources in that origin on 429 the current connection. 431 Client Server 432 -- (stream 0) CERTIFICATE_REQUEST ----------> 433 ... 434 -- (stream N) CERTIFICATE_NEEDED -----------> 435 <------------------ (stream 0) CERTIFICATE -- 436 <-------------- (stream N) USE_CERTIFICATE -- 437 -- (stream N) GET /from-new-origin ---------> 438 <----------------------- (stream N) 200 OK -- 440 Figure 5: Client-Requested Certificate 442 Likewise, on each stream where certificate authentication is 443 required, the server sends a "CERTIFICATE_NEEDED" frame, which the 444 client answers with a "USE_CERTIFICATE" frame indicating the 445 certificate to use. If the request parameters or the responding 446 certificate are not already available, they will need to be sent as 447 described in Section 2.2 as part of this exchange. 449 Client Server 450 <---------- (stream 0) CERTIFICATE_REQUEST -- 451 ... 452 -- (stream N) GET /protected ---------------> 453 <----------- (stream N) CERTIFICATE_NEEDED -- 454 -- (stream 0) CERTIFICATE ------------------> 455 -- (stream N) USE_CERTIFICATE --------------> 456 <----------------------- (stream N) 200 OK -- 458 Figure 6: Reactive Certificate Authentication 460 A server SHOULD provide certificates for an origin before pushing 461 resources from it. If a client receives a "PUSH_PROMISE" referencing 462 an origin for which it has not yet received the server's certificate, 463 the client MUST verify the server's possession of an appropriate 464 certificate by sending a "CERTIFICATE_NEEDED" frame on the pushed 465 stream to inform the server that progress is blocked until the 466 request is satisfied. The client MUST NOT use the pushed resource 467 until an appropriate certificate has been received and validated. 469 3. Certificates Frames for HTTP/2 471 The "CERTIFICATE_REQUEST" and "CERTIFICATE_NEEDED" frames are 472 correlated by their "Request-ID" field. Subsequent 473 "CERTIFICATE_NEEDED" frames with the same "Request-ID" value MAY be 474 sent on other streams where the sender is expecting a certificate 475 with the same parameters. 477 The "CERTIFICATE", and "USE_CERTIFICATE" frames are correlated by 478 their "Cert-ID" field. Subsequent "USE_CERTIFICATE" frames with the 479 same "Cert-ID" MAY be sent in response to other "CERTIFICATE_NEEDED" 480 frames and refer to the same certificate. 482 "Request-ID" and "Cert-ID" are sender-local, and the use of the same 483 value by the other peer does not imply any correlation between their 484 frames. 486 3.1. The CERTIFICATE_NEEDED frame 488 The "CERTIFICATE_NEEDED" frame (0xFRAME-TBD1) is sent to indicate 489 that the HTTP request on the current stream is blocked pending 490 certificate authentication. The frame includes a request identifier 491 which can be used to correlate the stream with a previous 492 "CERTIFICATE_REQUEST" frame sent on stream zero. The 493 "CERTIFICATE_REQUEST" describes the certificate the sender requires 494 to make progress on the stream in question. 496 The "CERTIFICATE_NEEDED" frame contains 1 octet, which is the 497 authentication request identifier, "Request-ID". A peer that 498 receives a "CERTIFICATE_NEEDED" of any other length MUST treat this 499 as a stream error of type "PROTOCOL_ERROR". Frames with identical 500 request identifiers refer to the same "CERTIFICATE_REQUEST". 502 A server MAY send multiple "CERTIFICATE_NEEDED" frames on the same 503 stream. If a server requires that a client provide multiple 504 certificates before authorizing a single request, each required 505 certificate MUST be indicated with a separate "CERTIFICATE_NEEDED" 506 frame, each of which MUST have a different request identifier 507 (referencing different "CERTIFICATE_REQUEST" frames describing each 508 required certificate). To reduce the risk of client confusion, 509 servers SHOULD NOT have multiple outstanding "CERTIFICATE_NEEDED" 510 frames on the same stream at any given time. 512 Clients MUST NOT send multiple "CERTIFICATE_NEEDED" frames on the 513 same stream. 515 The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a peer which has 516 not advertised support for HTTP-layer certificate authentication. 518 The "CERTIFICATE_NEEDED" frame MUST NOT be sent on stream zero, and 519 MUST NOT be sent on a stream in the "half-closed (local)" state 520 [RFC7540]. A client that receives a "CERTIFICATE_NEEDED" frame on a 521 stream which is not in a valid state SHOULD treat this as a stream 522 error of type "PROTOCOL_ERROR". 524 3.2. The USE_CERTIFICATE Frame 526 The "USE_CERTIFICATE" frame (0xFRAME-TBD4) is sent in response to a 527 "CERTIFICATE_NEEDED" frame to indicate which certificate is being 528 used to satisfy the requirement. 530 A "USE_CERTIFICATE" frame with no payload refers to the certificate 531 provided at the TLS layer, if any. If no certificate was provided at 532 the TLS layer, the stream should be processed with no authentication, 533 likely returning an authentication-related error at the HTTP level 534 (e.g. 403) for servers or routing the request to a new connection for 535 clients. 537 Otherwise, the "USE_CERTIFICATE" frame contains the "Cert-ID" of the 538 certificate the sender wishes to use. This MUST be the ID of a 539 certificate for which proof of possession has been presented in a 540 "CERTIFICATE" frame. Recipients of a "USE_CERTIFICATE" frame of any 541 other length MUST treat this as a stream error of type 542 "PROTOCOL_ERROR". Frames with identical certificate identifiers 543 refer to the same certificate chain. 545 The "USE_CERTIFICATE" frame MUST NOT be sent on stream zero or a 546 stream on which a "CERTIFICATE_NEEDED" frame has not been received. 547 Receipt of a "USE_CERTIFICATE" frame in these circmustances SHOULD be 548 treated as a stream error of type "PROTOCOL_ERROR". Each 549 "USE_CERTIFICATE" frame should reference a preceding "CERTIFICATE" 550 frame. Receipt of a "USE_CERTIFICATE" frame before the necessary 551 frames have been received on stream zero MUST also result in a stream 552 error of type "PROTOCOL_ERROR". 554 The referenced certificate chain MUST conform to the requirements 555 expressed in the "CERTIFICATE_REQUEST" to the best of the sender's 556 ability. Specifically: 558 o If the "CERTIFICATE_REQUEST" contained a non-empty "Certificate- 559 Authorities" element, one of the certificates in the chain SHOULD 560 be signed by one of the listed CAs. 562 o If the "CERTIFICATE_REQUEST" contained a non-empty "Cert- 563 Extensions" element, the end-entity certificate MUST match with 564 regard to the extension OIDs recognized by the sender. 566 If these requirements are not satisfied, the recipient MAY at its 567 discretion either return an error at the HTTP semantic layer, or 568 respond with a stream error [RFC7540] on any stream where the 569 certificate is used. Section 4 defines certificate-related error 570 codes which might be applicable. 572 3.3. The CERTIFICATE_REQUEST Frame 574 TLS 1.3 defines the "CertificateRequest" message, which prompts the 575 client to provide a certificate which conforms to certain properties 576 specified by the server. This draft defines the 577 "CERTIFICATE_REQUEST" frame (0xFRAME-TBD2), which contains the same 578 contents as a TLS 1.3 "CertificateRequest" message, but can be sent 579 over any TLS version. 581 The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a peer which 582 has not advertised support for HTTP-layer certificate authentication. 584 The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero. A 585 "CERTIFICATE_REQUEST" frame received on any other stream MUST be 586 rejected with a stream error of type "PROTOCOL_ERROR". 588 0 1 2 3 589 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 590 +-------------------------------+---------------+---------------+ 591 | Request-ID (8)| CA-Count (16) | 592 +-----------------------------------------------+---------------+ 593 | Certificate-Authorities (?) ... 594 +---------------------------------------------------------------+ 595 | Cert-Extension-Count (16) | Cert-Extensions(?) ... 596 +---------------------------------------------------------------+ 598 Figure 7: CERTIFICATE_REQUEST frame payload 600 The frame contains the following fields: 602 Request-ID: "Request-ID" is an 8-bit opaque identifier used to 603 correlate subsequent certificate-related frames with this request. 604 The identifier MUST be unique in the session for the sender. 606 CA-Count and Certificate-Authorities: "Certificate-Authorities" is a 607 series of distinguished names of acceptable certificate 608 authorities, represented in DER-encoded [X690] format. These 609 distinguished names may specify a desired distinguished name for a 610 root CA or for a subordinate CA; thus, this message can be used to 611 describe known roots as well as a desired authorization space. 612 The number of such structures is given by the 16-bit "CA-Count" 613 field, which MAY be zero. If the "CA-Count" field is zero, then 614 the recipient MAY send any certificate that meets the rest of the 615 selection criteria in the "CERTIFICATE_REQUEST", unless there is 616 some external arrangement to the contrary. 618 Cert-Extension-Count and Cert-Extensions: A list of certificate 619 extension OIDs [RFC5280] with their allowed values, represented in 620 a series of "CertificateExtension" structures (see 621 [I-D.ietf-tls-tls13] section 6.3.5). The list of OIDs MUST be 622 used in certificate selection as described in 623 [I-D.ietf-tls-tls13]. The number of Cert-Extension structures is 624 given by the 16-bit "Cert-Extension-Count" field, which MAY be 625 zero. 627 Some certificate extension OIDs allow multiple values (e.g. Extended 628 Key Usage). If the sender has included a non-empty Cert-Extensions 629 list, the certificate MUST contain all of the specified extension 630 OIDs that the recipient recognizes. For each extension OID 631 recognized by the recipient, all of the specified values MUST be 632 present in the certificate (but the certificate MAY have other values 633 as well). However, the recipient MUST ignore and skip any 634 unrecognized certificate extension OIDs. 636 Servers MUST be able to recognize the "subjectAltName" extension 637 ([RFC2459] section 4.2.1.7) at a minimum. Clients MUST always 638 specify the desired origin using this extension, though other 639 extensions MAY also be included. 641 PKIX RFCs define a variety of certificate extension OIDs and their 642 corresponding value types. Depending on the type, matching 643 certificate extension values are not necessarily bitwise-equal. It 644 is expected that implementations will rely on their PKI libraries to 645 perform certificate selection using these certificate extension OIDs. 647 3.4. The CERTIFICATE Frame 649 The "CERTIFICATE" frame (id=0xFRAME-TBD3) provides a exported 650 authenticator message ([I-D.ietf-tls-exported-authenticator]) from 651 the TLS layer that provides a chain of certificates, associated 652 extensions and proves possession of the private key corresponding to 653 the end-entity certificate. 655 The "CERTIFICATE" frame defines one flag: 657 AUTOMATIC_USE (0x01): Indicates that the certificate can be used 658 automatically on future requests. 660 0 1 2 3 661 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 662 +-------------------------------+-------------------------------+ 663 | Cert-ID (8) | Exported Authenticator (*) ... 664 +---------------------------------------------------------------+ 666 Figure 8: CERTIFICATE frame payload 668 The "CERTIFICATE" frame (0xFRAME-TBD4) contains an "Exported 669 Authenticator" field which corresponds to the value returned from the 670 TLS connection exported authenticator API when provided with a 671 certificate, a valid certificate chain for the connection and 672 associated extensions (OCSP, SCT, etc.), and a connection-unique 673 8-byte certificate_request_context value. 675 If the "AUTOMATIC_USE" flag is set, the recipient MAY omit sending 676 "CERTIFICATE_NEEDED" frames on future streams which would require a 677 similar certificate and use the referenced certificate for 678 authentication without further notice to the holder. This behavior 679 is optional, and receipt of a "CERTIFICATE_NEEDED" frame does not 680 imply that previously-presented certificates were unacceptable, even 681 if "AUTOMATIC_USE" was set. Servers MUST set the "AUTOMATIC_USE" 682 flag when sending a "CERTIFICATE" frame. A server MUST NOT send 683 certificates for origins which it is not prepared to service on the 684 current connection. 686 Upon recieving a CERTIFICATE frame, the reciever may validate the 687 Exported Authenticator value by using the exported authenticator API. 688 This returns either an error indicating that the message was invalid, 689 or the certificate chain and extensions used to create the message. 691 It is possible that a large certificate chain might be too large to 692 fit in a single HTTP/2 frame (see [RFC7540] section 4.2). Senders 693 unable to transfer a requested certificate due to the recipient's 694 "SETTINGS_MAX_FRAME_SIZE" value SHOULD terminate affected streams 695 with "CERTIFICATE_TOO_LARGE". 697 The "CERTIFICATE" frame MUST be sent on stream zero. A "CERTIFICATE" 698 frame received on any other stream MUST be rejected with a stream 699 error of type "PROTOCOL_ERROR". 701 4. Indicating failures during HTTP-Layer Certificate Authentication 703 Because this draft permits certificates to be exchanged at the HTTP 704 framing layer instead of the TLS layer, several certificate-related 705 errors which are defined at the TLS layer might now occur at the HTTP 706 framing layer. In this section, those errors are restated and added 707 to the HTTP/2 error code registry. 709 BAD_CERTIFICATE (0xERROR-TBD1): A certificate was corrupt, contained 710 signatures that did not verify correctly, etc. 712 UNSUPPORTED_CERTIFICATE (0xERROR-TBD2): A certificate was of an 713 unsupported type or did not contain required extensions 715 CERTIFICATE_REVOKED (0xERROR-TBD3): A certificate was revoked by its 716 signer 718 CERTIFICATE_EXPIRED (0xERROR-TBD4): A certificate has expired or is 719 not currently valid 721 CERTIFICATE_TOO_LARGE (0xERROR-TBD5): The certificate cannot be 722 transferred due to the recipient's "SETTINGS_MAX_FRAME_SIZE" 724 CERTIFICATE_GENERAL (0xERROR-TBD6): Any other certificate-related 725 error 727 As described in [RFC7540], implementations MAY choose to treat a 728 stream error as a connection error at any time. Of particular note, 729 a stream error cannot occur on stream 0, which means that 730 implementations cannot send non-session errors in response to 731 "CERTIFICATE_REQUEST", and "CERTIFICATE" frames. Implementations 732 which do not wish to terminate the connection MAY either send 733 relevant errors on any stream which references the failing 734 certificate in question or process the requests as unauthenticated 735 and provide error information at the HTTP semantic layer. 737 5. Security Considerations 739 This mechanism defines an alternate way to obtain server and client 740 certificates other than in the initial TLS handshake. While the 741 signature of exported authenticator values is expected to be equally 742 secure, it is important to recognize that a vulnerability in this 743 code path is at least equal to a vulnerability in the TLS handshake. 745 5.1. Impersonation 747 This mechanism could increase the impact of a key compromise. Rather 748 than needing to subvert DNS or IP routing in order to use a 749 compromised certificate, a malicious server now only needs a client 750 to connect to _some_ HTTPS site under its control in order to present 751 the compromised certificate. Clients MUST continue to validate that 752 the destination IP address is valid for the origin either by direct 753 DNS resolution or resolution of a validated Alternative Service. 754 (Future work could include a mechanism for a server to offer proofs.) 755 As noted in the Security Considerations of 756 [I-D.ietf-tls-exported-authenticator], it difficult to formally prove 757 that an endpoint is jointly authoritative over multiple certificates, 758 rather than individually authoritative on each certificate. As a 759 result, clients MUST NOT assume that because one origin was 760 previously colocated with another, those origins will be reachable 761 via the same endpoints in the future. Clients MUST NOT consider 762 previous secondary certificates to be validated after TLS session 763 resumption. However, clients MAY query for previously-presented 764 secondary certificates after first repeating the validation of the 765 endpoint's IP address against fresh DNS and Alt-Svc information. 767 5.2. Fingerprinting 769 This draft defines a mechanism which could be used to probe servers 770 for origins they support, but opens no new attack versus making 771 repeat TLS connections with different SNI values. Servers SHOULD 772 impose similar denial-of-service mitigations (e.g. request rate 773 limits) to "CERTIFICATE_REQUEST" frames as to new TLS connections. 775 While the "CERTIFICATE_REQUEST" frame permits the sender to enumerate 776 the acceptable Certificate Authorities for the requested certificate, 777 it might not be prudent (either for security or data consumption) to 778 include the full list of trusted Certificate Authorities in every 779 request. Senders, particularly clients, SHOULD send an empty 780 "Certificate-Authorities" element unless they are expecting a 781 certificate to be signed by a particular CA or one of a small set of 782 CAs. 784 5.3. Denial of Service 786 Failure to provide a certificate on a stream after receiving 787 "CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to 788 standard timeouts used to guard against unresponsive peers. 790 Validating a multitude of signatures can be computationally 791 expensive, while generating an invalid signature is computationally 792 cheap. Implementations will require checks for attacks from this 793 direction. Signature proofs SHOULD NOT be validated until a stream 794 requires the certificate to make progress. A signature which is not 795 valid based on the asserted public key SHOULD be treated as a session 796 error, to avoid further attacks from the peer, though an 797 implementation MAY instead disable HTTP-layer certificates for the 798 current connection instead. 800 5.4. Confusion About State 802 Implementations need to be aware of the potential for confusion about 803 the state of a connection. The presence or absence of a validated 804 certificate can change during the processing of a request, 805 potentially multiple times, as "USE_CERTIFICATE" frames are received. 806 A server that uses certificate authentication needs to be prepared to 807 reevaluate the authorization state of a request as the set of 808 certificates changes. 810 Client implementations need to carefully consider the impact of 811 setting the "AUTOMATIC_USE" flag. This flag is a performance 812 optimization, permitting the client to avoid a round-trip on each 813 request where the server checks for certificate authentication. 814 However, once this flag has been sent, the client has zero knowledge 815 about whether the server will use the referenced cert for any future 816 request, or even for an existing request which has not yet completed. 817 Clients MUST NOT set this flag on any certificate which is not 818 appropriate for currently-in-flight requests, and MUST NOT make any 819 future requests on the same connection which they are not willing to 820 have associated with the provided certificate. 822 6. IANA Considerations 824 This draft adds entries in three registries. 826 The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in 827 Section 6.1. Four frame types are registered in Section 6.2. Six 828 error codes are registered in Section 6.3. 830 6.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting 832 The SETTINGS_HTTP_CERT_AUTH setting is registered in the "HTTP/2 833 Settings" registry established in [RFC7540]. 835 Name: SETTINGS_HTTP_CERT_AUTH 837 Code: 0xSETTING-TBD 839 Initial Value: 0 841 Specification: This document. 843 6.2. New HTTP/2 Frames 845 Four new frame types are registered in the "HTTP/2 Frame Types" 846 registry established in [RFC7540]. The entries in the following 847 table are registered by this document. 849 +---------------------+--------------+---------------+ 850 | Frame Type | Code | Specification | 851 +---------------------+--------------+---------------+ 852 | CERTIFICATE_NEEDED | 0xFRAME-TBD1 | Section 3.1 | 853 | | | | 854 | CERTIFICATE_REQUEST | 0xFRAME-TBD2 | Section 3.3 | 855 | | | | 856 | CERTIFICATE | 0xFRAME-TBD3 | Section 3.4 | 857 | | | | 858 | USE_CERTIFICATE | 0xFRAME-TBD4 | Section 3.2 | 859 +---------------------+--------------+---------------+ 861 6.3. New HTTP/2 Error Codes 863 Five new error codes are registered in the "HTTP/2 Error Code" 864 registry established in [RFC7540]. The entries in the following 865 table are registered by this document. 867 +-------------------------+--------------+---------------+ 868 | Name | Code | Specification | 869 +-------------------------+--------------+---------------+ 870 | BAD_CERTIFICATE | 0xERROR-TBD1 | Section 4 | 871 | | | | 872 | UNSUPPORTED_CERTIFICATE | 0xERROR-TBD2 | Section 4 | 873 | | | | 874 | CERTIFICATE_REVOKED | 0xERROR-TBD3 | Section 4 | 875 | | | | 876 | CERTIFICATE_EXPIRED | 0xERROR-TBD4 | Section 4 | 877 | | | | 878 | CERTIFICATE_GENERAL | 0xERROR-TBD5 | Section 4 | 879 +-------------------------+--------------+---------------+ 881 7. Acknowledgements 883 Eric Rescorla pointed out several failings in an earlier revision. 884 Andrei Popov contributed to the TLS considerations. 886 8. References 888 8.1. Normative References 890 [I-D.ietf-tls-exported-authenticator] 891 Sullivan, N., "Exported Authenticators in TLS", draft- 892 ietf-tls-exported-authenticator-00 (work in progress), May 893 2017. 895 [I-D.ietf-tls-tls13] 896 Rescorla, E., "The Transport Layer Security (TLS) Protocol 897 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 898 April 2017. 900 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 901 Requirement Levels", BCP 14, RFC 2119, 902 DOI 10.17487/RFC2119, March 1997, 903 . 905 [RFC2459] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet 906 X.509 Public Key Infrastructure Certificate and CRL 907 Profile", RFC 2459, DOI 10.17487/RFC2459, January 1999, 908 . 910 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 911 (TLS) Protocol Version 1.2", RFC 5246, 912 DOI 10.17487/RFC5246, August 2008, 913 . 915 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 916 Housley, R., and W. Polk, "Internet X.509 Public Key 917 Infrastructure Certificate and Certificate Revocation List 918 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 919 . 921 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 922 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 923 March 2010, . 925 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 926 Protocol (HTTP/1.1): Message Syntax and Routing", 927 RFC 7230, DOI 10.17487/RFC7230, June 2014, 928 . 930 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 931 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 932 DOI 10.17487/RFC7540, May 2015, 933 . 935 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 936 Langley, A., and M. Ray, "Transport Layer Security (TLS) 937 Session Hash and Extended Master Secret Extension", 938 RFC 7627, DOI 10.17487/RFC7627, September 2015, 939 . 941 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 942 Specification of Basic Encoding Rules (BER), Canonical 943 Encoding Rules (CER) and Distinguished Encoding Rules 944 (DER)", ISO ISO/IEC 8825-1:2002, 2002, 945 . 948 8.2. Informative References 950 [FIPS-186-4] 951 National Institute of Standards and Technology, "Digital 952 Signature Standard (DSS)", FIPS 186-4, July 2013, 953 . 956 [I-D.josefsson-eddsa-ed25519] 957 Josefsson, S. and N. Moller, "EdDSA and Ed25519", draft- 958 josefsson-eddsa-ed25519-03 (work in progress), May 2015. 960 [PKCS.1.1991] 961 RSA Laboratories, "RSA Encryption Standard, Version 1.1", 962 PKCS 1, June 1991. 964 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 965 Adams, "X.509 Internet Public Key Infrastructure Online 966 Certificate Status Protocol - OCSP", RFC 2560, 967 DOI 10.17487/RFC2560, June 1999, 968 . 970 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 971 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 972 . 974 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 975 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 976 April 2016, . 978 Authors' Addresses 980 Mike Bishop 981 Microsoft 983 Email: michael.bishop@microsoft.com 984 Nick Sullivan 985 Cloudflare 987 Email: nick@cloudflare.com 989 Martin Thomson 990 Mozilla 992 Email: martin.thomson@gmail.com