draft-ietf-httpbis-http2-secondary-certs-02.txt   draft-ietf-httpbis-http2-secondary-certs-03.txt 
HTTP M. Bishop HTTP M. Bishop
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track N. Sullivan Intended status: Standards Track N. Sullivan
Expires: December 28, 2018 Cloudflare Expires: April 26, 2019 Cloudflare
M. Thomson M. Thomson
Mozilla Mozilla
June 26, 2018 October 23, 2018
Secondary Certificate Authentication in HTTP/2 Secondary Certificate Authentication in HTTP/2
draft-ietf-httpbis-http2-secondary-certs-02 draft-ietf-httpbis-http2-secondary-certs-03
Abstract Abstract
A use of TLS Exported Authenticators is described which enables A use of TLS Exported Authenticators is described which enables
HTTP/2 clients and servers to offer additional certificate-based HTTP/2 clients and servers to offer additional certificate-based
credentials after the connection is established. The means by which credentials after the connection is established. The means by which
these credentials are used with requests is defined. these credentials are used with requests is defined.
Note to Readers Note to Readers
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 28, 2018. This Internet-Draft will expire on April 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 45 skipping to change at page 2, line 45
2.3.1. Requiring Additional Server Certificates . . . . . . 10 2.3.1. Requiring Additional Server Certificates . . . . . . 10
2.3.2. Requiring Additional Client Certificates . . . . . . 11 2.3.2. Requiring Additional Client Certificates . . . . . . 11
3. Certificates Frames for HTTP/2 . . . . . . . . . . . . . . . 12 3. Certificates Frames for HTTP/2 . . . . . . . . . . . . . . . 12
3.1. The CERTIFICATE_NEEDED Frame . . . . . . . . . . . . . . 12 3.1. The CERTIFICATE_NEEDED Frame . . . . . . . . . . . . . . 12
3.2. The USE_CERTIFICATE Frame . . . . . . . . . . . . . . . . 14 3.2. The USE_CERTIFICATE Frame . . . . . . . . . . . . . . . . 14
3.3. The CERTIFICATE_REQUEST Frame . . . . . . . . . . . . . . 15 3.3. The CERTIFICATE_REQUEST Frame . . . . . . . . . . . . . . 15
3.3.1. Exported Authenticator Request Characteristics . . . 16 3.3.1. Exported Authenticator Request Characteristics . . . 16
3.4. The CERTIFICATE Frame . . . . . . . . . . . . . . . . . . 16 3.4. The CERTIFICATE Frame . . . . . . . . . . . . . . . . . . 16
3.4.1. Exported Authenticator Characteristics . . . . . . . 17 3.4.1. Exported Authenticator Characteristics . . . . . . . 17
4. Indicating Failures During HTTP-Layer Certificate 4. Indicating Failures During HTTP-Layer Certificate
Authentication . . . . . . . . . . . . . . . . . . . . . . . 17 Authentication . . . . . . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Impersonation . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Impersonation . . . . . . . . . . . . . . . . . . . . . . 19
5.2. Fingerprinting . . . . . . . . . . . . . . . . . . . . . 19 5.2. Fingerprinting . . . . . . . . . . . . . . . . . . . . . 19
5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 19 5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 19
5.4. Confusion About State . . . . . . . . . . . . . . . . . . 19 5.4. Confusion About State . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting . . . . . . . . . 20 6.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting . . . . . . . . . 20
6.2. New HTTP/2 Frames . . . . . . . . . . . . . . . . . . . . 20 6.2. New HTTP/2 Frames . . . . . . . . . . . . . . . . . . . . 21
6.3. New HTTP/2 Error Codes . . . . . . . . . . . . . . . . . 21 6.3. New HTTP/2 Error Codes . . . . . . . . . . . . . . . . . 21
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 21 7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 22 7.2. Informative References . . . . . . . . . . . . . . . . . 22
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23
A.1. Since draft-ietf-httpbis-http2-secondary-certs-01: . . . 23 A.1. Since draft-ietf-httpbis-http2-secondary-certs-01: . . . 23
A.2. Since draft-ietf-httpbis-http2-secondary-certs-00: . . . 23 A.2. Since draft-ietf-httpbis-http2-secondary-certs-00: . . . 23
A.3. Since draft-bishop-httpbis-http2-additional-certs-05: . . 23 A.3. Since draft-bishop-httpbis-http2-additional-certs-05: . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
HTTP clients need to know that the content they receive on a HTTP clients need to know that the content they receive on a
skipping to change at page 5, line 18 skipping to change at page 5, line 18
Many other uses for client certificates are reactive, that is, Many other uses for client certificates are reactive, that is,
certificates are requested in response to the client making a certificates are requested in response to the client making a
request. request.
1.2.1. HTTP/1.1 Using TLS 1.2 and Earlier 1.2.1. HTTP/1.1 Using TLS 1.2 and Earlier
In HTTP/1.1, a server that relies on client authentication for a In HTTP/1.1, a server that relies on client authentication for a
subset of users or resources does not request a certificate when the subset of users or resources does not request a certificate when the
connection is established. Instead, it only requests a client connection is established. Instead, it only requests a client
certificate when a request is made to a resource that requires a certificate when a request is made to a resource that requires a
certificate. TLS 1.2 [RFC5246] accomodates this by permitting the certificate. TLS 1.2 [RFC5246] accommodates this by permitting the
server to request a new TLS handshake, in which the server will server to request a new TLS handshake, in which the server will
request the client's certificate. request the client's certificate.
Figure 1 shows the server initiating a TLS-layer renegotiation in Figure 1 shows the server initiating a TLS-layer renegotiation in
response to receiving an HTTP/1.1 request to a protected resource. response to receiving an HTTP/1.1 request to a protected resource.
Client Server Client Server
-- (HTTP) GET /protected -------------------> *1 -- (HTTP) GET /protected -------------------> *1
<---------------------- (TLS) HelloRequest -- *2 <---------------------- (TLS) HelloRequest -- *2
-- (TLS) ClientHello -----------------------> -- (TLS) ClientHello ----------------------->
skipping to change at page 16, line 50 skipping to change at page 16, line 50
spans more than one frame. spans more than one frame.
0 1 2 3 0 1 2 3
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 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
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| Cert-ID (16) | Authenticator Fragment (*)... | Cert-ID (16) | Authenticator Fragment (*)...
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 11: CERTIFICATE frame payload Figure 11: CERTIFICATE frame payload
The "Exported Authenticator Fragment" field contains a portion of the The frame contains the following fields:
opaque data returned from the TLS connection exported authenticator
"authenticate" API. See Section 3.4.1 for more details on the input
to this API.
This opaque data is transported in zero or more "CERTIFICATE" frames Cert-ID: "Cert-ID" is a 16-bit opaque identifier used to correlate
with the "TO_BE_CONTINUED" flag set, followed by one "CERTIFICATE" other certificate- related frames with this exported authenticator
frame with the "TO_BE_CONTINUED" flag unset. Each of these frames fragment.
contains the same "Cert-ID" field, permitting them to be associated
with each other. Receipt of any "CERTIFICATE" frame with the same Authenticator Fragment: A portion of the opaque data returned from
"Cert-ID" following the receipt of a "CERTIFICATE" frame with the TLS connection exported authenticator "authenticate" API. See
"TO_BE_CONTINUED" unset MUST be treated as a connection error of type Section 3.4.1 for more details on the input to this API.
"PROTOCOL_ERROR".
An exported authenticator is transported in zero or more
"CERTIFICATE" frames with the "TO_BE_CONTINUED" flag set, followed by
one "CERTIFICATE" frame with the "TO_BE_CONTINUED" flag unset. Each
of these frames contains the same "Cert-ID" field, permitting them to
be associated with each other. Receipt of any "CERTIFICATE" frame
with the same "Cert-ID" following the receipt of a "CERTIFICATE"
frame with "TO_BE_CONTINUED" unset MUST be treated as a connection
error of type "PROTOCOL_ERROR".
Upon receiving a complete series of "CERTIFICATE" frames, the Upon receiving a complete series of "CERTIFICATE" frames, the
receiver may validate the Exported Authenticator value by using the receiver may validate the Exported Authenticator value by using the
exported authenticator API. This returns either an error indicating exported authenticator API. This returns either an error indicating
that the message was invalid, or the certificate chain and extensions that the message was invalid, or the certificate chain and extensions
used to create the message. used to create the message.
The "CERTIFICATE" frame MUST be sent on stream zero. A "CERTIFICATE" The "CERTIFICATE" frame MUST be sent on stream zero. A "CERTIFICATE"
frame received on any other stream MUST be rejected with a stream frame received on any other stream MUST be rejected with a stream
error of type "PROTOCOL_ERROR". error of type "PROTOCOL_ERROR".
3.4.1. Exported Authenticator Characteristics 3.4.1. Exported Authenticator Characteristics
The Exported Authenticator API defined in The Exported Authenticator API defined in
[I-D.ietf-tls-exported-authenticator] takes as input a request, a set [I-D.ietf-tls-exported-authenticator] takes as input a request, a set
of certificates, and supporting information about the certificate of certificates, and supporting information about the certificate
(OCSP, SCT, etc.). The result is an opaque token which is used when (OCSP, SCT, etc.). The result is an opaque token which is used when
generating the "CERTIFICATE" frame. generating the "CERTIFICATE" frame.
Upon receipt of a "CERTIFICATE" frame, an endpoint MUST perform the Upon receipt of a "CERTIFICATE" frame, an endpoint MUST perform the
following steps to validate the token it contains: - Using the "get following steps to validate the token it contains:
context" API, retrieve the "certificate_request_context" used to
generate the authenticator, if any. - Verify that the o Using the "get context" API, retrieve the
"certificate_request_context" is either empty (clients only) or "certificate_request_context" used to generate the authenticator,
contains the Request-ID of a previously-sent "CERTIFICATE_REQUEST" if any.
frame. - Use the "validate" API to confirm the validity of the
authenticator with regard to the generated request (if any). o Verify that the "certificate_request_context" is either empty
(clients only) or contains the Request-ID of a previously-sent
"CERTIFICATE_REQUEST" frame.
o Use the "validate" API to confirm the validity of the
authenticator with regard to the generated request (if any).
Once the authenticator is accepted, the endpoint can perform any Once the authenticator is accepted, the endpoint can perform any
other checks for the acceptability of the certificate itself. other checks for the acceptability of the certificate itself.
4. Indicating Failures During HTTP-Layer Certificate Authentication 4. Indicating Failures During HTTP-Layer Certificate Authentication
Because this draft permits certificates to be exchanged at the HTTP Because this draft permits certificates to be exchanged at the HTTP
framing layer instead of the TLS layer, several certificate-related framing layer instead of the TLS layer, several certificate-related
errors which are defined at the TLS layer might now occur at the HTTP errors which are defined at the TLS layer might now occur at the HTTP
framing layer. In this section, those errors are restated and added framing layer. In this section, those errors are restated and added
skipping to change at page 19, line 10 skipping to change at page 19, line 20
to connect to _some_ HTTPS site under its control in order to present to connect to _some_ HTTPS site under its control in order to present
the compromised certificate. As recommended in [RFC8336], clients the compromised certificate. As recommended in [RFC8336], clients
opting not to consult DNS ought to employ some alternative means to opting not to consult DNS ought to employ some alternative means to
increase confidence that the certificate is legitimate. increase confidence that the certificate is legitimate.
As noted in the Security Considerations of As noted in the Security Considerations of
[I-D.ietf-tls-exported-authenticator], it difficult to formally prove [I-D.ietf-tls-exported-authenticator], it difficult to formally prove
that an endpoint is jointly authoritative over multiple certificates, that an endpoint is jointly authoritative over multiple certificates,
rather than individually authoritative on each certificate. As a rather than individually authoritative on each certificate. As a
result, clients MUST NOT assume that because one origin was result, clients MUST NOT assume that because one origin was
previously colocated with another, those origins will be reachable previously collocated with another, those origins will be reachable
via the same endpoints in the future. Clients MUST NOT consider via the same endpoints in the future. Clients MUST NOT consider
previous secondary certificates to be validated after TLS session previous secondary certificates to be validated after TLS session
resumption. However, clients MAY proactively query for previously- resumption. However, clients MAY proactively query for previously-
presented secondary certificates. presented secondary certificates.
5.2. Fingerprinting 5.2. Fingerprinting
This draft defines a mechanism which could be used to probe servers This draft defines a mechanism which could be used to probe servers
for origins they support, but opens no new attack versus making for origins they support, but opens no new attack versus making
repeat TLS connections with different SNI values. Servers SHOULD repeat TLS connections with different SNI values. Servers SHOULD
skipping to change at page 21, line 45 skipping to change at page 21, line 51
| | | | | | | |
| CERTIFICATE_OVERUSED | 0xERROR-TBD6 | Section 4 | | CERTIFICATE_OVERUSED | 0xERROR-TBD6 | Section 4 |
+-------------------------+--------------+---------------+ +-------------------------+--------------+---------------+
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-tls-exported-authenticator] [I-D.ietf-tls-exported-authenticator]
Sullivan, N., "Exported Authenticators in TLS", draft- Sullivan, N., "Exported Authenticators in TLS", draft-
ietf-tls-exported-authenticator-04 (work in progress), ietf-tls-exported-authenticator-07 (work in progress),
October 2017. June 2018.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-22 (work in progress), Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
November 2017. March 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
 End of changes. 16 change blocks. 
34 lines changed or deleted 44 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/