]> Inria

yuxuan.song@inria.fr

Ericsson AB

goran.selander@ericsson.com

Security Lightweight Authenticated Key Exchange Internet-Draft 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Lightweight Authenticated Key Exchange Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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 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 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) . 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) 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 and . 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.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The reader is assumed to be familiar with the terms and concepts defined in EDHOC and RATS architecture .

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 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 defines three independent dimensions for performing remote attestation over EDHOC:

1. Target (see , ) defining the entity that undergoes the attestation process (IoT device or network service).
2. Model (see , ) defining the attestation model in use based on the RATS architecture (background-check model or passport model).
3. Message Flow (see , ) defining the EDHOC message flow in use (forward message flow or reverse message flow).

This document specifies the cases that are suited for constrained IoT environments. See this document 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.

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 .

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 ) and the passport model (see ). The corresponding EAD items for background-check model and the passport model are independent of each other.
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 ). In this specification, both flows can be used to perform remote attestation.

Target: IoT Device Attestation (IoT) The IoT device acts as the Attester.

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.

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 ), 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. 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.

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:

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 .

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 .

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:

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 .

Evidence The Attester calls its local attestation service to generate and return a serialized Entity Attestation Token (EAT) 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.

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 . A minimal claims set MAY be implemented when the Attester operates under constrained message size requirements and/or limited computational resources. The measurements claim MAY be formatted according to . When CoSWID 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.

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

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

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 that:
  • label = int / tstr
  • values = any

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 The attestation result is generated and signed by the Verifier as a serialized EAT . 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.

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 or a result in . The ead_value MUST not be present, as the ead_label serves as the trigger. The EAD item is:

• ead_label = TBD3
• ead_value = null

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

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.

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.

(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 ). An overview of doing IoT device attestation in background-check model and EDHOC forward message flow is established in . 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 scope of this specification, plays the role of the RATS Verifier (V). The EAD items specific to the background-check model are defined in . 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.

Overview of IoT device attestation in background-check model and EDHOC forward message flow. EDHOC is used between A and RP. | | | | | | | Attestation proposal | | +-------------------------->| | |<--------------------------+ | | EvidenceType(s), Nonce | | | | | EAD_2 = Attestation request | | |<-------------------------------+ | | | | | EAD_3 = Evidence | | +------------------------------->| | | | Evidence | | +-------------------------->| | |<--------------------------+ | | Attestation result | | | | | | | | | | | <----------------------------> | | | EDHOC session | | ]]>

(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 . 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 . The Relying Party asks the Attester to do a remote attestation by sending a trigger_pp (see ) 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.

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. | | | | | | EAD_2 = Result proposal | | |<---------------------------+ | | | | | EAD_3 = Result request | | +--------------------------->| Evidence + Nonce | | +--- --- --- --- --- -->| | |<--- --- --- --- --- --+ | | Result | | EAD_4 = Result | | |<---------------------------+ | | | | | | | | | | | <------------------------> | | | EDHOC session | | ]]>

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.

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

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

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.

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

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 , and incorporates the nonce generated by the Relying Party as an input parameter.

Security Considerations This specification is performed over EDHOC 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.

IANA Considerations

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 , Attestation_request in and Evidence in .
• The ead_label = TBD2 corresponds to the ead_value Result_proposal in , Result_request in and the Result in .
• The ead_label = TBD3 corresponds to the EAT item trigger_pp as specified in .

EAD labels.

References Normative References An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. Universität Bremen TZI Ericsson Universitat Politecnica de Catalunya The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. IANA n.d. Ericsson AB Ericsson AB INRIA INRIA Sandelman Software Works Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol intended for use in constrained scenarios. This document specifies Lightweight Authorization using EDHOC (ELA). The procedure allows authorizing enrollment of new devices using the extension point defined in EDHOC. ELA is applicable to zero-touch onboarding of new devices to a constrained network leveraging trust anchors installed at manufacture time. n.d.

Example: Remote Attestation Flow

Example of remote attestation. | | | | | | | | | types(a,b,c) | | | +------------------>| | | | | | | | | | | | Body: { | | | | nonce, | | | EDHOC message_2 | types(a,b) | | | {...} | } | | | EAD_2( |<------------------+ | | 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 | | | |<---------------------->| | | | | | ]]>

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 . In this case, the message count is much decreased. The detailed procedure is TBD.

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: 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. The Evidence in EAD_3 field is an Entity Attestation Token (EAT) , with the measurements claim formatted in CoSWID. The components of the Evidence should at least be: The infomation above serves as the payload of the COSE object. The complete resulting COSE object is: which has the following base16 encoding: 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.

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) . OSCORE provides application-layer protection for the Constrained Application Protocol (CoAP) using CBOR Object Signing and Encryption (COSE). As specified in , 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.

Mapping Attestation to OSCORE This section outlines how remote attestation is performed in the background-check model over OSCORE. EDITOR NOTE: put a figure

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 .

Flight 2 The CoAP server (Relying Party) receives the request and processes it as described in then prepares Attestation_request as defined in . 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 .

Flight 3 The CoAP client (Attester) receives the response and processes it as described in 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 .

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.

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.

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