LAKE Working Group E. Lopez-Perez
Internet-Draft Inria
Intended status: Standards Track G. Selander
Expires: 2 September 2025 J. Preuß Mattsson
Ericsson
R. Marin-Lopez
University of Murcia
1 March 2025
EDHOC Authenticated with Pre-Shred Keys (PSK)
draft-ietf-lake-edhoc-psk-03
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 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.
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.
Lopez-Perez, et al. Expires 2 September 2025 [Page 1]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
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 2 September 2025.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Credentials . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Message Flow of PSK . . . . . . . . . . . . . . . . . . . 5
4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 6
5. Message Formatting and Processing . . . . . . . . . . . . . . 7
5.1. Message 1 . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Message 2 . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.1. Formatting of Message 2 . . . . . . . . . . . . . . . 7
5.2.2. Responder Composition of Message 2 . . . . . . . . . 7
5.2.3. Initiator Processing of Message 2 . . . . . . . . . . 7
5.3. Message 3 . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3.1. Formatting of Message 3 . . . . . . . . . . . . . . . 8
5.3.2. Initiator Composition of Message 3 . . . . . . . . . 8
5.3.3. Responder Processing of Message 3 . . . . . . . . . . 9
5.4. Message 4 . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Identity protection . . . . . . . . . . . . . . . . . . . 9
6.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 9
Lopez-Perez, et al. Expires 2 September 2025 [Page 2]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
6.3. External Authorization Data Protection . . . . . . . . . 10
6.4. Post Quantum Considerations . . . . . . . . . . . . . . . 10
6.5. Independence of Session Keys . . . . . . . . . . . . . . 10
6.6. Unified Approach and Recommendations . . . . . . . . . . 11
7. PSK usage for Session Resumtpion . . . . . . . . . . . . . . 11
7.1. Ciphersuite Requirements for Resumption . . . . . . . . . 11
7.2. Privacy Considerations for Resumption . . . . . . . . . . 12
7.3. Security Considerations for Resumption . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. EDHOC Method Type Registry . . . . . . . . . . . . . . . 12
8.2. EDHOC Exporter Label Registry . . . . . . . . . . . . . . 13
8.3. EDHOC Info Label Registry . . . . . . . . . . . . . . . . 13
9. Normative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. CDDL Definitions . . . . . . . . . . . . . . . . . . 14
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 16
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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].
EDHOC with PSK authentication benefits systems where two nodes nodes
share a Pre-Shared Key (PSK) provided out-of-band (external PSK).
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
Lopez-Perez, et al. Expires 2 September 2025 [Page 3]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
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
PSK is provisioned after the establishment of a previous EDHOC
session by using EDHOC_Exporter (resumption PSK).
Therefore, the external PSK is supposed to be a long-term credential
while the resumption PSK is 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 discusses security considerations. How to
derive keys for resumption is described in Section 7.
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 (external PSK or
resumption 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.
Lopez-Perez, et al. Expires 2 September 2025 [Page 4]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
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.
Lopez-Perez, et al. Expires 2 September 2025 [Page 5]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
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.
Lopez-Perez, et al. Expires 2 September 2025 [Page 6]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
where:
* KEYSTREAM_3 is used to encrypt the ID_CRED_PSK in message_3.
* TH_3 = H( TH_2, PLAINTEXT_2 )
Additionally, the definition of the transcript hash TH_4 is modified
as:
* TH_4 = H( TH_3, ID_CRED_PSK, ? EAD_3, CRED_PSK )
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
Lopez-Perez, et al. Expires 2 September 2025 [Page 7]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
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 )
o 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].
o If the length of PLAINTEXT_3A exceeds the output of
EDHOC_KDF, then Appendix G of [RFC9528] applies.
- 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, CRED_PSK >>
- 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.
Lopez-Perez, et al. Expires 2 September 2025 [Page 8]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
5.3.3. Responder Processing of Message 3
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.
Lopez-Perez, et al. Expires 2 September 2025 [Page 9]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
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. 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.5. 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.
Lopez-Perez, et al. Expires 2 September 2025 [Page 10]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
6.6. 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. PSK usage for Session Resumtpion
This section defines how PSKs are used for session resumption in
EDHOC. Each time EDHOC-PSK is run a new PRK_out and PRK_exporter
will be generated. Following Section 4.2 of [RFC9528],
EDHOC_Exporter can be used to derive both CRED_PSK and ID_CRED_PSK:
CRED_PSK = EDHOC_Exporter( 2, h'', resumption_psk_length )
ID_CRED_PSK = EDHOC_Exporter( 3, h'', id_cred_psk_length )
7.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.
Lopez-Perez, et al. Expires 2 September 2025 [Page 11]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
7.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. Alternatively, as stated in
Appendix H of [RFC9528], EDHOC_KeyUpdate can be used to derive a
new PRK_out, and consequently a new CRED_PSK and ID_CRED_PSK for
session resumption.
While PSK reuse enhances efficiency by reducing the overhead of key
exchanges, it presents privacy risks if not managed properly through
periodic renewal.
7.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.
8. IANA Considerations
This document has IANA actions.
8.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.
Lopez-Perez, et al. Expires 2 September 2025 [Page 12]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
8.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)".
+------------+------------------------------+-------------------+-------------------+
| Label | Descritpion | Change Controller | Reference |
+============+==============================+===================+===================+
| 2 | Resumption CRED_PSK | IETF | Section 7 |
+------------+------------------------------+-------------------+-------------------+
| 3 | Resumption ID_CRED_PSK | IETF | Section 7 |
+------------+------------------------------+-------------------+-------------------+
Figure 4: Addition to the EDHOC Exporter Label Registry.
8.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 |
+============+=======================+===================+
| 12 | KEYSTREAM_3 | Section 4 |
+------------+-----------------------+-------------------+
| 13 | K_3 | Section 4 |
+------------+-----------------------+-------------------+
| 14 | IV_3 | Section 4 |
+------------+-----------------------+-------------------+
Figure 5: EDHOC Info Label Registry.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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,
May 2017, <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,
May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.
Lopez-Perez, et al. Expires 2 September 2025 [Page 13]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
[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,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<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, December 2020,
<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, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <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, March 2024,
<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, April 2018,
<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,
)
Lopez-Perez, et al. Expires 2 September 2025 [Page 14]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
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,
)
Lopez-Perez, et al. Expires 2 September 2025 [Page 15]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
info = (
info_label : int,
context : bstr,
length : uint,
)
Appendix B. Test Vectors
Appendix C. Change Log
RFC Editor: Please remove this appendix.
* From -02 to -03
- Updated abstract and Introduction
- Changed message_3 to hide the identity lenght 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 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.
Authors' Addresses
Elsa Lopez-Perez
Inria
Lopez-Perez, et al. Expires 2 September 2025 [Page 16]
Internet-Draft EDHOC Authenticated with Pre-Shred Keys March 2025
Email: elsa.lopez-perez@inria.fr
Göran Selander
Ericsson
Email: goran.selander@ericsson.com
John Preuß Mattsson
Ericsson
Email: john.mattsson@ericsson.com
Rafael Marin-Lopez
University of Murcia
Email: rafa@um.es
Lopez-Perez, et al. Expires 2 September 2025 [Page 17]