Internet-Draft EDHOC with Pre-Shared Key (PSK) Authenti February 2025
Lopez-Perez, et al. Expires 22 August 2025 [Page]
Workgroup:
LAKE Working Group
Internet-Draft:
draft-ietf-lake-edhoc-psk-latest
Published:
Intended Status:
Standards Track
Expires:
Authors:
E. Lopez-Perez
Inria
G. Selander
Ericsson
J. Preuß Mattsson
Ericsson
R. Marin-Lopez
University of Murcia

EDHOC with Pre-Shared Key (PSK) Authentication

Abstract

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 out-of-band and enables efficient session resumption with less computational overhead. This document details the PSK method flow, key derivation changes, message formatting, processing, and security considerations.

About This Document

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 22 August 2025.

▲

Table of Contents

1. Introduction

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 symmetrical key distribution is more complex than asymmetrical 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]. By utilizing the PSK for both authentication and key derivation, this method provides quantum resistance.

EDHOC with PSK authentication benefits systems where two nodes nodes share a Pre-Shared Key (PSK) provided out-of-band. This applies to scenarios like 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 from passive attackers. Additionally, by leveraging the PSK for both authentication and key derivation, the method offers quantum resistance key exchange and authentication.

Another key use case of PSK authentication in the EDHOC protocol is session resumption. This enables 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.

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 discusses security considerations. How to derive keys for resumption is described in Section TODO.

2. 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 [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.

3. 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.

3.1. 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:

ID_CRED_PSK = {4 : h'0f' }

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

{                                               /CCS/
  2 : "mydotbot",                               /sub/
  8 : {                                         /cnf/
    1 : {                                       /COSE_Key/
       1 : 4,                                   /kty/
       2 : h'0f',                               /kid/
      -1 : h'50930FF462A77A3540CF546325DEA214'  /k/
    }
  }
}

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 [RFC9528], and, when applicable, MUST follow the same guidelines described in Section 3.5.2 and Section 3.5.3 of [RFC9528].

3.2. 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. Figure 1 shows the message flow of PSK authentication method.

Initiator Responder METHOD, SUITES_I, G_X, C_I, EAD_1 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
Figure 1: Overview of Message Flow of PSK.

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.

4. Key Derivation

The pseudorandom keys (PRKs) used for PSK authentication method in EDHOC are derived using EDHOC_Extract, as done in [RFC9528].

PRK  = EDHOC_Extract( salt, IKM )

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.

Figure 2 lists the key derivations that differ from those specified in Section 4.1.2 of [RFC9528].

PRK_3e2m    = PRK_2e
PRK_4e3m    = EDHOC_Extract( SALT_4e3m, CRED_PSK )
KEYSTREAM_3 = EDHOC_KDF( PRK_3e2m, 11, TH_3, plaintext_length_3 )
K_3         = EDHOC_KDF( PRK_4e3m, 12, TH_3, key_length )
IV_3        = EDHOC_KDF( PRK_4e3m, 13, TH_3, iv_length )
Figure 2: Key Derivation of EDHOC PSK Authentication Method.

where:

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

5. Message Formatting and Processing

This section specifies the differences in message formatting and processing compared to Section 5 of [RFC9528].

5.1. Message 1

Message 1 is formatted and processed as specified in Section 5.2 of [RFC9528].

5.2. Message 2

5.2.1. Formatting of Message 2

Message 2 is formatted as specified in Section 5.3.1 of [RFC9528].

5.2.2. Responder Composition of Message 2

CIPHERTEXT_2 is calculated with a binary additive stream cipher, using a keystream generated with EDHOC_Expand, and the following plaintext:

  • PLAINTEXT_2B = ( C_R, ? EAD_2 )

  • CIPHERTEXT_2 = PLAINTEXT_2B XOR KEYSTREAM_2

Contrary to [RFC9528], ID_CRED_R, MAC_2, and Signature_or_MAC_2 are not used. C_R, EAD_2, and KEYSTREAM_2 are defined in Section 5.3.2 of [RFC9528].

5.2.3. Initiator Processing of Message 2

Compared 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

5.3. Message 3

5.3.1. Formatting of Message 3

Message 3 is formatted as specified in Section 5.4.1 of [RFC9528].

5.3.2. Initiator Composition of Message 3

  • CIPHERTEXT_3 is calculated with a binary additive stream cipher, using a keystream generated with EDHOC_Expand, and 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].

    • Compute KEYSTREAM_3 as in Section 4, where plaintext_length is the length of PLAINTEXT_3A. For the case of plaintext_length exceeding the EDHOC_KDF output size, see Appendix G of [RFC9528].

    • CIPHERTEXT_3 = PLAINTEXT_3A XOR KEYSTREAM_3

  • 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:

    • protected = h''

    • external_aad = << ID_CRED_PSK, TH_3 >>

    • K_3 and IV_3 as defined in Section 4

    • PLAINTEXT_3B = ( ? EAD_3 )

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

5.4. Message 4

Message 4 is formatted and processed as specified in Section 5.5 of [RFC9528].

Compared to [RFC9528], a fourth message does not only provide key confirmation but also Responder authentication. To authenticate the Responder and achieve mutual authentication, a fourth message is mandatory.

After verifying message_4, the Initiator is assured that the Responder has calculated the key PRK_out (key confirmation) and that no other party can derive the key. 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.

6. Security Considerations

PSK authentication method introduces changes with respect to the current specification of EDHOC [RFC9528]. This section analyzes the security implications of these changes.

6.1. Identity protection

EDHOC-PSK encrypts ID_CRED_PSK in message 3, XOR encrypted 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 Initator and the Responder against passive attackers.

6.2. Mutual Authentication

Authentication in EDHOC-PSK depends on the security of the session key and the protocol's confidentiality. Both security properties hold as long as the PSK remains secret. Even though the foruth message (message_4) remains optional, mutual authentication is not guaranteed without it, or without an OSCORE message or any application data that confirms that the Responder owns the PSK. When message_4 is included, the protocol achieves explicit key confirmation in addition to mutual authentication.

6.3. External Authorization Data Protection

Similarly to [RFC9528], EDHOC-PSK provides external authorization data protection. The integrity and confidentiality of EAD fields follow the same security guarantees as in the original EDHOC specification.

6.4. PSK usage for Session Resumtpion

This section defines how PSKs are used for session resumption in EDHOC. We can distinguish between two types of resumption PSKs:

  • External PSK: a PSK established out-of-band and used for the initial handshake.

  • Ressumption PSK: a key derived from a previous EDHOC session specifically for resumption purposes.

6.4.1. Ciphersuite requirements for resumption

When using a resumption PSK derived from a previous EDHOC exchange:

  1. The resumption PSK MUST only be used with the same ciphersuite that was used in the original EDHOC exchange, or with a ciphersuite that provides equal or higher security guarantees.

  2. Implmentations SHOULD manitain a mapping between the resumption PSK and its originating ciphersuite to enforce this requirement.

  3. If a resumption PSK is offered with a weaker ciphersuite than its original exchange, the recipient MUST reject the connection attempt.

6.4.2. Privacy Considerations for Resumption

When using resumption PSKs:

  • The same ID_CRED_PSK is reused each time EDHOC is executed with a specific resumption PSK.

  • To prevent long-term tracking, implementations SHOULD periodically initiate a full EDHOC exchange to generate a new resumption PSK and corresponding ID_CRED_PSK.

While PSK reuse enhances efficiency by reducing the overhead of key exchanges, it presents privacy risks if not managed properly through periodic renewal.

6.4.3. Security Considerations for Resumption

  • Resumption PSKs MUST NOT be used for purposes other than EDHOC session resumption.

  • Resumption PSKs MUST be securely stored with the same level of protection as the original session keys.

  • Parties SHOULD implement mechanisms to detect and prevent excessive reuse of the same resumption PSK.

6.5. Post Quantum Considerations

Recent achievements in developing quantum computers demonstrate that it is probably feasible to build one that is cryptographically significant. If such a computer is implemented, many of the cryptographic algorithms and protocols currently in use would be insecure. A quantum computer would be able to solve Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) problems in polynomial time.

EDCHOC with pre-shared keys would not be vulnerable to quantum attacks because those keys are used as inputs to the key derivation function. The use of intermediate keys derived through key derivation functions ensure that the message is not immediately compromised if the symmetrically distributed key (PSK) is compromised, or if the algorithm used to distribute keys asymmetrically (DH) is broken. If the pre-shared key has sufficient entropy and the Key Derivation Function (KDF), encryption, and authentication transforms are quantum secure, then the resulting system is believed to be quantum secure. Therefore, provided that the PSK remains secret, EDHOC-PSK provides confidentiality, mutual authentication and Perfect Forward Secrecy (PFS) even in the presence of quantum attacks. What is more, the key exchange is still a key agreement where both parties contribute with randomness.

6.6. Independence of Session Keys

NIST mandates that 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 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.

6.7. 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.

7. IANA Considerations

This document has IANA actions.

7.1. EDHOC Method Type Registry

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 Reference 4 PSK PSK
Figure 3: Addition to the EDHOC Method Type Registry.

7.2. EDHOC Exporter Label Registry

IANA is requested to register the following entry in the "EDHOC Exporter Label" registry under the group name "Ephemeral Diffie-Hellman Over OCSE (EDHOC)".

7.3. EDHOC Info Label Registry

IANA is requested to register the following registry "EDHOC Info Label" under the group name "Ephemeral Diffie-Hellman Over OCSE (EDHOC)".

Label Key Reference 10 KEYSTREAM_3 {{key-der}} 11 K_3 {{key-der}} 12 IV_3 {{key-der}}
Figure 5: EDHOC Info Label Registry.

8. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8392]
Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, , <https://www.rfc-editor.org/rfc/rfc8392>.
[RFC8610]
Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, , <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC8742]
Bormann, C., "Concise Binary Object Representation (CBOR) Sequences", RFC 8742, DOI 10.17487/RFC8742, , <https://www.rfc-editor.org/rfc/rfc8742>.
[RFC8949]
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9052]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9053]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, , <https://www.rfc-editor.org/rfc/rfc9053>.
[RFC9528]
Selander, G., Preuß Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, DOI 10.17487/RFC9528, , <https://www.rfc-editor.org/rfc/rfc9528>.
[SP-800-56A]
Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography", NIST Special Publication 800-56A Revision 3, , <https://doi.org/10.6028/NIST.SP.800-56Ar3>.

Appendix A. CDDL Definitions

This section compiles the CDDL definitions for easy reference, 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_2B = (
  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,
)

Appendix B. Test Vectors

Appendix C. Change Log

RFC Editor: Please remove this appendix.

Acknowledgments

The authors want to thank Christian Amsüss, Scott Fluhrer, Charlie Jacomme, and Marco Tiloca for reviewing and commenting on intermediate versions of the draft.

Authors' Addresses

Elsa Lopez-Perez
Inria
Göran Selander
Ericsson
John Preuß Mattsson
Ericsson
Rafael Marin-Lopez
University of Murcia