[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 draft-bishop-httpbis-http2-additional-certs

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/