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

Versions: 00

TLS                                                          N. Sullivan
Internet-Draft                                           CloudFlare Inc.
Intended status: Standards Track                              M. Thomson
Expires: February 6, 2017                                        Mozilla
                                                               M. Bishop
                                                               Microsoft
                                                          August 5, 2016


                  Post-Handshake Authentication in TLS
               draft-sullivan-tls-post-handshake-auth-00

Abstract

   This document describes a mechanism for performing post-handshake
   certificate-based authentication in Transport Layer Security (TLS)
   versions 1.3 and later.  This includes both spontaneous and solicited
   authentication of both client and server.

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 February 6, 2017.

Copyright Notice

   Copyright (c) 2016 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
   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



Sullivan, et al.        Expires February 6, 2017                [Page 1]


Internet-Draft           TLS Post-Handshake Auth             August 2016


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Post-Handshake Authentication . . . . . . . . . . . . . . . .   3
     2.1.  Spontaneous Authentication  . . . . . . . . . . . . . . .   3
     2.2.  Solicited Authentication  . . . . . . . . . . . . . . . .   4
   3.  Post-Handshake Authentication TLS Extension . . . . . . . . .   4
   4.  Post-Handshake Authentication Messages  . . . . . . . . . . .   6
     4.1.  Certificate Request . . . . . . . . . . . . . . . . . . .   6
     4.2.  Certificate Message . . . . . . . . . . . . . . . . . . .   7
     4.3.  CertificateVerify Message . . . . . . . . . . . . . . . .   8
     4.4.  Finished Message  . . . . . . . . . . . . . . . . . . . .   9
     4.5.  Forgetting certificates . . . . . . . . . . . . . . . . .   9
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   This document defines a way to authenticate one party of a Transport
   Layer Security (TLS) communication to another using a certificate
   after the session has been established.  This allows both the client
   and server to solicit proof of ownership of additional identities at
   any time after the handshake has completed.  It also allows for both
   the client and server to spontaneously provide a certificate and
   proof of ownership of the private key to the other party.

   This mechanism is useful in the following situations:

   o  servers that have the ability to serve requests from multiple
      domains over the same connection but do not have a certificate
      that is simultaneously authoritative for all of them

   o  servers that have resources that require client authentication to
      access and need to request client authentication after the
      connection has started

   o  clients that want to assert their identity to a server after a
      connection has been established

   o  clients that want a server to re-prove ownership of their private
      key during a connection





Sullivan, et al.        Expires February 6, 2017                [Page 2]


Internet-Draft           TLS Post-Handshake Auth             August 2016


   o  clients that wish to ask a server to authenticate for a new domain
      not covered by the certificate included in the initial handshake

   This document intends to replace the use of renegotiation for
   changing the authentication of peers.  It has an advantage over
   renegotiation in that it only takes at most one round trip and it
   does not include an additional key exchange.

   This document describes spontaneous and solicited modes for both
   client and server authentication.  Spontaneous authentication allows
   an endpoint to advertise a certificate without explicitly being
   requested.  Solicited authentication allows an endpoint to request
   that its peer provide authentication details.

   Support for different modes of authentication is negotiated using a
   new "post_handshake_auth" extension.  New handshake messages are
   defined for use after completion of the initial handshake, these
   mirror the authentication messages that are used in the TLS 1.3
   handshake.

2.  Post-Handshake Authentication

   There is a total of four different exchanges that are enabled by this
   specification.  Solicited and spontaneous authentication exchanges
   are largely the same for both peers.  This section describes how each
   exchange operates.

   In all cases, a unique value for the certificate_request_context is
   chosen.  This allows for identification of the authentication flow in
   application protocols that use TLS.  Exchanges that are initiated by
   the client start with an octet that has the most significant bit set;
   exchanges initiated by the server have the most significant bit
   cleared.

2.1.  Spontaneous Authentication

   An endpoint that wishes to offer spontaneous authentication sends a
   Certificate, CertificateVerify, and Finished message.

     Certificate
     CertificateVerify
     Finished              ---------->

   No application data records or any other handshake messages can be
   interleaved with these messages.  An endpoint MUST abort a connection
   if it does not receive these messages in a contiguous sequence.  A
   fatal "unexpected_message" alert SHOULD be sent if these messages do
   not appear in sequence.



Sullivan, et al.        Expires February 6, 2017                [Page 3]


Internet-Draft           TLS Post-Handshake Auth             August 2016


   A client MUST NOT initiate spontaneous authentication unless the
   server included client_auth_spontaneous in its "post_handshake_auth"
   extension.  Similarly, a server MUST NOT initiate spontaneous
   authentication unless it included server_auth_solicited in its
   "post_handshake_auth" extension.

2.2.  Solicited Authentication

   Solicited authentication is initiated by sending a CertificateRequest
   message.

   Endpoints that request that their peer authenticate need to account
   for delays in processing requests.  In particular, client
   authentication in some contexts relies on user interaction.  This
   means that responses might not arrive in the order in which the
   requests were made.

   If a request for authentication is accepted, the sequence of
   Certificate, CertificateVerify, and Finished messages are sent by the
   responding peer.  As with spontaneous authentication, these messages
   MUST form a contiguous sequence.

     CertificateRequest    ---------->
                                              Certificate
                                        CertificateVerify
                           <----------           Finished

   A request for authentication can be rejected by sending a Certificate
   message that contains an empty certificate_list field.  The
   extensions field of this message MUST be empty.

   A client MUST NOT request server authentication unless the server
   included client_auth_solicited in its "post_handshake_auth"
   extension.  Similarly, a server MUST NOT request client
   authentication unless it included client_auth_solicited in its
   "post_handshake_auth" extension.

3.  Post-Handshake Authentication TLS Extension

   The "post_handshake_auth" TLS extension advertises support for post-
   handshake authentication.










Sullivan, et al.        Expires February 6, 2017                [Page 4]


Internet-Draft           TLS Post-Handshake Auth             August 2016


       enum {
           client_auth_solicited(0),
           client_auth_spontaneous(1),
           server_auth_solicited(2),
           server_auth_spontaneous(3),
           (255)
       } AuthTypes;

       struct {
           AuthType auth_types<0..2^8-1>;
       } PostHandshakeAuth;

   The extension data for the "post_handshake_auth" extension is
   PostHandshakeAuth.  This includes one or more AuthType.  Each
   AuthType value represents support for a given authentication flow:

   client_auth_solicited:  indicates support for client authentication
      solicited by a server request

   client_auth_spontaneous:  indicates support for spontaneous client
      authentication

   server_auth_solicited:  indicates support for server authentication
      solicited by a client request

   server_auth_spontaneous:  indicates support for spontaneous server
      authentication

   The client includes a "post_handshake_auth" extension containing
   every type of authentication flow it supports in its ClientHello.
   The server replies with an EncryptedExtensions containing a
   "post_handshake_auth" extension containing a list of authentication
   types that it supports.  The set of AuthTypes in the server's
   "post_handshake_auth" extension MUST be a subset of those sent by the
   client.

   The "post_handshake_auth" extension MUST be omitted if the server
   does not support any mode of post-handshake authentication in common
   with the client.

   If a server declares support for either client_auth_solicited, or
   client_auth_spontaneous, it MUST also include a
   "signature_algorithms" extension (see Section 4.2.2 of
   [I-D.ietf-tls-tls13]).  This contains a list of the signature schemes
   that the server is able to use for client authentication, listed in
   descending order of preference.





Sullivan, et al.        Expires February 6, 2017                [Page 5]


Internet-Draft           TLS Post-Handshake Auth             August 2016


   This extension is not compatible with the raw public key extension
   [RFC7250].  The server MUST NOT select the raw public key extension
   if it uses this mechanism.

4.  Post-Handshake Authentication Messages

   The messages used for post-handshake authentication closely mirror
   those used to authenticate certificates in the standard TLS
   handshake.

4.1.  Certificate Request

   For solicited post-handshake authentication, the first message is
   used to define the characteristics required in the solicited
   certificate.

     opaque DistinguishedName<1..2^16-1>;

     struct {
         opaque certificate_extension_oid<1..2^8-1>;
         opaque certificate_extension_values<0..2^16-1>;
     } CertificateExtension;

     struct {
         opaque certificate_request_context<1..2^8-1>;
         select (Role) {
             case server:
                 DistinguishedName certificate_authorities<0..2^16-1>;
                 CertificateExtension certificate_extensions<0..2^16-1>;
             case client:
                 HostName host_name<1..2^16-1>;
         }
     } CertificateRequest;

   The certificate_request_context is an opaque string which identifies
   the certificate request and which will be echoed in the corresponding
   Certificate message.  The certificate_request_context value MUST be
   unique for the connection.  A client MUST set the most significant
   bit of the first octet of the certificate_request_context; a server
   MUST clear this bit.

   For CertificateRequests sent from the server, the DistinguishedName
   and CertificateExtension fields are defined exactly as in the TLS 1.3
   specification.

   For CertificateRequests send from the client, a HostName containing
   the Server Name Indication (defined in [RFC6066]) used for selecting
   the certificate is included.



Sullivan, et al.        Expires February 6, 2017                [Page 6]


Internet-Draft           TLS Post-Handshake Auth             August 2016


4.2.  Certificate Message

   The certificate message is used to transport the certificate.  It
   mirrors the Certificate message in the TLS with the addition of some
   certificate-specific extensions.

       opaque ASN1Cert<1..2^24-1>;

       struct {
           opaque certificate_request_context<0..2^8-1>;
           ASN1Cert certificate_list<0..2^24-1>;
           Extension extensions<0..2^16-1>;
       } Certificate;

   certificate_request_context:  If this message is in response to a
      CertificateRequest, the value of certificate_request_context in
      that message.

   certificate_list:  This is a sequence (chain) of certificates.  The
      sender's end entity certificate MUST come first in the list.  Each
      following certificate SHOULD directly certify one preceding it.
      Because certificate validation requires that trust anchors be
      distributed independently, a certificate that specifies a trust
      anchor MAY be omitted from the chain, provided that supported
      peers are known to possess any omitted certificates.

   extensions:  Valid extensions include OCSP Status extensions
      ([RFC6066] and [RFC6961]) and SignedCertificateTimestamps
      ([RFC6962]).  Any extension presented in a Certificate message
      must only be presented if the associated ClientHello extension was
      presented in the initial handshake.

   The certificate_request_context is an opaque string that identifies
   the certificate.  The certificate_request_context value MUST be
   unique for the connection.  If the certificate is used in response to
   a CertificateRequest, certificate_request_context includes the
   certificate_request_context value in the corresponding
   CertificateRequest.  If the Certificate message part of spontaneous
   authentication, the certificate_request_context value is chosen by
   the sender.  When spontaneous authentication is used, a client MUST
   set the most significant bit of the first octet of the
   certificate_request_context; a server MUST clear this bit.

   Any certificates provided MUST be signed using a signature scheme
   found in the "signature_algorithms" extension provided by the peer in
   the initial handshake.  The end entity certificate MUST allow the key
   to be used for signing (i.e., the digitalSignature bit MUST be set if
   the Key Usage extension is present) with a signature scheme indicated



Sullivan, et al.        Expires February 6, 2017                [Page 7]


Internet-Draft           TLS Post-Handshake Auth             August 2016


   in the "signature_algorithms" extension provided by the peer in the
   initial handshake.

4.3.  CertificateVerify Message

   The CertificateVerify message used in this document is defined in
   Section 4.3.2. of [I-D.ietf-tls-tls13].

       struct {
           SignatureScheme algorithm;
           opaque signature<0..2^16-1>;
       } CertificateVerify;

   The algorithm field specifies the signature algorithm used (see
   Section 4.2.2 of [I-D.ietf-tls-tls13]).  The signature is a digital
   signature using that algorithm that covers the handshake context, the
   resumption context and a hash of the CertificateRequest and
   Certificate messages:

       Hash(handshake_context) + resumption_context +
           Hash(CertificateRequest* + Certificate)

   Note that the CertificateRequest message is omitted with spontaneous
   authentication.

   The value of handshake_context is the entire transcript of the
   initial handshake, starting from the first ClientHello up to the
   final Finished message from the client.  The value of
   resumption_context is defined in Section 4.4.1 of
   [I-D.ietf-tls-tls13].

   The context string that is input to the digital signature is formed
   by taking the endpoint role and the authentication mode.  The final
   value is the concatenation of the ASCII-encoded strings:

   o  "TLS 1.3, "

   o  either "client" if the client is authenticating, or "server" if
      the server is authenticating

   o  a single space " " (0x20)

   o  "spontaneous" if no request was made; "solicited" if the peer sent
      a CertificateRequest

   o  " CertificateVerify"





Sullivan, et al.        Expires February 6, 2017                [Page 8]


Internet-Draft           TLS Post-Handshake Auth             August 2016


   Thus, a client that is responding to a CertificateRequest will use
   the string "TLS 1.3, client solicited CertificateVerify" as the
   context string.

4.4.  Finished Message

   Finished is defined in Section 4.3.3 of [I-D.ietf-tls-tls13].  When
   included in post-handshake authentication it includes a MAC over the
   value:

       Hash(Handshake Context) + resumption_context +
           Hash(CertificateRequest* + Certificate + CertificateVerify)

   Note that the CertificateRequest message is omitted with spontaneous
   authentication.

   The Finished message uses the current traffic secret
   (traffic_secret_N) as the MAC key; the hash function and HMAC
   function are the negotiated PRF hash function.

4.5.  Forgetting certificates

   Certificate identity should not be maintained across resumption.  If
   a connection is resumed, additional certificate identities for both
   client and server certificates SHOULD be forgotten.  Either the
   client or the server MAY choose to forget a certificate identity at
   any time.

   Repeated requests for the same certificate should be expected.  If
   multiple certificate requests are recieved that differ only in the
   certificate_request_context value, it is permitted to only answer the
   most recent request.

5.  Security Considerations

   TBD

6.  Acknowledgements

   Eric Rescorla and Andrei Popov were involved in helpful discussions
   around this draft.

7.  Normative References

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-13 (work in progress),
              May 2016.



Sullivan, et al.        Expires February 6, 2017                [Page 9]


Internet-Draft           TLS Post-Handshake Auth             August 2016


   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,
              <http://www.rfc-editor.org/info/rfc6066>.

   [RFC6961]  Pettersen, Y., "The Transport Layer Security (TLS)
              Multiple Certificate Status Request Extension", RFC 6961,
              DOI 10.17487/RFC6961, June 2013,
              <http://www.rfc-editor.org/info/rfc6961>.

   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <http://www.rfc-editor.org/info/rfc6962>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <http://www.rfc-editor.org/info/rfc7250>.

Authors' Addresses

   Nick Sullivan
   CloudFlare Inc.

   Email: nick@cloudflare.com


   Martin Thomson
   Mozilla

   Email: martin.thomson@gmail.com


   Mike Bishop
   Microsoft

   Email: michael.bishop@microsoft.com













Sullivan, et al.        Expires February 6, 2017               [Page 10]


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