draft-ietf-httpbis-http2-secondary-certs-04.txt   draft-ietf-httpbis-http2-secondary-certs-05.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: October 27, 2019 Cloudflare Expires: May 3, 2020 Cloudflare
M. Thomson M. Thomson
Mozilla Mozilla
April 25, 2019 October 31, 2019
Secondary Certificate Authentication in HTTP/2 Secondary Certificate Authentication in HTTP/2
draft-ietf-httpbis-http2-secondary-certs-04 draft-ietf-httpbis-http2-secondary-certs-05
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 October 27, 2019. This Internet-Draft will expire on May 3, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Server Certificate Authentication . . . . . . . . . . . . 3 1.1. Server Certificate Authentication . . . . . . . . . . . . 4
1.2. Client Certificate Authentication . . . . . . . . . . . . 4 1.2. Client Certificate Authentication . . . . . . . . . . . . 4
1.2.1. HTTP/1.1 Using TLS 1.2 and Earlier . . . . . . . . . 5 1.2.1. HTTP/1.1 Using TLS 1.2 and Earlier . . . . . . . . . 5
1.2.2. HTTP/1.1 Using TLS 1.3 . . . . . . . . . . . . . . . 6 1.2.2. HTTP/1.1 Using TLS 1.3 . . . . . . . . . . . . . . . 6
1.2.3. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.3. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. HTTP-Layer Certificate Authentication . . . . . . . . . . 7 1.3. HTTP-Layer Certificate Authentication . . . . . . . . . . 7
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
2. Discovering Additional Certificates at the HTTP/2 Layer . . . 8 2. Discovering Additional Certificates at the HTTP/2 Layer . . . 8
2.1. Indicating Support for HTTP-Layer Certificate 2.1. Indicating Support for HTTP-Layer Certificate
Authentication . . . . . . . . . . . . . . . . . . . . . 8 Authentication . . . . . . . . . . . . . . . . . . . . . 9
2.2. Making Certificates or Requests Available . . . . . . . . 9 2.2. Making Certificates or Requests Available . . . . . . . . 9
2.3. Requiring Certificate Authentication . . . . . . . . . . 10 2.3. Requiring Certificate Authentication . . . . . . . . . . 10
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 . . . . . . . . . . . . . . 13 3.1. The CERTIFICATE_NEEDED Frame . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . 17
3.4.1. Exported Authenticator Characteristics . . . . . . . 18 3.4.1. Exported Authenticator Characteristics . . . . . . . 18
4. Indicating Failures During HTTP-Layer Certificate 4. Indicating Failures During HTTP-Layer Certificate
Authentication . . . . . . . . . . . . . . . . . . . . . . . 18 Authentication . . . . . . . . . . . . . . . . . . . . . . . 19
5. Required Domain Certificate Extension . . . . . . . . . . . . 19 5. Required Domain Certificate Extension . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.1. Impersonation . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Impersonation . . . . . . . . . . . . . . . . . . . . . . 20
6.2. Fingerprinting . . . . . . . . . . . . . . . . . . . . . 21 6.2. Fingerprinting . . . . . . . . . . . . . . . . . . . . . 21
6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 21 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 21
6.4. Persistence of Service . . . . . . . . . . . . . . . . . 21 6.4. Persistence of Service . . . . . . . . . . . . . . . . . 21
6.5. Confusion About State . . . . . . . . . . . . . . . . . . 22 6.5. Confusion About State . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting . . . . . . . . . 22 7.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting . . . . . . . . . 22
7.2. New HTTP/2 Frames . . . . . . . . . . . . . . . . . . . . 22 7.2. New HTTP/2 Frames . . . . . . . . . . . . . . . . . . . . 22
7.3. New HTTP/2 Error Codes . . . . . . . . . . . . . . . . . 23 7.3. New HTTP/2 Error Codes . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . 23 8.1. Normative References . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . 24
8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25
A.1. Since draft-ietf-httpbis-http2-secondary-certs-03: . . . 25 A.1. Since draft-ietf-httpbis-http2-secondary-certs-04: . . . 25
A.2. Since draft-ietf-httpbis-http2-secondary-certs-02: . . . 25 A.2. Since draft-ietf-httpbis-http2-secondary-certs-03: . . . 25
A.3. Since draft-ietf-httpbis-http2-secondary-certs-01: . . . 25 A.3. Since draft-ietf-httpbis-http2-secondary-certs-02: . . . 25
A.4. Since draft-ietf-httpbis-http2-secondary-certs-00: . . . 25 A.4. Since draft-ietf-httpbis-http2-secondary-certs-01: . . . 25
A.5. Since draft-bishop-httpbis-http2-additional-certs-05: . . 26 A.5. Since draft-ietf-httpbis-http2-secondary-certs-00: . . . 26
A.6. Since draft-bishop-httpbis-http2-additional-certs-05: . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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
connection comes from the origin that they intended to retrieve it connection comes from the origin that they intended to retrieve it
from. The traditional form of server authentication in HTTP has been from. The traditional form of server authentication in HTTP has been
in the form of a single X.509 certificate provided during the TLS in the form of a single X.509 certificate provided during the TLS
([RFC5246], [RFC8446]) handshake. ([RFC5246], [RFC8446]) handshake.
skipping to change at page 21, line 23 skipping to change at page 21, line 34
While the extensions in the "CERTIFICATE_REQUEST" frame permit the While the extensions in the "CERTIFICATE_REQUEST" frame permit the
sender to enumerate the acceptable Certificate Authorities for the sender to enumerate the acceptable Certificate Authorities for the
requested certificate, it might not be prudent (either for security requested certificate, it might not be prudent (either for security
or data consumption) to include the full list of trusted Certificate or data consumption) to include the full list of trusted Certificate
Authorities in every request. Senders, particularly clients, SHOULD Authorities in every request. Senders, particularly clients, SHOULD
send only the extensions that narrowly specify which certificates send only the extensions that narrowly specify which certificates
would be acceptable. would be acceptable.
6.3. Denial of Service 6.3. Denial of Service
Failure to provide a certificate on a stream after receiving Failure to provide a certificate for a stream after receiving
"CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to "CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to
standard timeouts used to guard against unresponsive peers. standard timeouts used to guard against unresponsive peers.
Validating a multitude of signatures can be computationally Validating a multitude of signatures can be computationally
expensive, while generating an invalid signature is computationally expensive, while generating an invalid signature is computationally
cheap. Implementations will require checks for attacks from this cheap. Implementations will require checks for attacks from this
direction. Invalid exported authenticators SHOULD be treated as a direction. Invalid exported authenticators SHOULD be treated as a
session error, to avoid further attacks from the peer, though an session error, to avoid further attacks from the peer, though an
implementation MAY instead disable HTTP-layer certificates for the implementation MAY instead disable HTTP-layer certificates for the
current connection instead. current connection instead.
skipping to change at page 22, line 15 skipping to change at page 22, line 27
6.5. Confusion About State 6.5. Confusion About State
Implementations need to be aware of the potential for confusion about Implementations need to be aware of the potential for confusion about
the state of a connection. The presence or absence of a validated the state of a connection. The presence or absence of a validated
certificate can change during the processing of a request, certificate can change during the processing of a request,
potentially multiple times, as "USE_CERTIFICATE" frames are received. potentially multiple times, as "USE_CERTIFICATE" frames are received.
A server that uses certificate authentication needs to be prepared to A server that uses certificate authentication needs to be prepared to
reevaluate the authorization state of a request as the set of reevaluate the authorization state of a request as the set of
certificates changes. certificates changes.
Client implementations need to carefully consider the impact of
setting the "AUTOMATIC_USE" flag. This flag is a performance
optimization, permitting the client to avoid a round-trip on each
request where the server checks for certificate authentication.
However, once this flag has been sent, the client has zero knowledge
about whether the server will use the referenced cert for any future
request, or even for an existing request which has not yet completed.
Clients MUST NOT set this flag on any certificate which is not
appropriate for currently-in-flight requests, and MUST NOT make any
future requests on the same connection which they are not willing to
have associated with the provided certificate.
7. IANA Considerations 7. IANA Considerations
This draft adds entries in three registries. This draft adds entries in three registries.
The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in The HTTP/2 "SETTINGS_HTTP_CERT_AUTH" setting is registered in
Section 7.1. Four frame types are registered in Section 7.2. Six Section 7.1. Four frame types are registered in Section 7.2. Six
error codes are registered in Section 7.3. error codes are registered in Section 7.3.
7.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting 7.1. HTTP/2 SETTINGS_HTTP_CERT_AUTH Setting
skipping to change at page 23, line 45 skipping to change at page 23, line 45
| | | | | | | |
| CERTIFICATE_OVERUSED | 0xERROR-TBD6 | Section 4 | | CERTIFICATE_OVERUSED | 0xERROR-TBD6 | Section 4 |
+-------------------------+--------------+---------------+ +-------------------------+--------------+---------------+
8. References 8. References
8.1. Normative References 8.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-08 (work in progress), ietf-tls-exported-authenticator-09 (work in progress), May
October 2018. 2019.
[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>.
skipping to change at page 25, line 22 skipping to change at page 25, line 22
[2] http://httpwg.github.io/ [2] http://httpwg.github.io/
[3] https://github.com/httpwg/http-extensions/labels/secondary-certs [3] https://github.com/httpwg/http-extensions/labels/secondary-certs
Appendix A. Change Log Appendix A. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
A.1. Since draft-ietf-httpbis-http2-secondary-certs-03: A.1. Since draft-ietf-httpbis-http2-secondary-certs-04:
Editorial updates only.
A.2. Since draft-ietf-httpbis-http2-secondary-certs-03:
o "CERTIFICATE_REQUEST" frames contain the Request-ID, which MUST be o "CERTIFICATE_REQUEST" frames contain the Request-ID, which MUST be
checked against the "certificate_request_context" of the Exported checked against the "certificate_request_context" of the Exported
Authenticator Request Authenticator Request
o "CERTIFICATE" frames contain the Request-ID to which they respond, o "CERTIFICATE" frames contain the Request-ID to which they respond,
unless the UNSOLICITED flag is set unless the UNSOLICITED flag is set
o The Required Domain extension is defined for certificates, which o The Required Domain extension is defined for certificates, which
must be present for certificates presented by servers must be present for certificates presented by servers
A.2. Since draft-ietf-httpbis-http2-secondary-certs-02: A.3. Since draft-ietf-httpbis-http2-secondary-certs-02:
Editorial updates only. Editorial updates only.
A.3. Since draft-ietf-httpbis-http2-secondary-certs-01: A.4. Since draft-ietf-httpbis-http2-secondary-certs-01:
o Clients can send "CERTIFICATE_NEEDED" for stream 0 rather than o Clients can send "CERTIFICATE_NEEDED" for stream 0 rather than
speculatively reserving a stream for an origin. speculatively reserving a stream for an origin.
o Use SETTINGS to disable when a TLS-terminating proxy is present o Use SETTINGS to disable when a TLS-terminating proxy is present
(#617,#651) (#617,#651)
A.4. Since draft-ietf-httpbis-http2-secondary-certs-00: A.5. Since draft-ietf-httpbis-http2-secondary-certs-00:
o All frames sent on stream zero; replaced "AUTOMATIC_USE" on o All frames sent on stream zero; replaced "AUTOMATIC_USE" on
"CERTIFICATE" with "UNSOLICITED" on "USE_CERTIFICATE". (#482,#566) "CERTIFICATE" with "UNSOLICITED" on "USE_CERTIFICATE". (#482,#566)
o Use Exported Requests from the TLS Exported Authenticators draft; o Use Exported Requests from the TLS Exported Authenticators draft;
eliminate facilities for expressing certificate requirements in eliminate facilities for expressing certificate requirements in
"CERTIFICATE_REQUEST" frame. (#481) "CERTIFICATE_REQUEST" frame. (#481)
A.5. Since draft-bishop-httpbis-http2-additional-certs-05: A.6. Since draft-bishop-httpbis-http2-additional-certs-05:
o Adopted as draft-ietf-httpbis-http2-secondary-certs o Adopted as draft-ietf-httpbis-http2-secondary-certs
Acknowledgements Acknowledgements
Eric Rescorla pointed out several failings in an earlier revision. Eric Rescorla pointed out several failings in an earlier revision.
Andrei Popov contributed to the TLS considerations. Andrei Popov contributed to the TLS considerations.
A substantial portion of Mike's work on this draft was supported by A substantial portion of Mike's work on this draft was supported by
Microsoft during his employment there. Microsoft during his employment there.
 End of changes. 17 change blocks. 
33 lines changed or deleted 26 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/