idnits 2.17.1 draft-bishop-httpbis-http2-additional-certs-02.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.ietf-tls-tls13], [I-D.draft-sullivan-tls-exported-authenticator]), 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 (October 31, 2016) is 2727 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 872, but no explicit reference was found in the text == Unused Reference: 'RFC7627' is defined on line 886, but no explicit reference was found in the text == Unused Reference: 'FIPS-186-4' is defined on line 901, but no explicit reference was found in the text == Unused Reference: 'I-D.josefsson-eddsa-ed25519' is defined on line 912, but no explicit reference was found in the text == Unused Reference: 'I-D.nottingham-httpbis-origin-frame' is defined on line 916, but no explicit reference was found in the text == Unused Reference: 'RFC2560' is defined on line 925, but no explicit reference was found in the text == Unused Reference: 'RFC6962' is defined on line 931, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-18 ** 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 M. Thomson 5 Expires: May 4, 2017 Mozilla 6 October 31, 2016 8 Secondary Certificate Authentication in HTTP/2 9 draft-bishop-httpbis-http2-additional-certs-02 11 Abstract 13 TLS provides fundamental mutual authentication services for HTTP, 14 supporting up to one server certificate and up to one client 15 certificate associated to the session to prove client and server 16 identities as necessary. This draft provides mechanisms for 17 providing additional such certificates at the HTTP layer when these 18 constraints are not sufficient. 20 Many HTTP servers host content from several origins. HTTP/2 21 [RFC7540] permits clients to reuse an existing HTTP connection to a 22 server provided that the secondary origin is also in the certificate 23 provided during the TLS [I-D.ietf-tls-tls13] handshake. 25 In many cases, servers will wish to maintain separate certificates 26 for different origins but still desire the benefits of a shared HTTP 27 connection. Similarly, servers may require clients to present 28 authentication, but have different requirements based on the content 29 the client is attempting to access. 31 This document describes a how TLS exported authenticators [I-D.draft- 32 sullivan-tls-exported-authenticator] can be used to provide proof of 33 ownership of additional certificates to the HTTP layer to support 34 both scenarios. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on May 4, 2017. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Server Certificate Authentication . . . . . . . . . . . . 3 72 1.2. Client Certificate Authentication . . . . . . . . . . . . 4 73 1.2.1. HTTP/1.1 using TLS 1.2 and previous . . . . . . . . . 4 74 1.2.2. HTTP/1.1 using TLS 1.3 . . . . . . . . . . . . . . . 5 75 1.2.3. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 6 76 1.3. HTTP-Layer Certificate Authentication . . . . . . . . . . 6 77 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 78 2. Discovering Additional Certificates at the HTTP/2 Layer . . . 7 79 2.1. Indicating support for HTTP-layer certificate 80 authentication . . . . . . . . . . . . . . . . . . . . . 8 81 2.2. Making certificates or requests available . . . . . . . . 8 82 2.3. Requiring certificate authentication . . . . . . . . . . 9 83 3. Certificates Frames for HTTP/2 . . . . . . . . . . . . . . . 10 84 3.1. The CERTIFICATE_NEEDED frame . . . . . . . . . . . . . . 11 85 3.2. The USE_CERTIFICATE Frame . . . . . . . . . . . . . . . . 12 86 3.3. The CERTIFICATE_REQUEST Frame . . . . . . . . . . . . . . 13 87 3.4. The CERTIFICATE_PROOF Frame . . . . . . . . . . . . . . . 14 88 4. Indicating failures during HTTP-Layer Certificate 89 Authentication . . . . . . . . . . . . . . . . . . . . . . . 15 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 92 6.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting . . . . . . . . . 17 93 6.2. New HTTP/2 Frames . . . . . . . . . . . . . . . . . . . . 18 94 6.3. New HTTP/2 Error Codes . . . . . . . . . . . . . . . . . 18 95 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 98 8.2. Informative References . . . . . . . . . . . . . . . . . 20 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 101 1. Introduction 103 HTTP clients need to know that the content they receive on a 104 connection comes from the origin that they intended to retrieve in 105 from. The traditional form of server authentication in HTTP has been 106 in the form of X.509 certificates provided during the TLS RFC5246 107 [I-D.ietf-tls-tls13] handshake. 109 Many existing HTTP [RFC7230] servers also have authentication 110 requirements for the resources they serve. Of the bountiful 111 authentication options available for authenticating HTTP requests, 112 client certificates present a unique challenge for resource-specific 113 authentication requirements because of the interaction with the 114 underlying TLS layer. 116 TLS 1.2 [RFC5246] supports one server and one client certificate on a 117 connection. These certificates may contain multiple identities, but 118 only one certificate may be provided. 120 1.1. Server Certificate Authentication 122 Section 9.1.1 of [RFC7540] describes how connections may be used to 123 make requests from multiple origins as long as the server is 124 authoritative for both. A server is considered authoritative for an 125 origin if DNS resolves the origin to the IP address of the server and 126 (for TLS) if the certificate presented by the server contains the 127 origin in the Subject Alternative Names field. 129 [I-D.ietf-httpbis-alt-svc] enables a step of abstraction from the DNS 130 resolution. If both hosts have provided an Alternative Service at 131 hostnames which resolve to the IP address of the server, they are 132 considered authoritative just as if DNS resolved the origin itself to 133 that address. However, the server's one TLS certificate is still 134 required to contain the name of each origin in question. 136 Servers which host many origins often would prefer to have separate 137 certificates for some sets of origins. This may be for ease of 138 certificate management (the ability to separately revoke or renew 139 them), due to different sources of certificates (a CDN acting on 140 behalf of multiple origins), or other factors which might drive this 141 administrative decision. Clients connecting to such origins cannot 142 currently reuse connections, even if both client and server would 143 prefer to do so. 145 Because the TLS SNI extension is exchanged in the clear, clients 146 might also prefer to retrieve certificates inside the encrypted 147 context. When this information is sensitive, it might be 148 advantageous to request a general-purpose certificate or anonymous 149 ciphersuite at the TLS layer, while acquiring the "real" certificate 150 in HTTP after the connection is established. 152 1.2. Client Certificate Authentication 154 For servers that wish to use client certificates to authenticate 155 users, they might request client authentication during or immediately 156 after the TLS handshake. However, if not all users or resources need 157 certificate-based authentication, a request for a certificate has the 158 unfortunate consequence of triggering the client to seek a 159 certificate, possibly requiring user interaction, network traffic, or 160 other time-consuming activities. During this time, the connection is 161 stalled in many implementations. Such a request can result in a poor 162 experience, particularly when sent to a client that does not expect 163 the request. 165 The TLS 1.3 CertificateRequest can be used by servers to give clients 166 hints about which certificate to offer. Servers that rely on 167 certificate-based authentication might request different certificates 168 for different resources. Such a server cannot use contextual 169 information about the resource to construct an appropriate TLS 170 CertificateRequest message during the initial handshake. 172 Consequently, client certificates are requested at connection 173 establishment time only in cases where all clients are expected or 174 required to have a single certificate that is used for all resources. 175 Many other uses for client certificates are reactive, that is, 176 certificates are requested in response to the client making a 177 request. 179 1.2.1. HTTP/1.1 using TLS 1.2 and previous 181 In HTTP/1.1, a server that relies on client authentication for a 182 subset of users or resources does not request a certificate when the 183 connection is established. Instead, it only requests a client 184 certificate when a request is made to a resource that requires a 185 certificate. TLS 1.2 [RFC5246] accomodates this by permitting the 186 server to request a new TLS handshake, in which the server will 187 request the client's certificate. 189 Figure 1 shows the server initiating a TLS-layer renegotiation in 190 response to receiving an HTTP/1.1 request to a protected resource. 192 Client Server 193 -- (HTTP) GET /protected -------------------> *1 194 <---------------------- (TLS) HelloRequest -- *2 195 -- (TLS) ClientHello -----------------------> 196 <------------------ (TLS) ServerHello, ... -- 197 <---------------- (TLS) CertificateRequest -- *3 198 -- (TLS) ..., Certificate ------------------> *4 199 -- (TLS) Finished --------------------------> 200 <-------------------------- (TLS) Finished -- 201 <--------------------------- (HTTP) 200 OK -- *5 203 Figure 1: HTTP/1.1 Reactive Certificate Authentication with TLS 1.2 205 In this example, the server receives a request for a protected 206 resource (at *1 on Figure 1). Upon performing an authorization 207 check, the server determines that the request requires authentication 208 using a client certificate and that no such certificate has been 209 provided. 211 The server initiates TLS renegotiation by sending a TLS HelloRequest 212 (at *2). The client then initiates a TLS handshake. Note that some 213 TLS messages are elided from the figure for the sake of brevity. 215 The critical messages for this example are the server requesting a 216 certificate with a TLS CertificateRequest (*3); this request might 217 use information about the request or resource. The client then 218 provides a certificate and proof of possession of the private key in 219 Certificate and CertificateVerify messages (*4). 221 When the handshake completes, the server performs any authorization 222 checks a second time. With the client certificate available, it then 223 authorizes the request and provides a response (*5). 225 1.2.2. HTTP/1.1 using TLS 1.3 227 TLS 1.3 [I-D.ietf-tls-tls13] introduces a new client authentication 228 mechanism that allows for clients to authenticate after the handshake 229 has been completed. For the purposes of authenticating an HTTP 230 request, this is functionally equivalent to renegotiation. Figure 2 231 shows the simpler exchange this enables. 233 Client Server 234 -- (HTTP) GET /protected -------------------> 235 <---------------- (TLS) CertificateRequest -- 236 -- (TLS) Certificate, CertificateVerify ----> 237 <--------------------------- (HTTP) 200 OK -- 239 Figure 2: HTTP/1.1 Reactive Certificate Authentication with TLS 1.3 241 TLS 1.3 does not support renegotiation, instead supporting direct 242 client authentication. In contrast to the TLS 1.2 example, in TLS 243 1.3, a server can simply request a certificate. 245 1.2.3. HTTP/2 247 An important part of the HTTP/1.1 exchange is that the client is able 248 to easily identify the request that caused the TLS renegotiation. 249 The client is able to assume that the next unanswered request on the 250 connection is responsible. The HTTP stack in the client is then able 251 to direct the certificate request to the application or component 252 that initiated that request. This ensures that the application has 253 the right contextual information for processing the request. 255 In HTTP/2, a client can have multiple outstanding requests. Without 256 some sort of correlation information, a client is unable to identify 257 which request caused the server to request a certificate. 259 Thus, the minimum necessary mechanism to support reactive certificate 260 authentication in HTTP/2 is an identifier that can be use to 261 correlate an HTTP request with a request for a certificate. Since 262 streams are used for individual requests, correlation with a stream 263 is sufficient. 265 [RFC7540] prohibits renegotiation after any application data has been 266 sent. This completely blocks reactive certificate authentication in 267 HTTP/2 using TLS 1.2. If this restriction were relaxed by an 268 extension or update to HTTP/2, such an identifier could be added to 269 TLS 1.2 by means of an extension to TLS. Unfortunately, many TLS 1.2 270 implementations do not permit application data to continue during a 271 renegotiation. This is problematic for a multiplexed protocol like 272 HTTP/2. 274 1.3. HTTP-Layer Certificate Authentication 276 This draft proposes bringing a request/response mechanism that is 277 equivalent to the the TLS 1.3 CertificateRequest, Certificate, 278 CertificateVerify and Finished messages into HTTP/2 frames, enabling 279 certificate-based authentication of both clients and servers 280 independent of TLS version. This mechanism can be implemented at the 281 HTTP layer without breaking the existing interface between HTTP and 282 applications above it. 284 This could be done in a naive manner by replicating the messages as 285 HTTP/2 frames on each stream. However, this would create needless 286 redundancy between streams and require frequent expensive signing 287 operations. Instead, this draft lifts the bulky portions of each 288 message into frames on stream zero and permits the on-stream frames 289 to incorporate them by reference as needed. 291 Certificate chains, with proof-of-possession of the corresponding 292 private key, can be supplied into a collection of available 293 certificates. Likewise, descriptions of desired certificates can be 294 supplied into these collections. These pre-supplied elements are 295 then available for automatic use (in some situations) or for 296 reference by individual streams. 298 Section 2 describes how the feature is employed, defining means to 299 detect support in peers (Section 2.1), make certificates and requests 300 available (Section 2.2), and indicate when streams are blocked 301 waiting on an appropriate certificate (Section 2.3). Section 3 302 defines the required frame types, which parallel the TLS 1.3 message 303 exchange. Finally, Section 4 defines new error types which can be 304 used to notify peers when the exchange has not been successful. 306 1.4. Terminology 308 RFC 2119 [RFC2119] defines the terms "MUST", "MUST NOT", "SHOULD" and 309 "MAY". 311 2. Discovering Additional Certificates at the HTTP/2 Layer 313 A certificate chain with proof of possesion of the private key 314 corresponding to the end-entity certificate is sent as a single of 315 "CERTIFICATE_PROOF" frame (see Section 3.4) on stream zero. Once the 316 holder of a certificate has sent the chain and proof, this 317 certificate chain is cached by the recipient and available for future 318 use. If the certificate is marked as "AUTOMATIC_USE", the 319 certificate may be used by the recipient to authorize any current or 320 future request. Otherwise, the recipient requests the required 321 certificate on each stream, but the previously-supplied certificates 322 are available for reference without having to resend them. 324 Likewise, the details of a request are sent on stream zero and stored 325 by the recipient. These details will be referenced by subsequent 326 "CERTIFICATE_NEEDED" frames. 328 Data sent by each peer is correlated by the ID given in each frame. 329 This ID is unrelated to values used by the other peer, even if each 330 uses the same ID in certain cases. 332 2.1. Indicating support for HTTP-layer certificate authentication 334 Clients and servers that will accept requests for HTTP-layer 335 certificate authentication indicate this using the HTTP/2 336 "SETTINGS_HTTP_CERT_AUTH" (0xSETTING-TBD) setting. 338 The initial value for the "SETTINGS_HTTP_CERT_AUTH" setting is 0, 339 indicating that the peer does not support HTTP-layer certificate 340 authentication. If a peer does support HTTP-layer certificate 341 authentication, the value is 1. 343 2.2. Making certificates or requests available 345 When a peer has advertised support for HTTP-layer certificates as in 346 Section 2.1, either party can supply additional certificates into the 347 connection at any time. These certificates then become available for 348 the peer to consider when deciding whether a connection is suitable 349 to transport a particular request. 351 Available certificates which have the "AUTOMATIC_USE" flag set MAY be 352 used by the recipient without further notice. This means that 353 clients or servers which predict a certificate will be required could 354 pre-supply the certificate without being asked. Regardless of 355 whether "AUTOMATIC_USE" is set, these certificates are available for 356 reference by future "USE_CERTIFICATE" frames. 358 Client Server 359 <-- (stream 0) CERTIFICATE_PROOF (AU flag) -- 360 ... 361 -- (stream N) GET /from-new-origin ---------> 362 <----------------------- (stream N) 200 OK -- 364 Figure 3: Proactive Server Certificate 366 Client Server 367 -- (stream 0) CERTIFICATE_PROOF (AU flag) --> 368 -- (streams 1,3) GET /protected ------------> 369 <-------------------- (streams 1,3) 200 OK -- 371 Figure 4: Proactive Client Certificate 373 Likewise, either party can supply a "CERTIFICATE_REQUEST" that 374 outlines parameters of a certificate they might request in the 375 future. It is important to note that this does not currently request 376 such a certificate, but makes the contents of the request available 377 for reference by a future "CERTIFICATE_NEEDED" frame. 379 Because certificates can be large and each "CERTIFICATE_PROOF" 380 requires a signing operation, the server MAY instead send an "ORIGIN" 381 frame including origins which are not in its TLS certificate. This 382 represents an explicit claim by the server to possess the appropriate 383 certificate - a claim the client MUST verify using the procedures in 384 Section 2.3 before relying on the server's authority for the claimed 385 origin. 387 2.3. Requiring certificate authentication 389 As defined in [RFC7540], when a client finds that a https:// origin 390 (or Alternative Service [I-D.ietf-httpbis-alt-svc]) to which it needs 391 to make a request has the same IP address as a server to which it is 392 already connected, it MAY check whether the TLS certificate provided 393 contains the new origin as well, and if so, reuse the connection. 395 If the TLS certificate does not contain the new origin, but the 396 server has advertised support for HTTP-layer certificates (see 397 Section 2.1), it MAY send a "CERTIFICATE_NEEDED" frame on the stream 398 it will use to make the request. (If the request parameters have not 399 already been made available using a "CERTIFICATE_REQUEST" frame, the 400 client will need to send the "CERTIFICATE_REQUEST" in order to 401 generate the "CERTIFICATE_NEEDED" frame.) The stream represents a 402 pending request to that origin which is blocked until a valid 403 certificate is processed. 405 The request is blocked until the server has responded with a 406 "USE_CERTIFICATE" frame pointing to a certificate for that origin. 407 If the certificate is already available, the server SHOULD 408 immediately respond with the appropriate "USE_CERTIFICATE" frame. 409 (If the certificate has not already been transmitted, the server will 410 need to make the certificate available as described in Section 2.2 411 before completing the exchange.) 413 If the server does not have the desired certificate or cannot produce 414 a signature compatible with the client's advertised settings, it MUST 415 respond with an empty "USE_CERTIFICATE" frame. In this case, or if 416 the server has not advertised support for HTTP-layer certificates, 417 the client MUST NOT send any requests for resources in that origin on 418 the current connection. 420 Client Server 421 <----------------------- (stream 0) ORIGIN -- 422 -- (stream 0) CERTIFICATE_REQUEST ----------> 423 ... 424 -- (stream N) CERTIFICATE_NEEDED ---------> 425 <------------ (stream 0) CERTIFICATE_PROOF -- 426 <-------------- (stream N) USE_CERTIFICATE -- 427 -- (stream N) GET /from-new-origin ---------> 428 <----------------------- (stream N) 200 OK -- 430 Figure 5: Client-Requested Certificate 432 Likewise, on each stream where certificate authentication is 433 required, the server sends a "CERTIFICATE_NEEDED" frame, which the 434 client answers with a "USE_CERTIFICATE" frame indicating the 435 certificate to use. If the request parameters or the responding 436 certificate are not already available, they will need to be sent as 437 described in Section 2.2 as part of this exchange. 439 Client Server 440 <---------- (stream 0) CERTIFICATE_REQUEST -- 441 ... 442 -- (stream N) GET /protected ---------------> 443 <--------- (stream N) CERTIFICATE_NEEDED -- 444 -- (stream 0) CERTIFICATE_PROOF ------------> 445 -- (stream N) USE_CERTIFICATE --------------> 446 <----------------------- (stream N) 200 OK -- 448 Figure 6: Reactive Certificate Authentication 450 A server SHOULD provide certificates for an origin before pushing 451 resources from it. If a client receives a "PUSH_PROMISE" referencing 452 an origin for which it has not yet received the server's certificate, 453 the client MUST verify the server's possession of an appropriate 454 certificate by sending a "CERTIFICATE_NEEDED" frame on the pushed 455 stream to inform the server that progress is blocked until the 456 request is satisfied. The client MUST NOT use the pushed resource 457 until an appropriate certificate has been received and validated. 459 3. Certificates Frames for HTTP/2 461 The "CERTIFICATE_REQUEST" and "CERTIFICATE_NEEDED" frames are 462 correlated by their "Request-ID" field. Subsequent 463 "CERTIFICATE_NEEDED" frames with the same "Request-ID" value MAY be 464 sent on other streams where the sender is expecting a certificate 465 with the same parameters. 467 The "CERTIFICATE_PROOF", and "USE_CERTIFICATE" frames are correlated 468 by their "Cert-ID" field. Subsequent "USE_CERTIFICATE" frames with 469 the same "Cert-ID" MAY be sent in response to other 470 "CERTIFICATE_NEEDED" frames and refer to the same certificate. 472 "Request-ID" and "Cert-ID" are sender-local, and the use of the same 473 value by the other peer does not imply any correlation between their 474 frames. 476 3.1. The CERTIFICATE_NEEDED frame 478 The "CERTIFICATE_NEEDED" frame (0xFRAME-TBD2) is sent to indicate 479 that the HTTP request on the current stream is blocked pending 480 certificate authentication. The frame includes a request identifier 481 which can be used to correlate the stream with a previous 482 "CERTIFICATE_REQUEST" frame sent on stream zero. The 483 "CERTIFICATE_REQUEST" describes the certificate the sender requires 484 to make progress on the stream in question. 486 The "CERTIFICATE_NEEDED" frame contains 1 octet, which is the 487 authentication request identifier, "Request-ID". A peer that 488 receives a "CERTIFICATE_NEEDED" of any other length MUST treat this 489 as a stream error of type "PROTOCOL_ERROR". Frames with identical 490 request identifiers refer to the same "CERTIFICATE_REQUEST". 492 A server MAY send multiple "CERTIFICATE_NEEDED" frames on the same 493 stream. If a server requires that a client provide multiple 494 certificates before authorizing a single request, each required 495 certificate MUST be indicated with a separate "CERTIFICATE_NEEDED" 496 frame, each of which MUST have a different request identifier 497 (referencing different "CERTIFICATE_REQUEST" frames describing each 498 required certificate). To reduce the risk of client confusion, 499 servers SHOULD NOT have multiple outstanding "CERTIFICATE_NEEDED" 500 frames on the same stream at any given time. 502 Clients MUST NOT send multiple "CERTIFICATE_NEEDED" frames on the 503 same stream. 505 The "CERTIFICATE_NEEDED" frame MUST NOT be sent to a peer which has 506 not advertised support for HTTP-layer certificate authentication. 508 The "CERTIFICATE_NEEDED" frame MUST NOT be sent on stream zero, and 509 MUST NOT be sent on a stream in the "half-closed (local)" state 510 [RFC7540]. A client that receives a "CERTIFICATE_NEEDED" frame on a 511 stream which is not in a valid state SHOULD treat this as a stream 512 error of type "PROTOCOL_ERROR". 514 3.2. The USE_CERTIFICATE Frame 516 The "USE_CERTIFICATE" frame (0xFRAME-TBD5) is sent in response to a 517 "CERTIFICATE_NEEDED" frame to indicate which certificate is being 518 used to satisfy the requirement. 520 A "USE_CERTIFICATE" frame with no payload refers to the certificate 521 provided at the TLS layer, if any. If no certificate was provided at 522 the TLS layer, the stream should be processed with no authentication, 523 likely returning an authentication-related error at the HTTP level 524 (e.g. 403) for servers or routing the request to a new connection for 525 clients. 527 Otherwise, the "USE_CERTIFICATE" frame contains the "Cert-ID" of the 528 certificate the sender wishes to use. This MUST be the ID of a 529 certificate for which proof of possession has been presented in a 530 "CERTIFICATE_PROOF" frame. Recipients of a "USE_CERTIFICATE" frame 531 of any other length MUST treat this as a stream error of type 532 "PROTOCOL_ERROR". Frames with identical certificate identifiers 533 refer to the same certificate chain. 535 The "USE_CERTIFICATE" frame MUST NOT be sent on stream zero or a 536 stream on which a "CERTIFICATE_NEEDED" frame has not been received. 537 Receipt of a "USE_CERTIFICATE" frame in these circmustances SHOULD be 538 treated as a stream error of type "PROTOCOL_ERROR". Each 539 "USE_CERTIFICATE" frame should reference a preceding 540 "CERTIFICATE_PROOF" frame. Receipt of a "USE_CERTIFICATE" frame 541 before the necessary frames have been received on stream zero MUST 542 also result in a stream error of type "PROTOCOL_ERROR". 544 The referenced certificate chain MUST conform to the requirements 545 expressed in the "CERTIFICATE_REQUEST" to the best of the sender's 546 ability. Specifically: 548 o If the "CERTIFICATE_REQUEST" contained a non-empty "Certificate- 549 Authorities" element, one of the certificates in the chain SHOULD 550 be signed by one of the listed CAs. 552 o If the "CERTIFICATE_REQUEST" contained a non-empty "Cert- 553 Extensions" element, the first certificate MUST match with regard 554 to the extension OIDs recognized by the sender. 556 If these requirements are not satisfied, the recipient MAY at its 557 discretion either return an error at the HTTP semantic layer, or 558 respond with a stream error [RFC7540] on any stream where the 559 certificate is used. Section 4 defines certificate-related error 560 codes which might be applicable. 562 3.3. The CERTIFICATE_REQUEST Frame 564 TLS 1.3 defines the "CertificateRequest" message, which prompts the 565 client to provide a certificate which conforms to certain properties 566 specified by the server. This draft defines the 567 "CERTIFICATE_REQUEST" frame (0xFRAME-TBD1), which contains the same 568 contents as a TLS 1.3 "CertificateRequest" message, but can be sent 569 over any TLS version. 571 The "CERTIFICATE_REQUEST" frame SHOULD NOT be sent to a peer which 572 has not advertised support for HTTP-layer certificate authentication. 574 The "CERTIFICATE_REQUEST" frame MUST be sent on stream zero. A 575 "CERTIFICATE_REQUEST" frame received on any other stream MUST be 576 rejected with a stream error of type "PROTOCOL_ERROR". 578 0 1 2 3 579 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 580 +-------------------------------+---------------+---------------+ 581 | Request-ID (8)| CA-Count (16) | 582 +-----------------------------------------------+---------------+ 583 | Certificate-Authorities (?) ... 584 +---------------------------------------------------------------+ 585 | Cert-Extension-Count (16) | Cert-Extensions(?) ... 586 +---------------------------------------------------------------+ 588 Figure 7: CERTIFICATE_REQUEST frame payload 590 The frame contains the following fields: 592 Request-ID: "Request-ID" is an 8-bit opaque identifier used to 593 correlate subsequent certificate-related frames with this request. 594 The identifier MUST be unique in the session for the sender. 596 CA-Count and Certificate-Authorities: "Certificate-Authorities" is a 597 series of distinguished names of acceptable certificate 598 authorities, represented in DER-encoded [X690] format. These 599 distinguished names may specify a desired distinguished name for a 600 root CA or for a subordinate CA; thus, this message can be used to 601 describe known roots as well as a desired authorization space. 602 The number of such structures is given by the 16-bit "CA-Count" 603 field, which MAY be zero. If the "CA-Count" field is zero, then 604 the recipient MAY send any certificate that meets the rest of the 605 selection criteria in the "CERTIFICATE_REQUEST", unless there is 606 some external arrangement to the contrary. 608 Cert-Extension-Count and Cert-Extensions: A list of certificate 609 extension OIDs [RFC5280] with their allowed values, represented in 610 a series of "CertificateExtension" structures (see 611 [I-D.ietf-tls-tls13] section 6.3.5). The list of OIDs MUST be 612 used in certificate selection as described in 613 [I-D.ietf-tls-tls13]. The number of Cert-Extension structures is 614 given by the 16-bit "Cert-Extension-Count" field, which MAY be 615 zero. 617 Some certificate extension OIDs allow multiple values (e.g. Extended 618 Key Usage). If the sender has included a non-empty Cert-Extensions 619 list, the certificate MUST contain all of the specified extension 620 OIDs that the recipient recognizes. For each extension OID 621 recognized by the recipient, all of the specified values MUST be 622 present in the certificate (but the certificate MAY have other values 623 as well). However, the recipient MUST ignore and skip any 624 unrecognized certificate extension OIDs. 626 Servers MUST be able to recognize the "subjectAltName" extension 627 ([RFC2459] section 4.2.1.7) at a minimum. Clients MUST always 628 specify the desired origin using this extension, though other 629 extensions MAY also be included. 631 PKIX RFCs define a variety of certificate extension OIDs and their 632 corresponding value types. Depending on the type, matching 633 certificate extension values are not necessarily bitwise-equal. It 634 is expected that implementations will rely on their PKI libraries to 635 perform certificate selection using these certificate extension OIDs. 637 3.4. The CERTIFICATE_PROOF Frame 639 The "CERTIFICATE_PROOF" frame provides a exported authenticator 640 message from the TLS layer that provides a chain of certificates, 641 associated extensions and proves possession of the private key 642 corresponding to the end-entity certificate. 644 The "CERTIFICATE_PROOF" frame defines one flag: 646 AUTOMATIC_USE (0x01): Indicates that the certificate can be used 647 automatically on future requests. 649 0 1 2 3 650 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 651 +-------------------------------+-------------------------------+ 652 | Cert-ID (8) | Exported Authenticator(*)... 653 +---------------------------------------------------------------+ 655 Figure 8: CERTIFICATE_PROOF frame payload 657 The "CERTIFICATE_PROOF" frame (0xFRAME-TBD4) contains an "Exported 658 Authenticator" field which corresponds to the value returned from the 659 TLS connection exported authenticator API when provided with a 660 certificate, a valid certificate chain for the connection and 661 associated extensions (OCSP, SCT, etc.), and a connection-unique 662 8-byte certificate_request_context value. 664 If the "AUTOMATIC_USE" flag is set, the recipient MAY omit sending 665 "CERTIFICATE_NEEDED" frames on future streams which would require a 666 similar certificate and use the referenced certificate for 667 authentication without further notice to the holder. This behavior 668 is optional, and receipt of a "CERTIFICATE_NEEDED" frame does not 669 imply that previously-presented certificates were unacceptable, even 670 if "AUTOMATIC_USE" was set. Servers MUST set the "AUTOMATIC_USE" 671 flag when sending a "CERTIFICATE_PROOF" frame. A server MUST NOT 672 send certificates for origins which it is not prepared to service on 673 the current connection. 675 Upon recieving a CERTIFICATE_PROOF frame, the reciever may validate 676 the Exported Authenticator value by using the exported authenticator 677 API. This return either an error indicating that the message was 678 invalid, or the certificate chain and extensions used to create the 679 message. 681 4. Indicating failures during HTTP-Layer Certificate Authentication 683 Because this draft permits certificates to be exchanged at the HTTP 684 framing layer instead of the TLS layer, several certificate-related 685 errors which are defined at the TLS layer might now occur at the HTTP 686 framing layer. In this section, those errors are restated and added 687 to the HTTP/2 error code registry. 689 BAD_CERTIFICATE (0xERROR-TBD1): A certificate was corrupt, contained 690 signatures that did not verify correctly, etc. 692 UNSUPPORTED_CERTIFICATE (0xERROR-TBD2): A certificate was of an 693 unsupported type or did not contain required extensions 695 CERTIFICATE_REVOKED (0xERROR-TBD3): A certificate was revoked by its 696 signer 698 CERTIFICATE_EXPIRED (0xERROR-TBD4): A certificate has expired or is 699 not currently valid 701 CERTIFICATE_TOO_LARGE (0xERROR-TBD5): The certificate cannot be 702 transferred due to the recipient's "SETTINGS_MAX_FRAME_SIZE" 704 CERTIFICATE_GENERAL (0xERROR-TBD6): Any other certificate-related 705 error 707 As described in [RFC7540], implementations MAY choose to treat a 708 stream error as a connection error at any time. Of particular note, 709 a stream error cannot occur on stream 0, which means that 710 implementations cannot send non-session errors in response to 711 "CERTIFICATE_REQUEST", and "CERTIFICATE_PROOF" frames. 712 Implementations which do not wish to terminate the connection MAY 713 either send relevant errors on any stream which references the 714 failing certificate in question or process the requests as 715 unauthenticated and provide error information at the HTTP semantic 716 layer. 718 5. Security Considerations 720 This mechanism defines an alternate way to obtain server and client 721 certificates other than in the initial TLS handshake. While the 722 signature of exported authenticator values is expected to be equally 723 secure, it is important to recognize that a vulnerability in this 724 code path is at least equal to a vulnerability in the TLS handshake. 726 This could also increase the impact of a key compromise. Rather than 727 needing to subvert DNS or IP routing in order to use a compromised 728 certificate, a malicious server now only needs a client to connect to 729 _some_ HTTPS site under its control. Clients SHOULD continue to 730 validate that destination IP addresses are valid for the origin 731 either by direct DNS resolution or resolution of a validated 732 Alternative Service. (Future work could include a mechanism for a 733 server to offer proofs.) 735 This draft defines a mechanism which could be used to probe servers 736 for origins they support, but opens no new attack versus making 737 repeat TLS connections with different SNI values. Servers SHOULD 738 impose similar denial-of-service mitigations (e.g. request rate 739 limits) to "CERTIFICATE_REQUEST" frames as to new TLS connections. 741 While the "CERTIFICATE_REQUEST" frame permits the sender to enumerate 742 the acceptable Certificate Authorities for the requested certificate, 743 it might not be prudent (either for security or data consumption) to 744 include the full list of trusted Certificate Authorities in every 745 request. Senders, particularly clients, are advised to send an empty 746 "Certificate-Authorities" element unless they are expecting a 747 certificate to be signed by a particular CA or small set of CAs. 749 Failure to provide a certificate on a stream after receiving 750 "CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to 751 standard timeouts used to guard against unresponsive peers. 753 Client implementations need to carefully consider the impact of 754 setting the "AUTOMATIC_USE" flag. This flag is a performance 755 optimization, permitting the client to avoid a round-trip on each 756 request where the server checks for certificate authentication. 757 However, once this flag has been sent, the client has zero knowledge 758 about whether the server will use the referenced cert for any future 759 request, or even for an existing request which has not yet completed. 760 Clients MUST NOT set this flag on any certificate which is not 761 appropriate for currently-in-flight requests, and MUST NOT make any 762 future requests on the same connection which they are not willing to 763 have associated with the provided certificate. 765 Implementations need to be aware of the potential for confusion about 766 the state of a connection. The presence or absence of a validated 767 certificate can change during the processing of a request, 768 potentially multiple times, as "USE_CERTIFICATE" frames are received. 769 A server that uses certificate authentication needs to be prepared to 770 reevaluate the authorization state of a request as the set of 771 certificates changes. 773 Finally, validating a multitude of signatures can be computationally 774 expensive, while generating an invalid signature is computationally 775 cheap. Implementations will require checks against attacks from this 776 direction. Signature proofs SHOULD NOT be validated until a stream 777 requires the certificate to make progress. A signature which is not 778 valid based on the asserted public key SHOULD be treated as a session 779 error, to avoid further attacks from the peer, though an 780 implementation MAY instead disable HTTP-layer certificates for the 781 current connection instead. 783 6. IANA Considerations 785 This draft adds entries in three registries. 787 The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in 788 Section 6.1. Five frame types are registered in Section 6.2. Six 789 error codes are registered in Section 6.3. 791 6.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting 793 The SETTINGS_HTTP_CERT_AUTH setting is registered in the "HTTP/2 794 Settings" registry established in [RFC7540]. 796 Name: SETTINGS_HTTP_CERT_AUTH 798 Code: 0xSETTING-TBD 800 Initial Value: 0 801 Specification: This document. 803 6.2. New HTTP/2 Frames 805 Four new frame types are registered in the "HTTP/2 Frame Types" 806 registry established in [RFC7540]. The entries in the following 807 table are registered by this document. 809 +---------------------+--------------+-------------------------+ 810 | Frame Type | Code | Specification | 811 +---------------------+--------------+-------------------------+ 812 | CERTIFICATE_NEEDED | 0xFRAME-TBD1 | {{http-cert-needed}} | 813 | CERTIFICATE_REQUEST | 0xFRAME-TBD2 | {{http-cert-request}} | 814 | CERTIFICATE_PROOF | 0xFRAME-TBD3 | {{http-cert-proof}} | 815 | USE_CERTIFICATE | 0xFRAME-TBD4 | {{http-use-certificate}}| 816 +---------------------+--------------+-------------------------+ 818 Figure 9 820 6.3. New HTTP/2 Error Codes 822 Five new error codes are registered in the "HTTP/2 Error Code" 823 registry established in [RFC7540]. The entries in the following 824 table are registered by this document. 826 +-------------------------+--------------+-------------------------+ 827 | Name | Code | Specification | 828 +-------------------------+--------------+-------------------------+ 829 | BAD_CERTIFICATE | 0xERROR-TBD1 | {{errors}} | 830 | UNSUPPORTED_CERTIFICATE | 0xERROR-TBD2 | {{errors}} | 831 | CERTIFICATE_REVOKED | 0xERROR-TBD3 | {{errors}} | 832 | CERTIFICATE_EXPIRED | 0xERROR-TBD4 | {{errors}} | 833 | CERTIFICATE_GENERAL | 0xERROR-TBD5 | {{errors}} | 834 +-------------------------+--------------+-------------------------+ 836 Figure 10 838 7. Acknowledgements 840 Eric Rescorla pointed out several failings in an earlier revision. 841 Andrei Popov contributed to the TLS considerations. 843 8. References 844 8.1. Normative References 846 [I-D.ietf-tls-tls13] 847 Rescorla, E., "The Transport Layer Security (TLS) Protocol 848 Version 1.3", draft-ietf-tls-tls13-18 (work in progress), 849 October 2016. 851 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 852 Requirement Levels", BCP 14, RFC 2119, 853 DOI 10.17487/RFC2119, March 1997, 854 . 856 [RFC2459] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet 857 X.509 Public Key Infrastructure Certificate and CRL 858 Profile", RFC 2459, DOI 10.17487/RFC2459, January 1999, 859 . 861 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 862 (TLS) Protocol Version 1.2", RFC 5246, 863 DOI 10.17487/RFC5246, August 2008, 864 . 866 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 867 Housley, R., and W. Polk, "Internet X.509 Public Key 868 Infrastructure Certificate and Certificate Revocation List 869 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 870 . 872 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 873 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 874 March 2010, . 876 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 877 Protocol (HTTP/1.1): Message Syntax and Routing", 878 RFC 7230, DOI 10.17487/RFC7230, June 2014, 879 . 881 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 882 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 883 DOI 10.17487/RFC7540, May 2015, 884 . 886 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 887 Langley, A., and M. Ray, "Transport Layer Security (TLS) 888 Session Hash and Extended Master Secret Extension", 889 RFC 7627, DOI 10.17487/RFC7627, September 2015, 890 . 892 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 893 Specification of Basic Encoding Rules (BER), Canonical 894 Encoding Rules (CER) and Distinguished Encoding Rules 895 (DER)", ISO ISO/IEC 8825-1:2002, 2002, 896 . 899 8.2. Informative References 901 [FIPS-186-4] 902 National Institute of Standards and Technology, "Digital 903 Signature Standard (DSS)", FIPS 186-4, July 2013, 904 . 907 [I-D.ietf-httpbis-alt-svc] 908 Nottingham, M., McManus, P., and J. Reschke, "HTTP 909 Alternative Services", draft-ietf-httpbis-alt-svc-14 (work 910 in progress), March 2016. 912 [I-D.josefsson-eddsa-ed25519] 913 Josefsson, S. and N. Moller, "EdDSA and Ed25519", draft- 914 josefsson-eddsa-ed25519-03 (work in progress), May 2015. 916 [I-D.nottingham-httpbis-origin-frame] 917 Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", 918 draft-nottingham-httpbis-origin-frame-01 (work in 919 progress), January 2016. 921 [PKCS.1.1991] 922 RSA Laboratories, "RSA Encryption Standard, Version 1.1", 923 PKCS 1, June 1991. 925 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 926 Adams, "X.509 Internet Public Key Infrastructure Online 927 Certificate Status Protocol - OCSP", RFC 2560, 928 DOI 10.17487/RFC2560, June 1999, 929 . 931 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 932 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 933 . 935 Authors' Addresses 936 Mike Bishop 937 Microsoft 939 Email: michael.bishop@microsoft.com 941 Martin Thomson 942 Mozilla 944 Email: martin.thomson@gmail.com