| LURK | D. Migault |
| Internet-Draft | Ericsson |
| Intended status: Standards Track | July 02, 2018 |
| Expires: January 3, 2019 |
LURK Extension version 1 for (D)TLS 1.3 Authentication
draft-mglt-lurk-tls13-00
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.
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 January 3, 2019.
Copyright (c) 2018 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.
This document defines a LURK extension for TLS 1.3. This document assume s the reader is familiar with [I-D.mglt-lurk-lurk] that describes the LURK architecture as well as the LURK Protocol and the integration of the LURK extensions. The motivations for the LURK Extension TLS 1.3 are similar to those for the LURK extension of TLS 1.2 [I-D.mglt-lurk-tls12].
LURK defines an interface to a Cryptographic Service that stores the security credentials - Typically the PSKs and private keys. Interactions with the Cryptographic Service can be performed by the TLS Client as well as by the TLS Server.
The TLS Server expects from the Cryptographic Service:
The TLS Client expetcs from the Cryptographic Service:
Note that the TLS Server MAY interact with a single exchange with the Cryptographic Service, the TLS Client is expected to retrieve the [sender]_handshake_traffic_secret to generate the keys encrypt the handshake extensions and messages to decrypt the messages/extensions received from the TLS Server, prior to request for the generation of the CertificateVerify or Finished message.
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), rsa_master (2),
rsa_extended_master (3), ecdhe (4), (255)
}TLS13Type;
enum {
// generic values reserved or aligned with the
// LURK Protocol
request (0), success (1), undefined_error (2),
invalid_payload_format (3),
//code points for ecdhe authentication
invalid_ec_type (9), invalid_ec_curve (10),
invalid_poo_prf (11), invalid_poo (12), (255)
}TLS13Status
struct {
Designation designation = "tls12";
int8 version = 1;
} Extension;
struct {
Extension extension;
select( Extension ){
case ("tls13", 1):
TLS12Type;
} type;
select( Extension ){
case ("tls13", 1):
TLS13Status;
} status;
uint64 id;
unint32 length;
} LURKHeader;
This exchange is only expected to be performed by a TLS Client. The server_handshake_key is necessary for the TLS Client to decrypt the handshake message/extensions encrypted by the TLS Server.
Interaction with a Cryptographic Service MAY be required when the PSK is protected by the Cryptographic Service.
enum { sha256 (0), (255) } TranscriptHash;
enum { psk_raw (0), psk_ticket (1), (255) } PSKType
struct {
PSKType psk_type;
select( psk_type ){
case raw_psk :
opaque raw_psk<0..2^16-1>;
case identity_psk :
OfferedPsks offered_psk // {{I-D.ietf-tls-tls13}} section 4.2.11
} PSK
struct {
select ( ke_mode ){ // {{I-D.ietf-tls-tls13}} section 4.2.9
case psk_ke :
PSK psk
case psk_dhe_ke :
PSK psk
NamedGroup dh_group; // {{I-D.ietf-tls-tls13}} section 4.2.7
opaque dhe_secret<1..2^16-1>;
}
} KeyScheduleInputSecrets
enum {
sha256 (0) (255)
} PFSAlgorithm
struct {
PFSAlgorithm pfs; // {{I-D.mglt-lurk-tls12}} section 4.1
TranscriptHash h;
PskKeyExchangeMode ke_mode // {{I-D.ietf-tls-tls13}} section 4.2.9
opaque handshake_context<0..2^32-1>
KeyScheduleInputSecrets secrets
} HandshakeServerKeyRequest
struct {
opaque server_handshake_key<0..2^32-1>
} HandshakeServerKeyResponse
The TLS Client establishing a TLS session with a TLS Server receives from the TLS Server a ServerHello message with additional encrypted messages such as the EncryptedExtensions, the Finished as well as the optional Certificate, CertificateVerify and Application Data message. The TLS Client needs to retrieve the server_handshake_key in order to decrypt these messages.
With ServerHello as the input message, the LURK Client initiates the exchange as described below:
Perfect Forward Secrecy Setting:
Transcript Hash Setting:
PSK Key Exchange Mode Setting:
Key Schedule Input Secret Setting:
Upon receiving a handshake_server_key request, the LURK server proceeds as follows:
Perfect Forward Secrecy Check:
Transcript-Hash Check:
Handshake Check:
PSKExchangeMode Check:
KeyScheduleInputSecret Check check the validity of the secrets as well as the coherence wit the pre shared key exchange. These checking operations are subdivided into (EC)DHE Check and PSK Check operations:
(EC)DHE Check:
PSK Check:
..* if the number of psk or associated binder is more than 1, an invalid_ticket_format error is returned ..* there is no corresponding identity, an invalid_psk_ticket error is returned. * if the psk_type is identity_psk binder_key is generated as described in [I-D.ietf-tls-tls13] section 7.1. ..* if the binder associated to the psk does not match the one provided in the offered_psk and invalid_binder error is returned. The binder is computed as described in [I-D.ietf-tls-tls13] section 4.2.11.2. with the binder_key generated as described in [I-D.ietf-tls-tls13] section 7.1.
Key Generation:
This exchange provides interactions with a Cryptographic Service both on the TLS Client side as well as the TLS Server side.
enum { server (0), client (1), post-handshake (2) } HandshakeMode;
struct {
PFSAlgorithm pfs; // {{I-D.mglt-lurk-tls12}} section 4.1
TranscriptHash h; // c, f
PskKeyExchangeMode ke_mode // {{I-D.ietf-tls-tls13}} section 4.2.9
select( ke_mode ){
case : psk_dhe_ke
Certificate certificate // {{I-D.ietf-tls-tls13}} section 4.4.2
SignatureScheme algorithm // {{I-D.ietf-tls-tls13}} section 4.2.3.
}
HandshakeMode handshake_mode // c, f
opaque handshake_context<0..2^32-1> // c, f
KeyScheduleInputSecrets secrets // f
uint8 key_request
uint8 ticket_number
} AuthRequest
c: structure used for the CertificateVerify message
f: structure used for the Finished message
pfs, h, ke_mode, handshake_context and secrets are define in Section 3.1
struct{
opaque key<0..2^16-1>
} Key
struct {
uint8 key_index
opaque key_list<0..2^32-1>
} Keys
struct {
Keys keys
CertificateVerify certificate_verify
Finished finished
NewSessionTicket ticket_list<0..2^32-1>
} AuthResponse
key_list :the list of keys indicated by key_index.
On a TLS Server, the LURK Server initiates the LURK exchange after receiving the ClientHello from the TLS Client. The purpose of this exchange is to retrieve the CertificateVerify, Finished, and the necessary keys to:
Perfect Forward Secrecy Setting:
The LURK Client proceeds to the Transcript Hash Setting PSK Key Exchange Mode Setting and the Key Schedule Input Secret Setting as described in Section 3.3.
Handshake Mode Setting:
Handshake Setting: The handshake is set as described in [I-D.ietf-tls-tls13] section 4.4.
Key Request Setting:
Upon receiving the AuthResponse, the TLS Server encrypts the messages and pursue the TLS handshake as defined in [I-D.ietf-tls-tls13].
On a TLS Client the LURK Client initiates an AuthRequest in order to compute the Finished and optional CertificateVerify as well as to retrieve the necessary keys to:
The TLS Client has decrypted the encrypted handshake messages sent by the TLS Server by retrieving the server_handshake_traffic_secret with an HandshakeServerKeyRequest.
The LURK Client proceeds to Perfect Forward Secrecy Setting, Transcript Hash Setting, Key Schedule Input Secret Setting as described in Section 3.3.
If the TLS Client has received a CertificateRequest from the TLS Server, the LURK Client:
Handshake Mode Setting:
Handshake Setting:
Key Request Setting:
Ticket Number Setting:
Upon receiving the AuthResponse, the LURK Client has the necessary information to proceed the TLS handshake. The ticket_list is a list of local_ticket. The list MUST have a maximum of one local_ticket. The LURK Client is expected to manage the local_tickets as described in Section 4.4.1
local_ticket re-uses the NewSessionTicket structure in two different ways depending if the LURK exchange is initiated by a TLS Client or by a TLS Server.
During the initial handshake, the TLS Client has received a local_ticket from the LURK Server and a new_session_ticket from the TLS Server. The TLS Client updates the local_ticket as follows: the ticket_nonce and extensions fields of the new_session_ticket are copied to the local_ticket.
When the TLS Server provides more than one new_session_ticket tickets, these tickets are expected to have different nonce. On the other hand a single local_ticket will be provided by the LURK Server. The TLS Client generates an associated local_ticket for each new_session_ticket. All of them are generated from the local_ticket provided by the LURK Server.
Though the new_Session_ticket and the local_ticket have different meanings, a TLS Client will not be able to perform session resumption without the corresponding local_ticket. More specifically, the TLS Client MUST:
Upon receiving a handshake_server_key request, the LURK server proceeds as follows:
Perfect Forward Secrecy Check is performed as Section 3.3 using the pfs, and client_random (resp. server_random) as described in Section 3.3 (resp. Section 4.3).
Transcript-Hash Check, PSKExchangeMode Check, KeyScheduleInputSecrets Check are performed as described in Section 3.4
HandshakeMode Check:
Handshake Check:
CertificateVerify Check:
Keys are generated as described in [I-D.ietf-tls-tls13] section 7.1. This includes the Base Key use to generate the Finished messages as well as the resumption_master_secret.
key_request is indicative and is used by the LURK Client to indicate the keys that are not necessarily needed in order to save bandwidth. The LURK Server SHOULD NOT responds with keys whose key_request bit is unset.
The CertificateVerify message is generated as described in [I-D.ietf-tls-tls13] section 4.4.3.
The Finished message is generated as described in [I-D.ietf-tls-tls13] section 4.4.4.
ticket_number indicates the number of NewSessionTicket. ticket_session have different meaning when used by the TLS Client or the TLS Server. When the LURK exchange is initiated by the LURK Client, the ticket_sessions are local_ticket and are only expected to be used between the LURK Client and the LURK Server. Such local_ticket avoids a direct communication of the resumption_master_secret. local_ticket follows the definition of new_session_tickets described in [I-D.ietf-tls-tls13] section 4.6.1. The LURK Server MUST have a zero length ticket_nonce and zero length extensions
When the LURK exchange is initiated by the TLS Server the tickets are new_session_tickets as described in [I-D.ietf-tls-tls13] section 4.6.1. As a result:
| [I-D.ietf-tls-tls13] | Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Internet-Draft draft-ietf-tls-tls13-28, March 2018. |
| [I-D.mglt-lurk-lurk] | Migault, D., "LURK Protocol version 1", Internet-Draft draft-mglt-lurk-lurk-00, February 2018. |
| [I-D.mglt-lurk-tls12] | Migault, D., "LURK Extension version 1 for (D)TLS 1.2 and (D)TLS 1.1 Authentication", Internet-Draft draft-mglt-lurk-tls12-00, February 2018. |