LURK WG D. Migault, Ed.
Internet-Draft Ericsson
Intended status: Informational July 8, 2016
Expires: January 9, 2017
LURK Protocol for TLS/DTLS1.2 version 1.0
draft-mglt-lurk-tls-00
Abstract
This document describes the LURK/TLS protocol between a Edge Server
and a Key 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 January 9, 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Migault Expires January 9, 2017 [Page 1]
Internet-Draft LURK TLS July 2016
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3
4. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
5. LURK/TLS Header . . . . . . . . . . . . . . . . . . . . . . . 3
6. Reachability / Keep Alive . . . . . . . . . . . . . . . . . . 5
7. Capability Discovery . . . . . . . . . . . . . . . . . . . . 5
8. Master Secret with RSA Authentication . . . . . . . . . . . . 6
9. Extended Master Secret with RSA Authentication . . . . . . . 8
10. Master Secret with RSA Authentication and PFS . . . . . . . . 10
11. Signature with ECDHE Authentication . . . . . . . . . . . . . 10
12. Unpredictable Signature with ECDHE Authentication . . . . . . 11
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13.1. Threat Analysis . . . . . . . . . . . . . . . . . . . . 13
13.2. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.2.1. TLS Session Binding . . . . . . . . . . . . . . . . 14
13.2.2. Decryption Oracle . . . . . . . . . . . . . . . . . 15
13.2.3. Illegitimate access to Key Server and PFS . . . . . 15
13.3. ECDHE . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.3.1. Cross Protocol Attacks . . . . . . . . . . . . . . . 16
13.3.2. Signing Oracle . . . . . . . . . . . . . . . . . . . 17
13.4. LURKS versus standard TLS1.2 . . . . . . . . . . . . . . 17
13.5. DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . 18
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
16.1. Normative References . . . . . . . . . . . . . . . . . . 19
16.2. Normative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Example of LURK Exchanges . . . . . . . . . . . . . 20
A.1. LURK/TLS RSA Master Secret . . . . . . . . . . . . . . . 20
A.2. LURK/TLS RSA Extended Master Secret . . . . . . . . . . . 21
A.3. LURK/TLS ECDHE Signature . . . . . . . . . . . . . . . . 22
A.4. LURK/TLS/sECDHE Unpredictable . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Requirements notation
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].
2. Introduction
This document describes the LURK/TLS protocol between an Edge Server
and a Key Server. The LURK/TLS protocol is designed to address the
Migault Expires January 9, 2017 [Page 2]
Internet-Draft LURK TLS July 2016
use cases as well as fulfill the requirements presented in
[I-D.mglt-lurk-tls-use-cases].
This document limits the scope LURK/TLS to the following
authentication methods: RSA [RFC5246], [RFC6347] ECDHE_RSA,
ECDHE_ECDSA [RFC4279] with TLS1.2 or prior versions. If other
authentication methods are required, the LURK/TLS can be extended
considering the analysis of [I-D.mglt-lurk-tls-requirements].
3. Terminology and Acronyms
- item :
4. Introduction
LURK/TLS defines the interactions between the Edge Server and the Key
Server. In this document, the Edge Server interacts with the Key
Server in order to perform the authentication phase of the TLS key
exchange. This document only considers the case where the
authentication methods are RSA, ECHDE_RSA or ECDHE_ECDSA. Additional
authentication methods or different interactions are left for the
future.
LURK/TLS is a query - response protocol.
5. LURK/TLS Header
The LURK/TLS Header contains the necessary elements to interpret the
remaining payload as well as identifiers used to bind a query and a
response. As the status of a response is only meaningful for
response, this section defines a different header for query and
response.
The first byte of the LURK/TLS header contains the query bit (q) set
to 1 for a query and 0 for a response, 4 reserved bits set to zero,
and three right bits used to indicate the LURK/TLS version (version).
In this document, the version is set to 1. Follows the query type
(qtype) that indicates the purpose of the query as well as how to
interpret the remaining payload. Finally, the query identifier (id)
is used to bind the query with the response.
For responses, the LURK/TLS header contains an additional field that
indicates the status of the response (status).
When the Edge Server or the Key Server sends a query, the query bit
MUST be set to one, the reserved bits MUST be set to zero, the
version MUST be set to one, the query type MUST be one of the values
Migault Expires January 9, 2017 [Page 3]
Internet-Draft LURK TLS July 2016
indicated by the LURKTLSQueryType, and the query identifier SHOULD be
randomly generated to avoid response spoofing attacks.
Upon receiving the query, the Key Server or the Edge Server ignores
the reserved bits and checks the LURK/TLS version. If the version is
not supported, then an "unvalid_lurk_version" error is returned.
Then, it checks if the query type is supported. If the query type is
unknown, an "unvalid_query_type" error is returned. In any other
case, the message is treated accordingly to the query type indicated.
The response header associated to a query header, is the exact copy
of the query header with the query bit set to zero.
Upon receiving a response, the Key Server or the Edge Server checks
the response is bound to a query by checking the id. If no binding
is found, the response is ignored.
THESE ARE SOME OPEN QUESTIONS AND COMMENTS THAT SHOULD BE ADDRESSED
AND SHOULD NOT BE PART OF THE FINAL VERSION OF THE DRAFT.
OPEN QUESTIONS 1): OPEN QUESTION: CAN WE HAVE DIFFERENT HEADERS FOR
QUERY AND RESPONSE ?
OPEN QUESTIONS 2): THE DEFINITION OF THE FIRST BYTE HEADER IS NOT
PROPERLY DEFINED BY THE PSEUDO CODE.
Migault Expires January 9, 2017 [Page 4]
Internet-Draft LURK TLS July 2016
enum {
zero(0), one(1) (1)
} QueryBit
enum {
one (1), (8)
} LURKTLSVersion
enum {
ping (0), capabilities (1),
rsa_master (2), rsa_extended_master (3), pfs_rsa_master (4),
echde (5), pfs_non_predictable_ecdhe (6), (255)
}LURKTLSQueryType
enum {
success (0), unvalid_lurk_version (1),
unvalid_query_type (1) (255)
} LURKTLSResponseStatus
struct {
QueryBit q
Reserved reserved
LURKTLSVersion version
LURKTLSQueryType qtype
uint64 id;
} LURKTLSQueryHeader
struct {
LURKTLSQueryHeader qheader
LURKResponseStatus status
} LURKTLSResponseHeader
6. Reachability / Keep Alive
To check the reachability between the Edge Server and the Key Server,
the Edge Server or the Key Server may send a LURK/TLS query with the
query type "ping". Upon receiving such query, the receiver sends
back a LURK/TLS response with a LURKStatusResponse set to "success",
with no additional payloads.
7. Capability Discovery
To discover the capabilities of the Key Server, the Edge Server may
request the list of query types served by the Key Server. The Edge
Server sends a LURK/TLS query with the query type set to
"capability". Upon receiving the query, the Key Server sends back a
LURK/TLS response with a LURKStatus set to success and a LURK/TLS
Migault Expires January 9, 2017 [Page 5]
Internet-Draft LURK TLS July 2016
capability payload. The payload contains its length and an ordered
list of the LURK/TLS query type supported.
struct {
opaque data<1..2**32-1>
} LURKTLSCapabilityPayload
THESE ARE SOME OPEN QUESTION AND COMMENTS THAT SHOULD BE ADDRESSED
AND SHOULD NOT BE PART OF THE FINAL VERSION OF THE DRAFT.
OPEN QUESTIONS 3): CURRENT CAPABILITY FORMAT IS LIMITED TO THE
CAPABILITIES OF THE QUERY TYPE. IN SOME CASE,
THE QUERY TYPE MAY BE ASSOCIATED TO SOME
ADDITIONAL PARAMETERS SUCH AS CRYPTOGRAPHIC HASH
FUNCTIONS, OR ECC PARAMETERS. SHOULD THESE SUB
PARAMETERS BE EMBEDDED INTO THIS REQUEST OR
SHOULD WE HAVE DEDICATED REQUEST FOR THEM?
OPEN QUESTIONS 4): CURRENT PARAMETERS THAT NEED TO BE SPECIFIED ARE
PRF / ECParameters / EC Points into Capabilities.
8. Master Secret with RSA Authentication
This section describes how the Edge Server request the generation of
a master secret, with RSA as an authentication method.
The Edge Server sends a LURK/TLS query to the Key Server with the
necessary inputs to generate the master secret
(LURKTLSMasterRSAInputPayload). This payload contains the length of
the payload (length), the identifier of the RSA key pair (key_id),
the Pseudo Random Function Algorithm to generate the master secret
(master_prf), the ClientHello.random (client_random), the
ServerHello.random (edge_server_random), the TLS version
(client_version) of the TLS Client, the TLS version of the Edge
Server (edge_server_version), and the encrypted pre master secret
generated by the TLS Client (encrypted_premaster_secret).
Upon receipt of the LURKTLSMasterRSAInputPayload, the Key Server
checks the RSA key pair is available (key_id). Different format can
be used to identify the key pair. This document defines sha256_32
format which takes the 32 first bits of the hash of the public key
using sha256. If the format of the key pair identifier is not
understood, an "unvalid_keypair_id_format" error is returned. If the
designated key pair is not available an "unvalid_keypair_id". With
the key pair identified, the Key Server is able to check the length
of the encrypted premaster secret and so the length of the payload.
In case of length mismatch and "unvalid_payload_format" is returned.
Migault Expires January 9, 2017 [Page 6]
Internet-Draft LURK TLS July 2016
Note that the length can be derived from the public key, so the error
only reveals public information. If the Key Server does not support
the PRF, an "unvalid_prf" is returned. If the TLS version of client
and the Edge Server are not equal or that the Key Server does not
support the provided TLS version, an "unvalid_tls_version" error is
returned.
When the inputs have been checked, the Key Server decrypts the
encrypted premaster secret as described in [RFC5246] section 7.4.7.1.
More specifically, when a PKCS1.5 format error is detected, or a
mismatch between the TLS versions provided as input and the one
indicated in the encrypted premaster secret, the Key Server returns a
randomly generated master secret. If the pre master is appropriately
decrypted, then the master secret is computed as described in
[RFC5246] section 8.1 using the PRF, ClientHello.random, and
ServerHello.random provided by the Edge Server. Finally, the Key
Server returns a master secret to the Edge Server in a
LURKTLSMasterPayload.
Upon receipt of the master_secret the Edge Server can generate the
session keys and finish the TLS key exchange protocol.
Migault Expires January 9, 2017 [Page 7]
Internet-Draft LURK TLS July 2016
// status error specifically mentioned in this exchange
enum {
unvalid_key_pair_id_format (3), unvalid_key_pair_id (4),
unvalid_encrypted_master_length (5) unvalid_prf (6),
unvalid_tls_version (7), unvalid_payload_format (8), (255)
} LURKTLSResponseStatus
enum {
sha256_32 (0), (255)
}KeyPairIdType
struct {
KeyPairIdType type
opaque data // length defined by the type
} KeyPairID;
struct {
unit16 length
KeyPairID key_id
PRFAlgorithm master_prf // see RFC5246 section 6.1
Random client_random // see RFC5246 section 7.4.1.2
Random edge_server_random
ProtocolVersion client_version // see RFC5246 section 6.2.1
ProtocolVersion edge_server_version
EncryptedPreMasterSecret // see RFC5246 section 7.4.7.1
// Length depends on the key.
} LURKTLSMasterRSAInputPayload
struct {
LURKTLSPayloadType master
opaque master[0..47]
} LURKTLSMasterPayload
key_id = sha256(rsa_public_key)[0..31];
9. Extended Master Secret with RSA Authentication
This section describes how the Edge Server request the generation of
an extended master secret, with RSA as an authentication method.
The Edge Server sends a LURK/TLS query to the Key Server with the
necessary inputs to generate the master secret
(LURKTLSExtendedMasterRSAInputPayload). This payload contains the
length of the payload (length), the identifier of the RSA key pair
(key_id), the PRF used to generate the extended master secret
(master_prf), the PRF used to generate the session hash
Migault Expires January 9, 2017 [Page 8]
Internet-Draft LURK TLS July 2016
(session_prf), the TLS version of the TLS Client (client_version),
the TLS version of the Edge Server (edge_server_version), the session
hash (session_hash) and the encrypted pre master secret generated by
the TLS Client (encrypted_premaster_secret).
[RFC5246] section 7.4.9 mentions that for TLS1.2, the hash function
used to generate the session hash MUST be the one used in the PRF,
but some cipher_suites may also define different Hash function to
generate the session_hash. For that reason the PRF used to compute
the session hash is explicitly provided. The session hash is
generated by the Edge Server as defined in [RFC7627] section 3.
Upon receipt of the query, the Key Server checks the validity of key
pair (key_id), the PRF used to generate the master secret
(master_prf), the TLS versions of the TLS Client (client_version) and
the TLS version of the Edge Server (edge_server_version) as described
in Section 8. The Key Server checks the PRF to generate the session
hash (session_prf) similarly to the PRF used to generate the master
(master_prf). There is not a specific error for these two distinct
PRF as we believe that when a PRF is available it will be available
in both case. With the key pair identified (key_id) and the PRF of
the session has (session_prf), the Key Server is able to check the
length of the payload. If the length does not match, an
"unvalid_payload_format" is returned.
The decryption of the encrypted premaster is performed as described
in Section 8. Note that the TLS versions are only provided to check
the format of the encrypted premaster.
The extended master secret is generated as described in [RFC7627] and
a LURKTLSMasterPayload with the master secret.
Upon receipt of the master_secret the Edge Server can generate the
session keys and finish the TLS key exchange protocol.
struct{
unit16 length
KeyPairID key_id
PRFAlgorithm master_prf // see RFC5246 section 6.1
PRFAlgorithm session_prf // see RFC5246 section 6.1
ProtocolVersion client_version // see RFC5246 section 6.2.1
ProtocolVersion edge_server_version
EncryptedPreMasterSecret // see RFC5246 section 7.4.7.1
opaque session_hash //length - length(keyid) -1
}LURKTLSExtendedMasterRSAInputPayload;
Migault Expires January 9, 2017 [Page 9]
Internet-Draft LURK TLS July 2016
10. Master Secret with RSA Authentication and PFS
[I-D.erb-lurk-rsalg]
11. Signature with ECDHE Authentication
This section describes how the Edge Server request the generation of
signature for ECDHE_RSA or ECDHE_ECDSA as an authentication method.
The EdgeServer provides the Key Server the information to be signed
in a LURKTLSECDHEInputPayload. The payload contains the length of
the inputs (length), the key pair identifier (key_id), the
ClientHello.random (client_random), the ServerHello.random
(edge_server_random), the TLS version (version), signature scheme
which also includes the hash function (signature_scheme) and the
ECDHE parameters of the Edge Server (ecdhe_params).
Upon receipt of a LURKTLSECDHEInputPayload, the Key Server, checks
the key pair identifier (key_id) and the TLS version (version) as
described in Section 8. The Key Server MAY perform some checks on
the ECDHE parameters. If these parameters are not supported it may
return an "unvalid_ecdhparams" error. If a format error is detected,
an "unvalid_ecdhe_format" error may be returned.
[NOTE: We need to provide some additional details on how ECDHE params
can be checked, so it does not appear as an opaque value.]
Then, the key server generates the signature as defined in [RFC4492]
section 5.4.. The Key Server returns a LURKTLSDigitallySignedPayload.
The output of the Key Server has a similar structure as the Signature
structure defined in [RFC4492] section 5.4.
Upon receiving the LURKTLSDigitallySignedPayload the Edge Server
extracts the signature of the payload. It checks the length of the
signature which is known from the signature scheme and the key. In
case of length mismatch, the Edge Server reports an error and aborts
the session. In some case, the Edge Server MAY check the signature
before finalizing the key exchange.
Migault Expires January 9, 2017 [Page 10]
Internet-Draft LURK TLS July 2016
// defined in TLS1.3 section 4.8.1
enum {
// RSASSA-PKCS-v1_5 algorithms
rsa_pkcs1_sha1 (0x0201),
rsa_pkcs1_sha256 (0x0401),
rsa_pkcs1_sha384 (0x0501),
rsa_pkcs1_sha512 (0x0601),
// ECDSA algorithms
ecdsa_secp256r1_sha256 (0x0403),
ecdsa_secp384r1_sha384 (0x0503),
ecdsa_secp521r1_sha512 (0x0603),
// RSASSA-PSS algorithms
rsa_pss_sha256 (0x0700),
rsa_pss_sha384 (0x0701),
rsa_pss_sha512 (0x0702),
// EdDSA algorithms
ed25519 (0x0703),
ed448 (0x0704),
// Reserved Code Points
private_use (0xFE00..0xFFFF),
(0xFFFF)
} SignatureScheme;
struct {
unit16 length
KeyPairID key_id
Random client_random // RFC5246 section 7.4.1.2
Random edge_server_random
ProtocolVersion version
SignatureScheme signature_scheme; // draft-ietf-tls-tls13 sec. 4.8.1
ServerECDHParams ecdhe_params // RFC4492 section 5.4
} LURKTLSECDHEInputPayload;
struct {
opaque signature<0..2^16-1>;
} LURKTLSDigitallySignedPayloads;
12. Unpredictable Signature with ECDHE Authentication
Section 11 describes how LURK enables a Edge Server to chose the 64
bits of the message to be signed. Although in practice the risks are
limited, this section provides a mechanism that prevent the Edge
Server to chose the server random. In addition, the proposed
mechanism prevent an attacker to request the signature of a specific
Migault Expires January 9, 2017 [Page 11]
Internet-Draft LURK TLS July 2016
content. More specifically, upon receiving a content to be signed,
the Key Server, will return the signature of a "modified" content as
well as the necessary parameters to generate the modified content.
The Edge Server is expected to interacts with the TLS Client based on
the modified content.
When the Edge Server uses the unpredictable signature authentication,
in addition to the inputs sent in the case of the traditional ECDHE
signature described in Section 11, the Edge Server adds an Pseudo
Random Function (prf), that will be used by the Key Server to modify
the content to be signed.
The Key Server first starts checking the different arguments provided
by the Edge Server similarly as described in Section 11. As the PRF
(prf) is specific to this exchange, the Key Server checks it supports
the PRF. If not an "unvalid_prf" error is sent. If the prf is
supported, the Key Server generates a new ServerHello.random. The
generation of the new ServerHello.random is built following the guide
lines of Digital Signature section 4.8.1 of [I-D.ietf-tls-tls13] with
a NULL encryption algorithm. The Key Server generates a random nonce
(nonce) and concatenates padding, a 64 byte prefix of of octet 32,
the string "ECDHE ServerHello.random", a zero byte "0", the nonce and
the ServerHello.random provided by the Edge Server. The resulting
string is hashed by the PRF indicated by the Edge Server, and the new
value for the ServerHello.random is the first 32 bytes of that
resulting hash.
The Key Server generates the signature as described in [RFC4492]
section 5.4, with the new ServerHello.random.
Once the signature has been generated, the Key Server returns a
LURKTLSDigitallySignedPayload as well as a LURKTLSNoncePayload.
Upon receipt of these two payloads, the Edge Server generates the
ServerHello.random similarly to the Key Server. The new value for
the ServerHello.random is returned by the Edge Server to the TLS
Client, and the digital signature is returns as previously in the
ServerKeyExchange.
Migault Expires January 9, 2017 [Page 12]
Internet-Draft LURK TLS July 2016
struct {
LURKTLSECDHEInputPayload ecdhe_input
PRFAlgorithm prf // see RFC5246 section 6.1
} LURKTLSECDHEUnpredictableInputPayload;
padding = \
2020202020202020202020202020202020202020202020202020202020202020\
2020202020202020202020202020202020202020202020202020202020202020
context = 45 43 44 48 45 20 53 65 72 76 65 72 48 65 6c 6c
6f 2e 72 61 6e 64 6f 6d
zero-byte = 00
ServerHello.random = PRF(padding + context + zero-byte +
edge_server_random + nonce)[32]
struct {
opaque signature<0..2^16-1>;
opaque new_server_random[32]
} LURKTLSUnpredictableDigitallySignedPayloads;
THESE ARE SOME OPEN QUESTION AND COMMENTS THAT SHOULD BE ADDRESSED
AND SHOULD NOT BE PART OF THE FINAL VERSION OF THE DRAFT.
OPEN QUESTIONS 5): PRIMARY PURPOSE OF USING TLS1.3 PADDING SCHEME IS
TO HAVE ONE PADDING SCHEME USED ACROSS TLS
VERSIONS. IS THAT REASONABLE ?
13. Security Considerations
THIS SECTION CONTAINS ROUGH NOTES. IT NEEDS TO BE RE-WRITTEN, SO ANY
SUGGESTION IS WELCOME.
13.1. Threat Analysis
The TLS Server authentication provides a TLS Client a proof that it
is setting a TLS session with the expected TLS Server. The scope of
the provided authentication credentials is expected to be limited to
the TLS session established between the TLS Client and the TLS
Server.
TLS_AUTH 1: TLS authentication information is expected to be
restrained to a single TLS session.
In addition, motivations to perform illegitimate TLS session may be
to perform a resource exhaustion attack on the TLS Server or to
collect information leaked by the authentication method. As a
Migault Expires January 9, 2017 [Page 13]
Internet-Draft LURK TLS July 2016
result, the additional requirements for the TLS authentication should
be:
TLS_AUTH 2: TLS authentication should not leak information
associated to the Private Keys involved.
TLS_AUTH 3: TLS authentication should involve reasonable resource.
A TLS session is entirely characterized by its key exchange messages.
Among other characteristics, the TLS session is characterized by the
ClientHello.random, the ServerHello.random, the TLS version and the
TLS authentication.
13.2. RSA
13.2.1. TLS Session Binding
With RSA, the premaster secret provided by the TLS Client and
contains the TLS version used at least for TLS version 1.0 and
greater. There is only a single authentication method based on RSA
encryption. In addition, only the owner of the Private Key will be
able to provide the same master secret as the one locally generated
by the TLS Client. As a result, the master secret can hardly be re-
used across different authentication methods or TLS versions which
provides makes master secret some kind of resistant to cross protocol
attacks.
On the other hand the master secret is not bound to all parameters of
the key exchange such as the certificate for example. This exposes
RSA to MiM and master secret may not be bound to a single TLS
session. This vulnerability is addressed by the extended master
secret.
The premaster secret may be used against a TLS version that present
vulnerabilities. The premaster secret may be decrypted using this
vulnerability. Although having different keys for different TLS
version would prevent such protocol attack issue, certificates do not
allow to specify the TLS version.
The following recommendations are intended to address cross protocol
attack for RSA.
RECOMMENDATION 1) Server SHOULD limit the use of RSA to TLS1.0 and
greater version that do not present
vulnerabilities on the RSA authentication method.
RECOMMENDATION 2) TLS Client SHOULD NOT re-use their premaster
secret.
Migault Expires January 9, 2017 [Page 14]
Internet-Draft LURK TLS July 2016
13.2.2. Decryption Oracle
In order to prevent the Key Server to be used as an Bleichenbacher
oracle
RECOMMENDATION 1) The Key Server MUST NOT return any information
associated to the encrypted content. Instead,
when the encrypted data does not meet the expected
format a randomly generated premaster MUST be
generated and used to generate the master secret
or extended master secret returned by the Key
Server to the Edge Server. Currently Section 8
and Section 9 meet this requirements.
RECOMMENDATION 2) The Key Server MUST NOT use a Private Key shared
by a TLS Server implementing a vulnerable TLS
version.
In any proposed method Section 8, Section 9 or in
[I-D.erb-lurk-rsalg], the master secret or extended master secret is
returned instead of the premaster secret. The hash function
increases the difficulty for an attacker to perform chosen cipher
text attack. In fact, a collision free hash function makes difficult
to determine the pre-master secret even though randoms and session-
hash can be provided to the Key Server. As a result:
RECOMMENDATION 3) The Key Server MUST only use collision free PRF.
13.2.3. Illegitimate access to Key Server and PFS
An illegitimate access to a Key Server provides the attacker to send
any request to the Key Server. The Key Server can be used as an
oracle or to perform a single cryptographic operation. An
illegitimate access to the Key Server can be performed via an Edge
Server. If the attacker got control of the Edge Server that
terminates the TLS Session of the TLS Client, then the attacker has a
direct access to the data carried by the TLS Session. This section
does not consider this case. Instead, it considers an attacker that
access to the Key Server, but does not have access to the terminating
Edge Server.
With the operations described in Section 8 and in Section 9, an
attacker intercepting a TLS Session is able to derive the master or
extended master secret by sending a single request to the Key Server.
On the other hand, [I-D.erb-lurk-rsalg] uses a one-way hash that
defines the ServerHello.random as hash(N). In order to retrieve the
master secret, the attacker will need to derive n from hash(n). As
result:
Migault Expires January 9, 2017 [Page 15]
Internet-Draft LURK TLS July 2016
RECOMMENDATION 4) In order to provide PFS [I-D.erb-lurk-rsalg] is
recommended.
13.3. ECDHE
13.3.1. Cross Protocol Attacks
The generation of the signature of the Elliptic Curve Diffie Hellman
parameters involves the ClientHello.random and the
ServerHello.random, but for example the TLS version or the
authentication method are not part of the signature. As a result, an
attacker could provide some signed parameters associated to a
different authentication method. This issue is addressed by TLS1.3
which considers a context associated to the generation of the
signature.
In order to perform a cross protocol attack, a collision MUST occurs
between ClientHello.random, ServerHello.random and the authentication
credentials of two distinct communications. In addition, a given key
and a given signature scheme must be shared by the different
authentication credentials used in the two TLS Sessions.
a) ClientHello.random makes offline more difficult to be performed.
In fact, the ClientHello.random is randomly generated by the TLS
Client. As a result, an attacker willing to usurpate the
identity of the TLS Server, will have to generate a signature
that matches the ClientHello.random. For a given TLS Session,
the probability of success for a given TLS Session is 1 / 2 ** (
32 * 8 ) = 1 / 2 ** 256, and the probability for a random TLS
Session is 1 / 2 ** 128 to have a collision. This still provides
a high bar for collision during offline attacks. With on-line
attack, the attacker knows the values of ClientHello.random,
which raises the probability of collision to 1.
b) ServerHello.random is provided by the TLS Server which provides
the signature. As a result, an attacker usurping the TLS Server
identity will have the possibility to chose the
ServerHello.random.
c) Authentication credentials from different methods needs to match
and to be signed by the same key. A match between DHE and ECDHE
is estimated to be 1 / 2 ** 40, which presents a higher
probability of collision of several order of magnitude.
Cross protocol attack is an issue due to the signature scheme adopted
by TLS 1.2 and previous version. More specifically, the signature
scheme does not enable the Key Server or TLS Server to bind a
signature and authentication credentials to a given authentication
Migault Expires January 9, 2017 [Page 16]
Internet-Draft LURK TLS July 2016
method and TLS version. In order to address this issue, a signature
scheme should be limited to a given authentication credential and TLS
version. Possible ways include:
RECOMMENDATION 5) Server SHOULD limit the use of ECDSA to TLS1.2.
RECOMMENDATION 6) RSA signature SHOULD be preferred for DHE and
ECDSA SHOULD be preferred for ECDHE.
RECOMMENDATION 7) If RSA is used to sign ECDHE parameters, ECDHE
parameters that could be misinterpreted as DHE
parameters SHOULD be removed.
13.3.2. Signing Oracle
Section 5.8 of [RFC4492] defines the signed dayta as:
ClientHello.random + ServerHello.random +
ServerKeyExchange.ecdhe_params
The method described in Section 11 open the Key Server to a first
chosen 64 byte, which is increases by 32 the first chosen 32 byte of
the standard TLS. Section 12 on the other hand reduces it back to
32. In addition, Section 12 makes the signature unpredictable by
generating the ServerHello.random, which reduces the efficiency of
adaptive clear text signing attacks.
13.4. LURKS versus standard TLS1.2
The main difference between LURK and the standard TLS is that with
LURK the cryptographic operations associated to the authentication
are performed by the Key Server instead of the TLS Server.
a) A compromised Edge Server does not present risk of leakage of the
Private Key.
b) A compromised Edge Server can only have access to the Key Server,
and removal of the compromised Edge Server address the issue.
c) Access to the Private Key operations are not only cryptographic
operations, and when a master secret is computed, the
cryptographic output may be harder to access by a potential
attacker.
d) Centralizing provides a global view of the operations performed.
This may be more efficient for monitoring attacks, than
monitoring them locally on the Edge Server.
Migault Expires January 9, 2017 [Page 17]
Internet-Draft LURK TLS July 2016
On the other hand,
a) LURK does not address attacks that rely on the TLS protocols. In
other words, an attack that can be performed by a TLS Client
without the standard TLS is likely to be performed with LURK.
Eventually LURK will ease the detection of such attack making it
harder. In addition, the fact that the Key Server interacts with
authenticated Edge Server does not prevent an TLS Client to
perform the attack.
b) The Key Server provides a lighter way to perform cryptographic
operation that the standard TLS. As a result, if enabled by the
Key Server, an attacker having access to the Key Server will
become more efficient using it, than using a standard TLS Server.
c) LURK provides a bottle neck architecture where the Key Server is
involved for any TLS Sessions.
Note that in order to take the full advanatge of the LURK/TLS,
RECOMMENDATION 8) LURK/TLS SHOULD be used as the only way to perform
operations with the Private Key. More
specifically, LURK/TLS SHOULD NOT be used in
combination of other deployment where the Private
Key is copied on the server.
13.5. DDoS
A TLS Client or a corrupted Edge Server may be willing to perform a
DoS attack by sending random strings, to make the Key Server generate
some premaster or extended prematser. A DoS on the Key Server is
likely to impact all Edge Servers connected to that Key Server.
Although RSA and ECDHE signature have been designed with limited
overhead, cryptographic operations are significantly assymetric in
term of resource engaged.
RECOMMENDATION 9) The Key Server SHOULD control and monitor the
resource associated by the Key Server to each
node. The Key Server does not have any control
over the requesting TLS Client and so is not able
to advertise the Edge Server of an abusive TLS
Client. Instead the Key Server SHOULD be able to
report any detected abuse to an orchestrator that
is in charge of orchestrating the mitigation
either at the Edge Server level and internally,
that is before the traffic reaches the Key Server.
Migault Expires January 9, 2017 [Page 18]
Internet-Draft LURK TLS July 2016
Similarly, the Key Server may be used a reflector for Edge Server.
More specifically, the TLS Client may attack the Edge Server via the
communication between the Key Server and the Edge Server. However,
message exchange between the Edge Server and the Key Server have
responses that are not significantly larger than Edge Server queries.
In addition, the exchange between the Edge Server and the Key Server
and lighter than the one involved between the TLS Client and the Edge
Server.
14. IANA Considerations
15. Acknowledgments
We would like to thank for their very useful feed backs: Yaron
Sheffer, Yoav Nir, Stephen Farrell, Eric Burger, Thomas Fossati, Eric
Rescola.
16. References
16.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>.
[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>.
[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>.
Migault Expires January 9, 2017 [Page 19]
Internet-Draft LURK TLS July 2016
[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>.
16.2. Normative References
[I-D.mglt-lurk-tls-use-cases]
Migault, D., Ma, K., Salz, R., Mishra, S., and O. Dios,
"LURK TLS/DTLS Use Cases", draft-mglt-lurk-tls-use-
cases-02 (work in progress), June 2016.
[I-D.mglt-lurk-tls-requirements]
Migault, D. and K. Ma, "Authentication Model and Security
Requirements for the TLS/DTLS Content Provider Edge Server
Split Use Case", draft-mglt-lurk-tls-requirements-00 (work
in progress), January 2016.
[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.
[I-D.erb-lurk-rsalg]
Erb, S. and R. Salz, "A PFS-preserving protocol for LURK",
draft-erb-lurk-rsalg-01 (work in progress), May 2016.
Appendix A. Example of LURK Exchanges
A.1. LURK/TLS RSA Master Secret
TLS Client Edge Server Key Server
ClientHello
ProtocolVersion server_version
Random client_random
Cipher_suite
TLS_RSA_*, ...
-------->
ServerHello
ProtocolVersion edge_server_version
Random server_random
Cipher_suite=TLS_RSA
Certificate
RSA Public Key
ServerHelloDone
Migault Expires January 9, 2017 [Page 20]
Internet-Draft LURK TLS July 2016
<--------
ClientKeyExchange
EncryptedPremasterSecret
[ChangeCipherSpec]
Finished
-------->
LURKTLSMasterRSAInputPayload
key_id
master_prf
client_random
edge_server_random
client_version
edge_server_version
EncryptedPremasterSecret
-------->
1. Computing Master Secret
master_secret = master_prf(\
pre_master_secret + "master secret" +\
client_random +\
edge_server_random)[0..47];
LURKTLSMasterPayload
master
<--------
[ChangeCipherSpec]
Finished
<--------
Application Data <-------> Application Data
A.2. LURK/TLS RSA Extended Master Secret
TLS Client Edge Server Key Server
ClientHello
ProtocolVersion server_version
Cipher_suite
TLS_RSA_*, ...
Extension 0x0017
-------->
ServerHello
ProtocolVersion edge_server_version
Cipher_suite=TLS_RSA
Migault Expires January 9, 2017 [Page 21]
Internet-Draft LURK TLS July 2016
Extension 0x0017
Certificate
RSA Public Key
ServerHelloDone
<--------
ClientKeyExchange
EncryptedPremasterSecret
[ChangeCipherSpec]
Finished
-------->
LURKTLS Header (Query)
LURKTLSExtendedMasterRSAInputPayload
key_id
master_prf
session_prf
client_version
edge_server_version
EncryptedPreMasterSecret
session_hash
-------->
1. Computing Master Secret
master_secret = master_prf(
pre_master_secret +\
"extended master secret" +\
session_hash)[0..47]
LURKTLS Header (Response)
LURKTLSMasterPayload
master
<--------
[ChangeCipherSpec]
Finished
<--------
Application Data <-------> Application Data
A.3. LURK/TLS ECDHE Signature
TLS Client Edge Server Key Server
ClientHello
ProtocolVersion server_version
Random client_random
Cipher_suite
TLS_ECDHE_ECDSA_*, TLS_ECDHE_RSA_*, ...
Extension Supported EC, Supported Point Format
Migault Expires January 9, 2017 [Page 22]
Internet-Draft LURK TLS July 2016
-------->
LURKTLS Header (Query)
LURKTLSECDHEInputPayload
key_id
client_random
server_random
version
signature_scheme
ecdhe_params
-------->
1. Generating the signature
signature = ECDSA(client_random +\
edge_server_random + echde_params)
LURKTLS Header (Response)
LURKTLSDigitallySignedPayloads
signature
<--------
ServerHello
ProtocolVersion edge_server_version
Random server_random
Cipher_suite=TLS_ECDHE_ECDSA
Extension Supported EC, Supported Point Format
Certificate
ECDSA Public Key
ServerKeyExchange
ecdhe_params
signature
ServerHelloDone
<--------
ClientKeyExchange
[ChangeCipherSpec]
Finished
-------->
[ChangeCipherSpec]
Finished
<--------
Application Data <-------> Application Data
A.4. LURK/TLS/sECDHE Unpredictable
TLS Client Edge Server Key Server
ClientHello
Migault Expires January 9, 2017 [Page 23]
Internet-Draft LURK TLS July 2016
ProtocolVersion server_version
Random client_random
Cipher_suite
TLS_ECDHE_ECDSA_*, TLS_ECDHE_RSA_*, ...
Extension Supported EC, Supported Point Format
-------->
LURKTLS Header (Query)
LURKTLSECDHEInputPayload
key_id
client_random
edge_server_random
version
signature_scheme
ecdhe_params
prf
-------->
1. Generates a random nonce
2. Compute modified edge_server_random
modified_server_random = \
prf(padding + context +\
zero-byte + edge_server_random +\
once)[32]
3. Generate the signature
signature = ECDSA(client_random +\
modified_server_random + echde_params)
LURKTLS Header (Response)
LURKTLSDigitallySignedPayloads
signature
mofified_edge_server_random
<--------
ServerHello
ProtocolVersion edge_server_version
Random modified_edge_server_random
Cipher_suite=TLS_ECDHE_ECDSA
Extension Supported EC, Supported Point Format
Certificate
ECDSA Public Key
ServerKeyExchange
ecdhe_params
signature
ServerHelloDone
<--------
ClientKeyExchange
[ChangeCipherSpec]
Migault Expires January 9, 2017 [Page 24]
Internet-Draft LURK TLS July 2016
Finished
-------->
[ChangeCipherSpec]
Finished
<--------
Application Data <-------> Application Data
Author's Address
Daniel Migault (editor)
Ericsson
8400 boulevard Decarie
Montreal, QC H4P 2N2
Canada
Phone: +1 514-452-2160
Email: daniel.migault@ericsson.com
Migault Expires January 9, 2017 [Page 25]