]> Inria

elsa.lopez-perez@inria.fr

Ericsson

goran.selander@ericsson.com

Ericsson

john.mattsson@ericsson.com

University of Murcia

rafa@um.es

University of Murcia

francisco.lopezg@um.es

Security LAKE Working Group This document specifies a Pre-Shared Key (PSK) authentication method for the Lightweight Authenticated Key Exchange (LAKE) protocol. The PSK method provides mutual authentication, ephemeral key exchange, identity protection, and quantum resistance while incurring lower computational costs than the public-key authentication methods specified for LAKE. It is suited for systems where nodes share a PSK provided out-of-band (external PSK) and enables efficient session resumption with less computational overhead when the PSK is provided from a previous LAKE session (resumption PSK). This document details the PSK message flow, key derivation changes, message formatting, processing, and security considerations. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the LAKE Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document defines LAKE-PSK, a Pre-Shared Key (PSK) authentication method for the Lightweight Authenticated Key Exchange (LAKE) protocol . The PSK method trades the complexity of symmetric-key distribution for improved computational efficiency. Although symmetric-key distribution is more complex than public-key credential distribution, PSK authentication requires less computation than the authentication methods defined in . The PSK method provides mutual authentication, ephemeral asymmetric key exchange, and identity protection. LAKE with PSK authentication benefits use cases where two nodes share a Pre-Shared Key (PSK) provided out-of-band (external PSK). Examples include the Authenticated Key Management Architecture (AKMA) in mobile systems or the Peer and Authenticator in Extensible Authentication Protocol (EAP) systems. The PSK method enables the nodes to perform ephemeral key exchange, achieving Perfect Forward Secrecy (PFS). This ensures that even if the PSK is compromised, past communications remain secure against active attackers, while future communications are protected against passive attackers. Additionally, by leveraging the PSK for both authentication and key derivation, the method provides quantum-resistant key exchange and authentication even when used with Elliptic Curve Diffie–Hellman Ephemeral (ECDHE). Another important use case of PSK authentication in the LAKE protocol is session resumption. This allows previously connected parties to quickly reestablish secure communication using pre-shared keys from a prior session, reducing the overhead associated with key exchange and asymmetric authentication. By using PSK authentication, LAKE allows session keys to be refreshed with significantly lower computational overhead compared to public-key authentication. In this case, the resumption PSK is provisioned after the establishment of a previous LAKE session by using EDHOC_Exporter (see ). Thus, the external PSK may serve as a long-term credential, while the resumption PSK is a short-lived credential derived from a previous LAKE session. provides an overview of the PSK method, including its message flow and associated credentials. outlines the changes to key derivation compared to . details message formatting and processing, and describes the usage of PSK for resumption. discusses the use of LAKE-PSK with EAP-EDHOC and defines the use of LAKE-PSK with Object Security for Constrained RESTful Environments (OSCORE, ). Security considerations are compiled in and outlines the IANA considerations.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts related to LAKE , Concise Binary Object Representation (CBOR) , CBOR Sequences , CBOR Object Signing and Encryption (COSE) Structures and Processing , COSE Algorithms , CBOR Web Token (CWT) and CWT Claims Set (CCS) , and the Concise Data Definition Language (CDDL) , which is used to express CBOR data structures. This document uses the acronym LAKE, expanded to Lightweight Authenticated Key Exchange, to denote the protocol specified as EDHOC in . LAKE is also used in place of EDHOC in descriptive terms such as LAKE message_1 or LAKE EAD item. Identifiers defined literally in or in IANA registries (e.g., EDHOC_Exporter, the EDHOC registries, media types, and URIs) are unchanged.

Protocol This document specifies a new LAKE authentication method (see ) referred to as the Pre-Shared Key method (LAKE-PSK). This method shares some features with, and differs in other respects from, the authentication methods previously defined in LAKE. Authentication is based on a PSK shared by the Initiator and the Responder. As in the methods defined in , CRED_I and CRED_R are authentication credentials containing identifying information for the Initiator and Responder, respectively. However, unlike those methods, LAKE-PSK uses a single authentication credential identifier, ID_CRED_PSK, which the Responder uses to retrieve the PSK and the associated authentication credentials. The PSK method uses a “by reference” approach for credential representation. ID_CRED_PSK can be kept minimal, enabling a very compact on-the-wire encoding. In contrast, defines that ID_CRED_I and ID_CRED_R may convey arbitrary identity and application-specific context. This separation allows LAKE-PSK to minimize overhead for PSK identification while preserving flexibility in both identity and contextual information, as well as the security properties associated with their use. Like the Internet Key Exchange Protocol Version 2 (IKEv2) , LAKE-PSK encrypts the PSK identifier ID_CRED_PSK, providing identity protection against passive attackers. In contrast, (D)TLS 1.3 transmits the PSK identifier in cleartext and therefore does not provide identity protection for PSK-based authentication.

Credentials The Initiator and Responder are assumed to share a PSK (an external PSK or a resumption PSK) with high entropy that meets the following requirements:

• Only the Initiator and the Responder have access to the PSK.
• The Responder can retrieve the PSK, CRED_I, and CRED_R, using ID_CRED_PSK.

ID_CRED_PSK ID_CRED_PSK is a key identifier formatted as a COSE header map containing header parameters that can be used to retrieve one or more pre-shared keys and associated information required for LAKE processing. Following the compact encoding rules defined in , an ID_CRED_PSK containing only a single 'kid' parameter is encoded directly as the value of that parameter. For example, the identifier is not encoded as the CBOR map 0xa10441ff but the CBOR byte string h'ff', i.e., 0x41ff. Another example, the identifier is neither the CBOR map 0xA1044110 nor the CBOR byte string h'10', i.e., 0x4110, but the CBOR integer 0x10, reducing message size. The purpose of ID_CRED_PSK is to facilitate retrieval of the PSK and associated information required for LAKE processing. While ID_CRED_PSK uses encoding and representation patterns from , it differs fundamentally in that it identifies a symmetric key rather than a public authentication key. A given ID_CRED_PSK value MAY correspond to more than one candidate PSK and associated information. In that case, all candidates associated with the value may need to be checked. It is RECOMMENDED that ID_CRED_PSK uniquely or stochastically identifies the corresponding PSK context. Uniqueness avoids ambiguity that could require the recipient to try multiple candidate PSKs and associated information, while stochasticity reduces the risk of identifier collisions and supports stateless processing. These properties align with the requirements for rKID in session resumption (see ).

CRED_I and CRED_R CRED_I and CRED_R are authentication credentials associated with the PSK. The notation CRED_x refers to either CRED_I or CRED_R. Authentication is achieved implicitly through successful possession and use of the PSK in the derivation and verification of protected cryptographic material. When using an external PSK, a common representation of CRED_I and CRED_R is a CWT or CCS , where the 'cnf' claim includes the confirmation method COSE_Key. An example of CRED_I and CRED_R is shown below: Alternative formats for CRED_I and CRED_R MAY be used. When a resumption PSK is employed, CRED_I and CRED_R MUST be the same credentials used in the initial LAKE exchange, for example, public-key credentials such as X.509 certificates . Implementations MUST ensure that CRED_I and CRED_R are distinct, for example by including different identities in their 'sub' claims (e.g., "42-50-31-FF-EF-37-32-39" and "23-11-58-AA-B3-7F-10"). Ensuring distinct credentials simplifies correct party identification and prevents reflection and misbinding attacks, as described in .

Encoding and Processing Guidelines The following guidelines apply to the encoding and handling of CRED_x and ID_CRED_PSK. Requirements on CRED_x apply both to CRED_I and to CRED_R.

• If CRED_x is CBOR-encoded, it SHOULD use deterministic encoding as specified in Sections and of . Deterministic encoding ensures consistent identification and avoids interoperability issues caused by non-deterministic CBOR variants.
• If CRED_x is provisioned out-of-band and transported by value, it SHOULD be used as received without re-encoding. Re-encoding can cause mismatches when comparing identifiers such as hash values or 'kid' references.
• When ID_CRED_PSK consists solely of a 'kid' parameter (i.e., { 4 : kid }), the compact encoding optimization defined in MUST be applied in plaintext fields (such as PLAINTEXT_3A). These optimizations MUST NOT be applied in COSE header parameters or in other contexts where the full map structure is required. For example, in such cases where these optimizations are not applied:
  • { 4 : h'ff' } is encoded as 0xa10441ff, instead of 0x41ff (CBOR encoding of the CBOR byte string h'ff')
  • { 4 : h'15' } is encoded as 0xa1044115, instead of 0x15 (CBOR encoding of the CBOR integer 21)
• To prevent misbinding attacks, identity information such as a 'sub' (subject) claim MUST be included in both CRED_I and CRED_R.
• Claims such as 'iss' (issuer), 'aud' (audience), 'scope', 'exp' (expiration time), 'nbf' (not before), and 'cti' (CWT ID) MAY be used to convey context information for a pre-shared key (PSK), including aspects of its provenance, intended use, and validity period. This aligns with the notion of “context” in .

Message Flow of LAKE-PSK The message flow of LAKE-PSK follows the structure defined in , with authentication based on symmetric keys rather than public keys. For identity protection, credential-related message fields appear first in message_3. ID_CRED_PSK is encrypted using a key derived from a shared secret obtained through the first two messages. If Diffie-Hellman key exchange is used, G_X and G_Y are the ephemeral public keys, and the shared secret G_XY is the DH shared secret, as in . If the Diffie-Hellman procedure is replaced by a KEM (e.g., ), then G_X and G_Y are encapsulation key and ciphertext, respectively, and the shared secret G_XY is derived by the KEM. The Responder authenticates the Initiator first. illustrates the message flow of the LAKE-PSK authentication method.

Overview of Message Flow of LAKE-PSK. | | message_1 | | | | G_Y, Enc( C_R, EAD_2 ) | |<------------------------------------------------------------------+ | message_2 | | | | Enc( ID_CRED_PSK, AEAD( EAD_3 ) ) | +------------------------------------------------------------------>| | message_3 | | | | AEAD( EAD_4 ) | |<------------------------------------------------------------------+ | message_4 | ]]>

This approach provides identity protection against passive attackers for both Initiator and Responder. LAKE message_4 remains OPTIONAL, but is needed to authenticate the Responder and achieve mutual authentication in LAKE when external applications using secure communication (e.g., with OSCORE) are not relied upon. In either case, the inclusion of a fourth message provides mutual authentication and explicit key confirmation (see ).

Key Derivation The pseudorandom keys (PRKs) used in the LAKE-PSK authentication method are derived with EDHOC_Extract, as in . where salt and input keying material (IKM) are defined for each key. The definition of EDHOC_Extract depends on the LAKE hash algorithm of the selected cipher suite, see . To maintain a uniform key schedule across all LAKE authentication methods, the same pseudorandom key notation (PRK_2e, PRK_3e2m, and PRK_4e3m) is retained. The index notation is preserved for consistency with other LAKE authentication variants, even though it does not fully reflect the functional role of the keys in this method; for example, no MACs are used in LAKE-PSK. PRK_2e is extracted as in with

• salt = TH_2, and
• IKM = G_XY,

where the transcript hash TH_2 = H( G_Y, H(message_1) ) is defined in . SALT_4e3m is derived from PRK_3e2m and TH_3, as shown in Figure 6 of . The other PRKs and transcript hashes are modified as specified below. lists the key derivations that differ from what is defined in Sections and of .

Key Derivation of LAKE-PSK.

where:

• KEYSTREAM_2A is used to encrypt PLAINTEXT_2A in message_2.
  • plaintext_length_2a is the length of PLAINTEXT_2A in message_2.
• KEYSTREAM_3A is used to encrypt PLAINTEXT_3A (the concatenation of ID_CRED_PSK and CIPHERTEXT_3B) in message_3.
  • plaintext_length_3a is the length of PLAINTEXT_3A in message_3.
• TH_3 = H( TH_2, PLAINTEXT_2A ).

The definition of the transcript hash TH_4 is modified as follows:

• TH_4 = H( TH_3, ID_CRED_PSK, PLAINTEXT_3B, CRED_I, CRED_R )

Message Formatting and Processing This section specifies the differences in message formatting and processing compared to . Note that, if any processing step fails, then the message recipient MUST send an LAKE error message back as defined in and the LAKE session MUST be aborted.

Message 1 Message 1 is formatted and processed as specified in , with the METHOD field set to the LAKE-PSK method (i.e., the value registered in ).

Message 2

Formatting of Message 2 Message 2 is formatted as specified in , except that CIPHERTEXT_2 is replaced by CIPHERTEXT_2A.

Responder Composition of Message 2 CIPHERTEXT_2A is calculated with a binary additive stream cipher, using a keystream generated with EDHOC_Expand and the following plaintext:

• PLAINTEXT_2A = ( C_R, ? EAD_2 )
• CIPHERTEXT_2A = PLAINTEXT_2A XOR KEYSTREAM_2A

C_R and EAD_2 are defined in . In contrast to , ID_CRED_R, MAC_2, and Signature_or_MAC_2 are not included in message_2. This omission is the primary difference from the signature and MAC-based authentication methods defined in , as authentication in LAKE-PSK relies solely on the shared PSK and the successful decryption of protected messages. KEYSTREAM_2A is defined in .

Initiator Processing of Message 2 Upon receiving message_2, the Initiator processes it as follows:

• Compute KEYSTREAM_2A as defined in .
• Decrypt CIPHERTEXT_2A using binary XOR, i.e., PLAINTEXT_2A = CIPHERTEXT_2A XOR KEYSTREAM_2A

In contrast to , ID_CRED_R is not made available to the application in step 4, and steps 5 and 6 are skipped.

Message 3

Formatting of Message 3 Message 3 is formatted as specified in , except that CIPHERTEXT_3 is replaced by CIPHERTEXT_3A.

Initiator Composition of Message 3

• CIPHERTEXT_3A is computed using a binary additive stream cipher with a keystream generated by EDHOC_Expand, applied to the following plaintext:
  • PLAINTEXT_3A = ( ID_CRED_PSK / bstr / -24..23, CIPHERTEXT_3B )
    • If ID_CRED_PSK contains a single 'kid' parameter, i.e., ID_CRED_PSK = { 4 : kid_PSK }, then the compact encoding is applied, see .
    • For the case of plaintext_length_2a or plaintext_length_3a exceeding the EDHOC_KDF output size, see .
  • Compute KEYSTREAM_3A as in .
  • CIPHERTEXT_3A = PLAINTEXT_3A XOR KEYSTREAM_3A
• CIPHERTEXT_3B is the 'ciphertext' of the COSE_Encrypt0 object as defined in Sections and of , computed with the LAKE AEAD algorithm of the selected cipher suite, using the encryption key K_3, the initialization vector IV_3 (if used by the AEAD algorithm), the parameters described in , plaintext PLAINTEXT_3B and the following parameters as input:
  • protected = h''
  • external_aad = << ID_CRED_PSK, TH_3, CRED_I, CRED_R >>
  • K_3 and IV_3 as defined in
  • PLAINTEXT_3B = ( ? EAD_3 )

The Initiator computes TH_4 as defined in . There is no need for MAC_3 or signature, since AEAD's built-in integrity and the use of PSK-based key derivation provide implicit authentication of the Initiator.

Responder Processing of Message 3 Upon receiving message_3, the Responder proceeds as follows:

• Generate KEYSTREAM_3A with the same method the Initiator used.
• Decrypt CIPHERTEXT_3A using binary XOR with KEYSTREAM_3A to recover PLAINTEXT_3A.
• Parse the structure of PLAINTEXT_3A = ( ID_CRED_PSK, CIPHERTEXT_3B ), where CIPHERTEXT_3B is the inner AEAD-encrypted object.
• Use ID_CRED_PSK to identify the authentication credentials and retrieve PSK, CRED_I, and CRED_R.
• Select a candidate tuple (PSK, CRED_I, CRED_R).
• Derive K_3 and IV_3 as defined in .
• AEAD-decrypt CIPHERTEXT_3B using:
  • K_3, IV_3
  • external_aad = << ID_CRED_PSK, TH_3, CRED_I, CRED_R >>
  • protected = h''
  • LAKE AEAD algorithm of the selected cipher suite.

If AEAD verification fails, retry with a new candidate tuple. If all candidate authentication credential sets fail, this indicates a processing problem or that the message was tampered with. If it succeeds, the Responder concludes that the Initiator possesses the PSK, correctly derived TH_3, and is actively participating in the protocol. Finally, the Responder computes TH_4 as defined in . No MAC_3 or signature is needed, as the AEAD ciphertext guarantees both integrity and authenticity in this symmetric setting.

Message 4 Message 4 is formatted and processed as specified in . After successfully verifying message_4, or another fourth message from the Responder protected with an exported application key such as an OSCORE-protected message, the Initiator is assured that the Responder has derived PRK_out (key confirmation) and that no other party can derive this key. The Initiator MUST NOT persistently store PRK_out or application keys until it has successfully verified such a fourth message and the application has authenticated the Responder. Compared to , the fourth message not only provides key confirmation but also authenticates the Responder. For mutual authentication a fourth message is therefore mandatory.

PSK Usage for Session Resumption This section specifies how LAKE-PSK is used for session resumption in LAKE. The EDHOC_Exporter, as defined in , is used to derive the resumption parameters rPSK and rKID:

Resumption Parameters.

where:

• hash_length is the output size of the LAKE hash algorithm associated with the PSK, i.e., the LAKE hash algorithm of the selected cipher suite used in the LAKE session in which the resumption PSK is established.
• kid_length defaults to 2 bytes.

A peer that has successfully completed an LAKE session, regardless of the authentication method used or whether the session was a PSK resumption, MAY generate a resumption key. Whether resumption keys are generated is determined by the application profile, see . Support for resumption can be indicated, for example, by using means defined in . To ensure both peers share the same resumption key, when a resumption session is run using rPSK_i as the resumption key:

• The Responder MAY delete the previous resumption key rPSK_(i-1), if present, after successfully verifying message_3. At that point the Responder can be certain that the Initiator has access to the current resumption key rPSK_i.
• The Initiator MAY delete rPSK_i after successfully verifying the fourth message. At that point, the Initiator can be certain that the Responder is able to derive the next resumption key, rPSK_(i+1), if the Responder wants to.
• The Responder MAY delete rPSK_i after successfully verifying a fifth message from the Initiator protected with an exported application key such as an OSCORE-protected message, if present. At that point, the Responder can be certain that the Initiator is able to derive the next resumption key, rPSK_(i+1), if the Initiator wants to.

When resumption PSKs are used and public keys were used in the original session for non-resumption authentication, implementations MUST retain ID_CRED_I, ID_CRED_R, and LAKE hash algorithm used in that original session and associate them with the current resumption PSK. Implementations MAY retain an external ID_CRED_PSK and associated PSK to allow fallback if resumption fails. If fallback authentication uses an external PSK, the Initiator selects which PSK to use and indicates it via ID_CRED_PSK. If a credential associated with a resumption key expires, implementations SHOULD retry either with an external PSK or a different authentication method. How long the original authentication credentials are retained is determined by the application profile or by the expiration time of the credential (e.g., the 'exp' claim in a CWT). Key lifetime, retention, and retry policy are determined by the application profile.

LAKE-PSK and Extensible Authentication Protocol (EAP) LAKE with PSK authentication has several important use cases within the Extensible Authentication Protocol (EAP). One use case is the resumption of a session established with the EAP method EAP-EDHOC , regardless of the LAKE-based authentication method originally used in that session. This is similar to the resumption mechanism in EAP-TLS 1.3 . Resumption reduces the number of round trips and allows the EAP-EDHOC server to avoid database lookups that might be required during an initial handshake. If the server accepts resumption, the resumed session is considered authenticated and securely bound to the prior authentication or resumption. The use of resumption with EAP-EDHOC is optional for the peer, but it is RECOMMENDED whenever a valid rPSK is available. On the server side, resumption acceptance is also optional, but it is RECOMMENDED if the rPSK remains valid. The server MAY, however, require a new initial handshake by refusing resumption. It is further RECOMMENDED to use Network Access Identifiers (NAIs) with the same realm in the EAP identity response during both the full handshake and resumption. For example, the NAI @realm can safely be reused since it does not expose information that links a user’s resumption attempt with the original full handshake. EAP-EDHOC using PSK authentication also provides a significant improvement over EAP-PSK , which lacks support for identity protection, cryptographic agility, and ephemeral key exchange, now considered essential for meeting current security requirements. Without perfect forward secrecy, compromise of the PSK enables a passive attacker to decrypt both past and future sessions. Note that PSK authentication is not allowed in EAP-TLS .

LAKE-PSK and OSCORE describes an optimized use of LAKE with OSCORE by combining LAKE message_3 with the first OSCORE-protected request. This procedure omits message_4, but key confirmation of the Responder is provided by a subsequent OSCORE-protected response to the Initiator. In LAKE-PSK, authentication of the Responder is provided by message_4 or another fourth message. Hence, the combined delivery described in can be applied to LAKE-PSK. Note that, in this case, the Responder is not authenticated until the Initiator has verified a matching OSCORE-protected response. However, only the party with the correct PSK can decrypt the OSCORE-protected request.

Security Considerations The LAKE-PSK authentication method introduces deviations from the initial specification of LAKE . This section analyzes the security implications of these changes and discusses the security properties of LAKE authenticated with a PSK.

Identity Protection In LAKE-PSK, the identifier ID_CRED_PSK in message_3 is encrypted with a keystream derived from the ephemeral shared secret G_XY. This provides identity protection of both the Initiator and Responder against passive attackers. This contrasts with the asymmetric authentication methods discussed in , which protect the Initiator’s identity against active attackers and the Responder’s identity against passive ones. LAKE-PSK does not protect the PSK identifier against active attackers as an attacker impersonating the Responder can decrypt ID_CRED_PSK. The time to lookup or process an authentication credential based on ID_CRED_PSK may leak information about the identity.

Protection of Pre-Shared Keys The security of LAKE-PSK depends on the confidentiality of the PSK. Unlike an asymmetric private key, which can be generated and remain within a Hardware Security Module (HSM), secure element, or other protected cryptographic boundary, a PSK must be provisioned to and stored by multiple parties. This generally increases the attack surface and the risk of key compromise.

Mutual Authentication LAKE-PSK provides mutual authentication and explicit key confirmation through an additional message that demonstrates possession of the PSK. This may be message_4 or an application message (e.g., an OSCORE-protected message) protected with a key derived from LAKE. To mitigate reflection or Selfie attacks, the identities in CRED_I and CRED_R MUST be distinct. If identical credentials are used by both parties, an endpoint may incorrectly accept messages that originate from itself. LAKE-PSK is not resistant to Key Compromise Impersonation (KCI) attacks. Compromise of the PSK enables an attacker to impersonate either the Initiator or the Responder to the other party. While compromise of the ephemeral shared secret G_XY only affects the specific session in which it is used, compromise of the PSK allows full active impersonation in all future sessions that rely on the compromised key.

Protection of External Authorization Data (EAD) As in , LAKE-PSK ensures the confidentiality and integrity of External Authorization Data (EAD). The security guarantees for EAD fields remain unchanged from the original EDHOC specification.

Cryptographic Strength Each external PSK MUST be derived from at least 128 bits of entropy and MUST be at least 128 bits long. Deriving a shared secret from a password or other low-entropy sources is not secure. The cryptographic strength of LAKE-PSK depends on the selected cipher suite. For the currently defined cipher suites (0–6 and 24–25), LAKE-PSK provides at least 128-bit security against offline brute-force attacks and at least 64-bit security against online forgery attacks. In practical terms, mounting a successful online forgery attack at this security level would require an adversary, on average, to transmit 4.3 billion messages per second for 68 years, which is infeasible in constrained IoT radio environments. A successful forgery in LAKE-PSK breaks the security of all future application data derived from the session, while a forgery in the subsequent application protocol (e.g., OSCORE ) typically only breaks the security of the forged packet. Similar to TLS 1.3 , LAKE-PSK takes a conservative approach to PSK usage by binding each PSK to a specific KDF through an associated hash algorithm. A PSK MUST only be used with cipher suites that employ the same hash algorithm. For externally provisioned PSKs, the hash algorithm MUST be provisioned together with the PSK. For resumption PSKs, the hash algorithm is the LAKE hash algorithm of the selected cipher suite in the LAKE session in which the resumption PSK was established, see . The Responder MUST abort the ongoing LAKE session, if the PSK retrieved through ID_CRED_PSK is combined with a hash algorithm different from the one in the selected cipher suite used in the session.

Downgrade Protection Following , LAKE-PSK must support cryptographic agility, including modularity and negotiation of preferred cryptographic primitives. In message_1, the Initiator sends an ordered list of supported cipher suites (SUITES_I). The Responder verifies that the suite selected by the Initiator is the most preferred option in SUITES_I that is mutually supported. If this condition is not met, the Responder MUST abort the session.

Post Quantum Considerations Advances in quantum computing suggest that a Cryptographically Relevant Quantum Computer (CRQC) may eventually be realized. Such a machine would render many asymmetric algorithms, including Elliptic Curve Diffie-Hellman (ECDH), insecure. Quantum resistance of LAKE-PSK partly depends on the selected LAKE cipher suite. LAKE-PSK derives authentication and session keys primarily from a symmetric PSK, which provides quantum resistance even when combined with ECDHE. However, if a CRQC is realized, the ECDHE contribution degenerates to providing only randomness. In that case, LAKE-PSK with ECDHE offers neither identity protection nor Perfect Forward Secrecy (PFS) against quantum adversaries. Moreover, if the PSK is compromised, a passive quantum attacker could decrypt both past and future sessions. By contrast, combining LAKE-PSK with a quantum-resistant Key Encapsulation Mechanism (KEM), such as ML-KEM , ensures both identity protection and PFS even against quantum-capable attackers. Future LAKE cipher suites incorporating ML-KEM are expected to be registered; see .

Confidentiality The primary security goal of LAKE-PSK is to establish a shared secret known only to the authenticated Initiator and Responder. The protocol ensures key indistinguishability by relying on the security of the PSK and the ephemeral key shares, making it computationally infeasible for an adversary to distinguish the true session secret from a random value.

Independence of Session Keys NIST requires that an ephemeral private key be used in only one key-establishment transaction (, Section 5.6.3.3). This requirement preserves session key independence and forward secrecy, and LAKE-PSK complies with it. By deriving the final shared secret from a fresh, session-specific ephemeral secret (G_XY), the protocol ensures that even if the PSK is compromised, an attacker is unable to decrypt the past sessions. Similarly, if a session secret were to be compromised, future session secrets remain protected by fresh ephemeral keys. In other protocols, reuse of ephemeral keys, especially when combined with missing public key validation, has led to severe vulnerabilities, enabling attackers to recover “ephemeral” private keys and compromise both past and future sessions between two legitimate parties. Acknowledging the possibility of a breach and minimizing the impact of compromise are fundamental principles of zero-trust security.

Message 4 and Mutual Authentication Requirements For use cases where application data is transmitted, it can be sent together with message_3, maintaining efficiency. In applications such as EAP-EDHOC , where no application data is exchanged between Initiator and Responder, message_4 is mandatory. In such cases, LAKE-PSK does not increase the total number of messages compared to the methods defined in . Other implementations may replace message_4 with a protected application message. In general, the following requirement applies: The Initiator SHALL NOT persistently store PRK_out or derived application keys until it has successfully verified message_4 or a message protected with an exported application key (e.g., an OSCORE-protected message). This ensures that key material is stored only after its authenticity is confirmed. Finally, the order of authentication (i.e., whether the Initiator or the Responder authenticates first) is not relevant in LAKE-PSK. While this ordering affects privacy properties in the asymmetric methods of , it has no significant impact in LAKE-PSK.

Post-Compromise Security When LAKE-PSK is used for session resumption, the protocol provides Post-Compromise Security (PCS) for the resumption key chain. PCS means that even if a resumption PSK rPSK_i is compromised, security is restored in subsequent sessions provided the attacker cannot compromise the ephemeral keys of every such session. Specifically, rPSK_(i+1) is derived via EDHOC_Exporter from PRK_out, which incorporates fresh ephemeral keying material (G_XY). An attacker who has obtained rPSK_i cannot derive rPSK_(i+1) without also compromising the ephemeral keys. A passive attacker therefore loses any advantage once the next session completes with uncompromised ephemerals. This property applies only when resumption is used and new resumption keys are derived for each session. It does not apply when a long-lived external PSK is reused directly across sessions without key rotation. In that case, as noted in , compromise of the PSK enables an attacker to compromise the confidentiality and authentication of future sessions until the PSK is replaced.

Privacy Considerations for Resumption When using resumption PSKs:

• ID_CRED_PSK is not exposed to passive attackers, and it is not reused under normal operation. Reuse of the same ID_CRED_PSK can occur due to transmission errors or when a peer loses its stored resumption key. An active attacker can obtain the value of ID_CRED_PSK and force its reuse. This aligns with the security goals of LAKE-PSK, which are to provide identity protection against passive attackers, but not against active attackers.

Security Considerations for Resumption

• Resumption PSKs MUST NOT be used for purposes other than LAKE session resumption.
• Resumption PSKs MUST be securely stored with the same level of protection as the session keys.
• Parties SHOULD avoid excessive reuse of the same resumption PSK.
• The optional external PSK and the resumption PSKs form a key ratchet. If previous PSKs have been securely erased, compromise of the current resumption PSK does not enable recovery of earlier PSKs. This property holds regardless of whether ECDHE or a post-quantum key exchange is used. Handling of external and resumption PSKs can be specified in the application profile.

IANA Considerations This document requires the following IANA actions.

EDHOC Method Types Registry IANA is requested to register the following entry in the "EDHOC Method Types" registry within the registry group "Ephemeral Diffie-Hellman Over COSE (EDHOC)". Addition to the EDHOC Method Types Registry.

Value	Initiator Authentication Key	Responder Authentication Key	Reference
TBD4	PSK	PSK	this document

NOTE: Suggested value: TBD4 = 4. RFC Editor: Remove this note.

EDHOC Exporter Labels Registry IANA is requested to register the following entry in the "EDHOC Exporter Labels" registry within the registry group "Ephemeral Diffie-Hellman Over COSE (EDHOC)". Additions to the EDHOC Exporter Labels Registry.

Label	Description	Change Controller	Reference
TBD2	Resumption PSK	IETF	this document
TBD3	Resumption kid	IETF	this document

NOTE: Suggested values: TBD2 = 2, TBD3 = 3. RFC Editor: Remove this note.

References Normative References CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. University of Oviedo University of Murcia Ericsson Ericsson University of Murcia The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP- EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC is a lightweight security handshake protocol, enabling authentication and establishment of shared secret keys suitable in constrained settings. This document also provides guidance on authentication and authorization for EAP-EDHOC. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document specifies EAP-PSK, an Extensible Authentication Protocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11. This memo defines an Experimental Protocol for the Internet community. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. RISE AB RISE AB The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Furthermore, in order to facilitate interoperability between EDHOC implementations and support EDHOC extensibility for additional integrations, this document defines a number of means to coordinate the use of EDHOC application profiles. Finally, this document defines a set of well- known EDHOC application profiles. Ericsson Ericsson Limoges University The Lightweight Authenticated Key Exchange (LAKE) protocol, formerly known as Ephemeral Diffie-Hellman over COSE (EDHOC), as originally specified in RFC 9528, relies on Elliptic Curve Cryptography (ECC) for key exchange and authentication. This document specifies how the LAKE protocol operates in a post-quantum setting by defining new cipher suites using quantum-resistant algorithms, such as ML-DSA for digital signatures and ML-KEM for key exchange. This document also updates RFC 9528 by changing the name of the protocol from EDHOC to LAKE and updating the EDHOC Method Types and Cipher Suites registries to add columns indicating, respectively, whether a method requires and whether a cipher suite supports Diffie-Hellman or Non-Interactive Key Exchange (NIKE) primitives. This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document describes an interface for importing external Pre-Shared Keys (PSKs) into TLS 1.3.

CDDL Definitions This section compiles the CDDL definitions for convenience, incorporating errata filed against .

Test Vectors

message_1 Both endpoints are authenticated with Pre-Shared Keys (METHOD = 4) NOTE: Assuming TBD4 = 4, to be confirmed by IANA. RFC Editor: Remove this note. The initiator selects cipher suite 02. A single cipher suite is encoded as an int: The Initiator creates an ephemeral key pair for use with the LAKE key exchange algorithm: The Initiator selects its connection identifier C_I to be the byte string 0xA, which is encoded as 0xA since it is represented by the 1-byte CBOR int 10: No external authorization data The Initiator constructs message_1:

message_2 The Responder supports the most preferred and selected cipher suite 02, so SUITES_I is acceptable. The Responder creates an ephemeral key pair for use with the LAKE key exchange algorithm: The Responder selects its connection identifier C_R to be the byte string 0x05, which is encoded as 0x05 since it is represented by the 1-byte CBOR int 05: The transcript hash TH_2 is calculated using the LAKE hash algorithm: TH_2 = H( G_Y, H(message_1) ), where H(message_1) is: PRK_2e is specified in . To compute it, the Elliptic Curve Diffie-Hellman (ECDH) shared secret G_XY is needed. It is computed from G_X and Y or G_Y and X: Then, PRK_2e is calculated as defined in Since the Responder authenticates using PSK, PRK_3e2m = PRK_2e. No external authorization data: The Responder constructs PLAINTEXT_2A: The Responder computes KEYSTREAM_2A as defined in The Responder calculates CIPHERTEXT_2A as XOR between PLAINTEXT_2A and KEYSTREAM_2A: The Responder constructs message_2 as defined in :

message_3 The Initiator computes PRK_4e3m, as described in , using SALT_4e3m and PSK: The transcript hash TH_3 is calculated using the LAKE hash algorithm: TH_3 = H( TH_2, PLAINTEXT_2A ) No external authorization data: The Initiator constructs firstly PLAINTEXT_3B as defined in : It then computes CIPHERTEXT_3B as defined in . It uses ID_CRED_PSK, CRED_I, CRED_R and TH_3 as external_aad: The Initiator computes K_3 and IV_3 It then computes CIPHERTEXT_3B: The Initiator computes KEYSTREAM_3A as defined in : It then calculates PLAINTEXT_3A as stated in : It then uses KEYSTREAM_3A to derive CIPHERTEXT_3A: The Initiator computes message_3 as defined in : The transcript hash TH_4 is calculated using the LAKE hash algorithm: TH_4 = H( TH_3, ID_CRED_PSK, ? EAD_3, CRED_I, CRED_R )

message_4 No external authorization data: The Responder constructs PLAINTEXT_4: The Responder computes K_4 and IV_4: The Responder computes message_4:

PRK_out and PRK_exporter After the exchange, the following PRK_out and PRK_exporter are derived by both entities:

rPSK and rKID Both peers generate a resumption key for use in the next resumption attempt, as explained in : NOTE: Assuming TBD2 = 2 and TBD3 = 3, to be confirmed by IANA. RFC Editor: Remove this note.

Change Log RFC Editor: Please remove this appendix.

• From -09 to -10
  • Addressed shepherd review comments
  • Renamed EDHOC-PSK to LAKE-PSK and added terminology note on the use of LAKE vs. EDHOC
  • Clarified METHOD value in message_1 and the processing of message_3 (candidate tuples)
  • Clarified ID_CRED_PSK compact encoding with examples
  • Updated IANA considerations to match registry names
  • Updated references (RFC 8152 -> RFC 9052, RFC 8446 -> RFC 9846, I-D.ietf-lake-pqsuites, added FIPS 203 and RFC 5280)
  • Editorial changes
• From -08 to -09
  • Clarified that ID_CRED_PSK may identify more than one candidate PSK and updated message_3 processing accordingly
  • Fixed compact encoding examples of ID_CRED_PSK
  • Resumption: original credentials and hash algorithm MUST be retained; clarified hash_length
  • Fixed conditions for deleting rPSK_i
  • Clarified combined delivery with OSCORE (RFC 9668)
  • Fixed test vectors
  • Editorial changes
• From -07 to -08
  • Added clarification after formal analysis.
  • Added comparisons of identity protection with other protocols
  • Added requirements (single KDF) and considerations (context) based on TLS 1.3
  • Updated considerations regarding OSCORE and RFC 9668
  • Added considerations for protection of pre-shared keys
  • Added considerations for key chains / key ratchets
  • Added text on explaining the "by reference" benefits of ID_CRED_PSK
  • Editorial changes
• From -06 to -07
  • Fixed test vectors
  • Updated security considerations after formal analysis
  • Editorial changes
• From -05 to -06
  • Editorial changes
• From -04 to -05
  • Fixed misbinding attacks and resumption
  • Updated privacy considerations
  • Added EDHOC-PSK and EAP section
  • Editorial changes
  • Fixed test vectors
• From -03 to -04
  • Test Vectors
  • Editorial changes
• From -02 to -03
  • Updated abstract and Introduction
  • Changed message_3 to hide the identity length from passive attackers
  • CDDL Definitions
  • Security considerations of independence of Session Keys
  • Editorial changes
• From -01 to -02
  • Changes to message_3 formatting and processing
• From -00 to -01
  • Editorial changes and corrections

Acknowledgments The authors want to thank , , , , , , and for reviewing and commenting on intermediate versions of the draft. This work has been partly funded by PID2023-148104OB-C43 funded by MICIU/AEI/10.13039/501100011033 (ONOFRE4), FEDER/UE EU HE CASTOR under Grant Agreement No 101167904 and EU CERTIFY under Grant Agreement No 101069471. This work was supported partially by Vinnova - the Swedish Agency for Innovation Systems - through the EUREKA CELTIC-NEXT project CYPRESS. This work has been partially supported by the French National Research Agency under the France 2030 label (NF-HiSec ANR-22-PEFT-0009).