Individual Submission M. Vieuille Internet-Draft 28 May 2025 Intended status: Informational Expires: 29 November 2025 KerPass EPHEMSEC One-Time Password Algorithm draft-mvieuille-kerpass-ephemsec-00 Abstract This document specifies EPHEMSEC, an algorithm for generating one- time passwords (OTPs) and one-time keys (OTKs). Unlike traditional OTP algorithms that rely solely on static shared secrets, EPHEMSEC uses public key cryptography, which simplifies secure deployment on authentication servers. EPHEMSEC also supports binding the generated OTP/OTK to contextual data. When this context is obtained and injected by a trusted agent, the resulting codes can be made resistant to phishing and man-in-the-middle attacks. Finally, EPHEMSEC includes a built-in time synchronization mechanism that embeds a synchronization hint into the generated output. This allows both parties to deterministically derive the same OTP/OTK value without requiring trial-and-error validation, enabling compatibility with protocols such as Password Authenticated Key Exchange (PAKE) and TLS with Pre-Shared Key (TLS-PSK) that require exact secret agreement. 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 29 November 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Vieuille Expires 29 November 2025 [Page 1] Internet-Draft EPHEMSEC May 2025 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 3. Functions and Notation . . . . . . . . . . . . . . . . . . . 6 4. EPHEMSEC Roles . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Initiator Role . . . . . . . . . . . . . . . . . . . . . 6 4.2. Responder Role . . . . . . . . . . . . . . . . . . . . . 6 5. EPHEMSEC Parametrization . . . . . . . . . . . . . . . . . . 6 5.1. Hash Function . . . . . . . . . . . . . . . . . . . . . . 7 5.1.1. HKDF(salt, ikm, info, L) → byte[L] Function . . . . . 7 5.2. ECDH(privKey, PubKey) → byte[DHLEN] Function . . . . . . 7 5.3. Key Exchange Pattern . . . . . . . . . . . . . . . . . . 7 5.3.1. E1S1 Pattern . . . . . . . . . . . . . . . . . . . . 8 5.3.2. E1S2 Pattern . . . . . . . . . . . . . . . . . . . . 8 5.3.3. E2S2 Pattern . . . . . . . . . . . . . . . . . . . . 8 5.3.4. Rationale for Selecting a Key Exchange Pattern . . . 8 5.4. Code Output . . . . . . . . . . . . . . . . . . . . . . . 8 5.4.1. T – Time Window . . . . . . . . . . . . . . . . . . . 9 5.4.2. B – Encoding Base . . . . . . . . . . . . . . . . . . 9 5.4.3. P – Code Size . . . . . . . . . . . . . . . . . . . . 9 5.5. Naming Scheme . . . . . . . . . . . . . . . . . . . . . . 9 6. EPHEMSEC Credentials . . . . . . . . . . . . . . . . . . . . 10 6.1. Shared PSK . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Responder Static Key . . . . . . . . . . . . . . . . . . 10 6.3. Initiator Static Key . . . . . . . . . . . . . . . . . . 11 7. EPHEMSEC Protocol Overview . . . . . . . . . . . . . . . . . 11 8. Nonce Acquisition . . . . . . . . . . . . . . . . . . . . . . 12 8.1. INONCE – Initiator Nonce . . . . . . . . . . . . . . . . 12 8.2. PTIME – Responder Time Nonce . . . . . . . . . . . . . . 13 8.2.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . 13 8.2.2. Responder Function – PTime(time) → (PTIME, SYNCHINT) . . . . . . . . . . . . . . . . . . . . . . 13 8.2.3. Initiator Function – SyncPTime(time, SYNCHINT) → PTIME . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Z - Diffie-Hellman Secret Derivation . . . . . . . . . . . . 14 9.1. Initiator E1S1 Z Derivation . . . . . . . . . . . . . . . 14 9.2. Responder E1S1 Z Derivation . . . . . . . . . . . . . . . 15 9.3. Initiator E1S2 Z Derivation . . . . . . . . . . . . . . . 15 Vieuille Expires 29 November 2025 [Page 2] Internet-Draft EPHEMSEC May 2025 9.4. Responder E1S2 Z Derivation . . . . . . . . . . . . . . . 15 9.5. Initiator E2S2 Z Derivation . . . . . . . . . . . . . . . 15 9.6. Responder E2S2 Z Derivation . . . . . . . . . . . . . . . 16 10. 10. ISK – Intermediary Secret Derivation . . . . . . . . . . 16 10.1. 10.1 Inputs . . . . . . . . . . . . . . . . . . . . . . 16 10.2. 10.2 ISK Derivation . . . . . . . . . . . . . . . . . . 16 11. OTP/OTK Derivation . . . . . . . . . . . . . . . . . . . . . 17 11.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.2. OTP Derivation (B ∈ {10, 16, 32}) . . . . . . . . . . . 17 11.3. OTK Derivation (B = 256) . . . . . . . . . . . . . . . . 18 12. Key Exchange Protocol Integration . . . . . . . . . . . . . . 18 13. Security considerations . . . . . . . . . . . . . . . . . . . 19 13.1. Adversary Profiles . . . . . . . . . . . . . . . . . . . 20 13.2. Output Unpredictability of EPHEMSEC . . . . . . . . . . 20 13.3. Phishing and MITM Prevention via Context Binding . . . . 21 13.3.1. The need for a trusted Agent . . . . . . . . . . . . 21 13.4. Mutual Authentication . . . . . . . . . . . . . . . . . 22 13.5. Time Synchronization Attacks . . . . . . . . . . . . . . 22 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 15.1. Normative References . . . . . . . . . . . . . . . . . . 23 15.2. Informative References . . . . . . . . . . . . . . . . . 23 Appendix A. OTP Sampling Bias . . . . . . . . . . . . . . . . . 24 A.1. Bias Formula . . . . . . . . . . . . . . . . . . . . . . 24 A.1.1. Derivation . . . . . . . . . . . . . . . . . . . . . 25 A.1.2. Case 1: When M is divisible by m (M % m = 0) . . . . 25 A.1.3. Case 2: When M is not divisible by m (M % m = s where 0 < s < m) . . . . . . . . . . . . . . . . . . . . . . 25 A.1.4. Bias Quantification . . . . . . . . . . . . . . . . . 25 A.2. Lemma 1: Distribution of Remainders in [0, M) . . . . . . 26 A.2.1. Proof: . . . . . . . . . . . . . . . . . . . . . . . 26 Appendix B. Design Rationale . . . . . . . . . . . . . . . . . . 27 B.1. Use of HKDF . . . . . . . . . . . . . . . . . . . . . . . 27 B.2. Usage of PSK . . . . . . . . . . . . . . . . . . . . . . 27 B.3. Usage of Nonces . . . . . . . . . . . . . . . . . . . . . 27 B.3.1. Transmission of the Responder Nonce . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction The concept of one-time passwords has existed for decades. Proprietary systems such as RSA SecurID have been available since the early days of the Internet and have demonstrated the viability of time-based and event-based one-time passwords. HOTP (specified in [RFC4226]) and TOTP (specified in [RFC6238]) are open algorithms that enable the implementation of one-time password generators operating similarly to earlier proprietary systems. These algorithms now form the foundation of various hardware tokens and numerous smartphone Vieuille Expires 29 November 2025 [Page 3] Internet-Draft EPHEMSEC May 2025 authenticator applications that provide a second authentication factor for high-profile web applications. While OTP authenticator applications are simple to use and widely available, they have had limited impact on web application security. Two factors contribute to this limited success: 1. Deployment of corresponding authentication servers introduces additional risks, as stored credentials can be used to impersonate users if compromised. This problem is particularly serious in today's cloud environments. 2. The design of traditional authenticator applications does not address specific security challenges of web applications. In particular, modern web browsers do not provide a trusted input interface for entering authentication data, making users vulnerable to phishing attacks that capture credentials. These problems are the main reasons explaining the lack of attractiveness of one-time passwords for securing web applications. In the current technological ecosystem, one-time password solutions are seen as obsolete, and the current trend is toward using authentication credentials such as [PASSKEY], which address problems 1 and 2 by relying on digital signature key pairs. The KerPass EPHEMSEC algorithm also addresses problems 1 and 2 but takes a meaningfully different approach than digital signatures. The EPHEMSEC client credential contains a Diffie-Hellman key pair, and the server stores only the public part of this key pair. To obtain a new OTP from EPHEMSEC, a trusted agent obtains the server's ephemeral public key and acquires context information such as the login page URL. This information is passed to the EPHEMSEC client (also known as the Responder; see Section 4.2) in a challenge message. The client first calculates a Diffie-Hellman secret using the received public key and local key pair, then uses this ephemeral secret key to generate an OTP using an algorithm based on principles similar to the HOTP algorithm described in [RFC4226]. This simplified description excludes many important details but should be sufficient to provide an understanding of how public key cryptography is used in EPHEMSEC. Assuming that both EPHEMSEC OTP and digital signature solutions like [PASSKEY] can solve the server credential storage issue described in problem 1 and the phishing issue described in problem 2 (by having their output depend upon context input provided by a trusted agent), are there differences between the two that could help determine which option is better in a specific context? Vieuille Expires 29 November 2025 [Page 4] Internet-Draft EPHEMSEC May 2025 One advantage that an OTP authenticator application has over a digital signature authenticator application is simpler integration, resulting from the smaller size of OTPs compared to digital signatures. Integration of smartphone interfaces such as NFC and Bluetooth to computing devices may eventually lessen this advantage, and EPHEMSEC can also generate one-time keys (OTK) that would benefit from the ubiquity of such interfaces. The main difference between OTP/OTK and digital signature credentials is that OTP/OTK are ephemeral *shared* secrets known by both peers involved in an authentication session, whereas digital signatures can only be generated by the peer controlling the private key. There are contexts such as transaction validation in which the one-way nature of digital signatures is an advantage. However, shared secrets have the distinctive advantage that they can be used as the main credential with protocols like Password Authenticated Key Exchange (PAKE) or TLS-PSK that enable *mutual* authentication of the peers involved in an authentication session. The potential to use EPHEMSEC OTP/OTK for mutual authentication is the distinctive feature of this solution. OTPs generated by HOTP/TOTP algorithms are also ephemeral shared secrets, but synchronization problems make their integration with PAKE protocols complex (see Section 12). EPHEMSEC has a built-in auto-synchronization feature (see Section 8.2) that addresses this issue. This document specifies the KerPass EPHEMSEC algorithm, which addresses the fundamental limitations of HOTP/TOTP that have contributed to the low attractivity of OTP authenticator applications for securing web applications. EPHEMSEC solves the server credential storage security problem by using credentials based on public key cryptography, provides a context binding mechanism that enables the generation of OTPs and OTKs resistant to phishing and man-in-the- middle attacks, and produces shared secrets that can be used with mutual authentication protocols such as PAKE and TLS-PSK. Given the ease of implementing OTP/OTK authenticator applications on smartphones, an OTP/OTK generation algorithm with properties similar to EPHEMSEC may be valuable across a wide range of use cases. 2. Requirements Notation 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. Vieuille Expires 29 November 2025 [Page 5] Internet-Draft EPHEMSEC May 2025 3. Functions and Notation This section defines notation and helper functions used throughout the specification. * ||: Denotes byte string concatenation. * byte(v): Converts an integer or single-character input v to a one- byte string. * size(bs): Returns the length of byte string bs, as an integer. * BE8(v): Returns the 8-byte big-endian encoding of unsigned integer v. * U64(bs): Converts an 8-byte string bs into an unsigned 64-bit integer, using big-endian interpretation. * TLV(tag, bs): Constructs a Tag-Length-Value encoding. Returns byte(tag) || byte(size(bs)) || bs where: - tag: An integer identifier in the range 0–255 - bs: A byte string with length ≤ 255 bytes 4. EPHEMSEC Roles EPHEMSEC distinguishes two roles: Initiator & Responder. 4.1. Initiator Role This role is normally assigned to relying web application. 4.2. Responder Role This role is normally assigned to authenticator application. 5. EPHEMSEC Parametrization Each EPHEMSEC protocol instance is characterized by its selection of cryptographic primitives and operational parameters. These include: * A secure hash function, * An elliptic-curve Diffie-Hellman (ECDH) function, * A key exchange pattern defining key contributions from the parties, Vieuille Expires 29 November 2025 [Page 6] Internet-Draft EPHEMSEC May 2025 * Code output parameters specifying how the OTP/OTK values are formatted. 5.1. Hash Function The hash function MUST be cryptographically secure (e.g., SHA-512) with digest length between 32 and 64 bytes. . This hash function is used to instantiate the HKDF key derivation function, as specified in [RFC5869]. 5.1.1. HKDF(salt, ikm, info, L) → byte[L] Function This function follows the specification in [RFC5869]. * salt, ikm, and info are arbitrary-length byte strings. * L is a positive integer indicating the desired output length in bytes. * The function returns a byte string of length L. 5.2. ECDH(privKey, PubKey) → byte[DHLEN] Function This function performs an Elliptic-Curve Diffie-Hellman (ECDH) key agreement over a specified elliptic curve group, producing a shared secret of fixed length DHLEN. * privKey: A private key from an elliptic curve key pair. * PubKey: A public key from the same elliptic curve group. The function computes a shared secret using the standard ECDH primitive associated with the curve in use. The result is a byte string of length DHLEN. The specific behavior, including internal encoding and validation, is determined by the curve and cryptographic library in use. An example of a suitable ECDH function is X25519, as defined in [RFC7748], which yields a 32-byte shared secret. 5.3. Key Exchange Pattern The key exchange pattern determines which types of keys (ephemeral or static) are contributed by the Initiator and Responder during the ECDH exchanges. Vieuille Expires 29 November 2025 [Page 7] Internet-Draft EPHEMSEC May 2025 Note that in each of the pattern below, the Initiator always contribute an ephemeral key and the Responder always contribute a static key. 5.3.1. E1S1 Pattern * Initiator contributes: 1 ephemeral key. * Responder contributes: 1 static key. 5.3.2. E1S2 Pattern * Initiator contributes: 1 ephemeral key and 1 static key. * Responder contributes: 1 static key. 5.3.3. E2S2 Pattern * Initiator contributes: 1 ephemeral key and 1 static key. * Responder contributes: 1 ephemeral key and 1 static key. 5.3.4. Rationale for Selecting a Key Exchange Pattern The choice of key exchange pattern should align with the authentication guarantees provided by the method used to validate the generated OTP or OTK. If the selected authentication method provides only one-way authentication—verifying the Responder to the Initiator—then there is no benefit in selecting a pattern more complex than E1S1. Patterns such as E1S2 or E2S2 introduce additional computational and communication overhead without improving the resulting security. If the authentication method provides mutual authentication—for example, using PAKE or TLS-PSK—then the use of E1S2 or E2S2 becomes appropriate. These patterns ensure that both the Initiator and the Responder contribute static keys to the Diffie-Hellman exchange, reinforcing the mutual nature of the derived secret. 5.4. Code Output The format and characteristics of the OTP/OTK values produced by EPHEMSEC are determined by the parameters T, B, and P. Vieuille Expires 29 November 2025 [Page 8] Internet-Draft EPHEMSEC May 2025 5.4.1. T – Time Window T defines the duration of a validity window for each generated code, expressed in seconds. T MUST be a positive integer greater than parameter B. 5.4.2. B – Encoding Base B specifies the base used for code encoding. Valid values are: * 10, 16, or 32: Encodes the output using a human-readable digit set, suitable for OTP. * 256: Encodes the output in binary form, suitable for OTK. 5.4.3. P – Code Size P defines the number of digits in the generated code, where each digit is an integer in the range [0..B). The valid range of P depends on the encoding base B and the minimum required entropy. The table below summarizes the minimum and maximum allowed values of P for each supported base, along with the corresponding entropy range. +======+=======+=======+=============+=============+ | Base | min P | max P | min Entropy | max Entropy | +======+=======+=======+=============+=============+ | 10 | 8 | 15 | 23 bits | 46 bits | +------+-------+-------+-------------+-------------+ | 16 | 7 | 17 | 24 bits | 64 bits | +------+-------+-------+-------------+-------------+ | 32 | 6 | 13 | 25 bits | 60 bits | +------+-------+-------+-------------+-------------+ | 256 | 4 | 65 | 24 bits | 512 bits | +------+-------+-------+-------------+-------------+ Table 1: Code limits 5.5. Naming Scheme EPHEMSEC uses a structured naming scheme to identify specific protocol instantiations. A valid EPHEMSEC name has the following format: Kerpass____TBP

For example: Vieuille Expires 29 November 2025 [Page 9] Internet-Draft EPHEMSEC May 2025 Kerpass_SHA512_X25519_E1S1_T600B32P9 Where: 1. corresponds to the hash function used (see Section 5.1), e.g., SHA512. 2. denotes the ECDH function used (see Section 5.2), e.g., X25519. 3. specifies the key exchange pattern (see Section 5.3), e.g., E1S1. 4. TBP

encodes the code output parameters (see Section 5.4), with , , and

replaced by their respective values. 6. EPHEMSEC Credentials EPHEMSEC requires an *enrollment phase* during which the Responder (typically the authenticator app) registers an account with the Initiator (the relying web application). Implementations may support various enrollment scenarios depending on their operational context and security requirements. This specification does not define a particular enrollment protocol, but it assumes the following outcomes: * The Responder registers a static ECDH public key with the Initiator, corresponding to a key pair it controls. * Both parties derive and retain a shared secret (PSK) that will be used in subsequent EPHEMSEC operations. 6.1. Shared PSK The *pre-shared key (PSK)* is a byte string shared between the Responder and Initiator. It is established during the enrollment process and MUST be at least 32 bytes in length. The PSK is stored by both parties. 6.2. Responder Static Key During enrollment, the Responder generates a static ECDH key pair and transmits the corresponding public key to the Initiator. The Initiator stores this public key as part of the Responder’s account data. Vieuille Expires 29 November 2025 [Page 10] Internet-Draft EPHEMSEC May 2025 6.3. Initiator Static Key The Initiator is required to maintain a static ECDH key pair only when using key exchange patterns that require an Initiator static key (e.g., E1S2 or E2S2). The mechanism by which the Responder obtains and establishes trust in the Initiator’s static public key is out of scope for this specification. 7. EPHEMSEC Protocol Overview This section outlines the overall flow of a complete EPHEMSEC OTP/OTK generation exchange between an Initiator and a Responder. It assumes the following preconditions: * The two parties have agreed on an EPHEMSEC instantiation (see Section 5). * The Responder has registered an account with the Initiator, including a shared PSK and necessary public key material (see Section 6). The protocol operates as a Challenge/Response exchange. The Initiator sends a message to the Responder containing: * A CONTEXT byte string (e.g., relying party information), * A freshly generated INONCE, * Its Diffie-Hellman public key(s) as required by the selected key exchange pattern. *Note*: The structure and transport of this message are out of scope for this specification. Upon receiving this challenge, the Responder performs the following steps to compute the OTP or OTK: 1. *Obtain nonces* (see Section 8): * Read or receive INONCE from the Initiator, * Generate PTIME and extract SYNCHINT. 2. *Compute the Diffie-Hellman shared secret Z* (see Section 9): Based on the agreed key exchange pattern and available keys. Vieuille Expires 29 November 2025 [Page 11] Internet-Draft EPHEMSEC May 2025 3. *Derive the intermediary secret ISK* (see Section 10): Using HKDF with Z, PSK, CONTEXT, SCHEME, INONCE, and PTIME. 4. *Generate the OTP or OTK* (see Section 11): * The format is determined by the encoding base B, * The last digit or byte encodes SYNCHINT. The Responder returns the resulting code to the Initiator. The Initiator, upon receiving the response, uses the included SYNCHINT to reconstruct PTIME and repeat the same derivation steps to validate or use the resulting code. 8. Nonce Acquisition Each EPHEMSEC session uses two distinct nonces contributed independently by the two parties involved: * The *Initiator* provides a nonce called INONCE, which ensures session uniqueness from the Initiator's side. * The *Responder* provides a time-based nonce called PTIME, which captures the Responder’s local clock state. These nonces serve as independent inputs to the intermediary secret derivation process (see Section 10). 8.1. INONCE – Initiator Nonce The Initiator generates a nonce INONCE that contributes to the personalization of the derived intermediary secret (see Section 10). This value acts as an Initiator-specific input to ensure uniqueness of each EPHEMSEC execution. INONCE MUST be a byte string of length between 16 and 64 bytes. It MUST be unique for each run of the EPHEMSEC algorithm, and MUST NOT be reused across authentication sessions. The value of INONCE is transmitted from the Initiator to the Responder as part of the authentication request. Vieuille Expires 29 November 2025 [Page 12] Internet-Draft EPHEMSEC May 2025 8.2. PTIME – Responder Time Nonce The EPHEMSEC Responder derives a pseudo-time value, PTIME, from current time reading. This PTIME acts as a Responder contributed nonce and is used in secret derivation along with an Initiator- contributed nonce. The challenge lies in enabling the Initiator to reconstruct the same PTIME value computed by the Responder, despite clock skew between the two parties. To address this, the Responder includes a *synchronization hint*, SYNCHINT, in the last digit of the generated OTP or OTK. Given SYNCHINT, the Initiator can recover the original PTIME as long as clock drift remains within acceptable bounds. 8.2.1. Inputs The following parameters are used throughout this section: * time: Current Unix timestamp (seconds since 1970-01-01). * T: Code validity window (see Section 5.4.1). * B: Encoding base (see Section 5.4.2). 8.2.2. Responder Function – PTime(time) → (PTIME, SYNCHINT) This function is executed by the Responder to compute the PTIME nonce and the associated synchronization hint: step = T / (B - 1) # floating point division PTIME = round(time / step) SYNCHINT = PTIME % B return PTIME, SYNCHINT 8.2.3. Initiator Function – SyncPTime(time, SYNCHINT) → PTIME This function is executed by the Initiator to reconstruct the Responder’s PTIME using its local time and the received SYNCHINT: Vieuille Expires 29 November 2025 [Page 13] Internet-Draft EPHEMSEC May 2025 mintime = time - (T / 2) step = T / (B - 1) # floating point division mpt = round(mintime / step) mphint = mpt % B Q = mpt // B # integer division PTIME = Q * B + SYNCHINT if SYNCHINT < mphint: PTIME += B return PTIME This algorithm works correctly if the clock difference between the Responder and Initiator is less than T / 2. Outside this range, synchronization will fail, resulting in mismatched secrets. KerPass uses a 600-second time window, allowing up to ±5 minutes clock drift in between Initiator and Responder. 9. Z - Diffie-Hellman Secret Derivation Each party derives a shared secret Z using the Diffie-Hellman key exchange, based on the agreed EPHEMSEC key exchange pattern (see Section 5.3). Key material is retrieved from received protocol messages and account credential storage. The result of the Diffie-Hellman exchange is a byte string Z, which is used as part of the key derivation input (see later sections). Where ephemeral key pairs are used, they MUST be freshly generated for each execution of the EPHEMSEC protocol and MUST NOT be reused across sessions. EPHEMSEC execution MUST be aborted if any required key is missing or invalid. 9.1. Initiator E1S1 Z Derivation Inputs: * ei Initiator ephemeral Keypair * Sr Responder static PublicKey Z = ECDH(ei, Sr) Vieuille Expires 29 November 2025 [Page 14] Internet-Draft EPHEMSEC May 2025 9.2. Responder E1S1 Z Derivation Inputs: - sr Responder static Keypair - Ei Initiator ephemeral PublicKey Z = ECDH(sr, Ei) 9.3. Initiator E1S2 Z Derivation Inputs: * ei Initiator ephemeral Keypair * si Initiator static Keypair * Sr Responder static PublicKey Z = ECDH(ei, Sr) || ECDH(si, Sr) 9.4. Responder E1S2 Z Derivation Inputs: * sr Responder static Keypair * Ei Initiator ephemeral PublicKey * Si Initiator static PublicKey Z = ECDH(sr, Ei) || ECDH(sr, Si) 9.5. Initiator E2S2 Z Derivation Inputs: * ei Initiator ephemeral Keypair * si Initiator static Keypair * Er Responder ephemeral PublicKey * Sr Responder static PublicKey Z = ECDH(ei, Er) || ECDH(si, Sr) Vieuille Expires 29 November 2025 [Page 15] Internet-Draft EPHEMSEC May 2025 9.6. Responder E2S2 Z Derivation Inputs: * er Responder ephemeral Keypair * sr Responder static Keypair * Ei Initiator ephemeral PublicKey * Si Initiator static PublicKey Z = ECDH(er, Ei) || ECDH(sr, Si) 10. 10. ISK – Intermediary Secret Derivation EPHEMSEC derives an intermediary secret key ISK using the HKDF function (see Section 5.1.1). 10.1. 10.1 Inputs The function uses the following inputs: * CONTEXT: An implementation-specific byte string (≤ 64 bytes), used to encode contextual information (e.g., login page url). * SCHEME: A byte string representing the EPHEMSEC instantiation (see Section 5.5). * B: Code encoding base (see Section 5.4.2). * P: Code size (see Section 5.4.3). * INONCE: An Initiator-generated nonce, a byte string between 16 and 64 bytes (see see Section 8.1). * PTIME: Responder-contributed time nonce (see Section 8.2). * PSK: A shared pre-established secret (≥ 32 bytes) (see Section 6.1). * Z: Diffie-Hellman shared secret derived from the selected key exchange pattern (see see Section 9). 10.2. 10.2 ISK Derivation The ISK is derived using the following steps: Vieuille Expires 29 November 2025 [Page 16] Internet-Draft EPHEMSEC May 2025 # CONTEXT & SCHEME are used for domain separation salt = TLV(byte('C'), CONTEXT) || TLV(byte('S'), SCHEME) ikm = Z || PSK # INONCE & PTIME are used for output personalization info = TLV(byte('N'), INONCE) || TLV(byte('T'), BE8(PTIME)) # Output length if B == 256: L = P - 1 # OTK case else: L = 8 # OTP case ISK = HKDF(salt, ikm, info, L) return ISK 11. OTP/OTK Derivation The intermediate secret key ISK computed in Section 10 serves as the final source of entropy for generating the OTP (one-time password) or OTK (one-time key). The output format depends on the encoding base B (see Section 5.4.2). 11.1. Inputs * B: Code encoding base (see Section 5.4.2). * P: Code size (see Section 5.4.3). * PTIME: Responder-contributed time nonce (see Section 8.2). * ISK: Intermediate secret key (see Section 10). 11.2. OTP Derivation (B ∈ {10, 16, 32}) When B is 10, 16, or 32, the code is formatted as an OTP composed of P digits. The first P - 1 digits are derived from ISK, and the last digit is a synchronization hint (SYNCHINT) derived from PTIME. ISK MUST be exactly 8 bytes long and is interpreted as an unsigned 64-bit integer. Vieuille Expires 29 November 2025 [Page 17] Internet-Draft EPHEMSEC May 2025 # Interpret ISK as a big-endian unsigned integer maxcode = B ^ (P - 1) isrc = U64(ISK) % maxcode # Extract (P - 1) digits in base B OTP = '' # empty byte string for i in 0 .. (P - 2): digit = byte(isrc % B) OTP = digit || OTP isrc /= B # Append 1-digit time synchronization hint SYNCHINT = byte(PTIME % B) OTP = OTP || SYNCHINT return OTP # byte string of P digits in [0 .. B) *Note*: The result is returned as a sequence of P integer digits in base B. Conversion to a human-readable representation (e.g., alphanumeric alphabet) is outside the scope of this specification. 11.3. OTK Derivation (B = 256) When B is 256, the output is an opaque binary key. The first P - 1 bytes are taken directly from ISK, and the last byte encodes the synchronization hint. SYNCHINT = byte(PTIME % 256) OTK = ISK || SYNCHINT return OTK # byte string of length P 12. Key Exchange Protocol Integration EPHEMSEC OTPs/OTKs are ephemeral *shared secrets* that can serve as primary credentials in mutually authenticated key exchange protocols, such as: * Password-Authenticated Key Exchange (PAKE) * TLS with Pre-Shared Key authentication (TLS-PSK) Traditional one-time password algorithms like HOTP, as defined in [RFC4226], are unsuitable for these protocols due to their reliance on loose synchronization. Validation servers must compare a received OTP against a range of possible values, which precludes direct use as cryptographic key material. Vieuille Expires 29 November 2025 [Page 18] Internet-Draft EPHEMSEC May 2025 EPHEMSEC addresses this limitation by appending a *synchronization digit* to each OTP/OTK. This digit enables reconstruction of the time-based nonce PTIME (see Section 8.2), ensuring that both parties derive identical secrets without relying on trial-and-error validation. To use EPHEMSEC outputs as inputs to a key exchange protocol: 1. *Client Preparation*: * Append the synchronization digit to the account identifier. * Use this composite identifier to initiate the key exchange protocol. 2. *Server Operation*: * Extract the synchronization digit from the received identifier. * Remove the synchronization digit to recover the base account identifier. * Load the corresponding client credentials using the base identifier. * Execute the EPHEMSEC algorithm with the received session parameters, credentials, and synchronization hint to derive the shared secret. * Proceed with the key exchange protocol using the derived secret. 13. Security considerations This section outlines the security properties of the EPHEMSEC algorithm. The analysis presented here is intended to demonstrate why the protocol is expected to meet its security goals, based on widely accepted cryptographic assumptions. This document has not yet undergone comprehensive peer review by the cryptographic and security communities. The security analysis presented should be considered preliminary, and implementers should exercise appropriate caution in security-critical deployments pending further review. Vieuille Expires 29 November 2025 [Page 19] Internet-Draft EPHEMSEC May 2025 13.1. Adversary Profiles Two adversary profiles are considered in this analysis: * *Network Observer* This adversary has access to all publicly visible data, including the Initiator’s and Responder’s static ECDH public keys, session inputs (nonces, ephemeral public keys), and outputs (OTPs/OTKs) from previous EPHEMSEC sessions. It does not have access to any party’s private credentials. * *Credential Leak Attacker* This adversary has all the capabilities of a Network Observer, and additionally has read access to the Initiator’s credential store — specifically the Responder’s shared PSKs and static public keys. It does *not* have access to the Initiator’s private keys or control over protocol behavior. 13.2. Output Unpredictability of EPHEMSEC The primary security goal of an OTP/OTK algorithm is to ensure that outputs are unpredictable — even to attackers with significant passive or partial access. EPHEMSEC achieves this by combining Diffie-Hellman key exchange and HKDF with session-specific nonces. Specifically: 1. *Unpredictability of the Shared Secret (Z)* The ECDH-derived shared secret Z is indistinguishable from random to any adversary lacking private keys, due to the hardness of the Decisional Diffie-Hellman (DDH) problem on the chosen curve. 2. *Unpredictability of the HKDF Input (ikm)* The HKDF input key material (ikm = Z || PSK) inherits the unpredictability of Z. Even if the attacker knows the pre-shared key (PSK), the presence of the fresh and secret Z value ensures ikm remains secure. 3. *Security of the Derived Secret (ISK)* HKDF acts as a cryptographically strong pseudorandom function (PRF), meaning its outputs — including the intermediary secret ISK — are indistinguishable from random, provided the HKDF ikm secret input is unpredictable. Because each execution of EPHEMSEC uses unique nonces and ephemeral keys, the ISK value changes with every session. 4. *Output Derivation (OTP/OTK)* Vieuille Expires 29 November 2025 [Page 20] Internet-Draft EPHEMSEC May 2025 * For OTKs (B = 256): ISK is directly used, preserving its pseudorandomness. * For OTPs (B ∈ {10, 16, 32}): ISK is converted to digits via modular arithmetic. This process introduces bias when B = 10, but the bias is mitigated by restricting code sizes (P) to the ranges specified in Table 1 (see Appendix A for analysis). 5. *Prevention of Replay and Forward Prediction* The use of unique nonces (INONCE, PTIME) and ephemeral keys ensures that no two executions produce the same output — even for the same account and context. This prevents replay attacks and ensures that attackers cannot predict future codes based on prior sessions. As a result, even an attacker who observes multiple sessions (and even possesses some server-side credentials) cannot derive or guess new OTPs or OTKs, nor can they reuse prior ones. 13.3. Phishing and MITM Prevention via Context Binding EPHEMSEC can mitigate web browser phishing and man-in-the-middle (MITM) attacks by binding cryptographic outputs to authentication context through the CONTEXT input (see Section 10.1). This mechanism enables: 1. *Phishing Resistance*: * By embedding the login page URL in CONTEXT, the derived OTP/ OTK becomes domain-specific. * An attacker hosting a fake page cannot reuse intercepted codes, as their context will differ. 2. *MITM Resistance*: * Including the server's TLS certificate hash in CONTEXT ensures the OTP/OTK is tied to the authenticated connection. * A MITM with an invalid certificate cannot generate valid codes. 13.3.1. The need for a trusted Agent Context binding alone is *insufficient* to provide Phishing or MITM resistance. Vieuille Expires 29 November 2025 [Page 21] Internet-Draft EPHEMSEC May 2025 For Context binding to be efficient, it must be used jointly with a *trusted Agent* (e.g., a browser extension) that: * Reliably acquire authentication context (e.g., page URL, certificate) * Securely inject it into EPHEMSEC's CONTEXT parameter * Resist spoofing or coercion by attackers 13.4. Mutual Authentication Because the EPHEMSEC Initiator and Responder share a PSK (see Section 6.1), all OTP/OTK outputs are derived from a secret known to both parties. As a result, these values can serve as credentials in protocols that support mutual authentication, such as PAKE or TLS- PSK. However, when the E1S1 key exchange pattern is used, the only contribution from the Initiator is an ephemeral key. In this configuration, the mutuality of the shared secret relies solely on the PSK. If the PSK is compromised — for example, by a Credential Leak Attacker — the attacker can impersonate the Initiator to the Responder. To mitigate this risk, it is RECOMMENDED that mutual authentication deployments use the E1S2 or E2S2 key exchange patterns. These patterns require the Initiator to contribute a static ECDH key, ensuring that mutual authentication depends on key material not accessible to a Credential Leak Attacker. This prevents such an attacker from successfully impersonating the Initiator. 13.5. Time Synchronization Attacks EPHEMSEC's time-synchronized nature creates a potential attack vector against the protocol's availability. The algorithm requires that clock drift between Initiator and Responder remain within T/2 seconds for successful PTIME recovery (see Section 8.2). An attacker who can manipulate the time sources or time synchronization mechanisms of either party may cause authentication failures by forcing clock drift to exceed this threshold. Such attacks could result in denial of service against the authentication system. Future revisions will extend PTIME derivation to support event-based counters alongside time-based synchronization. Setting T = 0 will enable event-synchronized OTP/OTK generation using shared counters, Vieuille Expires 29 November 2025 [Page 22] Internet-Draft EPHEMSEC May 2025 while T > 0 will maintain time-based operation, allowing applications to choose the synchronization method best suited to their threat model. 14. IANA Considerations No IANA action is required. 15. References 15.1. Normative References [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, . [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, . 15.2. Informative References [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: Time-Based One-Time Password Algorithm", RFC 6238, DOI 10.17487/RFC6238, May 2011, . [PASSKEY] "passkeys-Specifications", n.d., . Vieuille Expires 29 November 2025 [Page 23] Internet-Draft EPHEMSEC May 2025 Appendix A. OTP Sampling Bias EPHEMSEC generates P (see Section 5.4.3) digits OTPs from 64-bit pseudo-random integers as described in Section 11. This final operation may introduce a non-uniform distribution in the generated OTP when the code base B (see Section 5.4.2) does not evenly divide 2^64, which occurs for all bases except B = 10. We apply the Bias Formula below to evaluate the bias for code base 10. The bias reaches its maximum when the code size P is at its maximum value. While EPHEMSEC supports a maximum P of 15, only 14 digits are used to encode the pseudo-random value. Therefore: bias = 1 / floor(2^64 / 10^14) ≈ 5.4e-6 This value is negligibly close to zero, making the code base 10 bias insignificant. For comparison, [RFC4226] generates 6-digit base-10 OTPs from 31-bit pseudo-random integers, resulting in: bias = 1 / floor(2^31 / 10^6) ≈ 0.5e-3 While this value is also close to zero, it is approximately 100 times larger than EPHEMSEC's code base 10 bias. A.1. Bias Formula For integers m and M where m ≤ M and m > 0, when sampling uniformly from [0, M) and taking remainder modulo m, remainder distribution may not be uniform. To quantify this non uniformity we can calculate a bias coefficient using: * bias = 0 when M % m = 0 * bias = 1/floor(M/m) when M % m ≠ 0 The bias value varies in [0,1] and indicates the relative overrepresentation of certain remainders. When bias = 0, distribution is uniform. Vieuille Expires 29 November 2025 [Page 24] Internet-Draft EPHEMSEC May 2025 A.1.1. Derivation Let X be a uniformly distributed random variable that generates integers in the range [0,M). Let R = X % m, where R is a random variable that maps X to the remainder of the division by m. We want to determine the probability distribution of R and quantify any bias that arises. Since X is uniformly distributed, the probability of X taking any specific value v in [0, M) is 1/M. Using the results from Lemma 1 below, we can determine the probability distribution of R. A.1.2. Case 1: When M is divisible by m (M % m = 0) From Lemma 1, each remainder r in [0, m) occurs exactly M/m times among the values [0, M). Therefore, R is uniformly distributed with: p(r) = (M/m) × (1/M) = 1/m for all r in [0, m) In this case, there is no bias since all remainders are equally likely. A.1.3. Case 2: When M is not divisible by m (M % m = s where 0 < s < m) From Lemma 1, the remainders have different frequencies: * Remainders r in [0, s) occur floor(M/m) + 1 times each * Remainders r in [s, m) occur floor(M/m) times each This leads to a non-uniform distribution: * p(r) = p1 = (floor(M/m) + 1)/M for r in [0, s) * p(r) = p2 = floor(M/m)/M for r in [s, m) A.1.4. Bias Quantification The bias arises because p1 > p2. We can express this relationship as: Vieuille Expires 29 November 2025 [Page 25] Internet-Draft EPHEMSEC May 2025 p1 = p2 × (1 + 1/floor(M/m)) = p2 × (1 + bias) where: bias = 1/floor(M/m) This bias factor measures the non-uniformity of the distribution: * bias = 0 when M is divisible by m (uniform case) * bias ∈ (0, 1] when M is not divisible by m, with larger values indicating greater non-uniformity * The bias is maximized when floor(M/m) = 1, giving bias = 1 A.2. Lemma 1: Distribution of Remainders in [0, M) Let m and M be integers where m ≤ M and m > 0. For any integer r in [0, m), the number of integers v in [0, M) that satisfy v % m = r is: 1. When M is divisible by m (M % m = 0): * Exactly M/m values for every r in [0, m) 2. When M is not divisible by m (M % m = s where 0 < s < m): * floor(M/m) + 1 values for r in [0, s) * floor(M/m) values for r in [s, m) A.2.1. Proof: For r in [0, m) let count(r) be the count of v satisfying v % m = r for v in [0, M) Any v, such that v % m = r can be written as v = q·m + r where q ≥ 0 To keep v in [0, M), we must have q ≤ (M - 1 - r)/m, hence count(r) = floor((M -1 - r)/m) + 1 When M = k·m (divisible case): - count(r) = floor((k·m - 1 - r)/m) + 1 = k = M/m When M = k·m + s (non-divisible case): - For r < s: count(r) = k + 1 - For r ≥ s: count(r) = k Vieuille Expires 29 November 2025 [Page 26] Internet-Draft EPHEMSEC May 2025 Appendix B. Design Rationale The EPHEMSEC algorithm has undergone several implementation iterations, initially starting by modifying the HOTP algorithm described in [RFC4226] to achieve the desired security properties. The following sections explain the rationale behind key design choices. B.1. Use of HKDF HKDF was chosen over the [RFC4226] HMAC approach for two reasons: 1. The HKDF domain separation feature enabled by the HKDF salt parameter (see Section 10.2) provides the necessary context binding used for phishing protection. 2. HKDF allows adjusting output size, which reduces the complexity of supporting the range of OTP/OTK sizes supported by EPHEMSEC (see Table 1). B.2. Usage of PSK The inclusion of a pre-shared key (PSK) ensures that generated OTP/ OTKs are always a *mutual* secret, which the E1S1 pattern (see Section 5.3.1) alone cannot guarantee. The incremental cost of mixing the PSK (see Section 6.1) into the HKDF ikm input (see Section 10.2) is expected to be low, and the PSK improves the secrecy of ikm. Therefore, it is always used even when the pattern (e.g., E1S2; see Section 5.3.2) already provides the desired *mutual* secrecy. B.3. Usage of Nonces The design requires that both the Initiator and Responder contribute a nonce and are responsible for ensuring that their respective nonces are not reused. During development, it was considered whether the Initiator nonce could serve dual purposes with the ephemeral public key contributed by the Initiator. However, after recognizing that all practical authentication server designs supporting EPHEMSEC require maintaining unique session identifiers, no attempt was made to evaluate whether removing the Initiator nonce could provide benefits. Vieuille Expires 29 November 2025 [Page 27] Internet-Draft EPHEMSEC May 2025 B.3.1. Transmission of the Responder Nonce When using OTP output, bandwidth between the Responder and the Initiator is severely constrained. Therefore, a synchronization digit SYNCHINT is used to "compress" the Responder nonce PTIME (see Section 8.2). When using OTK output, it is assumed that the application has addressed the bandwidth limitations that necessitate OTP output, and therefore PTIME could potentially be transmitted in uncompressed form. However, explicit support for uncompressed transmission was not included for two reasons: 1. The computational cost of running the synchronization algorithm to recover PTIME from SYNCHINT is very low. 2. Having the server rely on SYNCHINT to reconstruct PTIME limits the Responder's ability to reuse its own nonces, which provides additional security benefits. Author's Address Marc Vieuille Email: marc.vieuille@polytechnique.org Vieuille Expires 29 November 2025 [Page 28]