]> Inria

elsa.lopez-perez@inria.fr

Ericsson

goran.selander@ericsson.com

Ericsson

john.mattsson@ericsson.com

University of Murcia

rafa@um.es

Security LAKE Working Group This document specifies the Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange protocol. It describes the authentication processes, message flows, and security considerations of this authentication method. 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

Motivation Pre-shared key (PSK) authentication method provides a balance between security and computational efficiency. This authentication method was proposed in the first I-Ds of Ephemeral Diffie-Hellman Over COSE (EDHOC) , and was ruled out to speed out the development process. However, there is now a renewed effort to reintroduce PSK authentication, making this draft an update to the . EDHOC with PSK authentication could be beneficial for existing systems where two nodes have been provided with a PSK from other parties out of band. This allows the nodes to perform ephemeral Diffie-Hellman to achieve Perfect Forward Secrecy (PFS), ensuring that past communications remain secure even if the PSK is compromised. The authentication provided by EDHOC prevents eavesdropping by on-path attackers, as they would need to be active participants in the communication to intercept and potentially tamper with the session. Examples could be Generic Bootstrapping Architecture (GBA) and Authenticated Key Management Architecture (AKMA) in mobile systems, or Peer and Authenticator in EAP. Another prominent 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 their earlier session, reducing the overhead of full key exchange. This efficiency is beneficial in scenarios where frequent key updates are needed, such in resource-constrained environments or applications requiring high-frequency secure communications. The use of PSK authentication in EDHOC ensures that session key can be refreshed without heavy computational overhead, typically associated with public key operations, thus optimizing both performance and security.

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 described in CBOR , CBOR Sequences , COSE Structures and Processing , COSE Algorithms , CWT and CCS , and the Concise Data Definition Language (CDDL) , which is used to express CBOR data structures.

Protocol In this method, the Pre-Shared Key identifier (ID_CRED_PSK) is sent in message_3. The ID_CRED_PSK allows retrieval of CRED_PSK, a COSE_Key compatible authentication credential that contains the PSK. Through this document we will refer to the Pre-Shared Key authentication method as EDHOC-PSK.

Credentials Initiator and Responder are assumed to have a PSK with good amount of randomness and the requirements that:

• Only the Initiator and the Responder have access to the PSK.
• The Responder is able to retrieve the PSK using ID_CRED_PSK.

where:

• ID_CRED_PSK is a COSE header map containing header parameters that can identify a pre-shared key. For example:

• CRED_PSK is a COSE_Key compatible authentication credential, i.e., a CBOR Web Token (CWT) or CWT Claims Set (CCS) whose 'cnf' claim uses the confirmation method 'COSE_Key' encoding the PSK. For example:

The purpose of ID_CRED_PSK is to facilitate the retrieval of the PSK. It is RECOMMENDED that it uniquely identifies the CRED_PSK as the recipient might otherwise have to try several keys. If ID_CRED_PSK contains a single 'kid' parameter, then the compact encoding is applied; see Section 3.5.3.2 of RFC9528. The authentication credential CRED_PSK substitutes CRED_I and CRED_R specified in , and, when applicable, MUST follow the same guidelines described in Section 3.5.2 and Section 3.5.3 of RFC9528.

Message flow of PSK The ID_CRED_PSK is sent in message_3, encrypted using a key derived from the ephemeral shared secret, G_XY. The Responder authenticates the Initiator first. shows the message flow of PSK authentication method.

Overview of message flow of 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 protection against passive attackers for both Initiator and Responder. message_4 remains optional, but is needed to authenticate the Responder and achieve mutual authentication in EDHOC if not relaying on external applications, such as OSCORE. With this fourth message, the protocol achieves both explicit key confirmation and mutual authentication.

Key derivation The pseudorandom keys (PRKs) used for PSK authentication method in EDHOC are derived using EDHOC_Extract, as done in . where the 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. lists the key derivations that differ from those specified in Section 4.1.2 of RFC9528.

Key derivation of EDHOC PSK authentication method.

where:

• KEYSTREAM_3 is used to encrypt the ID_CRED_PSK in message_3.
• TH_3 = H( TH_2, PLAINTEXT_2, CRED_PSK )

Additionally, the definition of the transcript hash TH_4 is modified as:

• TH_4 = H( TH_3, ID_CRED_PSK, ? EAD_3, CRED_PSK )

Message formatting and processing This section specifies the differences on the message formatting compared to .

Message 1 Same as message_1 of EDHOC, described in Section 5.2.1 of RFC9528.

Message 2 message_2 SHALL be a CBOR sequence, defined as: where:

• G_Y_CIPHERTEXT_2 is the concatenation of G_Y (i.e., the ephemeral public key of the Responder) and CIPHERTEXT_2.
• CIPHERTEXT_2 is calculated with a binary additive stream cipher, using KEYSTREAM_2 and the following plaintext:
  • PLAINTEXT_2 = ( C_R, / bstr / -24..23, ? EAD_2 )
  • CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2

Contrary to , MAC_2 is not used.

Message 3 message_3 SHALL be a CBOR sequence, as defined below: > ) ; This defines an array, the elements of ; which are to be used in a CBOR Sequence: CIPHERTEXT_SEQUENCE = [CIPHERTEXT_3A, CIPHERTEXT_3B] CIPHERTEXT_3A = bstr CIPHERTEXT_3B = bstr ]]> where:

• CIPHERTEXT_3 is CBOR byte string, with value the binary representation of a CBOR Sequence composed of the following two elements:
  • CIPHERTEXT_3A is CBOR byte string, with value calculated by means of a binary additive stream cipher, XORing a KESYSTREAM_3 generated with EDHOC_Expand and the following plaintext:
    • PLAINTEXT_3A = ( ID_CRED_PSK )
  • 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, plaintext PLAINTEXT_3B and the following parameters as input:
    • protected = h''
    • external_aad = << Enc(ID_CRED_PSK), TH_3 >>
    • K_3 and IV_3 as defined in Section 5.2
    • PLAINTEXT_3B = ( ? EAD_3 )

The Initiator computes TH_4 = H( TH_3, ID_CRED_PSK, PLAINTEXT_3B, CRED_PSK ), defined in Section 5.2.

Message 4 message_4 is optional and is a CBOR sequence, defined as: To authenticate the Responder and achieve mutual authentication, a fourth message is mandatory. The Initiator MUST NOT persistently store PRK_out or application keys until the Initiator has verified message_4 or a message protected with a derived application key, such as an OSCORE message, from the Responder and the application has authenticated the Responder.

Security Considerations When evaluating the security considerations, it is important to differentiate between the initial handshake and session resumption phases.

1. Initial Handshake: a fresh CRED_PSK is used to establish a secure connection.
2. Session Resumption: the same PSK identifier (ID_CRED_PSK) is reused each time EDHOC is executed. While this enhances efficiency and reduces the overhead of key exchanges, it presents privacy risks if not managed properly. Over multiple resumption sessions, initiating a full EDHOC session changes the resumption PSK, resulting in a new ID_CRED_PSK. The periodic renewal of the CRED_PSK and ID_CRED_PSK helps mitigate long-term privacy risks associated with static key identifiers.

Identity protection The current EDHOC methods protect the Initiator’s identity against active attackers and the Responder’s identity against passive attackers (See Section 9.1 of RFC9528). With EDHOC-PSK authentication method, both the Initiator's and Responder's identities are protected against passive attackers, but not against active attackers.

Number of messages The current EDHOC protocol consists of three mandatory messages and an optional fourth message. In the case of EDHOC-PSK authentication method, message_4 remains optional, but mutual authentication is not guaranteed without it, or an OSCORE message or any application data that confirms that the Responder owns the PSK. Additionally, with this fourth message the protocol achieves explicit key confirmation in addition to mutual authentication.

External Authorization Data The Initiator and Responder can send information in EAD_3 and EAD_4 or in OSCORE messages in parallel with message_3 and message_4. This is possible because the Initiator knows that only the Responder with access to the CRED_PSK can decrypt the information.

Attacks EDHOC-PSK authentication method offers privacy and resistance to passive attacks but might be vulnerable to certain active attacks due to delayed authentication.

Privacy Considerations

Unified Approach and Recommendations 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, 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 a derived 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.

IANA Considerations This document has no IANA actions.

Normative References 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. 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 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. 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. 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. 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.

Acknowledgments TODO acknowledge.