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]