Reactive Certificate-Based Client Authentication in HTTP/2
draft-thomson-http2-client-certs-02
Document | Type |
Replaced Internet-Draft
(httpbis WG)
Expired & archived
|
|
---|---|---|---|
Authors | Martin Thomson , Mike Bishop | ||
Last updated | 2016-03-15 (Latest revision 2016-03-14) | ||
Replaced by | draft-bishop-httpbis-http2-additional-certs | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | (None) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | Candidate for WG Adoption | |
Document shepherd | (None) | ||
IESG | IESG state | Replaced by draft-bishop-httpbis-http2-additional-certs | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Some HTTP servers provide a subset of resources that require additional authentication to interact with. HTTP/1.1 servers rely on TLS renegotiation that is triggered by a request to a protected resource. HTTP/2 made this pattern impossible by forbidding the use of TLS renegotiation. While TLS 1.3 provides an alternate mechanism to obtain client certificates, this mechanism does not map well to usage in TLS 1.2. This document describes a how client authentication might be requested by a server as a result of receiving a request to a protected resource.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)