Lightweight Authenticated Key Exchange Y. Song Internet-Draft Inria Intended status: Standards Track G. Selander Expires: 6 May 2027 Ericsson AB 2 November 2026 Remote attestation over EDHOC draft-ietf-lake-ra-07 Abstract This document specifies methods to perform remote attestation as part of the lightweight authenticated 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 6 May 2027 [Page 1] Internet-Draft RA-EDHOC November 2026 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 6 May 2027. Copyright Notice Copyright (c) 2026 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 4.1. Reuse of EDHOC . . . . . . . . . . . . . . . . . . . . . 7 5. EAD Items for Remote Attestation over EDHOC . . . . . . . . . 7 5.1. Background-Check Model (BG) . . . . . . . . . . . . . . . 7 5.1.1. trigger_bg . . . . . . . . . . . . . . . . . . . . . 8 5.1.2. Attestation_proposal . . . . . . . . . . . . . . . . 8 5.1.3. Attestation_request . . . . . . . . . . . . . . . . . 9 5.1.4. Evidence . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Passport Model (PP) . . . . . . . . . . . . . . . . . . . 12 5.2.1. trigger_pp . . . . . . . . . . . . . . . . . . . . . 13 5.2.2. Result_proposal . . . . . . . . . . . . . . . . . . . 14 5.2.3. Result_request . . . . . . . . . . . . . . . . . . . 14 5.2.4. Result . . . . . . . . . . . . . . . . . . . . . . . 15 6. Instantiation of Remote Attestation over EDHOC . . . . . . . 15 6.1. (I, BG): EDHOC Initiator Attestation in the Background-check Model . . . . . . . . . . . . . . . . . 16 6.2. (R, PP): EDHOC Responder Attestation in the Passport Model . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.3. (R, BG): EDHOC Responder Attestation in the Background-check Model . . . . . . . . . . . . . . . . . 19 6.4. (I, PP): EDHOC Initiator Attestation in the Passport Model . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Song & Selander Expires 6 May 2027 [Page 2] Internet-Draft RA-EDHOC November 2026 7. Mutual Attestation in EDHOC . . . . . . . . . . . . . . . . . 23 7.1. (I, BG) - (R, PP) . . . . . . . . . . . . . . . . . . . . 23 8. Verifier . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Processing in the Background-Check Model . . . . . . . . 25 8.2. Processing in the Passport Model . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10.1. EDHOC External Authorization Data Registry . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . . 28 11.2. Informative References . . . . . . . . . . . . . . . . . 29 Appendix A. Example: Device Onboarding: Firmware Version Check . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Appendix B. Re-attestation . . . . . . . . . . . . . . . . . . . 33 B.1. Intra-handshake Re-attestation using EDHOC Resumption with PSK . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 B.2. Post-handshake Re-attestation using OSCORE . . . . . . . 34 B.2.1. Flight 1 . . . . . . . . . . . . . . . . . . . . . . 34 B.2.2. Flight 2 . . . . . . . . . . . . . . . . . . . . . . 34 B.2.3. Flight 3 . . . . . . . . . . . . . . . . . . . . . . 35 B.3. Differences between Intra-handshake and Post-handshake Attestation . . . . . . . . . . . . . . . . . . . . . . . 35 B.3.1. Performance properties . . . . . . . . . . . . . . . 35 B.3.2. Security properties . . . . . . . . . . . . . . . . . 35 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman over COSE (EDHOC) [RFC9528], developed for highly constrained networks, has formally proven security properties for protecting against network adversaries, but, like other authenticated key exchange protocols, lacks inherent mechanisms for validating endpoint security. Remote attestation is a security process that 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, e.g., before allowing the device to 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 Remote ATtestation procedureS (RATS) architecture [RFC9334] defines three main roles: the Attester, the Verifier and the Relying Party. The Attester generates evidence (a set of claims) concerning Song & Selander Expires 6 May 2027 [Page 3] Internet-Draft RA-EDHOC November 2026 its identity and integrity, which must be appraised by the Verifier for its validity. The Verifier produces the attestation result, which is subsequently 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. In this case, the Attester conveys evidence 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 the 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 embeds the protocol between the Attester and the Relying Party within the EDHOC protocol. 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 scope. The establishment of a secure association and communication security with the Verifier may be provided by EDHOC/OSCORE, TLS, or other security protocols that support secure message exchange. One way of conveying the attestation evidence or the attestation result is by means of an 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. In EDHOC, the two parties involved in the key exchange are referred to as the Initiator (I) and the Responder (R). EDHOC provides mutual authentication between I and R, forward secrecy, identity protection, message integrity, and other security properties. EDHOC supports the transport of External Authorization Data (EAD), through dedicated protocol fields containing so-called EAD items, see Section 3.8 of [RFC9528]. This specification defines new EAD items including EATs for performing remote attestation over EDHOC in the Background Check Model (BG, see Section 5.1) and in the Passport Model (PP, see Section 5.2). The EAD items are included in the EDHOC message integrity verification and key derivation, and thus attestation data becomes part of the security protocol data verified and used in an EDHOC session. Song & Selander Expires 6 May 2027 [Page 4] Internet-Draft RA-EDHOC November 2026 For the generation of evidence, the Attester invokes 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. This document defines attestation binders including EDHOC data in evidence, thus binding the measurements to the EDHOC session. 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. 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], RATS architecture [RFC9334] and CBOR [RFC8949]. 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. This document supports all four LAKE authentication methods defined in [RFC9528], as well as the PSK-based authentication method defined in [I-D.ietf-lake-edhoc-psk]. 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. Song & Selander Expires 6 May 2027 [Page 5] Internet-Draft RA-EDHOC November 2026 The Attester can act as either the EDHOC Initiator or the EDHOC Responder, depending on the attesting target. In the Background- Check (BG) Model, the Attester provides the evidence to the Relying Party during the EDHOC session. In the Passport (PP) Model, the Attester provides the attestation result to the Relying Party during the EDHOC session. Section 5 defines two independent dimensions for performing remote attestation over EDHOC: 1. Target: Defining the entity that is attested (EDHOC Initiator or EDHOC Responder), which could be a constrained device or not. 2. Model: Defining the attestation model in use based on the RATS architecture (BG or PP model, see Section 5.1 and Section 5.2). This document focuses on cases that are suited for constrained IoT environments, see [I-D.ietf-iotops-7228bis] for a characterization of constrained nodes and networks. When transferred over CoAP [RFC7252], the EDHOC protocol can be performed according to 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 are supported to perform remote attestation. 4. Assumptions In the BG 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 and is trusted to select an evidence type according to the applicable deployment policy. The Relying Party may narrow down the evidence type selection and send to the Attester only one format of the evidence type. In the PP model, the authentication credential of the Verifier is assumed to be stored at the Attester and the Relying Party. Also, the Attester and the Relying Party consider the Verifier a trusted source of the issued attestation result that they obtain. If timestamps are used to ensure freshness in the PP model, synchronized time between the Attester and Relying Party is assumed. For detailed time considerations, refer to Appendix A of [RFC9334]. If a nonce is used to ensure freshness, the device that generates the nonce is assumed to be able to generate a random byte string that is not predictable. Song & Selander Expires 6 May 2027 [Page 6] Internet-Draft RA-EDHOC November 2026 4.1. Reuse of EDHOC This specification reuses several components of EDHOC. * EAD is the External Authorization Data message field of EDHOC messages, see Section 3.8 of [RFC9528]. This specification specifies four new EAD items in BG model, and four new EAD items in PP model. See Section 5. * ID_CRED_I is used to identify the authentication credential of the Initiator in the authentication session. * The EDHOC hash algorithm of the selected cipher suite is used to generate the attestation_binder_m3 (see Section 5.1.4.1) when Evidence is sent in EDHOC message_3. * EDHOC_Exporter is used to generate the attestation_binder_m4 (see Section 5.1.4.1) when Evidence is sent in EDHOC message_4. 5. EAD Items for Remote Attestation over EDHOC This section specifies the EAD items and related processing for remote attestation over EDHOC in the BG model (see Section 5.1) and the PP model (see Section 5.2). The corresponding EAD items for the BG and PP models are independent. 5.1. Background-Check Model (BG) In the BG model, the Attester sends the evidence to the Relying Party. Evidence contains a set of claims about the current status of the Attester, including configurations, health, or construction that have security relevance (see Section 8.1 of [RFC9334]). 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. Song & Selander Expires 6 May 2027 [Page 7] Internet-Draft RA-EDHOC November 2026 A nonce, at least 8 bytes long [RFC9711], is required to guarantee the freshness of the attestation procedure. The nonce is generated by the Verifier and sent to the Relying Party. The Relying Party includes the nonce in the same Attestation request sent to the Attester, together with the selected evidence type. 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. The EAD item Remote Attestation BG with ead_label TBD1 conveys a different ead_value depending on the EDHOC message where the EAD item is included, and depending on who takes the initative: the Attester or the Relying Party. The four different ead_values are: Attestation_proposal (Section 5.1.2), Attestation_request (Section 5.1.3), Evidence (Section 5.1.4), and trigger_bg (Section 5.1.1). The Background-Check Model can be started by the Attester by including the Attestation_proposal in message_1, followed by the Attestation_request in message_2, and the Evidence in message_3 (see Section 6.1). Alternatively, the Relying Party can trigger the Attester by including the trigger_bg in message_1, followed by the Attestation_proposal in message_2, the Attestation_request in message_3, and the Evidence in message_4 (see Section 6.3). 5.1.1. trigger_bg The Relying Party can trigger the Attester to start a remote attestation in the Background-Check Model. The EAD item Remote Attestation BG for the trigger is: * ead_label = TBD1 * ead_value = trigger_bg, which is the CBOR simple value ´true´ (trigger_bg = 0xF5). The EAD value trigger_bg can only be carried in EDHOC message_1. The Attester MUST respond with an EAD item Remote Attestation BG with ead_value Attestation_proposal in EDHOC message_2. 5.1.2. Attestation_proposal The Attester indicates to the Relying Party its proposal to do remote attestation, together with the Proposed_EvidenceType object that specifies which types of attestation claims the Attester supports. The Proposed_EvidenceType is encoded in CBOR in the form of a sequence (see [RFC8742]). Song & Selander Expires 6 May 2027 [Page 8] Internet-Draft RA-EDHOC November 2026 The EAD item Remote Attestation BG for an attestation proposal is: * ead_label = TBD1 * ead_value = Attestation_proposal, which is a CBOR byte string: Attestation_proposal = bstr .cborseq Proposed_EvidenceType ;This defines an array, the elements of which are ;to be used in the CBOR Sequence Proposed_EvidenceType: Proposed_EvidenceType = [ + content-format ] content-format = uint where * Proposed_EvidenceType is a CBOR sequence of an array that carries 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]. 5.1.3. 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 previous message with an error indicating support for another evidence type. The EAD item Remote Attestation BG for an attestation request is: * ead_label = TBD1 * ead_value = Attestation_request, which is a CBOR byte string: Song & Selander Expires 6 May 2027 [Page 9] Internet-Draft RA-EDHOC November 2026 Attestation_request = bstr .cborseq Selected_EvidenceType ;This defines an array, the elements of which are ;to be used in the CBOR Sequence Selected_EvidenceType: Selected_EvidenceType = [ content-format: uint, nonce: bstr .size (8..64) ] where * content-format is the evidence type selected by the Relying Party and supported by the Verifier. * nonce is generated by the Verifier and forwarded by the Relying Party. 5.1.4. Evidence The Attester calls its local attestation service to generate and return a serialized Entity Attestation Token (EAT) [RFC9711] as Evidence. The EAD item Remote Attestation BG is: * ead_label = TBD1 * ead_value is the serialization of a COSE_Sign1 structure protecting the EAT. For remote attestation over EDHOC, the EAT MUST be formatted as a CBOR Web Token (CWT) [RFC8392] containing attestation-oriented claims. The complete set of attestation claims for the EAT is specified in [RFC9711]. An example is provided in Appendix A. A minimal claims set is defined as the payload of COSE_Sign1 when the Attester operates under constrained message size requirements and/or limited computational resources: Song & Selander Expires 6 May 2027 [Page 10] Internet-Draft RA-EDHOC November 2026 minimal-claim-set = { 10 => bstr .size (8..64) ;eat_nonce 256 => bstr .size (7..33) ;ueid 273 => measurements-type ;measurements } measurements-type = [+ measurements-format] measurements-format = [ content-format: uint, content: bytes ] where * eat-nonce is the nonce generated by the Verifier (see Section 5.1.3), which is included by the Attester within the Evidence. * The "measurements" claim could be a CoSWID [RFC9393], a CoRIM [I-D.ietf-rats-corim] or other claim formats, and MUST be identified by CoAP Content Format. An example as CoSWID is shown in Appendix A. 5.1.4.1. Attestation binder The signing of the Evidence MUST also take as input an attestation binder, see Section 9. The Relying Party has to provide the Verifier with the Evidence together with the attestation binder, which is needed for verifying the EAT signature. When Evidence is sent in EDHOC message_3 in EAD_3, the attestation binder is computed using HKDF-Expand defined in [RFC5869]. attestation_binder_m3 = HKDF-Expand(0, attest_info, hash_length) attest_info = [ H_12, "attestation", ID_CRED_I ] H_12 = H(H(message_1), message_2) where * 0 denotes an all-zero byte string of length hash_length used as the PRK input to HKDF-Expand. * hash_length is the length in bytes of the output of the EDHOC hash algorithm of the selected cipher suite. Song & Selander Expires 6 May 2027 [Page 11] Internet-Draft RA-EDHOC November 2026 * attest_info is a CBOR array containing H_12, the text string "attestation" and ID_CRED_I. * H() is the EDHOC hash algorithm of the selected cipher suite. When Evidence is sent in EDHOC message_4, the attestation binder is derived using EDHOC_Exporter defined in [RFC9528]. attestation_binder_m4 = EDHOC_Exporter (exporter_label, context, length) where * exporter_label = 2 * context = "attestation" * length is the length in bytes of the output of the EDHOC hash algorithm of the selected cipher suite. The signature in COSE_Sign1 is computed over a Sig_structure containing protected header, externally supplied data (external_aad) and payload using a private attestation key. The COSE Unprotected Header is empty. The message to be signed is: [ "Signature1", body_protected, external_aad, payload ] where * body_protected is the same CBOR byte string as the protected header in COSE_Sign1 * external_aad is set to attestation_binder_m3 when Evidence is carried in EDHOC message_3, and to attestation_binder_m4 when Evidence is carried in EDHOC message_4 * payload is the same CBOR byte string as the payload in COSE_Sign1 5.2. 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 attestation result is a set of claims generated by the Verifier following the appraisal of Evidence, as defined in [RFC9334]. It may contain a claim with a boolean value indicating compliance or non-compliance with the Verifier's appraisal policy, or multiple claims describing the appraisal results in different aspects. Song & Selander Expires 6 May 2027 [Page 12] Internet-Draft RA-EDHOC November 2026 An EDHOC session is established between the Attester and the Relying Party. The Attester and the Relying Party should decide from which Verifier the Attester obtains the attestation result before transferring it to the Relying Party. The Attester first sends a list of the Verifier identities that it can get the attestation result from. The Relying Party selects one trusted Verifier identity and sends it back within a Result request. 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 item Remote Attestation PP with ead_label TBD2 conveys a different ead_value depending on the EDHOC message where the EAD item is included, and depending on who takes the initative: the Attester or the Relying Party. The four different ead_values are: Result_proposal (Section 5.2.2), Result_request (Section 5.2.3), Result (Section 5.2.4), and trigger_pp (Section 5.2.1). The Passport Model can be started by the Attester by including the Result_proposal in message_1, followed by the Result_request in message_2, and the Result in message_3 (see Section 6.4). Alternatively, the Relying Party can trigger the Attester by including the trigger_pp in message_1, followed by the Result_proposal in message_2, the Result_request in message_3, and the Result in message_4 (see Section 6.2). 5.2.1. trigger_pp The Relying Party can trigger the Attester to start a remote attestation in the Passport Model. The EAD item Remote Attestation PP for the trigger is: * ead_label = TBD2 * ead_value = trigger_pp, which is the CBOR simple value ´true´ (trigger_pp = 0xF5). The EAD value trigger_pp can only be carried in EDHOC message_1. The Attester MUST respond with an EAD item Remote Attestation PP with ead_value Result_proposal in EDHOC message_2. Song & Selander Expires 6 May 2027 [Page 13] Internet-Draft RA-EDHOC November 2026 5.2.2. Result_proposal An attestation result proposal contains the identification of the credentials of the Verifiers to indicate Verifiers' identities. The identification of credentials relies on COSE header parameters [IANA-COSE-Header-Parameters], with a header label and credential value. The EAD item Remote Attestation PP 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 => any } label = int / tstr where * Proposed_VerifierIdentity is defined as a list of one or more VerifierIdentity elements. * label corresponds to a COSE header parameter as defined in [IANA-COSE-Header-Parameters], such as kid (4) or x5t (34). Profiles using this specification MUST specify which label values are acceptable. 5.2.3. 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. The EAD item Remote Attestation PP for an attestation result request is: * ead_label = TBD2 * ead_value = Result_request, which is a CBOR byte string: Song & Selander Expires 6 May 2027 [Page 14] Internet-Draft RA-EDHOC November 2026 Result_request = bstr .cbor Request_structure Request_structure = { selected_verifier: VerifierIdentity, ? nonce: bstr .size (8..64) } The nonce is optional and depends on whether the Relying Party requires an attestation result based on a real-time interaction with the Verifier. If the Relying Party can accept and evaluate a cached attestation result with a timestamp, the nonce does not need to be included in the result request. Otherwise, the Relying Party generates a random nonce and sends it to the Attester. The Attester must forward the nonce together with the evidence to the Verifier, which must include the nonce in the Attestation Result that it produces and provides to the Attester. 5.2.4. Result The attestation result is generated and signed by the Verifier as a serialized EAT [RFC9711], and MUST be protected using a COSE_Sign1 structure. The Relying Party can decide what action to take with regard to the Attester based on the information elements in attestation result. The EAD item Remote Attestation PP is: * ead_label = TBD2 * ead_value is the serialization of a COSE_Sign1 structure protecting the EAT. 6. Instantiation of Remote Attestation over EDHOC In this section we show four different instantiations of remote attestation carried over EDHOC between Attester and Relying Party. In each instantiation, one of the EDHOC peers are assumed to be constrained and/or access over a constrained network, and only have one network interface, over which the EDHOC protocol is executed. The four examples illustrate the constrained node being EDHOC Initiator/Responder and RATS Attester/Relying Party. We use the format (Target, Model) to denote the instantiation. In particular: * I means that the EDHOC Initiator is the Attester. * R means that the EDHOC Responder is the Attester. Song & Selander Expires 6 May 2027 [Page 15] Internet-Draft RA-EDHOC November 2026 * BG denotes the Background-Check Model. * PP denotes the Passport Model. For example, (I, BG) represents the Initiator as an Attester performing attestation using the Background-Check Model. The four possible instantiations are therefore: (I, BG), (R, PP), (R, BG), and (I, PP). In the remainder of this section we provide examples of these instantiations, starting with two instances of constrained Initiator followed by two instances of constrained Responder. 6.1. (I, BG): EDHOC Initiator Attestation in the Background-check Model In this instantiation, the constrained EDHOC Initiator acts as the RATS Attester and the EDHOC Responder acts as the RATS Relying Party. An overview of EDHOC Initiator attestation in the Background-Check Model is illustrated in Figure 1. The Attester and the Relying Party communicate by transporting messages within EDHOC External Authorization Data (EAD) fields. An external entity plays the role of the RATS Verifier (V). The EAD items specific to the Background- Check Model are defined in Section 5.1. 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(s) and nonce from the Verifier, and sends an Attestation request to the Attester. The Attester generates the Evidence with the nonce embedded and generates the EAT signature with the attestation binder as an input, then sends the Evidence to the Relying Party in EAD_3. The Relying Party computes the attestation binder and forwards the Evidence together with the attestation binder to the Verifier. The Verifier evaluates the Evidence and sends the Attestation result to the Relying Party. A common use case for (I, BG) is to attest an IoT device (EDHOC Initiator) to a network server (EDHOC Responder). For example, a simple illustrative example is the performance of 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 A). Song & Selander Expires 6 May 2027 [Page 16] Internet-Draft RA-EDHOC November 2026 +--------------------------------+ +-------------------+ | Constrained EDHOC Initiator | | EDHOC Responder | +--------------------------------+ +-------------------+ +----------+ | Attestation Service | Attester | | Relying Party | | Verifier | +--+------------------------+----+ +---------+---------+ +-----+----+ | | | | | | | | | | EDHOC message_1 | | | +----------------------------->| | | | EAD_1 = Attestation_proposal | | | | { types(a,b,c) } | | | | | Body: { types(a,b,c) } | | | +---------------------------->| | | | | | | | Body:{ types(a,b), nonce } | | | |<----------------------------+ | | EDHOC message_2 | | | |<-----------------------------+ | | | EAD_2 = Attestation_request | | | | { types(a), nonce } | | | | | | | type(a), nonce, | | | | attestation binder | | | |<-------------------+ | | | | | | | Evidence (EAT) | | | +------------------->| | | | | EDHOC message_3 | | | +----------------------------->| | | | EAD_3 = Evidence | | | | { EAT } | | | | | | | | | Body:{ EAT, | | | | attestation binder } | | | +---------------------------->| | | | Body:{ att-result: AR{} } | | | |<----------------------------+ | | +---. | | | | | verify AR{} | | | |<--' | | | application data | | | |<============================>| | | | | | Figure 1: Overview of EDHOC Initiator attestation in the Background-Check Model. EDHOC is used between A and RP. Song & Selander Expires 6 May 2027 [Page 17] Internet-Draft RA-EDHOC November 2026 6.2. (R, PP): EDHOC Responder Attestation in the Passport Model In this instantiation, the constrained EDHOC Initiator acts as the RATS Relying Party and the EDHOC Responder acts as the RATS Attester. An overview of the message flow is illustrated in Figure 2. The EAD items specific to the Passport Model are defined in Section 5.2. The Relying Party asks the Attester to do a remote attestation by sending a trigger_pp (see Section 5.2.1) 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. One use case for (R, PP) is when a network server (EDHOC Responder) needs to attest itself to a client (e.g., an IoT device (EDHOC Initiator)). For example, the client needs to send some sensitive data to the network server, which requires the network server to be attested first. Song & Selander Expires 6 May 2027 [Page 18] Internet-Draft RA-EDHOC November 2026 +-----------------------------+ +-----------------+ | Constrained EDHOC Initiator | | EDHOC Responder | +-----------------------------+ +-----------------+ +--------------+ | Relying Party | | Attester | | Verifier (2) | +--------------+--------------+ +--------+--------+ +-------+------+ | | | | EDHOC message_1 | | +------------------------------->| | | EAD_1 = trigger_pp | | | | | | EDHOC message_2 | | |<-------------------------------+ | | EAD_2 = Result_proposal | | | { Verifier(1,2,3) } | | | | | | EDHOC message_3 | | +------------------------------->| | | EAD_3 = Result_request | | | { Verifier(2), nonce } | | | | Evidence + nonce | | +--- --- --- --- --- -->| | | Result | | |<--- --- --- --- --- --+ | EDHOC message_4 | | |<-------------------------------+ | | EAD_4 = Result | | | { EAT } | | | | | Figure 2: Overview of EDHOC Responder attestation in the Passport Model. EDHOC is used between RP and A. The dashed line illustrates a logical connection that does not need to occur in real time. 6.3. (R, BG): EDHOC Responder Attestation in the Background-check Model In this instantiation, the constrained EDHOC Responder acts as the RATS Attester and the EDHOC Initiator acts as the RATS Relying Party. An overview of the message flow is illustrated in Figure 3. The EAD items specific to the Background-Check Model are defined in Section 5.1. The Relying Party initiates the procedure by sending trigger_bg in EAD_1 of message_1. The Attester responds with an Attestation proposal in EAD_2 of message_2, indicating the evidence types it can provide. The Relying Party forwards this proposal to the Verifier, which selects its supported evidence types and provides a nonce. The Relying Party then sends an Attestation request in EAD_3 of Song & Selander Expires 6 May 2027 [Page 19] Internet-Draft RA-EDHOC November 2026 message_3, which contains the nonce generated from the Verifier. Upon receipt of the Attestation request, the Attester generates the Evidence with the nonce embedded and generates the EAT signature with the attestation binder as an input. Evidence is carried in EAD_4 of message_4. The Relying Party forwards the Evidence to the Verifier together with the attestation binder and receives an Attestation result. Note that this is a post-handshake attestation since EDHOC completes the authenticated key exchange after message_3. Therefore, the attestation binder in this instantiation is derived using EDHOC_Exporter (see Section 5.1.4.1). Song & Selander Expires 6 May 2027 [Page 20] Internet-Draft RA-EDHOC November 2026 +-------------------+ +--------------------------------+ | EDHOC Initiator | | Constrained EDHOC Responder | +----------+ +-------------------+ +--------------------------------+ | Verifier | | Relying Party | | Attester | Attestation Service | +----------+ +---------+---------+ +----+-------------------+-------+ | | | | | | EDHOC message_1 | | | +----------------------------->| | | | EAD_1 = trigger_bg | | | | | | | | | | | | EDHOC message_2 | | | |<-----------------------------+ | | | EAD_2 = Attestation_proposal | | | | { types(a,b,c) } | | | Body: { types(a,b,c) } | | | |<---------------------------+ | | | | | | | Body: { types(a,b), nonce }| | | +--------------------------->| | | | | EDHOC message_3 | | | +----------------------------->| | | | EAD_3 = Attestation_request | | | | { types(a), nonce } | | | | | types(a), nonce, | | | | attestation binder| | | |------------------>+ | | | | | | | Evidence (EAT) | | | |<------------------+ | | EDHOC message_4 | | | |<-----------------------------+ | | | EAD_4 = Evidence | | | | { EAT } | | | Body: { EAT, | | | | attestation binder }| | | |<---------------------------+ | | | | | | | Body: { att-result: AR{} } | | | +--------------------------->| | | | +---. | | | | | verify AR {} | | | |<--' | | | | | | | | application data | | | |<============================>| | | | | | Song & Selander Expires 6 May 2027 [Page 21] Internet-Draft RA-EDHOC November 2026 Figure 3: Overview of EDHOC Responder attestation in the Background-Check Model. EDHOC is used between A and RP. 6.4. (I, PP): EDHOC Initiator Attestation in the Passport Model In this instantiation, the EDHOC Initiator acts as the RATS Attester and the constrained EDHOC Responder acts as the RATS Relying Party. An overview of the message flow is illustrated in Figure 4. The EAD items specific to the Passport Model are defined in Section 5.2. The Attester initiates the procedure by sending a Result proposal in EAD_1 of message_1, indicating the Verifier identities it can communicate with. The Relying Party selects a Verifier and sends a Result request in EAD_2 of message_2, together with a nonce. The Attester interacts with the selected Verifier to obtain an Attestation Result. How the Attester negotiates with the selected Verifier to get the attestation result is out of scope of this specification. The Attester then returns the Result in EAD_3 of message_3, after which the Relying Party can decide whether to continue with EDHOC message_4 or application data exchange. +-----------------+ +-----------------------------+ | EDHOC Initiator | | Constrained EDHOC Responder | +--------------+ +-----------------+ +-----------------------------+ | Verifier (2) | | Attester | | Relying Party | +-------+------+ +--------+--------+ +--------------+--------------+ | | | | | EDHOC message_1 | | +-------------------------------->| | | EAD_1 = Result_proposal | | | { Verifier(1,2,3) } | | | | | | EDHOC message_2 | | |<--------------------------------+ | | EAD_2 = Result_request | | | { Verifier(2), nonce } | | Evidence + nonce | | |<-- --- --- --- --- ---+ | | Result | | +--- --- --- --- --- -->| EDHOC message_3 | | +-------------------------------->| | | EAD_3 = Result | | | { EAT } | | | | Figure 4: Overview of EDHOC Initiator attestation in the Passport Model. EDHOC is used between A and RP. Song & Selander Expires 6 May 2027 [Page 22] Internet-Draft RA-EDHOC November 2026 7. Mutual Attestation in EDHOC In this section we demonstrate mutual attestation over EDHOC combining the cases (I, BG), see Section 6.1, and (R, PP), see Section 6.2, which is potentially the most relevant mutual attestation example for constrained IoT environments. This demonstrates combined mutual authentication with mutual attestation at a reduced message overhead and number of round trips. 7.1. (I, BG) - (R, PP) In this example, the mutual attestation is performed in EDHOC forward message flow, by one IoT device attestation in the Background-Check Model and another network service attestation in the Passport Model. The process is illustrated in Figure 5. 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 the 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 6 May 2027 [Page 23] Internet-Draft RA-EDHOC November 2026 +-----------------------------+ +-----------------+ | Constrained 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), NonceI | | | EAD_2 = Attestation request, | | | | Result proposal | | | |<------------------------------------+ | | | | | | | | | | | EAD_3 = EvidenceI | | | | Result request (nonceR) | | | +------------------------------------>| | | | | | | | |EvidenceI, attestation binder| | | +---------------------------->| EvidenceR + nonceR | | +--- --- --- --- --- --- ----+ --- --- --- --- --- --->| | | | | | | Attestation result | | | |<----------------------------+ | | | | | | |<--- --- --- --- --- ---+ --- --- --- --- --- ---+ | | | Result (nonceR) | | EAD_4 = Result | | | |<------------------------------------+ | | | | | | Figure 5: Overview of mutual attestation of (I, BG) - (R, PP). EDHOC is used between A and RP. The dashed line illustrates a logical connection that does not need to occur in real time. Song & Selander Expires 6 May 2027 [Page 24] Internet-Draft RA-EDHOC November 2026 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 attestation. The evaluation policy employed by the Verifier 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 the EDHOC message carrying the Attestation_proposal (message_1 in (I, BG) or message_2 in (R, BG)) from the Attester, it extracts and transmits the Attestation proposal to the Verifier. If the Verifier does not support any evidence type for evaluation, it returns an empty list. Otherwise, alongside the selected evidence type, the Verifier generates a random nonce and sends both elements to the Relying Party. When the Relying Party receives the EDHOC message carrying the Evidence (message_3 in (I, BG) or message_4 in (R, BG)), it forwards the evidence and the attestation binder (see Section 5.1.4.1) to the Verifier for evaluation. The evidence evaluation process MUST include the signature verification, nonce validation, and comparison of measurement values against trusted reference values. An example evaluation procedure for evidence formatted as an Entity Attestation Token (EAT) protected by a COSE_Sign1 structure is as follows: 1. Decode the COSE_Sign1 structure and extract constituent components: headers, payload, signature. Song & Selander Expires 6 May 2027 [Page 25] Internet-Draft RA-EDHOC November 2026 2. Verify the signature using the Attester's attestation public key. The Verifier reconstructs the Sig_Structure, with the attestation binder as the external_aad. 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 but the attestation result is supposed to be still fresh and valid. 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 builds on EDHOC [RFC9528] and uses EDHOC EAD fields. 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 performed in parallel but does not interfere with the authentication flow. 3. The privacy and security properties of EDHOC are not changed. The general security and privacy considerations about EAD fields apply to this specification. The privacy protection provided to EAD depends on the selected EDHOC authentication method and the message in which the EAD is conveyed. 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 active Song & Selander Expires 6 May 2027 [Page 26] Internet-Draft RA-EDHOC November 2026 attackers. When included in EAD_1 or EAD_2, the EAD items defined in this document could reveal sensitive information about the Attester, due to their very specific purpose and conveyed information. The leaking of the data in EAD_1 and/or EAD_2 may be used by attackers for malicious purposes. For the four EDHOC authentication methods defined in [RFC9528], EAD_3 and EAD_4 are protected against both passive and active attackers. For the PSK-based authentication method defined in [I-D.ietf-lake-edhoc-psk], EAD_3 is protected against passive attackers and EAD_4 provides protection against both passive and active attackers. Attestation evidence may contain Personally Identifiable Information (PII) or other sensitive or confidential information about the Attester. Such information MUST only be conveyed in EAD fields that provide protection against both passive and active attackers. Therefore, when using the authentication methods defined in [RFC9528], attestation evidence containing such information MUST NOT be sent before message_3. When using the PSK-based authentication method defined in [I-D.ietf-lake-edhoc-psk], attestation evidence containing such information MUST NOT be sent before message_4. The risks discussed above are reduced where 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 against active attackers. Both the Attestation_request/ Result_request in EAD_3 and the Evidence/Result in EAD_4 are protected. For privacy considerations of remote attestation, refer to Section 11 of [RFC9334]. The combination of authenticated key exchange with remote attestation is an area in development in the IETF. Two distinct approaches have emerged: (1) intra-handshake attestation, where attestation is performed during the authenticated key exchange. (2) post-handshake attestation, where attestation occurs after authentication is complete. Here are some examples of differences between the two approaches: Intra-handshake attestation enables early endpoint verification prior to the authentication session being established, which allows early abort and prevents sessions with unattested peers. Post-handshake attestation enables the use of an exported authenticator available after authentication completion, which is a more clean interface between authentication and attestation. Song & Selander Expires 6 May 2027 [Page 27] Internet-Draft RA-EDHOC November 2026 This specification allows both approaches. The EDHOC Exporter is available after message_3 has been constructed, after which post- handshake attestation is possible. The attestation binder is intended to cryptographically bind the attestation to the authentication process and to ensure that the attester is the one which is participating in the EDHOC authentication, and, in particular, to prevent relay attacks whereby an attacker relays Evidence generated in a different session. 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)". +-------------------------------+-------+------------------------+-------------------+ | Name | Label | Description | Reference | +===============================+=======+========================+===================+ | Remote Attestation BG | TBD1 | Background Check Model | [[This document]] | | | | related information | | +-------------------------------+-------+------------------------+-------------------+ | Remote Attestation PP | TBD2 | Passport Model | [[This document]] | | | | related information | | +-------------------------------+-------+------------------------+-------------------+ Figure 6: 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, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Song & Selander Expires 6 May 2027 [Page 28] Internet-Draft RA-EDHOC November 2026 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, . [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [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, . [RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, DOI 10.17487/RFC9528, March 2024, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . 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-10, 6 July 2026, . [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-08, 6 July 2026, . [I-D.ietf-lake-edhoc-psk] Lopez-Perez, Selander, G., Mattsson, J. P., Marin-Lopez, R., and F. Lopez-Gomez, "LAKE Authenticated with Pre- Song & Selander Expires 6 May 2027 [Page 29] Internet-Draft RA-EDHOC November 2026 Shared Keys (PSKs)", Work in Progress, Internet-Draft, draft-ietf-lake-edhoc-psk-10, 5 October 2026, . [I-D.ietf-rats-corim] Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and W. Pan, "Concise Reference Integrity Manifest", Work in Progress, Internet-Draft, draft-ietf-rats-corim-12, 1 November 2026, . [IANA-CoAP-Content-Formats] "CoAP Content-Formats", n.d., . [IANA-COSE-Header-Parameters] "COSE Header Parameters", n.d., . [IANA.CWT.Claims] IANA, "CBOR Web Token (CWT) Claims", . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [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, . [RFC9393] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. Waltermire, "Concise Software Identification Tags", RFC 9393, DOI 10.17487/RFC9393, June 2023, . [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, . Song & Selander Expires 6 May 2027 [Page 30] Internet-Draft RA-EDHOC November 2026 Appendix A. Example: Device Onboarding: Firmware Version Check The goal in this device onboarding example is to verify that the firmware running on the device is the latest version, and is neither tampered with nor compromised. The objective of onboarding is both authentication and integrity verification. If either one is compromised, the objective fails. In particular, if the attestation private key is leaked, the device firmware can no longer be trusted, so the value of valid authentication is significantly reduced. In this example, 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 Evidence is protected by a COSE_Sign1 structure, where the payload of COSE_Sign1 contains the following claims: Song & Selander Expires 6 May 2027 [Page 31] Internet-Draft RA-EDHOC November 2026 { /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 Sig_structure to compute the signature of COSE_Sign1 is: Sig_structure = [ "Signature1", h'a10127', /ED25519 algorithm, same as the protected header in COSE_Sign1/ h'7b4c94f32a0e6db86d915a444f76525fc32912b2e07dd481a96f627ee98a110c', /attestation_binder_m3/ h'A30A48A29F62A4C6CDAAE519010047616161626263631901118182190102A50045746 16749440C00016F446F74426F74206669726D7761726502A2181F684174746573746572 18210103A11181A218187819706172746974696F6E302D6E72663532383430646B2E626 96E078201582006294F6806B9C685EEA795048579CFD02A0C025BC8B5ABCA42A19EA0EC 23E81A', /same as the payload in COSE_Sign1/ ] The complete resulting COSE object is: Song & Selander Expires 6 May 2027 [Page 32] Internet-Draft RA-EDHOC November 2026 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 together with the attestation_binder_m3 to the Verifier. Once the Verifier sends back the Attestation Result, the Relying Party can be assured of the version of the firmware that the device is running. Appendix B. Re-attestation The trust relationship established during the initial EDHOC exchange may become outdated over time due to changes in Attester state. To maintain a valid trust relationship, a peer may require updated assurance periodically. This section presents two re-attestation approaches: re-attestation during EDHOC resumption and re-attestation using OSCORE. Song & Selander Expires 6 May 2027 [Page 33] Internet-Draft RA-EDHOC November 2026 B.1. Intra-handshake Re-attestation using EDHOC Resumption with PSK Remote attestation can be applied during EDHOC session resumption using EDHOC-PSK, as defined in Section 6 of [I-D.ietf-lake-edhoc-psk]. This enables re-attestation without public key based authentication. B.2. Post-handshake Re-attestation using OSCORE Post-handshake attestation can be performed after an EDHOC session using Object Security for Constrained RESTful Environments (OSCORE) [RFC8613]. In such a case, EDHOC is specifically used to establish an OSCORE Security Context (see Appendix A.1 of [RFC9668]). OSCORE provides application-layer protection for RESTful message exchanges, for example the Constrained Application Protocol (CoAP), which can be used to carry attestation information. Post-handshake attestation decouples the attestation process from the initial handshake, enabling re-attestation throughout the session lifetime and guaranteeing the runtime integrity. B.2.1. Flight 1 The CoAP client (Attester) initiates attestation with a CoAP request where: * The request method is POST. * The Uri-path is "./well-known/attest". * The payload is the Attestation_proposal CBOR sequence, where Attestation_proposal is constructed as defined in Section 5.1.2. B.2.2. Flight 2 The CoAP server (Relying Party) receives the request, processes it as described in Section 5.1, and then prepares Attestation_request as defined in Section 5.1.3. The CoAP server replies with a CoAP response where: * The response code is 2.04 Changed. * The payload is the Attestation_request CBOR sequence, as defined in Section 5.1.3. Song & Selander Expires 6 May 2027 [Page 34] Internet-Draft RA-EDHOC November 2026 B.2.3. Flight 3 The CoAP client (Attester) receives the response, processes it as described in Section 5.1, and then generates the evidence. The CoAP client sends a CoAP request where: * The request method is POST. * The Uri-path is "./well-known/attest". * The payload is the Evidence CBOR sequence, as defined in Section 5.1.4. B.3. 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. B.3.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 allows the attestation process to be integrated independently, but it requires additional round trips. B.3.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 trust is established before the session begins. Post-handshake attestation guarantees the runtime integrity which can obtain dynamic measurements during device execution, and can be repeatedly performed throughout the session which has the continuous assurance. Song & Selander Expires 6 May 2027 [Page 35] Internet-Draft RA-EDHOC November 2026 Acknowledgments The authors would like to thank Thomas Fossati, Malisa Vucinic, Ionut Mihalcea, Muhammad Usama Sardar, Michael Richardson, Geovane Fedrecheski, John Mattsson and Marco Tiloca 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 Göran Selander Ericsson AB Email: goran.selander@ericsson.com Song & Selander Expires 6 May 2027 [Page 36]