# drafts

name: draft-ietf-lake-ra
rev: 03
title: Remote attestation over EDHOC
time: 2025-11-21T17:10:57Z
group_uri: /api/v1/group/group/2249/
expires: 2026-04-23T14:06:07Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:09.014901+00:00
abstract:
This document specifies how to perform remote attestation as part of
   the lightweight authenticated Diffie-Hellman key exchange protocol
   EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote
   ATtestation procedureS (RATS) architecture.

full_text:
Lightweight Authenticated Key Exchange                           Y. Song
Internet-Draft                                                     Inria
Intended status: Standards Track                             G. Selander
Expires: 23 April 2026                                       Ericsson AB
                                                         20 October 2025


                     Remote attestation over EDHOC
                         draft-ietf-lake-ra-03

Abstract

   This document specifies how to perform remote attestation as part of
   the lightweight authenticated Diffie-Hellman key exchange protocol
   EDHOC (Ephemeral Diffie-Hellman Over COSE), based on the Remote
   ATtestation procedureS (RATS) architecture.

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/ra/draft-ietf-lake-ra.html.  Status information for this
   document may be found at https://datatracker.ietf.org/doc/draft-ietf-
   lake-ra/.

   Discussion of this document takes place on the Lightweight
   Authenticated Key Exchange 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/ra.

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







Song & Selander           Expires 23 April 2026                 [Page 1]

Internet-Draft                  RA-EDHOC                    October 2025


   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 23 April 2026.

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 . . . . . . . . . . . . . . . . .   5
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Assumptions . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Remote Attestation in EDHOC . . . . . . . . . . . . . . . . .   6
     5.1.  Target: IoT Device Attestation (IoT)  . . . . . . . . . .   7
     5.2.  Target: Network Service Attestation (Net) . . . . . . . .   7
     5.3.  Model: Background-check Model (BG)  . . . . . . . . . . .   7
       5.3.1.  Attestation_proposal  . . . . . . . . . . . . . . . .   8
       5.3.2.  Attestation_request . . . . . . . . . . . . . . . . .   9
       5.3.3.  Evidence  . . . . . . . . . . . . . . . . . . . . . .   9
     5.4.  Model: Passport Model (PP)  . . . . . . . . . . . . . . .  10
       5.4.1.  Result_proposal . . . . . . . . . . . . . . . . . . .  11
       5.4.2.  Result_request  . . . . . . . . . . . . . . . . . . .  12
       5.4.3.  Result  . . . . . . . . . . . . . . . . . . . . . . .  12
       5.4.4.  trigger_pp  . . . . . . . . . . . . . . . . . . . . .  12
     5.5.  EDHOC forward Message Flow (Fwd)  . . . . . . . . . . . .  13
     5.6.  EDHOC reverse Message Flow (Rev)  . . . . . . . . . . . .  13
   6.  Instantiation of Remote Attestation Protocol  . . . . . . . .  13
     6.1.  (IoT, BG, Fwd): IoT Device Attestation  . . . . . . . . .  13
     6.2.  (Net, PP, Fwd): Network Service Attestation . . . . . . .  15
   7.  Mutual Attestation in EDHOC . . . . . . . . . . . . . . . . .  16
     7.1.  (IoT, BG, Fwd) - (Net, PP, Fwd) . . . . . . . . . . . . .  17
   8.  Verifier  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
     8.1.  Processing in the Background-check Model  . . . . . . . .  19



Song & Selander           Expires 23 April 2026                 [Page 2]

Internet-Draft                  RA-EDHOC                    October 2025


     8.2.  Processing in the Passport Model  . . . . . . . . . . . .  20
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     10.1.  EDHOC External Authorization Data Registry . . . . . . .  21
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     11.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Appendix A.  Example: Remote Attestation Flow . . . . . . . . . .  23
   Appendix B.  Remote attestation in parallel with enrollment
           authorization . . . . . . . . . . . . . . . . . . . . . .  24
   Appendix C.  Example: Firmware Version  . . . . . . . . . . . . .  25
   Appendix D.  Post-handshake Attestation over OSCORE . . . . . . .  27
     D.1.  Mapping Attestation to OSCORE . . . . . . . . . . . . . .  28
       D.1.1.  Flight 1  . . . . . . . . . . . . . . . . . . . . . .  28
       D.1.2.  Flight 2  . . . . . . . . . . . . . . . . . . . . . .  28
       D.1.3.  Flight 3  . . . . . . . . . . . . . . . . . . . . . .  28
     D.2.  Differences between Intra-handshake and Post-handshake
           Attestation . . . . . . . . . . . . . . . . . . . . . . .  29
       D.2.1.  Performance properties  . . . . . . . . . . . . . . .  29
       D.2.2.  Security properties . . . . . . . . . . . . . . . . .  29
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  29
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

1.  Introduction

   Remote attestation is a security process which verifies and confirms
   the integrity and trustworthiness of a remote target (e.g., device,
   system, group of devices) in the network.  This process helps
   establish a level of trust in the remote system before allowing the
   device to e.g. join the network or get access to some sensitive
   information and resources.  The use cases that require remote
   attestation include secure boot and firmware management, cloud
   computing, network access control, etc.

   The IETF working group Remote ATtestation procedureS (RATS) has
   defined an architecture [RFC9334] for remote attestation.  The three
   main roles in the RATS architecture are the Attester, the Verifier
   and the Relying Party.  The Attester generates evidence (a set of
   claims) concerning its identity and integrity, which must be
   appraised by the Verifier for its validity.  Then, the Verifier
   produces the attestation result, which is consequently used by the
   Relying Party for the purposes of reliably applying application-
   specific actions.

   One type of interaction model defined in the RATS architecture is
   called the background-check model.  It resembles the procedure of how
   employers perform background checks to determine the prospective
   employee's trustworthiness, by contacting the respective organization



Song & Selander           Expires 23 April 2026                 [Page 3]

Internet-Draft                  RA-EDHOC                    October 2025


   that issues a report.  In this case, the employer acts as the Relying
   Party, the employee acts as the Attester and the organization acts as
   the Verifier.  The Attester conveys evidence directly to the Relying
   Party and the Relying Party forwards the evidence to the Verifier for
   appraisal.  Once the attestation result is computed by the Verifier,
   it is sent back to the Relying Party to decide what action to take
   based on the attestation result.  Another model is called passport
   model, where the Attester communicates directly with the Verifier.
   The Attester presents the evidence to the Verifier and gets an
   attestation result from the Verifier.  Then the Attester conveys the
   attestation result to the Relying Party.  This specification employs
   both the RATS background-check model and the passport model.

   This document specifies the protocol between the Attester and the
   Relying Party.  The details of the protocol between the Relying Party
   and the Verifier in the background-check model, and the protocol
   between the Attester and the Verifier in the passport model are out
   of the scope.  This communication may be secured through protocols
   such as EDHOC, TLS or other security protocols that support the
   secure transmission to and from the Verifier.

   One way of conveying attestation evidence or the attestation result
   is the Entity Attestation Token (EAT) [RFC9711].  It provides an
   attested claims set which can be used to determine a level of
   trustworthiness.  This specification relies on the EAT as the format
   for attestation evidence and the attestation result.

   Ephemeral Diffie-Hellman over COSE (EDHOC) [RFC9528] is a lightweight
   authenticated key exchange protocol for highly constrained networks.
   In EDHOC, the two parties involved in the key exchange are referred
   to as the Initiator (I) and the Responder (R).  EDHOC supports the
   transport of external authorization data, through the dedicated EAD
   fields.  This specification delivers EAT through EDHOC.
   Specifically, EAT is transported as an EAD item.  This specification
   also defines new EAD items needed to perform remote attesation over
   EDHOC in Section 5.3 and Section 5.4.

   For the generation of evidence, the Attester incorporates an internal
   attestation service, including a specific trusted element known as
   the "root of trust".  Root of trust serves as the starting point for
   establishing and validating the trustworthiness appraisals of other
   components on the system.  The measurements signed by the attestation
   service are referred to as the Evidence.  The signing is requested
   through an attestation API.  How the components are separated between
   the secure and non-secure worlds on a target is out of scope of this
   specification.





Song & Selander           Expires 23 April 2026                 [Page 4]

Internet-Draft                  RA-EDHOC                    October 2025


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.

   The reader is assumed to be familiar with the terms and concepts
   defined in EDHOC [RFC9528] and RATS architecture [RFC9334].

3.  Overview

   EDHOC provides the benefit of minimal message overhead and reduced
   round trips for lightweight authentication between an Initiator and a
   Responder.  However, authentication ensures only identity-level
   security, and additional integrity assurance may be required through
   remote attestation.  This specification describes how to perform
   remote attestation over the EDHOC protocol, following the RATS
   architecture.  More importantly, by integrating remote attestation
   with EDHOC, attestation can be run in parallel with authentication,
   improving the efficiency and maintaining lightweight properties.

   Remote attestation protocol elements are carried within EDHOC's
   External Authorization Data (EAD) fields.  EDHOC [RFC9528] supports
   one or more EAD items in each EAD field.

   The Attester can act as either the EDHOC Initiator or the EDHOC
   Responder, depending on the attesting target.  In the background-
   check model, the Attester (EDHOC Initiator/IoT device) exchanges
   evidence with the Relying Party (EDHOC Responder/Network service)
   during the EDHOC session.  In the passport model, the Attester (EDHOC
   Responder/Network servie) exhcnages the attestation result with the
   Relying Party (EDHOC Initiator/IoT device) during the EDHOC session.
   Section Section 5 defines three independent dimensions for performing
   remote attestation over EDHOC:

   1.  Target (see Section 5.1, Section 5.2) defining the entity that
       undergoes the attestation process (IoT device or network
       service).

   2.  Model (see Section 5.3, Section 5.4) defining the attestation
       model in use based on the RATS architecture (background-check
       model or passport model).

   3.  Message Flow (see Section 5.5, Section 5.6) defining the EDHOC
       message flow in use (forward message flow or reverse message
       flow).



Song & Selander           Expires 23 April 2026                 [Page 5]

Internet-Draft                  RA-EDHOC                    October 2025


   This document specifies the cases that are suited for constrained IoT
   environments.  See this document [I-D.ietf-iotops-7228bis] as a
   reference for classification of IoT devices.

   The remote attestation operation defined in this document preserves
   the properties of EDHOC:

   1.  The EDHOC protocol is not modified, the remote attestation
       elements are carried within EDHOC EAD fields.

   2.  The attestation protocol is in parallel but does not interfere
       with the authentication flow.

   3.  The privacy and security properties of EDHOC are not changed.

4.  Assumptions

   In the background-check model, the Verifier is assumed to support
   verification of at least one evidence format provided by the
   Attester.  The Verifier is assumed to be provisioned with the
   Attester's attestation public key and the reference values required
   for evidence validation prior to the attestation procedure.  It is
   assumed that the Relying Party also has knowledge about the Attester,
   so it can narrow down the evidence type selection and send to the
   Attester only one format of the evidence type.

   In the passport model, the credential identity of the Verifier is
   assumed to be stored at the Attester and the Relying Party, which
   means the Verifier is trusted by the Attester and the Relying Party
   to obtain the attestation result.  If timestamps are used to ensure
   freshness in the passport model, synchronized time between the
   Attester and Relying Party is assumed.  For detailed time
   considerations, refer to Appendix A of [RFC9334].

5.  Remote Attestation in EDHOC

   This section specifies three independent dimensions that characterize
   the remote attestation process over EDHOC.

   1.  Target: Defines the entity that undergoes the attestation
       process.

   2.  Model: Defines the attestation models based on RATS architecture.
       This specification supports both the RATS background-check model
       (see Section 5.3) and the passport model (see Section 5.4).  The
       corresponding EAD items for background-check model and the
       passport model are independent of each other.




Song & Selander           Expires 23 April 2026                 [Page 6]

Internet-Draft                  RA-EDHOC                    October 2025


   3.  EDHOC message flow: The EDHOC protocol defines two possible
       message flows, namely the EDHOC forward message flow and the
       EDHOC reverse message flow (see Appendix A.2.2 of [RFC9528]).  In
       this specification, both flows can be used to perform remote
       attestation.

5.1.  Target: IoT Device Attestation (IoT)

   The IoT device acts as the Attester.

5.2.  Target: Network Service Attestation (Net)

   The network service acts as the Attester.

   This attestation pattern applies when constrained devices need to
   establish trust with a network gateway.  For example, before
   transmitting sensitive data to a network gateway, a constrained
   device requires attestation of the network gateway.

5.3.  Model: Background-check Model (BG)

   In the background-check model, the Attester sends the evidence to the
   Relying Party.  The Relying Party transfers the evidence to the
   Verifier and gets back the attestation result from the Verifier.

   An EDHOC session is established between the Attester and the Relying
   Party.  A negotiation of the evidence type is required before the
   Attester sends the evidence.  All three parties must agree on a
   selected evidence type.

   The Attester first sends a list of the proposed evidence types to the
   Relying Party.  The list is formatted as an Attestation proposal in
   an EDHOC EAD item.  The Relying Party relays the list to the Verifier
   and receives at least one supported evidence type from the Verifier
   in return.  If the Relying Party receives more than one evidence
   type, a single evidence type should be selected by the Relying Party
   based on its knowledge of the Attester.  The Relying Party then sends
   it back within the Attestation request to the Attester.

   A nonce, at least 8-bytes long [RFC9711]), guarantees the freshness
   of the attestation session.  The nonce is generated by the Verifier
   and sent to the Relying Party.  The Relying Party puts the nonce and
   the selected evidence type together in a tuple to generate an
   Attestation request.

   Once the Attester receives the Attestation request, it can call its
   attestation service to generate the evidence, with the nonce value as
   one of the inputs.



Song & Selander           Expires 23 April 2026                 [Page 7]

Internet-Draft                  RA-EDHOC                    October 2025


   The ead_label for Attestation_proposal, Attestation_request and
   Evidence is the same (TBD1) because these EAD items appear in
   distinct and fixed positions within the EDHOC message sequence.
   Specifically, they are conveyed in EAD_1, EAD_2, and EAD_3 of EDHOC
   messaage_1, EDHOC message_2, and EDHOC message_3, respectively.  As
   their positions identify each item, separate labels are not required.

5.3.1.  Attestation_proposal

   To propose a list of provided evidence types in background-check
   model, the Attester transports the Proposed_EvidenceType object.  It
   signals to the Relying Party the proposal to do remote attestation,
   as well as which types of the attestation claims the Attester
   supports.  The Proposed_EvidenceType is encoded in CBOR in the form
   of a sequence.

   The EAD item for an attestation proposal is:

   *  ead_label = TBD1

   *  ead_value = Attestation_proposal, which is a CBOR byte string:

   Attestation_proposal = bstr .cbor Proposed_EvidenceType

   Proposed_EvidenceType = [ + content-format ]

   content-format = uint

   where

   *  Proposed_EvidenceType is an array that contains all the supported
      evidence types by the Attester.

   *  There MUST be at least one item in the array.

   *  content-format is an indicator of the format type (e.g.,
      application/eat+cwt with an appropriate eat_profile parameter
      set), from [IANA-CoAP-Content-Formats].

   The sign of ead_label TBD1 MUST be negative to indicate that the EAD
   item is critical.  If the receiver (EDHOC Responder/Relying Party)
   cannot recognize the critical EAD item, or cannot process the
   information in the critical EAD item, then the receiver MUST abort
   the EDHOC session, as defined in Section 3.8 of [RFC9528].







Song & Selander           Expires 23 April 2026                 [Page 8]

Internet-Draft                  RA-EDHOC                    October 2025


5.3.2.  Attestation_request

   As a response to the attestation proposal, the Relying Party signals
   to the Attester the supported and requested evidence type.  In case
   none of the evidence types is supported, the Relying Party rejects
   the first message_1 with an error indicating support for another
   evidence type.

   The EAD item for an attestation request is:

   *  ead_label = TBD1

   *  ead_value = Attestation_request, which is a CBOR byte string:

   Attestation_request = bstr .cbor Selected_EvidenceType

   Selected_EvidenceType = (
     content-format: uint,
     nonce: bstr .size 8..64
   )

   where

   *  content-format is the selected evidence type by the Relying Party
      and supported by the Verifier.

   *  nonce is generated by the Verifier and forwarded by the Relying
      Party.

   The sign of ead_label TBD1 MUST be negative to indicate that the EAD
   item is critical.  If the receiver (EDHOC Initiator/Attester) cannot
   recognize the critical EAD item, or cannot process the information in
   the critical EAD item, then the receiver MUST abort the EDHOC
   session, as defined in Section 3.8 of [RFC9528].

5.3.3.  Evidence

   The Attester calls its local attestation service to generate and
   return a serialized Entity Attestation Token (EAT) [RFC9711] as
   Evidence.  The Evidence is sent in EAD_3 within EDHOC message_3.

   The EAD item is:

   *  ead_label = TBD1

   *  ead_value is a serialized EAT.





Song & Selander           Expires 23 April 2026                 [Page 9]

Internet-Draft                  RA-EDHOC                    October 2025


   For remote attestation over EDHOC, The EAT MUST be formatted as a
   CBOR Web Token (CWT) containing attestation-oriented claims.  The
   complete set of attestation claims for the EAT is specified in
   [RFC9711].

   A minimal claims set MAY be implemented when the Attester operates
   under constrained message size requirements and/or limited
   computational resources.

   {
   /eat-nonce/          10: bstr .size 8
   /ueid/               256: bstr .size (7..33)
   /measurements/       273: measurements-type
   }

   The measurements claim MAY be formatted according to [RFC9393].  When
   CoSWID [RFC9393] is used, the claim MUST be an evidence CoSWID rather
   than a payload CoSWID.  Formats other than CoSWID are permitted and
   MUST be identified by CoAP Content Format.

   measurements-type = [+ measurements-format]

   measurements-format = [
         content-format: uint,
         content: bytes
   ]

5.4.  Model: Passport Model (PP)

   In the passport model, the Attester sends the evidence to the
   Verifier.  After the Attester receives the attestation result from
   the Verifier, the Attester sends the attestation result to the
   Relying Party.

   An EDHOC session is established between the Attester (EDHOC
   Responder) and the Relying Party (EDHOC Initiator).  The Attester and
   the Relying Party should decide from which Verifier the Attester
   obtains the attestation result and transfers it to the Relying Party.
   The Attester first sends a list of the Verifier identities that it
   can get the attestation result.  The Relying Party selects one
   trusted Verifier identity and sends it back as a Result request.










Song & Selander           Expires 23 April 2026                [Page 10]

Internet-Draft                  RA-EDHOC                    October 2025


   Regarding the freshness in passport model, the Attester could either
   establish a real-time connection with the selected Verifier, or use a
   pre-stored attestation result from the selected Verifier.  If the
   attestation result is not obtained via a real-time connection, it
   MUST include a time stamp and/or expiry time to indicate its
   validity.  Time synchronization is out of scope of this
   specification.

   Once the Attester obtains the attestation result from the selected
   Verifier, it sends the attestation result to the Relying Party.

   The ead_label for Result_proposal, Result_request and Result is the
   same (TBD2) because these EAD items appear in distinct and fixed
   positions within the EDHOC message sequence.  Specifically, they are
   conveyed in EAD_2, EAD_3, and EAD_4 of EDHOC messaage_2, EDHOC
   message_3, and EDHOC message_4, respectively.  As their positions
   identify each item, separate labels are not required.

5.4.1.  Result_proposal

   An attestation result proposal contains the identification of the
   credentials of the Verifiers to indicate Verifiers' indentities.  The
   identification of credentials relies on COSE header parameters
   [IANA-COSE-Header-Parameters], with a header label and credential
   value.

   The EAD item for the attestation result proposal is:

   *  ead_label = TBD2

   *  ead_value = Result_proposal, which is a CBOR byte string:

   Result_proposal = bstr .cbor Proposed_VerifierIdentity
   Proposed_VerifierIdentity = [ + VerifierIdentity ]

   VerifierIdentity = {
     label => values
   }

   where

   *  Proposed_VerifierIdentity is defined as a list of one or more
      VerifierIdentity elements.

   *  Each VerifierIdentity within the list is a map defined in
      [IANA-COSE-Header-Parameters] that:

      -  label = int / tstr



Song & Selander           Expires 23 April 2026                [Page 11]

Internet-Draft                  RA-EDHOC                    October 2025


      -  values = any

5.4.2.  Result_request

   As a response to the attestation result proposal, the Relying Party
   signals to the Attester the trusted Verifier.  In case none of the
   Verifiers can be trusted by the Relying Party, the session is
   aborted.  Relying Party generates a nonce to ensure the freshness of
   the attestation result from the Verifier.

   The EAD item for an attestation result request is:

   *  ead_label = TBD2

   *  ead_value = Result_request, which is a CBOR byte string:

   Result_request = bstr .cbor Request_structure

   Request_structure = {
     selected_verifier: VerfierIdentity,
     ? nonce: bstr .size 8..64
   }

5.4.3.  Result

   The attestation result is generated and signed by the Verifier as a
   serialized EAT [RFC9711].  The Relying Party can decide what action
   to take with regards to the Attester based on the information
   elements in attetation result.

   The EAD item is:

   *  ead_label = TBD2

   *  ead_value is a serialized EAT.

5.4.4.  trigger_pp

   The EAD item trigger_pp is used when the sender (EDHOC Initiator/
   Relying Party) triggers the receiver (EDHOC Responder/Attester) to
   start a remote attestation in the passport model.  The receiver MUST
   reply with an EAD item correspondign to the passport model, either a
   result proposal in Section 5.4.1 or a result in Section 5.4.3.  The
   ead_value MUST not be present, as the ead_label serves as the
   trigger.

   The EAD item is:




Song & Selander           Expires 23 April 2026                [Page 12]

Internet-Draft                  RA-EDHOC                    October 2025


   *  ead_label = TBD3

   *  ead_value = null

5.5.  EDHOC forward Message Flow (Fwd)

   In forward message flow, EDHOC may run with the Initiator as a CoAP/
   HTTP client.  Remote attestation over EDHOC starts with a POST
   requests to the Uri-Path: "/.well-known/lake-ra".

5.6.  EDHOC reverse Message Flow (Rev)

   In the reverse message flow, the CoAP/HTTP client is the Responder
   and the server is the Initiator.  A new EDHOC session begins with an
   empty POST request to the server's resource for EDHOC.

6.  Instantiation of Remote Attestation Protocol

   We use the format (Target, Model, Message Flow) to denote
   instantiations.  For example, (IoT, BG, Fwd) represents IoT device
   attestation using the background-check model with forward EDHOC
   message flow.

   There are 8 possible instantiations combining IoT/Net, BG/PP, and
   Fwd/Rev configurations.  Considering practical feasibility, IoT
   device attestation in the passport model and Network Service
   attestation in the background model are less viable.  These
   instantiations require IoT devices to maintain multiple network
   connections and perform complex computations, which exceed the
   capabilities of typical low-power, resource-constrained IoT devices.

   In this document, only the most relevant instantiations for
   constrained IoT environments are specified.

6.1.  (IoT, BG, Fwd): IoT Device Attestation

   A common use case for (IoT, BG, Fwd) is to attest an IoT device to a
   network server.  For example, a simple illustratice case is doing
   remote attestation to verify that the latest version of firmware is
   running on the IoT device before the network server allows it to join
   the network (see Appendix C).

   An overview of doing IoT device attestation in background-check model
   and EDHOC forward message flow is established in Figure 1.  EDHOC
   Initiator plays the role of the RATS Attester (A).  EDHOC Responder
   plays the role of the RATS Relying Party (RP).  The Attester and the
   Relying Party communicate by transporting messages within EDHOC's
   External Authorization Data (EAD) fields.  An external entity, out of



Song & Selander           Expires 23 April 2026                [Page 13]

Internet-Draft                  RA-EDHOC                    October 2025


   scope of this specification, plays the role of the RATS Verifier (V).
   The EAD items specific to the background-check model are defined in
   Section 5.3.

   The Attester starts the attestation by sending an Attestation
   proposal in EDHOC message_1.  The Relying Party generates EAD_2 with
   the received evidence type and nonce from the Verifier, and sends it
   to the Attester.  The Attester sends the Evidence to the Relying
   Party in EAD_3.  The Verifier evaluates the Evidence and sends the
   Attestation result to the Relying Party.

+-----------------+              +-----------------+
|   IoT device    |              | Network service |
+-----------------+              +-----------------+
| EDHOC Initiator |              | EDHOC Responder |
+-----------------+              +-----------------+            +----------+
|     Attester    |              |  Relying Party  |            | Verifier |
+--------+--------+              +--------+--------+            +-----+----+
         |                                |                           |
         |  EAD_1 = Attestation proposal  |                           |
         +------------------------------->|                           |
         |                                |                           |
         |                                |  Attestation proposal     |
         |                                +-------------------------->|
         |                                |<--------------------------+
         |                                |  EvidenceType(s), Nonce   |
         |                                |                           |
         |  EAD_2 = Attestation request   |                           |
         |<-------------------------------+                           |
         |                                |                           |
         |  EAD_3 = Evidence              |                           |
         +------------------------------->|                           |
         |                                |         Evidence          |
         |                                +-------------------------->|
         |                                |<--------------------------+
         |                                |    Attestation result     |
         |                                |                           |
         |                                |                           |
         |                                |                           |
         | <----------------------------> |                           |
         |         EDHOC session          |                           |

   Figure 1: Overview of IoT device attestation in background-check
    model and EDHOC forward message flow.  EDHOC is used between A
                               and RP.






Song & Selander           Expires 23 April 2026                [Page 14]

Internet-Draft                  RA-EDHOC                    October 2025


6.2.  (Net, PP, Fwd): Network Service Attestation

   One use case for (Net, PP, Fwd) is when a network server needs to
   attest itself to a client (e.g., an IoT device).  For example, the
   client needs to send some sensitive data to the network server, which
   requires the network server to be attested first.  In (Net, PP, Fwd),
   the network server acts as an Attester and the client acts as a
   Relying Party.

   An overview of the message flow is illustrated in Figure 2.  EDHOC
   Initiator plays the role of the RATS Relying Party.  EDHOC Responder
   plays the role of the RATS Attester.  An external entity, out of
   scope of this specification, plays the role of the RATS Verifier.
   The EAD items specific to the passport model are defined in
   Section 5.4.

   The Relying Party asks the Attester to do a remote attestation by
   sending a trigger_pp (see Section 5.4.4) in EDHOC message_1.  The
   Attester replies to the Relying Party with a Result proposal in
   EAD_2.  Then the Relying Party selects a trusted Verifier identity
   and sends it as a Result request.  How the Attester negotiates with
   the selected Verifier to get the attestation result is out of scope
   of this specification.  A fourth EDHOC message is required to send
   the Result from the Attester to the Relying Party.



























Song & Selander           Expires 23 April 2026                [Page 15]

Internet-Draft                  RA-EDHOC                    October 2025


+-----------------+          +-----------------+
|   IoT device    |          | Network service |
+-----------------+          +-----------------+
| EDHOC Initiator |          | EDHOC Responder |
+-----------------+          +-----------------+            +----------+
|  Relying Party  |          |     Attester    |            | Verifier |
+--------+--------+          +--------+--------+            +-----+----+
         |                            |                           |
         |  EAD_1 = trigger_PP        |                           |
         +--------------------------->|                           |
         |                            |                           |
         |  EAD_2 = Result proposal   |                           |
         |<---------------------------+                           |
         |                            |                           |
         |  EAD_3 = Result request    |                           |
         +--------------------------->|     Evidence + Nonce      |
         |                            +---  ---  ---  ---  --- -->|
         |                            |<---  ---  ---  --- ---  --+
         |                            |         Result            |
         |  EAD_4 = Result            |                           |
         |<---------------------------+                           |
         |                            |                           |
         |                            |                           |
         |                            |                           |
         | <------------------------> |                           |
         |       EDHOC session        |                           |

    Figure 2: Overview of network service attestation in passport
   model and EDHOC forward message flow.  EDHOC is used between RP
    and A.  The dashed line illustrates a logical connection that
                 does not need to occur in real time.

7.  Mutual Attestation in EDHOC

   Mutual attestation over EDHOC combines the cases where one of the
   EDHOC parties uses the IoT device attestation and the other uses the
   Network service attestation.  Performing mutual attestation to a
   single EDHOC message flow acheives a lightweight use with reduced
   message overhead.  Note that the message flow for the two parties in
   mutual attestation needs to be the same.

   In this specification, we list the most relevant mutual attestation
   example for constrained IoT environments.








Song & Selander           Expires 23 April 2026                [Page 16]

Internet-Draft                  RA-EDHOC                    October 2025


7.1.  (IoT, BG, Fwd) - (Net, PP, Fwd)

   In this example, the mutual attestation is performed in EDHOC forward
   message flow, by one IoT device attestation in background-check model
   and another network service attestation in passport model.  The
   process is illustrated in Figure 3.  How the Network service connects
   with the Verifier_1 and potential Verifier_2 is out of scope in this
   specification.

   The first remote attestation is initiated by the IoT device (A_1) in
   background-check model.  In parallel, the IoT device (A_1) requests
   the network service (A_2) to perform a remote attestation in passport
   model.  EAD_2 carries the EAD items Attestation request and Result
   proposal.  EAD_3 carries the EAD items Evidence and Result request.
   EAD_4 carries the EAD item Result for the passport model.




































Song & Selander           Expires 23 April 2026                [Page 17]

Internet-Draft                  RA-EDHOC                    October 2025


+-----------------+               +-----------------+
|   IoT device    |               | Network service |
+-----------------+               +-----------------+
| EDHOC Initiator |               | EDHOC Responder |
+-----------------+               +-----------------+            +------------+              +------------+
|    A_1/RP_2     |               |    RP_1/A_2     |            | Verifier_1 |              | Verifier_2 |
+--------+--------+               +--------+--------+            +------+-----+              +------+-----+
         |                                 |                            |                           |
         |  EAD_1 = Attestation proposal,  |                            |                           |
         |          trigger_PP             |                            |                           |
         +-------------------------------->|                            |                           |
         |                                 |                            |                           |
         |                                 |                            |                           |
         |                                 |   Attestation proposal     |                           |
         |                                 +--------------------------->|                           |
         |                                 |<---------------------------+                           |
         |                                 |   EvidenceType(s), Nonce   |                           |
         |  EAD_2 = Attestation request,   |                            |                           |
         |          Result proposal        |                            |                           |
         |<--------------------------------+                            |                           |
         |                                 |                            |                           |
         |                                 |                            |                           |
         |  EAD_3 = Evidence,              |                            |                           |
         |          Result request         |                            |                           |
         +-------------------------------->|                            |                           |
         |                                 |                            |                           |
         |                                 |         Evidence           |                           |
         |                                 +--------------------------->|         (Request)         |
         |                                 +--- --- --- --- --- ---  ---+ ---  ---  --- --- --- --->|
         |                                 |                            |                           |
         |                                 |                            |                           |
         |                                 |    Attestation result      |                           |
         |                                 |<---------------------------+                           |
         |                                 |                            |                           |
         |                                 |<---  ---  ---  ---  ---  --+ ---  ---  --- ---  --- ---+
         |                                 |          Result            |                           |
         |  EAD_4 = Result                 |                            |                           |
         |<--------------------------------+                            |                           |
         |                                 |                            |                           |
         |                                 |                            |                           |
         |                                 |                            |                           |
         |                                 |                            |                           |
         | <-----------------------------> |                            |                           |
         |          EDHOC session          |                            |                           |







Song & Selander           Expires 23 April 2026                [Page 18]

Internet-Draft                  RA-EDHOC                    October 2025


     Figure 3: Overview of mutual attestation of (IoT, BG, Fwd) -
  (Net, PP, Fwd).  EDHOC is used between A and RP.  The dashed line
   illustrates a logical connection that does not need to occur in
                              real time.

8.  Verifier

   The Verifier maintains an explicit trust relationship with the
   Attester, whereby the Verifier is provisioned with the Attester's
   attestation public key prior to the remote attestation process.  This
   explicit relationship may be established through various means, such
   as manufacturer provisioning, trusted certification authorities, or
   direct configuration.  Reference values used for comparison against
   received evidence should also be provided to the Verifier before the
   attesation.  The evaluation policy employed by the Verifer varies
   according to specific use cases and should be determined prior to the
   attestation; such policy definition is out of scope in this
   specification.

   The Verifier maintains an implicit trust relationship with the
   Relying Party, established through mechanisms such as web PKI with
   trusted Certificate Authority (CA) certificates, enabling the Relying
   Party to trust the attestation result that is generated by the
   Verifier.

8.1.  Processing in the Background-check Model

   The Verifier is connected with the Relying Party and is responsible
   for evaluating evidence forwarded by the Relying Party.  After the
   Relying Party receives EDHOC message_1 from the Attester, it extracts
   and transmits the Attestation proposal to the Verifier.  The Verifier
   must support at least one evidence type for evaluation, otherwise it
   returns an empty list.  Alongside the selected evidence type, the
   Verifier generates a random nonce and sends both elements to the
   Relying Party.

   When the Relying Party obtains EDHOC message_3, it forwards the
   evidence to the Verifier for evaluation.

   The evidence evaluation process should include the verification of
   the signature, nonce validation, and measurement value comparison.
   An example evaluation procedure for evidence formatted as an Entity
   Attestation Token (EAT) within a COSE_Sign1 structure is as follows:

   1.  Decode the COSE_Sign1 structure and extract constituent
       components: Headers, Payload, Signature.

   2.  Verify the signature using the Attester's attestation public key.



Song & Selander           Expires 23 April 2026                [Page 19]

Internet-Draft                  RA-EDHOC                    October 2025


   3.  Verify that the nonce exists in the Verifier's local nonce list.
       If the nonce is found, validation passes and the nonce is removed
       from the list to prevent replay attacks.

   4.  Compare the received evidence measurement values against the
       reference value.  The attestation result is returned to the
       Relying Party, with result generation conforming to the
       attestation token format defined in [RFC9711].

8.2.  Processing in the Passport Model

   When the Attester utilizes a cached attestation result previously
   generated by the Verifier, real-time re-evaluation by the Verifier is
   not required.  If the Attester receives result_request from the
   Relying Party and performs real-time attestation with the Verifier,
   the Verifier then generates the attestation result formatted as an
   Entity Attestation Token (EAT).  The token uses the "Software
   Measurement Results (measres)" claim as defined in [RFC9711], and
   incorporates the nonce generated by the Relying Party as an input
   parameter.

9.  Security Considerations

   This specification is performed over EDHOC [RFC9528] by using EDHOC's
   EAD fields.  The privacy considerations of EADs in EDHOC apply to
   this specification.

   EAD_1 is not resistant to either active attackers or passive
   attackers, because neither the Initiator nor the Responder has been
   authenticated.

   Although EAD_2 is encrypted, the Initiator has not been
   authenticated, rendering EAD_2 vulnerable against the active
   attackers.

   The ead items in EAD_1 and EAD_2 MAY be very specific and potentially
   reveal sensitive information about the device.  The leaking of the
   data in EAD_1 and/or EAD_2 MAY risk to be used by the attackers for
   malicious purposes.  Data in EAD_3 and EAD_4 are protected between
   the Initiator and the Responder in EDHOC.

   Mutual attestation carries a lower risk for EAD items when the
   Responder is the Attester.  For the mutual attestation at the EDHOC
   Responder, only the Attestation_proposal/Result_proposal in EAD_2 is
   not protected to active attackers.  Both the Attestation_request/
   Result_request in EAD_3 and the Evidence/Result in EAD_4 are
   protected.




Song & Selander           Expires 23 April 2026                [Page 20]

Internet-Draft                  RA-EDHOC                    October 2025


10.  IANA Considerations

10.1.  EDHOC External Authorization Data Registry

   IANA is requested to register the following entry in the "EDHOC
   External Authorization Data" registry under the group name "Ephemeral
   Diffie-Hellman Over Cose (EDHOC)".

   *  The ead_label = TBD1 corresponds to the ead_value
      Attestation_proposal in Section 5.3.1, Attestation_request in
      Section 5.3.2 and Evidence in Section 5.3.3.

   *  The ead_label = TBD2 corresponds to the ead_value Result_proposal
      in Section 5.4.1, Result_request in Section 5.4.2 and the Result
      in Section 5.4.3.

   *  The ead_label = TBD3 corresponds to the EAT item trigger_pp as
      specified in Section 5.4.4.

   +-----------+-------+------------------------+-------------------+
   | Name      | Label | Description            | Reference         |
   +===========+=======+========================+===================+
   | TBD       | TBD1  | BG model               |                   |
   |           |       | related information    | Section 5.2.1.1   |
   +-----------+-------+------------------------+-------------------+
   | TBD       | TBD2  | PP model               |                   |
   |           |       | related information    | Section 5.2.2.1   |
   +-----------+-------+------------------------+-------------------+
   | TBD       | TBD3  | trigger to start       |                   |
   |           |       | attestation in PP      | Section 5.2.2.1   |
   +-----------+-------+------------------------+-------------------+

                           Figure 4: EAD labels.

11.  References

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





Song & Selander           Expires 23 April 2026                [Page 21]

Internet-Draft                  RA-EDHOC                    October 2025


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

   [RFC9711]  Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
              Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
              DOI 10.17487/RFC9711, April 2025,
              <https://www.rfc-editor.org/rfc/rfc9711>.

11.2.  Informative References

   [I-D.ietf-iotops-7228bis]
              Bormann, C., Ersue, M., Keränen, A., and C. Gomez,
              "Terminology for Constrained-Node Networks", Work in
              Progress, Internet-Draft, draft-ietf-iotops-7228bis-02, 7
              July 2025, <https://datatracker.ietf.org/doc/html/draft-
              ietf-iotops-7228bis-02>.

   [I-D.ietf-lake-authz]
              Selander, G., Mattsson, J. P., Vučinić, M., Fedrecheski,
              G., and M. Richardson, "Lightweight Authorization using
              Ephemeral Diffie-Hellman Over COSE (ELA)", Work in
              Progress, Internet-Draft, draft-ietf-lake-authz-05, 7 July
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              lake-authz-05>.

   [IANA-CoAP-Content-Formats]
              "CoAP Content-Formats", n.d.,
              <https://www.iana.org/assignments/core-parameters>.

   [IANA-COSE-Header-Parameters]
              "COSE Header Parameters", n.d.,
              <https://www.iana.org/cose/header-parameters>.

   [IANA.CWT.Claims]
              IANA, "CBOR Web Token (CWT) Claims",
              <https://www.iana.org/assignments/cwt>.

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

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/rfc/rfc8613>.




Song & Selander           Expires 23 April 2026                [Page 22]

Internet-Draft                  RA-EDHOC                    October 2025


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

   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
              W. Pan, "Remote ATtestation procedureS (RATS)
              Architecture", RFC 9334, DOI 10.17487/RFC9334, January
              2023, <https://www.rfc-editor.org/rfc/rfc9334>.

   [RFC9393]  Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
              Waltermire, "Concise Software Identification Tags",
              RFC 9393, DOI 10.17487/RFC9393, June 2023,
              <https://www.rfc-editor.org/rfc/rfc9393>.

   [RFC9668]  Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
              G. Selander, "Using Ephemeral Diffie-Hellman Over COSE
              (EDHOC) with the Constrained Application Protocol (CoAP)
              and Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 9668, DOI 10.17487/RFC9668, November 2024,
              <https://www.rfc-editor.org/rfc/rfc9668>.

Appendix A.  Example: Remote Attestation Flow

 .--------------------------.
 |     EDHOC Initiator      |       .-------------------.
 +--------------------------+       |  EDHOC Responder  |
 | Attestation   | Attester |       +-------------------+   .----------.
 | Service       |          |       |  Relying Party    |   | Verifier |
 '--+----------------+------'       '---------+---------'   '-----+----'
    |                |                        |                   |
    |                |                        |                   |
    |                |EDHOC message_1         |                   |
    |                |  {...}                 |                   |
    |                |  EAD_1(                |                   |
    |                |    types(a,b,c)        |                   |
    |                |  )                     |                   |
    |                +----------------------->|                   |
    |                |                        |                   |
    |                |                        | types(a,b,c)      |
    |                |                        +------------------>|
    |                |                        |                   |
    |                |                        |                   |
    |                |                        | Body: {           |
    |                |                        |   nonce,          |
    |                | EDHOC message_2        |   types(a,b)      |
    |                |  {...}                 | }                 |
    |                |  EAD_2(                |<------------------+



Song & Selander           Expires 23 April 2026                [Page 23]

Internet-Draft                  RA-EDHOC                    October 2025


    |                |    nonce,              |                   |
    |                |    type(a)             |                   |
    |                |  )                     |                   |
    |                |  Auth_CRED(Sig/MAC)    |                   |
    |                |<-----------------------+                   |
    |   Body:{       |                        |                   |
    |    nonce,      |                        |                   |
    |    type(a)     |                        |                   |
    |   }            |                        |                   |
    |<---------------+                        |                   |
    | Body:{         |                        |                   |
    |   Evidence     |                        |                   |
    | }              |                        |                   |
    +--------------->|                        |                   |
    |                | EDHOC message_3        |                   |
    |                |  {...}                 |                   |
    |                |  Evidence(EAT)         |                   |
    |                |  Auth_CRED(sig/MAC)    |                   |
    |                +----------------------->|                   |
    |                |                        |                   |
    |                |                        |                   |
    |                |                        |                   |
    |                |                        | Body: {           |
    |                |                        |        EAT}       |
    |                |                        +------------------>|
    |                |                        | Body: {           |
    |                |                        |  att-result: AR{} |
    |                |                        | }                 |
    |                |                        |<------------------+
    |                |                        +---.               |
    |                |                        |    | verify AR{}  |
    |                |                        |<--'               |
    |                |                        |                   |
    |                |    application data    |                   |
    |                |<---------------------->|                   |
    |                |                        |                   |

                Figure 5: Example of remote attestation.

Appendix B.  Remote attestation in parallel with enrollment
             authorization

   This section discusses the possibility of doing remote attestation in
   parallel with the enrollment authorization procedure defined in
   [I-D.ietf-lake-authz].  In this case, the message count is much
   decreased.

   The detailed procedure is TBD.



Song & Selander           Expires 23 April 2026                [Page 24]

Internet-Draft                  RA-EDHOC                    October 2025


Appendix C.  Example: Firmware Version

   The goal in this example is to verify that the firmware running on
   the device is the latest version, and is neither tampered or
   compromised.  A device acts as the Attester, currently in an
   untrusted state.  The Attester needs to generate the evidence to
   attest itself.  A gateway that can communicate with the Attester and
   can control its access to the network acts as the Relying Party.  The
   gateway will finally decide whether the device can join the network
   or not depending on the attestation result.  The attestation result
   is produced by the Verifier, which is a web server that can be seen
   as the manufacturer of the device.  Therefore it can appraise the
   evidence that is sent by the Attester.  The remote attestation
   session starts with the Attester sending EAD_1 in EDHOC message 1.

   An example of the EAD_1 in EDHOC message_1 could be:

   [60,61,258]

   If the Verifier and the Relying Party can support at least one
   evidence type that is proposed by the Attester, the Relying Party
   will include in the EAD_2 field the same evidence type, alongside a
   nonce for message freshness.

   (258, h'a29f62a4c6cdaae5')

   The Evidence in EAD_3 field is an Entity Attestation Token (EAT)
   [RFC9711], with the measurements claim formatted in CoSWID[RFC9393].
   The components of the Evidence should at least be:






















Song & Selander           Expires 23 April 2026                [Page 25]

Internet-Draft                  RA-EDHOC                    October 2025


{
/eat-nonce/                 10: h'a29f62a4c6cdaae5',
/ueid/                      256: 'aaabbcc',
/measurements/              273: [
  /CoAP Content-Format ID/        [ 258,
  /evidence in CoSWID/              {
                                      0: 'tagID'             /tag-id/
                                      12: 0                  /tag-version/
                                      1: "DotBot firmware"   /software-name/
                                      2: {                   /entity/
                                          31: "Attester"     /entity-name/
                                          33: 1              /role, must be "tag-creator" which is 1/
                                          },
                                      3: {                   /evidence/
                                          17: [              /file/
                                               {
                                                24: "partition0-nrf52840dk.bin",   /fs-name/
                                                7: [                               /hash of file/
                                                    1,                             /alg SHA-256/
                                                    h'06294f6806b9c685eea795048579cfd02a0c025bc8b5abca42a19ea0ec23e81a'
                                                    ]                              /hash value/
                                                }
                                               ]
                                          }
                                    }
                                  ]
                                 ]
}

   The infomation above serves as the payload of the COSE object.  The
   complete resulting COSE object is:




















Song & Selander           Expires 23 April 2026                [Page 26]

Internet-Draft                  RA-EDHOC                    October 2025


18([
    /*protected header*/
    h'a10127',

    /*unprotected header*/
    {},

    /*payload*/
    h'A30A48A29F62A4C6CDAAE519010047616161626263631901118182190102A50045746
    16749440C00016F446F74426F74206669726D7761726502A2181F684174746573746572
    18210103A11181A218187819706172746974696F6E302D6E72663532383430646B2E626
    96E078201582006294F6806B9C685EEA795048579CFD02A0C025BC8B5ABCA42A19EA0EC
    23E81A',

    /*signature*/
    h'd4100901f4c3e51312c3110c6ddc8dcf7f68d8f5d3791c19133f2f0ac158c1f5ee6ed
    afe9d7c3d6eb3d2d197f82e733d375fdda9fb258b304961dfc38558950d'
])

   which has the following base16 encoding:

 D28443A10127A05890A30A48A29F62A4C6CDAAE51901004761616162626363190111818
 2190102A5004574616749440C00016F446F74426F74206669726D7761726502A2181F68
 417474657374657218210103A11181A218187819706172746974696F6E302D6E7266353
 2383430646B2E62696E078201582006294F6806B9C685EEA795048579CFD02A0C025BC8
 B5ABCA42A19EA0EC23E81A5840D4100901F4C3E51312C3110C6DDC8DCF7F68D8F5D3791
 C19133F2F0AC158C1F5EE6EDAFE9D7C3D6EB3D2D197F82E733D375FDDA9FB258B304961
 DFC38558950D

   The Relying Party (co-located with the gateway) then treats the
   Evidence as opaque and sends it to the Verifier.  Once the Verifier
   sends back the Attestation Result, the Relying Party can be assured
   on the version of the firmware that the device is running.

Appendix D.  Post-handshake Attestation over OSCORE

   Beyond the intra-handshake attestation defined in this document,
   remote attestation after an EDHOC session can be performed via post-
   handshake attestation over Object Security for Constrained RESTful
   Environments (OSCORE) [RFC8613].  OSCORE provides application-layer
   protection for the Constrained Application Protocol (CoAP) using CBOR
   Object Signing and Encryption (COSE).  As specified in [RFC9668],
   EDHOC can run over CoAP to establish a Security Context for OSCORE.

   Post-handshake attestation decouples attestation process from the
   initial handshake, enabling continuous attestation throughout the
   session lifetime and guaranteeing the runtime integrity.




Song & Selander           Expires 23 April 2026                [Page 27]

Internet-Draft                  RA-EDHOC                    October 2025


D.1.  Mapping Attestation to OSCORE

   This section outlines how remote attestation is performed in the
   background-check model over OSCORE.

   EDITOR NOTE: put a figure

D.1.1.  Flight 1

   The CoAP client (Attester) initiates attestation with a CoAP request:

   *  The request method is POST.

   *  The Uri-path is set to ".well-known/attest".

   *  The payload is the Attestation_proposal CBOR sequence, where
      Attestation_proposal is constructed as defined in Section 5.3.1.

D.1.2.  Flight 2

   The CoAP server (Relying Party) receives the request and processes it
   as described in Section 5.3 then prepares Attestation_request as
   defined in Section 5.3.2.  The CoAP server maps the message to a CoAP
   response:

   *  The response code is 2.04 Changed.

   *  The payload is the Attestation_request CBOR sequence, as defined
      in Section 5.3.2.

D.1.3.  Flight 3

   The CoAP client (Attester) receives the response and processes it as
   described in Section 5.3 then generates the evidence.  The CoAP
   client maps the message to a CoAP request:

   *  The request method is POST.

   *  The Uri-path is set to ".well-known/attest".

   *  The payload is the Evidence CBOR sequence, as defined in
      Section 5.3.3.









Song & Selander           Expires 23 April 2026                [Page 28]

Internet-Draft                  RA-EDHOC                    October 2025


D.2.  Differences between Intra-handshake and Post-handshake Attestation

   Intra-handshake attestation embeds evidence exchange into the
   authentication handshake, cryptographically tying identity to device
   state and blocking unauthenticated and untrusted devices from
   completing the handshake.  Post-handshake attestation separates
   attestation from the authentication handshake, providing modularity
   that allows attestation mechanisms to be integrated independently of
   the handshake protocol.  This section compares the two different
   types of remote attestation methods in terms of performance and
   security properties.

D.2.1.  Performance properties

   Intra-handshake attestation provides round-trip efficiency as
   attestation occurs within the handshake, requiring no additional
   round trips.  The intra-handshake attestation defined in this
   document does not modify the EDHOC protocol itself, though other
   intra-handshake designs may require changes.  Post-handshake has
   higher modularity which the attestation is integrated independently
   but it requires additional round trips.

D.2.2.  Security properties

   Remote attestation provides security properties including evidence
   integrity, freshness guarantees, and replay protection.  Besides,
   intra-handshake attestation is cryptographically bound to the
   authentication process, and the trust is established before the
   session begins.  Post-handshake attestation gurantees the runtime
   integrity which can obtain dynamic mesurements during device
   execution, and can be repeatedly performed throughout the session
   which has the continuous assurance.

Acknowledgments

   The author would like to thank Thomas Fossati, Malisa Vucinic, Ionut
   Mihalcea, Muhammad Usama Sardar, Michael Richardson and Geovane
   Fedrecheski for the provided ideas and feedback.

   Work on this document has in part been supported by the Horizon
   Europe Framework Programme project OpenSwarm (grant agreement No.
   101093046).

Authors' Addresses

   Yuxuan Song
   Inria
   Email: yuxuan.song@inria.fr



Song & Selander           Expires 23 April 2026                [Page 29]

Internet-Draft                  RA-EDHOC                    October 2025


   Göran Selander
   Ericsson AB
   Email: goran.selander@ericsson.com
















































Song & Selander           Expires 23 April 2026                [Page 30]


name: draft-ietf-ace-edhoc-oscore-profile
rev: 09
time: 2025-10-20T15:20:51Z
group_uri: /api/v1/group/group/1921/
expires: 2026-04-23T15:08:26Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Agent identity/auth", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:09.014905+00:00
title:
Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE)

abstract:
This document specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework.  It
   utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving
   mutual authentication between an ACE-OAuth client and resource
   server, and it binds an authentication credential of the client to an
   ACE-OAuth access token.  EDHOC also establishes an Object Security
   for Constrained RESTful Environments (OSCORE) Security Context, which
   is used to secure communications between the client and resource
   server when accessing protected resources according to the
   authorization information indicated in the access token.  This
   profile can be used to delegate management of authorization
   information from a resource-constrained server to a trusted host with
   less severe limitations regarding processing power and memory.

full_text:
ACE Working Group                                            G. Selander
Internet-Draft                                         J. Preuß Mattsson
Intended status: Standards Track                                Ericsson
Expires: 23 April 2026                                         M. Tiloca
                                                              R. Höglund
                                                                    RISE
                                                         20 October 2025


   Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for
    Constrained Environments (OSCORE) Profile for Authentication and
            Authorization for Constrained Environments (ACE)
                 draft-ietf-ace-edhoc-oscore-profile-09

Abstract

   This document specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework.  It
   utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving
   mutual authentication between an ACE-OAuth client and resource
   server, and it binds an authentication credential of the client to an
   ACE-OAuth access token.  EDHOC also establishes an Object Security
   for Constrained RESTful Environments (OSCORE) Security Context, which
   is used to secure communications between the client and resource
   server when accessing protected resources according to the
   authorization information indicated in the access token.  This
   profile can be used to delegate management of authorization
   information from a resource-constrained server to a trusted host with
   less severe limitations regarding processing power and memory.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-ace-edhoc-oscore-
   profile/.

   Discussion of this document takes place on the Authentication and
   Authorization for Constrained Environments (ace) Working Group
   mailing list (mailto:ace@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/ace/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/ace/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ace-wg/ace-edhoc-oscore-profile.





Selander, et al.          Expires 23 April 2026                 [Page 1]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


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 23 April 2026.

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  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Client-AS Communication . . . . . . . . . . . . . . . . . . .  10
     3.1.  C-to-AS: POST to /token endpoint  . . . . . . . . . . . .  11
     3.2.  Token Series  . . . . . . . . . . . . . . . . . . . . . .  14
     3.3.  AS-to-C: Response . . . . . . . . . . . . . . . . . . . .  15
       3.3.1.  Access Token  . . . . . . . . . . . . . . . . . . . .  17
       3.3.2.  Processing at C . . . . . . . . . . . . . . . . . . .  19
       3.3.3.  Update of Access Rights . . . . . . . . . . . . . . .  19
     3.4.  EDHOC_Information . . . . . . . . . . . . . . . . . . . .  20
   4.  Client-RS Communication . . . . . . . . . . . . . . . . . . .  28
     4.1.  EAD items for Access Token and Session Identifier . . . .  29
     4.2.  EDHOC Session . . . . . . . . . . . . . . . . . . . . . .  30
     4.3.  Forward Message Flow  . . . . . . . . . . . . . . . . . .  32



Selander, et al.          Expires 23 April 2026                 [Page 2]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


       4.3.1.  EDHOC message_1 . . . . . . . . . . . . . . . . . . .  32
       4.3.2.  EDHOC message_2 . . . . . . . . . . . . . . . . . . .  33
       4.3.3.  EDHOC message_3 . . . . . . . . . . . . . . . . . . .  33
     4.4.  Reverse Message Flow  . . . . . . . . . . . . . . . . . .  33
       4.4.1.  Trigger Message . . . . . . . . . . . . . . . . . . .  34
       4.4.2.  EDHOC message_1 . . . . . . . . . . . . . . . . . . .  34
       4.4.3.  EDHOC message_2 . . . . . . . . . . . . . . . . . . .  34
       4.4.4.  EDHOC message_3 . . . . . . . . . . . . . . . . . . .  35
       4.4.5.  EDHOC message_4 . . . . . . . . . . . . . . . . . . .  35
     4.5.  OSCORE Security Context . . . . . . . . . . . . . . . . .  36
     4.6.  Update of Access Rights . . . . . . . . . . . . . . . . .  36
       4.6.1.  C-to-RS: POST to /authz-info endpoint . . . . . . . .  37
       4.6.2.  RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . .  38
     4.7.  Discarding the OSCORE Security Context  . . . . . . . . .  38
     4.8.  Establishing a New OSCORE Security Context  . . . . . . .  39
     4.9.  Access Rights Verification  . . . . . . . . . . . . . . .  40
     4.10. Access Token Invalidity . . . . . . . . . . . . . . . . .  40
     4.11. Authentication Credential Invalidity  . . . . . . . . . .  40
     4.12. EDHOC Session Invalidity  . . . . . . . . . . . . . . . .  41
     4.13. Using AS Request Creation Hints . . . . . . . . . . . . .  41
     4.14. Requesting Authentication Credential By Value . . . . . .  43
   5.  Secure Communication with AS  . . . . . . . . . . . . . . . .  44
   6.  CWT Confirmation Methods  . . . . . . . . . . . . . . . . . .  45
     6.1.  Ordered Chain of X.509 Certificates . . . . . . . . . . .  45
     6.2.  Unordered Bag of X.509 Certificates . . . . . . . . . . .  45
     6.3.  Hash of an X.509 Certificate  . . . . . . . . . . . . . .  45
     6.4.  URI Pointing to an Ordered Chain of X.509 Certificates  .  45
     6.5.  Ordered Chain of C509 Certificates  . . . . . . . . . . .  45
     6.6.  Unordered Bag of C509 Certificates  . . . . . . . . . . .  46
     6.7.  Hash of a C509 Certificate  . . . . . . . . . . . . . . .  46
     6.8.  URI Pointing to an Ordered Chain of C509 Certificates . .  46
     6.9.  CWT Containing a COSE_Key . . . . . . . . . . . . . . . .  46
     6.10. CCS Containing a COSE_Key . . . . . . . . . . . . . . . .  46
   7.  JWT Confirmation Methods  . . . . . . . . . . . . . . . . . .  46
     7.1.  Ordered Chain of X.509 Certificates . . . . . . . . . . .  47
     7.2.  Unordered Bag of X.509 Certificates . . . . . . . . . . .  47
     7.3.  Hash of an X.509 Certificate  . . . . . . . . . . . . . .  47
     7.4.  URI Pointing to an Ordered Chain of X.509 Certificates  .  47
     7.5.  Ordered Chain of C509 Certificates  . . . . . . . . . . .  47
     7.6.  Unordered Bag of C509 Certificates  . . . . . . . . . . .  48
     7.7.  Hash of a C09 Certificate . . . . . . . . . . . . . . . .  48
     7.8.  URI Pointing to an Ordered Chain of C509 Certificates . .  48
     7.9.  CWT Containing a COSE_Key . . . . . . . . . . . . . . . .  48
     7.10. CCS Containing a COSE_Key . . . . . . . . . . . . . . . .  48
   8.  EDHOC Endpoint Identity Types . . . . . . . . . . . . . . . .  49
   9.  EDHOC Transports  . . . . . . . . . . . . . . . . . . . . . .  49
   10. EDHOC Trust Anchor Purposes . . . . . . . . . . . . . . . . .  50
   11. EDHOC Trust Anchor Types  . . . . . . . . . . . . . . . . . .  50



Selander, et al.          Expires 23 April 2026                 [Page 3]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   12. Security Considerations . . . . . . . . . . . . . . . . . . .  51
   13. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  53
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  53
     14.1.  ACE Profiles Registry  . . . . . . . . . . . . . . . . .  54
     14.2.  OAuth Parameters Registry  . . . . . . . . . . . . . . .  54
     14.3.  OAuth Parameters CBOR Mappings Registry  . . . . . . . .  54
     14.4.  JSON Web Token Claims Registry . . . . . . . . . . . . .  55
     14.5.  CBOR Web Token (CWT) Claims Registry . . . . . . . . . .  55
     14.6.  JWT Confirmation Methods Registry  . . . . . . . . . . .  55
     14.7.  CWT Confirmation Methods Registry  . . . . . . . . . . .  58
     14.8.  EDHOC External Authorization Data Registry . . . . . . .  61
     14.9.  EDHOC Information Registry . . . . . . . . . . . . . . .  62
     14.10. EDHOC Endpoint Identity Types Registry . . . . . . . . .  63
     14.11. EDHOC Transports Registry  . . . . . . . . . . . . . . .  64
     14.12. EDHOC Trust Anchor Purposes Registry . . . . . . . . . .  65
     14.13. EDHOC Trust Anchor Types Registry  . . . . . . . . . . .  66
     14.14. Expert Review Instructions . . . . . . . . . . . . . . .  67
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  68
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  68
     15.2.  Informative References . . . . . . . . . . . . . . . . .  72
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  74
     A.1.  Workflow without Optimizations  . . . . . . . . . . . . .  75
     A.2.  Workflow with Optimizations . . . . . . . . . . . . . . .  79
     A.3.  Non-sequential Workflow . . . . . . . . . . . . . . . . .  81
   Appendix B.  Profile Requirements . . . . . . . . . . . . . . . .  83
   Appendix C.  CDDL Model . . . . . . . . . . . . . . . . . . . . .  85
   Appendix D.  Document Updates . . . . . . . . . . . . . . . . . .  87
     D.1.  Version -08 to -09  . . . . . . . . . . . . . . . . . . .  87
     D.2.  Version -07 to -08  . . . . . . . . . . . . . . . . . . .  87
     D.3.  Version -06 to -07  . . . . . . . . . . . . . . . . . . .  87
     D.4.  Version -05 to -06  . . . . . . . . . . . . . . . . . . .  88
     D.5.  Version -04 to -05  . . . . . . . . . . . . . . . . . . .  89
     D.6.  Version -03 to -04  . . . . . . . . . . . . . . . . . . .  89
     D.7.  Version -02 to -03  . . . . . . . . . . . . . . . . . . .  90
     D.8.  Version -01 to -02  . . . . . . . . . . . . . . . . . . .  90
     D.9.  Version -00 to -01  . . . . . . . . . . . . . . . . . . .  90
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  91
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  91

1.  Introduction

   This document defines the "coap_edhoc_oscore" profile of the ACE-
   OAuth framework [RFC9200].  This profile addresses a "zero-touch"
   constrained setting where authenticated and authorized operations can
   be performed with low overhead without endpoint specific
   configurations.





Selander, et al.          Expires 23 April 2026                 [Page 4]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   Like in the "coap_oscore" profile [RFC9203], also in this profile a
   client (C) and a resource server (RS) use the Constrained Application
   Protocol (CoAP) [RFC7252] to communicate, and Object Security for
   Constrained RESTful Environments (OSCORE) [RFC8613] to protect their
   communications.  However, this profile uses the Ephemeral Diffie-
   Hellman Over COSE (EDHOC) protocol [RFC9528] to establish the OSCORE
   Security Context.  The processing of requests for specific protected
   resources is identical to what is defined in the "coap_oscore"
   profile.

   When using this profile, C accesses protected resources hosted at RS
   according to the authorization information specified in an access
   token, which is issued by a trusted authorization server (AS) and is
   bound to an authentication credential of C.  This differs from the
   "coap_oscore" profile, where the access token is bound to a secret
   that is generated by AS and is used to derive the OSCORE Security
   Context.

   Whereas [RFC9200] recommends the use of CBOR Web Tokens (CWTs)
   [RFC8392] as access tokens, this profile requires it (see
   Section 3.3.1).  Furthermore, this profile requires that, for
   messages exchanged between C and AS to request and provide an access
   token, the payload is encoded in CBOR [RFC8949] (see Section 3.1 and
   Section 3.3), which ACE requires if CoAP is used (see Section 5 of
   [RFC9200]) and recommends otherwise (see Section 3 of [RFC9200]).

   An authentication credential can be a raw public key, e.g., encoded
   as a CWT Claims Set (CCS) [RFC8392]; or a public key certificate,
   e.g., an X.509 certificate [RFC5280] or a CBOR-encoded C509
   certificate [I-D.ietf-cose-cbor-encoded-cert]); or a different type
   of data structure containing the public key of the peer in question.

   The ACE framework establishes what those authentication credentials
   are, and may transport the actual authentication credentials by value
   or uniquely refer to them.  If an authentication credential is pre-
   provisioned or can be obtained over less constrained links, then it
   suffices that ACE provides a unique reference such as a certificate
   hash (e.g., by using the COSE header parameter "x5t" [RFC9360]).
   This is in the same spirit as EDHOC, where the authentication
   credentials specified in the ID_CRED_x message fields can be
   transported by value or referred to (see Section 3.5.3 of [RFC9528]).










Selander, et al.          Expires 23 April 2026                 [Page 5]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   In general, AS and RS are likely to have trusted access to each
   other's authentication credentials, since AS acts on behalf of RS as
   per the trust model of ACE.  Also, AS needs to have some information
   about C, including the relevant authentication credential, in order
   to identify C when it requests an access token and to determine what
   access rights it can be granted.  However, the authentication
   credential of C may potentially be conveyed (or uniquely referred to)
   within the request for an access token that C makes to AS.

   The establishment of an association between RS and AS in an ACE
   ecosystem is out of scope, but one solution is to build on the same
   primitives as used in this document, i.e., EDHOC for authentication
   and OSCORE for communication security, using for example
   [I-D.ietf-lake-authz] for onboarding RS with AS and
   [I-D.ietf-ace-coap-est-oscore] for establishing a trust anchor in RS.
   A similar procedure can also be applied between C and AS for
   registering a client and for the establishment of a trust anchor.

1.1.  Terminology

   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.

   Certain security-related terms such as "authentication",
   "authorization", "confidentiality", "(data) integrity", "Message
   Authentication Code (MAC)", "Hash-based Message Authentication Code
   (HMAC)", and "verify" are taken from [RFC4949].

   RESTful terminology follows HTTP [RFC9110].

   Readers are expected to be familiar with the terms and concepts
   defined in CoAP [RFC7252], OSCORE [RFC8613], and EDHOC [RFC9528].

   Readers are also expected to be familiar with the terms and concepts
   of the ACE framework described in [RFC9200] and in [RFC9201].

   Terminology for entities in the architecture is defined in OAuth 2.0
   [RFC6749], such as the client (C), the resource server (RS), and the
   authorization server (AS).  It is assumed in this document that a
   given resource on a specific RS is associated with a unique AS.








Selander, et al.          Expires 23 April 2026                 [Page 6]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   Note that the term "endpoint" is used here, as in [RFC9200],
   following its OAuth definition, which is to denote resources such as
   /token and /introspect at AS, and /authz-info at RS.  The CoAP
   [RFC7252] definition, which is "An entity participating in the CoAP
   protocol", is not used in this document.

   The authorization information (authz-info) resource refers to the
   authorization information endpoint as specified in [RFC9200].  The
   term "claim" is used in this document with the same semantics as in
   [RFC9200], i.e., it denotes information carried in the access token
   or returned from introspection.

   Concise Binary Object Representation (CBOR) [RFC8949][RFC8742] and
   Concise Data Definition Language (CDDL) [RFC8610] are used in this
   document.  CDDL predefined type names, especially bstr for CBOR byte
   strings and tstr for CBOR text strings, are used extensively in this
   document.

   Examples throughout this document are expressed in CBOR diagnostic
   notation as defined in Section 8 of [RFC8949] and Appendix G of
   [RFC8610].  Diagnostic notation comments are often used to provide a
   textual representation of the numeric parameter names and values.

   In the CBOR diagnostic notation used in this document, constructs of
   the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME
   in the CDDL model shown in Figure 11 of Appendix C.  For example,
   {e'session_id' : h'01', e'cipher_suites': 3} stands for {0 : h'01', 2
   : 3}.

   Note to RFC Editor: Please delete the paragraph immediately preceding
   this note.  Also, in the CBOR diagnostic notation used in this
   document, please replace the constructs of the form e'SOME_NAME' with
   the value assigned to SOME_NAME in the CDDL model shown in Figure 11
   of Appendix C.  Finally, please delete this note.

2.  Protocol Overview

   This section gives an overview of how to use the ACE framework
   [RFC9200] together with the lightweight authenticated key exchange
   protocol EDHOC [RFC9528].  By doing so, the client (C) and the
   resource server (RS) generate an OSCORE Security Context [RFC8613]
   associated with authorization information, and use that Security
   Context to protect their communications.  The parameters needed by C
   to negotiate the use of this profile with the authorization server
   (AS), as well as the OSCORE setup process, are described in detail in
   the following sections.





Selander, et al.          Expires 23 April 2026                 [Page 7]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   RS maintains a collection of authentication credentials.  These are
   associated with OSCORE Security Contexts and with authorization
   information for all clients that RS is communicating with.  The
   authorization information is used to enforce policies for processing
   requests from those clients.

   The ACE framework describes how integrity protected authorization
   information propagates from AS to RS.  This profile describes how C
   requests from AS an access token specifying authorization information
   for the resources that C wants to access at RS, by sending an access
   token request to the /token endpoint at AS (see Section 5.8 of
   [RFC9200]).

   If the request is granted, then AS can provide C with an access token
   when sending a response to C, or instead upload the access token
   directly to RS as per the alternative workflow defined in
   [I-D.ietf-ace-workflow-and-params].  The latter option is not
   detailed further in this document.

   After that, C and RS run the EDHOC protocol, with C using the
   authentication credential of RS obtained from AS.  If C has obtained
   an access token from AS, then C specifies the access token within an
   External Authorization Data (EAD) field of an EDHOC message sent
   during the EDHOC session (see Section 3.8 of [RFC9528]).  RS uses the
   authentication credential of C bound to and specified in the access
   token.  How C and RS run EDHOC is detailed in Section 4.2.

   If C and RS successfully complete the EDHOC execution and the
   validation of each other's authentication credential, they are
   mutually authenticated and derive the OSCORE Security Context as per
   Appendix A.1 of [RFC9528].

   Figure 1 outlines an example of the message flow.  A more detailed
   description of the message flow is shown in Appendix A.1.

   From then on and as long as there is a valid access token, C
   effectively gains authorized and secure access to protected resources
   at RS using the established OSCORE Security Context.  When RS
   receives a request from C protected with an OSCORE Security Context
   derived from an EDHOC session implementing this profile, then that
   OSCORE Security Context is used to retrieve the uniquely associated
   access token determining the access rights of C.

   The OSCORE Security Context is discarded when an access token
   (whether the same or a different one) is used to successfully derive
   a new OSCORE Security Context for C.





Selander, et al.          Expires 23 April 2026                 [Page 8]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


      C                            RS                       AS
      |                            |                         |
      | <==== Mutual authentication and secure channel ====> |
      |                            |                         |
      +-------- POST /token  ------------------------------->|
      |                            |                         |
      |<--------------------------------- Access Token ------+
      |                               + Access Information   |
      |                            |                         |
      +------- POST /edhoc  ------>|                         |
      |     (EDHOC message_1)      |                         |
      |                            |                         |
      |<------ 2.04 Changed -------+                         |
      |     (EDHOC message_2)      |                         |
      |                            |                         |
   / Derivation of OSCORE          |                         |
   Security Context /              |                         |
      |                            |                         |
      +------- POST /edhoc  ------>|                         |
      |   (EDHOC message_3 with    |                         |
      |   access_token in EAD_3)   |                         |
      |                            |                         |
      |                / Derivation of OSCORE                |
      |                  Security Context /                  |
      |                            |                         |
      +----- OSCORE Request ------>|                         |
      |                            |                         |
      |<---- OSCORE Response ------|                         |
      |                            |                         |

      Figure 1: Protocol Outline using the EDHOC Forward Message Flow.

   As long as the OSCORE Security Context and the access token are
   valid, C can contact AS to request an update of its access rights, by
   sending a similar request as described above to the /token endpoint.
   This request also includes a "session identifier" (see Section 3.4)
   provided by AS in the response to the initial access token request,
   which allows AS to retrieve the data that it previously shared with
   C.  The session identifier is assigned by AS and used to identify a
   series of access tokens, called a "token series" (see Section 3.2).

   If C has obtained an access token from AS for updating its access
   rights belonging to the same token series, then C transfers the
   access token to RS using the /authz-info endpoint as specified in
   Section 5.10 of [RFC9200], where the exchanged CoAP messages are
   protected by the previously established OSCORE Security Context (see
   Section 4.6).  If the access token is valid, RS replies to the
   request with a 2.01 (Created) response.



Selander, et al.          Expires 23 April 2026                 [Page 9]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   Upon successful update of access rights, the new issued access token
   effectively becomes the latest in its token series also for RS, but
   the session identifier remains the same.  When the latest access
   token of a token series becomes invalid (e.g., when it expires or
   gets revoked), that token series ends.

   Figure 2 outlines the message flow for updating access rights.

      C                            RS                       AS
      |                            |                         |
      | <====         Existing security context        ====> |
      |                            |                         |
      +-------- POST /token  ------------------------------->|
      |                            |                         |
      |<--------------------------------- Access Token ------+
      |                               + Access Information   |
      |                            |                         |
      +--- POST /authz-info  ----->|                         |
      |  (OSCORE protected with    |                         |
      |   access_token in payload) |                         |
      |                            |                         |
      |               / Updated access rights /              |
      |                            |                         |
      |<------ 2.04 Changed -------+                         |
      |                            |                         |
      |                            |                         |
      +----- OSCORE Request ------>|                         |
      |                            |                         |
      |<---- OSCORE Response ------|                         |
      |                            |                         |

           Figure 2: Protocol Outline for Updating Access Rights.

3.  Client-AS Communication

   The following subsections describe the details of the POST request
   and response to the /token endpoint between C and AS.

   In this exchange, C provides AS with its own authentication
   credential AUTH_CRED_C.  Then, AS issues the access token as securely
   bound to AUTH_CRED_C, by including it or uniquely referring to it in
   the access token.  Together with the access token, AS provides C with
   a set of parameters that enable C to run EDHOC with RS.  In
   particular, these parameters include information about the
   authentication credential AUTH_CRED_RS of RS, which is transported by
   value or uniquely referred to.





Selander, et al.          Expires 23 April 2026                [Page 10]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   The request to the /token endpoint and the corresponding response can
   include EDHOC_Information, which is a CBOR map object containing
   information related to an EDHOC implementation (see Section 3.4).
   This object is transported in the "edhoc_info" parameter registered
   in Section 14.2 and Section 14.3.

3.1.  C-to-AS: POST to /token endpoint

   The client-to-AS request is specified in Section 5.8.1 of [RFC9200].

   The client MUST send this POST request to the /token endpoint over a
   secure channel that guarantees authentication, message integrity, and
   confidentiality (see Section 5).

   When using this profile, the payload of the POST request MUST be
   encoded in CBOR [RFC8949], i.e., the request has media-type
   "application/ace+cbor".  In order to reduce the number of libraries
   that C has to support, it is RECOMMENDED that C and AS use CoAP as
   message transfer protocol, OSCORE as security protocol, and EDHOC to
   establish an OSCORE Security Context.

   AUTH_CRED_C is specified in the "req_cnf" parameter [RFC9201] of the
   POST request, either transported by value or uniquely referred to.
   AS could explicitly ask C to provide its authentication credential
   AUTH_CRED_C by value in the Access Token Request, e.g., by relying on
   the method defined in [I-D.ietf-ace-workflow-and-params].

   For AUTH_CRED_C, its authentication credential type MUST be one of
   those supported by EDHOC, e.g., CBOR Web Tokens (CWTs) and CWT Claims
   Sets (CCSs) [RFC8392], X.509 certificates [RFC5280], and C509
   certificates [I-D.ietf-cose-cbor-encoded-cert].  Consequently, the
   "req_cnf" parameter MUST specify a confirmation method suitable for
   the type of AUTH_CRED_C, e.g., "x5chain" or "x5t" when AUTH_CRED_C is
   an X.509 certificate transported by value or referred to,
   respectively.

   Note that EDHOC does not admit the use of "naked" COSE_Keys as
   authentication credentials.  The closest admitted authentication
   credential type is a CCS containing a COSE_Key in a "cnf" claim and
   possibly other claims, which can be transported by value using the
   confirmation method "kccs".  Therefore, the "req_cnf" parameter MUST
   NOT specify the confirmation method "COSE_Key" (CBOR abbreviation:
   1).

   When receiving an Access Token request including the "req_cnf"
   parameter, AS checks whether it is already storing the authentication
   credential of C, namely AUTH_CRED_C, specified in "req_cnf" by value
   or reference.



Selander, et al.          Expires 23 April 2026                [Page 11]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   If this is not the case, AS retrieves AUTH_CRED_C, either using the
   "req_cnf" parameter or some other trusted source.  After that, AS
   validates the actual AUTH_CRED_C.

   In either case, the AS also needs to verify that C is in possession
   of the private key corresponding to the public key associated with
   AUTH_CRED_C.  This may already have been accomplished, for example,
   by C authenticating to AS using AUTH_CRED_C as authentication
   credential, or by some other trusted party vouching for C to the AS.
   Alternatively, it is possible to use an approach for achieving proof-
   of-possession similar to that in Section 3.2 of
   [I-D.ietf-ace-group-oscore-profile].

   In case of successful validations, AS stores AUTH_CRED_C as a valid
   authentication credential.  Otherwise, the Client-to-AS request MUST
   be declined.

   An example of client-to-AS request is shown in Figure 3.  In this
   example, C specifies its own authentication credential by reference,
   as the hash of an X.509 certificate carried in the "x5t" field of the
   "req_cnf" parameter.

      Header: POST (Code=0.02)
      Uri-Host: "as.example.com"
      Uri-Path: "token"
      Content-Format: application/ace+cbor
      Payload:
      {
        / audience / 5 : "tempSensor4711",
        / scope /    9 : "read",
        / req_cnf /  4 : {
          e'x5t' : [-15, h'79F2A41B510C1F9B']
        }
      }

   Figure 3: Example of C-to-AS POST /token request for an access token.

   If C wants to update its access rights without changing an existing
   OSCORE Security Context, it MUST specify an EDHOC_Information object
   in the "edhoc_info" parameter of its POST request to the /token
   endpoint.  The EDHOC_Information object MUST include the "session_id"
   field.  This POST request MUST NOT include the "req_cnf" parameter.
   An example of such a request is shown in Figure 4.








Selander, et al.          Expires 23 April 2026                [Page 12]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   The identifier "session_id" is assigned by AS as discussed in
   Section 3.2, and identifies an ongoing token series associated with
   the pair (AUTH_CRED_C, AUTH_CRED_RS).  That is, previous access
   tokens in that series were issued by AS to C, as bound to AUTH_CRED_C
   and intended for RS as identified by AUTH_CRED_RS.

   Note that the same "session_id" value might identify multiple ongoing
   token series, e.g., if those are associated with the same client but
   different resource servers.  In this case, AS can use the
   "session_id" value together with other information such as the
   targeted audience (see Section 5.8.1 of [RFC9200]) and the
   authenticated identity of C, in order to determine the exact token
   series to which the new requested access token has to be added.

   If the identifier specified in the "session_id" parameter of the POST
   request identifies multiple, ongoing token series of which C has an
   access token, then C MUST specify the "audience" parameter in the
   POST request.  In particular, the value of the "audience" parameter
   MUST be the same value of the "audience" parameter in the POST
   request that C previously sent to AS, for requesting the first access
   token in the token series to which the new requested access token has
   to be added.

   AS MUST verify that the received "session_id" identifies a token
   series to which a still valid access token issued for C and RS
   belongs.  If that is not the case, the Client-to-AS request MUST be
   declined with the error code "invalid_request" as defined in
   Section 5.8.3 of [RFC9200].

      Header: POST (Code=0.02)
      Uri-Host: "as.example.com"
      Uri-Path: "token"
      Content-Format: application/ace+cbor
      Payload:
      {
        / audience /      5 : "tempSensor4711",
        / scope /         9 : "write",
        e'edhoc_info_param' : {
           e'session_id' : h'01'
        }
      }

       Figure 4: Example of C-to-AS POST /token request for updating
                     access rights to an access token.







Selander, et al.          Expires 23 April 2026                [Page 13]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


3.2.  Token Series

   This document refers to "token series" as a series of access tokens
   that are sorted in chronological order of release and are
   characterized by the following properties:

   *  Issued by the same AS.

   *  Issued to the same C, and associated with the same authentication
      credential of C.

   *  Issued for the same RS as identified by the same authentication
      credential.

   Upon a successful update of access rights (see Section 3.3.3), the
   new issued access token becomes the latest in its token series.  When
   the latest access token of a token series becomes invalid (e.g., due
   to its expiration or revocation), the token series it belongs to
   ends.

   In this profile, a token series comprises access tokens that are used
   between a given pair (C, RS), are bound to the same authentication
   credential AUTH_CRED_C of C, and specify the same value in the
   "session_id" field of the EDHOC_Information object (see Section 3.4)
   in their "edhoc_info" claim.

   AS assigns the value of "session_id" when issuing the first access
   token of a new series.  That "session_id" value remains fixed
   throughout the series lifetime.

   When assigning the "session_id" value, AS MUST ensure that it was not
   used in a previous series whose access tokens share both the
   following properties with the access tokens of the new series,
   irrespective of the used ACE profile:

   *  issued to the same client C; and

   *  issued for the same RS.

   In case the access token is issued for a group-audience (see
   Section 6.9 of [RFC9200]), what is defined above applies, with the
   difference that the token series is associated with all the RSs in
   the group-audience, as indicated by their respective AUTH_CRED_RS.








Selander, et al.          Expires 23 April 2026                [Page 14]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


3.3.  AS-to-C: Response

   After verifying the POST request to the /token endpoint and that C is
   authorized to access protected resources at RS, AS responds as
   defined in Section 5.8.2 of [RFC9200], with potential modifications
   as detailed below.

   When using this profile, consistent with what is specified in
   Section 3.1, the payload of the response from AS MUST be encoded in
   CBOR [RFC8949], i.e., the response has media-type "application/
   ace+cbor".

   If the request from C was invalid or not authorized, AS returns an
   error response as described in Section 5.8.3 of [RFC9200].

   AS can signal that the use of EDHOC and OSCORE as per this profile is
   REQUIRED for a specific access token, by including the "ace_profile"
   parameter with the value "coap_edhoc_oscore" in the access token
   response.  This means that C MUST use EDHOC with RS and derive an
   OSCORE Security Context, as specified in Section 4.2.  After that, C
   MUST use the established OSCORE Security Context to protect
   communications with RS, when accessing protected resources at RS
   according to the authorization information indicated in the access
   token.  Usually, it is assumed that constrained devices will be pre-
   configured with the necessary profile, so that this kind of profile
   signaling can be omitted.

   According to this document, the AS provides the access token to C, by
   specifying it in the "access_token" parameter of the access token
   response.  An alternative workflow where the access token is uploaded
   by AS directly to RS is described in
   [I-D.ietf-ace-workflow-and-params].

   When issuing the first access token of a token series, AS MUST
   include the following data in the response to C.

   *  The "edhoc_info" parameter conveying an EDHOC_Information object
      (see Section 3.4).  The EDHOC_Information object MUST include the
      "session_id" field specifying the identifier of the token series
      which the issued access token belongs to.

      The EDHOC_Information object MAY include additional fields (see
      Section 3.4) to convey information about RS.  This information is
      based on knowledge that AS has about RS, e.g., from a previous
      onboarding process, with particular reference to what RS supports
      as EDHOC peer.





Selander, et al.          Expires 23 April 2026                [Page 15]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


      In case the access token is issued for a group-audience (see
      Section 6.9 of [RFC9200]), the information specified in the
      EDHOC_Information object refers to the group-audience as a whole.
      Therefore, it is appropriate for AS to define group-audiences
      comprising RSs that are all aligned in terms of supported EDHOC
      features and configurations.

   *  A unique identification of the authentication credential of RS,
      AUTH_CRED_RS.  This is specified in the "rs_cnf" parameter defined
      in [RFC9201].  AUTH_CRED_RS can be transported by value or
      referred to by means of an appropriate identifier.  C could
      explicitly ask AS to provide AUTH_CRED_RS by value in the Access
      Token Response, e.g., by relying on the method defined in
      [I-D.ietf-ace-workflow-and-params].

      When issuing the first access token ever to a pair (C, RS) using a
      pair of corresponding authentication credentials (AUTH_CRED_C,
      AUTH_CRED_RS), it is expected that the response to C includes
      AUTH_CRED_RS by value.

      When later issuing further access tokens to the same pair (C, RS)
      using the same AUTH_CRED_RS, it is expected that the response to C
      includes AUTH_CRED_RS by reference.

      For AUTH_CRED_RS, its authentication credential type MUST be one
      of those supported by EDHOC.  Consequently, the "rs_cnf" parameter
      MUST specify a confirmation method suitable for the type of
      AUTH_CRED_RS.  That is, the same considerations about AUTH_CRED_C
      and the "req_cnf" parameter made in Section 3.1 hold for
      AUTH_CRED_RS and the "rs_cnf" parameter.

   When issuing any access token of a token series, the response from AS
   MUST NOT include the "cnf" parameter.

   When issuing an access token for dynamically updating access rights
   (i.e., the access token is not the first in its token series), the
   response from AS MUST NOT include the "edhoc_info" and "rs_cnf"
   parameters (see Section 3.3.3).

   Figure 5 shows an example of an AS response.  The "rs_cnf" parameter
   specifies the authentication credential of RS, as an X.509
   certificate transported by value in the "x5chain" field.  The access
   token and the authentication credential of RS have been truncated for
   readability.







Selander, et al.          Expires 23 April 2026                [Page 16]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


      Header: Created (Code=2.01)
         Content-Format: application/ace+cbor
         Payload:
         {
           / access_token / 1 : h'8343a1010aa2044c53...0f6a'
             / remainder of access token (CWT) omitted for brevity /,
           / ace_profile / 38 : e'coap_edhoc_oscore',
           / expires_in /   2 : 3600,
           / rs_cnf /      41 : {
             e'x5chain' : h'3081ee3081a1a00302...77bc'
               / remainder of the credential omitted for brevity /
           }
           e'edhoc_info_param' : {
             e'session_id'    : h'01',
             e'methods'       : [0, 1, 2, 3],
             e'cipher_suites' : 0
           }
         }

     Figure 5: Example of AS-to-C Access Token response with EDHOC and
                              OSCORE profile.

3.3.1.  Access Token

   To avoid the complexity of different encodings, an access token of
   this profile SHALL be a CBOR Web Token (CWT) [RFC8392].

   When issuing any access token of a token series, AS MUST include the
   following claims in the access token:

   *  The "edhoc_info" claim defined in Section 14.5 and conveying an
      EDHOC_Information object (see Section 3.4).

      The EDHOC_Information object MUST include the "session_id" field
      specifying the identifier of the token series which the issued
      access token belongs to.  The "session_id" value is the same one
      included in the EDHOC_Information object of the response to C from
      the /token endpoint (see Section 3.3), when providing C with the
      first access token in the series.

   *  The "cnf" claim, specifying the authentication credential
      AUTH_CRED_C that C specified in its POST request to the /token
      endpoint, when requesting the first access token in the series
      which the issued access token belongs to (see Section 3.1).

      In the access token, AUTH_CRED_C can be transported by value or
      uniquely referred to by means of an appropriate identifier.  Yet,
      consistent with the considerations about AUTH_CRED_C and the



Selander, et al.          Expires 23 April 2026                [Page 17]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


      "req_cnf" parameter made in Section 3.1, the "cnf" claim of the
      access token MUST specify a confirmation method suitable for the
      type of AUTH_CRED_C.

      When issuing the first access token of a token series, the
      confirmation method used in the "cnf" claim MUST be the same one
      used in the "req_cnf" parameter of the corresponding POST request
      from C to the /token endpoint.

      When issuing the first access token ever to a pair (C, RS) using a
      pair of corresponding authentication credentials (AUTH_CRED_C,
      AUTH_CRED_RS), it is expected that AUTH_CRED_C is included by
      value in the "cnf" claim of the access token.

      When later issuing further access tokens to the same pair (C, RS)
      using the same AUTH_CRED_C, it is expected that AUTH_CRED_C is
      identified by reference in the "cnf" claim of the access token.

      Either transported by value or identified by reference, the
      authentication credential specified in the "cnf" claim MUST be
      exactly the one that was specified in the "req_cnf" parameter of
      the POST request to the /token endpoint, when C requested the
      first access token in the series which the issued access token
      belongs to.  That is, AS MUST NOT bind to the access token an
      authentication credential other than the one specified by C.

   When issuing the first access token of a token series, AS MAY include
   additional fields in the EDHOC_Information object (see Section 3.4)
   specified in the "edhoc_info" claim of the access token.

   The access token needs to be protected for various reasons.  To
   prevent manipulation of the content, it needs to be integrity
   protected.  Also, RS has to be able to verify that the access token
   is issued by a trusted AS, by achieving source authentication.
   Depending on the use case and deployment, the access token may need
   to be confidentiality protected, for example due to privacy reasons.

   AS protects the access token using a COSE method [RFC9052] as
   specified in [RFC8392].  Depending on the audience, there can be
   different ways to most appropriately ensure the confidentiality of an
   access token.  For an audience comprising a single RS, the CWT Claims
   Set may be wrapped in COSE_Encrypt / COSE_Encrypt0.  Instead, if the
   access token needs to be read by multiple RSs, then the CWT Claims
   Set may be wrapped in COSE_Sign / COSE_Sign1 and confidentiality
   protection is applied during transport, by including the access token
   in the EAD_3 field of EDHOC message_3 sent by C to RS, when using the
   EDHOC forward message flow (see Section 4.2).




Selander, et al.          Expires 23 April 2026                [Page 18]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   Figure 6 shows an example of CWT Claims Set, including the relevant
   EDHOC parameters in the "edhoc_info" claim.  The "cnf" claim
   specifies the authentication credential of C, as an X.509 certificate
   transported by value in the "x5chain" field.  The authentication
   credential of C has been truncated for readability.

      {
       / aud /   3 : "tempSensorInLivingRoom",
       / iat /   6 : 1563451500,
       / exp /   4 : 1563453000,
       / scope / 9 :  "temperature_g firmware_p",
       / cnf /   8 : {
         e'x5chain' : h'3081ee3081a1a00302...77bc'
           / remainder of the credential omitted for brevity /
       }
       e'edhoc_info_claim' : {
         e'session_id'    : h'01',
         e'methods'       : [0, 1, 2, 3],
         e'cipher_suites' : 0
       }
     }

         Figure 6: Example of CWT Claims Set with EDHOC parameters.

3.3.2.  Processing at C

   When receiving an access token response including the "rs_cnf"
   parameter, C checks whether it is already storing the authentication
   credential of RS, namely AUTH_CRED_RS, specified in "rs_cnf" by value
   or reference.

   If this is not the case, C retrieves AUTH_CRED_RS, either using the
   "rs_cnf" parameter or some other trusted source.  After that, C
   validates the actual AUTH_CRED_RS.  In case of successful validation,
   C stores AUTH_CRED_RS as a valid authentication credential.
   Otherwise, C MUST delete the access token.

3.3.3.  Update of Access Rights

   If C has a valid OSCORE Security Context associated with a valid
   access token, then C can send a request to AS for updating its access
   rights while preserving the same OSCORE Security Context.









Selander, et al.          Expires 23 April 2026                [Page 19]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   If the request is granted, then AS generates a new access token,
   where the EDHOC_Information object specified in the "edhoc_info"
   claim MUST include only the "session_id" field.  The access token is
   provisioned to RS either via C as specified in this document, or
   directly as described in [I-D.ietf-ace-workflow-and-params].  In
   either case, the access token response from AS to C MUST NOT include
   the "edhoc_info" and "rs_cnf" parameters.

   As defined in Section 3.3.1, the "session_id" field is included in
   the EDHOC_Information object specified in the "edhoc_info" claim of
   the new access token.  This allows RS to identify the old access
   token to supersede, as well as the OSCORE Security Context already
   shared between C and RS and to be associated with the new access
   token.

3.4.  EDHOC_Information

   EDHOC_Information is an object including information that guides two
   peers towards executing the EDHOC protocol.  In particular, the
   EDHOC_Information is defined to be serialized and transported between
   nodes, as specified by this document, but it can also be used by
   other specifications.

   In the "coap_edhoc_oscore" profile of the ACE-OAuth framework, which
   is specified in this document, the EDHOC_Information object MUST be
   encoded as CBOR.  However, for easy applicability to other contexts,
   we define also the JSON encoding.

   The EDHOC_Information can be encoded either as a JSON object or as a
   CBOR map.  The set of common fields that can appear in an
   EDHOC_Information can be found in the IANA "EDHOC Information"
   registry defined in Section 14.9 for extensibility.

   All EDHOC_Information parameters are optional.  The initial set of
   parameters defined in this document is summarized in Table 1 and is
   specified below.

   EDHOC_Information parameters are also categorized, i.e., each has one
   of two possible types, namely prescriptive or non-prescriptive:

   *  A prescriptive parameter is used to provide an authoritative
      statement about how an execution of EDHOC has to be performed.  An
      example is the "message_4" parameter indicating whether the use of
      EDHOC message_4 in an EDHOC session is mandatory or not.







Selander, et al.          Expires 23 April 2026                [Page 20]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  A non-prescriptive parameter is used to provide convenient
      information to consider when executing EDHOC, e.g., in terms of
      features supported by other peers.  Such information is not
      necessarily exhaustive.  An example is the "methods" parameter
      indicating a set of supported EDHOC methods.

   This categorization helps coordinate the use of EDHOC application
   profiles Section 3.9 of [RFC9528] in a robust way, e.g., by using the
   means defined in [I-D.ietf-lake-app-profiles].

   +===============+=====+=====+================+================+====+
   | Name          |CBOR |CBOR | Registry       | Description    |Type|
   |               |label|type |                |                |    |
   +===============+=====+=====+================+================+====+
   | session_id    |0    |bstr |                | Identifier of  |P   |
   |               |     |     |                | a session      |    |
   +---------------+-----+-----+----------------+----------------+----+
   | methods       |1    |int  | EDHOC Method   | Set of         |NP  |
   |               |     |or   | Type registry  | supported      |    |
   |               |     |array|                | EDHOC methods  |    |
   +---------------+-----+-----+----------------+----------------+----+
   | cipher_suites |2    |int  | EDHOC Cipher   | Set of         |NP  |
   |               |     |or   | Suites         | supported      |    |
   |               |     |array| registry       | EDHOC cipher   |    |
   |               |     |     |                | suites         |    |
   +---------------+-----+-----+----------------+----------------+----+
   | message_4     |3    |True |                | Mandatory use  |P   |
   |               |     |or   |                | of EDHOC       |    |
   |               |     |False|                | message_4      |    |
   +---------------+-----+-----+----------------+----------------+----+
   | comb_req      |4    |True |                | Support for    |NP  |
   |               |     |or   |                | the EDHOC +    |    |
   |               |     |False|                | OSCORE         |    |
   |               |     |     |                | combined       |    |
   |               |     |     |                | request        |    |
   +---------------+-----+-----+----------------+----------------+----+
   | uri_path      |5    |tstr |                | URI-path of    |P   |
   |               |     |     |                | the EDHOC      |    |
   |               |     |     |                | resource       |    |
   +---------------+-----+-----+----------------+----------------+----+
   | cred_types    |6    |int  | EDHOC          | Set of         |NP  |
   |               |     |or   | Authentication | supported      |    |
   |               |     |array| Credential     | types of       |    |
   |               |     |     | Types registry | authentication |    |
   |               |     |     |                | credentials    |    |
   |               |     |     |                | for EDHOC      |    |
   +---------------+-----+-----+----------------+----------------+----+
   | id_cred_types |7    |int  | COSE Header    | Set of         |NP  |



Selander, et al.          Expires 23 April 2026                [Page 21]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   |               |     |or   | Parameters     | supported      |    |
   |               |     |tstr | registry       | types of       |    |
   |               |     |or   |                | authentication |    |
   |               |     |array|                | credential     |    |
   |               |     |     |                | identifiers    |    |
   |               |     |     |                | for EDHOC      |    |
   +---------------+-----+-----+----------------+----------------+----+
   | eads          |8    |uint | EDHOC External | Set of         |NP  |
   |               |     |or   | Authorization  | supported      |    |
   |               |     |array| Data registry  | EDHOC External |    |
   |               |     |     |                | Authorization  |    |
   |               |     |     |                | Data (EAD)     |    |
   |               |     |     |                | items          |    |
   +---------------+-----+-----+----------------+----------------+----+
   | initiator     |9    |True |                | Support for    |NP  |
   |               |     |or   |                | the EDHOC      |    |
   |               |     |False|                | Initiator role |    |
   +---------------+-----+-----+----------------+----------------+----+
   | responder     |10   |True |                | Support for    |NP  |
   |               |     |or   |                | the EDHOC      |    |
   |               |     |False|                | Responder role |    |
   +---------------+-----+-----+----------------+----------------+----+
   | max_msgsize   |11   |uint |                | Maximum size   |P   |
   |               |     |     |                | of EDHOC       |    |
   |               |     |     |                | messages in    |    |
   |               |     |     |                | bytes          |    |
   +---------------+-----+-----+----------------+----------------+----+
   | coap_ct       |12   |True |                | Mandatory use  |P   |
   |               |     |of   |                | of the CoAP    |    |
   |               |     |False|                | Content-Format |    |
   |               |     |     |                | Option in CoAP |    |
   |               |     |     |                | messages whose |    |
   |               |     |     |                | payload        |    |
   |               |     |     |                | includes       |    |
   |               |     |     |                | exclusively an |    |
   |               |     |     |                | EDHOC message, |    |
   |               |     |     |                | possibly       |    |
   |               |     |     |                | prepended by   |    |
   |               |     |     |                | an EDHOC       |    |
   |               |     |     |                | connection     |    |
   |               |     |     |                | identifier     |    |
   +---------------+-----+-----+----------------+----------------+----+
   | ep_id_types   |13   |int  | EDHOC Endpoint | Set of         |NP  |
   |               |     |or   | Identity Types | supported      |    |
   |               |     |array| registry       | types of       |    |
   |               |     |     |                | endpoint       |    |
   |               |     |     |                | identities for |    |
   |               |     |     |                | EDHOC          |    |



Selander, et al.          Expires 23 April 2026                [Page 22]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   +---------------+-----+-----+----------------+----------------+----+
   | transports    |14   |int  | EDHOC          | Set of         |NP  |
   |               |     |or   | Transports     | supported      |    |
   |               |     |array| registry       | means for      |    |
   |               |     |     |                | transporting   |    |
   |               |     |     |                | EDHOC messages |    |
   +---------------+-----+-----+----------------+----------------+----+
   | trust_anchors |15   |map  | EDHOC Trust    | Set of         |NP  |
   |               |     |     | Anchor         | supported      |    |
   |               |     |     | Purposes       | trust anchors  |    |
   |               |     |     | registry and   |                |    |
   |               |     |     | EDHOC Trust    |                |    |
   |               |     |     | Anchor Types   |                |    |
   |               |     |     | registry       |                |    |
   +---------------+-----+-----+----------------+----------------+----+

     Table 1: EDHOC_Information Parameters.  Types: P (Prescriptive),
                          NP (Non- Prescriptive)

   *  session_id: This parameter identifies a 'session' which the EDHOC
      information is associated with, but does not necessarily identify
      a specific EDHOC session.  In this document, "session_id"
      identifies a token series.  In JSON, the "session_id" value is a
      Base64 encoded byte string.  In CBOR, the "session_id" type is a
      byte string, and has label 0.

   *  methods: This parameter specifies a set of supported EDHOC methods
      (see Section 3.2 of [RFC9528]).  If the set is composed of a
      single EDHOC method, this is encoded as an integer.  Otherwise,
      the set is encoded as an array of integers, where each array
      element encodes one EDHOC method.  In JSON, the "methods" value is
      an integer or an array of integers.  In CBOR, the "methods" is an
      integer or an array of integers, and has label 1.

   *  cipher_suites: This parameter specifies a set of supported EDHOC
      cipher suites (see Section 3.6 of [RFC9528]).  If the set is
      composed of a single EDHOC cipher suite, this is encoded as an
      integer.  Otherwise, the set is encoded as an array of integers,
      where each array element encodes one EDHOC cipher suite.  In JSON,
      the "cipher_suites" value is an integer or an array of integers.
      In CBOR, the "cipher_suites" is an integer or an array of
      integers, and has label 2.

   *  message_4: This parameter indicates whether the EDHOC message_4
      (see Section 5.5 of [RFC9528]) is supported.  In JSON, the
      "message_4" value is a boolean.  In CBOR, "message_4" is the
      simple value true (0xf5) or false (0xf4), and has label 4.




Selander, et al.          Expires 23 April 2026                [Page 23]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  comb_req: This parameter indicates whether the combined EDHOC +
      OSCORE request defined in [RFC9668]) is supported.  In JSON, the
      "comb_req" value is a boolean.  In CBOR, "comb_req" is the simple
      value true (0xf5) or false (0xf4), and has label 5.

   *  uri_path: This parameter specifies the path component of the URI
      of the EDHOC resource where EDHOC messages have to be sent as
      requests.  In JSON, the "uri_path" value is a string.  In CBOR,
      "uri_path" is a text string, and has label 6.

   *  cred_types: This parameter specifies a set of supported types of
      authentication credentials for EDHOC (see Section 3.5.2 of
      [RFC9528]).  If the set is composed of a single type of
      authentication credential, this is encoded as an integer.
      Otherwise, the set is encoded as an array of integers, where each
      array element encodes one type of authentication credential.  In
      JSON, the "cred_types" value is an integer or an array of
      integers.  In CBOR, "cred_types" is an integer or an array of
      integers, and has label 6.  The integer values are taken from the
      "EDHOC Authentication Credential Types" registry defined in
      [RFC9668].

   *  id_cred_types: This parameter specifies a set of supported types
      of authentication credential identifiers for EDHOC (see
      Section 3.5.3 of [RFC9528]).  If the set is composed of a single
      type of authentication credential identifier, this is encoded as
      an integer or a text string.  Otherwise, the set is encoded as an
      array, where each array element encodes one type of authentication
      credential identifier, as an integer or a text string.  In JSON,
      the "id_cred_types" value is an integer, or a text string, or an
      array of integers and text strings.  In CBOR, "id_cred_types" is
      an integer or a text string, or an array of integers and text
      strings, and has label 7.  The integer or text string values are
      taken from the 'Label' column of the "COSE Header Parameters"
      registry [COSE.Header.Parameters].

   *  eads: This parameter specifies a set of supported EDHOC External
      Authorization Data (EAD) items, identified by their ead_label (see
      Section 3.8 of [RFC9528]).  If the set is composed of a single
      ead_label, this is encoded as an unsigned integer.  Otherwise, the
      set is encoded as an array of unsigned integers, where each array
      element encodes one ead_label.  In JSON, the "eads" value is an
      unsigned integer or an array of unsigned integers.  In CBOR,
      "eads" is an unsigned integer or an array of unsigned integers,
      and has label 8.  The unsigned integer values are taken from the
      'Label' column of the "EDHOC External Authorization Data" registry
      defined in [RFC9528].




Selander, et al.          Expires 23 April 2026                [Page 24]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  initiator: This parameter specifies whether the EDHOC Initiator
      role is supported.  In JSON, the "initiator" value is a boolean.
      In CBOR, "initiator" is the simple value true (0xf5) or false
      (0xf4), and has label 9.

   *  responder: This parameter specifies whether the EDHOC Responder
      role is supported.  In JSON, the "responder" value is a boolean.
      In CBOR, "responder" is the simple value true (0xf5) or false
      (0xf4), and has label 10.

   *  max_msgsize: This parameter specifies the admitted maximum size of
      EDHOC messages in bytes.  In JSON, the "max_msgsize" value is an
      unsigned integer.  In CBOR, "max_msgsize" is an unsigned integer
      and has label 11.

   *  coap_cf: This parameter specifies whether it is required that CoAP
      messages include the CoAP Content-Format Option with value 64
      (application/edhoc+cbor-seq) or 65 (application/cid-edhoc+cbor-
      seq) as appropriate, when the message payload includes exclusively
      an EDHOC message possibly prepended by an EDHOC connection
      identifier (see Sections 3.4.1 and A.2 of [RFC9528]).  In JSON,
      the "coap_cf" value is a boolean.  In CBOR, "coap_cf" is the
      simple value true (0xf5) or false (0xf4), and has label 12.

   *  ep_id_types: This parameter specifies a set of supported types of
      endpoint identities for EDHOC.  If the set is composed of a single
      type of endpoint identity, this is encoded as an integer.
      Otherwise, the set is encoded as an array, where each array
      element encodes one type of endpoint identity as an integer.  In
      JSON, the "ep_id_types" value is an integer or an array of
      integers.  In CBOR, "ep_id_types" is an integer or an array of
      integers, and has label 13.  The integer values are taken from the
      'CBOR Label' column of the "EDHOC Endpoint Identity Types"
      registry defined in Section 14.10 of this document.

   *  transports: This parameter specifies a set of supported means for
      transporting EDHOC messages.  If the set is composed of a single
      means for transporting EDHOC messages, this is encoded as an
      integer.  Otherwise, the set is encoded as an array, where each
      array element encodes one means for transporting EDHOC messages as
      an integer.  In JSON, the "transports" value is an integer or an
      array of integers.  In CBOR, "transports" is an integer or an
      array of integers, and has label 14.  The integer values are taken
      from the 'Transport ID' column of the "EDHOC Transports" Registry
      defined in Section 14.11 of this document.






Selander, et al.          Expires 23 April 2026                [Page 25]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  trust_anchors: This parameter specifies a collection of supported
      trust anchors for performing authentication.  According to what is
      specified within the collection, these trust anchors are used for
      different purposes, e.g., for verifying authentication credentials
      of other EDHOC peers in EDHOC sessions.

      More in detail, the collection of trust anchors is composed of one
      or more sets.  Each set includes one or more trust anchors to use
      for one specific purpose associated with that set.

      In particular, each set is composed of pairs, each of which
      specifies a trust anchor type and an identifier of a trust anchor
      of that type.  If the set is composed of a single pair, this pair
      is specified as a single item.  If the set is composed of multiple
      pairs, these pairs are specified as elements of an array.

      Trust anchor purposes are selected from the "EDHOC Trust Anchor
      Purposes" registry defined in Section 14.12 of this document.
      Trust anchor types are selected from the "EDHOC Trust Anchor
      Types" registry defined in Section 14.13 of this document.

      In JSON, the "trust_anchors" value is an object with one or more
      outer entries, each of which is associated with a trust anchor
      purpose.  The following applies for each outer entry:

      -  The outer entry's key specifies the associated trust anchor
         purpose taken from the 'Name' column' of the "EDHOC Trust
         Anchor Purposes" registry.

      -  The outer entry's value is an object or an array of at least
         two objects.  Each object includes one inner entry, specifying
         the pair for a trust anchor TA of type TYPE.  The inner entry
         is formatted as follows:

         o  The inner entry's key specifies the TA's type TYPE taken
            from the 'Name' column of the "EDHOC Trust Anchor Types"
            registry.

         o  The inner entry's value is the identifier of TA, whose
            encoding depends on TYPE.  Such an encoding is what results
            from applying the conversion in Section 6.1 of [RFC8949] to
            the CBOR encoding of the identifier of TA when
            "trust_anchors" is encoded in CBOR (see below).

      In CBOR, the "trust_anchors" value is a map and has label 15.  The
      map includes one or more outer entries, each of which is
      associated with a trust anchor purpose.  The following applies for
      each outer entry:



Selander, et al.          Expires 23 April 2026                [Page 26]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


      -  The outer entry's key specifies the associated trust anchor
         purpose encoded as a CBOR integer, with integer value taken
         from the 'CBOR label' column of the "EDHOC Trust Anchor
         Purposes" registry.

      -  The outer entry's value is a map or an array of at least two
         maps.  Each map includes one inner entry, specifying the pair
         for a trust anchor TA of type TYPE.  The inner entry is
         formatted as follows:

         o  The inner entry's key specifies the TA's type TYPE encoded
            as a CBOR integer, with integer value taken from the 'CBOR
            label' column of the "EDHOC Trust Anchor Types" registry.

         o  The inner entry's value specifies the identifier of TA,
            whose encoding depends on TYPE and is specified by the
            'Value type' column of the "EDHOC Trust Anchor Types"
            registry, for the registry entry that has TYPE as value of
            the 'Name' column.

   An example of JSON EDHOC_Information is given in Figure 7.

      "edhoc_info" : {
          "session_id"    : b64'AQ==',
          "methods"       : 1,
          "cipher_suites" : 0,
          "trust_anchors" : {
            "edhoc_cred" : [
              { "c5u" : "coap://certs.c509.example" },
              { "x5u" : "coap://certs.x509.example" }
            ]
          }
      }

                Figure 7: Example of JSON EDHOC_Information

   An example of CBOR EDHOC_Information is given in Figure 8.














Selander, et al.          Expires 23 April 2026                [Page 27]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


      e'edhoc_info_param'  : {
        e'session_id'    : h'01',
        e'methods'       : 1,
        e'cipher_suites' : 0,
        e'trust_anchors' : {
          e'edhoc_cred' : [
            { e'c5t_ta_type' : [-15, h'81DC2F32CB87E163'] },
            { e'c5u_ta_type' : "coap://certs.c509.example" },
            { e'x5t_ta_type' : [-15, h'79F2A41B510C1F9B'] },
            { e'x5u_ta_type' : "coap://certs.x509.example" }
          ]
        }
      }

                Figure 8: Example of CBOR EDHOC_Information

   The CDDL grammar describing the CBOR EDHOC_Information is:

   EDHOC_Information = {
     ?  0 => bstr,                   ; id
     ?  1 => int / array,            ; methods
     ?  2 => int / array,            ; cipher_suites
     ?  3 => true / false,           ; message_4
     ?  4 => true / false,           ; comb_req
     ?  5 => tstr,                   ; uri_path
     ?  6 => int / array,            ; cred_types
     ?  7 => int / tstr / array,     ; id_cred_types
     ?  8 => uint / array,           ; eads
     ?  9 => true / false,           ; initiator
     ? 10 => true / false,           ; responder
     ? 11 => uint,                   ; max_msgsize
     ? 12 => true / false,           ; coap_ct
     ? 13 => int / array,            ; ep_id_types
     ? 14 => int / array,            ; transports
     ? 15 => map,                    ; trust_anchors
     * int / tstr => any
   }

4.  Client-RS Communication

   This section describes the exchange between C and RS, including the
   execution of the EDHOC protocol and the uploading of the access token
   from C to RS.  The alternative workflow, where AS uploads the access
   token directly to RS, is described in
   [I-D.ietf-ace-workflow-and-params].






Selander, et al.          Expires 23 April 2026                [Page 28]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   C and RS run the EDHOC protocol (see Section 4.2), and C uploads the
   access token in an EAD field (see Section 4.1) of an EDHOC message.
   Once successfully completed the EDHOC session, C and RS derive an
   OSCORE Security Context (see Section 4.5).  After that, OSCORE is
   used for protecting communications when C accesses resources at RS,
   as per the access rights specified in the access token (see
   Section 4.9).

   Detailed examples are given in Appendix A.

4.1.  EAD items for Access Token and Session Identifier

   This document defines EAD items (see Section 3.8 of [RFC9528]) for
   transporting an access token or a session identifier in EDHOC.

   *  EAD_ACCESS_TOKEN = (ead_label, ead_value), where:

      -  ead_label is the integer value TBD registered in Section 14.8.

      -  ead_value is a CBOR byte string equal to the value of the
         "access_token" field of the access token response from AS (see
         Section 3.3).

      This EAD item is critical, i.e., it is used only with the negative
      value of its ead_label, indicating that the receiving RS must
      progress the protocol using the received access token, or else
      abort the EDHOC session (see Section 3.8 of [RFC9528]).  A client
      or resource server supporting the profile of ACE defined in this
      document MUST support this EAD item.

      EAD_ACCESS_TOKEN is used only when uploading the first access
      token of a token series, but not for the update of access rights
      (see Section 4.6).

      Example: Assuming IANA label 26 and critical, so ead_label = -26
      (0x3819), and 180 bytes access_token =
      h'8343a1010aa2044c53...0f6a' (partly omitted for brevity):

      -  EAD_ACCESS_TOKEN = 0x381958B48343a1010aa2044c53...0f6a

      Editor's note: Replace IANA label with TBD value registered for
      ACE-OAuth Access Token in Section 14.8.

   *  EAD_SESSION_ID = (ead_label, ead_value), where:

      -  ead_label is the integer value TBD registered in Section 14.8.





Selander, et al.          Expires 23 April 2026                [Page 29]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


      -  ead_value is a CBOR byte string equal to the value of the
         "session_id" field within the EDHOC_Information object
         specified by AS in the "edhoc_info" parameter of the response
         from the /token endpoint, when issuing the first access token
         of a token series (see Section 3.3).

      This EAD item is critical, i.e., it is used only with the negative
      value of its ead_label, indicating that the receiving RS must
      progress the protocol using the access token associated with the
      identifier specified in "ead_value" and with the AUTH_CRED_C used
      in the EDHOC session, or else abort the EDHOC session (see
      Section 3.8 of [RFC9528]).  A client or resource server supporting
      the profile of ACE defined in this document MUST support this EAD
      item.

      EAD_SESSION_ID is used only if the access token has been
      provisioned to RS and is valid, but there is a need to establish a
      (new) OSCORE Security Context between C and RS through EDHOC.

      Example: Assuming IANA label 5 and critical, so ead_label = -5
      (0x24), and session_id = h'1645'

      -  EAD_SESSION_ID = 0x24421645

      Editor's note: Replace IANA label with TBD value for Session ID
      registered in Section 14.8.

4.2.  EDHOC Session

   In order to mutually authenticate and establish secure communication
   for authorized access according to the profile described in this
   document, C and RS run the EDHOC protocol augmented with an access
   token.  During the EDHOC session, C specifies the access token to RS
   by value as conveyed in EAD item EAD_ACCESS_TOKEN, or by reference
   through a session identifier SESSION_ID conveyed in the EAD item
   EAD_SESSION_ID (see Section 4.1).

   As per Appendix A.2 of [RFC9528], EDHOC can be transferred over CoAP
   using either the forward or the reverse message flow, thus
   manifesting the two possible mappings between the ACE roles (client
   and resource server) and the EDHOC roles (Initiator and Responder),
   whereas the CoAP roles (client and server) remain the same.  The
   choice of message flow and corresponding mapping depends on the
   deployment setting and in particular on which identity to protect the
   most, since EDHOC protects the identity of the Initiator against
   active attackers.





Selander, et al.          Expires 23 April 2026                [Page 30]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   In case the EDHOC forward message flow is used (see Section 4.3), C
   acts as EDHOC Initiator, and the access token MUST be specified by
   value or by reference in the EAD_3 field of EDHOC message_3.  In case
   the EDHOC reverse message flow is used (see Section 4.4), C acts as
   EDHOC Responder, and the access token MUST be specified by value or
   by reference either in the EAD_2 field of EDHOC message_2 or in the
   EAD_4 field of EDHOC message_4.  By doing so, the access token or the
   associated session identifier gets at least the same confidentiality
   protection by EDHOC as provided to the authentication credential used
   by C in the EDHOC session (see Section 9.1 of [RFC9528]).

   When RS processes the EAD item EAD_ACCESS_TOKEN or EAD_SESSION_ID, RS
   MUST verify that the authentication credential AUTH_CRED_C that C
   specifies in the ID_CRED_X field during the EDHOC session is the same
   authentication credential correlated with the EAD item.  If such a
   verification fails, RS MUST abort the EDHOC session.  Note that:

   *  The ID_CRED_X field in question is the ID_CRED_I or ID_CRED_R
      field, when using the EDHOC forward or reverse message flow,
      respectively.

   *  If the processed EAD item is EAD_ACCESS_TOKEN, then the
      authentication credential correlated with the EAD item is
      specified in the 'cnf' claim of the access token conveyed in the
      EAD item.

   *  If the processed EAD item is EAD_SESSION_ID, then the
      authentication credential correlated with the EAD item is
      specified in the 'cnf' claim of an access token stored at the RS,
      which is associated with the authentication credential specified
      by ID_CRED_X and with the SESSION_ID conveyed in the EAD item.

   RS MUST have successfully validated the access token before
   completing the EDHOC session.  If completed successfully, then the
   EDHOC session is associated with both the access token and the pair
   (SESSION_ID, AUTH_CRED_C).  If the EAD item used in the EDHOC session
   is EAD_ACCESS_TOKEN, then SESSION_ID is specified by the "session_id"
   field, within the EDHOC_Information object specified by the "cnf"
   claim of the access token.

   Any previous EDHOC session associated with the same access token and
   with the same pair (SESSION_ID, AUTH_CRED_C) MUST be deleted.  The
   OSCORE Security Context derived from that EDHOC session MUST also be
   deleted.

   Depending on the message flow used, the EDHOC messages will be
   carried either in CoAP POST requests or in CoAP 2.04 (Changed)
   responses, as detailed in Appendix A.2 of [RFC9528].



Selander, et al.          Expires 23 April 2026                [Page 31]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   C MUST target the EDHOC resource at RS with the URI path specified in
   the "uri_path" field (if present) of the EDHOC_Information object
   within the access token response received from AS, through which C
   obtained the first access token of the token series (see
   Section 3.1).  If the "uri_path" field is not present in that
   EDHOC_Information object, C assumes the target resource at RS to be
   the well-known EDHOC resource at the path /.well-known/edhoc.

   In this profile of ACE, RS MUST implement the CoAP Uri-Path-Abbrev
   Option specified in [I-D.ietf-core-uri-path-abbrev] and MUST
   understand the corresponding Uri-Path-Abbrev value 2 that abbreviates
   the path /.well-known/edhoc.  While there is no equivalent
   requirement for C, the above ensures that the CoAP Uri-Path-Abbrev
   Option and its value are going to be understood by RS, if C includes
   the Option in a CoAP request that carries an EDHOC message and
   targets the well-known EDHOC resource at the path /.well-known/edhoc.

   RS has to ensure that no requests can be performed on an EDHOC
   resource other than for running the EDHOC protocol.  Specifically, it
   SHOULD NOT be possible to perform any other operation than POST on an
   EDHOC resource.

4.3.  Forward Message Flow

   This section details the case where the EDHOC forward message flow is
   used (see Appendix A.2.1 of [RFC9528]), i.e., where C acts as the
   Initiator I and RS acts as the Responder R.

   Consistently with the EDHOC forward message flow, C sends EDHOC
   message_1 and EDHOC message_3 to an EDHOC resource at RS, as CoAP
   POST requests.  RS sends EDHOC message_2 and (optionally) EDHOC
   message_4 as CoAP 2.04 (Changed) responses.

4.3.1.  EDHOC message_1

   The processing of EDHOC message_1 is specified in Section 5.2 of
   [RFC9528], with the following additions:

   *  The EDHOC method MUST be one of the EDHOC methods specified in the
      "methods" field (if present) of the EDHOC_Information object
      within the access token response received from AS, through which C
      obtained the first access token of the token series (see
      Section 3.1)








Selander, et al.          Expires 23 April 2026                [Page 32]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  The selected cipher suite MUST be an EDHOC cipher suite specified
      in the "cipher_suites" field (if present) of the EDHOC_Information
      object within the access token response received from AS, through
      which C obtained the first access token of the token series (see
      Section 3.1)

4.3.2.  EDHOC message_2

   The processing of EDHOC message_2 is specified in Section 5.3 of
   [RFC9528], with the following additions:

   *  The authentication credential CRED_R specified by the message
      field ID_CRED_R is AUTH_CRED_RS.

4.3.3.  EDHOC message_3

   The processing of EDHOC message_3 is specified in Section 5.4 of
   [RFC9528], with the following additions:

   *  The authentication credential CRED_I specified by the message
      field ID_CRED_I is AUTH_CRED_C.

   *  Exactly one of the EAD items EAD_ACCESS_TOKEN or EAD_SESSION_ID
      MUST be included in the EAD_3 field.  If this is not the case, RS
      MUST abort the EDHOC session.

   *  If the EAD_3 field includes the EAD item EAD_ACCESS_TOKEN, then RS
      MUST ensure that the access token specified in the EAD item is
      valid.  If the EAD_3 field includes the EAD item EAD_SESSION_ID,
      then RS MUST ensure that the access token associated with the
      session identifier SESSION_ID specified in the EAD item and with
      the AUTH_CRED_C used in the EDHOC session is valid.

      The validation follows the procedure specified in Section 4.6.2.
      If such validation fails, RS MUST reply to C with an EDHOC error
      message with ERR_CODE = 1 (see Section 6 of [RFC9528]) and it MUST
      abort the EDHOC session.

      Editor's note: Instead of ERR_CODE = 1, consider to use ERR_CODE =
      3 "Access Denied" defined in draft-ietf-lake-authz

4.4.  Reverse Message Flow

   This section details the case where the EDHOC reverse message flow is
   used (see Appendix A.2.2 of [RFC9528]), i.e., where C acts as the
   Responder R and RS acts as the Initiator I.





Selander, et al.          Expires 23 April 2026                [Page 33]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   Consistently with the EDHOC reverse message flow, C sends a trigger
   message, EDHOC message_2, and (optionally) EDHOC message_4 to RS as
   CoAP POST requests.  RS sends EDHOC message_1 and EDHOC message_3 as
   CoAP 2.04 (Changed) responses.

   In this profile of ACE, if RS implements the EDHOC reverse message
   flow, then RS MUST implement EDHOC message_4.

   Exactly one of the EAD items EAD_ACCESS_TOKEN or EAD_SESSION_ID MUST
   be included in either the EAD_2 field of EDHOC message_2 or the EAD_4
   field of EDHOC message_4.  If this is not the case, RS MUST abort the
   EDHOC session.

   Specific instructions for the different messages are provided in the
   following subsections.

4.4.1.  Trigger Message

   As specified in Appendix A.2.2 of [RFC9528], the trigger message is
   an empty POST request that C sends to the EDHOC resource at RS, as
   intended to trigger a response conveying EDHOC message_1.

   In case the access token is issued for a group-audience (see
   Section 6.9 of [RFC9200]), then C can perform an EDHOC "roll call",
   by sending the trigger message as a group request over IP multicast
   [I-D.ietf-core-groupcomm-bis].  For the sake of efficiency, it is
   expected that the group-audience is appropriately associated with a
   CoAP group and/or application group (see Section 2 of
   [I-D.ietf-core-groupcomm-bis]), so that only the RSs belonging to the
   group-audience receive the trigger message.  After that, C can
   receive a different EDHOC message_1 from each of the targeted RSs and
   separately progresses the corresponding EDHOC sessions, by sending a
   different EDHOC message_2 to each RS that has replied with an EDHOC
   message_1.

4.4.2.  EDHOC message_1

   The processing of EDHOC message_1 is specified in Section 5.2 of
   [RFC9528].

4.4.3.  EDHOC message_2

   The processing of EDHOC message_2 is specified in Section 5.3 of
   [RFC9528], with the following additions:

   *  The authentication credential CRED_R specified by the message
      field ID_CRED_R is AUTH_CRED_C.




Selander, et al.          Expires 23 April 2026                [Page 34]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  If the EAD_2 field includes the EAD item EAD_ACCESS_TOKEN, then RS
      MUST ensure that the access token specified in the EAD item is
      valid.  If the EAD_2 field includes the EAD item EAD_SESSION_ID,
      then RS MUST ensure that the access token associated with the
      session identifier SESSION_ID specified in the EAD item and with
      the AUTH_CRED_C used in the EDHOC session is valid.

   Note that in this case C uploads the Access Token or session ID
   before RS is authenticated, since C will not learn about the identity
   of RS until having verified message_3.  In particular, in the case of
   a group-audience, when there may be multiple legitimate RS, C does
   not yet know which member of the group-audience it communicates with
   (if any).

   The validation follows the procedure specified in Section 4.6.2.  If
   such validation fails, RS MUST reply to C with an EDHOC error message
   with ERR_CODE = 1 (see Section 6 of [RFC9528]) and it MUST abort the
   EDHOC session.

   Editor's note: Instead of ERR_CODE = 1, consider to use ERR_CODE = 3
   "Access Denied" defined in draft-ietf-lake-authz

4.4.4.  EDHOC message_3

   The processing of EDHOC message_3 is specified in Section 5.4 of
   [RFC9528], with the following additions:

   *  The authentication credential CRED_I specified by the message
      field ID_CRED_I is AUTH_CRED_RS.

4.4.5.  EDHOC message_4

   The processing of EDHOC message_4 is specified in Section 5.5 of
   [RFC9528], with the following additions:

   *  If the EAD_4 field includes the EAD item EAD_ACCESS_TOKEN, then RS
      MUST ensure that the access token specified in the EAD item is
      valid.  If the EAD_4 field includes the EAD item EAD_SESSION_ID,
      then RS MUST ensure that the access token associated with the
      session identifier SESSION_ID specified in the EAD item and with
      the AUTH_CRED_C used in the EDHOC session is valid.

      The validation follows the procedure specified in Section 4.6.2.
      If such validation fails, RS MUST reply to C with an EDHOC error
      message with ERR_CODE = 1 (see Section 6 of [RFC9528]) and it MUST
      abort the EDHOC session.





Selander, et al.          Expires 23 April 2026                [Page 35]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


      Editor's note: Instead of ERR_CODE = 1, consider to use ERR_CODE =
      3 "Access Denied" defined in draft-ietf-lake-authz

4.5.  OSCORE Security Context

   Once successfully completed the EDHOC session, C and RS derive an
   OSCORE Security Context as defined in Appendix A.1 of [RFC9528].

   In addition, RS associates the latest EDHOC session and the derived
   OSCORE Security Context with the stored access token, which is bound
   to the authentication credential AUTH_CRED_C used in the EDHOC
   session.  The access token is also associated with the pair
   (SESSION_ID, AUTH_CRED_C), where SESSION_ID is the identifier of the
   token series to which the access token belongs.

   If supported by C, C MAY use the EDHOC + OSCORE combined request
   defined in [RFC9668], unless the EDHOC_Information object specified
   by the "edhoc_info" parameter of the access token response included
   the "comb_req" field encoding the CBOR simple value false (0xf4).

   In the combined request, both EDHOC message_3 and the first OSCORE-
   protected application request are combined together in a single
   OSCORE-protected CoAP request, thus saving one round trip.  This
   requires C to derive the OSCORE Security Context with RS already
   after having successfully processed the received EDHOC message_2 and
   before sending EDHOC message_3.  An example is provided in
   Appendix A.2.

4.6.  Update of Access Rights

   If C has a valid OSCORE Security Context associated with a valid
   access token at RS, then C can request from AS an update of the
   access rights as described in Section 3.1.

   If the request is granted, then AS generates a new access token
   containing updated access rights for C (see Section 3.3.3), in the
   same token series of the current access token (see Section 3.2).

   According to this document, AS provides the new access token to C
   (see Section 3.3) for further uploading to RS.  Alternatively, the
   new access token can be uploaded by AS directly to RS, as described
   in [I-D.ietf-ace-workflow-and-params].

   If all validations are successful, C can access protected resources
   at RS according to the updated access rights, using the previously
   established OSCORE Security Context.





Selander, et al.          Expires 23 April 2026                [Page 36]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   The rest of this section describes the message exchange for the
   uploading of the new access token from C to RS.

4.6.1.  C-to-RS: POST to /authz-info endpoint

   C can update its access rights by uploading the updated access token
   to RS using CoAP [RFC7252] and the Authorization Information endpoint
   as described in Section 5.10.1 of [RFC9200].

   That is, C sends a POST request to the /authz-info endpoint at RS,
   with the request payload containing the access token without any CBOR
   wrapping.  As per Section 5.10.1 of [RFC9200], the Content-Format of
   the POST request MUST be "application/cwt" to reflect the format of
   the transported access token.

   C MUST protect the POST request using the current OSCORE Security
   Context shared with RS.

   Upon receiving an access token from C, RS MUST follow the procedures
   defined in Section 5.10.1 of [RFC9200].  That is, RS MUST verify the
   validity of the access token.  RS MAY make an introspection request
   (see Section 5.9.1 of [RFC9200]) to validate the access token at AS.

   RS MUST check the following conditions:

   *  RS checks whether it stores an access token T_OLD, such that the
      "session_id" field of the EDHOC_Information object specified by
      the "cnf" claim matches the "session_id" field of the
      EDHOC_Information object specified by the "cnf" claim of the new
      access token T_NEW.

   *  RS checks whether the OSCORE Security Context CTX used to protect
      the request matches the OSCORE Security Context associated with
      the stored access token T_OLD.

   If both the conditions above hold, RS MUST supersede the old access
   token T_OLD by replacing the corresponding authorization information
   with the one specified in the new access token T_NEW, and MUST
   associate T_NEW with the OSCORE Security Context CTX.

   Note that C and RS do not execute the EDHOC protocol, they do not
   establish a new OSCORE Security Context, and AUTH_CRED_C remains the
   same.








Selander, et al.          Expires 23 April 2026                [Page 37]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


4.6.2.  RS-to-C: 2.01 (Created)

   If all validations are successful, RS stores the new access token in
   such a way that it is possible to retrieve it based on the pair
   (SESSION_ID, AUTH_CRED_C), where SESSION_ID is the identifier of the
   token series to which the access token belongs.  Note that SESSION_ID
   is specified in the "session_id" field of the EDHOC_Information
   object, within the "cnf" claim of the access token.

   Then, RS MUST reply to the POST request by sending a 2.01 (Created)
   response with no payload.  The response is protected with the same
   OSCORE Security Context used to protect the corresponding request.
   After that, C can access protected resources at RS according to the
   updated access rights, using the previously established OSCORE
   Security Context.

   Instead, if any validation fails, RS MUST respond with a 4.01
   (Unauthorized) error response.  RS MAY provide additional information
   in the payload of the error response, in order to clarify what went
   wrong.

   As specified in Section 5.10.1 of [RFC9200], when receiving a valid
   access token with updated authorization information from C (see
   Section 4.6.1), it is recommended that RS overwrites the previous
   access token.  That is, only the latest authorization information in
   the access token received by RS is valid.  This simplifies the
   process needed by RS to keep track of authorization information for a
   given client.

4.7.  Discarding the OSCORE Security Context

   There are a number of cases where C or RS have to discard the OSCORE
   Security Context that they share, and may establish a new one (see
   Section 4.8).

   C MUST discard the current OSCORE Security Context shared with RS
   when any of the following occurs.

   *  The OSCORE Sender Sequence Number space of C is exhausted.

   *  The access token associated with the OSCORE Security Context
      becomes invalid, for example, due to expiration or revocation.









Selander, et al.          Expires 23 April 2026                [Page 38]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  C receives a number of unprotected 4.01 (Unauthorized) responses
      to OSCORE-protected requests, which are sent to RS and protected
      using the same OSCORE Security Context.  The exact number of such
      received responses needs to be specified by the application.  This
      can happen, for example, due to lack of storage at RS, which then
      sends the "AS Request Creation Hints" message (see Section 5.3 of
      [RFC9200]).

   *  The authentication credential of C (of RS) becomes invalid, e.g.,
      due to expiration or revocation, and it was used as AUTH_CRED_C
      (AUTH_CRED_RS) in the EDHOC session to establish the OSCORE
      Security Context.

   RS MUST discard the current OSCORE Security Context shared with C
   when any of the following occurs:

   *  The OSCORE Sender Sequence Number space of RS is exhausted.

   *  The access token associated with the OSCORE Security Context
      becomes invalid, for example, due to expiration or revocation.

   *  The authentication credential of C (of RS) becomes invalid (e.g.,
      due to expiration or revocation), and it was used as AUTH_CRED_C
      (AUTH_CRED_RS) in the EDHOC session to establish the OSCORE
      Security Context.

   After a new access token is successfully uploaded to RS and a new
   OSCORE Security Context is established between C and RS, messages
   still in transit that were protected with the previous OSCORE
   Security Context might not be successfully verified by the recipient,
   since the old OSCORE Security Context might have been discarded.
   This means that messages sent shortly before C has uploaded the new
   access token to RS might not be successfully accepted by the
   recipient.

   Furthermore, implementations may want to cancel CoAP observations at
   RS, if registered before the new OSCORE Security Context has been
   established.  Alternatively, applications need to implement a
   mechanism to ensure that, from then on, messages exchanged within
   those observations are going to be protected with the newly derived
   OSCORE Security Context.

4.8.  Establishing a New OSCORE Security Context

   The procedure of provisioning a new access token to RS specified in
   this section applies to various cases when an OSCORE Security Context
   shared between C and RS has been deleted, for example as described in
   Section 4.7.



Selander, et al.          Expires 23 April 2026                [Page 39]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   Another exceptional case is when there is still a valid OSCORE
   Security Context but it needs to be updated, e.g., due to a policy
   limiting its use in terms of time or amount of processed data, or to
   the imminent exhaustion of the OSCORE Sender Sequence Number space.
   In this case, C and RS MAY alternatively attempt to run a key update
   protocol that they both support.  One lightweight example is KUDOS
   [I-D.ietf-core-oscore-key-update], which is independent of ACE and
   EDHOC and does not require the uploading of an access token.  If C
   and RS does not support a common key update protocol to use for
   updating their still valid OSCORE Security Context, then C and RS
   fall back to EDHOC as outlined above.

   In either case, C and RS establish a new OSCORE Security Context that
   replaces the old one and will be used for protecting their
   communications from then on.  In particular, RS MUST associate the
   new OSCORE Security Context with the current (potentially re-
   uploaded) access token.  Furthermore, the SESSION_ID identifying the
   token series to which the access token belongs to remains unchanged,
   even if C and RS have established a new EDHOC session.  Unless C and
   RS re-run the EDHOC protocol, they preserve their OSCORE identifiers,
   i.e., their OSCORE Sender/Recipient IDs.

4.9.  Access Rights Verification

   RS MUST follow the procedures defined in Section 5.10.2 of [RFC9200].
   That is, if RS receives an OSCORE-protected request targeting a
   protected resource from C, then RS processes the request according to
   [RFC8613].

   If OSCORE verification succeeds and the target resource requires
   authorization, RS retrieves the authorization information using the
   access token associated with the OSCORE Security Context.  Then, RS
   MUST verify that the authorization information covers the target
   resource and the action intended by C on it.

4.10.  Access Token Invalidity

   When an access token becomes invalid (e.g., due to its expiration or
   revocation), RS MUST delete the access token and the associated
   OSCORE Security Context, and MUST notify C with an error response
   with code 4.01 (Unauthorized) for any long running request, as
   specified in Section 5.8.3 of [RFC9200].

4.11.  Authentication Credential Invalidity

   If an authentication credential AUTH_CRED_C of C is invalidated
   (e.g., it expires), then the following applies:




Selander, et al.          Expires 23 April 2026                [Page 40]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  RS MUST delete all the stored access tokens that specify
      AUTH_CRED_C in the "cnf" claim.

   *  C MUST delete every stored access token such that C obtained the
      first access token of the same series through the response to an
      access token request specifying AUTH_CRED_C, e.g., in the
      "req_cnf" parameter (see Section 3.1).

   *  RS and C MUST abort and purge all the EDHOC sessions that used
      AUTH_CRED_C and successfully completed, as well as the OSCORE
      Security Context derived from those sessions (see Section 4.7).

   If an authentication credential AUTH_CRED_RS of RS is invalidated
   (e.g., it expires), then the following applies:

   *  C MUST delete every stored access token such that C obtained the
      first access token of the same series through an access token
      response specifying AUTH_CRED_RS, e.g., in the 'rs_cnf' parameter
      (see Section 3.3).

   *  C MUST delete every stored access token that C specified (by value
      or be reference) during an EDHOC session that used AUTH_CRED_RS
      and successfully completed.

   *  RS and C MUST abort and purge all the EDHOC sessions that used
      AUTH_CRED_RS and successfully completed, as well as the OSCORE
      Security Context derived from those sessions (see Section 4.7).

4.12.  EDHOC Session Invalidity

   If an EDHOC session is aborted and purged for other reasons than
   those in Section 4.11, then RS and C that established the session
   MUST delete the OSCORE Security Context derived from that session
   (see Section 4.7).

4.13.  Using AS Request Creation Hints

   When replying to an unauthorized resource request message from a
   client, RS can send an unprotected AS Request Creation Hints message
   as a 4.01 (Unauthorized) error response (see Section 5.3 of
   [RFC9200]).

   The message payload can specify a number of parameters that help the
   sender client acquire a valid access token from AS.  These parameters
   include "audience" and "scope".






Selander, et al.          Expires 23 April 2026                [Page 41]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   When using this profile and running EDHOC per its reverse message
   flow (see Section 4.4), RS acts as EDHOC Initiator.  A compelling
   reason to do so is the wish to protect the identity of RS against
   active attackers, consistently with the EDHOC security properties.

   However, the identity protection achieved through EDHOC can be
   defeated if RS exposes information such as audience and scope, when
   specifying the corresponding parameters in an unprotected AS Request
   Creation Hints message.

   Therefore, if RS supports the EDHOC reverse message flow and sends an
   AS Request Creation Hints, the following applies:

   *  The message payload MUST NOT include the "audience" parameter.

   *  The message payload SHOULD NOT include the "scope" parameter,
      unless its value cannot contribute to expose the identity of RS.

   AS Request Creation Hints may also be requested and retrieved through
   a new EAD item defined here, see Figure 9, Section 14.8, and an
   example of its usage in Appendix A.3.

   ead_label = TBD
   ? ead_value = bstr .cbor AS_request_creation_hints

   AS_request_creation_hints : map

               Figure 9: EAD item EAD_REQUEST_CREATION_HINTS.

   The AS_request_creation_hints is a CBOR map with keys defined in the
   IANA registry "ACE Authorization Server Request Creation Hints".

   Example: Assuming IANA label 12 and non-critical, so ead_label = 12
   (0x0C), and the AS_request_creation_hints map containing one CBOR
   text string "coap://www.example.com/token" with key 1 (the absolute
   URI of the /token endpoint at the AS):

   *  EAD_REQUEST_CREATION_HINTS =
      0x0C5820A101781C636F61703A2F2F7777772E6578616D70
      6C652E636F6D2F746F6B656E

   Editor's note: Replace IANA label with TBD value registered for
   EAD_REQUEST_CREATION_HINTS in Section 14.8.

   This EAD item is intended to be used in EAD fields of EDHOC messages
   exchanged between C and RS: in the forward message flow in EAD_1 and
   EAD_2, and in the reverse message flow in EAD_2 and EAD_3.  In the
   first EDHOC message from C to RS, an EAD item with ead_label = TBD



Selander, et al.          Expires 23 April 2026                [Page 42]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   with no ead_value asks the RS to include in the next EDHOC message
   the same EAD item with ead_value encoding the
   AS_request_creation_hints map.  This EAD item is non-critical, i.e.,
   it can be ignored by the receiving peer.  It is OPTIONAL to
   implement.

   Since C has not made an actual request targeting a specific
   application resource, the RS may not know what resource C is
   interested in accessing.  Moreover, such information needs to be
   matched against the privacy policy of the application.  Since EDHOC
   message_2 is only protected against passive attackers, the
   AS_request_creation_hints map SHOULD NOT include "audience" and
   "scope" when present in the EAD item conveyed in the EAD_2 field.

4.14.  Requesting Authentication Credential By Value

   EDHOC peers need access to each other's authentication credentials to
   complete the protocol.  However, to reduce unnecessary overhead, the
   EDHOC protocol enables credential references to be sent instead of
   authentication credentials.  The ACE protocol includes the initial
   transport of authentication credentials of C and RS and thus matches
   the use of credential references in EDHOC.

   However, if one of the parties has deleted the other party's
   authentication credential from its local storage, then there should
   be a way to restore it without requesting a new access token.

   Consider first the EDHOC forward message flow.  If the ACE Client /
   EDHOC Initiator sends a credential by reference in message_3, then
   Responder may return error code 3, Unknown credential referenced.
   This enables the Initiator to restart the protocol using some other
   ID_CRED, typically the authentication credential by value thereby
   resolving the issue.  However, in case the ACE Resource Server /
   EDHOC Responder sends a credential by reference in message_2, then
   returning a code 3 EDHOC error message does not automatically solve
   the problem.  Having aborted the protocol, the Responder has no
   reliable way to act differently in a following EDHOC session since it
   never authenticated the Initiator.

   In order to remediate this situation, this section specifies a new
   EAD item for requesting the peer's authentication credential by
   value, see Figure 10, Section 14.8, and an example of its usage in
   Appendix A.3.

   ead_label = TBD

                   Figure 10: EAD item EAD_CRED_BY_VALUE.




Selander, et al.          Expires 23 April 2026                [Page 43]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   This EAD item has no ead_value.  When present in EAD_1, it requests
   the Responder's authentication credential by value in ID_CRED_R of
   message_2.  When present in EAD_2, it requests the Initiator's
   authentication credential by value in ID_CRED_I of message_3.  The
   EAD item is non-critical, i.e., it can be ignored by the receiving
   peer.  It is OPTIONAL to implement.

   Example: Assuming IANA label 15 and non-critical, so ead_label = 15
   (0x0F), and considering that this EAD item has no ead_value:

   *  EAD_CRED_BY_VALUE = 0x0F

   Editor's note: Replace IANA label with TBD value registered for
   EAD_CRED_BY_VALUE in Section 14.8.

   In the EDHOC reverse message flow this EAD item can be applied for
   better control of the use of credential by value.  Note that in the
   reverse flow both C and RS may recover from error code 3, but at the
   cost of more round trips which can be avoided by the use of the EAD
   item.

   *  In case the ACE Client / EDHOC Responder sends a credential by
      reference in message_2 and receives a code 3 error message, then
      it can trigger a new EDHOC session and send credential by value
      this time.

   *  In case the ACE Resource Server / EDHOC Initiator sends a
      credential by reference in message_3 and receives a code 3 error
      message, then since the RS has authenticated C, it can store the
      authentication credential of C, and in the next session with C,
      the RS can send its credential by value.

5.  Secure Communication with AS

   As specified in the ACE framework (see Sections 5.8 and 5.9 of
   [RFC9200]), the requesting entity (RS and/or C) and AS communicates
   via the /token or /introspect endpoint.  When using this profile, the
   use of CoAP [RFC7252] and OSCORE [RFC8613] for this communication is
   RECOMMENDED.  Other protocols fulfilling the security requirements
   defined in Section 5 of [RFC9200] (such as HTTP and DTLS [RFC9147] or
   TLS [RFC8446]) MAY be used instead.










Selander, et al.          Expires 23 April 2026                [Page 44]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   If OSCORE is used, the requesting entity and AS need to have an
   OSCORE Security Context in place.  While this can be pre-installed,
   the requesting entity and AS can establish such an OSCORE Security
   Context, for example, by running the EDHOC protocol, as shown between
   C and AS by the examples in Appendix A.1 and Appendix A.2.  This also
   applies for communication between RS and AS, for example to protect
   the upload of access tokens from AS directly to RS as described in
   [I-D.ietf-ace-workflow-and-params].

6.  CWT Confirmation Methods

   This document defines a number of new CWT confirmation methods, which
   are registered in Section 14.7.  The semantics of each confirmation
   method is defined below.

6.1.  Ordered Chain of X.509 Certificates

   The confirmation method "x5chain" specifies an ordered array of X.509
   certificates [RFC5280].  The semantics of "x5chain" is like that of
   the "x5chain" COSE Header Parameter specified in [RFC9360].

6.2.  Unordered Bag of X.509 Certificates

   The confirmation method "x5bag" specifies a bag of X.509 certificates
   [RFC5280].  The semantics of "x5bag" is like that of the "x5bag" COSE
   Header Parameter specified in [RFC9360].

6.3.  Hash of an X.509 Certificate

   The confirmation method "x5t" specifies the hash value of the end-
   entity X.509 certificate [RFC5280].  The semantics of "x5t" is like
   that of the "x5t" COSE Header Parameter specified in [RFC9360].

6.4.  URI Pointing to an Ordered Chain of X.509 Certificates

   The confirmation method "x5u" specifies the URI [RFC3986] of an
   ordered chain of X.509 certificates [RFC5280].  The semantics of
   "x5u" is like that of the "x5u" COSE Header Parameter specified in
   [RFC9360].

6.5.  Ordered Chain of C509 Certificates

   The confirmation method "c5c" specifies an ordered array of C509
   certificates [I-D.ietf-cose-cbor-encoded-cert].  The semantics of
   "c5c" is like that of the "c5c" COSE Header Parameter specified in
   [I-D.ietf-cose-cbor-encoded-cert].





Selander, et al.          Expires 23 April 2026                [Page 45]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


6.6.  Unordered Bag of C509 Certificates

   The confirmation method "c5b" specifies a bag of C509 certificates
   [I-D.ietf-cose-cbor-encoded-cert].  The semantics of "c5b" is like
   that of the "c5b" COSE Header Parameter specified in
   [I-D.ietf-cose-cbor-encoded-cert].

6.7.  Hash of a C509 Certificate

   The confirmation method "c5t" specifies the hash value of the end-
   entity C509 certificate [I-D.ietf-cose-cbor-encoded-cert].  The
   semantics of "c5t" is like that of the "c5t" COSE Header Parameter
   specified in [I-D.ietf-cose-cbor-encoded-cert].

6.8.  URI Pointing to an Ordered Chain of C509 Certificates

   The confirmation method "c5u" specifies the URI [RFC3986] of a
   COSE_C509 containing an ordered chain of C509 certificates
   [I-D.ietf-cose-cbor-encoded-cert].  COSE_C509 is defined in
   [I-D.ietf-cose-cbor-encoded-cert].  The semantics of "c5u" is like
   that of the "c5u" COSE Header Parameter specified in
   [I-D.ietf-cose-cbor-encoded-cert].

6.9.  CWT Containing a COSE_Key

   The confirmation method "kcwt" specifies a CBOR Web Token (CWT)
   [RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and
   possibly other claims.  The semantics of "kcwt" is like that of the
   "kcwt" COSE Header Parameter specified in [RFC9528].

6.10.  CCS Containing a COSE_Key

   The confirmation method "kccs" specifies a CWT Claims Set (CCS)
   [RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and
   possibly other claims.  The semantics of "kccs" is like that of the
   "kccs" COSE Header Parameter specified in [RFC9528].

7.  JWT Confirmation Methods

   This document defines a number of new JWT confirmation methods, which
   are registered in Section 14.6.  The semantics of each confirmation
   method is defined below.









Selander, et al.          Expires 23 April 2026                [Page 46]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


7.1.  Ordered Chain of X.509 Certificates

   The confirmation method "x5c" specifies an ordered array of X.509
   certificates [RFC5280].  The semantics of "x5c" is like that of the
   "x5c" JSON Web Signature and Encryption Header Parameter specified in
   [RFC7515], with the following difference.  The public key contained
   in the first certificate is the proof-of-possession key and does not
   have to correspond to a key used to digitally sign the JWS.

7.2.  Unordered Bag of X.509 Certificates

   The confirmation method "x5b" specifies a bag of X.509 certificates
   [RFC5280].  The semantics of the "x5b" is like that of the "x5c" JWT
   confirmation method defined in Section 7.1, with the following
   differences.  First, the set of certificates is unordered and may
   contain self-signed certificates.  Second, the composition and
   processing of "x5b" are like for the "x5bag" COSE Header Parameter
   defined in [RFC9360].

7.3.  Hash of an X.509 Certificate

   The confirmation method "x5t" specifies the hash value of the end-
   entity X.509 certificate [RFC5280].  The semantics of "x5t" is like
   that of the "x5t" JSON Web Signature and Encryption Header Parameter
   specified in [RFC7515].

7.4.  URI Pointing to an Ordered Chain of X.509 Certificates

   The confirmation method "x5u" specifies the URI [RFC3986] of an
   ordered chain of X.509 certificates [RFC5280].  The semantics of
   "x5u" is like that of the "x5u" COSE Header Parameter specified in
   [RFC9360], with the following difference.  The public key contained
   in the first certificate is the proof-of-possession key and does not
   have to correspond to a key used to digitally sign the JWS.

7.5.  Ordered Chain of C509 Certificates

   The confirmation method "c5c" specifies an ordered array of C509
   certificates [I-D.ietf-cose-cbor-encoded-cert].  The semantics of
   "c5c" is like that of the "x5c" JWT confirmation method defined in
   Section 7.1, with the following difference.  Each string in the JSON
   array is a base64-encoded (Section 4 of [RFC4648] - not base64url-
   encoded) C509 certificate.








Selander, et al.          Expires 23 April 2026                [Page 47]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


7.6.  Unordered Bag of C509 Certificates

   The confirmation method "c5b" specifies a bag of C509 certificates
   [I-D.ietf-cose-cbor-encoded-cert].  The semantics of "c5b" is like
   that of the "c5c" JWT confirmation method defined in Section 7.5,
   with the following differences.  First, the set of certificates is
   unordered and may contain self-signed certificates.  Second, the
   composition and processing of "c5b" is like for the "c5b" COSE Header
   Parameter defined in [I-D.ietf-cose-cbor-encoded-cert].

7.7.  Hash of a C09 Certificate

   The confirmation method "c5t" specifies the hash value of the end-
   entity C509 certificate [I-D.ietf-cose-cbor-encoded-cert].  The
   semantics of "c5t" is like that of the "x5t" JWT confirmation method
   defined in Section 7.3, with the following differences.  First, the
   base64url-encoded SHA-1 thumbprint is computed over the C509
   certificate.  Second, the public key contained in the C509
   certificate does not have to correspond to a key used to digitally
   sign the JWS.

7.8.  URI Pointing to an Ordered Chain of C509 Certificates

   The confirmation method "c5u" specifies the URI [RFC3986] of
   COSE_C509 containing an ordered chain of C509 certificates
   [I-D.ietf-cose-cbor-encoded-cert].  COSE_C509 is defined in
   [I-D.ietf-cose-cbor-encoded-cert].  The semantics of "c5u" is like
   that of the "x5u" JWT confirmation method defined in Section 7.4,
   with the following differences.  First, the URI refers to a resource
   for the C509 certificate chain.  Second, the public key contained in
   one of the C509 certificates and acting as proof-of-possession key
   does not have to correspond to a key used to digitally sign the JWS.

7.9.  CWT Containing a COSE_Key

   The confirmation method "kcwt" specifies a CBOR Web Token (CWT)
   [RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and
   possibly other claims.  The format of "kcwt" is the base64url-encoded
   serialization of the CWT.

7.10.  CCS Containing a COSE_Key

   The confirmation method "kccs" specifies a CWT Claims Set (CCS)
   [RFC8392] containing a COSE_Key [RFC9053] in a 'cnf' claim and
   possibly other claims.  The format of "kcwt" is the base64url-encoded
   serialization of the CWT.





Selander, et al.          Expires 23 April 2026                [Page 48]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


8.  EDHOC Endpoint Identity Types

   This document defines the following identifier of type of endpoint
   identity for EDHOC.

   Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
   with the RFC number of this specification and delete this paragraph.

    +========+============+====================+=====================+
    | Name   | CBOR label | Description        | Reference           |
    +========+============+====================+=====================+
    | EUI-64 | 0          | An EUI-64 identity | [RFC-XXXX][RFC4291] |
    +--------+------------+--------------------+---------------------+

                  Table 2: EDHOC Endpoint Identity Types

9.  EDHOC Transports

   This document defines the following identifiers of means for
   transporting EDHOC messages.

    +===========+============+===================+====================+
    | Transport | Name       | Description       | Reference          |
    | ID        |            |                   |                    |
    +===========+============+===================+====================+
    | 0         | CoAP over  | EDHOC messages    | [RFC7252],         |
    |           | UDP        | are transported   | Appendix A.2 of    |
    |           |            | as payload of     | [RFC9528]          |
    |           |            | CoAP messages, in |                    |
    |           |            | turn transported  |                    |
    |           |            | over UDP          |                    |
    +-----------+------------+-------------------+--------------------+
    | 1         | CoAP over  | EDHOC messages    | [RFC7252][RFC8323] |
    |           | TCP        | are transported   |                    |
    |           |            | as payload of     |                    |
    |           |            | CoAP messages, in |                    |
    |           |            | turn transported  |                    |
    |           |            | over TCP          |                    |
    +-----------+------------+-------------------+--------------------+
    | 2         | CoAP over  | EDHOC messages    | [RFC7252][RFC8323] |
    |           | WebSockets | are transported   |                    |
    |           |            | as payload of     |                    |
    |           |            | CoAP messages, in |                    |
    |           |            | turn transported  |                    |
    |           |            | over WebSockets   |                    |
    +-----------+------------+-------------------+--------------------+

                         Table 3: EDHOC Transports



Selander, et al.          Expires 23 April 2026                [Page 49]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


10.  EDHOC Trust Anchor Purposes

   This document defines the following EDHOC trust anchor purpose.

   Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
   with the RFC number of this specification and delete this paragraph.

     +============+=======+===================+=====================+
     | Name       | CBOR  | Description       | Reference           |
     |            | label |                   |                     |
     +============+=======+===================+=====================+
     | edhoc_cred | 0     | Verifying         | [RFC-XXXX][RFC9528] |
     |            |       | authentication    |                     |
     |            |       | credentials of    |                     |
     |            |       | other EDHOC peers |                     |
     |            |       | in EDHOC sessions |                     |
     +------------+-------+-------------------+---------------------+

                   Table 4: EDHOC Trust Anchor Purposes

   Trust anchors with purpose "edhoc_cred" are used for verifying
   authentication credentials of other EDHOC peers in an EDHOC session,
   and they typically are authentication credentials of Certificate
   Authorities (CAs).

11.  EDHOC Trust Anchor Types

   This document defines the following EDHOC trust anchor types.

   Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
   with the RFC number of this specification and delete this paragraph.




















Selander, et al.          Expires 23 April 2026                [Page 50]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   +======+=======+===============+=================+=================+
   | Name | CBOR  | Value type    | Description     | Reference       |
   |      | label |               |                 |                 |
   +======+=======+===============+=================+=================+
   | uuid | 0     | #6.37(bstr)   | Binary CBOR-    | [RFC-           |
   |      |       |               | encoded UUID    | XXXX][RFC9562]  |
   +------+-------+---------------+-----------------+-----------------+
   | kid  | 4     | bstr          | Key identifier  | [RFC-           |
   |      |       |               |                 | XXXX][RFC9052]  |
   +------+-------+---------------+-----------------+-----------------+
   | c5t  | 22    | COSE_CertHash | Hash of a C509  | [RFC-           |
   |      |       |               | certificate     | XXXX][draft-    |
   |      |       |               |                 | ietf-cose-cbor- |
   |      |       |               |                 | encoded-cert]   |
   +------+-------+---------------+-----------------+-----------------+
   | c5u  | 23    | uri           | URI pointing to | [RFC-           |
   |      |       |               | a COSE_C509     | XXXX][draft-    |
   |      |       |               | containing a    | ietf-cose-cbor- |
   |      |       |               | ordered chain   | encoded-cert]   |
   |      |       |               | of certificates |                 |
   +------+-------+---------------+-----------------+-----------------+
   | x5t  | 34    | COSE_CertHash | Hash of an      | [RFC-           |
   |      |       |               | X.509           | XXXX][RFC9360]  |
   |      |       |               | certificate     |                 |
   +------+-------+---------------+-----------------+-----------------+
   | x5u  | 35    | uri           | URI pointing to | [RFC-           |
   |      |       |               | an X.509        | XXXX][RFC9360]  |
   |      |       |               | certificate     |                 |
   +------+-------+---------------+-----------------+-----------------+

                    Table 5: EDHOC Trust Anchor Types

12.  Security Considerations

   This document specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework [RFC9200].
   Thus, the general security considerations from the ACE framework also
   apply to this profile.

   Furthermore, the security considerations from OSCORE [RFC8613] and
   from EDHOC [RFC9528] also apply to this specific use of the OSCORE
   and EDHOC protocols.









Selander, et al.          Expires 23 April 2026                [Page 51]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   As previously stated, once completed the EDHOC session, C and RS are
   mutually authenticated through their respective authentication
   credentials, whose retrieval has been facilitated by AS.  Also, once
   completed the EDHOC session, C and RS have established a long-term
   secret key PRK_out enjoying forward secrecy.  This is in turn used by
   C and RS to establish an OSCORE Security Context.

   Furthermore, RS achieves confirmation that C has PRK_out (proof-of-
   possession) when completing the EDHOC session.  Instead, C achieves
   confirmation that RS has PRK_out (proof-of-possession) either when
   receiving the optional EDHOC message_4 from RS, or when successfully
   verifying a response from RS protected with the established OSCORE
   Security Context.

   OSCORE is designed to secure point-to-point communication, providing
   a secure binding between a request and the corresponding response(s).
   Thus, the basic OSCORE protocol is not intended for use in point-to-
   multipoint communication (e.g., enforced via multicast or a publish-
   subscribe model).  Implementers of this profile should make sure that
   their use case of OSCORE corresponds to the expected one, in order to
   prevent weakening the security assurances provided by OSCORE.

   When using this profile, it is RECOMMENDED that RS stores only one
   access token per client.  The use of multiple access tokens for a
   single client increases the strain on RS, since it must consider
   every access token associated with the client and calculate the
   actual permissions that client has.  Also, access tokens indicating
   different or disjoint permissions from each other may lead RS to
   enforce wrong permissions.  If one of the access tokens expires
   earlier than others, the resulting permissions may offer insufficient
   protection.  Developers SHOULD avoid using multiple access tokens for
   a same client.  Furthermore, RS MUST NOT store more than one access
   token per client per PoP-key (i.e., per client's authentication
   credential).

   This profile defines the confirmation methods "kcwt" and "kccs"
   corresponding to the use of CBOR Web Tokens (CWTs) and CWT Claims Set
   (CCSs), respectively.  Security considerations of CWTs and CCSs, and
   of COSE header parameters "kcwt" and "kccs" are given in Section 9.8
   of [RFC9528], and apply also to confirmation methods.  In particular,
   the contents of the CWT or CCS must be processed as untrusted input.
   The application needs to define a trust-establishment mechanism and
   identify the relevant trust anchors.








Selander, et al.          Expires 23 April 2026                [Page 52]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


13.  Privacy Considerations

   This document specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework [RFC9200].
   Thus, the general privacy considerations from the ACE framework also
   apply to this profile.

   Furthermore, the privacy considerations from OSCORE [RFC8613] and
   from EDHOC [RFC9528] also apply to this specific use of the OSCORE
   and EDHOC protocols.

   An unprotected response to an unauthorized request may disclose
   information about RS and/or its existing relationship with C.  It is
   advisable to include as little information as possible in an
   unencrypted response (see also Section 4.13).  When an OSCORE
   Security Context already exists between C and RS, more detailed
   information may be included.

   The (encrypted) access token is never sent in an unprotected POST
   request to the /authz-info endpoint at RS.  Thus, even if C uses the
   same single access token from multiple locations, the access token's
   value does not contribute to the risk of C being tracked.

   The identifiers used in OSCORE, i.e., the OSCORE Sender/Recipient
   IDs, are negotiated by C and RS during the EDHOC session.  When using
   the EDHOC forward (reverse) message flow:

   *  The EDHOC Connection Identifier C_I (C_R) of C is going to be the
      OSCORE Recipient ID of C, i.e., the OSCORE Sender ID of RS.

   *  The EDHOC Connection Identifier C_R (C_I) of RS is going to be the
      OSCORE Recipient ID of RS, i.e., the OSCORE Sender ID of C.

   These OSCORE identifiers are privacy sensitive (see Section 12.8 of
   [RFC8613]).  In particular, they could reveal information about C, or
   may be used for correlating different requests from C, e.g., across
   different networks that C has joined and left over time.  This can be
   mitigated if C and RS dynamically update their OSCORE identifiers,
   e.g., by using the method defined in
   [I-D.ietf-core-oscore-id-update].

14.  IANA Considerations

   This document has the following actions for IANA.

   Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
   with the RFC number of this specification and delete this paragraph.




Selander, et al.          Expires 23 April 2026                [Page 53]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


14.1.  ACE Profiles Registry

   IANA is asked to add the following entry to the "ACE Profiles"
   registry, following the procedure specified in [RFC9200].

   *  Name: coap_edhoc_oscore

   *  Description: Profile for delegating client authentication and
      authorization in a constrained environment by establishing an
      OSCORE Security Context [RFC8613] between resource-constrained
      nodes, through the execution of the lightweight authenticated key
      exchange protocol EDHOC [RFC9528].

   *  CBOR Value: TBD (value between 1 and 23)

   *  Reference: [RFC-XXXX]

14.2.  OAuth Parameters Registry

   IANA is asked to add the following entry to the "OAuth Parameters"
   registry.

   *  Name: edhoc_info

   *  Parameter Usage Location: token request and token response

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]

14.3.  OAuth Parameters CBOR Mappings Registry

   IANA is asked to add the following entry to the "OAuth Parameters
   CBOR Mappings" registry, following the procedure specified in
   [RFC9200].

   *  Name: edhoc_info

   *  CBOR Key: TBD (value between 1 and 255)

   *  Value Type: map

   *  Reference: [RFC-XXXX]

   *  Original Specification: [RFC-XXXX]






Selander, et al.          Expires 23 April 2026                [Page 54]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


14.4.  JSON Web Token Claims Registry

   IANA is asked to add the following entries to the "JSON Web Token
   Claims" registry, following the procedure specified in [RFC7519].

   *  Claim Name: edhoc_info

   *  Claim Description: Information for EDHOC session

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]

14.5.  CBOR Web Token (CWT) Claims Registry

   IANA is asked to add the following entries to the "CBOR Web Token
   (CWT) Claims" registry, following the procedure specified in
   [RFC8392].

   *  Claim Name: edhoc_info

   *  Claim Description: Information for EDHOC session

   *  JWT Claim Name: edhoc_info

   *  Claim Key: TBD (value between 1 and 255)

   *  Claim Value Type: map

   *  Change Controller: IETF

   *  Reference: [RFC-XXXX]

14.6.  JWT Confirmation Methods Registry

   IANA is asked to add the following entries to the "JWT Confirmation
   Methods" registry, following the procedure specified in [RFC7800].

   *  Confirmation Method Value: x5c

   *  Confirmation Method Description: An ordered chain of X.509
      certificates

   *  Change Controller: IETF

   *  Reference: Section 7.1 of [RFC-XXXX]





Selander, et al.          Expires 23 April 2026                [Page 55]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  Confirmation Method Value: x5b

   *  Confirmation Method Description: An unordered bag of X.509
      certificates

   *  Change Controller: IETF

   *  Reference: Section 7.2 of [RFC-XXXX]



   *  Confirmation Method Value: x5t

   *  Confirmation Method Description: Hash of an X.509 certificate

   *  Change Controller: IETF

   *  Reference: Section 7.3 of [RFC-XXXX]



   *  Confirmation Method Value: x5u

   *  Confirmation Method Description: URI pointing to an ordered chain
      of X.509 certificates

   *  Change Controller: IETF

   *  Reference: Section 7.4 of [RFC-XXXX]



   *  Confirmation Method Value: c5c

   *  Confirmation Method Description: An ordered chain of C509
      certificates

   *  Change Controller: IETF

   *  Reference: Section 7.5 of [RFC-XXXX]



   *  Confirmation Method Value: c5b

   *  Confirmation Method Description: An unordered bag of C509
      certificates




Selander, et al.          Expires 23 April 2026                [Page 56]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  Change Controller: IETF

   *  Reference: Section 7.6 of [RFC-XXXX]



   *  Confirmation Method Value: c5t

   *  Confirmation Method Description: Hash of a C509 certificate

   *  Change Controller: IETF

   *  Reference: Section 7.7 of [RFC-XXXX]



   *  Confirmation Method Value: c5u

   *  Confirmation Method Description: URI pointing to a COSE_C509
      containing an ordered chain of C509 certificates

   *  Change Controller: IETF

   *  Reference: Section 7.8 of [RFC-XXXX]



   *  Confirmation Method Value: kcwt

   *  Confirmation Method Description: A CBOR Web Token (CWT) containing
      a COSE_Key in a 'cnf' claim and possibly other claims

   *  Change Controller: IETF

   *  Reference: Section 7.9 of [RFC-XXXX]



   *  Confirmation Method Value: kccs

   *  Confirmation Method Description: A CWT Claims Set (CCS) containing
      a COSE_Key in a 'cnf' claim and possibly other claims

   *  Change Controller: IETF

   *  Reference: Section 7.10 of [RFC-XXXX]





Selander, et al.          Expires 23 April 2026                [Page 57]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


14.7.  CWT Confirmation Methods Registry

   IANA is asked to add the following entries to the "CWT Confirmation
   Methods" registry, following the procedure specified in [RFC8747].

   *  Confirmation Method Name: x5chain

   *  Confirmation Method Description: An ordered chain of X.509
      certificates

   *  JWT Confirmation Method Name: x5c

   *  Confirmation Key: TBD (value between 24 and 255)

   *  Confirmation Value Type: COSE_X509

   *  Change Controller: IETF

   *  Reference: Section 6.1 of [RFC-XXXX]



   *  Confirmation Method Name: x5bag

   *  Confirmation Method Description: An unordered bag of X.509
      certificates

   *  JWT Confirmation Method Name: x5b

   *  Confirmation Key: TBD (value between 24 and 255)

   *  Confirmation Value Type: COSE_X509

   *  Change Controller: IETF

   *  Reference: Section 6.2 of [RFC-XXXX]



   *  Confirmation Method Name: x5t

   *  Confirmation Method Description: Hash of an X.509 certificate

   *  JWT Confirmation Method Name: x5t

   *  Confirmation Key: TBD (value between 1 and 23)

   *  Confirmation Value Type: COSE_CertHash



Selander, et al.          Expires 23 April 2026                [Page 58]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  Change Controller: IETF

   *  Reference: Section 6.3 of [RFC-XXXX]



   *  Confirmation Method Name: x5u

   *  Confirmation Method Description: URI pointing to an ordered chain
      of X.509 certificates

   *  JWT Confirmation Method Name: x5u

   *  Confirmation Key: TBD (value between 1 and 23)

   *  Confirmation Value Type: uri

   *  Change Controller: IETF

   *  Reference: Section 6.4 of [RFC-XXXX]



   *  Confirmation Method Name: c5c

   *  Confirmation Method Description: An ordered chain of C509
      certificates

   *  JWT Confirmation Method Name: c5c

   *  Confirmation Key: TBD (value between 24 and 255)

   *  Confirmation Value Type: COSE_C509

   *  Change Controller: IETF

   *  Reference: Section 6.5 of [RFC-XXXX]



   *  Confirmation Method Name: c5b

   *  Confirmation Method Description: An unordered bag of C509
      certificates

   *  JWT Confirmation Method Name: c5b

   *  Confirmation Key: TBD (value between 24 and 255)



Selander, et al.          Expires 23 April 2026                [Page 59]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  Confirmation Value Type: COSE_C509

   *  Change Controller: IETF

   *  Reference: Section 6.6 of [RFC-XXXX]



   *  Confirmation Method Name: c5t

   *  Confirmation Method Description: Hash of a C509 certificate

   *  JWT Confirmation Method Name: c5t

   *  Confirmation Key: TBD (value between 1 and 23)

   *  Confirmation Value Type: COSE_CertHash

   *  Change Controller: IETF

   *  Reference: Section 6.7 of [RFC-XXXX]



   *  Confirmation Method Name: c5u

   *  Confirmation Method Description: URI pointing to a COSE_C509
      containing an ordered chain of C509 certificates

   *  JWT Confirmation Method Name: c5u

   *  Confirmation Key: TBD (value between 1 and 23)

   *  Confirmation Value Type: uri

   *  Change Controller: IETF

   *  Reference: Section 6.8 of [RFC-XXXX]



   *  Confirmation Method Name: kcwt

   *  Confirmation Method Description: A CBOR Web Token (CWT) containing
      a COSE_Key in a 'cnf' claim and possibly other claims

   *  JWT Confirmation Method Name: kcwt




Selander, et al.          Expires 23 April 2026                [Page 60]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  Confirmation Key: TBD (value between 1 and 23)

   *  Confirmation Value Type: COSE_Messages

   *  Change Controller: IETF

   *  Reference: Section 6.9 of [RFC-XXXX]



   *  Confirmation Method Name: kccs

   *  Confirmation Method Description: A CWT Claims Set (CCS) containing
      a COSE_Key in a 'cnf' claim and possibly other claims

   *  JWT Confirmation Method Name: kccs

   *  Confirmation Key: TBD (value between 1 and 23)

   *  Confirmation Value Type: map / #6(map)

   *  Change Controller: IETF

   *  Reference: Section 6.10 of [RFC-XXXX]

14.8.  EDHOC External Authorization Data Registry

   IANA is asked to add the following entries to the "EDHOC External
   Authorization Data" registry defined in Section 10.5 of [RFC9528].

   *  Name: ACE-OAuth Access Token

   *  Label: TBD (value between 24 and 255)

   *  Description: An Access Token as used in the ACE-OAuth framework
      [RFC9200]

   *  Reference: [RFC-XXXX], Section 4.1



   *  Name: Session ID

   *  Label: TBD (value between 1 and 23)

   *  Description: The identifier of an EDHOC session

   *  Reference: [RFC-XXXX], Section 4.1



Selander, et al.          Expires 23 April 2026                [Page 61]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  Name: Credential By Value

   *  Label: TBD (value between 1 and 23)

   *  Description: The sender peer wishes to receive the other peer's
      credential transported by value (and not identified by reference)

   *  Reference: [RFC-XXXX], Section 4.14



   *  Name: Request Creation Hints

   *  Label: TBD (value between 1 and 23)

   *  Description: Request or convey AS Request Creation Hints

   *  Reference: [RFC-XXXX], Section 4.13

14.9.  EDHOC Information Registry

   IANA is requested to create a new "EDHOC Information" registry within
   the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group
   defined in [RFC9528].

   The registration policy is either "Private Use", "Standards Action
   with Expert Review", "Specification Required" per Section 4.6 of
   [RFC8126], or "Expert Review" per Section 4.5 of [RFC8126].  "Expert
   Review" guidelines are provided in Section 14.14.

   All assignments according to "Standards Action with Expert Review"
   are made on a "Standards Action" basis per Section 4.9 of [RFC8126],
   with Expert Review additionally required per Section 4.5 of
   [RFC8126].  The procedure for early IANA allocation of Standards
   Track code points defined in [RFC7120] also applies.  When such a
   procedure is used, review and approval by the designated expert are
   also required, in order for the WG chairs to determine that the
   conditions for early allocation are met (see step 2 in Section 3.1 of
   [RFC7120]).

   The columns of the registry are:

   *  Name: A descriptive name that enables easier reference to this
      item.  Because a core goal of this document is for the resulting
      representations to be compact, it is RECOMMENDED that the name be
      short.





Selander, et al.          Expires 23 April 2026                [Page 62]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


      This name is case sensitive.  Names may not match other registered
      names in a case-insensitive manner unless the Designated Experts
      determine that there is a compelling reason to allow an exception.
      The name is not used in the CBOR encoding.

   *  CBOR label: The value to be used as CBOR abbreviation of the item.

      The value MUST be unique.  The value can be a positive integer, a
      negative integer, or a string.  Integer values between -256 and
      255 and strings of length 1 are designated as "Standards Action
      with Expert Review".  Integer values from -65536 to -257 and from
      256 to 65535 and strings of maximum length 2 are designated as
      "Specification Required".  Integer values greater than 65535 and
      strings of length greater than 2 are designated as "Expert
      Review".  Integer values less than -65536 are marked as "Private
      Use".

   *  CBOR type: The CBOR type of the item, or a pointer to the registry
      that defines its type, when that depends on another item.

   *  Registry: The registry that values of the item may come from, if
      one exists.

   *  Description: A brief description of the item.

   *  Type: The category of the item, i.e., P if prescriptive or NP if
      Non-Prescriptive.

   *  Specification: A pointer to the public specification for the item,
      if one exists.

   This registry will be initially populated by the values in Table 1.
   In the "Specification" column, the value for all of these entries
   will be [RFC-XXXX] and [RFC9528].

14.10.  EDHOC Endpoint Identity Types Registry

   IANA is requested to create a new "EDHOC Endpoint Identity Types"
   registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)"
   registry group defined in [RFC9528].

   The registration policy is either "Private Use", "Standards Action
   with Expert Review", or "Specification Required" per Section 4.6 of
   [RFC8126].  "Expert Review" guidelines are provided in Section 14.14.

   All assignments according to "Standards Action with Expert Review"
   are made on a "Standards Action" basis per Section 4.9 of [RFC8126],
   with Expert Review additionally required per Section 4.5 of



Selander, et al.          Expires 23 April 2026                [Page 63]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   [RFC8126].  The procedure for early IANA allocation of Standards
   Track code points defined in [RFC7120] also applies.  When such a
   procedure is used, IANA will ask the designated expert(s) to approve
   the early allocation before registration.  In addition, WG chairs are
   encouraged to consult the expert(s) early during the process outlined
   in Section 3.1 of [RFC7120].

   The columns of this registry are:

   *  Name: This field contains the name of the EDHOC endpoint identity
      type.

   *  CBOR label: The value to be used to identify this EDHOC endpoint
      identity type.  These values MUST be unique.  The value can be a
      positive integer or a negative integer.  Different ranges of
      values use different registration policies [RFC8126].  Integer
      values from -24 to 23 are designated as "Standards Action with
      Expert Review".  Integer values from -65536 to -25 and from 24 to
      65535 are designated as "Specification Required".  Integer values
      smaller than -65536 and greater than 65535 are marked as "Private
      Use".

   *  Description: This field contains a short description of the EDHOC
      endpoint identity type.

   *  Reference: This field contains a pointer to the public
      specification for the EDHOC endpoint identity type.

   This registry has been initially populated with the values in
   Table 2.

14.11.  EDHOC Transports Registry

   IANA is requested to create a new "EDHOC Transports" registry within
   the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group
   defined in [RFC9528].

   The registration policy is either "Private Use", "Standards Action
   with Expert Review", or "Specification Required" per Section 4.6 of
   [RFC8126].  "Expert Review" guidelines are provided in Section 14.14.











Selander, et al.          Expires 23 April 2026                [Page 64]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   All assignments according to "Standards Action with Expert Review"
   are made on a "Standards Action" basis per Section 4.9 of [RFC8126],
   with Expert Review additionally required per Section 4.5 of
   [RFC8126].  The procedure for early IANA allocation of Standards
   Track code points defined in [RFC7120] also applies.  When such a
   procedure is used, IANA will ask the designated expert(s) to approve
   the early allocation before registration.  In addition, WG chairs are
   encouraged to consult the expert(s) early during the process outlined
   in Section 3.1 of [RFC7120].

   The columns of this registry are:

   *  Transport ID: The value to be used to identify this means for
      transporting EDHOC messages.  These values MUST be unique.  The
      value can be a positive integer or a negative integer.  Different
      ranges of values use different registration policies [RFC8126].
      Integer values from -24 to 23 are designated as "Standards Action
      with Expert Review".  Integer values from -65536 to -25 and from
      24 to 65535 are designated as "Specification Required".  Integer
      values smaller than -65536 and greater than 65535 are marked as
      "Private Use".

   *  Name: This field contains the name of the means for transporting
      EDHOC messages.

   *  Description: This field contains a short description of the means
      used for transporting EDHOC messages.

   *  Reference: This field contains a pointer to the public
      specification for the means used for transporting EDHOC messages.

   This registry has been initially populated with the values in
   Table 3.

14.12.  EDHOC Trust Anchor Purposes Registry

   IANA is requested to create a new "EDHOC Trust Anchor Purposes"
   registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)"
   registry group defined in [RFC9528].

   The registration policy is either "Private Use", "Standards Action
   with Expert Review", or "Specification Required" per Section 4.6 of
   [RFC8126].  "Expert Review" guidelines are provided in Section 14.14.

   All assignments according to "Standards Action with Expert Review"
   are made on a "Standards Action" basis per Section 4.9 of [RFC8126],
   with Expert Review additionally required per Section 4.5 of
   [RFC8126].  The procedure for early IANA allocation of Standards



Selander, et al.          Expires 23 April 2026                [Page 65]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   Track code points defined in [RFC7120] also applies.  When such a
   procedure is used, IANA will ask the designated expert(s) to approve
   the early allocation before registration.  In addition, WG chairs are
   encouraged to consult the expert(s) early during the process outlined
   in Section 3.1 of [RFC7120].

   The columns of this registry are:

   *  Name: This field contains the descriptive name of the trust anchor
      purpose, to enable easier reference to the item.  These names MUST
      be unique.

   *  CBOR label: This field contains the value used to identify the
      trust anchor purpose.  These values MUST be unique.  The value can
      be an unsigned integer or a negative integer.  Different ranges of
      values use different registration policies:

      -  Integer values from -24 to 23 are designated as "Standards
         Action with Expert Review".

      -  Integer values from -65536 to -25 and from 24 to 65535 are
         designated as "Specification Required".

      -  Integer values smaller than -65536 and greater than 65535 are
         marked as "Private Use".

   *  Description: This field contains a short description of the trust
      anchor purpose.

   *  Reference: This field contains a pointer to the public
      specification for the trust anchor purpose.

   This registry has been initially populated with the values in
   Section 10.

14.13.  EDHOC Trust Anchor Types Registry

   IANA is requested to create a new "EDHOC Trust Anchor Types" registry
   within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry
   group defined in [RFC9528].

   The registration policy is either "Private Use", "Standards Action
   with Expert Review", or "Specification Required" per Section 4.6 of
   [RFC8126].  "Expert Review" guidelines are provided in Section 14.14.

   All assignments according to "Standards Action with Expert Review"
   are made on a "Standards Action" basis per Section 4.9 of [RFC8126],
   with Expert Review additionally required per Section 4.5 of



Selander, et al.          Expires 23 April 2026                [Page 66]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   [RFC8126].  The procedure for early IANA allocation of Standards
   Track code points defined in [RFC7120] also applies.  When such a
   procedure is used, IANA will ask the designated expert(s) to approve
   the early allocation before registration.  In addition, WG chairs are
   encouraged to consult the expert(s) early during the process outlined
   in Section 3.1 of [RFC7120].

   The columns of this registry are:

   *  Name: This field contains the descriptive name of the type of
      trust anchor, to enable easier reference to the item.  These names
      MUST be unique.

   *  CBOR label: This field contains the value used to identify the
      type of trust anchor.  These values MUST be unique.  The value can
      be an unsigned integer or a negative integer.  Different ranges of
      values use different registration policies:

      -  Integer values from -24 to 23 are designated as "Standards
         Action with Expert Review".

      -  Integer values from -65536 to -25 and from 24 to 65535 are
         designated as "Specification Required".

      -  Integer values smaller than -65536 and greater than 65535 are
         marked as "Private Use".

   *  Value type: This field contains the CBOR type for the value
      portion of the label.

   *  Description: This field contains a short description of the type
      of trust anchor.

   *  Reference: This field contains a pointer to the public
      specification for the type of trust anchor.

   This registry has been initially populated with the values in
   Table 5.

14.14.  Expert Review Instructions

   "Standards Action with Expert Review", "Specification Required", and
   "Expert Review" are three of the registration policies defined for
   the IANA registries established in this document.  This section gives
   some general guidelines for what the experts should be looking for,
   but they are being designated as experts for a reason so they should
   be given substantial latitude.




Selander, et al.          Expires 23 April 2026                [Page 67]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   Expert reviewers should take into consideration the following points:

   *  Clarity and correctness of registrations.  Experts are expected to
      check the clarity of purpose and use of the requested entries.
      Experts need to make sure that the object of registration is
      clearly defined in the corresponding specification.  Entries that
      do not meet these objective of clarity and completeness must not
      be registered.

   *  Point squatting should be discouraged.  Reviewers are encouraged
      to get sufficient information for registration requests to ensure
      that the usage is not going to duplicate one that is already
      registered and that the point is likely to be used in deployments.
      The zones tagged as "Private Use" are intended for testing
      purposes and closed environments.  Code points in other ranges
      should not be assigned for testing.

   *  Specifications are required for the "Standards Action with Expert
      Review" range of point assignment.  Specifications should exist
      for "Specification Required" ranges, but early assignment before a
      specification is available is considered to be permissible.  When
      specifications are not provided, the description provided needs to
      have sufficient information to identify what the point is being
      used for.

   *  Experts should take into account the expected usage of fields when
      approving point assignment.  Documents published via Standards
      Action can also register points outside the Standards Action
      range.  The length of the encoded value should be weighed against
      how many code points of that length are left, the size of device
      it will be used on, and the number of code points left that encode
      to that size.

15.  References

15.1.  Normative References

   [COSE.Header.Parameters]
              IANA, "COSE Header Parameters",
              <https://www.iana.org/assignments/cose/cose.xhtml#header-
              parameters>.

   [I-D.ietf-core-uri-path-abbrev]
              Amsüss, C. and M. Richardson, "URI-Path abbreviation in
              CoAP", Work in Progress, Internet-Draft, draft-ietf-core-
              uri-path-abbrev-01, 26 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              uri-path-abbrev-01>.



Selander, et al.          Expires 23 April 2026                [Page 68]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   [I-D.ietf-cose-cbor-encoded-cert]
              Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and
              M. Furuhed, "CBOR Encoded X.509 Certificates (C509
              Certificates)", Work in Progress, Internet-Draft, draft-
              ietf-cose-cbor-encoded-cert-15, 18 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-cose-
              cbor-encoded-cert-15>.

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

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/rfc/rfc3986>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/rfc/rfc4291>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/rfc/rfc4648>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/rfc/rfc5280>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6749>.

   [RFC7120]  Cotton, M., "Early IANA Allocation of Standards Track Code
              Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
              2014, <https://www.rfc-editor.org/rfc/rfc7120>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/rfc/rfc7252>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/rfc/rfc7515>.



Selander, et al.          Expires 23 April 2026                [Page 69]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7519>.

   [RFC7800]  Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
              Possession Key Semantics for JSON Web Tokens (JWTs)",
              RFC 7800, DOI 10.17487/RFC7800, April 2016,
              <https://www.rfc-editor.org/rfc/rfc7800>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/rfc/rfc8126>.

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

   [RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets",
              RFC 8323, DOI 10.17487/RFC8323, February 2018,
              <https://www.rfc-editor.org/rfc/rfc8323>.

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

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

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
              <https://www.rfc-editor.org/rfc/rfc8613>.

   [RFC8742]  Bormann, C., "Concise Binary Object Representation (CBOR)
              Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8742>.

   [RFC8747]  Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
              Tschofenig, "Proof-of-Possession Key Semantics for CBOR
              Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
              2020, <https://www.rfc-editor.org/rfc/rfc8747>.




Selander, et al.          Expires 23 April 2026                [Page 70]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


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

   [RFC9200]  Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
              H. Tschofenig, "Authentication and Authorization for
              Constrained Environments Using the OAuth 2.0 Framework
              (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9200>.

   [RFC9201]  Seitz, L., "Additional OAuth Parameters for Authentication
              and Authorization for Constrained Environments (ACE)",
              RFC 9201, DOI 10.17487/RFC9201, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9201>.

   [RFC9203]  Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
              "The Object Security for Constrained RESTful Environments
              (OSCORE) Profile of the Authentication and Authorization
              for Constrained Environments (ACE) Framework", RFC 9203,
              DOI 10.17487/RFC9203, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9203>.

   [RFC9360]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Header Parameters for Carrying and Referencing X.509
              Certificates", RFC 9360, DOI 10.17487/RFC9360, February
              2023, <https://www.rfc-editor.org/rfc/rfc9360>.

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

   [RFC9562]  Davis, K., Peabody, B., and P. Leach, "Universally Unique
              IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
              2024, <https://www.rfc-editor.org/rfc/rfc9562>.






Selander, et al.          Expires 23 April 2026                [Page 71]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   [RFC9668]  Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
              G. Selander, "Using Ephemeral Diffie-Hellman Over COSE
              (EDHOC) with the Constrained Application Protocol (CoAP)
              and Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 9668, DOI 10.17487/RFC9668, November 2024,
              <https://www.rfc-editor.org/rfc/rfc9668>.

15.2.  Informative References

   [I-D.ietf-ace-coap-est-oscore]
              Selander, G., Raza, S., Furuhed, M., Vučinić, M., and T.
              Claeys, "Protecting EST Payloads with OSCORE", Work in
              Progress, Internet-Draft, draft-ietf-ace-coap-est-oscore-
              08, 7 July 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-ace-coap-est-oscore-08>.

   [I-D.ietf-ace-group-oscore-profile]
              Tiloca, M., Höglund, R., and F. Palombini, "The Group
              Object Security for Constrained RESTful Environments
              (Group OSCORE) Profile of the Authentication and
              Authorization for Constrained Environments (ACE)
              Framework", Work in Progress, Internet-Draft, draft-ietf-
              ace-group-oscore-profile-05, 3 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ace-
              group-oscore-profile-05>.

   [I-D.ietf-ace-workflow-and-params]
              Tiloca, M. and G. Selander, "Short Distribution Chain
              (SDC) Workflow and New OAuth Parameters for the
              Authentication and Authorization for Constrained
              Environments (ACE) Framework", Work in Progress, Internet-
              Draft, draft-ietf-ace-workflow-and-params-05, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ace-
              workflow-and-params-05>.

   [I-D.ietf-core-groupcomm-bis]
              Dijk, E. and M. Tiloca, "Group Communication for the
              Constrained Application Protocol (CoAP)", Work in
              Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
              15, 25 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              groupcomm-bis-15>.









Selander, et al.          Expires 23 April 2026                [Page 72]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   [I-D.ietf-core-oscore-id-update]
              Höglund, R. and M. Tiloca, "Identifier Update for OSCORE",
              Work in Progress, Internet-Draft, draft-ietf-core-oscore-
              id-update-04, 20 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              oscore-id-update-04>.

   [I-D.ietf-core-oscore-key-update]
              Höglund, R. and M. Tiloca, "Key Update for OSCORE
              (KUDOS)", Work in Progress, Internet-Draft, draft-ietf-
              core-oscore-key-update-11, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
              oscore-key-update-11>.

   [I-D.ietf-lake-app-profiles]
              Tiloca, M. and R. Höglund, "Coordinating the Use of
              Application Profiles for Ephemeral Diffie-Hellman Over
              COSE (EDHOC)", Work in Progress, Internet-Draft, draft-
              ietf-lake-app-profiles-02, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lake-
              app-profiles-02>.

   [I-D.ietf-lake-authz]
              Selander, G., Mattsson, J. P., Vučinić, M., Fedrecheski,
              G., and M. Richardson, "Lightweight Authorization using
              Ephemeral Diffie-Hellman Over COSE (ELA)", Work in
              Progress, Internet-Draft, draft-ietf-lake-authz-05, 7 July
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              lake-authz-05>.

   [I-D.serafin-lake-ta-hint]
              Serafin, M. and G. Selander, "Trust Anchor Hints in
              Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in
              Progress, Internet-Draft, draft-serafin-lake-ta-hint-00,
              21 October 2024, <https://datatracker.ietf.org/doc/html/
              draft-serafin-lake-ta-hint-00>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://www.rfc-editor.org/rfc/rfc4949>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.







Selander, et al.          Expires 23 April 2026                [Page 73]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
              Datagram Transport Layer Security (DTLS) Protocol Version
              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
              <https://www.rfc-editor.org/rfc/rfc9147>.

Appendix A.  Examples

   This appendix provides examples where this profile of ACE is used.
   In particular:

   *  Appendix A.1 does not make use of use of any optimization.

   *  Appendix A.2 makes use of the optimizations defined in [RFC9668],
      hence reducing the roundtrips of the interactions between C and
      RS.

   *  Appendix A.3 makes use of the EAD items
      EEAD_REQUEST_CREATION_HINTS (see Section 4.13) and
      EAD_CRED_BY_VALUE (see Section 4.14), allowing C to receive AS
      Request Creation Hints from the RS transported in an EAD item.
      This is useful if C is not be able to determine in advance the
      appropriate AS to contact.

   All these examples build on the following assumptions, as relying on
   expected early procedures performed at AS.  These include the
   registration of resource servers by the respective resource owners as
   well as the registrations of clients authorized to request access
   tokens for those resource servers.

   *  AS knows the authentication credential AUTH_CRED_C of C.

   *  C knows the authentication credential AUTH_CRED_AS of AS.

   *  AS knows the authentication credential AUTH_CRED_RS of RS.

   *  RS knows the authentication credential AUTH_CRED_AS of AS.

      This is relevant in case AS and RS actually require a secure
      association (e.g., for RS to perform token introspection at AS, or
      for AS to upload an access token to RS on behalf of C as described
      in [I-D.ietf-ace-workflow-and-params]).





Selander, et al.          Expires 23 April 2026                [Page 74]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   As a result of the assumptions above, it is possible to limit the
   transport of AUTH_CRED_C and AUTH_CRED_RS by value only to the
   following two cases, and only when C requests an access token for RS
   for the first time when considering the pair (AUTH_CRED_C,
   AUTH_CRED_RS).

   *  In the access token response from AS to C, where AUTH_CRED_RS is
      specified by the "rs_cnf" parameter.

   *  In the access token, where AUTH_CRED_C is specified by the "cnf"
      claim.

   Note that, even under the circumstances mentioned above, AUTH_CRED_C
   might rather be identified by reference.  This is possible if RS can
   effectively use such a reference from the access token to retrieve
   AUTH_CRED_C (e.g., from a trusted repository of authentication
   credentials reachable through a non-constrained link), and if AS is
   in turn aware of that.

   In any other case, it is otherwise possible to identify both
   AUTH_CRED_C and AUTH_CRED_RS by reference, when performing the ACE
   access control workflow as well as later on when C and RS run EDHOC.

A.1.  Workflow without Optimizations

   The example below shows a simple interaction between C and RS: C and
   RS run EDHOC wherein C uploads the access token to RS, and then
   accesses a protected resource at RS.

     C                                 AS                             RS
     |                                  |                              |
     |  EDHOC message_1 to /edhoc       |                              |
 M01 +--------------------------------->|                              |
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_2                 |                              |
 M02 |<---------------------------------+                              |
     |  ID_CRED_R identifies            |                              |
     |     CRED_R = AUTH_CRED_AS        |                              |
     |     by reference                 |                              |
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_3 to /edhoc       |                              |
 M03 +--------------------------------->|                              |
     |  ID_CRED_I identifies            |                              |
     |     CRED_I = AUTH_CRED_C         |                              |
     |     by reference                 |                              |
     |                                  |                              |



Selander, et al.          Expires 23 April 2026                [Page 75]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


     |                                  |                              |
     |  Token request to /token         |                              |
     |  (OSCORE-protected message)      |                              |
 M04 +--------------------------------->|                              |
     |  "req_cnf" identifies            |                              |
     |     AUTH_CRED_C by reference     |                              |
     |                                  |                              |
     |                                  |                              |
     |  Token response                  |                              |
     |  (OSCORE-protected message)      |                              |
 M05 |<---------------------------------+                              |
     |  "rs_cnf" specifies              |                              |
     |     AUTH_CRED_RS by value        |                              |
     |                                  |                              |
     |  "ace_profile" specifies the     |                              |
     |  ACE profile "coap_edhoc_oscore" |                              |
     |                                  |                              |
     |  "edhoc_info" specifies:         |                              |
     |     {                            |                              |
     |       e'session_id' : h'01',     |                              |
     |       e'cipher_suites' : 2,      |                              |
     |       e'methods' : 3,            |                              |
     |       e'uri_path' : "/edhoc"     |                              |
     |     }                            |                              |
     |                                  |                              |
     |  In the access token:            |                              |
     |  - the "cnf" claim specifies     |                              |
     |    AUTH_CRED_C by value          |                              |
     |  - the "edhoc_info" claim        |                              |
     |    specifies the same as         |                              |
     |    "edhoc_info" above            |                              |
     |                                  |                              |

      Possibly after chain verification, C adds AUTH_CRED_RS
      to the set of its trusted peer authentication credentials,
      relying on AS as trusted provider

     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_1 to /edhoc       |                              |
     |  (no access control is enforced) |                              |
 M06 +---------------------------------------------------------------->|
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_2                 |                              |
 M07 |<----------------------------------------------------------------+
     |  ID_CRED_R identifies            |                              |
     |     CRED_R = AUTH_CRED_RS        |                              |



Selander, et al.          Expires 23 April 2026                [Page 76]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


     |     by reference                 |                              |
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_3 to /edhoc       |                              |
     |  (no access control is enforced) |                              |
 M08 +---------------------------------------------------------------->|
     |      EAD_3 contains access token |                              |
     |  ID_CRED_I identifies            |                              |
     |     CRED_I = AUTH_CRED_C         |                              |
     |     by reference                 |                              |
     |                                  |                              |

      Possibly after chain verification, RS adds AUTH_CRED_C
      to the set of its trusted peer authentication credentials,
      relying on AS as trusted provider

     |                                  |                              |
     |                                  |                              |
     |  Access to protected resource    |                              |
     |  (OSCORE-protected message)      |                              |
     |  (access control is enforced)    |                              |
 M08 +---------------------------------------------------------------->|
     |                                  |                              |
     |  Response                        |                              |
     |  (OSCORE-protected message)      |                              |
 M10 |<----------------------------------------------------------------+
     |                                  |                              |

      Later on, the access token expires ...

       - C and RS delete their OSCORE Security Context and purge
         the EDHOC session used to derive it (unless the same
         session is also used for other reasons).
       - RS retains AUTH_CRED_C as still valid,
         and AS knows about it.
       - The Client retains AUTH_CRED_RS as still valid,
         and AS knows about it.

     |                                  |                              |
     |                                  |                              |

      Time passes ...

     |                                  |                              |
     |                                  |                              |

      C asks for a new access token; now all the
      authentication credentials can be identifies by reference



Selander, et al.          Expires 23 April 2026                [Page 77]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


      The price to pay is on AS, about remembering that at least
      one access token has been issued for the pair (Client, RS)
      and considering the pair (AUTH_CRED_C, AUTH_CRED_RS)

     |                                  |                              |
     |                                  |                              |
     |  Token request to /token         |                              |
     |  (OSCORE-protected message)      |                              |
 M11 +--------------------------------->|                              |
     |  "req_cnf" identifies            |                              |
     |     CRED_I = AUTH_CRED_C         |                              |
     |     by reference                 |                              |
     |                                  |                              |
     |                                  |                              |
     |  Token response                  |                              |
     |  (OSCORE-protected message)      |                              |
 M12 |<---------------------------------+                              |
     |  "rs_cnf" identifies             |                              |
     |     AUTH_CRED_RS by reference    |                              |
     |                                  |                              |
     |  "ace_profile" specifies the     |                              |
     |  ACE profile "coap_edhoc_oscore" |                              |
     |                                  |                              |
     |  "edhoc_info" specifies:         |                              |
     |     {                            |                              |
     |       e'session_id' : h'05',     |                              |
     |       e'cipher_suites' : 2,      |                              |
     |       e'methods' : 3,            |                              |
     |       e'uri_path' : "/edhoc"     |                              |
     |     }                            |                              |
     |                                  |                              |
     |  In the access token:            |                              |
     |  - the "cnf" claim identifies    |                              |
     |    AUTH_CRED_C by reference      |                              |
     |  - the "edhoc_info" claim        |                              |
     |    specifies the same as         |                              |
     |    "edhoc_info" above            |                              |
     |                                  |                              |
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_1 to /edhoc       |                              |
     |  (no access control is enforced) |                              |
 M13 +---------------------------------------------------------------->|
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_2                 |                              |
     |  (no access control is enforced) |                              |
 M14 |<----------------------------------------------------------------+



Selander, et al.          Expires 23 April 2026                [Page 78]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


     |  ID_CRED_R identifies            |                              |
     |     CRED_R = AUTH_CRED_RS        |                              |
     |     by reference                 |                              |
     |                                  |                              |
     |                                  |                              |
     |  EDHOC message_3 to /edhoc       |                              |
     |  (no access control is enforced) |                              |
 M15 +---------------------------------------------------------------->|
     |      EAD_3 contains access token |                              |
     |  ID_CRED_I identifies            |                              |
     |     CRED_I = AUTH_CRED_C         |                              |
     |     by reference                 |                              |
     |                                  |                              |
     |                                  |                              |
     |  Access to protected resource /r |                              |
     |  (OSCORE-protected message)      |                              |
     |  (access control is enforced)    |                              |
 M16 +---------------------------------------------------------------->|
     |                                  |                              |
     |                                  |                              |
     |  Response                        |                              |
     |  (OSCORE-protected message)      |                              |
 M17 |<----------------------------------------------------------------+
     |                                  |                              |

A.2.  Workflow with Optimizations

   The example below builds on the example in Appendix A.1, while
   additionally using the EDHOC + OSCORE request defined in [RFC9668]
   when running EDHOC both with AS and with RS.

   This interaction between C and RS consists of only two roundtrips to
   upload the access token, run EDHOC, and access the protected resource
   at RS.

     C                                   AS                           RS
     |                                    |                            |
     |  EDHOC message_1 to /edhoc         |                            |
 M01 +----------------------------------->|                            |
     |                                    |                            |
     |                                    |                            |
     |  EDHOC message_2                   |                            |
 M02 |<-----------------------------------+                            |
     |  ID_CRED_R identifies              |                            |
     |     CRED_R = AUTH_CRED_AS          |                            |
     |     by reference                   |                            |
     |                                    |                            |
     |                                    |                            |



Selander, et al.          Expires 23 April 2026                [Page 79]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


     |  EDHOC + OSCORE request to /token  |                            |
 M03 +----------------------------------->|                            |
     |  - EDHOC message_3                 |                            |
     |      ID_CRED_I identifies          |                            |
     |         CRED_I = AUTH_CRED_C       |                            |
     |         by reference               |                            |
     |  --- --- ---                       |                            |
     |  - OSCORE-protected part           |                            |
     |      Token request                 |                            |
     |         "req_cnf" identifies       |                            |
     |         AUTH_CRED_C by reference   |                            |
     |                                    |                            |
     |                                    |                            |
     |  Token response                    |                            |
     |  (OSCORE-protected message)        |                            |
 M04 |<-----------------------------------+                            |
     |  "rs_cnf" specifies                |                            |
     |     AUTH_CRED_RS by value          |                            |
     |                                    |                            |
     |  "ace_profile" specifies the       |                            |
     |  ACE profile "coap_edhoc_oscore"   |                            |
     |                                    |                            |
     |  "edhoc_info" specifies:           |                            |
     |     {                              |                            |
     |       e'session_id' : h'01',       |                            |
     |       e'cipher_suites' : 2,        |                            |
     |       e'methods' : 3,              |                            |
     |       e'uri_path' : "/edhoc"       |                            |
     |     }                              |                            |
     |                                    |                            |
     |  In the access token:              |                            |
     |  - the "cnf" claim specifies       |                            |
     |    AUTH_CRED_C by value            |                            |
     |  - the "edhoc_info" claim          |                            |
     |    specifies the same as           |                            |
     |    "edhoc_info" above              |                            |
     |                                    |                            |

      Possibly after chain verification, C adds AUTH_CRED_RS
      to the set of its trusted peer authentication credentials,
      relying on AS as trusted provider

     |                                    |                            |
     |  EDHOC message_1 to /edhoc         |                            |
     |  (no access control is enforced)   |                            |
 M05 +---------------------------------------------------------------->|
     |                                    |                            |




Selander, et al.          Expires 23 April 2026                [Page 80]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


      Possibly after chain verification, RS adds AUTH_CRED_C
      to the set of its trusted peer authentication credentials,
      relying on AS as trusted provider

     |                                    |                            |
     |                                    |                            |
     |  EDHOC message_2                   |                            |
 M06 |<----------------------------------------------------------------+
     |  ID_CRED_R identifies              |                            |
     |     CRED_R = AUTH_CRED_RS          |                            |
     |     by reference                   |                            |
     |                                    |                            |
     |                                    |                            |
     |  EDHOC + OSCORE request to /r      |                            |
 M07 +---------------------------------------------------------------->|
     |  - EDHOC message_3                 |                            |
     |      EAD_3 contains access token   |                            |
     |      ID_CRED_I identifies          |                            |
     |         CRED_I = AUTH_CRED_C       |                            |
     |         by reference               |                            |
     |  --- --- ---                       |                            |
     |  - OSCORE-protected part           |                            |
     |      Application request to /r     |                            |
     |                                    |                            |

      After the EDHOC processing is completed, access control
      is enforced on the rebuilt OSCORE-protected request,
      like if it had been sent stand-alone

     |                                    |                            |
     |                                    |                            |
     |  Response                          |                            |
     |  (OSCORE-protected message)        |                            |
 M08 |<----------------------------------------------------------------+
     |                                    |                            |

A.3.  Non-sequential Workflow

   When this profile is used, the C might not be able to determine in
   advance the appropriate AS to contact.  In such cases, C may initiate
   EDHOC with RS prior to obtaining an access token and rely on RS to
   provide this information.









Selander, et al.          Expires 23 April 2026                [Page 81]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   One approach, as detailed in this section, is for RS to convey this
   information by including an External Authorization Data (EAD) item in
   EDHOC message_2.  The content of this EAD item is the information
   conveyed in a Request Creation Hints response, thereby helping C to
   identify the correct AS, and possibly other relevant parameters
   needed to request an access token.

   The following describes an example scenario where this functionality
   is used in the EDHOC forward message flow, in particular taking
   advantage of the new EAD items EAD_REQUEST_CREATION_HINTS (see
   Section 4.13) and EAD_CRED_BY_VALUE (see Section 4.14).

   1.  Without having an access token, C sends EDHOC message_1 to RS,
       including in EAD_1:

       *  A new EAD item EAD_REQUEST_CREATION_HINTS, here specifying no
          ead_value.

          By doing so, C is asking RS to include the same EAD item in
          EAD_2, specifying the information that would be included in a
          Request Creation Hints response.

       *  A new EAD item EAD_CRED_BY_VALUE, asking RS to specify its
          authentication credential AUTH_CRED_RS by value in ID_CRED_R.

   2.  RS replies with EDHOC message_2, including in EAD_2:

       *  The new EAD item EAD_REQUEST_CREATION_HINTS, whose CBOR byte
          string specified as ead_value encodes the information that
          would have been included in a Request Creation Hints response
          to an unauthorized request sent to RS.  In particular, this
          information includes the URI to the /token endpoint at the AS.

          However, note that C has not made an actual request with a
          specific request method and targeting a specific application
          resource.  That is, RS does not know yet what resources C is
          actually interested in accessing later on.  Hence, the
          information specified in this EAD_REQUEST_CREATION_HINTS item
          is typically not expected to include "audience" and "scope".

   3.  C requests an access token for the right audience and scope from
       the right AS, based on pre-configured parameters on the client
       and the information from EAD_REQUEST_CREATION_HINTS within EDHOC
       message_2, like if C had received a Request Creation Hints
       response.






Selander, et al.          Expires 23 April 2026                [Page 82]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


       C should already know the right audience and scope to specify in
       the Access Token Request, as that information is not expected to
       be provided by RS in the EAD_REQUEST_CREATION_HINTS item of EDHOC
       message_2.  There may also be default audience and scope set at
       the AS to use, if none is specified by C in its Access Token
       Request.

   4.  C sends EDHOC message_3 to RS, specifying the access token in
       EAD_3 as value of the EAD item "EAD_ACCESS_TOKEN".

   5.  If a protected request from C for accessing a resource at RS is
       not authorized per the issued access token, then RS replies with
       a protected error response.  Within that error response, RS can
       provide C with information that would have been specified in a
       Request Creation Hints response.  This time, that information
       also includes "audience" and "scope".  After this, C can follow-
       up requesting a new access token that dynamically updates access
       rights accordingly (see Section 3.1).

       Note that this applies also if C uses the EDHOC + OSCORE combined
       request (see [RFC9668]), hence combining EDHOC message_3 with the
       first OSCORE-protected request to access a protected resource at
       RS (see Appendix A.2).

   If, instead, the EDHOC reverse message flow is used, then the
   following differences compared to what is described above apply:

   *  EAD_REQUEST_CREATION_HINTS and EAD_CRED_BY_VALUE are included in
      EDHOC message_2 by C, in order to ask RS to provide the Request
      Creation Hints information and to specify AUTH_CRED_RS by value in
      ID_CRED_I, respectively.

   *  EAD_REQUEST_CREATION_HINTS is included in EDHOC message_3 by RS,
      with value the Request Creation Hints information.

   *  After receiving EDHOC message_3, C requests the access token to
      the AS, based on the information from EAD_REQUEST_CREATION_HINTS
      in EDHOC message_3.

   *  Finally, C sends EDHOC message_4 to RS, specifying the access
      token in EAD_4 as value of the EAD item "EAD_ACCESS_TOKEN".

Appendix B.  Profile Requirements

   This section lists the specifications of this profile based on the
   requirements of the framework, as requested in Appendix C of
   [RFC9200].




Selander, et al.          Expires 23 April 2026                [Page 83]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  Optionally, define new methods for the client to discover the
      necessary permissions and AS for accessing a resource, different
      from the one proposed in [RFC9200]: Not specified

   *  Optionally, specify new grant types: Not specified

   *  Optionally, define the use of client certificates as client
      credential type: C can use authentication credentials of any type
      admitted by the EDHOC protocol, including public key certificates
      such as X.509 and C509 certificates.

   *  Specify the communication protocol the client and RS must use:
      CoAP

   *  Specify the security protocol the client and RS must use to
      protect their communication: OSCORE

   *  Specify how the client and RS mutually authenticate: Explicitly,
      by successfully executing the EDHOC protocol, after which a common
      OSCORE Security Context is exported from the EDHOC session.  As
      per the EDHOC authentication method used during the EDHOC session,
      authentication is provided by digital signatures, or by Message
      Authentication Codes (MACs) computed from an ephemeral-static ECDH
      shared secret.

   *  Specify the proof-of-possession protocol(s) and how to select one,
      if several are available.  Also specify which key types (e.g.,
      symmetric/asymmetric) are supported by a specific proof-of-
      possession protocol: proof-of-possession is first achieved by RS
      when successfully processing EDHOC message_3 during the EDHOC
      session with C, through EDHOC algorithms and symmetric EDHOC
      session keys.  Also, proof-of-possession is later achieved by C
      when receiving from RS: i) the optional EDHOC message_4 during the
      EDHOC session with RS, through EDHOC algorithms and symmetric
      EDHOC session keys; or ii) the first response protected with the
      OSCORE Security Context established after the EDHOC session with
      RS, through OSCORE algorithms and OSCORE symmetric keys derived
      from the completed EDHOC session.

   *  Specify a unique ace_profile identifier: coap_edhoc_oscore

   *  If introspection is supported, specify the communication and
      security protocol for introspection: HTTP/CoAP (+ TLS/DTLS/OSCORE)

   *  Specify the communication and security protocol for interactions
      between client and AS: HTTP/CoAP (+ TLS/DTLS/OSCORE)





Selander, et al.          Expires 23 April 2026                [Page 84]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  Specify if/how the authz-info endpoint is protected, including how
      error responses are protected: Not protected

   *  Optionally, define methods of token transport other than the
      authz-info endpoint: C can upload the access token when executing
      EDHOC with RS, by including the access token in the EAD_3 field of
      EDHOC message_3 (see Section 4.2).

Appendix C.  CDDL Model

   This section is to be removed before publishing as an RFC.








































Selander, et al.          Expires 23 April 2026                [Page 85]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   ; ACE Profiles
   coap_edhoc_oscore = 4

   ; OAuth Parameters CBOR Mappings
   edhoc_info_param = 47

   ; CBOR Web Token (CWT) Claims
   edhoc_info_claim = 41

   ; CWT Confirmation Methods
   x5t = 6
   x5u = 7
   c5t = 8
   c5u = 9
   kcwt = 10
   kccs = 11
   x5chain = 24
   x5bag = 25
   c5c = 26
   c5b = 27

   ; EDHOC Information
   session_id = 0
   methods = 1
   cipher_suites = 2
   message_4 = 3
   comb_req = 4
   uri_path = 5
   cred_types = 6
   id_cred_types = 7
   eads = 8
   initiator = 9
   responder = 10
   max_msgsize = 11
   coap_ct = 12
   ep_id_types = 13
   transports = 14
   trust_anchors = 15

   ; EDHOC Trust Anchor Purposes
   edhoc_cred = 0

   ; EDHOC Trust Anchor Types
   c5t_ta_type = 22
   c5u_ta_type = 23
   x5t_ta_type = 34
   x5u_ta_type = 35




Selander, et al.          Expires 23 April 2026                [Page 86]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


                           Figure 11: CDDL model

Appendix D.  Document Updates

   This section is to be removed before publishing as an RFC.

D.1.  Version -08 to -09

   *  Parameter "cnf" explicitly forbidden in the Access Token Response.

   *  Clarification about content of "cnf" claim in the access token.

   *  RS must support the CoAP Uri-Path-Abbrev Option and its value
      abbreviating /.well-known/edhoc.

   *  Example of Request Creation Hints provided in EAD item.

   *  Examples showing content of new EAD items.

D.2.  Version -07 to -08

   *  KUDOS is just an example of protocol to use for optional key
      update.

   *  message_4 is mandatory to support for an RS that supports the
      reverse message flow.

   *  Method in -workflow-and-params as example for coordinating the
      exchange of authentication credentials by value or reference.

   *  Revised initial set of EDHOC_Information parameters.

   *  Defined categorization of EDHOC_Information parameters.

   *  New EAD item for C to retrieve Request Creation Hints information
      from RS.

   *  New EAD item for requesting authentication credential by value.

   *  Means for the AS to achive proof-of-possession of C's private key.

   *  Editorial improvements.

D.3.  Version -06 to -07

   *  Renamed id_ep_types as ep_id_types.

   *  Revised rules for the AS to assign session ID values.



Selander, et al.          Expires 23 April 2026                [Page 87]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  Added explicit validation of AUTH_CRED_C at AS.

   *  "edhoc_info" only in AS-to-C response for first token in a series.

   *  With a group-audience, "edhoc_info" refers to the whole audience.

   *  Defined parameters for the EDHOC_Information object:

      -  Parameters moved here from draft-ietf-lake-app-profiles.

      -  New parameter "trust_anchors".

   *  Access Token Request/Response messages must be encoded in CBOR.

   *  Explicit statement on admitted confirmation methods.

   *  First token in a series: the "cnf" claim uses the same
      confirmation method of the "req_cnf" request to /token.

   *  Revised examples in CBOR diagnostic notation.

   *  With a group-audience, the reverse message flow can use a roll
      call.

   *  Matching authentication credentials from ID_CRED_X and EAD item.

   *  Handling authentication credentials and EDHOC session that become
      invalid.

   *  Limited use of ACE Request Creation Hints when supporting the
      EDHOC reverse message flow.

   *  Changed CBOR abbreviations to not collide with existing
      codepoints.

   *  Updates and fixes in the IANA considerations.

   *  Updated references.

   *  Clarifications and editorial improvements.

D.4.  Version -05 to -06

   *  The access token can be uploaded through EDHOC in EAD_3, EAD_2, or
      EAD_4.

   *  Ruled out the upload of the access token to the /authz-info
      endpoint over an unprotected channel.



Selander, et al.          Expires 23 April 2026                [Page 88]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  Defined an EDHOC EAD item for transporting a Session ID.

   *  Provided more details and added example of dynamic update of
      access rights.

   *  Defined in detail the use of the EDHOC reverse message flow.

   *  Provided details on access token invalidity.

   *  Revised examples with message exchanges.

   *  Clarifications and editorial improvements.

D.5.  Version -04 to -05

   *  CBOR diagnostic notation uses placeholders from a CDDL model.

   *  Only CWTs are supported as access tokens in this profile.

   *  The alternative workflow of ACE is only mentioned as an example.

   *  Clarified that both the EDHOC forward and reverse message flows
      are possible.

   *  Consistent with the used EDHOC message flow, the access token can
      be in the EAD item of any EDHOC message.

   *  Explicit registration policies for the new IANA registry.

   *  Fixes in the IANA considerations.

   *  Editorial fixes and improvements.

D.6.  Version -03 to -04

   *  Fixed column name and prefilling of the "EDHOC Information"
      registry.

   *  Added EDHOC_Information Parameters originally in draft-tiloca-
      lake-app-profiles-00.

   *  Removed the case of transporting access token in EAD_1

   *  Removed redundant normative text

   *  Clarifications of association between access token, session_id,
      EDHOC session and OSCORE security context




Selander, et al.          Expires 23 April 2026                [Page 89]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  Updated references.

   *  Editorial fixes and improvements.

D.7.  Version -02 to -03

   *  Restructured presentation of content.

   *  Simplified description of the use of EDHOC_Information.

   *  Merged the concepts of EDHOC "session_id" and identifier of token
      series.

   *  Enabled the transport of the access token also in EDHOC EAD_3.

   *  Defined semantics of the newly defined CWT/JWT Confirmation
      Methods.

   *  Clarifications and editorial improvements.

D.8.  Version -01 to -02

   *  Removed use of EDHOC_KeyUpdate.

   *  The Security Context is updated either by KUDOS or a rerun of
      EDHOC.

   *  The alternative workflow (AS token posting) is specified in
      separate draft.

   *  Fixed and updated examples.

   *  Editorial improvements.

D.9.  Version -00 to -01

   *  Fixed semantics of the ead_value for transporting an Access Token
      in the EAD_1 field.

   *  Error handling aligned with EDHOC.

   *  Precise characterization of the EDHOC execution considered for
      EDHOC-KeyUpdate.

   *  Fixed message exchange examples.

   *  Added appendix with profile requirements.




Selander, et al.          Expires 23 April 2026                [Page 90]

Internet-Draft       EDHOC and OSCORE profile of ACE        October 2025


   *  Updated references.

   *  Clarifications and editorial improvements.

Acknowledgments

   The authors sincerely thank Christian Amsüss and Carsten Bormann for
   their comments and feedback.

   The parameter "trust_anchors" for specifying supported trust anchors
   builds on a proposal originally described in
   [I-D.serafin-lake-ta-hint].

   This work was supported by the Sweden's Innovation Agency VINNOVA
   within the EUREKA CELTIC-NEXT project CYPRESS; and by the H2020
   project SIFIS-Home (Grant agreement 952652).

Authors' Addresses

   Göran Selander
   Ericsson
   Email: goran.selander@ericsson.com


   John Preuß Mattsson
   Ericsson
   Email: john.mattsson@ericsson.com


   Marco Tiloca
   RISE
   Email: marco.tiloca@ri.se


   Rikard Höglund
   RISE
   Email: rikard.hoglund@ri.se














Selander, et al.          Expires 23 April 2026                [Page 91]


name: draft-josefsson-chempat
rev: 04
title: Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms
time: 2025-10-20T17:30:41Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T17:30:41Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:09.014910+00:00
abstract:
This document specify Chempat as a generic family of instantiated
   Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs).
   The goal is to provide a generic combiner construct that can be
   analysed separately for security assurance, and to offer concrete
   instantiated algorithms for integration into protocol and
   implementations.  Identified instances are provided based on some
   combinations of traditional Diffie-Hellman key agreement using curves
   P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 and
   brainpoolP512 combined with post quantum methods ML-KEM-768, ML-KEM-
   1024, Streamlined NTRU Prime sntrup761, Classic McEliece and
   FrodoKEM.

full_text:
CFRG                                                        S. Josefsson
Internet-Draft                                           20 October 2025
Intended status: Informational                                          
Expires: 23 April 2026


 Chempat: Generic Instantiated PQ/T Hybrid Key Encapsulation Mechanisms
                       draft-josefsson-chempat-04

Abstract

   This document specify Chempat as a generic family of instantiated
   Post-Quantum/Traditional (PQ/T) Hybrid Key Exchange Methods (KEMs).
   The goal is to provide a generic combiner construct that can be
   analysed separately for security assurance, and to offer concrete
   instantiated algorithms for integration into protocol and
   implementations.  Identified instances are provided based on some
   combinations of traditional Diffie-Hellman key agreement using curves
   P-256, P-384, X25519, X448, brainpoolP256, brainpoolP384 and
   brainpoolP512 combined with post quantum methods ML-KEM-768, ML-KEM-
   1024, Streamlined NTRU Prime sntrup761, Classic McEliece and
   FrodoKEM.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-josefsson-chempat/.

   Discussion of this document takes place on the Crypto Forum Research
   Group (CFRG) Research Group mailing list (mailto:cfrg@ietf.org),
   which is archived at https://mailarchive.ietf.org/arch/browse/cfrg/.

   Source for this draft and an issue tracker can be found at
   https://gitlab.com/jas/ietf-chempat.

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





Josefsson                 Expires 23 April 2026                 [Page 1]

Internet-Draft                   Chempat                    October 2025


   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 23 April 2026.

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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Comparison to X-Wing  . . . . . . . . . . . . . . . . . . . .   4
   4.  Comparison to HPKE X25519Kyber768Draft00  . . . . . . . . . .   4
   5.  Comparison to KEM Generic Combiner  . . . . . . . . . . . . .   5
   6.  Design Goals  . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   8.  Chempat . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   9.  Naming  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   10. Use in HPKE . . . . . . . . . . . . . . . . . . . . . . . . .   7
   11. Chempat-X25519-sntrup761  . . . . . . . . . . . . . . . . . .   9
   12. Chempat with Classic McEliece with X448 and X25519  . . . . .   9
   13. Chempat with (e)FrodoKEM and X25519/Brainpool . . . . . . . .  11
   14. Chempat-X25519-ML-KEM-768 . . . . . . . . . . . . . . . . . .  12
   15. Chempat-X448-ML-KEM-1024  . . . . . . . . . . . . . . . . . .  13
   16. Chempat-P256-ML-KEM-768 . . . . . . . . . . . . . . . . . . .  13
   17. Chempat-P384-ML-KEM-1024  . . . . . . . . . . . . . . . . . .  13
   18. Chempat-brainpoolP256-ML-KEM-768  . . . . . . . . . . . . . .  14
   19. Chempat-brainpoolP384-ML-KEM-1024 . . . . . . . . . . . . . .  14
   20. Security Considerations . . . . . . . . . . . . . . . . . . .  14
   21. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   22. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
   23. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     23.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     23.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20





Josefsson                 Expires 23 April 2026                 [Page 2]

Internet-Draft                   Chempat                    October 2025


1.  Introduction

   To hedge against attacks on a traditional key agreement algorithm
   such as X25519 [RFC7748] and a post-quantum key encapsulation
   mechanism (KEM) such as ML-KEM-768 [MLKEM], it is possible to combine
   both algorithms to derive a shared secret [GHP18] and define the
   combination mechanism as a new KEM.  Using the terminology of
   [RFC9794], this combination forms a PQ/T Hybrid Key Encapsulation
   Mechanism.

   Chempat is a generic pattern to create a PQ/T Hybrid Key
   Encapsulation Mechanism based on at least one post-quantum algorithm
   and at least one traditional algorithm.  The idea is that the Chempat
   combiner can be analyzed generally and some assurance can be had that
   it behaves well.  For ease of presentation, this document combine one
   traditional DH-Based KEM algorithm with one post-quantum KEM
   algorithm.

   While a natural approach would be to integrate the generic key
   combiner construct into protocols and have the protocol and
   implementation negotiate parameters, that leads to complexity
   detrimental to security.  Therefor this document describe specific
   instances of Chempat applied on selected algorithms.

2.  Motivation

   There are many choices that can be made when specifying a hybrid KEM:
   the constituent KEMs; their security levels; the combiner; and the
   hash within, to name but a few.  Having too many similar options are
   a burden to the ecosystem.

   The above argues for having carefully selected instantiated hybrid
   KEMs.  Each hybrid KEM should be analysed to meet security targets.
   If that analysis assume specific behaviour of the combiner, or if the
   analysis become more complex due to the combiner, that leads to more
   work to re-use the analysis for other combinations.  While it would
   be preferrable to only specify one hybrid KEM and analyse that, such
   as [XWING], cryptographic history suggests that algorithm preferences
   varies over time.

   The argument then is to establish a generic method that can be
   analysed independent of its component algorithms, such as
   [KEMCOMBINER].  Generic methods can lead to parametrized protocols
   and implementations that is more difficult to analyse, and a lack of
   instantiated algorithm identifiers.






Josefsson                 Expires 23 April 2026                 [Page 3]

Internet-Draft                   Chempat                    October 2025


   While non-hybrid approaches may eventually be preferrable, there are
   doubts on what properties protocols demand from cryptographic
   primitives, and some of the properties are different from what have
   been expected from traditional algorithms [CDM23].  This suggests
   that some post-quantum KEM's should be used together with a other
   algorithms to strengthen the properties.

   Finally this leads up to our approach to describe a generic method
   that can be analysed independently of the individual components, with
   as few parameters as possible in the generic combiner, and to
   instantiate it with common algorithm choices that make sense for
   protocols and implementations.  That is the essence of Chempat.

3.  Comparison to X-Wing

   X-Wing [XWING] is a Hybrid PQ/T KEM based on X25519 and ML-KEM-768.
   Main differences:

   *  Chempat is applicable to other algorithm combinations, X-Wing's
      combiner does not extend securely to other KEM combinations.

   *  Chempat on X25519 with ML-KEM-768 will hash the ML-KEM ciphertext
      and public key.

   *  Chempat on X25519 with ML-KEM-768 can provide a per-protocol key-
      domain separation context string.

4.  Comparison to HPKE X25519Kyber768Draft00

   HPKE's X25519Kyber768Draft00 [XYBERHPKE] is similar to X-Wing.  Main
   differences to Chempat:

   *  Chempat is applicable to other algorithm combinations,
      X25519Kyber768Draft00's combiner does not extend securely to other
      KEM combinations.

   *  Chempat hashes the shared secret, to be usable outside of HPKE.

   *  Chempat hashes the combined ciphertext and public keys.

   There is also a different KEM called X25519Kyber768Draft00 [XYBERTLS]
   which is used in TLS.  This one should not be used outside of TLS, as
   it assumes the presence of the TLS transcript to ensure non
   malleability.







Josefsson                 Expires 23 April 2026                 [Page 4]

Internet-Draft                   Chempat                    October 2025


5.  Comparison to KEM Generic Combiner

   Chempat is most similar to the generic combiner in [KEMCOMBINER].
   Main differences:

   *  Chempat offers instantiated identified Hybrid KEMs for direct use
      in protocols and implementations.

   *  Chempat offers the possibility of a generic simpler security
      argument for the combiner, whereas [KEMCOMBINER] is parametrized
      with several algorithm choices and any security analysis needs to
      be parametrized over the numerous options permitted.

   *  Chempat has a fixed 32 byte shared secret instead of a variable
      length shared secret.

   *  Chempat hashes the public keys of the component KEM's.

6.  Design Goals

   While Chempat share a lot with [XWING], [XYBERHPKE] and [KEMCOMBINER]
   the following goals set it apart:

   *  Allow generic security analysis independent of combinations.

   *  Provide concrete instantiated algorithm identifiers for several
      anticipated uses of Hybrid KEM combinations.

   We aim for instantiated algorithms of Chempat to be usable for most
   applications, including specifically HPKE [RFC9180], TLS [RFC8446],
   OpenPGP [RFC4880] and SSH [RFC4251].

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

   The following terms are used throughout this document:

   string - array of bytes

   func1(), func2(a,b) - denote functions called FUNC1 and FUNC2 that
   takes no parameters and two parameters a and b, respectively.





Josefsson                 Expires 23 April 2026                 [Page 5]

Internet-Draft                   Chempat                    October 2025


   concat(x0, ..., xN): returns the concatenation of byte strings.
   concat(0x01, 0x0203, 0x040506) = 0x010203040506.

   random(n): return a pseudorandom byte string of length n bytes
   produced by a cryptographically-secure random number generator.

8.  Chempat

   Chempat is defined as follows:

   H = SHA3-256

   hybrid_pk = concat(receiver_pk_TKEM, receiver_pk_PQKEM)

   hybrid_ct = concat(sender_ct_TKEM, sender_ct_PQKEM)

   hybrid_ss = H(concat(ss_TKEM,
                        ss_PQKEM,
                        H(hybrid_ct),
                        H(hybrid_pk),
                        context))

   The hash function SHA3-256 is defined in [NIST.FIPS.202].

   The hybrid_pk string is the concatenation of the serialized public-
   key output from the traditional (receiver_pk_TEM) and post-quantum
   (receiver_pk_PQKEM) respectively.  To reduce memory usage it is
   possible to hash the public keys to pre-compute H(hybrid_pk) directly
   when hybrid_pk is received.

   The hybrid_ct string is the concatenation of the serialized
   ciphertext output from the traditional (receiver_ct_TEM) and post-
   quantum (receiver_ct_PQKEM) respectively.  To reduce memory usage it
   is possible to hash the ciphertext to pre-compute H(hybrid_ct)
   directly when hybrid_ct is received.

   The hybrid_ss string is the 32-byte output shared secret, formed as
   the output of the SHA3-256 hash function.  The inputs to the hash
   function is a concatenation of the shared secrets from the
   traditional (ss_TKEM) and post-quantum (ss_PQKEM) KEMs with the
   hashes of the ciphertexts (H(hybrid_ct)) and public keys
   (H(hybrid_pk)) together with a variable-length protocol-specific
   context string.

   The context string can be chosen uniquely by the protocol referencing
   this document.  The purpose is to provide protocol domain separation
   of the generated keys.  The content is arbitrary, and in practice the
   name of the protocol will suffice.  Since this results in a new



Josefsson                 Expires 23 April 2026                 [Page 6]

Internet-Draft                   Chempat                    October 2025


   Chempat instance, to reduce combinatorical complexity of parameters,
   we provide one instance with the context variable set to the name of
   the Chempat instance, for example "Chempat-X25519-sntrup761".

9.  Naming

   Protocols wishing to utilize a PQ/T Hybrid KEM described in this
   document MUST refer to one of the derived instantiated algorithm
   identifiers and MUST NOT specify a generic construction where the
   individual algorithms are parameters.

   The convention for identifiers is "Chempat-TKEM-PQKEM" replacing
   "TKEM" and "PQKEM" with a brief mnemonic identifying the traditional
   and post-quantum algorithm respectively.

10.  Use in HPKE

   Each Chempat instance satisfy the HPKE KEM interface as follows.

   The SerializePublicKey, DeserializePublicKey, SerializePrivateKey and
   DeserializePrivateKey are concatenation and splitting of the known-
   length component strings.





























Josefsson                 Expires 23 April 2026                 [Page 7]

Internet-Draft                   Chempat                    October 2025


   H = SHA3-256

   def GenerateKeyPair():
     (pk_T, sk_T) = DHKEM.KeyGen()
     (pk_PQ, sk_PT) = PQKEM.KeyGen()
     return (concat(sk_T, sk_PQ, pk_T, pk_PQ), concat(pk_T, pk_PQ))

   # TBA DeriveKeyPair

   def Chempat(ss_T, ss_PQ, ct_T, ct_PQ, pk_T, pk_PQ):
     return H(concat(ss_T,
                     ss_PQ,
                     H(concat(ct_T, ct_PQ)),
                     H(concat(pk_T, pk_PQ)),
                     Context))

   def Encapsulate(pk):
     pk_T = pk[0:DHKEM.Npk]
     pk_PQ = pk[DHKEM.Npk:PQKEM.Npk-DHKEM.Npk]
     (ss_T, ct_T) = DHKEM.Encap(pk_T)
     (ss_PQ, ct_PQ) = PQKEM.Encap(pk_PQ)
     ss = Chempat(ss_T, ss_PQ, ct_T, ct_PQ, pk_T, pk_PQ)
     ct = concat(ct_T, ct_PQ)
     return (ss, ct)

   def Decapsulate(ct, sk):
     ct_T = ct[0:DHKEM.Nenc]
     ct_T = ct[DHKEM.Nenc:PQKEM.Nenc-DHKEM.Nenc]
     sk_PQ = sk[0:DHKEM.Nsecret]
     sk_T = sk[DHKEM.Nsecret:PQKEM.Nsecret-DHKEM.Nsecret]
     pk_T = sk[0:DHKEM.Npk]
     pk_PQ = sk[DHKEM.Npk:PQKEM.Npk-DHKEM.Npk]
     ss_T = DHKEM.Decap(ct_T, sk_T)
     ss_PQ = PQKEM.Decap(ct_PQ, sk_PQ)
     return Chempat(ss_T, ss_PQ, ct_T, ct_PQ, pk_T, pk_PQ)

   Chempat does not provide authenticeted KEMs and does not support
   AuthEncap() or AuthDecap() of [RFC9180].

   Context is a string provided by the protocol referencing this
   document, or if not provided corresponds to the name of the Chempat
   instance, such as "Chempat-X25519-sntrup761".

   Nsecret is 32 for all Chempat instances, and Nenc, Npk, and Nsk
   depends on the underlying components.






Josefsson                 Expires 23 April 2026                 [Page 8]

Internet-Draft                   Chempat                    October 2025


11.  Chempat-X25519-sntrup761

   This algorithm is instantiated using the TKEM as DHKEM(X25519, HKDF-
   SHA256) from [RFC9180] and PQKEM as a HPKE variant of sntrup761 from
   [NTRUPrimePQCS] [NTRUPrime].

   The DHKEM.Nsecret, DHKEM.Nenc, DHKEM.Npk, DHKEM.Nsk are all 32 for
   X25519 per Section 7.1 of [RFC9180].

   The PQKEM.Nsecret is 32, PQKEM.Nenc is 1039, PQKEM.Npk is 1158 and
   PQKEM.Nsk is 1763 for sntrup761 per [NTRUPrimePQCS].

   Thus Nenc is 1071, Npk is 1190 and Nsk is 1795 for Chempat-
   X25519-sntrup761.

12.  Chempat with Classic McEliece with X448 and X25519

   This is a set of mechanisms implemented the same way but with
   different component algorithms and parameter lengths.

   This algorithm is instantiated using the TKEM as DHKEM(X, HKDF-
   SHA512) from [RFC9180] and PQKEM as a HPKE variant of M from
   [MCELIECE] [CM-spec], substituting X and M for the particular
   algorithm from the tables below.  Sizes for DHKEM for X25519 and X448
   as per Section 7.1 of [RFC9180], and sizes for PQKEM as per
   [CM-spec].

   The f and non-f versions are interoperable.  The f versions have
   faster key generation, while the non-f versions have simpler key
   generation.  For example, a key generated with mceliece6688128f can
   decapsulate ciphertexts that were encapsulated with mceliece6688128,
   and vice versa.  The secret-key sizes (and formats) are the same, the
   encapsulation functions are the same, and the decapsulation functions
   are the same.  Implementations of this protocol can chose between f
   and non-f variants, however the name of the hybrid will use the non-f
   names.

              +===============+=========+======+=====+=====+
              | DHKEM variant | Nsecret | Nenc | Npk | Nsk |
              +===============+=========+======+=====+=====+
              | X25519        | 32      | 32   | 32  | 32  |
              +---------------+---------+------+-----+-----+
              | X448          | 64      | 56   | 56  | 56  |
              +---------------+---------+------+-----+-----+

                     Table 1: X25519/X448 DHKEM size





Josefsson                 Expires 23 April 2026                 [Page 9]

Internet-Draft                   Chempat                    October 2025


          +=================+=========+======+=========+=======+
          | PQKEM variant   | Nsecret | Nenc | Npk     | Nsk   |
          +=================+=========+======+=========+=======+
          | mceliece348864  | 32      | 96   | 261120  | 6492  |
          +-----------------+---------+------+---------+-------+
          | mceliece460896  | 32      | 156  | 524160  | 13608 |
          +-----------------+---------+------+---------+-------+
          | mceliece6688128 | 32      | 208  | 1044992 | 13932 |
          +-----------------+---------+------+---------+-------+
          | mceliece6960119 | 32      | 194  | 1047319 | 13948 |
          +-----------------+---------+------+---------+-------+
          | mceliece8192128 | 32      | 208  | 1357824 | 14120 |
          +-----------------+---------+------+---------+-------+

                     Table 2: Classic McEliece sizes

   Names and sizes of the Chempat hybrids are per table below.

        +================================+======+=========+=======+
        | Variant                        | Nenc | Npk     | Nsk   |
        +================================+======+=========+=======+
        | Chempat-X25519-mceliece348864  | 128  | 261152  | 6524  |
        +--------------------------------+------+---------+-------+
        | Chempat-X25519-mceliece460896  | 188  | 524192  | 13640 |
        +--------------------------------+------+---------+-------+
        | Chempat-X25519-mceliece6688128 | 240  | 1045024 | 13964 |
        +--------------------------------+------+---------+-------+
        | Chempat-X25519-mceliece6960119 | 226  | 1047351 | 13980 |
        +--------------------------------+------+---------+-------+
        | Chempat-X25519-mceliece8192128 | 240  | 1357856 | 14152 |
        +--------------------------------+------+---------+-------+
        | Chempat-X448-mceliece348864    | 160  | 261176  | 6548  |
        +--------------------------------+------+---------+-------+
        | Chempat-X448-mceliece460896    | 220  | 524216  | 13664 |
        +--------------------------------+------+---------+-------+
        | Chempat-X448-mceliece6688128   | 272  | 1045048 | 13988 |
        +--------------------------------+------+---------+-------+
        | Chempat-X448-mceliece6960119   | 258  | 1047375 | 14004 |
        +--------------------------------+------+---------+-------+
        | Chempat-X448-mceliece8192128   | 272  | 1357880 | 14176 |
        +--------------------------------+------+---------+-------+

                 Table 3: Classic McEliece with X25519/X448








Josefsson                 Expires 23 April 2026                [Page 10]

Internet-Draft                   Chempat                    October 2025


13.  Chempat with (e)FrodoKEM and X25519/Brainpool

   This algorithm is instantiated using the TKEM as DHKEM(X, HKDF-
   SHA512) from [RFC9180] and PQKEM as a HPKE variant of M from
   [FRODOKEM], substituting X and M for the particular algorithm from
   the tables below.  Sizes for DHKEM for X25519 as per Section 7.1 of
   [RFC9180], sizes for Brainpool curves as per [RFC5639], and sizes for
   PQKEM as per [FRODOKEM].

              +===============+=========+======+=====+=====+
              | DHKEM variant | Nsecret | Nenc | Npk | Nsk |
              +===============+=========+======+=====+=====+
              | X25519        | 32      | 32   | 32  | 32  |
              +---------------+---------+------+-----+-----+
              | brainpoolP256 | 32      | 65   | 65  | 32  |
              +---------------+---------+------+-----+-----+
              | brainpoolP384 | 48      | 97   | 97  | 48  |
              +---------------+---------+------+-----+-----+
              | brainpoolP512 | 64      | 129  | 129 | 64  |
              +---------------+---------+------+-----+-----+

                        Table 4: X25519 DHKEM size

           +================+=========+=======+=======+=======+
           | PQKEM variant  | Nsecret | Nenc  | Npk   | Nsk   |
           +================+=========+=======+=======+=======+
           | FrodoKEM-640   | 16      | 9752  | 9616  | 19888 |
           +----------------+---------+-------+-------+-------+
           | eFrodoKEM-640  | 16      | 9720  | 9616  | 19888 |
           +----------------+---------+-------+-------+-------+
           | FrodoKEM-976   | 24      | 15792 | 15632 | 31296 |
           +----------------+---------+-------+-------+-------+
           | eFrodoKEM-976  | 24      | 15744 | 15632 | 31296 |
           +----------------+---------+-------+-------+-------+
           | FrodoKEM-134   | 32      | 21696 | 21520 | 43088 |
           +----------------+---------+-------+-------+-------+
           | eFrodoKEM-1344 | 32      | 21632 | 21520 | 43088 |
           +----------------+---------+-------+-------+-------+

                         Table 5: FrodoKEM sizes

   Names and sizes of the Chempat hybrids are per table below.









Josefsson                 Expires 23 April 2026                [Page 11]

Internet-Draft                   Chempat                    October 2025


    +====================================+=========+=========+========+
    |Variant                             |Nenc     |Npk      |Nsk     |
    +====================================+=========+=========+========+
    |Chempat-X25519-FrodoKEM-976         |15792+32 |15632+32 |31296+32|
    +------------------------------------+---------+---------+--------+
    |Chempat-X25519-eFrodoKEM-976        |15744+32 |15632+32 |31296+32|
    +------------------------------------+---------+---------+--------+
    |Chempat-brainpoolP256-FrodoKEM-640  |9752+65  |9616+65  |19920+32|
    +------------------------------------+---------+---------+--------+
    |Chempat-brainpoolP256-eFrodoKEM-640 |9720+65  |9616+65  |19920+32|
    +------------------------------------+---------+---------+--------+
    |Chempat-brainpoolP384-FrodoKEM-976  |15792+97 |15632+97 |31328+48|
    +------------------------------------+---------+---------+--------+
    |Chempat-brainpoolP384-eFrodoKEM-976 |15744+97 |15632+97 |31328+48|
    +------------------------------------+---------+---------+--------+
    |Chempat-brainpoolP512-FrodoKEM-1344 |21696+129|21520+129|43088+64|
    +------------------------------------+---------+---------+--------+
    |Chempat-brainpoolP512-eFrodoKEM-1344|21632+129|21520+129|43088+64|
    +------------------------------------+---------+---------+--------+

                       Table 6: FrodoKEM with X25519

14.  Chempat-X25519-ML-KEM-768

   This algorithm is instantiated using the TKEM as DHKEM(X25519, HKDF-
   SHA256) from [RFC9180] and PQKEM as a HPKE variant of ML-KEM-768 from
   [MLKEM].

   Protocols and implementation MAY consider [XWING] instead of Chempat-
   X25519-ML-KEM-768, and the definition of Chempat-X25519-ML-KEM-768 is
   here for situations when some property of X-Wing is not wanted.
   Informally and non-conclusively, X-Wing offers better performance and
   Chempat-X25519-ML-KEM-768 offers re-use of the generic security
   claims on Chempat and a per-protocol key-separation context string.

   The DHKEM.Nsecret, DHKEM.Nenc, DHKEM.Npk, DHKEM.Nsk are all 32 for
   X25519 per Section 7.1 of [RFC9180].

   The PQKEM.Nsecret is 32, PQKEM.Nenc is 1088, PQKEM.Npk is 1184 and
   PQKEM.Nsk is 2400 for ML-KEM-768 per [MLKEM].

   Thus Nenc is 1120, Npk is 1216 and Nsk is 2432 for Chempat-X25519-ML-
   KEM-768.








Josefsson                 Expires 23 April 2026                [Page 12]

Internet-Draft                   Chempat                    October 2025


15.  Chempat-X448-ML-KEM-1024

   This algorithm is instantiated using the TKEM as DHKEM(X448, HKDF-
   SHA512) from [RFC9180] and PQKEM as a HPKE variant of ML-KEM-1024
   from [MLKEM].

   For X448 DHKEM.Nsecret is 64, DHKEM.Nenc is 56, DHKEM.Npk is 56,
   DHKEM.Nsk is 56 per Section 7.1 of [RFC9180].

   The PQKEM.Nsecret is 32, PQKEM.Nenc is 864, PQKEM.Npk is 1568 and
   PQKEM.Nsk is 2400 for ML-KEM-1024 per [MLKEM].

   Thus Nenc is 1120, Npk is 1624 and Nsk is 2456 for Chempat-X25519-ML-
   KEM-1024.

16.  Chempat-P256-ML-KEM-768

   This algorithm is instantiated using the TKEM as DHKEM(P-256, HKDF-
   SHA256) from [RFC9180] and PQKEM as a HPKE variant of ML-KEM-768 from
   [MLKEM].

   For P256 DHKEM.Nsecret is 32, DHKEM.Nenc is 65, DHKEM.Npk is 65,
   DHKEM.Nsk is 32 per Section 7.1 of [RFC9180].

   The PQKEM.Nsecret is 32, PQKEM.Nenc is 1088, PQKEM.Npk is 1184 and
   PQKEM.Nsk is 2400 for ML-KEM-768 per [MLKEM].

   Thus Nenc is 1153, Npk is 1249 and Nsk is 2432 for Chempat-P256-ML-
   KEM-768.

17.  Chempat-P384-ML-KEM-1024

   This algorithm is instantiated using the TKEM as DHKEM(P-384, HKDF-
   SHA384) from [RFC9180] and PQKEM as a HPKE variant of ML-KEM-1024
   from [MLKEM].

   For P384 DHKEM.Nsecret is 48, DHKEM.Nenc is 97, DHKEM.Npk is 97,
   DHKEM.Nsk is 48 per Section 7.1 of [RFC9180].

   The PQKEM.Nsecret is 32, PQKEM.Nenc is 864, PQKEM.Npk is 1568 and
   PQKEM.Nsk is 2400 for ML-KEM-1024 per [MLKEM].

   Thus Nenc is 961, Npk is 1665 and Nsk is 2448 for Chempat-P384-ML-
   KEM-1024.







Josefsson                 Expires 23 April 2026                [Page 13]

Internet-Draft                   Chempat                    October 2025


18.  Chempat-brainpoolP256-ML-KEM-768

   This algorithm is instantiated using the TKEM as DHKEM(brainpoolP256,
   HKDF-SHA256) from [RFC9180] [RFC5639] and PQKEM as a HPKE variant of
   ML-KEM-768 from [MLKEM].

   For brainpoolP256 DHKEM.Nsecret is 32, DHKEM.Nenc is 65, DHKEM.Npk is
   65, DHKEM.Nsk is 32.

   The PQKEM.Nsecret is 32, PQKEM.Nenc is 1088, PQKEM.Npk is 1184 and
   PQKEM.Nsk is 2400 for ML-KEM-768 per [MLKEM].

   Thus Nenc is 1153, Npk is 1249 and Nsk is 2432 for Chempat-
   brainpoolP256-ML-KEM-768.

19.  Chempat-brainpoolP384-ML-KEM-1024

   This algorithm is instantiated using the TKEM as DHKEM(brainpoolP384,
   HKDF-SHA384) from [RFC9180] [RFC5639] and PQKEM as a HPKE variant of
   ML-KEM-1024 from [MLKEM].

   For brainpoolP384 DHKEM.Nsecret is 48, DHKEM.Nenc is 97, DHKEM.Npk is
   97, DHKEM.Nsk is 48.  The PQKEM.Nsecret is 32, PQKEM.Nenc is 864,
   PQKEM.Npk is 1568 and PQKEM.Nsk is 2400 for ML-KEM-1024 per [MLKEM].

   Thus Nenc is 961, Npk is 1665 and Nsk is 2448 for Chempat-
   brainpoolP384-ML-KEM-1024.

20.  Security Considerations

   Chempat is intended to be secure if SHA3-256 is secure and either the
   traditional algorithm is secure or the post-quantum algorithm is
   secure.

   The security considerations of each component algorithm are
   inherited.

   Cryptographic algorithms and parameters will be broken or weakened
   over time.  Blindly implementing supported groups listed here is not
   advised.  Implementers and users need to check that the cryptographic
   algorithms listed continue to provide the expected level of security.

21.  IANA Considerations

   Protocols that provide a Context variable will need to register their
   own key-domain separate identifiers.  The registrations below are
   when Chempat instances are used with their default value of Context.




Josefsson                 Expires 23 April 2026                [Page 14]

Internet-Draft                   Chempat                    October 2025


   This document requests/registers new entries to the "HPKE KEM
   Identifiers" registry as follows.

   +=====+======================+=======+=====+=======+=====+====+=========+
   |Value|KEM                   |Nsecret|Nenc |Npk    |Nsk  |Auth|Reference|
   +=====+======================+=======+=====+=======+=====+====+=========+
   |  TBD|Chempat-              |32     |1071 |1190   |1795 |No  |THISRFC  |
   |     |X25519-sntrup761      |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-              |32     |128  |261152 |6524 |No  |THISRFC  |
   |     |X25519-mceliece348864 |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-              |32     |188  |524192 |13640|No  |THISRFC  |
   |     |X25519-mceliece460896 |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-              |32     |240  |1045024|13964|No  |THISRFC  |
   |     |X25519-mceliece6688128|       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-              |32     |226  |1047351|13980|No  |THISRFC  |
   |     |X25519-mceliece6960119|       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-              |32     |240  |1357856|14152|No  |THISRFC  |
   |     |X25519-mceliece8192128|       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-              |32     |160  |261176 |6548 |No  |THISRFC  |
   |     |X448-mceliece348864   |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-              |32     |220  |524216 |13664|No  |THISRFC  |
   |     |X448-mceliece460896   |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-              |32     |272  |1045048|13988|No  |THISRFC  |
   |     |X448-mceliece6688128  |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-              |32     |258  |1047375|14004|No  |THISRFC  |
   |     |X448-mceliece6960119  |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-              |32     |272  |1357880|14176|No  |THISRFC  |
   |     |X448-mceliece8192128  |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-X25519-ML-    |32     |1120 |1216   |2432 |No  |THISRFC  |
   |     |KEM-768               |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-X448-ML-      |32     |1120 |1624   |2456 |No  |THISRFC  |
   |     |KEM-1024              |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-P256-ML-      |32     |1153 |1249   |2432 |No  |THISRFC  |
   |     |KEM-768               |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+



Josefsson                 Expires 23 April 2026                [Page 15]

Internet-Draft                   Chempat                    October 2025


   |  TBD|Chempat-P384-ML-      |32     |961  |1665   |2448 |No  |THISRFC  |
   |     |KEM-1024              |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-brainpoolP256-|32     |1153 |1249   |2432 |No  |THISRFC  |
   |     |ML-KEM-768            |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-brainpoolP384-|32     |961  |1665   |2448 |No  |THISRFC  |
   |     |ML-KEM-1024           |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-              |32     |15824|15664  |31328|No  |THISRFC  |
   |     |X25519-FrodoKEM-976   |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-              |32     |15776|15665  |31328|No  |THISRFC  |
   |     |X25519-eFrodoKEM-976  |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-brainpoolP256-|32     |9817 |9681   |19952|No  |THISRFC  |
   |     |FrodoKEM-640          |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-brainpoolP256-|32     |9785 |9681   |19952|No  |THISRFC  |
   |     |FrodoKEM-640          |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-brainpoolP384-|32     |15889|15729  |31376|No  |THISRFC  |
   |     |FrodoKEM-976          |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-brainpoolP384-|32     |15841|15729  |31376|No  |THISRFC  |
   |     |FrodoKEM-976          |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-brainpoolP512-|32     |21825|21649  |43152|No  |THISRFC  |
   |     |FrodoKEM-1344         |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+
   |  TBD|Chempat-brainpoolP512-|32     |21761|21649  |43152|No  |THISRFC  |
   |     |FrodoKEM-1344         |       |     |       |     |    |         |
   +-----+----------------------+-------+-----+-------+-----+----+---------+

                   Table 7: Chempat HPKE KEM Identifiers

   This document requests/registers a new entry to the TLS Supported
   Group registry as follows.













Josefsson                 Expires 23 April 2026                [Page 16]

Internet-Draft                   Chempat                    October 2025


   +=====+==================+=====+=============+=========+===========+
   |Value| Description      |DTLS-| Recommended |Reference|Comment    |
   |     |                  |OK   |             |         |           |
   +=====+==================+=====+=============+=========+===========+
   |  TBD| Chempat-         |Y    | Y           |THISRFC  |PQ/T hybrid|
   |     | X25519-sntrup761 |     |             |         |of X25519  |
   |     |                  |     |             |         |and        |
   |     |                  |     |             |         |sntrup761  |
   +-----+------------------+-----+-------------+---------+-----------+
   |  TBD| Chempat-X25519-  |Y    | Y           |THISRFC  |PQ/T hybrid|
   |     | eFrodoKEM-976    |     |             |         |of X25519  |
   |     |                  |     |             |         |and eFrodoK|
   |     |                  |     |             |         |EM-976     |
   +-----+------------------+-----+-------------+---------+-----------+

                  Table 8: Chempat TLS Supported Groups

22.  Acknowledgments

   The combiner function was suggested by Daniel J. Bernstein.  The
   document re-use ideas and some text from [XWING], [KEMCOMBINER],
   [XYBERHPKE] and [RFC9180].

23.  References

23.1.  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/info/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/info/rfc8174>.

23.2.  Informative References

   [CDM23]    Cremers, C., Dax, A., and N. Medinger, "Keeping Up with
              the KEMs: Stronger Security Notions for KEMs and automated
              analysis of KEM-based protocols", 2023,
              <https://eprint.iacr.org/2023/1933>.

   [CM-spec]  Classic McEliece Team, "Classic McEliece: conservative
              code-based cryptography: cryptosystem specification",
              October 2022,
              <https://classic.mceliece.org/mceliece-spec-20221023.pdf>.




Josefsson                 Expires 23 April 2026                [Page 17]

Internet-Draft                   Chempat                    October 2025


   [FRODOKEM] Longa, P., Bos, J. W., Ehlen, S., and D. Stebila,
              "FrodoKEM: key encapsulation from learning with errors",
              Work in Progress, Internet-Draft, draft-longa-cfrg-
              frodokem-01, 16 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-longa-cfrg-
              frodokem-01>.

   [GHP18]    Giacon, F., Heuer, F., and B. Poettering, "KEM Combiners",
              2018, <https://doi.org/10.1007/978-3-319-76578-5_7>.

   [KEMCOMBINER]
              Ounsworth, M., Wussler, A., and S. Kousidis, "Combiner
              function for hybrid key encapsulation mechanisms (Hybrid
              KEMs)", Work in Progress, Internet-Draft, draft-ounsworth-
              cfrg-kem-combiners-05, 31 January 2024,
              <https://datatracker.ietf.org/doc/html/draft-ounsworth-
              cfrg-kem-combiners-05>.

   [MCELIECE] Josefsson, S., "Classic McEliece", Work in Progress,
              Internet-Draft, draft-josefsson-mceliece-03, 7 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-josefsson-
              mceliece-03>.

   [MLKEM]    National Institute of Standards and Technology, ., "FIPS
              203 (Initial Draft): Module-Lattice-Based Key-
              Encapsulation Mechanism Standard", n.d.,
              <https://csrc.nist.gov/pubs/fips/203/ipd>.

   [NIST.FIPS.202]
              Dworkin, M., Dworkin, M. J., and NIST, "SHA-3 Standard:
              Permutation-Based Hash and Extendable-Output Functions",
              FIPS PUB 202, NIST Federal Information Processing
              Standards Publications 202, DOI 10.6028/nist.fips.202,
              DOI 10.6028/NIST.FIPS.202, August 2015,
              <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf>.

   [NTRUPrime]
              Bernstein, D.J., Chuengsatiansup, C., Lange, T., and C.
              van Vredendaal, "NTRU Prime: reducing attack surface at
              low cost", August 2017,
              <https://ntruprime.cr.yp.to/ntruprime-20170816.pdf>.

   [NTRUPrimePQCS]
              Bernstein, Daniel J., Billy Bob Brumley, ., Ming-Shing
              Chen, ., Chitchanok Chuengsatiansup, ., Tanja Lange, .,
              Adrian Marotzke, ., Bo-Yuan Peng, ., Nicola Tuveri, .,
              Christine van Vredendaal, ., and . Bo-Yin Yang, "NTRU
              Prime: round 3, Submission to the NIST PQC Standardization



Josefsson                 Expires 23 April 2026                [Page 18]

Internet-Draft                   Chempat                    October 2025


              Round 3 Process", October 2020,
              <https://csrc.nist.gov/CSRC/media/Projects/post-quantum-
              cryptography/documents/round-3/submissions/NTRU-Prime-
              Round3.zip>.

   [RFC4251]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
              January 2006, <https://www.rfc-editor.org/info/rfc4251>.

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880,
              DOI 10.17487/RFC4880, November 2007,
              <https://www.rfc-editor.org/info/rfc4880>.

   [RFC5639]  Lochter, M. and J. Merkle, "Elliptic Curve Cryptography
              (ECC) Brainpool Standard Curves and Curve Generation",
              RFC 5639, DOI 10.17487/RFC5639, March 2010,
              <https://www.rfc-editor.org/info/rfc5639>.

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/info/rfc7748>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9180]  Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
              Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
              February 2022, <https://www.rfc-editor.org/info/rfc9180>.

   [RFC9794]  Driscoll, F., Parsons, M., and B. Hale, "Terminology for
              Post-Quantum Traditional Hybrid Schemes", RFC 9794,
              DOI 10.17487/RFC9794, June 2025,
              <https://www.rfc-editor.org/info/rfc9794>.

   [XWING]    Connolly, D., Schwabe, P., and B. Westerbaan, "X-Wing:
              general-purpose hybrid post-quantum KEM", Work in
              Progress, Internet-Draft, draft-connolly-cfrg-xwing-kem-
              09, 1 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-connolly-
              cfrg-xwing-kem-09>.









Josefsson                 Expires 23 April 2026                [Page 19]

Internet-Draft                   Chempat                    October 2025


   [XYBERHPKE]
              Westerbaan, B. and C. A. Wood, "X25519Kyber768Draft00
              hybrid post-quantum KEM for HPKE", Work in Progress,
              Internet-Draft, draft-westerbaan-cfrg-hpke-xyber768d00-03,
              14 May 2024, <https://datatracker.ietf.org/doc/html/draft-
              westerbaan-cfrg-hpke-xyber768d00-03>.

   [XYBERTLS] Westerbaan, B. and D. Stebila, "X25519Kyber768Draft00
              hybrid post-quantum key agreement", Work in Progress,
              Internet-Draft, draft-tls-westerbaan-xyber768d00-03, 24
              September 2023, <https://datatracker.ietf.org/doc/html/
              draft-tls-westerbaan-xyber768d00-03>.

Author's Address

   Simon Josefsson
   Email: simon@josefsson.org


































Josefsson                 Expires 23 April 2026                [Page 20]


name: draft-pocero-authkem-edhoc
rev: 01
title: KEM-based Authentication for EDHOC
time: 2025-10-25T06:54:24Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-28T06:54:24Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:09.014915+00:00
abstract:
This document specifies extensions to the Ephemeral Diffie-Hellman
   over COSE (EDHOC) protocol to provide resistance against quantum
   computer adversaries by incorporating Post-Quantum Cryptography (PQC)
   mechanisms for both key exchange and authentication.  It defines a
   Key Encapsulation Mechanism (KEM)-based authentication method to
   enable signature-free post-quantum authentication when PQC KEMs, such
   as NIST-standardized ML-KEM, are used.  The document further
   describes scenarios where both parties employ KEM-based
   authentication, as well as cases where authentication methods are
   combined, with one party using KEM-based authentication and the other
   relying on a PQC signature scheme.

full_text:
individual                                              L. Pocero Fraile
Internet-Draft                                               C. Koulamas
Intended status: Standards Track                          A.P. Fournaris
Expires: 27 April 2026                                     E. Haleplidis
                                                        ISI, R.C. ATHENA
                                                         24 October 2025


                   KEM-based Authentication for EDHOC
                     draft-pocero-authkem-edhoc-01

Abstract

   This document specifies extensions to the Ephemeral Diffie-Hellman
   over COSE (EDHOC) protocol to provide resistance against quantum
   computer adversaries by incorporating Post-Quantum Cryptography (PQC)
   mechanisms for both key exchange and authentication.  It defines a
   Key Encapsulation Mechanism (KEM)-based authentication method to
   enable signature-free post-quantum authentication when PQC KEMs, such
   as NIST-standardized ML-KEM, are used.  The document further
   describes scenarios where both parties employ KEM-based
   authentication, as well as cases where authentication methods are
   combined, with one party using KEM-based authentication and the other
   relying on a PQC signature scheme.

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 27 April 2026.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Pocero Fraile, et al.     Expires 27 April 2026                 [Page 1]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   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
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology and Requirements Language . . . . . . . . . .   5
       1.2.1.  Key Encapsulation Mechanisms (KEMs) . . . . . . . . .   6
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Protocol Elements . . . . . . . . . . . . . . . . . . . .   9
       2.1.1.  Ephemeral KEM . . . . . . . . . . . . . . . . . . . .  10
       2.1.2.  Method  . . . . . . . . . . . . . . . . . . . . . . .  10
       2.1.3.  Authentication Parameters . . . . . . . . . . . . . .  11
         2.1.3.1.  Authentication Keys . . . . . . . . . . . . . . .  11
         2.1.3.2.  Authentication Credentials  . . . . . . . . . . .  12
         2.1.3.3.  Identification of Credentials . . . . . . . . . .  12
       2.1.4.  Cipher Suites . . . . . . . . . . . . . . . . . . . .  13
   3.  Key Derivation  . . . . . . . . . . . . . . . . . . . . . . .  13
     3.1.  Keys for EDHOC Message Processing . . . . . . . . . . . .  15
       3.1.1.  EDHOC_Extract . . . . . . . . . . . . . . . . . . . .  15
         3.1.1.1.  PRK_2e  . . . . . . . . . . . . . . . . . . . . .  15
         3.1.1.2.  PRK_3e2m  . . . . . . . . . . . . . . . . . . . .  15
         3.1.1.3.  PRK_4e3m  . . . . . . . . . . . . . . . . . . . .  16
       3.1.2.  EDHOC_Expand and EDHOC_KDF  . . . . . . . . . . . . .  17
       3.1.3.  PRK_out . . . . . . . . . . . . . . . . . . . . . . .  18
     3.2.  Keys for EDHOC Applications . . . . . . . . . . . . . . .  18
   4.  Message Formatting and Processing . . . . . . . . . . . . . .  18
     4.1.  KEM-based Authentication EDHOC Message 1  . . . . . . . .  18
       4.1.1.  Formating of Message 1  . . . . . . . . . . . . . . .  18
       4.1.2.  Initiator Composition of Message 1  . . . . . . . . .  18
       4.1.3.  Responder Processing of Message 1 . . . . . . . . . .  19
     4.2.  KEM-based authentication EDHOC Message 2  . . . . . . . .  19
       4.2.1.  Formating of Message 2  . . . . . . . . . . . . . . .  19
       4.2.2.  Responder Composition of Message 2  . . . . . . . . .  19
       4.2.3.  Initiator Processing of Message 2 . . . . . . . . . .  20
     4.3.  KEM-based authentication EDHOC Message 3  . . . . . . . .  21
       4.3.1.  Formating of Message 3  . . . . . . . . . . . . . . .  22
       4.3.2.  Initiator Composition of Message 3  . . . . . . . . .  22
       4.3.3.  Responder Processing of Message 3 . . . . . . . . . .  23
     4.4.  KEM-based authentication EDHOC Message 4  . . . . . . . .  24
       4.4.1.  Formating of Message 4  . . . . . . . . . . . . . . .  24



Pocero Fraile, et al.     Expires 27 April 2026                 [Page 2]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


       4.4.2.  Responder Composition of Message 4  . . . . . . . . .  24
       4.4.3.  Initaitor Processing of Message 4 . . . . . . . . . .  26
     4.5.  KEM-based authentication EDHOC Message 5  . . . . . . . .  27
       4.5.1.  Formating of Message 5  . . . . . . . . . . . . . . .  27
       4.5.2.  Initiator Composition of Message 5  . . . . . . . . .  27
       4.5.3.  Responder Processing of Message 5 . . . . . . . . . .  29
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29
     5.1.  COSE Algorithms Registry  . . . . . . . . . . . . . . . .  29
     5.2.  EDHOC Cipher Suites Registry  . . . . . . . . . . . . . .  30
     5.3.  EDHOC Method Types Registry . . . . . . . . . . . . . . .  31
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  32
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  35
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  36
   Appendix A.  Early Authentication Approach for Combined PQC KEM and
           Signature Authentication Methods  . . . . . . . . . . . .  37
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40

1.  Introduction

   The purpose of this document is to address the quantum-resistant
   transition of the Ephemeral Diffie-Hellman over COSE (EDHOC) protocol
   by extending with a new Key Encapsulation Mechanism (KEM)-based
   authentication method and Post-Quantum Cryptography cipher suits.

   The specific protocol is part of a more extensive analysis of the PQ
   transition for the EDHOC protocol, which is currently in the process
   of being published.

1.1.  Motivation

   The emerging Quantum Computing technologies bring new potential risks
   to the existing cryptographic infrastructures.  Security mechanisms
   that rely on integer factorization or the discrete logarithm problem
   will be vulnerable to attacks by a Cryptographically Relevant Quantum
   Computer (CRQC).  The European Commission recently issued a roadmap
   for the transition to Post-Quantum Cryptography (PQC), establishing a
   2030 deadline for high-risk use cases and 2035 for medium-risk use
   cases, in alignment with the 2035 deadline set by the U.S. government
   for completing the transition to PQC in federal systems.

   The U.S.  National Institute of Standards and Technology (NIST) has
   concluded its PQC standardization process with the release of its
   first standardized PQC algorithms in three new Federal Information
   Processing Standards (FIPS): FIPS 203 (ML-KEM, based on CRYSTALS-
   Kyber), FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium), and FIPS 205
   (SLH-DSA, based on SPHINCS+).  Additionally, FALCON has been selected
   for future standardization, and NIST has launched a new initiative to



Pocero Fraile, et al.     Expires 27 April 2026                 [Page 3]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   evaluate alternative PQC signature schemes with compact signatures
   and efficient verification speeds.  Complementing these efforts, the
   Post-Quantum Use in Protocols (PQUIC) IETF Working Group (WG) is
   developing operational and design guidelines to support the
   transition.  For example, [RFC9794] defines terminology for post-
   quantum/traditional Hybrid schemes, while ongoings draft such as
   [I-D.ietf-pquip-pqc-engineers] analyze the impact of CRQCs on
   existing systems and the challenges involved in transitioning to
   post-quantum algorithms.

   The growing urgency to transition to PQC highlights the need to adapt
   EDHOC, whose current security relies on traditional Elliptic-Curve
   Cryptography(ECC), based on the discrete logarithm problem that is
   known to be vulnerable to attacks by CRQCs.  The integration of the
   PQC mechanism into EDHOC raises important considerations around
   performance, as the protocol is explicitly designed for constrained
   environments where the number of handshake message rounds, network
   overhead, processing time, and power consumption are critical
   factors.

   PQC algorithms generally have higher computational and memory costs
   compared to the classical cryptography algorithms they aim to replace
   because they often involve complex calculations and require larger
   byte sizes.  Notably, the PQC digital signature schemes standardized
   by NIST, such as ML-DSA and SLH-DSA, use significantly large public
   keys and signatures, which can be difficult to transmit over
   constrained networks.  It is important to note that while FALCON,
   also selected for standardization by NIST, provides much shorter
   signatures than the lattice-based schemes, its current
   implementations have been shown to be vulnerable to side-channel
   attacks.  The new compact schemes under NIST evaluation should be
   more suitable for constrained environments.  However, the current
   Cortex-M4 implementations of some of the most compact PQC signature
   schemes, like SNOVA and MAYO, still demand substantial memory
   resources, making them impractical for many constrained devices.
   Additionally, others, such as SQISign, have only recently been
   supported on such platforms, and performance benchmarks for their
   signature operations are still unavailable.

   On the other hand, the standardized ML-KEM offers significantly
   higher computational efficiency compared to all other PQC KEMs (order
   of magnitude faster) and is at least three times more efficient than
   the fastest PQC signature schemes.  Therefore, extending EDHOC with a
   new authentication method that enables a signature-free KEM-based
   EDHOC has the potential to reduce memory and processing requirements
   when ML-KEM is used.  The approach can also result in lower network
   overhead compared to signature-based EDHOC implementations that rely
   on standardized PQC signature-based algorithms.



Pocero Fraile, et al.     Expires 27 April 2026                 [Page 4]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   Some standardization efforts propose adopting the KEM-based
   authentication mechanism to mitigate the overhead introduced by PQC
   digital signatures.  For example, [I-D.celi-wiggers-tls-authkem]
   specifies a KEM-based authentication scheme for TLS 1.3, while
   [I-D.uri-lake-pquake] aims to define a general Post-Quantum
   Authentication Key exchange protocoll, which based on the same
   approach.

   This document describes a KEM-based authentication mechanism
   specifically for the EDHOC protocol, introducing a new authentication
   method intended to provide a PQC signature-free variant as the static
   DH authentication method intends.  The static-DH authentication of
   EDHOC is based on the XX pattern of the Noise framework protocol
   [Noise], where channel security guarantees are increasingly
   established by encrypting transmitted messages with keys derived from
   chains of shared secrets, as soon as those secrets become available.
   To align with this model, the KEM-based authentication Method defined
   in this document follows the approach outlined in [PQNoise-CCS22],
   which provides a recipe for transforming classical Noise patterns
   into PQ variants.  This specification defines the necessary
   modifications to the EDHOC protocol to support the PQ-Noise framework
   while preserving security properties comparable to those of the
   static-DH authentication method.

   In addition to the scheme in which both parties use KEM-based
   authentication, providing a PQC signature-free alternative to static-
   DH authentication, this document further extends EDHOC with two
   additional methods that provide combined authentication variants,
   combining KEM-based authentication with PQC signature-based
   authentication.  Together, these methods enable flexible post-quantum
   authentication options while maintaining the security properties of
   the original EDHOC design.

   This specification defines the simplest approach for extending
   combined authentication variants, in which the five-message handshake
   is maintained and authentication is performed in the last two
   messages, as in the both-parties KEM-based authentication method.  A
   more complex approach, which prioritizes authentication as early as
   possible, is presented in the Appendix A to provide a discussion of
   alternative strategies and their relative advantages.

1.2.  Terminology and Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].





Pocero Fraile, et al.     Expires 27 April 2026                 [Page 5]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   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] and COSE
   Algorithms [RFC9053], When referring to CBOR, this specification
   always refers to Deterministically Encoded CBOR, as specified in
   Section 4.2.1 and 4.2.2 of [RFC8949].  The single output from
   authenticated encryption (including the authentication tag) is called
   "ciphertext", following [RFC5116].

1.2.1.  Key Encapsulation Mechanisms (KEMs)

   The Key Encapsulation Mechanism consists of 3 algorithms:

   *  *( pk, sk ) <- KEM.KeyGen( )*: The probabilistic key generation
      algorithm generates a KEM key pair consisting of a public
      encapsulation key ( pk ) and secret decapsulation key ( sk ).

   *  *( ss , ct ) <- KEM.Encapsulate( pk )*: The probabilistic
      encapsulation algorithm takes as input a public encapsulation key
      ( pk ) and produces a shared secret ( ss ) and ciphertext ( ct ).

   *  *( ss ) <- KEM.Decapsulate( ct, sk )*: The decapsulation algorithm
      takes as input a secret encacpsulation key ( sk ) and produce a
      shared secret ( ss ).

2.  Protocol Overview

   This document defines a KEM-based authentication method for EDHOC in
   a general scenario where both parties may be mutually unknown.  It
   aims to provide a free-signature authentication scheme as the static
   DH authentication EDHOC method 3 does, which relies on the XX pattern
   from the Noise framework [Noise], supporting mutual authentication
   and the transmission of encrypted public credentials.  The proposed
   protocol adopts the approach provided by [PQNoise-CCS22] to transform
   the classical Noise XX pattern in EDHOC into a PQ Noise XX variant.
   This results in a quantum-resistant, KEM-only version of EDHOC when a
   PQC KEM is used.

   The PQ translation of the Noise XX pattern requires introducing up to
   one additional round trip.  With KEMs, the owner of the static key
   cannot combine their static private key with the ephemeral public key
   belonging to the other party to immediately prove their identity in
   the next message, as is possible with DH.  Instead, the party must
   first receive a ciphertext that encapsulates its static public key,
   generated by the peer, before it can authenticate itself.  This
   necessitates an additional key-confirmation message from the key
   owner, using the key derived from the encapsulated value.




Pocero Fraile, et al.     Expires 27 April 2026                 [Page 6]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   The KEM-based authentication in EDHOC is extended by defining three
   new authentication methods: method 4, in which both parties use KEM-
   based authentication; method 5, in which the Initiator employs KEM-
   based authentication and the Responder uses a PQC signature scheme;
   and method 6, in which the Initiator uses a PQC signature scheme and
   the Responder employs KEM-based authentication.  To extend KEM-based
   authentication to support all this combinations of Initiator and
   Responder authentication, a message-flow-preserving approach is
   applied and specify in this document.  This approach provides a
   unified message flow, maintaining the same number of messages for all
   KEM-based authentication method keeping a uniform message structure
   across them.  A second aproach, which prioritizes authenticating a
   party as soon as it become possible is describe in Appendix A
   highlighting its advantage and disadvantages compared with the
   approach presented here.

   All three new methods extending KEM-based authentication in EDHOC
   consist of five mandatory messages (message_1, message_2, message_3,
   message_4, and message_5).  Figure 1 illustrates the EDHOC message
   flow for these three methods, as well as the content of each message.
   An error message may also be exchanged between the Initiator (I) and
   the Responder (R).  Error handling and cipher suit negotiation
   mechanisms are the same as defined in Section 6 of [RFC9528].  All
   EDHOC messages are CBOR Sequences as specified in [RFC9528].  The
   protocol elements are introduced in this Section and in Section 4.
   Message formatting and processing are specified in Section 4.

   Initiator                                                   Responder
   |               METHOD, SUITES_I, pk_eph, C_I, EAD_1                |
   +------------------------------------------------------------------->
   |                             message_1                             |
   |                                                                   |
   |               ct_eph, Enc( C_R, ID_CRED_R, EAD_2 )                |
   <-------------------------------------------------------------------+
   |                             message_2                             |
   |                                                                   |
   |                  AEAD( ID_CRED_I, EAD_3 ), ct_R?                  |
   +------------------------------------------------------------------->
   |                             message_3                             |
   |                                                                   |
   |                AEAD( EAD_4, Sig_R_or_MAC_2 ), ct_I?               |
   <-------------------------------------------------------------------+
   |                             message_4                             |
   |                                                                   |
   |                     AEAD( EAD_5, Sig_I_or_MAC_3 )                 |
   +------------------------------------------------------------------->
   |                             message_5                             |




Pocero Fraile, et al.     Expires 27 April 2026                 [Page 7]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


                        Figure 1: EDHOC Message Flow

   The parties exchange ephemeral keys from a PQC KEM and static public
   keys, either from the same PQC KEM as the ephemeral keys or from a
   PQC digital signature scheme, depending on the selected method, along
   with ciphertexts encapsulating these keys.  They then compute shared
   secrets and pseudorandom keys (PRK), from which symmetric session
   keys are derived to encrypt elements in the intermediate handshake
   messages.  All handshake messages include encrypted components
   protected with these derived session keys, offering varying levels of
   confidentiality and authenticity, except for the first message, which
   is sent in plaintext.

   The parties compute a shared secret session key, PRK_out, from which
   symmetric application keys are derived to protect application data.
   The Initiator derives these keys after receiving message_4, and the
   Responder after receiving message_5.

   *  pk_eph is the ephemeral KEM public key generated by the Initiator.

   *  ct_eph is the ephemeral ciphertext computed by the Responder with
      the KEM.encapsulation algorithm over the received ephemeral public
      key (pk_eph).

   *  ct_R is the responder ciphertext computed by the Initiator with
      the KEM.encapsulation algorithm over the static KEM public key of
      the Responder, retrieved from the received ID_CRED_R in message_2.
      This value is used in authentication Methods 4 and 6, where the
      Responder employs KEM-based authentication.

   *  ct_I is the Iniatiator ciphertext computed by the Responder with
      the KEM.encapsulation algorithm over the static KEM public key of
      the Initiator, retrieved from the received ID_CRED_I in message_1.
      This value is used in authentication Methods 4 and 5, where the
      Initiator employs KEM-based authentication.

   *  "CRED_I and CRED_R are the authentication credentials containing
      the public authentication keys of I and R, respectively", as
      defined in Section 2 of [RFC9528].

   *  "ID_CRED_I and ID_CRED_R are used to identify and optionally
      transport the credentials of I and R, respectively", as defined in
      Section 2 of [RFC9528].








Pocero Fraile, et al.     Expires 27 April 2026                 [Page 8]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  Sig_I and Sig_R denote signatures made with the private
      authentication key from a PQC digital signature algorithm selected
      of I and R, respectively.  Sig_I is used when the Initiator
      employs PQC signature-based authentication in the method 6, and
      Sig_R is used when the Responder employs PQC signature-based
      authentication in the method 5.

   *  "Enc(), AEAD(), and MAC() denote encryption, Authenticated
      Encryption with Associated Data, and Message Authentication Code,
      crypto algorithms applied with keys derived from one or more
      shared secrets calculated during the protocol", as defined in
      Section 2 of [RFC9528].

   *  "SUITES_I contains cipher suites supported by the Initiator and
      formatted and processed as specified in Section 3.6 and 6.3.2 of
      [RFC9528]".

   *  "METHOD is an integer specifying the authentication method",as
      defined in Section 3.2 of [RFC9528].  In this case method 4 5 or
      6; see Section 2.1.2.

   *  C_I and C_R are Connection Identifiers chosen by the Initiator and
      Responder, respectively, as specified in Section 3.3 of [RFC9528]
      .

   *  EAD_1, EAD_2, EAD_3, EAD_4, EAD_5 are External Authorization Data
      included in message_1, message_2, message_3, message_4 and
      message_5 respectively.

   This protocol is designed so that it follows the provisions of
   [RFC9528], that is, to encrypt and integrity protect as much
   information as possible and derive symmetric keys and random material
   using EDHOC_KDF with as much previous information as possible

2.1.  Protocol Elements

   This section describes the principal protocol elements that differ
   from the definitions of EDHOC and highlights the most important
   similarities.  For the missing elements, the definitions in Section 3
   of [RFC9528] SHOULD be consulted.











Pocero Fraile, et al.     Expires 27 April 2026                 [Page 9]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


2.1.1.  Ephemeral KEM

   The ephemeral KEM provides forward secrecy for the three
   authentication methods (Methods 4, 5, and 6) described in this
   document, for both the mutual KEM-based authentication method and the
   combined authentication variants.  The Initiator generates a new
   ephemeral KEM key pair in every new session to ensure that the
   compromise of long-term keys does not compromise past communications.
   The elements of the Ephemeral KEM are:

   *  The ephemeral KEM key pair ( pk_eph, sk_eph ) is generated by the
      Initiator using the following function:

      pk_eph, sk_eph <- KEM.KeyGen()

   *  The ephemeral shared secret ( ss_eph ) and the ephemeral
      ciphertext ( ct_eph ) are generated using the encapsulation and
      decapsulation functions: in the Responder

      ss_eph, ct_eph <-  KEM.Encapsulate( pk_eph )

      in the Initiator

      ss_eph <-  KEM.decapsulation( ct_eph, sk_eph )

2.1.2.  Method

   The protocol extends EDHOC by introducing three new authentication
   methods.  When both parties use static KEM key pairs, authentication
   method 4 is used.  In this case, authentication is achieved using a
   Message Authentication Code (MAC) computed from an ephemeral-static
   shared secret.  This MAC is included in message_4 and message_5 to
   authenticate the Responder and the Initiator, respectively.  Methods
   5 and 6 correspond to combined authentication modes, where one party
   uses a static KEM key pair and the other uses a PQC signature scheme.
   The Initiator and Responder must agree on the authentication method
   to be used.  The selected method is indicated by the Initiator in
   message_1.













Pocero Fraile, et al.     Expires 27 April 2026                [Page 10]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


      +===================+====================+====================+
      | Method Type Value | Initiator          | Responder          |
      |                   | Authentication Key | Authentication Key |
      +===================+====================+====================+
      |                 4 | Static KEM Key     | Static KEM Key     |
      +-------------------+--------------------+--------------------+
      |                 5 | Static KEM Key     | PQC Signature      |
      +-------------------+--------------------+--------------------+
      |                 6 | PQC Signature      | Static KEM Key     |
      +-------------------+--------------------+--------------------+

               Table 1: Authentication Keys for Method Types

2.1.3.  Authentication Parameters

   The protocol performs the same authentication-related operations as
   described in Section 3.5 of [RFC9528]

   The protocol transports information about credentials ID_CRED_I and
   ID_CRED_R in message_2 and message_3, respectively.  The
   authentication of these credentials is verified through
   Sig_R_or_MAC_2 and Sig_I_or_MAC_3, sent by the Responder and the
   Initiator in message_4 and message_5, respectively.

   *  If the Responder uses KEM-based authentication (methods 4 or 6),
      it sends MAC_2.  If it authenticates using a PQC signature key
      (method 5), it sends a signature over MAC_2 using the PQC
      algorithm selected on the cipher suit.

   *  Similarly, if the Initiator uses KEM-based authentication (methods
      4 or 5), it sends MAC_3.  If it authenticates with a PQC signature
      key (method 6), it sends a signature over MAC_3 using the PQC
      signature algorithm selected on the cipher suit

2.1.3.1.  Authentication Keys

   The authentication key MUST be a static KEM authentication key or a
   PQC signature key.  The Initiator and Responder use KEM
   authentication keys with method 4, and different types of
   authentication keys with methods 5 and 6.

   The authentication key algorithm must be compatible with the chosen
   method and selected cipher suite.  When either party uses KEM-based
   authentication, the same KEM algorithm selected for the EDHOC key
   exchange in the cipher suite MUST be used for both the ephemeral KEM
   key exchange and the authentication static KEM keys.  When using
   static KEM keys, the Initiator’s and Responder’s private and public
   authentication keys are denoted as follows:



Pocero Fraile, et al.     Expires 27 April 2026                [Page 11]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  The Initiator static KEM authentication key pair: ( pk_I, sk_I )

   *  The Responder static KEM authentication key pair: ( pk_R, sk_R )

   When PQC signature authentication is used, the authentication key
   algorithm MUST be compatible with the EDHOC signature algorithm
   selected in the cipher suite.

2.1.3.2.  Authentication Credentials

   The authentication credentials, CRED_I and CRED_R, contain the
   authentication public key of the Initiator and Responder,
   respectively, as described in Section 3.5.2 of [RFC9528].

   *  The authentication credentials can be X.509 certificates seconded
      as bstr, as defined in Section 3.5.2 of [RFC9528], using
      [RFC9360].  When static KEM authentication keys are used,
      [I-D.ietf-lamps-kyber-certificates] specifies the conventions for
      using ML-KEM wuthin X.509 Public Key Infrastructure (PKI).

   *  Additionally, the authentication credential may include a
      COSE_key, formatted as specified in [RFC8392], to reduce the
      credential size and avoid the PQC signature verification needed
      when X.509 certificates are used.  New IANA value registries
      should be defined to extend COSE Algorithms with the corresponding
      KEMs algorithm values.

2.1.3.3.  Identification of Credentials

   The ID_CRED fields are used to identify and optionally transport
   credentials as defined in Section 3.5.3 of [RFC9528].  The
   authentication method defined in this document operates within the
   general EDHOC framework described in Section 3.5.3 of [RFC9528],
   where ID_CRED_X can either contain the full CRED_X credentials or an
   identifier of those credentials if they have already been provided
   out-of-band.

   *  "ID_CRED_R is intended to facilitate for the Initiator retrieving
      the authentication credential CRED_R and the authentication key of
      R", as defined in Section 3.5.3 of [RFC9528].

   *  "ID_CRED_I is intended to facilitate for the Responder retrieving
      the authentication credential CRED_I and the authentication key of
      I", as defined in Section 3.5.3 of [RFC9528].







Pocero Fraile, et al.     Expires 27 April 2026                [Page 12]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


2.1.4.  Cipher Suites

   The authentication method specified in this document uses the EDHOC
   cipher suites element, as defined in Section 3.6 of [RFC9528].  An
   EDHOC cipher suit consists of an ordered set of algorithms from the
   "COSE Algorithms" IANA registry [RFC9053].  The predefined EDHOC
   cipher suites are also listed in the IANA registry, as specified in
   Section 10.2 of [RFC9528].

   A new predefined cipher suite SHOULD be added to the IANA registry,
   specifying the supported KEM in the EDHOC Key Exchange Algorithm
   parameter and the PQC signature algorithm in the EDHOC signature
   algorithm parameter, as specified in Section 5.2 of
   [I-D.spm-lake-pqsuites].  An example of this, when ML-KEM is used, is
   shown in Section 5.  The same KEM algorithm selected for key exchange
   SHOULD also be used for KEM-based authentication when methods 4, 5 or
   6 are selected.  Furthermore, the KEM algorithms used SHOULD also be
   added to the COSE Algorithms IANA registry to identify them, as is
   shown in Section 5.

3.  Key Derivation

   This section highlights the differences and similarities in the key
   derivation process when KEM-based authentication is used to
   authenticate the Initiator (method 5), the Responder (method 6), or
   both (method 4), compared to [RFC9528].  An overview of the EDHOC key
   schedule for KEM-based authentication methods 4, 5, or 6 is shown in
   Figure 2, and each key derivation step is explained in the following
   subsections.


                +-------+
                | TH_2  |
                +-------+
                 |
      +----+  +--v+  +------+  +------+  +-----+    +-+  +---+
      |ss_e|->|Ext|->|PRK_2e|--|Expand|->|KEY_2|--->| |->|C_2|
      +----+  +---+  +--+---+  +--+---+  +-----+    |X|  +---+
                        |         |   PLAINTEXT_2-->| |
                     +-----+      |                 +-+
                T+---|R use|      |
                 |   |KEM ?|      |
                 |   +-----+      |
                 |     F|     +--+----------------------+
                 |      |     |TH_2=H(H(Message1),ct_eph|
                 |      |     +-------------------------+
                 |      |
      +----+  +--++  +--v-----+  +------+  +---+  +----+  +---+



Pocero Fraile, et al.     Expires 27 April 2026                [Page 13]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


      |ss_R|->|Ext|->|PRK_3e2m|+-|Expand|->|K_3|->|AEAD|->|C_3|
      +----+  +---+  +----+---+ |+--+---+  +---+  +----+  +---+
                          |     |   |            |
                          |     |   |        PLAINTEXT_3
                     +----++    |   |
                T+---|I use|    |   |
                 |   |KEM ?|    |   |
                 |   +--+--+    |   |
                 |      | F     | +-+---------------------+
                 |      |       | |TH_3=                  |
                 |      |       | |  H(TH_2,PLAINTEXT_2,  |
                 |      |       | |  CRED_R,ct_R?)        |
                 |      |       | +-----------------------+
                 |      |       |
                 |      |       |  +------+  +-----+
                 |      |       +--|Expand|->|MAC_2|
                 |      |          +-+----+  +-----+
                 |      |            |
                 |      |    +---------------+---------------------+
                 |      |    |TH_4=H(TH_3,PLAINTEXT_3,CRED_I,ct_I?)|
                 |      |    +------------------+------------------+
                 |      |           |
      +----+  +--+-+  +-v------+  +-+----+  +---+  +----+  +---+
      |ss_I|->|Ext |->|PRK_4e3m|+-|Expand|->|K_4|->|AEAD|->|C_4|
      +----+  +----+  +--------+| +------+ |+---+ |+--^-+  +---+
                                |          |      |   |
                                |          |      | PLAINTEXT_4
                                |          |      |+----+  +---+
                                |          |      -|AEAD|->|C_5|
      +------------------------+|          |       +-^--+  +---+
      |TH_5=H(TH_4,PLAINTEXT_4)||          |         |
      +--+---------------------+|          |       PLAINTEXT_5
                          |     |          |
            +-----+   +-+----+  |          |
            |MAC_3|<--|Expand|--|          |
            +-----+   +------+             |   +-------+
                                           |-->|PRK_out|
                                               +--+----+
                                                  |
                                               +--v---+
                                               |Expand|
                                               +------+
                                                 |
                                                 v
                                            +------------+
                                            |PRK_exporter|
                                            +---+--------+
                                                |



Pocero Fraile, et al.     Expires 27 April 2026                [Page 14]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


                                             +--v---+
                                             |Expand|
                                             +--+---+
                                                |
                                                v
                                          Aplication Key

         Figure 2: EDHOC Message Key Derivation using the KEM-based
                      Authentication Methods 4, 5 or 6

3.1.  Keys for EDHOC Message Processing

3.1.1.  EDHOC_Extract

   The pseudorandom keys (PRKs) used for KEM-based authentication
   methods are derived using the same EDHOC_Extract function defined in
   [RFC9528], where the input keying material (IKM) and Salt are
   specified for each PRK below.

3.1.1.1.  PRK_2e

   The pseudorandom key PRK_2e is derived with the following input:

   *  The salt SHALL be TH_2.

   *  The IKM SHALL be the ephemeral KEM shared secret (ss_eph)

   When SHA-256 is used PRK_2e is produced as follows:

   PRK_2e = HMAC-SHA-256( TH_2, ss_eph )

   Where the ephemeral shared secret ss_eph is the output of the
   following functions in the Initiator and Responder respectively

   Initiator:

   ss_eph <-  KEM.Decapsulate( ct_eph, sk_eph )

   Responder:

   ss_eph, ct_eph <-  KEM.Encapsulate( pk_eph )

3.1.1.2.  PRK_3e2m

   If the Responder authenticates using static KEM keys, the
   pseudorandom key PRK_3e2m is derived using the following input:

   *  The salt SHALL be the SALT_3e2m derived from PRK_2e



Pocero Fraile, et al.     Expires 27 April 2026                [Page 15]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  The IKM SHALL be the KEM shared secret ss_R, used to authenticate
      the Responder

   PRk_3e2m is derived as follows:

   PRK_3e2m = EDHOC_Extract( SALT_3e2m, ss_R )

   Where the KEM shared secret ss_R used to authenticate the Responder
   is the output of the following functions in the Initiator and
   Responder, respectively

   Initiator:

   ss_R, ct_R <-  KEM.Encapsulate( pk_R )

   Responder:

   ss_R <-  KEM.Decapsulate( ct_R, sk_R )

   Else, if the Responder authenticates using a PQC signature algorithm,
   then PRK_3e2m SHALL be set equal to PRK_2e (PRK_3e2m = PRK_2e).

3.1.1.3.  PRK_4e3m

   If the Initiator authenticates using static KEM keys, the
   pseudorandom key PRK_4e3m is derived using the following input:

   *  The salt SHALL be the SALT_4e3m, derived from PRK_3e2m

   *  The IKM SHALL be the KEM shared secret ss_I, used to authenticate
      the Initiator

   PRk_4e3m is derived as follows:

   PRK_4e3m = EDHOC_Extract( SALT_4e3m, ss_I )

   Where the KEM shared secret ss_I used to authenticate the Initiator
   is the output of the following functions in the Initiator and
   Responder, respectively

   Initiator:

   ss_I <-  KEM.Decapsulate( ct_I, sk_I )

   Responder:

   ss_I, ct_I <-  KEM.Encapsulate( pk_I )




Pocero Fraile, et al.     Expires 27 April 2026                [Page 16]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   Else, if the Initiator authenticates using a PQC signature algorithm,
   then PRK_4e3m SHALL be set equal to PRK_3e2m (PRK_4e3m = PRK_3e2m).

3.1.2.  EDHOC_Expand and EDHOC_KDF

   The output key materials (OKMs) are derived from the PRKs in the same
   way as described in Section 4.1.2 of [RFC9528], with modifications in
   the transcript hashes THs input contraction as specified in
   Section 4.

   The same OKMs, including keys, initialization vectors (IV), and salts
   as those shows in Section 4.1.2 of [RFC9528] Figure 6 are derived,
   just notice that:

   *  K_3 and IV_3 are computed to provide integrity protection for
      message_3 ensuring that the Initiator’s identity is protected
      against active attacks.  However, this does not provide
      authentication of the Initiator’s identity.

   The final key derivations using EDHOC_KDF is shwon in Figure 3.
   Further details of the key derivation and how the output keying
   material is used are specified in Section 4

   KEYSTREAM_2   = EDHOC_KDF( PRK_2e,   0, TH_2,      plaintext_length )
   SALT_3e2m     = EDHOC_KDF( PRK_2e,   1, TH_2,      hash_length )
   MAC_2         = EDHOC_KDF( PRK_3e2m, 2, context_2, mac_length_2 )
   K_3           = EDHOC_KDF( PRK_3e2m, 3, TH_3,      key_length )
   IV_3          = EDHOC_KDF( PRK_3e2m, 4, TH_3,      iv_length )
   SALT_4e3m     = EDHOC_KDF( PRK_3e2m, 5, TH_4,      hash_length )
   MAC_3         = EDHOC_KDF( PRK_4e3m, 6, context_3, mac_length_3 )
   PRK_out       = EDHOC_KDF( PRK_4e3m, 7, TH_4,      hash_length )
   K_4           = EDHOC_KDF( PRK_4e3m, 8, TH_4,      key_length )
   IV_4          = EDHOC_KDF( PRK_4e3m, 9, TH_4,      iv_length )
   PRK_exporter  = EDHOC_KDF( PRK_out, 10, h'',       hash_length )

        Figure 3: Key Derivations Using EDHOC_KDF for the KEM-based
                           Authentication Methods

   Notice that a new key session (K_5/IV_5) can be derived from the same
   PRK_4e3m, using TH_5 as the info parameter, to encrypt message_5, if
   separate keys are shown to enhance security in any way.  The initial
   version of this protocol adopts a simpler approach by deriving a
   single session key to protect both messages, which are different from
   the MAC keys.







Pocero Fraile, et al.     Expires 27 April 2026                [Page 17]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


3.1.3.  PRK_out

   The pseudorandom key PRK_out is the output session key of a completed
   EDHOC session and is derived as follows:

   PRK_out = EDHOC_KDF( PRK_4e3m, TH_4, hash_length )

3.2.  Keys for EDHOC Applications

   Keying material for the application can be derived using the same
   EDHOC_Exporter interface defined in Section 4.2.1 of [RFC9528]

4.  Message Formatting and Processing

   This section outlines the message format and the procedures for
   composing and processing each message.

4.1.  KEM-based Authentication EDHOC Message 1

4.1.1.  Formating of Message 1

   message_1 retains the same format as defined in Section 5.2.1 of
   [RFC9528].  The same fields are used, except that GX is replaced by
   the KEM ephemeral public key ( pk_eph ) computed by the Initiator.

   message_1 = (
     METHOD : int,
     SUITES_I : suites,
     pk_eph : bstr,
     C_I : bstr / -24..23,
     ? EAD_1,
   )

   suites = [ 2* int ] / int
   EAD_1 = 1* ead

   The selected authentication method (methods 4, 5 or 6) SHOULD be
   indicated in the METHOD field.

4.1.2.  Initiator Composition of Message 1

   The Initiator SHALL compose message_1 as follows:

   *  Construct SUITES_I following the Section 5.2.2 of [RFC9528]
      specifications






Pocero Fraile, et al.     Expires 27 April 2026                [Page 18]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  Generate an ephemeral KEM Key pair (pk_eph) using the KEM
      algorithm from the selected cipher suit.  The ephemeral key pair
      is computed by the Initiator using the following function:

      pk_eph, sk_eph <-  KEM.KeyGen()

   *  Choose a conection identifier as in Section 5.2.2 of [RFC9528].

   *  Encode message_1 as sequence of CBOR-encoded elements, as
      specified in Section 4.1.1

4.1.3.  Responder Processing of Message 1

   The Responder SHALL process message_1 in the following order:

   1.  "Decode message_1", as specified in Section 5.2.3 of [RFC9528]

   2.  "Process message_1", as specify in Section 5.2.3 of [RFC9528]

   3.  "If all processing is completed successfully, and if EAD_1 is
       present, then make it available to the application", as specified
       in Section 5.2.3 of [RFC9528]

4.2.  KEM-based authentication EDHOC Message 2

4.2.1.  Formating of Message 2

   message_2 keeps the same formatting as Section 5.3.1 of [RFC9528].
   The same fields are used instead GY is replaced with the ephemeral
   KEM ciphertext ( ct_eph ) computed on the Responder.

   message_2 = (
     ct_eph_CIPHERTEXT_2 : bstr,
   )

   where cc_eph_CIPHERTEXT_2 is the concatenation of ct_eph and
   CIPHERTEXT_2.

4.2.2.  Responder Composition of Message 2

   The Responder SHALL compose message_2 as follows:

   *  Encapsulate the ephemeral KEM key received within message_1 using
      the KEM algorithm in the selected cipher suit.  The ephemeral KEM
      ciphertext and the KEM ephemeral shared secret are computed by the
      Responder using the following function:

       ss_eph, ct_eph <-  KEM.Encapsulate(pk_eph)



Pocero Fraile, et al.     Expires 27 April 2026                [Page 19]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  Compute the PRK_2e pseudorandom key from the ephemeral KEM shared
      secret ( ss_eph )

   *  "Choose a connection identifier C_R", as specified in
      Section 5.3.2 of [RFC9528]

   *  Compute the transcript hash TH_2 = H(pk_eph,H(message_1)) as
      specified in Section 5.3.2 of [RFC9528]

   *  At this point, when the Responder use KEM-based authentication, is
      not jet able to authenticate itself; therfore MAC_2 is not
      computed.  Although the Responder could, in principle,
      authenticate itself at this stage when using PQC signature-based
      authentication, the message-flow-preserving approach restricts
      Responder authentication to message_4.  A corresponding message
      flow that enables a party to authenticate as soon as it becomes
      possible is shown in Appendix A

   *  CIPHERTEXT_2 is calculated, with a binary additive stream cipher
      as in Section 5.3.2 of [RFC9528], using a keystream (KEYSTREAM_2)
      generated with EDHOC_Expand and the following plaintext:

      -  Compute PLAINTEXT_2 as:

            PLAINTEXT_2 = (C_R,ID_CRED_R,?EAD_2)

         where C_R, ID_CRED_R and EAD_2 elements corresponds with the
         ones in Section 5.3.2 of [RFC9528].

      -  Compute KEYSTREAM_2 as in Section 3.1.2

      -  Compute CIPHERTEXT_2 as in Section 5.3.2 of [RFC9528]

         CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2

   *  Encode message_2 as a sequence of CBOR-encoded data items as
      specified in Section 4.2.1

4.2.3.  Initiator Processing of Message 2

   The Initiator SHALL process message_2 in the following order:

   1.   Decode message_2

   2.   "Retrieve the protocol state" as proposed in Section 5.3.3 of
        [RFC9528]





Pocero Fraile, et al.     Expires 27 April 2026                [Page 20]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   3.   Compute the ephemeral KEM shared_secret ( ss_eph ) by
        decapsulating the KEM ciphertext ( ct_eph ) received in
        message_2 using the ephemeral secret key ( sk_eph ).  The
        ephemeral KEM shared secret is computed by the Initiator using
        the following function:

       ss_eph <-  KEM.Decapsulate( ct_eph, sk_eph )

   4.   Compute the PRK_2e pseudorandom key from the ephemeral KEM
        shared secret ( ss_eph )

   5.   Compute the transcript hash TH_2 = H(pk_eph,H(message_1))

   6.   Derive KEYSTREAM_2 as in Section 3.1.2

   7.   Decrypt CIPHERTEXT_2; see Section 4.2.2

   8.   If all processing is completed successfully, then make ID_CRED_R
        and (if present) EAD_2 available to the application as in
        Section 5.3.3 of [RFC9528]

   9.   Obtain the authentication credential (CRED_R) from the
        (ID_CRED_R) as in Section 5.3.3 of [RFC9528], and the static
        authentication key of the Responder

   10.  If the Responder use KEM-based authentication (methods equal 4
        or 6) then the Initiator MUST perform the following steps:

        *  Encapsulate the retrieved static KEM authentication key of
           the Responder ( pk_R ) calculating the corresponding
           ciphertext ( ct_R ) and shared secret ( ss_R ) with the
           following function:

            ss_R, ct_R <-  KEM.Encapsulate(pk_R)

        *  Compute the new PRK_3e2m from a chain that includes both the
           ephemeral KEM shared secret ( ss_eph ) and the latest KEM
           shared secret for the Authentication of the Responder ( ss_R
           ), as defined in Section 3.1.1.2

        Else, if the Responder authenticates using a PQC signature
        algorithm (method 5), then PRK_3e2m SHALL be set equal to PRK_2e
        (PRK_3e2m = PRK_2e).

4.3.  KEM-based authentication EDHOC Message 3






Pocero Fraile, et al.     Expires 27 April 2026                [Page 21]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


4.3.1.  Formating of Message 3

   message_3 SHALL be a CBOR Sequence as defined below:

   message_3 = (
     CIPHERTEXT_3 : bstr,
     ? ct_R : bstr,
   )

4.3.2.  Initiator Composition of Message 3

   The Initiator SHALL process the composition of message_3 as follows:

   *  Compute the transcript hash TH_3=H(TH_2,PLAINTEXT_2,CRED_R,? ct_R)
      as specified in Section 5.4.2 of [RFC9528].  The element ( ct_R )
      SHALL be present only when the Responder use KEM-based
      authentication (methods 4 and 6); otherwise it SHALL be ommited.

   *  Derive the new session key K_3/IV_3 as defined in Section 3.1.2.
      The Initiator can use this key to compute CIPHERTEXT_3, but it
      cannot be used to authenticate itself.

   *  At this point, when the Initiator use KEM-based authentication, is
      not jet able to authenticate itself; therfore MAC_3 is not
      computed.  Although the Initiator could, in principle,
      authenticate itself at this stage when using PQC signature-based
      authentication, the message-flow-preserving approach restricts
      Responder authentication to message_5.  A corresponding message
      flow that enables a party to authenticate as soon as it becomes
      possible is shown in Appendix A

   *  Compute a COSE_Encrypt0 object as defined in Section 5.2 and 5.3
      of [RFC9052], 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 plaintext PLAINTEXT_3,
      and the following parameters as input:

      -  protected = h''

      -  external_aad = TH_3

      -  K_3 and IV_3 are defined in Section 3.1.2

      -  PLAINTEXT_3 = (C_I,ID_CRED_I,?EAD_3) where C_I, ID_CRED_I and
         EAD_3 elements corresponds with the ones in Section 5.3.3 of
         [RFC9528]

      CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.



Pocero Fraile, et al.     Expires 27 April 2026                [Page 22]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  Encode message_3 as a CBOR data item as specified in
      Section 4.3.1.  The element ( ct_R ) SHALL be present only when
      the Responder use KEM-based authentication (methods 4 and 6);
      otherwise it SHALL be ommited.  When the Responder use PQC
      Signature algorithms (method 5) message_3 consists of a single
      element (CIPHERTEXT_3).  ( ct_R ) is defined as the trailing
      element so it can be omitted when not used; therefore, senders
      MUST NOT encode ct_R as NULL.

4.3.3.  Responder Processing of Message 3

   The Responder SHALL process message_3 in the following order:

   1.  Decode message_3

   2.  "Retrieve the protocol state", as defined in Section 5.4.3 of
       [RFC9528]

   3.  If the Responder use KEM-based authentication (methods 4 or 6)
       then it MUST perform the following steps:

       *  Compute the KEM shared_secret ( ss_R ) for the authentication
          of the Responder by decapsulating the KEM ciphertext ( ct_R )
          received in message_3 using the Responder static KEM secret
          key ( sk_R ).  The KEM shared secret is computed by the
          Responder using the following function:

           ss_R <-  KEM.Decapsulate( ct_R, sk_R )

       *  Compute the new PRK_3e2m from a chain that includes both the
          ephemeral KEM shared secret ( ss_eph ) and the latest KEM
          shared secret for the Authentication of the Responder ( ss_R
          ), as defined in Section 3.1.1.2

       Else, if the Responder authenticates using a PQC signature
       algorithm (method 5), then PRK_3e2m SHALL be set equal to PRK_2e
       (PRK_3e2m = PRK_2e).

   4.  Compute the transcript hash TH_3=H(TH_2,PLAINTEXT_2,CRED_R,?
       ct_R).  The element ( ct_R ) SHALL be present only when the
       Responder use KEM-based authentication (methods 4 and 6);
       otherwise it SHALL be ommited.

   5.  Compute K_3/IV_3 as in Section 3.1.2, where plaintext_length is
       the length of PLAINTEXT_3

   6.  Decrypt CIPHERTEXT_3; see Section 4.3.2




Pocero Fraile, et al.     Expires 27 April 2026                [Page 23]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   7.  "If all processing is completed successfully, then make ID_CRED_I
       and (if present) EAD_2 available to the application", as in
       Section 5.3.4 of [RFC9528]

   8.  "Obtain the authentication credential (CRED_I) from the
       (ID_CRED_I)" as in Section 5.3.4 of [RFC9528] and the static
       authentication key of the Initiator.

4.4.  KEM-based authentication EDHOC Message 4

4.4.1.  Formating of Message 4

   message_4 SHALL be a CBOR Sequence as defined below:

   message_3 = (
     CIPHERTEXT_4 : bstr,
     ? ct_I : bstr,
   )

4.4.2.  Responder Composition of Message 4

   The Responder SHALL process the composition of message_4 as follows:

   *  If the Initiator use KEM-based authentication (methods equal 4 or
      5) then the Responder MUST perform the following step:

      -  Encapsulate the retrieved static KEM authentication key of the
         Initiator ( pk_I ) calculating the corresponding ciphertext (
         ct_I ) and shared secret ( ss_I ) with the following function:

          ss_I, ct_I <-  KEM.Encapsulate(pk_I)

   *  Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I,?
      ct_I).  The element ( ct_I ) SHALL be present only when the
      Initiator use KEM-based authentication (methods 4 and 5);
      otherwise it SHALL be ommited.

   *  Compute MAC_2 as defined in Section 3.1.2, with context_2 =<< C_R,
      ID_CRED_R, TH_4, CRED_R, ? EAD_4 >>

      -  If the Resonder authenticates with static KEM key (methods
         equals 4 or 6), then the mac_lenght_2 is equal to the EDHOC MAC
         length of the selected cipher suit.  If the Responder
         authenticates with PQC Signature algorithms (method equal 5),
         then the mac_lenght_2 is equal to hash_length.

      -  The C_R, ID_CRED_R and CRED_R elements corresponds with the
         ones in Section 5.3.2 of [RFC9528]



Pocero Fraile, et al.     Expires 27 April 2026                [Page 24]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


      -  The latest transcript hash TH_4 and the External Application
         Data included in Message 4 (EAD_4) are used.

   *  If the Responder use KEM-based authentication (methods equal 4 or
      6) then Sig_R_or_MAC_2 is MAC_2.  If the Responder authenticates
      using a PQC signature algorithm (method 5), then Sig_R_or_MAC_2 is
      the 'signature' field of a COSE_Sign1 object, computed as
      specified in Section 5.3.2 of [RFC9528] but using the PQC
      Signature algorithm specify in the selected cipher suite, the
      private PQC authentication key of the Responder,and the following
      parameteres as input::

      -  protected = << ID_CRED_R >>

      -  external_aad = << TH_4, CRED_R, ? EAD_4 >>

      -  payload = MAC_2

   *  If the Initiator use KEM-based authentication (methods equal 4 or
      5) then the Responder MUST perform the following step:

      -  Compute the new PRK_4e3m from a chain that includes the
         ephemeral KEM shared secret ( ss_eph ), the KEM shared secret
         for the Authentication of the Responder ( ss_R ), and the
         latest KEM shared secret for the Authentication of the
         Initiator ( ss_I ) as defined in Section 3.1.1.3

      Else, if the Initiator authenticates using a PQC signature
      algorithm (method equal 6), then PRK_4e3m SHALL be set equal to
      PRK_3e2m (PRK_4e3m = PRK_3e2m).

   *  Derive the session key K_4/IV4 as in Section 3.1.2.

   *  Compute a COSE_Encrypt0 object as defined in Section 5.2 and 5.3
      of [RFC9052], with the EDHOC AEAD algorithm of the selected cipher
      suite, using the encryption key K_4, the initialization vector
      IV_4 (if used by the AEAD algorithm), the plaintext PLAINTEXT_4,
      and the following parameters as input:

      -  protected = h''

      -  external_aad = TH_4

      -  K_4 and IV_4 are defined in Section 3.1.2

      -  PLAINTEXT_4 = ( MAC_2, ?EAD_4 )

      CIPHERTEXT_4 is the 'ciphertext' of COSE_Encrypt0.



Pocero Fraile, et al.     Expires 27 April 2026                [Page 25]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  Compute the transcript hash TH_5 = H(TH_4, PLAINTEXT_4)

   *  Encode message_4 as a CBOR data item as specified in
      Section 4.4.1.The element ( ct_I ) SHALL be present only when the
      Initiator use KEM-based authentication (methods 4 and 5);
      otherwise it SHALL be ommited.  When the Initiator use PQC
      Signature algorithms (method 6) message_4 consists of a single
      element (CIPHERTEXT_4).  ( ct_I ) is defined as the trailing
      element so it can be omitted when not used; therefore, senders
      MUST NOT encode ct_I as NULL.

4.4.3.  Initaitor Processing of Message 4

   The Initiator SHALL process message_4 in the following order:

   1.  Decode message_4

   2.  "Retrieve the protocol state using available message
       correlation", as in Section 3.4.2 of [RFC9528].

   3.  If the Initiator use KEM-based authentication (methods equal 4 or
       5) then it MUST perform the following steps:

       *  Compute the KEM shared secret ( ss_I ) for the authentication
          of the Initiator by decapsulating the KEM ciphertext ( ct_I )
          received in message_4 using the Responder static KEM secret
          key ( sk_I ).  The KEM shared secret is computed by the
          Initiator using the following function:

           ss_I <-  KEM.Decapsulate( ct_I, sk_I )

       *  Compute the new PRK_4e3m from a chain that includes the
          ephemeral KEM shared secret ( ss_eph ), the KEM shared secret
          for the Authentication of the Responder ( ss_R ), and the
          latest KEM shared secret for the Authentication of the
          Initiator ( ss_I ) as defined in Section 3.1.1.3

       Else, if the Initiator authenticates using a PQC signature
       algorithm (method equal 6), then PRK_4e3m SHALL be set equal to
       PRK_3e2m (PRK_4e3m = PRK_3e2m).

   4.  Compute the transcript hash TH_4 = H(TH_3, PLAINTEXT_3, CRED_I, ?
       ct_I).  The element ( ct_I ) SHALL be present only when the
       Initiator use KEM-based authentication (methods 4 and 5);
       otherwise it SHALL be ommited.

   5.  Derive the session key K_4/IV4 as in Section 3.1.2.




Pocero Fraile, et al.     Expires 27 April 2026                [Page 26]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   6.  Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_4) as defined
       Section 5.2 and 5.3 of [RFC9052]], with the EDHOC AEAD algorithm
       in the selected cipher suite and the parameters defined in
       Section 4.4.2.

   7.  Verify Sig_R_or_MAC_2 using the algorithm in the selected cipher
       suite.  The verification process depepends on the authentication
       method used by the Responder as defined in Section 4.4.2.  "Make
       the result of the verification available to the application" as
       in Section 5.3.3 of [RFC9052]

4.5.  KEM-based authentication EDHOC Message 5

4.5.1.  Formating of Message 5

   message_5 SHALL be a CBOR Sequence as defined below:

   message_3 = (
     CIPHERTEXT_5 : bstr,
   )

4.5.2.  Initiator Composition of Message 5

   The Initiator SHALL process the composition of message_5 as follows:

   *  Compute the transcript hash TH_5 = H(TH_4, PLAINTEXT_4)

   *  Compute MAC_3 as defined in Section 3.1.2, with context_3 =<< C_I,
      ID_CRED_I, TH_5, CRED_I, ? EAD_5 >>

      -  If the Initiator authenticates with static KEM key (methods
         equals 4 or 5), then the mac_lenght_3 is equal to the EDHOC MAC
         length of the selected cipher suit.  If the Initiator
         authenticates with PQC Signature algorithms (method equal 6),
         then the mac_lenght_3 is equal to hash_length.

      -  The C_I, ID_CRED_I and CRED_I elements corresponds with the
         ones in Section 5.4.2 of [RFC9528]

      -  The latest transcript hash TH_5 and the External Application
         Data included on Message 5 (EAD_5) are used.










Pocero Fraile, et al.     Expires 27 April 2026                [Page 27]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   *  If the Initiator use KEM-based authentication (methods equal 4 or
      5) then Sig_I_or_MAC_3 is MAC_3.  If the Initiator authenticates
      using a PQC signature algorithm (method 6), then Sig_I_or_MAC_3 is
      the 'signature' field of a COSE_Sign1 object, computed as
      specified in Section 4.3.2 of [RFC9528] but using the PQC
      Signature algorithm specify in the selected cipher suite, the
      private PQC authentication key of the Initiator, and the following
      parameteres as input:

      -  protected = << ID_CRED_I >>

      -  external_aad = << TH_5, CRED_I, ? EAD_5 >>

      -  payload = MAC_3

   *  Compute a COSE_Encrypt0 object as defined inSection 5.2 and 5.3 of
      [RFC9052], with the EDHOC AEAD algorithm of the selected cipher
      suite, using the encryption key K_4, the initialization vector
      IV_4 (if used by the AEAD algorithm), the plaintext PLAINTEXT_5,
      and the following parameters as input:

      -  protected = h''

      -  external_aad = TH_5

      -  K_5 and IV_5 are defined in Section 3.1.2

      -  PLAINTEXT_5 = ( MAC_3, ? EAD_5 )

      CIPHERTEXT_5 is the 'ciphertext' of COSE_Encrypt0.

   *  Calculate PRK_out as defined in Section 3.1.3.  The Initiator can
      now derive application keys using the EDHOC_Exporter interface;
      see Section 3.2

   *  Encode message_5 as a CBOR data item as specified in Section 4.5.1

   *  "Make the connection identifiers (C_I and C_R) and the application
      algorithms in the selected cipher suite available to the
      application" as in Section 5.4.2 of [RFC9528]

   After creating message_5, the Initiator can compute PRK_out and
   derive application keys using the EDHOC_Exporter interface.  The
   Responder SHOULD now persistently store PRK_out or application keys
   and send protected application data, since it has already verified
   message_4, which is protected with a derived application key by the
   Responder, and the application has authenticated the Responder.




Pocero Fraile, et al.     Expires 27 April 2026                [Page 28]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


4.5.3.  Responder Processing of Message 5

   The Responder SHALL process message_5 in the following order:

   1.  Decode message_5

   2.  "Retrieve the protocol state using available message correlation"
       as in Section 3.4.2 of [RFC9528].

   3.  Decrypt and verify the COSE_Encrypt0 (CIPHERTEXT_5) as defined in
       Section 5.2 and 5.3 of [RFC9052], with the EDHOC AEAD algorithm
       in the selected cipher suite and the parameters defined in
       Section 4.5.2.

   4.  Verify Sig_I_or_MAC_3 using the algorithm in the selected cipher
       suite.  The verification process depepends on the authentication
       method used by the Initiator as defined in Section 4.5.2.  "Make
       the result of the verification available to the application" as
       in Section 5.3.3 of [RFC9052]

   5.  Calculate PRK_out as defined in Section 3.1.3.  The Initiator can
       now derive application keys using the EDHOC_Exporter interface;
       see Section 3.2

   After verifying message_5, the Responder can compute PRK_out and
   derive application keys using the EDHOC_Exporter interface.  The
   Responder SHOULD now persistently store PRK_out or application keys
   and send protected application data, since it has already verified
   message_5, which is protected with a derived application key by the
   Initiator, and the application has authenticated the Initiator.

5.  IANA Considerations

5.1.  COSE Algorithms Registry

   The "COSE Algorithms" Registry from "CBOR Object Signing and
   Encryption (COSE)" group SHOULD be extended with new values to
   include PQC KEM algorithms.  The extension of values from the
   "Standards Action with Expert Review" range for ML-KEM algorithms at
   NIST security levels 1 and 3, is proposed in Table 2

   Registry Name:  COSE Algorithms

   Reference:  draft-pocero-authkem-edhoc-00







Pocero Fraile, et al.     Expires 27 April 2026                [Page 29]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   The columns of the registry are Name, Value and Description, where
   Value is an integer and the other columns are text strings.  For both
   new registrations, the change controller is the IETF, and the
   reference field should point to this document.  The new values
   proposed are:

       +=============+=================+===========================+
       | Name        | Value           | Description               |
       +=============+=================+===========================+
       | ML-KEM-512  | -54 (suggested) | CBOR object KEM Algorithm |
       |             |                 | for ML-KEM-512            |
       +-------------+-----------------+---------------------------+
       | ML-KEM-1024 | -55 (suggested) | CBOR object KEM Algorithm |
       |             |                 | for ML-KEM-1024           |
       +-------------+-----------------+---------------------------+

                          Table 2: COSE Algorithms

5.2.  EDHOC Cipher Suites Registry

   The "EDHOC Cipher Suites" Registry from group "Ephemeral Diffie-
   Hellman Over COSE (EDHOC)" SHOULD be extended with new values to
   include the cipher suits with the KEM algorithm used.  While the KEM-
   based authentication protocol specified in this document can support
   different KEM algorithms, the NIST-standardized ML-KEM is
   RECOMMENDED.  The extension of values from the "Standards Action with
   Expert Review" range, when the ML-KEM algorithm is used at NIST
   security levels 1 and 3, is proposed in Table 3

   Registry Name:  EDHOC Cipher Suites

   Reference:  draft-pocero-authkem-edhoc-00

   The columns of the registry are Value, Array, Description, and
   Reference, where Value is an integer and the other columns are text
   strings.  The new values proposed are:















Pocero Fraile, et al.     Expires 27 April 2026                [Page 30]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   +===========+=====+===================+=============================+
   |Value      |Array|Description        |Reference                    |
   +===========+=====+===================+=============================+
   |7          |30,  |AES-CCM-16-128-128,|draft-pocero-authkem-edhoc-00|
   |(suggested)|-16, |SHA-256, 16, ML-   |                             |
   |           |16,  |KEM-512, ML-DSA-44,|                             |
   |           |-54, |AES-CCM-16-64-128, |                             |
   |           |-48 ,|SHA-256            |                             |
   |           |10,  |                   |                             |
   |           |-16  |                   |                             |
   +-----------+-----+-------------------+-----------------------------+
   |8          |10,  |A256GCM, SHA-384,  |draft-pocero-authkem-edhoc-00|
   |(suggested)|-16, |16, ML-KEM-1024,   |                             |
   |           |8, 1,|ML-DSA-65, A256GCM,|                             |
   |           |-55, |SHA-384            |                             |
   |           |-49 ,|                   |                             |
   |           |-16  |                   |                             |
   +-----------+-----+-------------------+-----------------------------+

                        Table 3: EDHOC Cipher Suites

   The PQC ML-DSA signature algorithms are selected as the EDHOC
   signature algorithm parameter to verify X.509 certificate signatures
   when the X.509 credential type is used.

5.3.  EDHOC Method Types Registry

   The "EDHOC Method Types" Registry from group "Ephemeral Diffie-
   Hellman Over COSE (EDHOC)" SHOULD be extended with a new value that
   identifies the KEM-based authentication method.  The extension value
   from the "Standards Action with Expert Review" range, is proposed in
   Table 4

   Registry Name:  EDHOC Method Types

   Reference:  draft-pocero-authkem-edhoc-00

   The columns of the registry are Value, Initiator Authentication Key,
   Responder Authentication Key and Reference, where Value is an integer
   and the other columns are text strings.  The new value proposed is:











Pocero Fraile, et al.     Expires 27 April 2026                [Page 31]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


    +=============+================+================+================+
    | Value       | Initiator      | Responder      | Reference      |
    |             | Authentication | Authentication |                |
    |             | Key            | Key            |                |
    +=============+================+================+================+
    | 4           | Static KEM Key | Static KEM Key | [draft-pocero- |
    | (suggested) |                |                | authkem-edhoc- |
    |             |                |                | 00]            |
    +-------------+----------------+----------------+----------------+
    | 5           | Static KEM Key | PQC Signature  | [draft-pocero- |
    | (suggested) |                | key            | authkem-edhoc- |
    |             |                |                | 00]            |
    +-------------+----------------+----------------+----------------+
    | 6           | PQC Signature  | Static KEM Key | [draft-pocero- |
    | (suggested) | key            |                | authkem-edhoc- |
    |             |                |                | 00]            |
    +-------------+----------------+----------------+----------------+

                       Table 4: EDHOC Method Types

6.  Security Considerations

   EDHOC protocol with static DH keys enables the Initiator and
   Responder to generate an ephemeral-static shared secret using the
   other party's ephemeral public keys and their own credentials.  This
   shared secret is then used to derive a session key for
   authentication.  Messages 2 and 3 provide explicit authentication
   through MACs, which also bind the exchanged credentials to prevent
   misbinding attacks, as is described in Section 9.1 of [RFC9528]

   In contrast, the KEM-based authentication mechanism requires an
   initial action from the other party.  The Responder must first
   receive the encapsulation of its static public key generated by the
   Initiator to authenticate itself.  To perform this encapsulation, the
   Initiator must retrieve the static KEM public key of the Responder
   from the ID_CRED_R sent in Message 2.  As a result, the Responder
   cannot authenticate itself until Message 3 is processed, which
   contains the ct_R ciphertext necessary to derive the ss_R shared
   secret.  Then it cannot generate MAC_2 or authenticate itself until
   then.  Similarly, the Initiator cannot generate MAC_3 or authenticate
   itself before sending Message 3.  This highlights the main challenge
   in integrating KEM-based authentication method within the EDHOC
   handshake.

   To address this issue and maintain the same level of identity
   protection than EDHOC, against active attacks on the Initiator and
   passive attacks on the Responder, the credentials continue to be
   encrypted in Messages 2 and 3.  In message_2, the Responder’s



Pocero Fraile, et al.     Expires 27 April 2026                [Page 32]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   credentials are included in a ciphertext that is XORed with a key
   derived from the ephemeral shared secrets.  This construction
   provides identity protection against passive attacks on the
   Responder.  The credentials of the Initiator ( ID_CRED_I ) are
   encrypted using an AEAD algorithm to provide integrity protection,
   but not authentication, because the Initator’s shared secret is not
   yet available to prove its identity.  The encryption key is derived
   from a combination of both ephemeral KEM shared secret (ss_eph) and
   the Responder static KEM shared secret ( ss_R ), used to authenticate
   the Responder.  At this stage in the protocol, the specific
   encryption provided a form of weak forward secrecy, as the Initiator
   has not yet verify the static KEM public key of the Responder.
   However, the credentials are still protected against active attacks,
   as only the legitimate Responder, who possesses the corresponding
   private key ( sk_R ) is capable of deriving the session key and
   decrypting message_3.

   Furthermore, the protocol is extended with two additional messages
   (Messages 4 and 5) to enable both parties to:

   *  Prove possession of the final session key, ensuring key
      confirmation to the other party

   *  Ensure mutual authentication by explicitly authenticating
      themselves using the final session key, which incorporates all
      three shared secrets: the ephemeral KEM shared secret ( ss_eph )
      and the KEM shared secrets ss_I and ss_R used to authenticate the
      Initiator and Responder, respectively.

   *  Provide credential binding by including MAC_2 and MAC_3, ensuring
      the integrity and authenticity of the credentials exchanged in
      messages 2 and 3.



















Pocero Fraile, et al.     Expires 27 April 2026                [Page 33]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   In [RFC9528], the transcript hashes (THs) are constructed as an
   accumulative hash, combining previous TH values with the current
   plain-text message.  Each new plain-text message in the handshake is
   concatenated with the previous TH value, and the resulting hash forms
   the new TH.  This process links each message in the sequence to all
   prior messages, creating a verifiable and continuous chain.  As a
   result, any changes to the message content are detected during
   subsequent integrity verification using the transcript hashes.  The
   KEM-based authentication method described in this document extends
   this approach.  Both parties only need to verify the integrity and
   authenticity of the latest TH_4 and TH_5, which encompass all
   previous messages in the handshake.  To facilitate this, the MAC-
   protected data in Messages 4 and 5 is modified to include TH_4 and
   TH_5 respectively.  At the end of the handshake, both the Initiator
   and Responder can verify the integrity and authenticity of the entire
   handshake by checking the received MACs.

   The payload security properties for the static DH authentication
   method and the KEM-based authentication method differ during the
   handshake.  Unlike the static DH authentication method, the KEM-based
   method exhibits no authentication until the final two messages.  It
   provides the same level of destination confidentiality for the first
   two and the last two messages, while message_3 offers weaker forward
   secrecy.  The Initiator’s credentials are encrypted within message_3
   using a key derived from the Responder’s static public key and the
   ephemeral key, ensuring that only the intended Responder can decrypt
   the credential, and protect them against active attacks.

   Full forward secrecy and explicit mutual authentication are achieved
   once the KEM-based method handshake is completed, similar to the
   static-DH method handshake (described in Section 9.1 of [RFC9528]).
   Additionally, a potential misbinding attack will not be detected
   until the handshake concludes, specifically when the Initiator
   verifies Message 4 and the Responder verifies Message 5.  Therefore,
   EAD data should be treated as unprotected, and keying materials
   should not be persistently stored until the protocol is complete, as
   with the static-DH method (described in Section 9.1 of [RFC9528]).
   The final Application Session Key should only be derived at the end
   of the handshake, after ensuring mutual authentication, message
   handshake integrity, credentials authenticity, and proof of key
   possession.

   The KEM-based authentication method does not provide non-repudiation,
   but only implicit proof of participation, similar to EDHOC with
   static DH keys.  It also maintains an equivalent level of downgrade
   protection, as the negotiation base of the protocol is unchanged.





Pocero Fraile, et al.     Expires 27 April 2026                [Page 34]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   The proposed KEM-based authentication method with a 5-message
   handshake is designed to meet the same security requirements as
   static-DH method.  However, it can be adapted to reduce the number of
   round trips while remaining suitable for scenarios where neither
   party knows the other beforehand.  This is achieved by transmitting
   the ID_CRED_I credentials of the Initiator in plain-text within the
   message_1, similar to the Noise IX pattern, where the Initiator's
   static key is immediately transmitted to the Responder, despite or
   absent identity protection.  This modification allows the Initiator
   to authenticate itself in Message 2, eliminating the need for Message
   5.  Since the Responder includes its credentials in the first
   message, Message 4 remains necessary to ensure explicit
   authentication of the Responder.  This adaptation reduces the message
   exchange to four but sacrifices identity protection for the
   Initiator's credentials.

7.  References

7.1.  Normative References

   [I-D.ietf-lamps-kyber-certificates]
              Turner, S., Kampanakis, P., Massimo, J., and B.
              Westerbaan, "Internet X.509 Public Key Infrastructure -
              Algorithm Identifiers for the Module-Lattice-Based Key-
              Encapsulation Mechanism (ML-KEM)", Work in Progress,
              Internet-Draft, draft-ietf-lamps-kyber-certificates-11, 22
              July 2025, <https://datatracker.ietf.org/doc/html/draft-
              ietf-lamps-kyber-certificates-11>.

   [I-D.spm-lake-pqsuites]
              Selander, G. and J. P. Mattsson, "Quantum-Resistant Cipher
              Suites for EDHOC", Work in Progress, Internet-Draft,
              draft-spm-lake-pqsuites-01, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-spm-lake-
              pqsuites-01>.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <https://www.rfc-editor.org/info/rfc5116>.

   [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/info/rfc8392>.

   [RFC8742]  Bormann, C., "Concise Binary Object Representation (CBOR)
              Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
              <https://www.rfc-editor.org/info/rfc8742>.




Pocero Fraile, et al.     Expires 27 April 2026                [Page 35]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   [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/info/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/info/rfc9052>.

   [RFC9360]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Header Parameters for Carrying and Referencing X.509
              Certificates", RFC 9360, DOI 10.17487/RFC9360, February
              2023, <https://www.rfc-editor.org/info/rfc9360>.

   [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/info/rfc9528>.

7.2.  Informative References

   [I-D.celi-wiggers-tls-authkem]
              Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N.
              Sullivan, "KEM-based Authentication for TLS 1.3", Work in
              Progress, Internet-Draft, draft-celi-wiggers-tls-authkem-
              05, 22 April 2025, <https://datatracker.ietf.org/doc/html/
              draft-celi-wiggers-tls-authkem-05>.

   [I-D.ietf-pquip-pqc-engineers]
              Banerjee, A., Reddy.K, T., Schoinianakis, D., Hollebeek,
              T., and M. Ounsworth, "Post-Quantum Cryptography for
              Engineers", Work in Progress, Internet-Draft, draft-ietf-
              pquip-pqc-engineers-14, 25 August 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pquip-
              pqc-engineers-14>.

   [I-D.uri-lake-pquake]
              Blumenthal, U., Luo, B., O'Melia, S., Torres, G., and D.
              A. Wilson, "PQuAKE - Post-Quantum Authenticated Key
              Exchange", Work in Progress, Internet-Draft, draft-uri-
              lake-pquake-00, 22 April 2025,
              <https://datatracker.ietf.org/doc/html/draft-uri-lake-
              pquake-00>.

   [Noise]    Perrin, T., "The Noise Protocol Framework", Revision 34,
              July 2018, <https://noiseprotocol.org/noise.html>.




Pocero Fraile, et al.     Expires 27 April 2026                [Page 36]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   [PQNoise-CCS22]
              Angel, Y., Dowling, B., Hulsing, A., Schwabe, P., and F.
              Weber, "Post Quantum Noise", Proceedings of the 2022 ACM
              SIGSAC Conference on Computer and Communications Security
              (CCS '22), pages 97–109. Association for Computing
              Machinery, New York, NY, USA.  DOI:
              https://doi.org/10.1145/3548606.3560577, 2022,
              <https://doi.org/10.1145/3548606.3560577>.

   [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/info/rfc2119>.

   [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
              August 2022, <https://www.rfc-editor.org/info/rfc9053>.

   [RFC9794]  Driscoll, F., Parsons, M., and B. Hale, "Terminology for
              Post-Quantum Traditional Hybrid Schemes", RFC 9794,
              DOI 10.17487/RFC9794, June 2025,
              <https://www.rfc-editor.org/info/rfc9794>.

Appendix A.  Early Authentication Approach for Combined PQC KEM and
             Signature Authentication Methods

   To extend the pure KEM-based authentication between both parties with
   support for combinations where the Initiator and Responder use
   different mechanisms, combining KEM-based and signature-based
   authentication, an alternative approach can be considered.  In this
   early authentication approach, authentication is prioritized, and
   each party authenticates in the first message in which it is able to
   do so.  This enables authentication to occur as early as possible, in
   contrast to the message-flow-preserving approach defined in this
   document.
















Pocero Fraile, et al.     Expires 27 April 2026                [Page 37]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   When KEM-based authentication is used by both parties, the two
   approaches share the same message flow, as shown in Figure 4.  When
   the Initiator uses PQC signature-based authentication, it is able to
   authenticate its identity within message 3.  By using the early
   authentication approach, this avoids the need for message_5 and
   reduces the message flow to four mandatory messages, as shown in
   Figure 6.  On the other hand, when the Responder uses PQC signature-
   based authentication, the authentication trough signatures within
   message 2 does not reduce the number of mandatory messages, as shown
   in Figure 5.  However, both Method 5 and Method 6 can benefit from
   the early authentication approach, which allows the protocol to
   terminate early if authentication fails, enables early detection of
   misbinding attacks, and increases the level of authentication
   assurance provided by intermediate messages.

   The main drawback of the early authentication approach is the
   increased complexity associated with using different message formats
   and numbers of messages across the various authentication methods,
   which complicates protocol specifications and implementations.

   Priority has been given in this document to maintaining a simpler
   protocol specification with the same number of messages and a
   consistent format across the three authentication methods, since the
   benefits of lower complexity are considered more important than the
   marginal advantages provided by the early authentication approach.
   However, the advantages and disadvantages of both approaches should
   be further discussed within the LAKE Working Group to evaluate the
   pros and cons of each approach.























Pocero Fraile, et al.     Expires 27 April 2026                [Page 38]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   Initiator                                                   Responder
   |               METHOD, SUITES_I, pk_eph, C_I, EAD_1                |
   +------------------------------------------------------------------->
   |                             message_1                             |
   |                                                                   |
   |               ct_eph, Enc( C_R, ID_CRED_R, EAD_2 )                |
   <-------------------------------------------------------------------+
   |                             message_2                             |
   |                                                                   |
   |                   ct_R, AEAD( ID_CRED_I, EAD_3 )                  |
   +------------------------------------------------------------------->
   |                             message_3                             |
   |                                                                   |
   |                     ct_I, AEAD( EAD_4, MAC_2 )                    |
   <-------------------------------------------------------------------+
   |                             message_4                             |
   |                                                                   |
   |                         AEAD( EAD_5, MAC_3 )                      |
   +------------------------------------------------------------------->
   |                             message_5                             |

     Figure 4: EDHOC Message Flow for KEM-based Authentication on both
                     Initiator and Responder (Method 4)

   Initiator                                                   Responder
   |               METHOD, SUITES_I, pk_eph, C_I, EAD_1                |
   +------------------------------------------------------------------->
   |                             message_1                             |
   |                                                                   |
   |               ct_eph, Enc( C_R, ID_CRED_R, sig, EAD_2 )           |
   <-------------------------------------------------------------------+
   |                             message_2                             |
   |                                                                   |
   |                     AEAD( ID_CRED_I, EAD_3 )                      |
   +------------------------------------------------------------------->
   |                             message_3                             |
   |                                                                   |
   |                          ct_I, AEAD( EAD_4)                       |
   <-------------------------------------------------------------------+
   |                             message_4                             |
   |                                                                   |
   |                         AEAD( EAD_5, MAC_3 )                      |
   +------------------------------------------------------------------->
   |                             message_5                             |

      Figure 5: EDHOC Message flow for KEM-based authentication on the
     Initiator and PQC signature-based authentication on the Responder
                                 (Method 5)



Pocero Fraile, et al.     Expires 27 April 2026                [Page 39]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


  Initiator                                                   Responder
  |               METHOD, SUITES_I, pk_eph, C_I, EAD_1                |
  +------------------------------------------------------------------->
  |                             message_1                             |
  |                                                                   |
  |               ct_eph, Enc( C_R, ID_CRED_R, EAD_2 )                |
  <-------------------------------------------------------------------+
  |                             message_2                             |
  |                                                                   |
  |                   ct_R, AEAD( ID_CRED_I, sig, EAD_3 )              |
  +------------------------------------------------------------------->
  |                             message_3                             |
  |                                                                   |
  |                      AEAD( EAD_4, MAC_2 )                         |
  <-------------------------------------------------------------------+
  |                             message_4                             |

           Figure 6: EDHOC Message flow for PQC signature-based
     authentication on the Initiator and KEM-based authentication on
                         the Responder (Method 6)

Authors' Addresses

   Lidia Pocero Fraile
   ISI, R.C. ATHENA
   Cyber-physical and Networked Embedded Systems
   26504 Patras
   Greece
   Email: pocero@isi.gr


   Christos Koulamas
   ISI, R.C. ATHENA
   Cyber-physical and Networked Embedded Systems
   26504 Patras
   Greece
   Email: koulamas@isi.gr


   Apostolos P. Fournaris
   ISI, R.C. ATHENA
   Security and Protection of Systems, Networks and Infrastructures
   26504 Patras
   Greece
   Email: fournaris@isi.gr






Pocero Fraile, et al.     Expires 27 April 2026                [Page 40]

Internet-Draft     KEM-based Authentication for EDHOC       October 2025


   Evangelos Haleplidis
   ISI, R.C. ATHENA
   Department of Digital Systems
   26504 Patras
   Greece
   Email: haleplidis@isi.gr













































Pocero Fraile, et al.     Expires 27 April 2026                [Page 41]


