TLS Working Group P. Urien Internet Draft Telecom Paris Intended status: Experimental Ethertrust 17 March 2026 Expires: 16 September 2026 TLS for Secure Element Recursive Authentication draft-urien-tls-se-xauth-00 Abstract This document defines a recursive authentication architecture based on the TLS 1.3 pre-shared key (PSK) mode. In this context, TLS servers, typically hosted within secure elements (TLS-SE), realize procedures that compute TLS 1.3 PSK-binder and Handshake Secret. These procedures allow a client to authenticate to downstream TLS servers without directly possessing the corresponding PSKs. Authentication capabilities can therefore be delegated across multiple TLS servers while maintaining protection of the underlying secrets. Requirements Language 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. 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 September 2026. . Urien Expires September 2026 [Page 1] Copyright Notice Copyright (c) 2026 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents Abstract........................................................... 1 Requirements Language.............................................. 1 Status of this Memo................................................ 1 Copyright Notice................................................... 2 1 Introduction..................................................... 3 1.1 PSK Binder procedure........................................ 3 1.2 Handshake Secret Procedure.................................. 3 2 Recursive authentication with TLS-PSK............................ 4 2.1 Overview.................................................... 4 2.2 Recursive Authentication.................................... 4 2.3 Root Server................................................. 5 2.4 Crypto Provider............................................. 5 2.5 Target server............................................... 5 3 1-HOP session.................................................... 6 4_2-HOPs session................................................... 6 5 n-HOPs session................................................... 7 6 IANA Considerations.............................................. 7 7 Security Considerations.......................................... 7 8 References....................................................... 8 8.1 Normative References........................................ 8 8.2 Informative References...................................... 8 9 Authors' Addresses............................................... 8 Urien Expires September 2026 [page 2] TLS for Secure Element Recursive Authentication March 2026 1 Introduction TLS1.3 [RFC8446] supports a basic key exchange mode based on pre- shared-key (PSK) with Diffie-Hellman over either finite fields or elliptic curves (EC)DHE, in short TLS1.3-PSK for PSK with (EC)DHE. According to [RFC8446] external PSKs MAY be provisioned outside of TLS [RFC9257}. TLS1.3-PSK server MAY be implemented in secure elements [TLS-SE]. The TLS1.3 client MAY use a TLS Identity Module [TLS-IM], that protects procedures dealing with PSK. 1.1 PSK Binder procedure The Early Secret (ESK) is computed according to relation: ESK =HKDF-Extract(salt=0s,PSK) = HMAC(salt=0s,PSK) The Binder Key (BSK) for outside provisioning is computed according to the relation: BSK = Derive-Secret(ESK, "ext binder", "") The Finished External Key (FEK) is computed according to the relation: FEK = KDF-Expand-Label(BSK, "finished", "", Hash.length) For Derive-Secret procedures, "" is equivalent to the value hash(empty), whose size is hash-length. The PSK Binder is computed as: PSK-Binder=HMAC(FEK, transcript hash) PSK-Binder is included in the Client Hello message. We name derive(transcript hash) or derive(T) the procedure that computes the PSK-Binder. 1.2 Handshake Secret Procedure The Derived Secret (DSK) is computed according to the relation: DSK= Derive-Secret(ESK, "derived", ""). The Handshake Secret (HS) is computed as: HS= HKDF-Extract(salt=DSK,(EC)DHE) We name derive(DHE) the procedure that computes the Handshake Secret. The recovery of HS needs the knowledge of both PSK and (EC)DHE. Therefore, even if PSK has a low entropy, it is extremely difficult to retrieve the HS value. Urien Expires September 2026 [Page 3] TLS for Secure Element Recursive Authentication March 2026 2 Recursive authentication with TLS-PSK 2.1 Overview In traditional TLS-PSK deployments the client must possess the PSK locally in order to compute the PSK-Binder and the Handshake Secret. Distributing PSKs to clients introduces operational challenges and security risks, especially in large distributed systems. This document introduces a recursive authentication model in which TLS1.3 PSK servers perform PSK-related cryptographic computations on behalf of the client. The client invokes these procedures during the TLS1.3 handshake without learning the underlying PSKs. After authenticating to one TLS secure element server [TLS-SE], the client uses delegated cryptographic services from that server to authenticate to additional TLS-SE servers. Authentication relationships therefore form a recursive chain across multiple servers. 2.2 Recursive Authentication The schema below illustrates recursive authentication with two TLS1.3 servers, server k and server k+1. Two procedures binder; which computes the Binder-PSK value, and derive, which computes the Handshake Secret are realized by server k and used for connection to server k+1. It should be noticed that server k generates Handshake Secret for server k+1, and therefore COULD decrypt further data exchanges between client and server k+1. Client Server k Server k+1 | | | |=== TLS Channel Established ===| | | | | |----compute Binder-PSK-------->| | |<---Binder-PSK value-----------| | |----ClientHello------------------------------------------ >| |<---ServerHello--------------------------------------------| | Compute (EC)DHE | | |----Compute Handshake Secret-->| | |<---HandshakeSecret value------| | |----Close TLS session--------->| | |<---Server Encrypted Extensions----------------------------| |<---Server Finished----------------------------------------| |----Client Finished--------------------------------------->| | | |================== TLS Channel Established ================| Urien Expires September 2026 [Page 4] TLS for Secure Element Recursive Authentication March 2026 2.3 Root Server The root server (RS) is the first server to which client is connected; it provides binder and derive procedures to be used for connection to the second server (server 2). According to [TLS-SE] root server MAY be implemented in secure elements [ISO7816}. 2.4 Crypto Provider We call Crypto Provider (CP) the entity that knows the pre-shared- key to be used with root server (server 1), and therefore that is able to compute binder(T) and derive(DHE) procedures. Crypto Provider could be realized in multiple computing environments such as: - Classical software programs using PSK value to compute binder and derive procedures. PSK is exposed in software memory, and cloning is possible. - Tamper resistant computing devices such as secure elements defined by [ISO7816] standards. The IETF draft [TLS-IM] defines ISO7816 interfaces for binder and derive procedures computed within secure elements. This environment ensures strong key protection, non- extractable secrets, and portable identity. - Remote call of procedures hosted in network device. For example the IETF draft [RACS] defines interfaces running over a TLS stack that enable remote accesses to secure elements implementing binder and derive functions as defined by [TLS-IM]. These resources can be used over the TLS protocol by the client, which is identified by an X509 certificate. This provides hardware-backed keys, and targets Virtual Machine environments with PKI support. 2.5 Target server Recursive Authentication creates a tree of servers, the root node is the root server, while other are referred as target servers. The client uses a crypto provider for connection to root. According to [TLS-SE] target server MAY be implemented in secure elements [ISO7816}. Client-------------------------->Root | / \ Crypto Provider Target Target / | \ / \ Software Secure Network Target Target Element Urien Expires September 2026 [Page 5] TLS for Secure Element Recursive Authentication March 2026 3 1-HOP session A 1-HOP session establishes a session between a client and a roor server. Client Crypto Provider Root Server | | | | | | |----- binder(Transcript)-->| | |<---- binder value --------| | | | | |----- ClientHello --------------------------------->| | | |<---------------------- ServerHello ----------------| | | |----- derive(DHE) -------->| | |<---- Handshake Secret-----| | | | |<---- Server Encrypted Extensions -----------------| |<---- Server Finished ------------------------------| | | |----- Client Finished ----------------------------->| | | |=========== Secure AEAD Channel Established ========| 4_2-HOPs session Client Crypto Provider Root Server Target Server |-- binder(T1)--->| | | |<--binder value--| | | |---ClientHello----------------------> | | |<--ServerHello----------------------- | | |---derive(DHE1)->| | | |<--HS1 value-----| | | |<--Server Encrypted Extensions------- | | |<--Server Finished--------------------| | |---Client Finished------------------->| | |====== TLS Channel Established =======| | | | | |---binder(T2)--------------------_--->| | |<--binder value ----------------------| | |---ClientHello------------------------------------------>| |<--ServerHello-------------------------------------------| |---derive(DHE2)---------------------->| | |<--HS2 Value--------------------------| | |<--Close Session--------------------->| | |<--Server Encrypted Extensions---------------------------| |<--Server Finished---------------------------------------| |---Client Finished-------------------------------------->| |=============== TLS Channel Established =================| Urien Expires September 2026 [Page 6] TLS for Secure Element Recursive Authentication March 2026 A 2-HOPs session establishes a session with a target server. The root server typically acts as a gateway that checks the client rights. An example of 2-HOPs client, is available at [TLSSE-Client]. 5 n-HOPs session Client establishes a first session 1 with root server, using a crypto provider that computes binder(T1) and derive(DH1). Client establishes a session 2 with target 1 server, using binder(T2) and derive(DHE2) provided par root server. Client closes session with root server. Client establishes a session k+1 with target k server, using binder(Tk+1) and derive(DHEk+1) provided par target k-1 server. Client closes session with target k-1. Client establishes a session n with target n-1 server, using binder(Tn) and derive(DHEn) provided par target n-2 server. Client closes session with target n-2. 6 IANA Considerations This draft does not require any action from IANA. 7 Security Considerations Recursive Authentication MAY be realized with classical software TLS-PSK server, but in these platforms PSK is exposed in software memory, and cloning is possible. Recursive Authentication within TLS-SE servers has the followings security benefits : - PSK Protection :PSKs remain protected inside secure elements and MUST NOT be exposed to clients. - Delegated Authentication: Authentication capabilities are delegated through controlled cryptographic procedures rather than through direct key distribution. - Compartmentalization: Each TLS-SE server manages its own PSKs and delegation policies. Compromise of one server does not automatically compromise unrelated servers. - Revocation: Removing a server from the authentication chain prevents further delegation to downstream servers. Urien Expires September 2026 [Page 7] TLS for Secure Element Recursive Authentication March 2026 8 References 8.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119,DOI 10.17487/RFC2119, March 1997, [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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. [RFC9257] HOUSLEY, R., HOYLAND, J., SETHI, M., et al. Rfc 9257: Guidance for external pre-shared key (psk) usage in tls. 2022. [ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards with Contacts", The International Organization for Standardization (ISO). 8.2 Informative References [TLS-IM] "Identity Module for TLS Version 1.3", draft-urien-tls-im- 10.txt, January 2024. [RACS] "Remote APDU Call Secure (RACS)", draft-urien-core-racs- 19.txt, February 2024 [TLS-SE] "Secure Element for TLS Version 1.3", draft-urien-tls-se- 08, December 2024 [TLSSE-Client] "2-Hops Recursive Authentication Client", https://github.com/purien/pnhsm 9 Authors' Addresses Pascal Urien Telecom Paris - Ehertrust 19 place Marguerite Perey 91120 Palaiseau France Email: Pascal.Urien@telecom-paris.fr Urien Expires September 2026 [Page 8]