| Internet-Draft | EDHOC-PSK | August 2025 |
| Lopez-Perez, et al. | Expires 21 February 2026 | [Page] |
This document specifies a Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange protocol. The PSK method enhances computational efficiency while providing mutual authentication, ephemeral key exchange, identity protection, and quantum resistance. It is particularly 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 EDHOC session (resumption PSK). This document details the PSK method flow, key derivation changes, message formatting, processing, and security considerations.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://lake-wg.github.io/psk/#go.draft-ietf-lake-edhoc-psk.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc-psk/.¶
Discussion of this document takes place on the LAKE Working Group mailing list (mailto:lake@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/lake/. Subscribe at https://www.ietf.org/mailman/listinfo/lake/.¶
Source for this draft and an issue tracker can be found at https://github.com/lake-wg/psk.¶
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 21 February 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document defines a Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange protocol [RFC9528]. The PSK method balances the complexity of credential distribution with computational efficiency. While symmetric key distribution is more complex than asymmetric approaches, PSK authentication offers greater computational efficiency compared to the methods outlined in [RFC9528]. The PSK method retains mutual authentication, asymmetric ephemeral key exchange, and identity protection established by [RFC9528].¶
EDHOC 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 ECDHE.¶
Another important use case of PSK authentication in the EDHOC 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, EDHOC 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 EDHOC session by using EDHOC_Exporter. Thus, the external PSK serves as a long-term credential while the resumption PSK acts as a session key.¶
Section 3 provides an overview of the PSK method flow and credentials. Section 4 outlines the changes to key derivation compared to [RFC9528]. Section 5 details message formatting and processing, and Section 6 describes the usage of PSK for resumption. Section 7 defines the use of EDHOC-PSK with OSCORE. Security considerations are described in Section 8, and Section 9 outlines the IANA considerations.¶
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.¶
Readers are expected to be familiar with the terms and concepts described in EDHOC [RFC9528], CBOR [RFC8949], CBOR Sequences [RFC8742], COSE Structures and Processing [RFC9052], COSE Algorithms [RFC9053], CWT and CCS [RFC8392], and the Concise Data Definition Language (CDDL) [RFC8610], which is used to express CBOR data structures.¶
This document specifies a new EDHOC authentication method (see Section 3.2 of [RFC9528]) referred to as the Pre-Shared Key method (EDHOC-PSK). This method shares some features with, and differs in other respects from, the authentication methods previously defined in EDHOC.¶
Authentication is based on a Pre-Shared Key (PSK) shared between the Initiator and the Responder. As in the methods defined in [RFC9528], CRED_I and CRED_R are authentication credentials containing identifying information for the Initiator and Responder, respectively. However, unlike those methods, there is a single shared authentication credential identifier, ID_CRED_PSK, which the Responder uses to retrieve the PSK and the associated authentication credentials.¶
The Initiator and Responder are assumed to share a PSK (either 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 is a COSE header map containing header parameters that can identify a pre-shared key. For example:¶
ID_CRED_PSK = {4 : h'0f' }; 4 = 'kid'
¶
The purpose of ID_CRED_PSK is to facilitate retrieval of the correct PSK. While ID_CRED_PSK use encoding and representation patterns from [RFC9528], it differs fundamentally in that it identifies a symmetric key rather than a public authentication key.¶
It is RECOMMENDED that ID_CRED_PSK uniquely or stochastically identifies the corresponding PSK. Uniqueness avoids ambiguity that could require the recipient to try multiple keys, while stochasticity reduces the risk of identifier collisions and supports stateless processing. These properties align with the requirements for rKID in session resumption.¶
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 the successful use of the PSK to derive keying material, and to encrypt and subsequently decrypt protected messages.¶
When using an external PSK, a common representation of CRED_I and CRED_R is a CBOR Web Token (CWT) or CWT Claims Set (CCS) [RFC8392], where the 'cnf' claim includes the confirmation method COSE_Key. An example of CRED_I and CRED_R is shown below:¶
{ /CCS/
2 : "42-50-31-FF-EF-37-32-39", /sub/
8 : { /cnf/
1 : { /COSE_Key/
1 : 4, /kty/
2 : h'0f', /kid/
}
}
}
¶
{ /CCS/
2 : "23-11-58-AA-B3-7F-10", /sub/
8 : { /cnf/
1 : { /COSE_Key/
1 : 4, /kty/
2 : h'0f', /kid/
}
}
}
¶
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 EDHOC 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 Appendix D.2 of [RFC9528].¶
The following guidelines apply to the encoding and handling of CRED_x and ID_CRED_PSK. Requirements on CRED_x applies both to CRED_I and to CRED_R.¶
If CRED_x is CBOR-encoded, it SHOULD use deterministic encoding as specified in Sections 4.2.1 and 4.2.2. of [RFC8949]. 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.¶
ID_CRED_PSK SHOULD uniquely identify the corresponding PSK to avoid ambiguity. When ID_CRED_PSK contains a key identifier, care must be taken to ensure that 'kid' is unique for the PSK.¶
When ID_CRED_PSK consists solely of a 'kid' parameter (i.e., { 4 : kid }), the compact encoding optimization defined in Section 3.5.3.2 of [RFC9528] MUST be applied in plaintext fields (such as PLAINTEXT_3A). For example:¶
These optimizations MUST NOT be applied in COSE header parameters or in other contexts where the full map structure is required.¶
To mitigate misbinding attacks, identity information such as a 'sub' (subject) claim MUST be included in both CRED_I and CRED_R.¶
The message flow of EDHOC-PSK follows the structure defined in [RFC9528], 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 [RFC9528]. If the Diffie-Hellman procedure is replaced by a KEM, then G_X and G_Y are encapsulation key and ciphertext, respectively, and the shared secret G_XY is derived by the KEM, see [I-D.spm-lake-pqsuites].¶
The Responder authenticates the Initiator first. Figure 1 illustrates the message flow of the EDHOC-PSK authentication method.¶
This approach provides identity protection against passive attackers for both Initiator and Responder. EDHOC message_4 remains OPTIONAL, but is needed to authenticate the Responder and achieve mutual authentication in EDHOC when external applications (e.g., OSCORE) are not relied upon. In either case, the inclusion of a fourth message provides mutual authentication and explicit key confirmation (see Section 5.4).¶
The pseudorandom keys (PRKs) used in the EDHOC-PSK authentication method are derived with EDHOC_Extract, as in [RFC9528].¶
PRK = EDHOC_Extract( salt, IKM )¶
where salt and input keying material (IKM) are defined for each key. The definition of EDHOC_Extract depends on the EDHOC hash algorithm selected in the cipher suite, see Section 4.1.1 of [RFC9528].¶
To maintain a uniform key schedule across all EDHOC 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 EDHOC 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 EDHOC-PSK.¶
PRK_2e is extracted as in [RFC9528] with¶
where the transcript hash TH_2 = H( G_Y, H(message_1) ) is defined in Section 5.3.2 of [RFC9528].¶
SALT_4e3m is derived from PRK_3e2m and TH_3, as shown in Figure 6 of [RFC9528].¶
The other PRKs and transcript hashes are modified as specified below. Figure 2 lists the key derivations that differ from Section 4.1.2 of [RFC9528].¶
PRK_3e2m = PRK_2e KEYSTREAM_2A = EDHOC_KDF( PRK_2e, 0, TH_2, plaintext_length_2a ) PRK_4e3m = EDHOC_Extract( SALT_4e3m, PSK ) KEYSTREAM_3A = EDHOC_KDF( PRK_3e2m, 11, TH_3, plaintext_length_3a ) K_3 = EDHOC_KDF( PRK_4e3m, 3, TH_3, key_length ) IV_3 = EDHOC_KDF( PRK_4e3m, 4, TH_3, iv_length )
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 )¶
This section specifies the differences in message formatting and processing compared to Section 5 of [RFC9528]. Note that if any processing step fails, then the Responder MUST send an EDHOC error message back as defined in Section 6 of [RFC9528], and the EDHOC session MUST be aborted.¶
Message 1 is formatted and processed as specified in Section 5.2 of [RFC9528].¶
Message 2 is formatted as specified in Section 5.3.1 of [RFC9528].¶
CIPHERTEXT_2A is calculated with a binary additive stream cipher, using a keystream generated with EDHOC_Expand, and the following plaintext:¶
C_R, EAD_2 are defined in Section 5.3.2 of [RFC9528]. In contrast to [RFC9528], 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 [RFC9528], as authentication in EDHOC-PSK relies solely on the shared PSK and the successful decryption of protected messages. KEYSTREAM_2A is defined in Section 4.¶
Upon receiving message_2, the Initiator processes it as follows:¶
Decrypt CIPHERTEXT_2A using binary XOR, i.e., PLAINTEXT_2A = CIPHERTEXT_2A XOR KEYSTREAM_2A¶
In contrast to Section 5.3.3 of [RFC9528], ID_CRED_R is not made available to the application in step 4, and steps 5 and 6 are skipped¶
Message 3 is formatted as specified in Section 5.4.1 of [RFC9528].¶
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 Section 3.5.3.2 of [RFC9528].¶
For the case of plaintext_length exceeding the EDHOC_KDF output size, see Appendix G of [RFC9528].¶
CIPHERTEXT_3A = PLAINTEXT_3A XOR KEYSTREAM_3A¶
CIPHERTEXT_3B is the 'ciphertext' of COSE_Encrypt0 object as defined in Section 5.2 and Section 5.3 of [RFC9528], with the EDHOC 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 Section 5.2 of [RFC9528], plaintext PLAINTEXT_3B and the following parameters as input:¶
The Initiator computes TH_4 as defined in Section 4.¶
There is no need for MAC_3 or signature, since AEAD's built-in integrity and the use of PSK-based key derivation provides implicit authentication of the Initiator.¶
Upon receiving message_3, the Responder proceeds as follows:¶
Parse the structure of message_3, which consists of a stream-cipher encrypted structure, CIPHERTEXT_3A = PLAINTEXT_3A XOR KEYSTREAM_3A, where PLAINTEXT_3A = ( ID_CRED_PSK, CIPHERTEXT_3B ) and CIPHERTEXT_3B is the inner AEAD-encrypted object.¶
Generate KEYSTREAM_3A with the same method the initiator used.¶
Decrypt CIPHERTEXT_3A using binary XOR with KEYSTREAM_3A to recover PLAINTEXT_3A.¶
Use ID_CRED_PSK to identify the authentication credentials and retrieve PSK.¶
AEAD-decrypt CIPHERTEXT_3B using:¶
If AEAD verification fails, 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 Section 4.¶
No MAC_3 or signature is needed, as the AEAD tag guarantees both integrity and authenticity in this symmetric setting.¶
Message 4 is formatted and processed as specified in Section 5.5 of [RFC9528].¶
After verifying message_4, 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 message_4 has been verified, or until another fourth message from the Responder protected with an exported application key such as an OSCORE message has been received and the application has authenticated the Responder.¶
Compared to [RFC9528], the fourth message not only provide key confirmation but also authenticates the Responder. For mutual authentication a fourth message is therefore mandatory.¶
This section specifies how EDHOC-PSK is used for session resumption in EDHOC. The EDHOC_Exporter, as defined in Section 4.2 of [RFC9528], is used to derive the resumption parameters rPSK and rKID:¶
rPSK = EDHOC_Exporter( 2, h'', resumption_psk_length )
rKID = EDHOC_Exporter( 3, h'', id_cred_psk_length )
rID_CRED_PSK = { 4 : rKID }
where:¶
resumption_psk_length defaults to the key_length, i.e., the length of the encryption key of the EDHOC AEAD algorithm in the selected cipher suite of the session where the EDHOC_Exporter is invoked.¶
id_cred_psk_length defaults to 2 bytes.¶
A peer that has successfully completed an EDHOC session, regardless of the used authentication method and regardless of if the session was PSK resumption, MUST generate a resumption key for use in the next resumption within the current "session series", provided it supports PSK resumption.¶
To ensure both peers share the same resumption key, when a session is run using rPSK_i as the resumption key:¶
The Initiator MAY delete rPSK_i after successfully verifying the fourth message. At that point, the Responder will already have derived the next rPSK_(i+1), which the Initiator can be certain of upon receiving the fourth message.¶
The Responder MAY delete rPSK_(i-1), if present, after successfully sending the fourth message. Upon receiving message_3, the Responder knows with certainty that the Initiator derived rPSK_i at the end of the previous session in the session series, making it safe to delete the prior resumption key rPSK_(i-1).¶
When using a resumption PSK derived from a previous EDHOC exchange:¶
The resumption PSK MUST only be used with the same cipher suite from which it was derived, or with a cipher suite that provides stronger security guarantees.¶
Implementations MUST maintain a mapping between each resumption PSK and its originating cipher suite to enforce this requirement.¶
If a resumption PSK is offered with a cipher suite that provides weaker security, the Responder MUST reject the ongoing EDHOC session.¶
When using resumption PSKs:¶
ID_CRED_PSK is not exposed to passive attackers, and under normal operation it is not reused. 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 EDHOC-PSK, which aim to provide identity protection against passive, but not active, attackers.¶
When PSK authentication is used and the Initiator is able to derive PRK_out before sending message_3, then the optimization described in Section 3 of [RFC9668] applies. In this scenario, the Initiator MAY concatenate EDHOC message_3 and the first OSCORE request in a single CoAP message.¶
The EDHOC-PSK authentication method introduces changes with respect to the current specification of EDHOC [RFC9528]. This section analyzes the security implications of these changes.¶
EDHOC-PSK encrypts ID_CRED_PSK in message 3 with a keystream derived from the ephemeral shared secret G_XY. As a consequence, contrary to the current EDHOC methods that protect the Initiator’s identity against active attackers and the Responder’s identity against passive attackers (See Section 9.1 of [RFC9528]), EDHOC-PSK provides identity protection for both the Initiator and the Responder against passive attackers.¶
In symmetric key setups, using the same CRED_x for both parties makes the protocol vulnerable to reflection or Selfie attacks. Separate identities in sub serve as non-cryptographic role binders and MUST be distinct.¶
EDHOC-PSK enables mutual authentication and explicit key confirmation with the inclusion of a fourth message demonstrating possession of the PSK (assuming the PSK remains secret). The fourth message may either be the optional message_4 or application data such as an OSCORE message protected with an exported application key.¶
Recent advancements in quantum computing suggest that the development of a Cryptographically Relevant Quantum Computer (CRQC) is likely feasible long-term. If realized, such a machine would render many currently deployed asymmetric cryptographic algorithms—such as Elliptic Curve Diffie-Hellman (ECDH)—insecure.¶
By leveraging a symmetric PSK for both authentication and key derivation, EDHOC-PSK provides quantum-resistant key exchange and authentication, even when used with ECDHE. However, if a cryptographically relevant quantum computer (CRQC) is realized, the ECDHE component would be broken and contribute only randomness. Consequently, EDHOC-PSK with ECDHE does not offer identity protection or Perfect Forward Secrecy (PFS) against quantum-capable adversaries. If the PSK is compromised, a passive quantum attacker could decrypt both past and future sessions. In contrast, EDHOC-PSK combined with a quantum-resistant Key Encapsulation Mechanism (KEM), such as ML-KEM, provides identity protection and PFS even in the presence of a quantum attacker.¶
NIST mandates that an ephemeral private key shall be used in exactly one key-establishment transaction (see Section 5.6.3.3 of [SP-800-56A]). This requirement is essential for preserving session key independence and ensuring forward secrecy. The EDHOC-PSK protocol complies with this NIST requirement.¶
In other protocols, the reuse of ephemeral keys, particularly when combined with implementation flaws such as the absence of public key validation, has resulted in critical security vulnerabilities. Such weaknesses have allowed attackers to recover the so called “ephemeral” private key from a compromised session, thereby enabling them to compromise the security of both past and future sessions between legitimate parties. Assuming breach and minimizing the impact of compromise are fundamental zero-trust principles.¶
For use cases involving the transmission of application data, application data can be sent concurrently with message_3, maintaining the protocol's efficiency. In applications such as EAP-EDHOC, where application data is not sent, message_4 is mandatory. Thus, the EDHOC-PSK authentication method does not include any extra messages. Other implementations may continue using OSCORE in place of EDHOC message_4, with a required change in the protocol's language to: The Initiator SHALL NOT persistently store PRK_out or application keys until the Initiator has verified message_4 or a message protected with an exported application key, such as an OSCORE message.¶
This change ensures that key materials are only stored once their integrity and authenticity are confirmed, thereby enhancing privacy by preventing early storage of potentially compromised keys.¶
Lastly, whether the Initiator or Responder authenticates first is not relevant when using symmetric keys. This consideration was important for the privacy properties when using asymmetric authentication but is not significant in the context of symmetric key usage.¶
This document requires the following IANA actions.¶
IANA is requested to register the following entry in the "EDHOC Method Type" registry under the group name "Ephemeral Diffie-Hellman Over OCSE (EDHOC)".¶
| Value | Initiator Authentication Key | Responder Authentication Key |
|---|---|---|
| 4 (suggested) | PSK | PSK |
IANA is requested to register the following entry in the "EDHOC Exporter Label" registry under the group name "Ephemeral Diffie-Hellman Over OCSE (EDHOC)".¶
| Label | Description | Change Controller | Reference |
|---|---|---|---|
| 2 (suggested) | Resumption PSK | IETF | Section 7 |
| 3 (suggested) | Resumption kid | IETF | Section 7 |
This section compiles the CDDL definitions for convenience, incorporating errata filed against [RFC9528].¶
suites = [ 2* int ] / int ead = ( ead_label : int, ? ead_value : bstr, ) EAD_1 = (1* ead) EAD_2 = (1* ead) EAD_3 = (1* ead) EAD_4 = (1* ead) message_1 = ( METHOD : int, SUITES_I : suites, G_X : bstr, C_I : bstr / -24..23, ? EAD_1, ) message_2 = ( G_Y_CIPHERTEXT_2 : bstr, ) PLAINTEXT_2A = ( C_R : bstr / -24..23, ? EAD_2, ) message_3 = ( CIPHERTEXT_3 : bstr, ) PLAINTEXT_3A = ( ID_CRED_PSK : header_map / bstr / -24..23, CIPHERTEXT_3B : bstr, ) PLAINTEXT_3B = ( ? EAD_3 ) message_4 = ( CIPHERTEXT_4 : bstr, ) PLAINTEXT_4 = ( ? EAD_4, ) error = ( ERR_CODE : int, ERR_INFO : any, ) info = ( info_label : int, context : bstr, length : uint, )¶
Both endpoints are authenticated with Pre-Shared Keys (METHOD = 4)¶
METHOD (CBOR Data Item) (1 byte) 04¶
The initiator selects cipher suite 02. A single cipher suite is encoded as an int:¶
SUITES_I (CBOR Data Item) (1 byte) 02¶
The Initiator creates an ephemeral key pair for use with the EDHOC key exchange algorithm:¶
Initiator's ephemeral private key X (Raw Value) (32 bytes) 09 97 2D FE F1 EA AB 92 6E C9 6E 80 05 FE D2 9F 70 FF BF 4E 36 1C 3A 06 1A 7A CD B5 17 0C 10 E5¶
Initiator's ephemeral public key G_X (Raw Value) (32 bytes) 7E C6 81 02 94 06 02 AA B5 48 53 9B F4 2A 35 99 2D 95 72 49 EB 7F 18 88 40 6D 17 8A 04 C9 12 DB¶
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:¶
Connection identifier chosen by the Initiator C_I (CBOR Data Item) (1 byte) 0A¶
No external authorization data¶
EAD_1 (CBOR Sequence) (0 bytes)¶
The Initiator constructs message_1:¶
message_1 (CBOR Sequence) (37 bytes) 04 02 58 20 7e c6 81 02 94 06 02 aa b5 48 53 9b f4 2a 35 99 2d 95 72 49 eb 7f 18 88 40 6d 17 8a 04 c9 12 db 0a¶
The Responder supports the most preferred and selected cipher suite 0, so SUITES_I is acceptable.¶
The Responder creates an ephemeral key pair for use with the EDHOC key exchange algorithm:¶
Responder's ephemeral private key Y (Raw Value) (32 bytes) 1E 1C 8F 2D F1 AA 71 10 B3 9F 33 BA 5E A8 DC CF 31 41 1E B3 3D 4F 9A 09 4C F6 51 92 D3 35 A7 A3¶
Responder's ephemeral public key G_Y (Raw Value) (32 bytes) ED 15 6A 62 43 E0 AF EC 9E FB AA BC E8 42 9D 5A D5 E4 E1 C4 32 F7 6A 6E DE 8F 79 24 7B B9 7D 83¶
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:¶
Connection identifier chosen by the Responder C_R (CBOR Data Item) (1 byte) 05¶
The transcript hash TH_2 is calculated using the EDHOC hash algorithm: TH_2 = H( G_Y, H(message_1) ), where H(message_1) is:¶
H(message_1) (CBOR Data Item) (32 bytes) 19 CC 2D 2A 95 7E DD 80 10 90 42 FD E6 CC 20 C2 4B 6A 34 BC 21 C6 D4 9F EA 89 5D 4C 75 92 34 0E¶
TH_2 (CBOR Data Item) (32 bytes) 5B 48 34 AE 63 0A 8A 0E D0 B0 C6 F3 66 42 60 4D 01 64 78 C4 BC 81 87 BB 76 4D D4 0F 2B EE 3D DE¶
PRK_2e is specified in Section 4.1.2 of [RFC9528]. 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:¶
G_XY (Raw Value) (ECDH shared secret) (32 bytes) 2F 4A 79 9A 5A B0 C5 67 22 0C B6 72 08 E6 CF 8F 4C A5 FE 38 5D 1B 11 FD 9A 57 3D 41 60 F3 B0 B2¶
Then, PRK_2e is calculated as defined in Section 4.1.2 of [RFC9528]¶
PRK_2e (Raw Value) (32 bytes) D0 39 D6 C3 CF 35 EC A0 CD F8 19 E3 25 79 C7 7E 1F 30 3E FC C4 36 20 50 99 48 A9 FD 47 FB D9 29¶
Since the Responder authenticates using PSK, PRK_3e2m = PRK_2e.¶
PRK_3e2m (Raw Value) (32 bytes) D0 39 D6 C3 CF 35 EC A0 CD F8 19 E3 25 79 C7 7E 1F 30 3E FC C4 36 20 50 99 48 A9 FD 47 FB D9 29¶
No external authorization data:¶
EAD_2 (CBOR Sequence) (0 bytes)¶
The Responder constructs PLAINTEXT_2A:¶
PLAINTEXT_2A (CBOR Sequence) (1 byte) 05¶
The Responder computes KEYSTREAM_2 as defined in Section 4.1.2 of [RFC9528]¶
KEYSTREAM_2 (CBOR Sequence) (1 byte) EC¶
The Responder calculates CIPHERTEXT_2B as XOR between PLAINTEXT_2A and KEYSTREAM_2:¶
CIPHERTEXT_2B (CBOR Sequence) (1 byte) E9¶
The Responder constructs message_2 as defined in Section 5.3.1 of [RFC9528]:¶
message_2 (CBOR Sequence) (35 bytes) 58 21 ED 15 6A 62 43 E0 AF EC 9E FB AA BC E8 42 9D 5A D5 E4 E1 C4 32 F7 6A 6E DE 8F 79 24 7B B9 7D 83 E9¶
The Initiator computes PRK_4e3m, as described in Section 4, using SALT_4e3m and PSK:¶
SALT_4e3m (Raw Value) (32 bytes) ED E0 76 12 14 83 19 EB 72 59 52 71 2A 54 2C 20 97 61 0A 13 9C 4A 14 1C 8E C5 7A 5F 62 E5 E9 DD¶
PSK (Raw Value) (16 bytes) 50 93 0F F4 62 A7 7A 35 40 CF 54 63 25 DE A2 14¶
PRK_4e3m (Raw Value) (32 bytes) B3 65 6C 57 B6 14 4E 9C A3 72 08 81 D8 AF 69 53 C4 69 17 A8 5D D8 92 E6 E6 13 65 4F FC 4F A8 0B¶
The transcript hash TH_3 is calculated using the EDHOC hash algorithm:¶
TH_3 = H( TH_2, PLAINTEXT_2A )¶
TH_3 (CBOR Data Item) (32 bytes) 38 6A 9D 05 2B 25 59 92 EE E5 FF B5 94 34 7D 32 74 18 A2 EA 51 83 48 6C 0C 9E 20 42 6E 0B CA 2F¶
No external authorization data:¶
EAD_3 (CBOR Sequence) (0 bytes)¶
The Initiator constructs firstly PLAINTEXT_3B as defined in Section 5.3.1.:¶
PLAINTEXT_3B (CBOR Sequence) (0 bytes)¶
It then computes CIPHERTEXT_3B as defined in Section 5.3.2. It uses ID_CRED_PSK, CRED_I, CRED_R and TH_3 as external_aad:¶
ID_CRED_PSK (CBOR Sequence) (1 byte) 10¶
CRED_I (Raw Value) (38 bytes) A2 02 69 69 6E 69 74 69 61 74 6F 72 08 A1 01 A3 01 04 02 41 10 20 50 50 93 0F F4 62 A7 7A 35 40 CF 54 63 25 DE A2 14¶
CRED_R (Raw Value) (38 bytes) A2 02 69 72 65 73 70 6F 6E 64 65 72 08 A1 01 A3 01 04 02 41 10 20 50 50 93 0F F4 62 A7 7A 35 40 CF 54 63 25 DE A2 14¶
TH_3 (CBOR Data Item) (32 bytes) 38 6A 9D 05 2B 25 59 92 EE E5 FF B5 94 34 7D 32 74 18 A2 EA 51 83 48 6C 0C 9E 20 42 6E 0B CA 2F¶
The initiator computes K_3 and IV_3¶
K_3 (CBOR Sequence) (16 bytes) A4 A5 35 4E 1F 79 EC 99 D8 24 35 45 7F A8 FA 0C¶
IV_3 (CBOR Sequence) (13 bytes) 18 09 36 AD 4C 31 9A E8 D5 DC C7 E0 09¶
It then computes CIPHERTEXT_3B:¶
CIPHERTEXT_3B (CBOR Sequence) (9 bytes) 48 11 D0 49 1F C8 BB 2E 16 0A¶
The Initiator computes KEYSTREAM_3 as defined in Section 4:¶
KEYSTREAM_3 (CBOR Sequence) () A3 60 2B 68 19 A4 84 40 68 7E 00¶
It then calculates PLAINTEXT_3A as stated in Section 5.3.2.:¶
PLAINTEXT_3A (CBOR Sequence) (10 bytes) 10 48 11 D0 49 1F C8 BB 2E 16 0A¶
It then uses KEYSTREAM_3 to derive CIPHERTEXT_3A:¶
CIPHERTEXT_3A (CBOR Sequence) (10 bytes) B3 28 3A B8 50 BB 4C FB 46 68 00¶
The Initiator computes message_3 as defined in Section 5.3.2.:¶
message_3 (CBOR Sequence) (11 bytes) 4A B3 28 3A B8 50 BB 4C FB 46 68¶
The transcript hash TH_4 is calculated using the EDHOC hash algorithm: TH_4 = H( TH_3, ID_CRED_PSK, ? EAD_3, CRED_I, CRED_R )¶
TH_4 (CBOR Data Item) (32 bytes) 11 48 1B 9A FE F9 5C 67 9A 52 03 82 17 EE DD 0E 0C E0 8F AA 86 5B DC 82 55 11 CA 6D C3 91 94 13¶
After sending message_3, the Initiator can compute PRK_out¶
PRK_out (Raw value) (32 bytes) B7 1F A6 27 07 34 54 63 91 D6 DC D0 C4 0F 58 CA D4 25 8E F4 63 5A 81 37 C1 FD 8B F7 92 C8 07 F4¶
No external authorization data:¶
EAD_4 (CBOR Sequence) (0 bytes)¶
The Responder constructs PLAINTEXT_4:¶
PLAINTEXT_4 (CBOR Sequence) (0 bytes)¶
The Responder computes K_4 and IV_4¶
K_4 (CBOR Sequence) (16 bytes) 81 C8 1A 4F DC 80 AE 09 99 59 98 61 CA 55 0A B3¶
IV_4 (CBOR Sequence) (13 bytes) BF 14 F7 95 6D 54 49 99 B0 9A 6A CB 0D¶
The Responder computes message_4:¶
48 AA CC FA 23 A4 0F 4A B5¶
The Responder then computes PRK_out:¶
PRK_out (Raw value) (32 bytes) B7 1F A6 27 07 34 54 63 91 D6 DC D0 C4 0F 58 CA D4 25 8E F4 63 5A 81 37 C1 FD 8B F7 92 C8 07 F4¶
RFC Editor: Please remove this appendix.¶
The authors want to thank Christian Amsüss, Scott Fluhrer, Charlie Jacomme, Marco Tiloca, and Francisco Lopez-Gomez 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.¶