One document matched: draft-thomson-http2-client-certs-00.txt
HTTP M. Thomson
Internet-Draft Mozilla
Updates: 7450 (if approved) M. Bishop
Intended status: Standards Track Microsoft
Expires: April 21, 2016 October 19, 2015
Reactive Certificate-Based Client Authentication in HTTP/2
draft-thomson-http2-client-certs-00
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.
This document describes a how client authentication might be
requested by a server as a result of receiving a request to a
protected resource. This document updates RFC 7540 to allow TLS
renegotiation in limited circumstances.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Thomson & Bishop Expires April 21, 2016 [Page 1]
Internet-Draft HTTP/2 Client Certs October 2015
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Reactive Certificate Authentication in HTTP/1.1 . . . . . 3
1.2. TLS 1.3 Client Authentication . . . . . . . . . . . . . . 4
1.3. Reactive Client Authentication in HTTP/2 . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. HTTP/2 Request Correlation in TLS 1.3 . . . . . . . . . . . . 5
3. HTTP/2 Request Correlation in TLS 1.2 . . . . . . . . . . . . 6
3.1. The TLS application_context_id Hello Extension . . . . . 6
3.2. Permitting TLS Renegotiation in HTTP/2 . . . . . . . . . 7
4. Indicating Stream Dependency on Certificate Authentication . 8
5. Indicating Support for Reactive Certificate Authentication . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. TLS application_context_id Extension . . . . . . . . . . 9
7.2. HTTP/2 SETTINGS_REACTIVE_AUTH Setting . . . . . . . . . . 9
7.3. HTTP/2 WAITING_FOR_AUTH Frame . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. Normative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Many existing HTTP [RFC7230] servers have different authentication
requirements for the different resources they serve. Of the
bountiful authentication options available for authenticating HTTP
requests, client certificates present a unique challenge for
resource-specific authentication requirements because of the
interaction with the underlying TLS RFC5246 [I-D.ietf-tls-tls13]
layer.
For servers that wish to use client certificates to authenticate
users, they might request client authentication during the TLS
handshake. However, if not all users or resources need certificate-
based authentication, a request for a certificate has the unfortunate
consequence of triggering the client to seek a certificate. Such a
request can result in a poor experience, particular when sent to a
client that does not expect the request.
Thomson & Bishop Expires April 21, 2016 [Page 2]
Internet-Draft HTTP/2 Client Certs October 2015
The TLS CertificateRequest can be used by servers to give clients
hints about which certificate to offer. Servers that rely on
certificate-based authentication might request different certificates
for different resources. Such a server cannot use contextual
information about the resource to construct an appropriate TLS
CertificateRequest message during the initial handshake.
Consequently, client certificates are requested at connection
establishment time only in cases where all clients are expected or
required to have a single certificate that is used for all resources.
Many other uses for client certificates are reactive, that is,
certificates are requested in response to the client making a
request.
CAVEAT: As of 2015-10-02, TLS 1.3 does not include the client
authentication features this draft relies on. While these
features have been agreed in the TLS working group, the exact
design is still under revision. The basic functionality shouldn't
change in a way that will affect this document, though some
details such as field names are highly likely to change.
1.1. Reactive Certificate Authentication in HTTP/1.1
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
connection is established. Instead, it only requests a client
certificate when a request is made to a resource that requires a
certificate.
Figure 1 shows the server initiating a TLS-layer renegotiation in
response to receiving an HTTP/1.1 request to a protected resource.
Client Server
-- (HTTP) GET /protected -------------------> *1
<---------------------- (TLS) HelloRequest -- *2
-- (TLS) ClientHello ----------------------->
<------------------ (TLS) ServerHello, ... --
<---------------- (TLS) CertificateRequest -- *3
-- (TLS) ..., Certificate ------------------> *4
-- (TLS) Finished -------------------------->
<-------------------------- (TLS) Finished --
<--------------------------- (HTTP) 200 OK -- *5
Figure 1: HTTP/1.1 Reactive Certificate Authentication with TLS 1.2
In this example, the server receives a request for a protected
resource (at *1 on Figure 1). Upon performing an authorization
check, the server determines that the request requires authentication
Thomson & Bishop Expires April 21, 2016 [Page 3]
Internet-Draft HTTP/2 Client Certs October 2015
using a client certificate and that no such certificate has been
provided.
The server initiates TLS renegotiation by sending a TLS HelloRequest
(at *2). The client then initiates a TLS handshake. Note that some
TLS messages are elided from the exchange for the sake of brevity.
The critical messages for this example are the server requesting a
certificate with a TLS CertificateRequest (*3); this request might
use information about the request or resource. The client then
provides a certificate and proof of possession of the private key in
Certificate and CertificateVerify messages (*4).
When the handshake completes, the server performs any authorization
checks a second time. With the client certificate available, it then
authorizes the request and provides a response (*5).
1.2. TLS 1.3 Client Authentication
TLS 1.3 [I-D.ietf-tls-tls13] introduces a new client authentication
mechanism that allows for clients to authenticate after the handshake
has been completed. For the purposes of authenticating an HTTP
request, this is functionally equivalent to renegotiation. Figure 2
shows the simpler exchange this enables.
Client Server
-- (HTTP) GET /protected ------------------->
<---------------- (TLS) CertificateRequest --
-- (TLS) Certificate ----------------------->
<--------------------------- (HTTP) 200 OK --
Figure 2: HTTP/1.1 Reactive Certificate Authentication with TLS 1.3
TLS 1.3 does not support renegotiation, instead supporting direct
client authentication. In contrast to the TLS 1.2 example, in TLS
1.3, a server can simply request a certificate.
1.3. Reactive Client Authentication in HTTP/2
An important part of the HTTP/1.1 exchange is that the client is able
to easily identify the request that caused the TLS renegotiation.
The client is able to assume that the next unanswered request on the
connection is responsible. The HTTP stack in the client is then able
to direct the certificate request to the application or component
that initiated that request. This ensures that the application has
the right contextual information for processing the request.
Thomson & Bishop Expires April 21, 2016 [Page 4]
Internet-Draft HTTP/2 Client Certs October 2015
In HTTP/2, a client can have multiple outstanding requests. Without
some sort of correlation information, a client is unable to identify
which request caused the server to request a certificate.
Thus, the minimum necessary mechanism to support reactive certificate
authentication in HTTP/2 is an identifier that can be use to
correlate an HTTP request with either a TLS renegotiation or
CertificateRequest.
Section 2 describes how the existing TLS 1.3 fields and a new HTTP/2
frame described in Section 4 can be used to correlate a request with
a TLS CertificateRequest. Section 3 describes how the same can be
done in TLS 1.2 using TLS renegotiation and a new TLS
"application_context_id" extension. Finally, Section 5 describes how
an HTTP/2 client can announce support for this feature so that a
server might use these capabilities.
1.4. Terminology
RFC 2119 [RFC2119] defines the terms "MUST", "MUST NOT", "SHOULD" and
"MAY".
2. HTTP/2 Request Correlation in TLS 1.3
An HTTP/2 request from a client that has signaled support for
reactive certificate authentication (see Section 5) might cause a
server to request client authentication. In TLS 1.3 a server does
this by sending a new TLS 1.3 CertificateRequest.
The server MUST first send a WAITING_FOR_AUTH frame (see Section 4)
on the stream which triggered the request for client credentials.
The certificate_request_id (name TBD) field of the TLS
CertificateRequest is populated by the server with the same value in
the WAITING_FOR_AUTH frame. Subsequent WAITING_FOR_AUTH frames with
the same request identifier MAY be sent on other streams while the
server is awaiting client authentication with the same parameters.
This allows a client to correlate the TLS CertificateRequest with one
or more outstanding requests.
A server MAY send multiple concurrent TLS CertificateRequest
messages. If a server requires that a client provide multiple
certificates before authorizing a single request, it MUST send
WAITING_FOR_AUTH frames with different request identifiers before
sending subsequent TLS CertificateRequest messages.
Thomson & Bishop Expires April 21, 2016 [Page 5]
Internet-Draft HTTP/2 Client Certs October 2015
3. HTTP/2 Request Correlation in TLS 1.2
An HTTP/2 server that uses TLS 1.2 initiates client authentication by
sending a an HTTP/2 WAITING_FOR_AUTH frame followed by a TLS
HelloRequest. This triggers a TLS renegotiation.
An HTTP/2 client that receives a TLS HelloRequest message MUST
initiate a TLS handshake, including an empty "application_context_id"
extension. If the client has not indicated support for renegotiation
(see Section 5), the client MUST send a fatal TLS "no_renegotiation"
alert.
The server populates the "application_context_id" extension with the
same value it previously sent in a WAITING_FOR_AUTH frame.
Absence of an "application_context_id" extension or an empty value
from the server MUST be treated as a fatal error; endpoints MAY send
a fatal TLS "no_renegotiation" alert.
As with the TLS 1.3 solution, a server MAY request multiple client
certificates, either for different requests or for the same request.
If multiple requests are waiting for authentication and require
different certificates, the server SHOULD immediately send the
WAITING_FOR_AUTH frames with unique values. Only one TLS
renegotiation can be in progress at a time, though a new HelloRequest
can be emitted once the renegotiation has completed.
A server MAY treat all certificates presented in the same connection
as cumulative, remembering multiple certificates as they are
presented. Note that the authentication information collected from
the client will need to be checked after each TLS renegotiation
completes, since most TLS stacks only report the presence of the
client certificate presented during the last TLS handshake.
3.1. The TLS application_context_id Hello Extension
The "application_context_id" TLS Hello Extension is used to carry an
identifier from an application context in the TLS handshake. This is
used to identify the application context that caused the TLS
handshake to be initiated. The semantics of the field depend on
application protocol, and could further depend on application
protocol state.
Either client or server can populate this field. A client can
provide an empty value to indicate that it does not know the
application context, but would like the server to provide a value. A
server can provide an empty value in response to a non-empty value
only.
Thomson & Bishop Expires April 21, 2016 [Page 6]
Internet-Draft HTTP/2 Client Certs October 2015
In HTTP/2 clients always provide an empty "application_context_id"
value, and servers always provide a value that will appear in a
subsequent WAITING_FOR_AUTH frame.
enum {
...
application_context_id(EXTENSION-TBD),
(65535)
} ExtensionType;
struct {
opaque id<0..255>;
} ApplicationContextId;
Figure 3: The application_context_id Extension Format
3.2. Permitting TLS Renegotiation in HTTP/2
The prohibition from Section 9.2.1 of [RFC7540] against TLS
renegotiation is removed, provided that the requirements of this
section are adhered to.
TLS renegotiation MUST NOT be used to circumvent the other
restrictions on TLS use from Section 9.2 of [RFC7540]. Furthermore,
TLS renegotiation MUST negotiate the same ALPN [RFC7301] identifier
(that is, "h2"). An endpoint MAY treat failure to comply with these
requirements as a connection error (Section 5.4.1 of [RFC7540]) of
type INADEQUATE_SECURITY.
Note: A client need not offer cipher suites that might otherwise be
offered for compatibility reasons when renegotiating. In
particular, cipher suites on the black list from Appendix A of
[RFC7540] can be removed from the handshake.
In addition to the requirements from [RFC7540], endpoints that
renegotiate MUST implement the TLS extended master secret extension
[RFC7627] and the TLS renegotiation indication extension [RFC5746].
These extensions MUST be negotiated and used to prevent serious
attacks on TLS renegotiation. If an endpoint receives a TLS
ClientHello or ServerHello that does not include these extensions, it
MUST respond with a fatal TLS "no_renegotiation" alert.
The TLS renegotiation handshake MUST include the
"application_context_id" extension when used with HTTP/2.
A server MUST present the same certificate during TLS renegotiation
it used during the initial handshake. Clients MUST verify that the
server certificate does not change. Clients MUST verify that the
Thomson & Bishop Expires April 21, 2016 [Page 7]
Internet-Draft HTTP/2 Client Certs October 2015
server certificate has not changed; a different certificate MUST be
treated as a fatal error and MAY cause a fatal "handshake_failure"
alert to be sent.
Once the HTTP/2 connection preface has been received from a peer, an
endpoint SHOULD treat the receipt of a TLS ClientHello or ServerHello
without an "application_context_id" extension as a fatal error and
SHOULD send a fatal TLS "no_renegotiation" alert.
4. Indicating Stream Dependency on Certificate Authentication
The WAITING_FOR_AUTH frame (0xFRAME-TBD) is sent by servers to
indicate that processing of a request is blocked pending
authentication outside of the HTTP channel. The frame includes a
request identifier which can be used to correlate the stream with
challenges for authentication received at other layers, such as TLS.
The WAITING_FOR_AUTH frame contains between 1 and 255 octets, which
is the authentication request identifier. A client that receives a
WAITING_FOR_AUTH of any other length MUST treat this as a stream
error of type PROTOCOL_ERROR. Frames with identical request
identifiers refer to the same TLS CertificateRequest.
The WAITING_FOR_AUTH frame MUST NOT be sent by clients. A
WAITING_FOR_AUTH frame received by a server SHOULD be rejected with a
stream error of type PROTOCOL_ERROR.
The server MUST NOT send a WAITING_FOR_AUTH frame on stream zero, a
server-initiated stream or a stream that does not have an outstanding
request. In other words, a server can only send in the "open" or
"half-closed (remote)" stream states.
A client that receives a WAITING_FOR_AUTH frame on a stream which is
not in a valid state ("open" or "half-closed (local)" for clients)
SHOULD treat this as a connection error of type PROTOCOL_ERROR.
5. Indicating Support for Reactive Certificate Authentication
Clients that support reactive certificate authentication indicate
this using the HTTP/2 "SETTINGS_REACTIVE_AUTH" (0xSETTING-TBD)
setting.
The initial value for the "SETTINGS_REACTIVE_AUTH" setting is 0,
indicating that the client does not support reactive client
authentication. A client sets the "SETTINGS_REACTIVE_AUTH" setting
to a value of 1 to indicate support for reactive certificate
authentication as defined in this document. Any value other than 0
Thomson & Bishop Expires April 21, 2016 [Page 8]
Internet-Draft HTTP/2 Client Certs October 2015
or 1 MUST be treated as a connection error (Section 5.4.1 of
[RFC7540]) of type PROTOCOL_ERROR.
6. Security Considerations
The TLS extended master secret extension [RFC7627] and the TLS
renegotiation indication extension [RFC5746] MUST be used to mitigate
several known attacks on TLS renegotiation.
Adding correlation between requests and TLS-layer authentication
addresses the primary functional concerns with mid-session client
authentication. However, implementations need to be aware of the
potential for confusion about the state of a connection.
The presence or absence of a validated client certificate can change
during the processing of a request, potentially multiple times. A
server that uses reactive certificate authentication needs to be
prepared to reevaluate the authorization state of a request as the
set of certificates changes.
7. IANA Considerations
The TLS "application_context_id" extension is registered in
Section 7.1. The HTTP/2 "SETTINGS_REACTIVE_AUTH" setting is
registered in Section 7.2. The HTTP/2 "WAITING_FOR_AUTH" frame type
is registered in Section 7.3.
7.1. TLS application_context_id Extension
The "application_context_id" TLS extension is registered in the
"ExtensionType Values" registry established by [RFC5246].
Value: EXTENSION-TBD
Extension name: application_context_id
Reference: This document.
7.2. HTTP/2 SETTINGS_REACTIVE_AUTH Setting
The SETTINGS_REACTIVE_AUTH setting is registered in the "HTTP/2
Settings" registry established in [RFC7540].
Name: SETTINGS_REACTIVE_AUTH
Code: 0xSETTING-TBD
Initial Value: 0
Thomson & Bishop Expires April 21, 2016 [Page 9]
Internet-Draft HTTP/2 Client Certs October 2015
Specification: This document.
7.3. HTTP/2 WAITING_FOR_AUTH Frame
The WAITING_FOR_AUTH frame type is registered in the "HTTP/2 Frame
Types" registry established in [RFC7540].
Frame Type: WAITING_FOR_AUTH
Code: 0xFRAME-TBD
Specification: This document.
8. Acknowledgements
Eric Rescorla pointed out several failings in an earlier revision.
9. Normative References
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-08 (work in progress),
August 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
<http://www.rfc-editor.org/info/rfc5746>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", RFC
7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <http://www.rfc-editor.org/info/rfc7301>.
Thomson & Bishop Expires April 21, 2016 [Page 10]
Internet-Draft HTTP/2 Client Certs October 2015
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI
10.17487/RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension", RFC
7627, DOI 10.17487/RFC7627, September 2015,
<http://www.rfc-editor.org/info/rfc7627>.
Authors' Addresses
Martin Thomson
Mozilla
Email: martin.thomson@gmail.com
Mike Bishop
Microsoft
Email: michael.bishop@microsoft.com
Thomson & Bishop Expires April 21, 2016 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 02:42:22 |