Network Working Group D. Migault
Internet-Draft K. Ma
Intended status: Standards Track Ericsson
Expires: July 22, 2016 January 19, 2016
Authentication Model and Security Requirements for the TLS/DTLS Content
Provider Edge Server Split Use Case
draft-mglt-lurk-tls-requirements-00
Abstract
In the TLS/DTLS Content provider Edge Server Split use case, a TLS
Client uses TLS/DTLS to authenticates the Content Provider while
establishing a TLS/DTLS session with the Edge Server. Such
authentication scheme is designated as Split Authentication in this
document.
In most cases, the Edge Server does not even belong to the Content
Provider, but instead to a third party like, for example, a Content
Delivery Network. As a result, the Content Provider and the Edge
Server must be able to interact and/or share some information.
Interactions and shared information constitutes a split
authentication model varies with the authentication method involved
in the TLS session.
For each TLS/DTLS authentication method, the document provides the
associated split authentication model that makes possible a split
authentication. The split authentication model is associated to
security requirements and an analysis to show it does not introduce
any weakness compared to the standard TLS authentication model.
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 July 22, 2016.
Migault & Ma Expires July 22, 2016 [Page 1]
Internet-Draft TLS Split Authentication Models January 2016
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Handshake Authentication Methods for DTLS1.2 / TLS1.2 . . . . 4
4.1. RSA Authentication . . . . . . . . . . . . . . . . . . . 6
4.1.1. Standard TLS Authentication Description . . . . . . . 6
4.1.2. Split Authentication Model . . . . . . . . . . . . . 7
4.1.3. Security Analysis . . . . . . . . . . . . . . . . . . 7
4.2. DH_DSS, DH_RSA, ECDH_ECDSA, ECDH_RSA . . . . . . . . . . 8
4.2.1. Standard TLS Authentication Description . . . . . . . 9
4.2.2. Split Authentication Model . . . . . . . . . . . . . 9
4.2.3. Security Analysis . . . . . . . . . . . . . . . . . . 10
4.3. DH_anon, ECDH_anon . . . . . . . . . . . . . . . . . . . 11
4.3.1. Standard TLS Authentication Description . . . . . . . 11
4.3.2. Split Authentication Model . . . . . . . . . . . . . 11
4.3.3. Security Analysis . . . . . . . . . . . . . . . . . . 11
4.4. DHE_DSS, DHE_RSA, ECDHE_RSA, ECDHE_ECDSA . . . . . . . . 12
4.4.1. Standard TLS Authentication Description . . . . . . . 12
4.4.2. Split Authentication Model . . . . . . . . . . . . . 13
4.4.3. Security Analysis . . . . . . . . . . . . . . . . . . 14
4.5. PSK, DHE_PSK, RSA_PSK . . . . . . . . . . . . . . . . . . 16
4.5.1. Standard TLS Authentication Description . . . . . . . 16
4.5.2. Split Authentication Model . . . . . . . . . . . . . 17
4.5.3. Security Analysis . . . . . . . . . . . . . . . . . . 19
4.6. Client Hash and Signature . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Migault & Ma Expires July 22, 2016 [Page 2]
Internet-Draft TLS Split Authentication Models January 2016
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
TLS is commonly used by applications to authenticate their counter
part. Although the client part of the application and the TLS Client
are likely to be hosted on the same node, this is no longer true on
the server endpoints. As presented in [draft-mglt-tls-session-key-
interface-use-cases], split scenarios considers that the TLS endpoint
(Edge Server) and the application endpoint (Content Provider) may be
hosted on different nodes that may not even share a common
administrative domain.
Authentication of the Content Provider while establishing a TLS/DTLS
session with the Edge Server is designated in this document as a
split authentication. How split authentication can be performed
varies on the TLS authentication method involved between the TLS
Client and the Edge Server. The requirements on the information that
can be shared between the Content Provider and the Edge Server, as
well as the interactions between these two entities constitute a
split authentication model.
This document provides a split authentication model for each TLS
method. The model is often expresses as a list of requirements.
These split authentication models are designed to avoid the leak of
secret authentication credentials of the Content Provider, and
matched against the standard TLS/DTLS authentication model. More
especially, the split authentication models are designed not to
introduce vulnerabilities or weakness compared to the standard TLS
authentication model.
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Terminology
In addition to the terminology used in [draft-mglt-tls-session-key-
interface-use-cases], the current document defines
Split Authentication : designates the case when a TLS Client
authenticates the Content Provider, while establishing a TLS
session with a Edge Server. This is a three party
authentication as the Edge Server may not necessarily belong to
the Content Provider, nor share authentication credentials -
like private keys for example - with the Content Provider. Use
Migault & Ma Expires July 22, 2016 [Page 3]
Internet-Draft TLS Split Authentication Models January 2016
cases can be found in [draft-mglt-tls-session-key-interface-
use-cases]
Split Authentication Model : designates the information that can be
shared as well as the interactions between the Edge Server and
the Content Provider in order to enable the split
authentication. In most cases, each TLS authentication method
comes with a specific authentication model.
Standard TLS Authentication Model : designates the standard
authentication model for TLS, i.e. between the TLS Client and
the TLS Server.
DH: Diffie Hellman
ECDH Elliptical Diffie Hellman
4. Handshake Authentication Methods for DTLS1.2 / TLS1.2
TLS has been designed for end-to-end security. This means that the
TLS Client is expected to authenticate and set up a secure channel
with the other end point of the communication designated as TLS
Server.
TLS provides multiple KeyExchangeAlgorithm to authenticate the TLS
Server by the TLS Client. Current authentication methods for DTLS
1.2 [RFC6347] TLS 1.2 [RFC5246] are dhe_dss, dhe_rsa, dh_anon, rsa,
dh_dss and dh_rsa. [RFC4492] defines the additional ecdh_ecdsa,
ecdhe_ecdsa, ecdh_rsa, ecdhe_rsa and ecdh_anon. In addition,
[RFC4279] defines psk, dhe_psk and rsa_psk.
For each authentication method, this section provides a brief
description of the authentication method. The authentication
involves multiple credentials usually associated to the Content
Provider. For each of these credential this section specifies
whether it can be shared with the Edge Servers or not, and if not
what information the Content Provider needs to provide to the Edge
Server so the TLS session can be agreed between the TLS Client and
the Edge Server.
Authentication in TLS1.2 is performed during the Handshake Protocol
-- see section 7.3 in [RFC5246]. The messages involved in the
authentication are Certificate, the ServerKeyExchange, the client
Certificate, and the ClientKeyExchange message. Not all of them are
always involved, and the following sections provides a high level
description on how authentication is performed with the different
methods. Figure 1 illustrates the various messages exchanges during
a full handshake protocol in TLS1.2.
Migault & Ma Expires July 22, 2016 [Page 4]
Internet-Draft TLS Split Authentication Models January 2016
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* Indicates optional or situation-dependent messages that
are not always sent.
Figure 1: TLS1.2 Full Handshake
The purpose of the authentication in TLS is that the TLS Client and
the TLS Server can agree on a master_secret that will be used to
derive all necessary keys to secure the channel between the TLS
Client and the TLS Server. This master_secret is derived from a
pre_master agreed between the TLS Client and the TLS Server.
[RFC5246] and [RFC7627] define different ways to generate the
master_secret from the pre_master.
For information, in [RFC5246], the master_secret is generated as
follows:
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
[0..47];
where:
struct {
uint32 gmt_unix_time; # 4 bytes
opaque random_bytes[28];
} Random;
master_secret
[RFC7627] defines the Extended Master Secret Extension where the
"master_secret" is defined as follows:
Migault & Ma Expires July 22, 2016 [Page 5]
Internet-Draft TLS Split Authentication Models January 2016
master_secret = PRF(pre_master_secret, "extended master secret",
session_hash)
[0..47];
where:
- session_hash = Hash(handshake_messages)
- handshake_messages is the concatenation of all the exchanged
Handshake structures, as defined in Section 7.4 of [RFC5246].
- Hash is as defined in Section 7.4.9 of [RFC5246]
Note that in TLS1.2 section 5 mentions "New cipher suites MUST
explicitly specify a PRF and, in general, SHOULD use the TLS PRF with
SHA-256 or a stronger standard hash function." This means that
TLS1.2 provides the necessary cryptographic agility that allow the
use of different hash function to generate the master secret from the
premaster secret is collision free.
4.1. RSA Authentication
4.1.1. Standard TLS Authentication Description
When key exchange method chosen by the TLS Server is rsa, the TLS
Server provides a ServerCertificate message that contains the public
RSA key. This RSA key will be used for encryption. The TLS Client
checks the public key provided by the certificate is associated to
the requested entity, and then checks the binding between the RSA
public key and the Content provider is certified by a trusted
Certification Authority. This later operation requires that the TLS
Client and the TLS Server share a common trusted Certification
Authority as well as the TLS Client is able to check the signature
embedded in the certificate. More specifically, the TLS must support
the necessary hash and signature algorithms to check the certificate.
The TLS Client does not inform the TLS Server what are the TLS
Client's trusted CA, on the other hand, it provides the supported
hash and signature - see Section 4.6.
The TLS Client sends the EncryptedPreMasterSecret, a premaster
encrypted with the RSA public key of the TLS Server - provided in the
Certificate - in a ClientKeyExchange message. The TLS Client does
not provide any Certificate message.
The TLS Server is considered authenticated, if it can provide a proof
of ownership of the private key associated to the public key provided
in the certificate. In the case of the rsa key exchange algorithm,
the TLS Server, needs the private key to decrypt the premaster secret
in order to derive the master secret and all session keys, and have
the same sessions keys as the TLS Client. Without the private key
the TLS Server will not be able to decrypt the premaster secret and
Migault & Ma Expires July 22, 2016 [Page 6]
Internet-Draft TLS Split Authentication Models January 2016
thus not be able to agree with the TLS Client the session keys. In
other words, the TLS session cannot be established.
4.1.2. Split Authentication Model
This section lists the requirements to use the RSA authentication in
a split authentication model. The requirements regarding the
credential information shared between the Content Provider and the
Edge Server are:
REQ1: The Content Provider SHOULD share the RSA public key with the
Edge Server. The RSA public key is public information and is
conveyed in the ServerCertificate message.
REQ2: The Content Provider MUST NOT share the private RSA key with
the Edge Server. The RSA private key is associated to the
Content Provider and SHOULD be kept in a secure place.
The RSA private key is necessary to the Edge Server to decrypt the
premaster secret so the TLS Server and the TLS Client can set the
session keys. These operations can only be performed by the owner of
the private key, that is in our case the Content Provider. Thus, the
requirements regarding interactions between the Content Provider and
the Edge Server are:
REQ3: The Content Provider MUST provide RSA decryption facilities to
the Edge Servers. The Edge Server SHOULD be able to provide
the EncryptedPremasterSecret - as well as additional necessary
parameters - and be returned the clear text premaster or the
master secret so the Edge Server and the TLS Client can agree
and set the TLS channel.
4.1.3. Security Analysis
This section provides a security analysis of the split authentication
model versus the standard TLS authentication model with RSA used as
an authentication method. The purpose of this section is to show
that the Content Provider in the split authentication model does not
leak more information on its secret credential than the TLS Server
does in the standard TLS model.
In the split authentication model, the Content Provider receives the
EncryptedPremasterSecret and returns the cleartext premaster. This
is exactly the information provided by the TLS Server to the TLS
Client in the TLS standard authentication model.
The Edge Server can perform a chosen cipher text attack as it can
send ciphered text to the Content Provider and get the corresponding
Migault & Ma Expires July 22, 2016 [Page 7]
Internet-Draft TLS Split Authentication Models January 2016
clear text. Such attack cannot be performed by the TLS Client in the
standard TLS authentication model as the TLS Client generate the
premaster and does not get the clear text premaster from the TLS
Server, and retrieving the premaster from the session key is believe
to be unfeasible.
Another difference between the split authentication model and the
standard TLS model is that unlike the TLS Server, the Content
Provider cannot check whether the computation of the premaster leads
to an effective TLS session. This may be detected by the Edge Server
and not by the Content Provider. On the other hand, the Content
Provider centralizes the operations of all TLS Servers, which
provides the ability to detect orchestrated or cipher text attacks.
Also some of the discussion are discussed in the architecture
document, on a model comparison, one can say that the split
authentication model exposes the Content Provider to a cipher text
attack, which can be prevented by the appropriated choice of the RSA
parameters:
REQ4: RSA parameters MUST be chosen to make cipher text attack
infeasible.
REQ5: The Content Provider MUST be able to provide the master secret
or the extended master secret instead of the premaster. This
could mitigate the cipher text attack as it is believe to be
infeasible to retrieve the premaster secret from the master or
extended master secret.
REQ6: The Content Provider SHOULD be able to provide the premaster
secret.
In order to protect the TLS session between the TLS Client and the
Edge Server, the master secret or the premaster secret must not be
disclosed. Follows the security requirements on the Content Provider
/ Edge Server channel:
REQ7: The communication between the Edge Server and the Content
Provider MUST be authenticated and encrypted.
As a result, the split authentication model is not expected to leak
more information than the standard TLS authentication model as long
as RSA parameters are appropriately chosen.
4.2. DH_DSS, DH_RSA, ECDH_ECDSA, ECDH_RSA
Migault & Ma Expires July 22, 2016 [Page 8]
Internet-Draft TLS Split Authentication Models January 2016
4.2.1. Standard TLS Authentication Description
With Diffie Hellman fixed values, the TLS Server provides a
ServerCertificate which contains a certificate that contains the
fixed DH or ECDH value. The DH or ECDH fix value is authenticated by
the Certification Authority with a specific signature algorithm -
RSA, DSS or ECDSA for example. As the DH or ECDH keys are used to
establish a shared secret from public values, the purpose of the key
is limited to the key agreement and the certificate is expected to
have the key usage set to key agreement - e.g. the key is not used
for signing or encrypting.
In order to compute the shared secret, the TLS Server expects to
receive the TLS Client DH / ECDH counter part fix value. Optionally,
the TLS Server can send a Certificate Request with the type
corresponding to the key agreement method: rsa_fixed_dh,
dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh.
Upon receiving the ServerCertificate message and optionally the
CertificateRequest from the TLS Server, the TLS Client sends back a
ClientCertificate with the same type as the ServerCertificate
(rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh).
Once the TLS Client and the TLS Server have exchanged their fixed DH
/ ECDH value, the pre_master can be derived by both the TLS Client
and the TLS Server by combining the public and private DH / ECDH key.
The premaster is then agreed between the TLS Server and the TLS
Client and session keys can be derived from both the TLS Server and
TLS Client.
4.2.2. Split Authentication Model
This section lists the requirements to use the DH_DSS, DH_RSA,
ECDH_ECDSA, ECDH_RSA authentication in a split authentication model.
The requirements regarding the credential information shared between
the Content Provider and the Edge Server are:
REQ8: The Content Provider SHOULD share the DH or ECDH public key
with the Edge Server. The DH or ECDH public key is public
information and is conveyed in the ServerCertificate message.
REQ9: The Content Provider MUST NOT share the private DH or ECDH key
with the Edge Servers. The DH or ECDH private key is
associated to the Content Provider and SHOULD be kept in a
secure place.
The DH or ECDH private key is necessary to the Edge Server to decrypt
the premaster secret so the TLS Server and the TLS Client can set the
Migault & Ma Expires July 22, 2016 [Page 9]
Internet-Draft TLS Split Authentication Models January 2016
session keys. These operations can only be performed by the owner of
the private key, that is in our case the Content Provider. Thus, the
requirements regarding interactions between the Content Provider and
the Edge Server are:
REQ10: The Content Provider SHOULD provide the Edge Server facilities
to compute the DH or ECDH shared secret, the premaster, the
premaster or the extended master to the Edge Server.
4.2.3. Security Analysis
This section provides a security analysis of the split authentication
model versus the standard TLS authentication model with DH_DSS,
DH_RSA, ECDH_ECDSA, ECDH_RSA used as an authentication method. The
purpose of this section is to show that the Content Provider in the
split authentication model does not leak more information on its
secret credential than the TLS Server does in the standard TLS model.
When the Content Provider receives the public key of the TLS Client,
it may return the shared DH / ECDH secret to the Edge Server. In
that case, the Edge Server is exactly aware of the shared secret as
well as the respective public keys of the Content Provider and the
TLS Client. The situation differs from a node intercepting the DH /
ECDH exchange as this node never gets the resulting secret. On the
other hand, such information are also exchanged between the TLS
Server and the TLS Client in the TLS standard authentication model.
As a result, interactions between the Edge Server and the Content
Provider is not expected to leak more information then the TLS Server
leak information to the TLS Client in [RFC5246].
Similarly to Section 4.1.3 the Content Provider can hardly
distinguish the premaster that are being requested in order to
perform an attack to the premasters that ends up into a TLS session.
As a result,
REQ11: DH / ECDH parameters MUST be chosen to make guessing attacks
infeasible.
REQ12: The Content Provider MAY provide the master secret or the
extended master secret instead of the premaster. This could
mitigate the cipher text attack as it is believe to be
infeasible to retrieve the premaster secret from the master or
extended master secret.
In order to protect the TLS session between the TLS Client and the
Edge Server, the master secret or the premaster secret must not be
Migault & Ma Expires July 22, 2016 [Page 10]
Internet-Draft TLS Split Authentication Models January 2016
disclosed. Follows the security requirements on the Content Provider
/ Edge Server channel:
REQ13: The communication between the Edge Server and the Content
Provider MUST be authenticated and encrypted.
As a result, the split authentication model is not expected to leak
more information than the standard TLS authentication model as long
as DH / ECDH parameters are appropriately chosen.
4.3. DH_anon, ECDH_anon
4.3.1. Standard TLS Authentication Description
With anonymous DH or ECDH - as opposed to fixed DH - the Certificate
message is not appropriated to carry the DH or ECDH parameters, as
they are not expected to be signed by a CA. As a result, the TLS
Server provides the DH / ECDH parameters in a ServerDHParams
structure or a ECParameters carried by a ServerKeyExchange message.
Upon receipt of the ServerKeyExchange, the TLS Client responds with a
ClientKeyExchange with the associated DH / ECDH parameters.
Once the TLS Client and the TLS Server have exchanged the fixed DH /
ECDH value, the pre_master is agreed between the TLS Server and the
TLS Client and session keys can be derived from both the TLS Server
and TLS Client.
4.3.2. Split Authentication Model
This section lists the requirements to use the DH_anon or ECDH_anon
authentication in a split authentication model. The requirements
regarding the credential information shared between the Content
Provider and the Edge Server are:
REQ14: The DH or ECDH public and private keys SHOULD be generated by
the Edge Servers. In other words, the DH or ECDH keys used
SHOULD NOT be generated and associated to the Content
Provider. As no authentication is provided to the TLS Client,
there is no need to use private information of the Content
provider.
4.3.3. Security Analysis
This section provides a security analysis of the split authentication
model versus the standard TLS authentication model with DH_anon or
ECDH_anon used as an authentication method. The purpose of this
section is to show that the Content Provider in the split
Migault & Ma Expires July 22, 2016 [Page 11]
Internet-Draft TLS Split Authentication Models January 2016
authentication model does not leak more information on its secret
credential than the TLS Server does in the standard TLS model.
The DH_anon and ECDH_anon authentication methods do not involve any
authentication credentials from the Content Provider, so the risks of
leakage of Content Provider authentication are not considered in this
case.
As a result, the split authentication model is not expected to leak
more information than the standard TLS authentication model.
4.4. DHE_DSS, DHE_RSA, ECDHE_RSA, ECDHE_ECDSA
4.4.1. Standard TLS Authentication Description
With ephemeral DH or ECDH - as opposed to fixed DH - the Certificate
message is not appropriated to carry the DH / ECDH parameters. In
fact, with ephemeral DH / ECDH, the DH / ECDH parameters are not
signed by a CA. Instead, they are signed by a signature-capable
certificate, which has been signed by the CA.
Since Certificate messages are not appropriated to carry the DH /
ECDH parameters, the TLS Server provides the DH / ECDH parameters in
a ServerDHParams structure or a ECParameters carried by a
ServerKeyExchange message. This is the same structure as for
anonymous DH / ECDH. In order to authenticate, a proof of ownership
is added. This proof of ownership takes the form of a signature of a
combination of the DH / ECDH parameters associated with the
ClientHello.random and the ServerHello.random. The exact structure
signed_params for DHE_RSA or ECDHE_RSA is defined in section 7.4.3 of
[RFC5246], or Signature for ECDSA_ECDSA is defined in section 5.4 of
[RFC4492]. In order to check the signature associated to the DH /
ECDH parameters, the TLS Server provides the necessary public key
associated to the TLS Server. These keys are carried in a
ServerCertificate signed by a CA. These certificates are used to
check the signature only.
Upon receipt of the ServerKeyExchange and the ServerCertificate, the
TLS Client provides the DH / ECDH parameters to the TLS Server via
the ClientDiffieHellmanPublic defined in section 7.4.7.2 of [RFC5246]
or ClientECDiffieHellmanPublic structure defined in section 5.7 of
[RFC4492]. Both structures are conveyed by the ClientKeyExchange
message. This message does not carry any signatures that enable the
TLS Server to authenticate the TLS Client. The TLS Client can be
authenticated by providing a signing key in a ClientCertificate. The
key is signed by a CA. On the other hand, the proof of ownership of
the key by the TLS Client is provided by sending a CertificateVerify.
Migault & Ma Expires July 22, 2016 [Page 12]
Internet-Draft TLS Split Authentication Models January 2016
The CertificateVerify message is the generic mechanism to
authenticate the TLS Client over the global TLS exchange.
4.4.2. Split Authentication Model
This section lists the requirements to use the DHE_DSS, DHE_RSA,
ECDHE_RSA, ECDHE_ECDSA authentication in a split authentication
model. The requirements regarding the credential information shared
between the Content Provider and the Edge Server are:
REQ15: The Content Provider SHOULD share the public key with the Edge
Server. The public key is used for signing the DH ECDH
parameters. The public key is respectively a DSS public key
when DHE_DSS is selected, a RSA public key when ECDHE_RSA is
selected or a ECDSA public key when ECDHE_ECDSA is selected.
The public key is public information and is conveyed in the
ServerCertificate message.
REQ16: The Content Provider MUST NOT share the private RSA DSS or
ECDSA key with the Edge Server. The private key is associated
to the Content Provider and SHOULD be kept in a secure place.
The DSA, RSA or ECDSA private key is necessary to the Edge Server to
sign the DH or ECDH parameters sent by the Edge Servers to the TLS
Clients. These operations can only be performed by the owner of the
private key, that is in our case the Content Provider. Thus, the
requirements regarding interactions between the Content Provider and
the Edge Server are:
REQ17: The Content Provider MUST provide DSS, RSA or ECDSA signing
facilities to the Edge Servers. The Edge Server SHOULD be
able to provide the extended parameters to be signed (that is
the signed_params ClientHello.random, ServerHello.random and
ServerKeyExchange.params) or their hash - as well as
additional necessary parameters - and be returned the signed
value so the Edge Server can send the ServerKeyExchange
message to the TLS Client and the TLS Client.
[DISCUSSION: the DHE_DSS / DH_DSS are mentioned for TLS1.2 but do not
seems to have specific actions associated to. I expected similar
behavior for dhe_dss as for dhe_rsa, but section A.4.2. "Server
Authentication and Key Exchange Messages" specifies no specific
payload when dhe_dss is selected. I would like to clarify how
DHE_DSS should be considered.]
Migault & Ma Expires July 22, 2016 [Page 13]
Internet-Draft TLS Split Authentication Models January 2016
4.4.3. Security Analysis
This section provides a security analysis of the split authentication
model versus the standard TLS authentication model with DHE_DSS,
DHE_RSA, ECDHE_RSA, ECDHE_ECDSA used as an authentication method.
The purpose of this section is to show that the Content Provider in
the split authentication model does not leak more information on its
secret credential than the TLS Server does in the standard TLS model.
The Content provider is expected to provide some signatures
associated to a given clear text. Such information provided by the
Content Provider to the Edge Server and the TLS Client in the split
authentication model are exactly the same information provided by the
TLS Server to the TLS Client in the standard TLS authentication
model.
The main difference between the two models is that the Content
Provider does not have any means to check whether the corresponding
signature effectively result in a running session or is part of an
attack. In order to mitigate the surface of such attacks:
REQ18: Signature scheme and associated parameters MUST be chosen to
be resistant to adaptive chosen cleartext attacks, i.e. the
computation of signatures MUST NOT reveal information of the
private key during the lifetime of the private key.
REQ19: The Edge Server SHOULD provide the complete clear text instead
of the hash to be signed. In fact, providing the complete
clear text provide the opportunity of the Content Provider to
check what is being signed. With secure signature scheme it
is believe that a collision with another clear text content
has a very low probability. On the other hand, if the Edge
Server simply provides the hash of the clear text, the Content
Provider does not have any means to check what it is signing.
In this case, the Content Provider relies on the Edge Server
to provide appropriated content and legitimated content, which
implies a strong trust relationship between the Content
Provider and the Edge Server.
The Edge Server can provide the complete cleartext or a hash of the
cleartext. An attacker may want to usurpate the Content Provider's
identity and provides content associated with the signature of the
content provider. In this case, the attacker may generate the
malicious content and hash it. By submitting the hash to the Content
Provider for signing, the Content Provider has no ways to check the
content that is expected to be signed by the Content Provider. In
other words, when hashes are submitted for signing, the content check
and validation is expected to be left to the Edge Server. On the
Migault & Ma Expires July 22, 2016 [Page 14]
Internet-Draft TLS Split Authentication Models January 2016
other hand, when the whole content is provided to the Content
Provider, the Content Provider is able to approve the content before
signing it. In this case, the Edge Server is not assigned the role
of checking the content. Instead, this role is left to the Content
Provider, thus limiting the trust in the Edge Server. This limits
the surface of attacks.
When the Edge Server provides the complete content to the Content
Provider, an attacker that wants to usurpate the Content Provider's
identity has the following possibilities:
a) It can provide a malicious content that is not detected as
malicious by the Content Provider, and so get signed by the
Content Provider. In order to address such vector of attack, the
Content Provider should be provided some means to control the
content that are signed. Otherwise, this function is delegated
to the Edge Server, and the model implies the Edge Server is a
trusted entity. When the clear text is provide instead of hash,
the Content Provider has means to check the content its signs.
On the other hand the Content Provider cannot check the signed
clear text corresponds to an effective and legitimate TLS
session.
b) It can generate the malicious content such that its hash matches
an already known hash. Such attack is known as a hash collision.
To address this vector of attack, the hash function is expected
to be resistant to pre-image, second pre-image and collision
attack.
c) It can guess the signature given the corresponding between
cleartext and their corresponding signatures. In order to
address this vector of attack, the signature is expected to be
resistant to the adaptive chosen message attack.
Only a) is introduced by the split model. In fact, in the TLS model,
the TLS Server signs content it generates and so assumes it is
legitimate. As explained, this is not anymore always true in the
split model where the Content Provider is not supposed to trust the
Edge Server. Vector of attack mentioned in b) and c) are common in
the split model and the standard TLS model, as an Edge Server in the
split model does not have any additional information than a TLS
Client in the TLS model. As a result:
REQ20: The Content Provider MUST be able to sign cleartext content
rather than the resulting hash. In addition, the Content
Provider MUST verify the cleartext content provided as input
to avoid signature usurpation.
Migault & Ma Expires July 22, 2016 [Page 15]
Internet-Draft TLS Split Authentication Models January 2016
REQ21: The Content Provider SHOULD enable hash signature. When the
Content Provider chose to sign hashes, the Edge Server MUST be
a trusted node.
The signature is not expected to be secret. As a result, the
information exchanged between the Content Provider and the Edge
Server does not require confidentiality. In addition, the
information provided to the Content Provider is not protected so
confidentiality is not mandatory. On the other hand, it is of
primary importance that only the legitimate Edge Server have access
to the signing service.
REQ22: The communication between the Edge Server and the Content
Provider MUST be authenticated.
As a result, the split authentication model is not expected to leak
more information than the standard TLS authentication model.
4.5. PSK, DHE_PSK, RSA_PSK
4.5.1. Standard TLS Authentication Description
When PSK, DHE_PSK or RSA_PSK [RFC4279] are selected by the TLS Server
for authentication, the TLS Server sends the TLS Client
ServerKeyExchange message with a psk_identity_hint to indicate the
TLS Client the PSK to select. When PSK has been selected, no
additional information is provided by the TLS Server. When DHE_PSK
is selected, the TLS Server adds the ServerDHParams to the
ServerKeyExchange. When RSA_PSK is selected, the TLS Server provides
the RSA public key of the TLS Server in a ServerCertificate message.
The key will be used for encryption.
Upon receipt of the ServerKeyExchange message, the TLS Client
responds with a ClientKeyExchange that contains the psk_identity.
When PSK has been selected, no additional information is provided.
The premaster includes the PSK designated by the psk_identity, and
TLS session keys are derived based on the shared secret. In case the
PSK is not known by both the TLS Client and the TLS Server, the
premaster will not be agreed upon.
When DHE_PSK is selected, in addition to the psk_identity, the TLS
Client provides the DH parameters in a ClientDiffieHellmanPublic
structure that is added to the ClientKeyExchange message. The
premaster is derived by the TLS Client and the TLS Server and
includes both the DH shared secret as well as the PSK itself. Only
if the TLS Server and the TLS Client share the same PSK, the
premaster is not agreed upon.
Migault & Ma Expires July 22, 2016 [Page 16]
Internet-Draft TLS Split Authentication Models January 2016
When RSA_PSK is selected, in addition to the psk_identity, the TLS
Client provides and EncryptedPreMasterSecret structure conveyed by
the ClientKeyExchange message. The EncryptedPreMasterSecret contains
among other informations a 46-byte random value and the PSK. When
receiving this message, the TLS Server decrypts the premaster and
check the validity between the PSK and the claimed psk_identity
before the premaster is agreed.
To sum up PSK DHE_PSK key exchange methods requires up to five
messages to be exchanged: ServerKeyExchange and ClientKeyExchange.
RSA_PSK requires the TLS Server to provide an additional
ServerCertificate.
4.5.2. Split Authentication Model
This section lists the requirements to use the PSK, RSA_PSK or the
DHE_PSK authentication in a split authentication model. The
requirements regarding the credential information shared between the
Content Provider and the Edge Server are:
REQ23: The Content Provider MAY share the psk_identity_hints and
associated profile with the Edge Servers. This information
may be shared after an evaluation that they are public
information and that profiles do not leak confidential,
critical or privacy related information. In addition the
Content Provider must also evaluate how the distribution of
the hints profiles may be distributed and updated on the Edge
Servers. Hints is definitely public as opposed to the PSK
that is secret, so the list of psk_identity_hints associated
to profiles may be provided to the Edge Servers. On the other
hand, there might be privacy issues related to providing a
complete list of hints, as well as management issues
associated to maintaining up-to-date lists between multiple
Edge Servers.
REQ24: The Content Provider SHOULD be able to provide
psk_identity_hints on a per request basis. More especially,
the Edge Server SHOULD be able to send a ClientHello message
or specific parameters to the Content Provider in order to get
the corresponding psk_identity_hint. Such interaction is
necessary when privacy and management issues may require the
profiles and psk_identity_hints be kept in a safe and
centralized place.
REQ25: The Content Provider MUST NOT share the PSK with the Edge
Server. The PSK is associated to the Content Provider and
MUST be kept in a secure place.
Migault & Ma Expires July 22, 2016 [Page 17]
Internet-Draft TLS Split Authentication Models January 2016
When PSK is selected, the requirements regarding interactions between
the Content Provider and the Edge Server are:
REQ26: The Content Provider SHOULD provide the Edge Server master
secret generation from the psk_identity as well as additional
information. As the premaster conveys the PSK in cleartext,
the Content Provider MUST NOT provide the cleartext premaster,
but instead should compute the master in order to avoid
transmitting the PSK to the Edge Server.
When PSK_RSA is selected, the requirements regarding interactions
between the Content Provider and the Edge Server are similar as those
to the RSA case except that the PSK SHOULD NOT be returned by the
Content Provider. More especially:
REQ27: The Content Provider SHOULD share the RSA public key with the
Edge Server. The RSA public key is public information and is
conveyed in the ServerCertificate message.
REQ28: The Content Provider MUST NOT share the private RSA key with
the Edge Server. The RSA private key is associated to the
Content Provider and SHOULD be kept in a secure place.
REQ29: The Content Provider MUST provide RSA decryption facilities to
the Edge Servers. The Edge Server SHOULD be able to provide
the EncryptedPremasterSecret - as well as additional necessary
parameters - and be returned the clear master so the Edge
Server and the TLS Client can agree and set the TLS channel.
As the premaster conveys the PSK in cleartext, the Content
Provider MUST NOT provide the cleartext premaster, but instead
should compute the master in order to avoid transmitting the
PSK to the Edge Server.
When DHE_PSK is selected, the DH exchange may be performed by the
Edge Server or by the Content Provider. When the DH exchange is
performed between the Edge Server and the TLS Client, the Edge Server
needs to provide the DH share secret - and the psk_identity - to the
Content Provider which in turn generates the master secret with its
PSK. Note that performing the DH with the Edge Server requires the
Edge Server to provide a Certificate with a public key signed by a CA
trusted by the TLS Client. This key may also be associated to the
Content provider URL. When the exchange is performed between the
Content Provider and the TLS Client, the agreed DH shared secret as
well as the PSK are only known by the Content Provider, which limits
the possibilities for the Edge Server to guess the PSK for example.
Migault & Ma Expires July 22, 2016 [Page 18]
Internet-Draft TLS Split Authentication Models January 2016
When the DH exchange is performed by the Edge Server and the TLS
Client, the requirements regarding interactions between the Content
Provider and the Edge Server are:
REQ30: The Content Provider MUST be able to generate a master from
the shared secret agreed between the Edge Server and the TLS
Client and the psk_identity provided by the TLS Client.
REQ31: As the premaster conveys the PSK in cleartext, the Content
Provider MUST NOT provide the cleartext premaster, but instead
should compute the master in order to avoid transmitting the
PSK to the Edge Server. This requirement assumes that the
Edge Server is performing the DH exchange.
When the DH exchange is performed between the Content Provider and
the TLS Client, the requirements regarding interactions between the
Content Provider and the Edge Server are:
REQ32: The Content Provider SHOULD share the private DH key with the
Edge Server. These DHParams will be sent to the TLS Client by
the Edge Server in the ServerKeyExchange message.
REQ33: The Content Provider SHOULD be able to generate a master from
the psk_identity and TLS Client DHParams - in addition to
potential additional parameters. As the premaster conveys the
PSK in clear, the Content Provider MUST NOT provide the
cleartext premaster, but instead should compute the master in
order to avoid transmitting the PSK to the Edge Server.
4.5.3. Security Analysis
This section compares the PSK, DHE_PSK, RSA_PSK authentication method
as described in [RFC4279] in a standard TLS model to the split model
described in this document - that is when it is split between the
Edge Server and the Content Provider. The main question considered
is how the split model exposes the authentication credential compared
to the standard TLS model described in [RFC5246].
All PSK, DHE_PSK, RSA_PSK assumes the PSK owned by the Content
Provider MUST NOT be provided to the Edge Server. The difference
between the split authentication model and the standard TLS
authentication model is that in the standard TLS model, the TLS
Server owns the PSK and derives the master secret from the PSK. On
the other hand, the split authentication model assumes that the Edge
Server is not aware of the PSK while being aware of the master
secret. The difference is that the TLS standard model assumes all
parties (TLS Server and TLS Client) share the PSK, whether the split
model assumes the PSK is not shared between all parties. As a
Migault & Ma Expires July 22, 2016 [Page 19]
Internet-Draft TLS Split Authentication Models January 2016
result, the PSK leakage analysis is out of scope of the standard TLS
model and is specific to the split model.
The PSK is used to generate the master secret using a hash function.
The leakage of the PSK information in the master depends on the
hashing function and its collision free properties. [RFC4279]. As a
result, we can assume that the master secret does not leak
information about the premaster to the Edge Server.
For PSK_RSA, the authentication credential of the Content provider
are a RSA key and a PSK. Section 4.1 addresses the requirements
associated to the leakage of the RSA credential. Similarly to the
RSA analyzed in Section 4.1.3:
REQ34: RSA parameters MUST be chosen to make cipher text attack
infeasible.
For DHE_PSK, the DH exchange may be performed between the TLS Client
and the Content Provider or between the TLS Client and the Edge
Server. When the DH exchange is performed between the TLS Client and
the Content provider, the Content Provider provides the public key
used to sign the DHparams structure. In this case the analysis is
similar to Section 4.4. When the DH exchange is performed between
the Edge Server and the TLS Client, the Content Provider does not
share any additional authentication credentials. Similarly to DH /
ECDH:
REQ35: DH parameters MUST be chosen to make guessing attacks
infeasible.
In order to protect the TLS session between the TLS Client and the
Edge Server, the master secret or the premaster secret must not be
disclosed. Follows the security requirements on the Content Provider
/ Edge Server channel:
REQ36: The communication between the Edge Server and the Content
Provider MUST be authenticated and encrypted.
As a result, the split authentication model is not expected to leak
more information than the standard TLS authentication model.
4.6. Client Hash and Signature
These are provided in the SignatureAndHash which is an Hello
Extension. As detailed in [RFC5246], if this extension has not been
provided, and rsa has been chosen as KeyExchangeAlgorithm, than the
server behaves as if the TLS Client had provided sha1 for the hash
function and rsa for the supported signatures. If the TLS Client
Migault & Ma Expires July 22, 2016 [Page 20]
Internet-Draft TLS Split Authentication Models January 2016
does not support sha1, than it has to use the extension to indicate
it.
5. Security Considerations
The scope of this document is to avoid that secret information
information associated to authentication credentials is spread over
multiple Edge Servers. Such models would assume that all Edge Server
remain trusted and reliable over time while being exposed on the
Internet. Instead the secret information is kept in one secured
place own by the Content Provider. Authentication of the Content
Provider by the TLS Clients is performed through the Edge Servers.
Such model designated in this document as the split model requires
some interactions between the Edge Servers and the Content Provider.
This document described what are the necessary interactions between
the Edge Servers and the Content Provider as well as the information
that can be shared between the Edge Servers and the Content Provider
and the information that must not be shared and that must remain
secret. These interactions as well as the shared and non shared
information do not expose the split model to additional risks of
secret leakages than in the standard TLS model.
The security associated to the authentication relies on the
authentication protocols defined in [RFC5246], [RFC4279] and
[RFC4492] and practices provided by [RFC7525]. As a result, security
consideration of these document apply.
6. IANA Considerations
There is no IANA considerations in this document.
7. Acknowledgements
8. References
8.1. Normative References
[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>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", RFC
4279, DOI 10.17487/RFC4279, December 2005,
<http://www.rfc-editor.org/info/rfc4279>.
Migault & Ma Expires July 22, 2016 [Page 21]
Internet-Draft TLS Split Authentication Models January 2016
[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>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
[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>.
8.2. Informative References
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, DOI
10.17487/RFC4492, May 2006,
<http://www.rfc-editor.org/info/rfc4492>.
Authors' Addresses
Daniel Migault
Ericsson
8400 boulevard Decarie
Montreal, QC H4P 2N2
Canada
Phone: +1 514-452-2160
Email: daniel.migault@ericsson.com
Migault & Ma Expires July 22, 2016 [Page 22]
Internet-Draft TLS Split Authentication Models January 2016
Kevin Ma J
Ericsson
43 Nagog Park
Acton, MA 01720
USA
Phone: +1 978-844-5100
Email: kevin.j.ma@ericsson.com
Migault & Ma Expires July 22, 2016 [Page 23]