]> Inria

yuxuan.song@inria.fr

Ericsson AB

goran.selander@ericsson.com

Security Lightweight Authenticated Key Exchange Internet-Draft 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 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 The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman over COSE (EDHOC) , 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 defines three main roles: 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. 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) . 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 . This specification defines new EAD items including EATs for performing remote attestation over EDHOC in the Background Check Model (BG, see ) and in the Passport Model (PP, see ). 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. 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.

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 , RATS architecture and CBOR .

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 , as well as the PSK-based authentication method defined in . 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 (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. 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 and ).

This document focuses on cases that are suited for constrained IoT environments, see for a characterization of constrained nodes and networks. When transferred over CoAP , 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 ). In this specification, both flows are supported to perform remote attestation.

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

Reuse of EDHOC This specification reuses several components of EDHOC.

• EAD is the External Authorization Data message field of EDHOC messages, see . This specification specifies four new EAD items in BG model, and four new EAD items in PP model. See .
• 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 ) when Evidence is sent in EDHOC message_3.
• EDHOC_Exporter is used to generate the attestation_binder_m4 (see ) when Evidence is sent in EDHOC message_4.

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 ) and the PP model (see ). The corresponding EAD items for the BG and PP models are independent.

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 ). 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 , 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 (), Attestation_request (), Evidence (), and trigger_bg (). 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 ). 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 ).

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.

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 ). The EAD item Remote Attestation BG for an attestation proposal is:

• ead_label = TBD1
• ead_value = Attestation_proposal, which is a CBOR byte string:

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 .

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:

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.

Evidence The Attester calls its local attestation service to generate and return a serialized Entity Attestation Token (EAT) 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) containing attestation-oriented claims. The complete set of attestation claims for the EAT is specified in . An example is provided in .

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: 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 ), which is included by the Attester within the Evidence.
• The "measurements" claim could be a CoSWID , a CoRIM or other claim formats, and MUST be identified by CoAP Content Format. An example as CoSWID is shown in .

Attestation binder The signing of the Evidence MUST also take as input an attestation binder, see . 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 . 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.
• 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 . 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: 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

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 . 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. 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 (), Result_request (), Result (), and trigger_pp (). 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 ). 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 ).

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.

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

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 , such as kid (4) or x5t (34). Profiles using this specification MUST specify which label values are acceptable.

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:

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.

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

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

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

Overview of EDHOC Initiator attestation in the Background-Check Model. EDHOC is used between A and RP. | | | | 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 | | | |<============================>| | | | | | ]]>

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

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

(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 . The EAD items specific to the Background-Check Model are defined in . 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 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 ).

Overview of EDHOC Responder attestation in the Background-Check Model. EDHOC is used between A and RP. | | | | 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 | | | |<============================>| | | | | | ]]>

(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 . The EAD items specific to the Passport Model are defined in . 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.

Overview of EDHOC Initiator attestation in the Passport Model. EDHOC is used between A and RP. | | | 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 } | | | | ]]>

Mutual Attestation in EDHOC In this section we demonstrate mutual attestation over EDHOC combining the cases (I, BG), see , and (R, PP), see , 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.

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

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

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.

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

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

Security Considerations This specification builds on EDHOC 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 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 , EAD_3 and EAD_4 are protected against both passive and active attackers. For the PSK-based authentication method defined in , 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 , attestation evidence containing such information MUST NOT be sent before message_3. When using the PSK-based authentication method defined in , 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 . 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. 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.

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

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. This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. 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. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. 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 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. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. 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 research and standardization work for constrained-node networks. This document obsoletes RFC 7228. Fraunhofer SIT NVIDIA arm Independent Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. Inria Ericsson Ericsson University of Murcia University of Murcia This document specifies a Pre-Shared Key (PSK) authentication method for the Lightweight Authenticated Key Exchange (LAKE) protocol. The PSK method provides mutual authentication, ephemeral key exchange, identity protection, and quantum resistance while incurring lower computational costs than the public-key authentication methods specified for LAKE. It is suited for systems where nodes share a PSK provided out-of-band (external PSK) and enables efficient session resumption with less computational overhead when the PSK is provided from a previous LAKE session (resumption PSK). This document details the PSK message flow, key derivation changes, message formatting, processing, and security considerations. 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: 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: 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 Evidence is protected by a COSE_Sign1 structure, where the payload of COSE_Sign1 contains the following claims: The Sig_structure to compute the signature of COSE_Sign1 is: 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 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.

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.

Intra-handshake Re-attestation using EDHOC Resumption with PSK Remote attestation can be applied during EDHOC session resumption using EDHOC-PSK, as defined in . This enables re-attestation without public key based authentication.

Post-handshake Re-attestation using OSCORE Post-handshake attestation can be performed after an EDHOC session using Object Security for Constrained RESTful Environments (OSCORE) . In such a case, EDHOC is specifically used to establish an OSCORE Security Context (see Appendix A.1 of ). 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.

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 .

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

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

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 allows the attestation process to be 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 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.

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