LURK D. Migault
Internet-Draft Ericsson
Intended status: Standards Track 26 July 2021
Expires: 27 January 2022
LURK Extension version 1 for (D)TLS 1.3 Authentication
draft-mglt-lurk-tls13-05
Abstract
This document describes the LURK Extension 'tls13' which enables
interactions between a LURK client and a LURK server in a context of
authentication with (D)TLS 1.3.
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 https://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 27 January 2022.
Copyright Notice
Copyright (c) 2021 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 (https://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 27 January 2022 [Page 1]
Internet-Draft LURK/TLS 1.3 July 2021
Table of Contents
1. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. LURK Header . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Structures . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. secret_request . . . . . . . . . . . . . . . . . . . . . 7
5.2. handshake . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. session_id . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. freshness . . . . . . . . . . . . . . . . . . . . . . . . 11
5.5. ephemeral . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5.1. shared_secret_provided: . . . . . . . . . . . . . . . 13
5.5.2. secret_generated: . . . . . . . . . . . . . . . . . . 13
5.5.3. no_secret . . . . . . . . . . . . . . . . . . . . . . 14
5.6. selected_identity . . . . . . . . . . . . . . . . . . . . 15
5.7. certificate . . . . . . . . . . . . . . . . . . . . . . . 16
5.8. tag . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.9. secret . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.10. signature . . . . . . . . . . . . . . . . . . . . . . . . 20
6. LURK exchange on the TLS server . . . . . . . . . . . . . . . 20
6.1. s_init_cert_verify . . . . . . . . . . . . . . . . . . . 20
6.2. s_new_tickets . . . . . . . . . . . . . . . . . . . . . . 21
6.3. s_init_early_secret . . . . . . . . . . . . . . . . . . . 22
6.4. s_hand_and_app_secret . . . . . . . . . . . . . . . . . . 23
7. LURK exchange on the TLS client . . . . . . . . . . . . . . . 24
7.1. c_init_post_hand_auth . . . . . . . . . . . . . . . . . . 26
7.2. c_post_hand_auth . . . . . . . . . . . . . . . . . . . . 28
7.3. c_init_cert_verify . . . . . . . . . . . . . . . . . . . 28
7.4. c_init_client_hello . . . . . . . . . . . . . . . . . . . 30
7.5. c_client_hello . . . . . . . . . . . . . . . . . . . . . 32
7.6. c_hand_and_app_secret . . . . . . . . . . . . . . . . . . 33
7.7. c_register_tickets . . . . . . . . . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
11.1. Normative References . . . . . . . . . . . . . . . . . . 37
11.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Annex . . . . . . . . . . . . . . . . . . . . . . . 37
A.1. TLS server ECDHE (no session resumption) . . . . . . . . 37
A.1.1. ecdhe generated on the CS . . . . . . . . . . . . . . 39
A.1.2. ecdhe generated by the TLS server . . . . . . . . . . 39
A.2. TLS server ECDHE ( with session resumption ) . . . . . . 40
A.3. TLS server PSK / PSK-ECDHE . . . . . . . . . . . . . . . 42
A.4. TLS client unauthenticated ECDHE . . . . . . . . . . . . 45
A.5. TLS client unauthenticated PSK / PSK-ECDHE . . . . . . . 49
A.6. TLS client authenticated ECDHE . . . . . . . . . . . . . 50
Migault Expires 27 January 2022 [Page 2]
Internet-Draft LURK/TLS 1.3 July 2021
A.6.1. (EC)DHE or Proposed PSK protected by the CS . . . . . 51
A.6.2. (EC)DHE provided by the TLS client . . . . . . . . . 52
A.7. TLS client authenticated - post handshake
authentication . . . . . . . . . . . . . . . . . . . . . 53
A.7.1. Initial Post Handshake Authentication . . . . . . . . 54
A.7.2. Post Handshake Authentication . . . . . . . . . . . . 54
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 55
1. TODO
1. check the terminology is used. PSK agreed....
2. move the handshake description to the s_exchange description
description
3. state diagram for the server.
2. Introduction
This document defines a LURK extension for TLS 1.3 [RFC8446].
This document assumes the reader is familiar with TLS 1.3 the LURK
architecture [I-D.mglt-lurk-lurk].
Interactions with the Cryptographic Service (CS) can be performed by
the TLS client as well as by the TLS server.
LURK defines an interface to a CS that stores the security
credentials which include the PSK involved in a PSK or PSK-ECDHE
authentication or the key used for signing in an ECDHE
authentication. In the case of session resumption the PSK is derived
from the resumption_master_secret during the key schedule [RFC8446]
section 7.1, this secret MAY require similar protection or MAY be
delegated as in the LURK extension of TLS 1.2 [I-D.mglt-lurk-tls12].
The current document extends the scope of the LURK extension for TLS
1.2 in that it defines the CS on the TLS server as well as on the TLS
client and the CS can operate in non delegating scenarios.
This document defines the role to specify whether the CS runs on a
TLS client or a TLS service. The CS MUST be associated a single
role.
From a LURK client perspective, the purpose of the LURK exchange is
to request secrets, a signing operations, or ticket
(NewSessionTicket) as summed up in Table Figure 1.
Migault Expires 27 January 2022 [Page 3]
Internet-Draft LURK/TLS 1.3 July 2021
+--------+-----------------------+------------------------+
| Role | LURK exchange | secret | sign | ticket |
+--------+-----------------------+--------+------+--------+
| server | s_init_early_secret | yes | - | - |
| server | s_init_cert_verify | yes | yes | - |
| server | s_hand_and_app_secret | yes | - | - |
| server | s_new_ticket | yes | - | yes |
| client | c_init_post_hand_auth | - | yes | - |
| client | c_post_hand_auth | - | yes | - |
| client | c_init_cert_verify | yes | yes | - |
| client | c_init_early_secret | yes | - | - |
| client | c_init_hand_secret | yes | - | - |
| client | c_hand_and_app_secret | yes | - | - |
| client | c_register_tickets | yes | - | yes |
+--------+-----------------------+--------+------+--------+
Figure 1: Operation associated to LURK exchange
The number of operations are limited, but the generation of secrets,
tickets as well as signing heavily rely on the knowledge of the TLS
handshake messages and in turn impacts these TLS handshake messages.
As a result, these operations are highly inter-dependent. This is
one reason multiple sequential exchanges are needed between the LURK
client and the CS as opposed to independent requests for secrets,
signing or tickets. This especially requires the necessity to create
a session between the LURK client and the CS. In addition, the LURK
client and the CS need to synchronize the TLS handshake. First it is
a necessary component for the CS to generate the secrets, signature
and tickets. Second, elements are respectively generated by the LURK
client and by the CS.
While all these messages do share a lot of structures, they also
require different structure that make them unique.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the terms defined [RFC8446] and
[I-D.mglt-lurk-tls12].
ECHDE designates the ECDHE authentication defined in [RFC8446].
(EC)DHE
Migault Expires 27 January 2022 [Page 4]
Internet-Draft LURK/TLS 1.3 July 2021
designates the shared secret agreed by the key_share extension
(section 4.2.8 of [RFC8446]) during a TLS handshake.
PSK Proposed A TLS handshake between a TLS client and a TLS server
is said to be "PSK proposed" when the latest ClientHello contains
a psk_key_exchange_modes (section 4.2.9 of [RFC8446]) and a
pre_shared_key (section 4.2.11 of [RFC8446]) extension. A TLS
client is said to "propose PSK" when its TLS handshake is PSK
proposed.
PSK Agreed A TLS handshake between a TLS client and a TLS server is
said to be "PSK agreed" when the TLS handshake is PSK proposed and
the ServerHello contains a psk_key_exchange_modes and a
pre_shared_key extension. A TLS client and a TLS server are said
to have "agreed on PSK" when its TLS handshake is PSK agreed.
ECDHE Agreed A TLS handshake between a TLS client and a TLS server
is said to be "ECDHE agreed" when the ServerHello contains neither
a psk_key_exchange_modes or a pre_shared_key extension. As
currently TLS proposes only ECDHE and PSK based authentication,
when PSK agreed is false, ECDHE agreed is true. A TLS client and
a TLS server are said to have "agreed on ECDHE" when its TLS
handshake is PSK agreed.
Key Share Proposed A TLS handshake between a TLS client and a TLS
server is said to be "key shared proposed" or "(EC)DHE proposed"
when the latest ClientHello contains a key_share extension
(section 4.2.8 of [RFC8446]). A TLS client is said to "propose
PSK" when its TLS handshake is PSK proposed.
Key Share Agreed A TLS handshake between a TLS client and a TLS
server is said to be "key shared agreed" or "(EC)DHE agreed" when
the TLS handshake is key shared proposed and the ServerHello
contains neither a key_share extension. A TLS client and a TLS
server are said to have "agreed on (EC)DHE" when its TLS handshake
is key share agreed.
Early Data Enabled A TLS client is said to "support early data" or
"enable early data" when its latest ClientHello contains a
early_data extension (section 4.2.10 of [RFC8446].
Post Handshake Enabled: A TLS client is said to "support early data"
or "enable early data" when its latest ClientHello contains a
post_handshake_auth extension.
Migault Expires 27 January 2022 [Page 5]
Internet-Draft LURK/TLS 1.3 July 2021
4. LURK Header
LURK / TLS 1.3 is a LURK Extension that introduces a new designation
"tls13". This document assumes that Extension is defined with
designation set to "tls13" and version set to 1. The LURK Extension
extends the LURKHeader structure defined in [I-D.mglt-lurk-lurk] as
follows:
enum {
tls13 (2), (255)
} Designation;
enum {
capabilities(0),
ping(1),
s_init_cert_verify(2),
s_new_ticket(3),
s_init_early_secret(4),
s_hand_and_app_secret(5),
c_binder_key(6),
c_init_early_secret(7),
c_init_hand_secret(8),
c_hand_secret(9),
c_app_secret(10),
c_cert_verify(11),
c_register_tickets(12),
c_post_hand(13), (255)
}TLS13Type;
enum {
// generic values reserved or aligned with the
// LURK Protocol
request (0), success (1), undefined_error (2),
invalid_payload_format (3),
invalid_psk
invalid_freshness
invalid_request
invalid_key_id_type
invalid_key_id
invalid_signature_scheme
invalid_certificate_type
invalid_certificate
invalid_certificate_verify
invalid_secret_request
invalid_handshake
Migault Expires 27 January 2022 [Page 6]
Internet-Draft LURK/TLS 1.3 July 2021
invalid_extension
invalid_ephemeral
invalid_identity
too_many_identities
}TLS13Status
struct {
Designation designation = "tls13";
int8 version = 1;
} Extension;
struct {
Extension extension;
select( Extension ){
case ("tls13", 1):
TLS13Type;
} type;
select( Extension ){
case ("tls13", 1):
TLS13Status;
} status;
uint64 id;
unint32 length;
} LURKHeader;
5. Structures
This section describes structures that are widely re-used across the
multiple LURK exchanges.
5.1. secret_request
secret_request is a 16 bit structure described in Table Figure 2 that
indicates the requested key or secrets by the LURK client. The
secret_request structure is present in the request of any exchange
except for a c_post_hand exchange. The same structure is used across
all LURK exchanges, but each LURK exchange only permit a subset of
values described in Table Figure 3.
A LURK client MUST NOT set secret_request to key or secrets that are
not permitted. The CS MUST check the secret_request has only
permitted values and has all mandatory keys or secrets set. If these
two criteria are not met the CS MUST NOT perform the LURK exchange
and SHOULD return a invalid_secret_request error. If the CS is not
able to compute an optional key or secret, the CS MUST proceed the
LURK exchange and ignore the optional key or secret.
Migault Expires 27 January 2022 [Page 7]
Internet-Draft LURK/TLS 1.3 July 2021
+------+-------------------------------------------+
| Bit | key or secret (designation) |
+------+-------------------------------------------+
| 0 | binder_key (b) |
| 1 | client_early_traffic_secret (e_c) |
| 2 | early_exporter_master_secret (e_x) |
| 3 | client_handshake_traffic_secret (h_c) |
| 4 | server_handshake_traffic_secret (h_s) |
| 5 | client_application_traffic_secret_0 (a_c) |
| 6 | server_application_traffic_secret_0 (a_s) |
| 7 | exporter_master_secret (x) |
| 8 | resumption_master_secret (r) |
| 9-15 | reserved and set to zero |
+------+-------------------------------------------+
Figure 2: secret_request structure
+-----------------------+-----------------------------+
| LURK exchange | Permitted secrets |
+-----------------------+-----------------------------+
| s_init_cert_verify | h_c*, h_s*, a_c*, a_s*, x* |
| s_new_ticket | r* |
| s_init_early_secret | b,e_c*, e_x* |
| s_hand_and_app_secret | h_c, h_s, a_c*, a_s*, x* |
| c_init_post_hand_auth | - |
| c_post_hand_auth | - |
| c_init_cert_verify | a_c*, a_s*, x* |
| c_init_client_hello | b*, e_c*, e_x* |
| c_client_hello | b*, e_c*, e_x* |
| c_hand_and_app_secret | h_c, h_s, a_c*, a_s*, x*, r*|
| c_register_tickets | - |
+-----------------------+-----------------------------+
* indicates the secret MAY be requested
- indicates no secrets van be requested
Figure 3: secret_request permitted values per LURK exchange
5.2. handshake
The derivation of the secrets, signing operation and tickets requires
the TLS handshake. The TLS handshake is described in [RFC8446]
section 4 and maintained by the TLS server and the TLS client to
derive the same secrets. As the CS is in charge is deriving the
secrets as well to perform some signature verification, the CS must
be be aware of the TLS handshake. The TLS handshake is not
necessarily being provided by the LURK client to the CS, but instead
is derived some structures provided by the LURK client as well as
other structures generated or modified by the CS.
Migault Expires 27 January 2022 [Page 8]
Internet-Draft LURK/TLS 1.3 July 2021
When an unexpected handshake context is received, the CS SHOULD
return an invalid_handshake error.
The value of the TLS hanshake is defined in [RFC8446] section 4 and
remainded in Table Figure 4 reminds the TLS handshake values after
each LURK exchange and describes operations performed by the CS in
order to build it.
On the TLS server:
* (a) ServerHello.random value provided by the LURK client requires
specific treatment as described in Section 5.4 before being
inserted in the TLS handshake variable.
* (b) When the shared secret ( and so the private ECDHE ) is
generated by the CS, the KeyShareServerHello structure cannot be
provided to the CS by the LURK client in a ServerHello and is
instead completed by the CS as described in Section 5.5.
* (c) The TLS Certificate structure MUST not be provided by the LURK
client as part of the handshake structure. Instead, the CS
generates the Certificate message from the certificate structure
described in Section 5.7. The handshake MUST NOT contain a TLS
Certificate message and CS SHOULD raise an invalid_handshake_error
if such message is found in the TLS handshake. When a client
Certificate is provided, the CS SHOULD raise an invalid_handshake
error in the absence of a CertificateRequest message.
* (d) The Certificate and Finished messages are not provided in a
handshake structure by the LURK client but are instead generated
by the CS as described in Section 5.10.
* (e) Some authentication PSK_ECHDE or ECDHE requires the agreement
of a shared ECDHE secret. This is indicated by the presence of
key_share extension in both ClientHello and ServerHello. When
these extensions are not found, the CS SHOULD raise an error.
Note that in the case of PSK / PSK-ECDHE, the presence or absence
of key_share extension MAY be used to distinguish between the two
authentication methods.
* (f) ECDHE authentication does not involve the agreement of a PSK.
This is indicated by the presence of a key_share extension in both
ClientHello and ServerHello. When these extensions are found, the
CS SHOULD raise an error.
Migault Expires 27 January 2022 [Page 9]
Internet-Draft LURK/TLS 1.3 July 2021
* (g) PSK and PSK_ECDHE requires the agreement of a PSK, so a psk is
expected in the ClientHello as well as - when present in the
ServerHello. When this extension are not found, the CS SHOULD
raise an error.
+-----------------------+------------------------------------+---------------+
| LURK exchange | TLS handshake | CS operations |
+-----------------------+------------------------------------+---------------+
| s_init_cert_verify | ClientHello ... later of | a,b,c,d,e,f |
| | server EncryptedExtensions / | |
| | CertificateRequest | |
| s_new_ticket | earlier of client Certificate / | c |
| | client CertificateVerify / | |
| | Finished ... Finished | |
| s_init_early_secret | ClientHello | a, g |
| s_hand_and_app_secret | ServerHello ... later of | b, g |
| | server EncryptedExtensions / | |
| | CertificateRequest | |
| c_init_post_hand_auth | ClientHello ... ServerHello | e |
| | CertificateRequest | |
| c_post_hand_auth | CertificateRequest | |
| c_init_cert_verify | ClientHello...server Finished | e,f |
| c_init_client_hello | (Partial) ClientHello or | |
| | ClientHello, HelloRetryRequest, | |
| | (Partial) ClientHello | |
| c_client_hello | HelloRetryRequest, (Partial) ClientHello |
| c_hand_and_app_secret | ServerHello, {EncryptedExtensions} | |
| | ... later of { server Finished } / | |
| | EndOfEarlyData | |
| c_register_tickets | - | |
+-----------------------+------------------------------------+---------------+
Figure 4: handshake values per LURK exchange
Handshake handshake<0..2^32> //RFC8446 section 4 (clear) clientHello...client finished CertificateRequest
5.3. session_id
The session_id is a 32 bit identifier that identifies a LURK session
between a LURK client and a CS. Unless the exchange is sessionless,
the session_id is negotiated at the initiation of the LURK session
where the LURK client (resp. the CS) indicates the value to be used
for inbound session_id in the following LURK exchanges. For other
LURK exchanges, the session_id is set by the sender to the inbound
value provided by the receiving party. When the CS receives an
unexpected session_id the CS SHOULD return an invalid_session_id
error.
Migault Expires 27 January 2022 [Page 10]
Internet-Draft LURK/TLS 1.3 July 2021
Table Figure 5 indicates the presence of the session_id.
+-----------------------+------------+
| LURK exchange | session_id |
+-----------------------+------------+
| s_init_cert_verify | * |
| s_new_ticket | y |
| s_init_early_secret | y |
| s_hand_and_app_secret | y |
| c_init_post_hand_auth | * |
| c_post_hand_auth | y |
| c_init_cert_verify | * |
| c_init_client_hello | y |
| c_client_hello | y |
| c_hand_and_app_secret | y |
| c_register_tickets | y |
+-----------------------+------------+
y indicates the session_id is present
- indicates session_id may be absent
* indicates session_id may be present (depending on the tag.last_message)
Figure 5: session_id in LURK exchanges
The session_id structure is defined below: ~~~ uint32 session_id ~~~
5.4. freshness
The freshness function implements perfect forward secrecy (PFS) and
prevents replay attack. On the TLS server, the CS generates the
ServerHello.random of the TLS handshake that is used latter to derive
the secrets. The ServerHello.random value is generated by the CS
using the freshness function and the ServerHello.random provided by
the LURK client in the handshake structure. The CS operates
similarly on the TLS client and generates the ClientHello.random of
the TLS handshake using the freshness function as well as the
ClientHello.random value provided by the LURK client in the handshake
structure.
If the CS does not support the freshness, the CS SHOULD return an
invalid_freshness error. In this document the freshness function is
implemented by applying sha256.
Table {table:freshness} details the exchanges that contains the
freshness structure.
Migault Expires 27 January 2022 [Page 11]
Internet-Draft LURK/TLS 1.3 July 2021
+-----------------------+-----------+
| LURK exchange | freshness |
+-----------------------+-----------+
| s_init_cert_verify | y |
| s_new_ticket | - |
| s_init_early_secret | - |
| s_hand_and_app_secret | y |
| c_init_post_hand_auth | y |
| c_post_hand_auth | - |
| c_init_cert_verify | y |
| c_init_client_hello | y |
| c_client_hello | - |
| c_hand_and_app_secret | - |
| c_register_tickets | - |
+-----------------------+-----------+
y indicates freshness is present
- indicates freshness is absent
Figure 6: freshness in LURK exchange
The extension data is defined as follows:
enum { sha256(0) ... (255) } Freshness;
When the CS is running on the TLS server, the ServerHello.random is
generated as follows:
server_random = ServerHello.random
ServerHello.random = freshness( server_random + "tls13 pfs srv" );
When the CS is running on the TLS client, the ClientHello.random is
generated as follows:
client_random = ClientHello.random
ClientHello.random = freshness( client_random + "tls13 pfs clt" );
The server_random (resp client_random) MUST be deleted once it has
been received by the CS. In some cases, especially when the TLS
client enables post handshake authentication and interacts with the
CS via a (c_init_post_hand_auth) exchange, there might be some delay
between the ClientHello is sent to the server and the Handshake
context is shared with the CS. The client_random MUST be kept until
the post-handshake authentication is performed as the full handshake
is provided during this exchange.
Migault Expires 27 January 2022 [Page 12]
Internet-Draft LURK/TLS 1.3 July 2021
5.5. ephemeral
The Ephemeral structure carries the necessary information to generate
the (EC)DHE shared secret used to derive the secrets. This document
defines the following ephemeral methods to generate the (EC)DHE
shared secret:
* secret_provided: Where (EC)DHE keys and shared secret are
generated by the TLS server and provided to the CS
* secret_generated: Where the (EC)DH keys and shared secret are
generated by the CS.
* no_secret: where no (EC)DHE is involved, and PSK authentication is
performed.
5.5.1. shared_secret_provided:
When ECDHE shared secret are generated by the TLS server, the LURK
client provides the shared secret value to the CS. The shared secret
is transmitted via the SharedSecret structure, which is similar to
the key_exchange parameter of the KeyShareEntry described in The CS
MUST NOT return any data.[RFC8446] section 4.2.8.
struct {
NamedGroup group;
opaque shared_secret[coordinate_length];
} SharedSecret;
Where coordinate_length depends on the chosen group. For secp256r1,
secp384r1, secp521r1, x25519, x448, the coordinate_length is
respectively 32 bytes, 48 bytes, 66 bytes, 32 bytes and 56 bytes.
Upon receiving the shared_secret, the CS MUST check group is proposed
in the KeyShareClientHello and agreed in the KeyShareServerHello.
5.5.2. secret_generated:
When the ECDHE public/private keys are generated by the CS, the LURK
client requests the CS the associated public value. Note that in
such cases the CS would receive an incomplete Handshake Context from
the LURK client with the public part of the ECDHE missing. Typically
the ServerHello message would present a KeyShareServerHello that
consists of a KeyShareEntry with an empty key_exchange field, but the
field group is present.
The CS MUST check the group field in the KeyShareServerHello, and get
the public value of the TLS client from the KeyShareClientHello. The
CS performs the same checks as described in [RFC8446] section 4.2.8.
Migault Expires 27 January 2022 [Page 13]
Internet-Draft LURK/TLS 1.3 July 2021
The CS generates the private and public (EC)DH keys, computes the
shared key and return the KeyShareEntry server_share structure
defined in [RFC8446] section section 4.2.8 to the LURK client.
5.5.3. no_secret
With PSK authentication, (EC)DHE keys and shared secrets are not
needed. The CS SHOULD check the PSK authentication has been agreed,
that is pre_shared_key and psk_key_exchamge_modes extensions are noth
present in the ClientHello and in the ServerHello
When the ephemeral method or the group is not supported, the CS
SHOULD return an invalid_ephemeral error.
+-----------------------+-----------+---------------------------+
| | | ephemeral_method= secret |
| LURK exchange | ephemeral | no | provided | generated |
+-----------------------+-----------+----+----------+-----------+
| s_init_cert_verify | y+ | - | y | y |
| s_new_ticket | - | - | - | - |
| s_init_early_secret | - | - | - | - |
| s_hand_and_app_secret | y | y | y | y |
| c_init_post_hand | y | - | y | - |
| c_post_hand | y | - | y | y |
| c_init_cert_verify | y | - | y | y |
| c_init_client_hello | y | y | - | y |
| c_client_hello | y | y | - | y |
| c_hand_and_app_secret | y | y | y | - |
| c_register_tickets | - | - | - | - |
+-----------------------+-----------+----+----------+-----------+
y indicates presence of ephemeral or possible value for ephemeral_method
- indicates absent or ephemeral or incompatible value for ephemeral_method
Figure 7: Ephemeral field in LURK exchange
The extension data is defined as follows:
Migault Expires 27 January 2022 [Page 14]
Internet-Draft LURK/TLS 1.3 July 2021
enum { no_secret (0), secret_provided(1), secret_generated(2) (255)} EphemeralMethod;
EphemeralRequest {
EphemeralMethod method;
select(method) {
case secret_provided:
SharedSecret shared_secret<0..2^16>;
}
}
EphemeralResponse {
select(method) {
case secret_generated:
KeyShareEntry server_share
}
}
5.6. selected_identity
The selected_identity indicates the identity of the PSK used in the
key schedule. The selected_identity is expressed as a (0-based)
index into the identities in the client's list. The client's list is
provided in the pre_shared_key extension as expressed in [RFC8446]
section 4.2.11.
The LURK client MUST provide the selected_identity only when PSK or
PSK-authentication is envisioned and when the PSK has not been
provided earlier. These exchanges are s_init_early_secret on the TLS
server and c_init_early_secret and c_init_hand_secret on the TLS
client side.
Migault Expires 27 January 2022 [Page 15]
Internet-Draft LURK/TLS 1.3 July 2021
+-----------------------+-----+
| LURK exchange | req |
+-----------------------+-----+
| s_init_cert_verify | - |
| s_new_ticket | - |
| s_init_early_secret | y |
| s_hand_and_app_secret | - |
| c_init_post_hand_auth | - |
| c_post_hand_auth | - |
| c_init_cert_verify | - |
| c_init_client_hello | - |
| c_client_hello | - |
| c_hand_and_app_secret | - |
| c_register_tickets | - |
+-----------------------+-----+
y indicates the selected_identity is present
- indicates the selected_identity is absent
Figure 8: psk_id in LURK exchange
The extension data is defined as follows:
uint16 selected_identity; //RFC8446 section 4.2.11
The CS retrieve the PSK identity from the ClientHello and SHOULD send
an invalid_psk error if an error occurs. If the PSK is not provided,
a default PSK is generated as described in [RFC8446] section 7.1. If
the default PSK is not allowed then an invalid_psk is returned.
5.7. certificate
The certificate structure indicates the presence and associated value
of the Certificate message in the TLS handshake.
Upon receiving a certificate field, the CS MUST: 1. ensure coherent
with the handshake messages - typically authentication method is
ECDHE and not PSK or PSK-ECDHE. 2. ensure the provided value
corresponds to an acceptable provisioned value. 3. generate the
appropriated corresponding message.
If the CS is not able to understand the lurk_tls13_certificate field,
it SHOULD return an invalid_certificate error.
Table Figure 9 indicates the presence of that field in the LURK
exchanges.
Migault Expires 27 January 2022 [Page 16]
Internet-Draft LURK/TLS 1.3 July 2021
+-----------------------+-------------+--------------------+
| LURK exchange | certificate | certificate type |
+-----------------------+-------------+--------------------+
| s_init_cert_verify | y | server certificate |
| s_new_ticket | * | client certificate |
| s_init_early_secret | - | |
| s_hand_and_app_secret | - | |
| c_init_post_hand_auth | y | client_certificate |
| c_post_hand_auth | y | client_certificate |
| c_init_cert_verify | y | client certificate |
| c_init_client_hello | - | |
| c_client_hello | - | |
| c_hand_and_app_secret | y | client_certificate |
| c_register_tickets | - | |
+-----------------------+-------------+--------------------+
* indicates certificate type MAY be set to emtpy.
y indicates certificate type MUST NOT be set to empty
- indicates the certificate structure is absent
Figure 9: certificate per LURK exchange
There are different ways the LURK client can provide the certificate
message:
enum { empty(0), finger_print(1), uncompressed(2), (255)
}; LURKTLS13CertificateType
struct {
LURKTLS13CertificateType certificate_type;
select (certificate_type) {
case empty:
// no payload
case finger_print
uint32 hash_cert;
case uncompressed:
Certificate certificate; // RFC8446 section 4.4.2
};
} LURKTLS13Certificate;
empty indicates there is no certificates provided by this field.
fingerprint a 4 bytes finger print length that represents the
Migault Expires 27 January 2022 [Page 17]
Internet-Draft LURK/TLS 1.3 July 2021
fingerprinting of the TLS Certificate message. Fingerprinting is
described in [RFC7924] and takes as input the full handshake
message - that is a message of message type certificate with that
contain the Certificate as its message_data. In this document
only the 4 most left bytes of the output are considered.
uncompressed
indicates the Certificate message as defined in [RFC8446] is
provided.
5.8. tag
This field provides extra information. Currently, the tag structure
defines tag.last_message and tag.cert_request.
The LURK client or the CS sets the tag.last_message to terminate the
LURK session. The tag.cert_request is only used by the CS in a
c_hand_and_app_secret exchange. The tag.cert_request by the CS when
a CertificateRequest has been found in the handshake and that the CS
includes in its response the necessary information to the TLS client
to build a CertificateVerify message (see Section 7.6 ).
In this document, we use setting, setting to True to indicate the bit
is set to 1. Respectively, we say unsetting, setting to False to
indicate the bit is set to 0.
Table Figure 10 indicates the different values carried by the tag as
well as the exchange these tags are considered. The bits values MUST
be ignored outside their exchange context and bits Bits that are not
specified within a given exchange MUST be set to zero by the sender
and MUST be ignored by the receiver.
+------+----------------+
| Bit | description |
+------+----------------+
| 0 | last_exchange |
| 1 | cert_request |
| 2-7 | RESERVED |
+------+----------------+
Figure 10: tag description
Migault Expires 27 January 2022 [Page 18]
Internet-Draft LURK/TLS 1.3 July 2021
+-----------------------+--------------+--------------+
| LURK exchange | last_message | cert_request |
+-----------------------+--------------+--------------+
| s_init_cert_verify | y | - |
| s_new_ticket | y | - |
| s_init_early_secret | - | - |
| s_hand_and_app_secret | y | - |
| c_init_post_hand_auth | y | - |
| c_post_hand_auth | y | - |
| c_init_cert_verify | y | - |
| c_init_client_hello | - | - |
| c_client_hello | - | _ |
| c_hand_and_app_secret | y | y (response) |
| c_register_tickets | y | - |
+-----------------------+--------------+--------------+
y indicates tag is present
- indicates tag is absent
Figure 11: tag per LURK exchange
5.9. secret
The Secret structure is used by the CS to send the various secrets
derived by the key schedule described in [RFC8446] section 7.
enum {
binder_key (0),
client_early_traffic_secret(1),
early_exporter_master_secret(2),
client_handshake_traffic_secret(3),
server_handshake_traffic_secret(4),
client_application_traffic_secret_0(5),
server_application_traffic_secret_0(6),
exporter_master_secret(7),
esumption_master_secret(8),
(255)
} SecretType;
struct {
SecretType secret_type;
opaque secret_data<0..2^8-1>;
} Secret;
secret_type: The type of the secret or key
secret_data: The value of the secret.
Migault Expires 27 January 2022 [Page 19]
Internet-Draft LURK/TLS 1.3 July 2021
5.10. signature
The signature requires the signature scheme, a private key and the
appropriated context. The signature scheme is provided using the
SignatureScheme structure defined in [RFC8446] section 4.2.3, the
private key is derived from the lurk_tls13_certificate Section 5.7
and the context is derived from the handshake Section 5.2 and
lurk_tls13_certificate Section 5.7.
Signing operations are described in [RFC8446] section 4.4.3. The
context string is derived from the role and the type of the LURK
exchange as described below. The Handshake Context is taken from the
key schedule context.
+--------------------+-------------------------------------+
| type | context |
+--------------------+-------------------------------------+
| s_init_cert_verify | "TLS 1.3, server CertificateVerify" |
| c_cert_verify | "TLS 1.3, client CertificateVerify" |
+--------------------+-------------------------------------+
struct {
opaque signature<0..2^16-1>; //RFC8446 section 4.4.3.
} Signature;
6. LURK exchange on the TLS server
This section describes the LURK exchanges that are performed on the
TLS server. Unless specified used structures are described in
Section 5
6.1. s_init_cert_verify
s_init_cert_verify initiates a LURK session when the server is
authenticated with ECDHE. The ClientHello received by the TLS
server, and the ServerHello and optionally the HelloRetryRequest MUST
carry a key_share extension.
If the LURK client is configured to not proceed to further exchange,
it sets the last_exchange bit of the tag. When this bit is set, the
session_id is ignored. The CS sets the last_exchange bit if the
last_exchange bit has been set by the LURK client or when it has been
configured to not accept further LURK exchanges, such as
s_new_ticket.
Migault Expires 27 January 2022 [Page 20]
Internet-Draft LURK/TLS 1.3 July 2021
struct{
uint8 tag;
select (tag.last_exchange){
case False:
uint32 session_id;
}
FreshnessFunct freshness;
Ephemeral ephemeral;
Handshake handshake<0..2^32>; //RFC8446 section 4
LURKTLS13Certificate certificate;
uint16 secret_request;
SignatureScheme sig_algo; //RFC8446 section 4.2.3.
}SInitCertVerifyRequest
struct{
uint8 tag;
select (tag.last_exchange){
case False:
uint32 session_id;
}
Ephemeral ephemeral;
Secret secret_list<0..2^16-1>;
Signature signature;
}SInitCertVerifyResponse
sig_algo SignatureScheme is defined in [RFC8446] section 4.2.3.
6.2. s_new_tickets
new_session ticket handles session resumption. It enables to
retrieve NewSessionTickets that will be forwarded to the TLS client
by the TLS server to be used later when session resumption is used.
It also provides the ability to delegate the session resumption
authentication from the CS to the TLS server. In fact, if the LURK
client requests and receives the resumption_master_secret it is able
to emit on its own NewSessionTicket. As a result s_new_ticket LURK
exchanges are only initiated if the TLS server expects to perform
session resumption and the CS responds only if if session_resumption
is enabled.
The CS MAY responds with a resumption_master_secret based on its
policies.
The LURK client MAY perform multiple s_new_ticket exchanges. The
LURK client and CS are expected to advertise by setting the
last_exchange bit in the tag field.
Migault Expires 27 January 2022 [Page 21]
Internet-Draft LURK/TLS 1.3 July 2021
struct {
uint8 tag
uint32 session_id
Handshake handshake<0..2^32> //RFC8446 section 4.
LURKTLS13Certificate certificate;
uint8 ticket_nbr;
uint16 secret_request;
} SNewTicketRequest;
struct {
uint8 tag
uint32 session_id
Secret secret_list<0..2^16-1>;
NewSessionTicket ticket_list<0..2^16-1>; //RFC8446 section 4.6.1.
} SNewTicketResponse;
ticket_nbr: designates the requested number of NewSessionTicket. In
the case of delegation this number MAY be set to zero. The CS MAY
responds with less tickets when the value is too high.
6.3. s_init_early_secret
s_init_early_secret initiates a LURK session when the server is
authenticated by the PSK or PSK-ECDHE methods. This means the
ClientHello received by the TLS server and ServerHello responded by
the TLS server MUST carry the pre_shared_key and
psk_key_exchange_modes extensions.
selected_identity indicates the selected PSK
struct{
uint32 session_id
FreshnessFunct freshness
uint16 selected_identity
Handshake handshake<0..2^32> //RFC8446 section 4
uint16 secret_request;
}SInitEarlySecretRequest
struct{
uint32 session_id
Secret secret_list<0..2^16-1>;
}SInitEarlySecretResponse
Migault Expires 27 January 2022 [Page 22]
Internet-Draft LURK/TLS 1.3 July 2021
The binder_key MUST be requested, since it is used to validate the
PSK. The TLS client MAY indicate support for early application data
via the early_data extension. Depending on the TLS server policies,
it MAY accept early data and request the client_early_traffic_secret.
The TLS server MAY have specific policies and request
early_exporter_master_secret.
The CS MUST check pre_shared_key and psk_key_exchange_modes
extensions are present in the ClientHello message. If these
extensions are not present, a invalid_handshake error SHOULD be
returned. The CS MUST ignore the client_early_traffic_secret if
early_data extension is not found in the ClientHello. The
Cryptographic Service MAY ignore the request for
client_early_traffic_secret or early_exporter_master_secret depending
on configuration parameters.
6.4. s_hand_and_app_secret
The s_hand_and_app_secret is necessary to complete the ServerHello
and always follows an s_init_early_secret LURK exchange. Such
sequence is guaranteed by the session_id. In case of unknown
session_id or an invalid_request error SHOULD be returned.
The LURK client MUST ensure that PSK or PSK-ECDHE authentication has
been selected via the presence of the pre_shared_key extension in the
ServerHello. In addition, the selected identity MUST be the one
provided in the pre_shared_key extension of the previous
s_init_early_secret exchange. The CS MUST also check the selected
cipher in the ServerHello match the one associated to the PSK. The
CS generates the Finished message as described in [RFC8446] section
4.4.4. Which involves the h_s secret. The LURK client MAY request
the exporter_master_secret depending on its policies. The CS MAY
ignore the request based on its policies.
If the LURK client is configured to not proceed to further exchange,
it sets the last_exchange bit of the tag. The CS sets the
last_exchange bit if the last_exchange bit has been set by the LURK
client or when it has been configured to not accept further LURK
exchange.
Migault Expires 27 January 2022 [Page 23]
Internet-Draft LURK/TLS 1.3 July 2021
struct{
uint8 tag
uint32 session_id
Ephemeral ephemeral
Handshake handshake<0..2^32> //RFC8446 section 4
uint16 secret_request;
} SHandAndAppSecretRequest
struct{
uint8 tag
uint32 session_id
Ephemeral ephemeral
Secret secret_list<0..2^16-1>;
} SHandAndAppSecretResponse
7. LURK exchange on the TLS client
The CS described in this document considers the case where PSK and
(EC)DHE private part MAY be protected by the CS. This document does
not consider the case where a TLS client may propose a combination of
protected and unprotected PSKs. Either all proposed PSK are
unprotected by the CS or all PSK are protected by the CS. Similarly,
this document does not consider the case where a TLS client may
propose a combination of protected and unprotected (EC)DHE. Either
all (EC)DHE are generated by the CS or all (EC)DHE are generated by
the TLS client.
Figure Figure 12 summarizes the different possible LURK session as
well as the different messages that are involved in the session.
Migault Expires 27 January 2022 [Page 24]
Internet-Draft LURK/TLS 1.3 July 2021
^ | no
| (EC)DHE in CS or ------------+
ClientHello | PSK in CS Proposed |
Derivation | yes | |
| c_init_client_hello |
| | no |
| Hello Retry Request --+ |
| yes | | |
ClientHello | c_client_hello | |
sent -->v |<------------+ |
ServerHello-->^ | | no
received | | ECDHE Agreed --+
| | yes | |
ServerHello | c_hand_and_app_secret c_init_cert_verify|
Treatment | | | |
clientFinished| +-------+------------+ | no
sent -->v | Post Auth Enabled --+
^ | + |
| | CertificateRequest |
| | | |
| | c_init_post_hand_auth|
| | | |
|+----------------->|<--------------------+ |
Posthandshake || +---------+-------+ |
Treatment || | | |
||Post Auth Enabled (EC)DHE in CS or |
|| + Agreed PSK in CS |
||CertificateRequest + |
|| | NewSessionTicket |
|| | | |
||c_post_hand_auth c_register_tickets |
|| | | |
|| +-------+---------+ |
|| | |
v+----------------+ +-----+
| |
LURK session LURK session
closed not initiated
Figure 12: LURK client State Diagram
The TLS client needs to interact with the CS when either the TLS
client proposes PKSs and the CS hosts the PSKs or when the TLS client
requests the CS to generate the (EC)DHE private key. The TLS client
requests with a c_init_client_hello exchange the CS the binder_keys,
the (EC)DHE public part as well as early secrets and is thus able to
start the TLS handshake, that is sending a ClientHello with potential
early data. In case a HeloRetryRequest is received, the TLS client
Migault Expires 27 January 2022 [Page 25]
Internet-Draft LURK/TLS 1.3 July 2021
pursue with a c_client_hello exchange to complete the second
ClientHello. Upon receiving a ServerHello as well as other messages
by the TLS server, the TLS client requests via a
c_hand_and_App_secret exchange the necessary information (signature,
secrets) to complete the TLS handshake.
When the TLS client does not propose PSKs that are protected by the
CS nor does request the CS to generate the private part of the
(EC)DHE shared secret, the TLS client does not need to interact wit
the CS to send its ClientHello. However, the TLS client may interact
with the CS to authenticate itself to the TLS server via the
generation of a signature contained in a CertificateVerify message.
Such authentication can be performed during the TLS handshake when
ECDHE is agreed and when the TLS client enables post handshake
authentication, in which case the signature is requested via a
c_init_cert_verify exchange.
Once the TLS handshake is completed, and the TLS client has enabled
post handshake authentication, the TLS server may request by sending
a CertificateRequest the TLS client to authenticate itself with a
signature. If the TLS client has already started a LURK session
associated to the TLS handshake the signature is requested via a
c_post_hand_auth exchange. Otherwise, the signature is requested via
a c_init_post_hand_auth exchange. Multiple post hand shake
authentication may be performed in both cases and additional
signature generation are requested via c_post_hand_auth exchange.
Similarly, once the TLS handshake is completed, the TLS client may
receive NewSessionTickets from the TLS server to perform session
resumption. If the TLS client has its (EC)DHE or the PSK in use
protected by the CS - the NewSessionTicket is registered via a
c_register_ticket. Multiple NewSessionTickets may be registered.
When no protected PSK have been agreed and (EC)DHE are not generated
by the CS, the TLS client may generate the PSK session resumption.
As a result, it cannot be registered in the CS as to prevent
providing a false sense of security.
7.1. c_init_post_hand_auth
The c_init_post_hand_auth occurs when the TLS client performs post
handshake authentication while no previous interactions occurred
between the TLS client and the CS. More specifically, the (EC)DHE
shared secrets have been generated by the TLS client, and the
proposed keys, if proposed previously by the TLS client, are not
protected by the CS.
The CS completes and returns the signature as described in
Section 5.10.
Migault Expires 27 January 2022 [Page 26]
Internet-Draft LURK/TLS 1.3 July 2021
Since session resumption secrets are not protected by the CS, the
registration of NewSessioinTickets is not expected, and the only
exchanges that MAY follow are additional post handshake
authentications described in Section 7.2.
struct{
uint8 tag;
select (tag.last_exchange){
case False:
uint32 session_id;
}
FreshnessFunct freshness;
Ephemeral = ephemeral ## ephemeral_method = secret_provided
Handshake handshake<0..2^32> //RFC8446 section 4
LURKTLS13Certificate cert;
SignatureScheme sig_algo;
}CInitPostHandAuthRequest
struct{
unit8 tag
select (tag.last_exchange){
case False:
uint32 session_id;
}
Signature signature
}CInitPostHandAuth
tag is defined in Section 5.8. The TLS client sets tag.last_message
if further post handshake authentications are expected. Similarly
the CS sets the tag.last_message if further post handshake
authentications are permitted. Note that it is out of scope of
this specification to specify the reasons, but it is RECOMMENEDED
the CS sets life time to LURK session as well as limits the
maximum number of post handshake authentications.
ephemeral is defined in Section 5.5 and ephemeral_method MUST be set
to 'secret_provided' when the TLS handshake agreed an ECDHE or a
PSK-ECDHE authentication. The ephemeral_method MUST be set to
'no_secret' when PSK the TLS handshake agreed on PSK
authentication.
handshake is defined in Section 5.2 and post handshake
authentication MUST be enabled by the TLS client.
cert is defined in Section 5.7 and is used by the TLS client to
Migault Expires 27 January 2022 [Page 27]
Internet-Draft LURK/TLS 1.3 July 2021
indicate the expected certificate to be used to compute the
signature as well as the certificate that is expected to be send
further to the TLS server.
sig_algo is defined in Section 5.10 and indicates the selected
algorithm.
signature is defined in Section 5.10.
7.2. c_post_hand_auth
The c_post_hand_auth exchange enables a TLS client to perform post
handshake authentication.
This exchange is followed by a c_register_ticket or a
c_post_hand_and_app exchange.
struct{
Tag tag
uint32 session_id
Ephemeral = ephemeral ## ephemeral_method = secret_provided
Handshake handshake<0..2^32> // CertificateRequest
LURKTLS13Certificate cert;
SignatureScheme sig_algo;
}CPostHandAuthRequest
struct{
Tag tag
uint32 session_id
Signature signature
}CPostHandAuth
tag, sig_algo, cert, signature are described in Section 7.1
handshake is defined in Section 5.2 and is only composed of a
CertificateRequest. However, post handshake authentication MUST
be enabled by the TLS client.
7.3. c_init_cert_verify
The c_init_cert_verify exchange occurs when the TLS client is being
requested to authenticate during the TLS handshake. According to
[RFC8446] client authentication during the TLS handshake is not valid
with a PSK or PSK based authentication. As a result, ECHDE needs to
be agreed. In addition, as c_init_cert_verify initiates a LURK
session, the ECDHE shared secrets have been generated by the TLS
client as opposed to the CS.
Migault Expires 27 January 2022 [Page 28]
Internet-Draft LURK/TLS 1.3 July 2021
The CS completes and returns the signature as described in
Section 5.10. When further LURK exchanges are expected, the CS
generates also the Finished message in order to be able to complete
the latter requests for post authentication.
This exchange is followed by a c_post_hand_auth exchange.
struct{
uint8 tag;
select (tag.last_exchange){
case False:
uint32 session_id;
}
FreshnessFunct freshness;
Ephemeral ephemeral;
Handshake handshake<0..2^32>; //RFC8446 section 4
LURKTLS13Certificate certificate;
SignatureScheme sig_algo; //RFC8446 section 4.2.3.
}CInitCertVerifyRequest
struct{
uint8 tag;
select (tag.last_exchange){
case False:
uint32 session_id;
}
Ephemeral ephemeral;
Signature signature;
}CInitCertVerifyResponse
freshness, session_id are respectively defined in Section 5.4 and
Section 5.3.
tag is defined in Section 5.8. The TLS client that does not expect
an additional post handshake authentication MUST set it
tag.last_message. A consequence is that a TLS client that does
not enable post authentication MUST set the tag.last_message.
The CS MUST set the tag.last_message when the TLS client does not
enabled post handshake authentication or when no further post
handshake authentication is expected.
ephemeral is defined in Section 5.5. The TLS client MUST set the
ephemeral_method to 'secret_provided'.
handshake is defined in Section 5.2 and must be set to ECDHE agreed.
Note that PSK may be proposed if these PSKs are not provisioned in
the CS. The handshake messages are also in clear.
Migault Expires 27 January 2022 [Page 29]
Internet-Draft LURK/TLS 1.3 July 2021
7.4. c_init_client_hello
The c_init_ephemeral_binder exchange occurs when the TLS client needs
to generate the ClientHello as well as the early secrets. In fact
the generation of the ClientHello may require the CS to generates the
(EC)DHE private key and returns the public part as well as the
binder_key to generate the binders. On the other hand, the
generation of the early secrets requires the ClientHello to be
completed. As a result, the CS will be expected to complete the
ClientHello from a potential partial ClientHello. More specifically,
when binders are needed, the partial Client Hello does not contains
the OfferedPsks structure, that is the PreSharedKeyExtension. The
latter structure is simply stripped from the ClientHello, without any
further changes, such as changing the lengths for example. It is
entirely built by the CS and append as the last extension as
described in section 4.2.11 of The reason for having CPskID as
opposed to the identity structure is that nothing prevent identities
of two different NewSessionTickets to be collide. CPskID are managed
by the CS of the TLS client to prevent such collisions and are
provided during the registration of the NewSessionTickets
c_register_tickets (see [RFC8446]. Note that extension_type as well
as the 16 bit length of the OfferedPsks remain present. The
PreSharedKeyExtension structure of the ClientHello is built from a
list of CPskIDs where each CPskID designates a PSK with an identifier
managed by the CS of the TLS client. The PSK can be associated to a
NewSessionTicket in which case the CPskID will be used to designate
the NewSessionTicket and its associate identity
structure.Section 7.7). When the PSK is provisioned, the TLS client
needs to be configured with it. When the CS is not able to generate
the PreSharedKeyExtension an invalid_identity error SHOULD be raised.
Note that when PSK is not proposed or when PSK are not registered in
the CS, the ClientHello is fully provided - without the
PreSharedKeyExtension or with a completed PreSharedKeyExtension
extension. The CS is expected to be able to distinguish between the
two by for example, comparing the length of the handshake provided in
c_init_client_hello and the length indicated in the ClientHello.
Migault Expires 27 January 2022 [Page 30]
Internet-Draft LURK/TLS 1.3 July 2021
Note that (EC)DHE may be generated when ECDHE or PSK-ECDHE
authentication is proposed by the TLS client, while early secrets and
binder_key can only be requested when PSK is proposed. When the TLS
client requests the generation of a (EC)DHE private key, the
KeyShareClietHello MAY contain a list of KeyShareEntry (defined in
section 4.2.8 When an error is found regarding the
KeyShareClientHello, the CS SHOULD raise an invalid_ephemeral error.
Note that according to [RFC8446] ). When provided, these structures
contains the group but are being stripped the key_exchange_value,
while all other fields - including the lengths - are left
unchanged.Section 5.5 when the ephemeral_method is set to
'no_secret', the resulting list is empty.
This exchange is followed by a c_client_hello or a
c_hand_and_app_secret.
struct{
uint32 c_psk_id
}CPskID
struct{
uint32 session_id
Freshness freshness
Ephemeral ephemeral ephemeral_method=secret_generate or no_secret
Handshake handshake<0..2^32> //RFC8446 section 4
CPskID c_psk_id_list<0..2^8-1>
uint16 secret_request;
}CInitClientHello
struct{
uint32 session_id
Ephemeral ephemeral_list<0..2^16-1>
Secret secret_list<0..2^16-1>;
}CInitClientHello
session_id, freshness and ephemeral, secret_request and secret_list
are respectively defined in Section 5.3, Section 5.4, Section 5.5,
Section 5.1 and Section 5.9.
ephemeral is defined in Section 5.5. With a single ClientHello or
partial ClientHello, ephemeral_method is set to secret_generate
when ECDHE and PSK-ECDHE authentication are being proposed or
no_secret when only PSK is proposed or when the ECDHE is generated
by the TLS client.
Note that even though the CLientHello requests multiple
KeyShareENtries, a single ephemeral method is provided.
Migault Expires 27 January 2022 [Page 31]
Internet-Draft LURK/TLS 1.3 July 2021
handshake is defined in Section 5.2. When a partial ClientHello is
provided, PSK or PSK-ECDHE MUST be enabled. When a ClientHello is
provided, PSK or PSK-ECDHE may be proposed but with unprotected
keys. ClientHello, HelloRetryRequest, ClientHello or ClientHello,
HelloRetryRequest, partial ClientHello MAY be provided. However,
there are cases this is not possible, typically when the
HellRequestRetry does not contain a key_share extension, the
(EC)DHE shared secret is generated with the (EC)DHE generated
associated to the first ClientHello. When the (EC)DHE private key
has been generated by the CS, the TLS client MUST use a
c_early_secret LURK exchange as defined in Section 7.5 in order to
ensure the CS is aware of the (EC)DHE shared secret to generate
the further secrets.
c_psk_id designate an 32 bit identifier for a PSK. This identifier
is provided and managed by the CS of the TLS client to avoid
collision of different PSK provided by different TLS servers.
c_psk_id_list designates the list of CPskIDs. The list is used by
the CS to build the OfferedPsks structure - including the
PSKIdentity structure. The list of identities in the OfferedPsks
MUST be the same as the one of the c_psk_id_list.
ephemeral_list When contains the different values of (EC)DHE public
parts - i.e. the KeyShareEntries when the ephemeral_method is set
to secret_generated. When the ephemeral_method is set to
no_secret, the list is an empty list by construction of the
ephemeral structure (see Section 5.5).
7.5. c_client_hello
The c_client_hello exchange occurs after a TLS server responds to a
ClientHello generated using a c_init_client_hello defined in
Section 7.4 is being responded a HelloRetryRequest by the TLS server.
While in some cases, re-initiating a LURK exchange with a
_init_client_hello MAY be considered, this document RECOMMENDS to
proceed as follows when a HelloRetryRequest is received:
* If the first ClientHello has been generated via a
c_init_client_hello, use c_client_hello to generate the second
ClientHello
* If the first ClientHello has not been generated via a
c_init_client_hello, consider generating the second ClientHello
via c_init_client_hello.
This exchange is followed by a c_hand_and_app_secret.
Migault Expires 27 January 2022 [Page 32]
Internet-Draft LURK/TLS 1.3 July 2021
struct{
uint32 session_id
Freshness freshness
Ephemeral ephemeral ephemeral_method=secret_generate or no_secret
Handshake handshake<0..2^32> //RFC8446 section 4
uint16 secret_request;
}CClientHello
struct{
uint32 session_id
Ephemeral ephemeral
Secret secret_list<0..2^16-1>;
}CClientHello
session_id, ephemeral, secret_request and secret_list are
respectively defined in Section 5.3, Section 5.5, Section 5.1 and
Section 5.9.
handshake is defined in Section 5.2. The handshake MUST contain a
HelloRetryRequest and a ClientHello or partial ClientHello. The
same restrictions as defined in Section 7.4 apply to the
ClientHello
7.6. c_hand_and_app_secret
The c_hand_and_app_secret exchange occurs after a ServerHello is
received and the TLS client request handshake secrets to decrypt
(resp. encrypt) handshake messages sent by (resp. to) the server.
Similarly the TLS client requests application secrets used to protect
the TLS session as well as other secrets such as exporter secrets.
Upon receiption of the handshake the CS derives the handshake secrets
and the server_handshake_traffic_secret as described in [RFC8446]
section 7.3 to decrypt the encrypted messages. The presence of a
CertificateRequest indicates the TLS server expects the TLS client to
authenticate via a CertificateVerify message. If the CS protects a
private key associated to the TLS client, the CS MUST provides the
necessary information to the TLS client client. Otherwise, the
CertificateRequest is ignored by the CS.
When the CS generates the signature, the presence of the certificate,
the signature and sig_algo is indicated by setting tag.cert_request.
Unlike on the TLS server, where the TLS server indicates the
certificate to chose as well as the signature scheme to select, on
the TLS client, such decision is left to the CS. The choice of the
signature algorithm and certificate is performed by the CS as
described in When resumption_master_secret is requested by the TLS
client, or when further exchanges between teh TLS client and the CS
Migault Expires 27 January 2022 [Page 33]
Internet-Draft LURK/TLS 1.3 July 2021
are expected, the CS generates the CertificateVerify and Finished
message to synchronize the TLS handshake context. The Certificate,
respectively CertificateVerify and Finished message are generated as
described in [RFC8446] section 4.4.2.3. [RFC8446] section 4.4.2,
section 4.4.3, and section 4.4.4.
This exchange is followed by a c_post_hand_auth, c_register_ticket
exchange.
struct{
uint8 tag;
uint32 session_id;
Ephemeral ephemeral;
Handshake handshake<0..2^32>; //RFC8446 section 4
uint16 secret_request;
}CHandAndAppSecretRequest
struct{
uint8 tag;
uint32 session_id;
Secret secret_list<0..2^16-1>;
select( tag.cert_request){
case true:
LURKTLS13Certificate certificate;
SignatureScheme sig_algo;
Signature signature;
}
}CHandAndAppSecretRequest
session_id, secret_request certificate signature, and secret_list are
respectively described in Section 5.3, Section 5.1, Section 5.7,
Section 5.10 and Section 5.9
tag is defined in Section 5.8 and indicates whether the further
exchanges are expected or not. If the TLS client or the TLS
server do not expect to perform session resumption or have not
enabled post handshake authentication the tag.last_message SHOULD
be set.
ephemeral is defined in Section 5.5. Since ClientHello as already
been sent, the purpose of the ephemeral is to provid ethe (EC)DHE
shared secret to perform the key schedule and ephemeral_method
MUST NOT be set to secret_generated.
handshake is defined in Section 5.2 and includes the ServerHello up
to the server Finished. These messages are passed to the CS
encrypted.
Migault Expires 27 January 2022 [Page 34]
Internet-Draft LURK/TLS 1.3 July 2021
sig_algo is defined in Section 5.10 and defines the algorithm chosen
by the CS.
7.7. c_register_tickets
The c_register_ticket is only used when the TLS client intend to
perform session resumption. The LURK client MAY provide one or
multiple NewSessionTickets. These tickets will be helpful for the
session resumption to bind the PSK value to some identities. As teh
NewSessionTicket's identities may collide when being provided by
multiple TLS servers, the CS provides identities it manages to
prevent such collisions (CPskID). One such CPskID is assigned to
each ticket and is later used to designate that ticket (see
Section 7.4). When too many tickets are provided, the CS SHOULD
raise a too_many_identities error.
struct {
uint8 tag
uint32 session_id
NewSessionTicket ticket_list<0..2^16-1>; //RFC8446 section 4.6.1.
} RegisterTicketsRequest;
struct {
uint8 tag
uint32 session_id
CPskID c_spk_id_list<0..2^8-1>
} RegisterTicketsResponse;
8. Security Considerations
Security credentials as per say are the private key used to sign the
CertificateVerify when ECDHE authentication is performed as well as
the PSK when PSK or PSK-ECDHE authentication is used.
The protection of these credentials means that someone gaining access
to the CS MUST NOT be able to use that access from anything else than
the authentication of an TLS being established. In other way, it
MUST NOT leverage this for: * any operations outside the scope of TLS
session establishment. * any operations on past established TLS
sessions * any operations on future TLS sessions * any operations on
establishing TLS sessions by another LURK client.
The CS outputs are limited to secrets as well as NewSessionTickets.
The design of TLS 1.3 make these output of limited use outside the
scope of TLS 1.3. Signature are signing data specific to TLS 1.3
that makes the signature facility of limited interest outside the
scope of TLS 1.3. NewSessionTicket are only useful in a context of
TLS 1.3 authentication.
Migault Expires 27 January 2022 [Page 35]
Internet-Draft LURK/TLS 1.3 July 2021
ECDHE and PSK-ECDHE provides perfect forward secrecy which prevents
past session to be decrypted as long as the secret keys that
generated teh ECDHE share secret are deleted after every TLS
handshake. PSK authentication does not provide perfect forward
secrecy and authentication relies on the PSK remaining sercet. The
Cryptographic Service does not reveal the PSK and instead limits its
disclosure to secrets that are generated from the PSK and hard to be
reversed.
Future session may be impacted if an attacker is able to authenticate
a future session based on what it learns from a current session.
ECDHE authentication relies on cryptographic signature and an ongoing
TLS handshake. The robustness of the signature depends on the
signature scheme and the unpredictability of the TLS Handshake. PSK
authentication relies on not revealing the PSK. The CS does not
reveal the PSK. TLS 1.3 has been designed so secrets generated do
not disclose the PSK as a result, secrets provided by the
Cryptographic do not reveal the PSK. NewSessionTicket reveals the
identity (ticket) of a PSK. NewSessionTickets.ticket are expected to
be public data. It value is bound to the knowledge of the PSK. The
Cryptographic does not output any material that could help generate a
PSK - the PSK itself or the resumption_master_secret. In addition,
the Cryptographic only generates NewSessionTickets for the LURK
client that initiates the key schedule with CS with a specific way to
generate ctx_id. This prevents the leak of NewSessionTickets to an
attacker gaining access to a given CS.
If an the attacker get the NewSessionTicket, as well as access to the
CS of the TLS client it will be possible to proceed to the
establishment of a TLS session based on the PSK. In this case, the
CS cannot make the distinction between the legitimate TLS client and
teh attacker. This corresponds to the case where the TLS client is
corrupted.
Note that when access to the CS on the TLS server side, a similar
attack may be performed. However the limitation to a single re-use
of the NewSessionTicket prevents the TLS server to proceed to the
authentication.
Attacks related to other TLS sessions are hard by design of TLS 1.3
that ensure a close binding between the TLS Handshake and the
generated secrets. In addition communications between the LURK
client and the CS cannot be derived from an observed TLS handshake
(freshness function). This makes attacks on other TLS sessions
unlikely.
9. IANA Considerations
Migault Expires 27 January 2022 [Page 36]
Internet-Draft LURK/TLS 1.3 July 2021
10. Acknowledgments
11. References
11.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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension", RFC 7924,
DOI 10.17487/RFC7924, July 2016,
<https://www.rfc-editor.org/info/rfc7924>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
11.2. Informative References
[I-D.mglt-lurk-lurk]
Migault, D., "LURK Protocol version 1", Work in Progress,
Internet-Draft, draft-mglt-lurk-lurk-00, 9 February 2018,
<https://www.ietf.org/archive/id/draft-mglt-lurk-lurk-
00.txt>.
[I-D.mglt-lurk-tls12]
Migault, D. and I. Boureanu, "LURK Extension version 1 for
(D)TLS 1.2 Authentication", Work in Progress, Internet-
Draft, draft-mglt-lurk-tls12-04, 25 January 2021,
<https://www.ietf.org/internet-drafts/draft-mglt-lurk-
tls12-04.txt>.
Appendix A. Annex
A.1. TLS server ECDHE (no session resumption)
This section illustrates the most common exchange of a TLS client
authenticates a TLS server with it certificate (ECDHE) without
session resumption.
Migault Expires 27 January 2022 [Page 37]
Internet-Draft LURK/TLS 1.3 July 2021
The TLS handshake is depicted below from {!RFC8446}}. For clarity as
ECDHE authentication is performed, PSK related extensions (
psk_key_exchange_modes, pre_shared_key ) have been omitted. In
addition, as the TLS client is not authenticated, CertificateRequest
sent by the TLS server as well as Certificate and CertificateVerify
sent by the TLS client have been removed.
TLS client TLS Server
Key ^ ClientHello
Exch | + key_share
v + signature_algorithms --------->
ServerHello ^ Key
+ key_share v Exch
{EncryptedExtensions} Server Params
{Certificate} ^
{CertificateVerify} | Auth
{Finished} v
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
The TLS server interacts with the CS with a s_init_cert_verify
exchange in order to respond to the ClientHello.
Since there is no session resumption, the request indicates with the
tag set to last_exchange that no subsequent messages are expected.
As a result, no session_id is provided. The freshness function is
set to sha256, the handshake is constituted with the appropriated
messages with a modified server_random to provide PFS. The
Certificate message is also omitted from the handshake and is instead
provided in the certificate structure using a finger_print. The
requested secrets are handshake and application secrets, that is h_s,
h_c, a_s, and a_c. The signature scheme is ed25519. With
authentication based on certificates, there are two ways to generate
the shared secrets that is used as an input to the derive the
secrets. The ECDHE private key and shared secret may be generated by
the CS as described in {sec:ex:srv:cs_generated}. On the other hand
the ECDHE private key and shared secret may be generated by the TLS
server as described in {tls_server_generated}
Migault Expires 27 January 2022 [Page 38]
Internet-Draft LURK/TLS 1.3 July 2021
A.1.1. ecdhe generated on the CS
When the (EC)DHE private key and shared secrets are generated by the
CS, the LURK client set the ephemeral_method to secret_generated.
The (EC)DHE group x25519 is specified in the handshake in the
key_share extension. In return the CS provides the LURK client the
public key so the TLS server can send the ServerHello to the TLS
client.
In this scenario, the CS is the only entity that knows the private
ECDHE key and the shared secret, and only the CS is able to compute
the secrets. The CS indicates the exchange is final by setting the
tag to last_message, returns the x25519 public key that will be
included in the ServerHello key_share extension, the signature sig
that will be returned in the CertificateVerify message as well as the
secrets that will be used to derive the appropriated keys.
TLS server
LURK client Cryptographic Service
SInitCertVerifyRequest
tag=last_exchange -------->
freshness = sha256
ephemeral
ephemeral_method = secret_generated
handshake = handshake (x25519)
certificate = finger_print
secret_request = h_s, h_c, a_s, and a_c
sig_algo = ed25519
SInitCertVerifyResponse
tag=last_exchange
ephemeral
key
group = x25519,
key_exchange = public_key
secret_list
signature = sig
<---------
A.1.2. ecdhe generated by the TLS server
When the (EC)DHE private keys and the shared secrets are generated by
the TLS server, the LURK client provides the shared secret to the CS
as only the shared secret is necessary to generated the signature.
This is indicated by the ephemeral_method set to secret_provided. No
(EC)DHE values are returned by the CS as these have already been
generated by the TLS server. However, the TLS server has all the
necessary material to generate the secrets and the only information
that the CS owns and that is not known to et TLS server is the
Migault Expires 27 January 2022 [Page 39]
Internet-Draft LURK/TLS 1.3 July 2021
private key (associated to the certificate) used to generate the
signature. This means that is session resumption were allowed, since
it is based on PSK authentication derived from the resumption secret,
these sessions could be authenticated by the TLS server without any
implication from the CS.
In this scenario, the CS is the only entity that knows the private
ECDHE key. Only the CS is able to generate the signature. Both the
CS and the TLS server are able to compute all secrets. The CS
indicates the exchange is final by setting the tag to last_message,
returns the signature sig that will be returned in the
CertificateVerify message as well as - when requested - the secrets
that will be used to derive the appropriated keys.
TLS server
LURK client Cryptographic Service
SInitCertVerifyRequest
tag.last_exchange=True -------->
freshness = sha256
ephemeral
ephemeral_method = secret_provided
key
group = x25519
shared_secret = shared_secret
handshake = handshake
certificate = finger_print
secret_request = h_s, h_c, a_s, and a_c
sig_algo = ed25519
SInitCertVerifyResponse
tag.last_exchange=True
secret_list
signature = sig
<---------
A.2. TLS server ECDHE ( with session resumption )
When the TLS client is enabling session resumption, the TLS server is
expected to generate some tickets that will be later used for later
sessions. The generation of the tickets is based on the
resumption_master_secret. To ensure protection of the authentication
credential used for the session resumption, the CS necessarily must
have generated the (EC)DHE keys and must not have provided the
resumption_master_secret. In either other cases, the TLS client is
able to compute the resumption_master_secret and so session
resumption is out of control of the CS. As a result, the CS sort of
achieves a delegation to the TLS server.
Migault Expires 27 January 2022 [Page 40]
Internet-Draft LURK/TLS 1.3 July 2021
In the remaining of this section, we consider the session resumption
is performed by the CS.
ECDHE authentication is performed with the CS generating the private
part of the (EC)DHE as described in {sec:ex:srv:cs_generated}.
However, additional s_new_ticket exchanges are needed so the TLS
server provides sufficient material to generate the tickets by the CS
and retrieves the generated tickets by the CS. As result, the main
difference with the scenario described in {sec:ex:srv:cs_generated}
is that tag carries a session_id to identify the session between the
TLS server and the CS.
TLS server
LURK client Cryptographic Service
SInitCertVerifyRequest
tag.last_exchange=False
session_id = session_id_tls_server -------->
freshness = sha256
ephemeral
ephemeral_method = secret_generated
handshake = handshake (x25519)
certificate = finger_print
secret_request = h_s, h_c, a_s, a_c
sig_algo = ed25519
SInitCertVerifyResponse
tag.last_exchange=False
session_id = session_id_cs
ephemeral
key
group = x25519,
key_exchange = public_key
secret_list
signature = sig
<---------
To enable session resumption, the TLS server needs to send
NewSessionTickets to the TLS client. This exchange is taken from
[RFC8446] and represented below: ~~~ TLS client TLS Server <-----
[NewSessionTicket] ~~~
The TLS server requests NewSessionTicket to the CS by sending a
SNewTicketRequest. The tag.last_exchange set to False indicates to
the CS the TLS server is willing to request NewSessionTickets
multiple times. The session_id is set to the value provided
previously by the CS. This session_id will be used to associate the
SNewTicketRequest to the specific context of teh TLS handshake.
handshake is the remaining handshake necessary to generate the
secrets. In some cases, when the TLS client is authenticated, the
Migault Expires 27 January 2022 [Page 41]
Internet-Draft LURK/TLS 1.3 July 2021
TLS handshake contains a Certificate message that is carried in the
certificate structure as opposed as to the handshake structure. In
our current case, the TLS client is not authenticated, so the
certificate_type is set to 'empty'. ticket_nbr is an indication of
the number of requested NewSessionTicket, and secret_list indicates
the requested secrets. In our case the resumption_master_secret (r)
will remain in the CS and will be anyway ignored by the CS, so the
secret_request has its r bit unset.
As depicted below, the CS provides a list of tickets that could be
later used in order to authenticate the TLS server using PSK or PSK-
ECDHE authentication as describe din {sec:ex:srv:server-psk}.
TLS server
LURK client Cryptographic Service
SNewTicketRequest
tag.last_exchange=False
session_id = session_id_cs
handshake = client Finished
certificate
certificate_type = empty
ticket_nbr
secret_request -------->
SNewTicketResponse
tag.last_exchange=False
session_id = session_id_tls_server
secret_list
<--------- ticket_list
A.3. TLS server PSK / PSK-ECDHE
PSK/PSK-ECDHE authentication is the method used for session
resumption but can also be used outside the scope of session
resumption. In both cases, the PSK is hosted by the CS.
The PSK authentication can be illustrated by the exchange below:
TLS client TLS Server
ClientHello
+ key_share
+ psk_key_exchange_mode
+ pre_shared_key -------->
ServerHello
+ pre_shared_key
+ key_share
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
Migault Expires 27 January 2022 [Page 42]
Internet-Draft LURK/TLS 1.3 July 2021
The TLS client may propose to the TLS server multiple PSKs.
Each of these PSKs is associated a PskBindersEntry defined in
[RFC8446] section 4.2.11.2. PskBindersEntry is computed similarly to
the Finished message using the binder_key and the partial
ClientHello. The TLS server is expected to pick a single PSK and
validate the binder. In case the binder does not validate the TLS
Handshake is aborted. As a result, only one binder_key is expected
to be requested by the TLS server as opposed to the TLS client. In
this example we assume the psk_key_exchange_mode indicated by the TLS
client supports PSK-ECDHE as well as PSK authentication. The
presence of a pre_shared_key and a key_share extension in the
ServerHello indicates that PSK-ECDHE has been selected.
While the TLS handshake is performed in one round trip, the TLS
server and the CS have 2 LURK exchanges. These exchanges are
consecutive and performed in the scope of a LURK session. A first
exchange (s_init_early_secret) validates the ClientHello receives by
the TLS server and existence of the selected PSK (by the TLS server)
is actually hosted by the CS. Once the s_init_early_secret exchange
succeeds, the TLS server starts building the ServerHello and requests
the necessary parameters derived by the CS to complete the
ServerHello with a second exchange (s_init_hand_and_apps).
The TLS server is expected to select a PSK, check the associated
binder and proceed further. If the binder fails, it is not expected
to proceed to another PSK, as a result, the TLS server is expected to
initiates a single LURK session.
The SInitEarlySecretRequest structure provides the session_id that
will be used later by the TLS server to identify the session with
future inbound responses from the CS (session_id_server). The
freshness function (sha256) is used to implement PFS together with
the ClientHello.random. selected_identity indicates the PSK chosen
by the TLS server among those proposed by the TLS client in its
ClientHello. The secrets requested by the TLS server are indicated
in secret_request. This example shows only the binder_key, but other
early secrets may be requests as well.
The CS responds with a SInitEarlySecretResponse that contains the
session_id_cs used later to identify the incoming packets associated
to the LURK session and the binder_key.
Migault Expires 27 January 2022 [Page 43]
Internet-Draft LURK/TLS 1.3 July 2021
TLS server
LURK client Cryptographic Service
SInitEarlySecretRequest ---------->
session_id = session_id_tls_server
freshness = sha256
selected_identity = 0
handshake = ClientHello
secret_request = b
SInitEarlySecretResponse
session_id = session_id_cs
<--------- secret_list = binder_key
To complete to the ServerHello exchange, the TLS server needs the
handshake and application secrets. These secrets are requested via
an s_hand_and_app_secret LURK exchange.
The SHandAndAppSecretRequest structure carries a tag with its
last_exchange set to False to indicate the willingness of the TLS
server to keep the session open and proceed to further LURK
exchanges. In our case, this could mean the TLS server expects to
request additional tickets. The session_id is set to session_id_cs,
the value provided by the CS. ephemeral is in our case set the
ephemeral_method to secret_generated as described in Appendix A.1.
The method (x25519) to generate the (EC)DHE is indicated in the
handshake. The necessary handshake to derive the handshake and
application secrets, as well the requested secrets are indicated in
the secret_request structure.
The CS sets its tag.last_exchange to True to indicate the session
will be closed after this exchange. This also means that no ticket
will be provided by the CS. The CS returns the (EC)DHE public key as
well as requested secrets in a SHandAndAppResponse structure
similarly to what is being described in {sec:ex:srv:ecdhe}.
Migault Expires 27 January 2022 [Page 44]
Internet-Draft LURK/TLS 1.3 July 2021
TLS server
LURK client Cryptographic Service
SHandshakeAndAppRequest
tag.last_exchange = False
session_id = session_id_cs
ephemeral
ephemeral_method = secret_generated
handshake = ServerHello(x25519) ... EncryptedExtensions
secret_request = h_c, h_s, a_c, a_s ------->
SHandAndAppResponse
tag.last_exchange = True
session_id = session_id_tls_server
ephemeral
key
group = x25519,
key_exchange = public_key
<--------- secret_list
A.4. TLS client unauthenticated ECDHE
This section details the case where a TLS client establishes a TLS
session authenticating the TLS server using ECDHE. The TLS client
interacts with the CS in order to generate the (EC)DHE private part.
While this section does not illustrates session resumption, the TLS
client is configured to proceed to session resumption which will be
described with further details in Appendix A.5.
The TLS handshake described in [RFC8446] is depicted below. In this
example, the TLS client proposes a key_share extension to agree on a
(EC)DHE shared secret, but does not propose any PSK.
TLS client TLS Server
Key ^ ClientHello
Exch | + key_share
v + signature_algorithms --------->
ServerHello ^ Key
+ key_share v Exch
{EncryptedExtensions} Server Params
{Certificate} ^
{CertificateVerify} | Auth
{Finished} v
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Migault Expires 27 January 2022 [Page 45]
Internet-Draft LURK/TLS 1.3 July 2021
If the TLS client generates the (EC)DHE private key, no interaction
with the CS is needed as it will have the default PSK value as well
as the (EC)DHE shared secrets necessary to proceed to the key
schedule described in section 7.1 of [RFC8446].
In this example, the TLS client requests the CS via a
c_init_client_hello to generate the (EC)DHE private key and provide
back the public part that will be placed into the key_share extension
before being sent to the TLS server.
Like in any init methods, the TLS client indicates with
session_id_tls_client the idnetifier of the session that is being
assigned by the TLS client for future inbound LURK message responses
sent by the CS. Similarly, the CS advertises its session_id_cs.
freshness is set to sha256, and the ClientHello.random is generated
as described in Section 5.4. handshake contains the ClientHello
message to which the key_exchange of the KeyShareentries has been
stripped off without changing the other fields. As PSK are not
involved, no early secrets are involved and c_psk_list and
secret_request are empty.
The CS provides the KeyShareEntries. The TLS client is able to build
the ClientHello to the TLS server with ClientHello.random and by
placing the KeyShareEntries.
TLS client
LURK client Cryptographic Service
CInitClientHello
session_id = session_id_tls_client
freshness = sha256
ephemeral
ephemeral_method = secret_generated
handshake = ClientHello(x25519, x488, ... )
c_psk_id_list = []
secret_request = [] ------>
CInitClientHello
session_id=session_id_cs
ephemeral_list
key
group = x25519,
key_exchange = public_key
ephemeral_method = secret_generated
key
group = x488,
key_exchange = public_key
secret_list=[]
Migault Expires 27 January 2022 [Page 46]
Internet-Draft LURK/TLS 1.3 July 2021
Upon receiving the response from the TLS server, responds with a
ServerHello followed by additional encrypted messages.
The TLS client needs the handshake secrets to decrypt these encrypted
messages and send back the client Finished message. In addition, the
TLS client requests the application secrets to encrypt and decrypt
the TLS session. The secrets are requested via a
c_hand_and_app_secret.
We assume the TLS client supports session resumption so, the
tag.last_message is unset. The session_id takes the value advertises
by each party during the previous c_init_client_hello exchange.
Since the CS already has the (EC)DHE private keys, it will be able to
derive the (EC)DHE shared secret and no information needs to be
provided by the TLS client. As a result, ephemeral_method is set to
no_secret. The handshake is composed of the messages sent by the TLS
server. As the TLS client does not have yet the messages are not
decrypted, and are provided encrypted. The requested secrets are the
handshake and application secrets.
The CS generates the handshake secrets and the associated key to
decrypt the encrypted messages. As no CertificateRequest has been
found, the CS does not compute the signature that would authenticate
the TLS client. In this section, we assume the CS is ready to accept
further exchanges, and in our case the c_register_tickets exchange to
enable session resumption. Since session resumption is enabled, the
CS computes the Finished message to generate the
resumption_master_secret.
The CS returns the response by unsetting the tag.last_message and
cert_request. The ephemeral is an empty list and secret_request
returns the requested secrets.
Migault Expires 27 January 2022 [Page 47]
Internet-Draft LURK/TLS 1.3 July 2021
TLS client
LURK client Cryptographic Service
CHandAndAppSecretRequest
tag.last_message=False
session_id=session_id_cs
ephemeral
ephemeral_method = no_secret
handshake = ServerHello, {EncryptedExtensions}...,{Finished}.
secret_request = h_c, h_s, a_c, a_s ------->
CHandAndAppSecretResponse
tag
last_message=False
cert_request=False
session_id=session_id_tls_clt
ephemeral_list = []
secret_request = h_s, h_c, a_s, and a_c
Upon reception of the response, the TLS client generates the
necessary keys to decrypt and encrypt the handshake message and
terminates the TLS handshake. The TLS client is also able to decrypt
and encrypt application traffic.
In this section, we assume that after some time, the TLS client
receives a NewSessionTicket from the TLS server. The TLS client will
then transmit the NewSessionTicket to the CS so that it can generate
the associated PSK that will be used for the authentication.
As multiple NewSessionTickets may be sent, in this example, both TLS
client and CS enable further additional registrations by unsetting
tag.last_message. For each registered NewSessionTicket, the CS
returns c_spk_id that will use for further references. The c_spk_ids
are managed by the CS which can ensure the uniqueness of these
references as opposed to using the ticket field that is assigned by
the TLS server.
Appendix A.5 illustrates how session resumption is performed using
PSK / PSK-ECDHE authentication.
Migault Expires 27 January 2022 [Page 48]
Internet-Draft LURK/TLS 1.3 July 2021
TLS client
LURK client Cryptographic Service
RegisterTicketsRequest
tag.last_message=False
session_id=session_id_cs
ticket_list = [NewSessionTicket]
---------------->
RegisterTicketsResponse
last_message=False
session_id=session_id_tls_clt
<-------- c_spk_id_list = [nst_id]
A.5. TLS client unauthenticated PSK / PSK-ECDHE
This section describes the intercation between a TLS client and a CS
for a PSK-ECDHE TLS handshake. Appendix A.4 shows how the PSK may be
provisioned during a ECDHE TLS handshake. The scenario described in
this section presents a number of similarities to the one described
in Appendix A.4. As such, we expect the reader to be familiar with
Appendix A.4 and will highlight the differences with Appendix A.4 to
avoid to repeat the description.
In this section, the PSK is protected by the CS, but the (EC)DHE
private keys are generated by the TLS client and as such are
considered as unprotected. As the (EC)DHE secret are generated by
the TLS client, the ephemeral_method is set to no_secret, and the
key_share extension is fully provided in the ClientHello. However,
the ClientHello do not carry the PreSharedKeyExtension. Instead,
this extension is built from the NewSessionTicket identifier nst_id
provided in our case from a previous c_register_ticktes exchange (see
Appendix A.4 }. The TLS client requests the binder_key associated to
nst_id in order to be able to complete the binders.
Upon receiving the message, the CS, computes the binder_keys,
complete the ClientHello in order to synchronize its TLS handshake
with the TLS client (and the TLS server). As the CS does not
generate any (EC)DHE, the ephemeral_list is empty.
Migault Expires 27 January 2022 [Page 49]
Internet-Draft LURK/TLS 1.3 July 2021
TLS client
LURK client Cryptographic Service
CInitClientHello
session_id = session_id_tls_client
freshness = sha256
ephemeral
ephemeral_method = no_secret
handshake = ClientHello without PreSharedKeyExtension
c_psk_id_list = [nst_id]
secret_request = [b] ------>
CInitClientHello
session_id=session_id_cs
ephemeral_list = []
secret_list=[binder_key]
When the TLS client receives the responses from the TLS server, the
handshake and application secrets are requested with a c_hand_and_app
similarly to Appendix A.4. The only difference here is that (EC)DHE
have been generated by the TLS client and the shared secret needs to
be provided to the CS as described below:
TLS client
LURK client Cryptographic Service
CHandAndAppSecretRequest
tag.last_message=False
session_id=session_id_cs
ephemeral
ephemeral_method = secret_provided
shared_secret
handshake = ServerHello, {EncryptedExtensions}...,{Finished}.
secret_request = h_c, h_s, a_c, a_s ------->
CHandAndAppSecretResponse
tag
last_message=False
cert_request=False
session_id=session_id_tls_clt
ephemeral_list = []
secret_request = h_s, h_c, a_s, and a_c
Upon receiving the response, the TLS client proceeds similarly to the
TLS client described in Appendix A.4.
A.6. TLS client authenticated ECDHE
This section provides scenarios when the TLS client is authenticated
during the TLS handshake. Post handshake authentication is detailed
in Appendix A.7
Migault Expires 27 January 2022 [Page 50]
Internet-Draft LURK/TLS 1.3 July 2021
A.6.1. (EC)DHE or Proposed PSK protected by the CS
When the (EC)DHE part have been generated by the CS, or the proposed
PSK are protected by the CS, the TLS client sends a ClientHello after
a c_client_hello exchange with the CS (see Appendix A.5 or
Appendix A.4). The request for TLS client authentication is
indicated by a encrypted CertificateRequest sent by the TLS server as
indicated below:
TLS client TLS Server
Key ^ ClientHello
Exch | + key_share
v + signature_algorithms --------->
ServerHello ^ Key
+ key_share v Exch
{EncryptedExtensions} ^ Server Params
{CertificateRequest} v
{Certificate} ^
{CertificateVerify} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate}
Auth | {CertificateVErify}
v {Finished} -------->
[Application Data] <-------> [Application Data]
The TLS client is unaware of the presence of the CertifcateRequest
until it has decrypted the message with a key derived from the
handshake secrets. As a result, the TLS client initiates a
c_hand_an_app_secret exchange as described in Appendix A.5 or
Appendix A.4.
The CS proceeds as described in Appendix A.5 or Appendix A.4.
However, after the messages have been decrypted, the CS proceeds to
the generation of the signature and returns the necessary information
to build the CertificateVerify. The CS indicates their presence by
setting tag.cert_request and returns the certificate, the sig_algo
and sig as described below:
Migault Expires 27 January 2022 [Page 51]
Internet-Draft LURK/TLS 1.3 July 2021
TLS client
LURK client Cryptographic Service
CHandAndAppSecretRequest
tag.last_message=False
session_id=session_id_cs
ephemeral
ephemeral_method = secret_provided
shared_secret
handshake = ServerHello, {EncryptedExtensions}...,{Finished}.
secret_request = h_c, h_s, a_c, a_s ------->
CHandAndAppSecretResponse
tag
last_message=False
cert_request=True
session_id=session_id_tls_clt
ephemeral_list = []
secret_request = h_s, h_c, a_s, and a_c
certificate
certificate_type = finger_print
sig_algo = ed25519
sig
Note that in the example above, (EC)DHE have not been generated by
the CS, but the c_client_hello was motivated to propose a protected
PSK. As the PSK has not been agreed for authentication by the TLS
server, the TLS session does not provide PFS and the protection is
similar as the one described in {sec:ex:clt:auth:ecdhe-certverify},
where the TLS client would have proposed directly ECDHE with (EC)DHE
generated by the TLS client.
A.6.2. (EC)DHE provided by the TLS client
This section considers a TLS client that proposes to authenticate the
TLS server using ECDHE with (EC)DHE private parts being generated by
the TLS client.
Migault Expires 27 January 2022 [Page 52]
Internet-Draft LURK/TLS 1.3 July 2021
The TLS client does not need to interact with CS to build its
ClientHello. Similarly, as the (EC)DHE private part have been
generated by the TLS client, the TLS client is able to perform the
key schedule and derive the necessary keys to decrypt the encrypted
response from the TLS server. Upon receiving a CertificateRequest,
the TLS client requests the CS to generate the signature needed to
send the CertificateVerify. The exchange is very similar as the one
s_init_cert_verify (see Appendix A.1.2). As the (EC)DHE shared
secret is generated by the TLS client, the ephemeral_method is
necessarily set to secret_provided. The handshake is set to the
ClientHello ... server Finished, and the certificate carries the
reference to the TLS client certificate, so the CS picks the
appropriated private key. sig_algo designates the signature
algorithm.
TLS server
LURK client Cryptographic Service
CInitCertVerifyRequest
tag.last_exchange=True -------->
freshness = sha256
ephemeral
ephemeral_method = secret_provided
key
group = x25519
shared_secret = shared_secret
handshake = hanshake
certificate
certificate_type = finger_print
sig_algo = ed25519
CInitCertVerifyResponse
tag.last_exchange=True
signature = sig
<---------
A.7. TLS client authenticated - post handshake authentication
Post handshake authentication may be requested at any time after the
TLS handshake is completed as long as the TLS client has indicated
its support with a post_handshake_authentication extension.
If the establishment of the TLS session did not required any
interactions with the CS, post handshake authentication is performed
with a c_init_post_hand_auth exchange as described in Appendix A.7.1.
When the TLS handshake already required some interactions with the CS
the post handshake authentication is performed using a
c_post_hand_auth described in {sec:ex:clt:auth:post_continued}.
Migault Expires 27 January 2022 [Page 53]
Internet-Draft LURK/TLS 1.3 July 2021
In some cases, both c_init_post_hand_auth and c_post_hand_auth can be
used. When this is possible, c_post_hand_auth is preferred as the
handshake context is already being provisioned in the CS. On the
other hand, when the shared secret is only known to the CS,
c_init_post_hand_auth cannot be used instead.
A.7.1. Initial Post Handshake Authentication
This situation describes the case where the TLS client has performed
the TLS handshake without interacting with the CS. As a result, if
involved PSK, (EC)DHE shared secrets are unprotected and hosted by
the TLS client. Upon receiving a CertificateRequest, the TLS client
sends session_id and freshness to initiate the LURK session.
tag.last_message is set in order to accept future post handshake
authentication request. ephemeral_method is set to secret_provide as
the CS is unable to generate the (EC)DHE shared secret. handshake is
set to the full handshake including the just received
CertificateRequest message. The certificate represents the TLS
client certificate to determine the private key involved in computing
the signature. sig_algo specifies the signature algorithm.
TLS server
LURK client Cryptographic Service
CInitPostHandAuthRequest
tag.last_message = False
session_id = session_id_tls_client
freshness = sha256
ephemeral
ephemeral_method = secret_provided
handshake = ClientHello ... client Finished CertificateRequest
certificate
certificate_type = finger_print
sig_algo ---------------->
CInitPostHandAuthResponse
tag.last_message = False
session_id = session_id_cs
<-------------- signature = sig
A.7.2. Post Handshake Authentication
In this scenario, the post authentication is performed while a LURK
session has already been set. Upon receiving the CertificateRequest,
the TLS client proceeds similarly to the initial post handshake
authentication as described in As a result, the exchange is
illustrated below:Appendix A.7.1 except that the LURK session does
not need to be initiated, the shared secret is already known to the
CS and the handshake is only constituted of the remaining
CertificateRequest message.
Migault Expires 27 January 2022 [Page 54]
Internet-Draft LURK/TLS 1.3 July 2021
TLS server
LURK client Cryptographic Service
CInitPostHandAuthRequest
tag.last_message = False
session_id = session_id_tls_client
handshake = CertificateRequest
certificate
certificate_type = finger_print
sig_algo ---------------->
CInitPostHandAuthResponse
tag.last_message = False
session_id = session_id_cs
<-------------- signature = sig
Author's Address
Daniel Migault
Ericsson
8275 Trans Canada Route
Saint Laurent, QC 4S 0B6
Canada
Email: daniel.migault@ericsson.com
Migault Expires 27 January 2022 [Page 55]