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


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

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 Notice

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 ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

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.

2. 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), rsa_master (2),
   rsa_extended_master (3), ecdhe (4), (255)

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)

struct {
     Designation designation = "tls12";
     int8 version = 1;
} Extension;

struct {
    Extension extension;
    select( Extension ){
        case ("tls13", 1):
    } type;
    select( Extension ){
        case ("tls13", 1):
    } status;
    uint64 id;
    unint32 length;
} LURKHeader;

3. handshake_server_key

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.

3.1. Request Payload

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

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

indicates how the PSK is provisioned to initiate the key schedule as described in [I-D.ietf-tls-tls13] section 7.1. The type psk_raw indicates the PSK is explicitly provided. The type psk_ticket indicates the PSK is generated from the ticket as described in [I-D.ietf-tls-tls13] section 4.6.1.
the one-way hash function (OWHF) used by LURK to implement Perfect Forward Secrecy.
the hash function used by the Transcript-Hash [I-D.ietf-tls-tls13] section 4.4.1.
reuses the OfferedPsks described in [I-D.ietf-tls-tls13] section 4.2.11. The PSK structure only allow a single PSK, thus OfferedPsks MUST represent a single PSK.
defines pre shared key exchange defined in [I-D.ietf-tls-tls13] section 4.2.9. It indicates whether the key exchange considers a (EC)DHE key establishment or not in addition to the PSK.
reuses the structure NamedGroup of [I-D.ietf-tls-tls13] section 4.2.7 to indicate the curve or the group used in (EC)DHE key establishment.
the necessary handshake context to generate the key as described in [I-D.ietf-tls-tls13] section 7.1. The handshake_context MUST be ClientHello…ServerHello.
the necessary secret inputs (PSK, (EC)DHE) secret necessary for the key schedule of [I-D.ietf-tls-tls13] section 7.1.

3.2. Response Payload

struct {
    opaque server_handshake_key<0..2^32-1>
} HandshakeServerKeyResponse

the server_handshake_key

3.3. LURK Client Behavior

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:

3.4. LURK Server Behavior

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 with the binder_key generated as described in [I-D.ietf-tls-tls13] section 7.1.

Key Generation:

4. auth

This exchange provides interactions with a Cryptographic Service both on the TLS Client side as well as the TLS Server side.

4.1. Request Payload

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

end point certificate defined in [I-D.ietf-tls-tls13] section 4.4.2.
signature algorithm used defined in [I-D.ietf-tls-tls13] section 4.2.3.
defines the specific Handshake Context and Base Key necessary to compute authentication messages as defined in [I-D.ietf-tls-tls13] section 4.4. The handshake_mode set to server indicates the LURK exchange is performed by the TLS Server while the handshake_mode set to client or post-handshake indicates the LURK exchange is performed by the TLS Client.
Handshake Context has defined in [I-D.ietf-tls-tls13] section 4.4.
indicates optional requested keys. The bit is set to 1 to indicate the key is being requested by the LURK Client. ..* bit 0 : client_handshake_traffic_secret ..* bit 1 : server_handshake_traffic_secret ..* bit 2 : client_application_traffic_secret_0 ..* bit 3 : server_application_traffic_secret_0 ..* bit 4 : exporter_master_secret ..* bit 5-7: set to 0
indicates the expected number of session resumption tickets. When requested by the TLS Client the ticket_number is expected to be 0 or 1. When requested by the TLS Server the number can be larger.

4.2. Response Payload

    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

follows the same syntax as key_request in Section 4.1.

key_list :the list of keys indicated by key_index.

list of NewTicketSessions

4.3. LURK Client Behavior (TLS Server)

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].

4.4. LURK Client Behavior (TLS Client)

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

4.4.1. Local Ticket

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:

4.5. LURK Server Behavior

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:

5. Security Considerations

6. IANA Considerations

7. Acknowledgments

8. Normative References

[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.

Author's Address

Daniel Migault Ericsson 8275 Trans Canada Route Saint Laurent, QC, 4S 0B6 Canada EMail: