]> Ericsson AB

Sweden goran.selander@ericsson.com

Ericsson AB

Sweden john.mattsson@ericsson.com

INRIA

France malisa.vucinic@inria.fr

INRIA

France geovane.fedrecheski@inria.fr

Sandelman Software Works

Canada mcr+ietf@sandelman.ca

Security LAKE Working Group Internet-Draft 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. 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 For constrained IoT deployments the overhead and processing contributed by security protocols may be significant, which motivates the specification of lightweight protocols that are optimizing, in particular, message overhead (see ). This document describes Lightweight Authorization using EDHOC (ELA), a procedure for augmenting the lightweight authenticated Diffie-Hellman key exchange EDHOC with third party-assisted authorization. ELA involves a device, a domain authenticator, and an enrollment server. The device and domain authenticator perform mutual authentication and authorization, assisted by the enrollment server that provides relevant authorization information to the device (a "voucher") and to the authenticator. The high-level model is similar to BRSKI . In this document, we consider the target interaction for which authorization is needed to be "enrollment", for example joining a network for the first time (e.g., ), but it can be applied to authorize other target interactions. The enrollment server may represent the manufacturer of the device, or some other party with information about the device from which a trust anchor has been pre-provisioned into the device. The (domain) authenticator may represent the service provider or some other party controlling access to the network in which the device is enrolling. ELA assumes that authentication between device and authenticator is performed with EDHOC , and defines the integration of a lightweight authorization procedure using the External Authorization Data (EAD) fields defined in EDHOC. ELA enables a low message count by performing authorization and enrollment in parallel with authentication, instead of in sequence, which is common for network access. It further reuses protocol elements from EDHOC, leading to reduced message sizes on constrained links. This protocol is applicable to a wide variety of settings, and can be mapped to different authorization architectures.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Readers are expected to have an understanding of CBOR , CDDL , and EDHOC . Appendix C.1 of contains some basic info about CBOR.

Protocol Outline The goal of ELA is to enable a (potentially constrained) device (U) to enroll into a domain over a constrained link. The device authenticates and enforces authorization of the (non-constrained) domain authenticator (V) with the help of a voucher conveying authorization information. The voucher has a similar role as in but should be considerably more compact. The domain authenticator, in turn, authenticates the device and authorizes its enrollment into the domain. ELA also enables scenarios where only V needs to authorize U, by allowing the voucher to be optional. The procedure is assisted by a (non-constrained) enrollment server (W) located in a non-constrained network behind the domain authenticator, e.g., on the Internet, providing information to the device (conveyed in the voucher) and to the domain authenticator as part of the protocol. The objective of this document is to specify such a protocol that is lightweight over the constrained link, by reusing elements of EDHOC and by shifting message overhead to the non-constrained side of the network. See illustration in . Note the cardinality of the involved parties. It is expected that the domain authenticator needs to handle a large unspecified number of devices, but for a given device type or manufacturer it is expected that one or a few nodes host enrollment servers.

Overview of the message flow. EDHOC is used on the constrained link between U and V. Voucher_Info and Voucher are sent in EDHOC External Authorization Data (EAD). The link between V and W is not constrained. | | Voucher | | | |<-----+-----+ Domain | Request | Enrollment | | Device +------o---->| Authenticator +---------->| Server | | |<---o-------+ |<----------+ | | (U) | | | (V) | Voucher | (W) | | | | | | Response | | +----------+ | +---------------+ +---------------+ Voucher ]]>

Assumptions The protocol is based on the following pre-existing relations between the device (U), the domain authenticator (V) and the enrollment server (W), see .

• U and W have an explicit relation: U is configured with a public key of W, see .
• V and W have an implicit relation, e.g., based on web PKI with trusted CA certificates, see .
• U and V need not have any previous relation. This protocol establishes a relation between U and V.

Each of the three parties can gain protected communication with the other two during the protocol. V may be able to access credentials over non-constrained networks, but U may be limited to constrained networks. Implementations wishing to leverage the zero-touch capabilities of this protocol are expected to support transmission of credentials from V to U by value during the EDHOC exchange, which will impact the message size depending on the type of credential used.

Overview of pre-existing relations. | | | +----+-----+ +---------------+ +-------+-------+ | | | | | | | Device | con- | Domain | not con- | Enrollment | | | strained | Authenticator | strained | Server | | (U) | network | (V) | network | (W) | | | | | | | +----+-----+ +-------+-------+ +-------+-------+ | | | | <----------------------> | <------------------------> | No previous relation Implicit relation (e.g., web PKI based) ]]>

Device (U) To authenticate to V, the device (U) runs EDHOC in the role of Initiator with authentication credential CRED_U, for example, an X.509 certificate or a CBOR Web Token (CWT, ). CRED_U may, for example, be carried by value in ID_CRED_I of EDHOC message_3 or be provisioned to V over a non-constrained network, leveraging a credential identifier in ID_CRED_I (see ). U also needs to identify itself to W, for which it reuses ID_CRED_I. Note that while typically ID_CRED_I is treated as a field that only needs to be understood between two EDHOC peers (here U and V), in this case ID_CRED_I also MUST be formatted in a way that it is unambiguous to W. W will use ID_CRED_I to determine if the device with this identifier is authorized to enroll with V. U is also provisioned with information about W:

• A static public key of W (PK_W) used to establish secure communication with the enrollment server (see ).
• Location information about the enrollment server (LOC_W) that can be used by V to reach W. This is typically a URI but may alternatively be only the domain name.

Domain Authenticator (V) To authenticate to U, the domain authenticator (V) runs EDHOC in the role of Responder with an authentication credential CRED_V containing a public key of V, see . This proves to U the possession of the private key corresponding to the public key of CRED_V. CRED_V typically needs to be transported to U in EDHOC (using ID_CRED_R = CRED_V, see ) since there is no previous relation between U and V. V and W need to establish a secure (confidentiality and integrity protected) connection for the Voucher Request/Response protocol. Furthermore, W needs to access the same credential CRED_V that V uses with U (to compute the Voucher), and V needs to prove to W the possession of the private key corresponding to the public key of CRED_V. V MUST authenticate to W using the same credential CRED_V as with U. Note that the type of credential used by V will depend on what is supported by U and W. U can signal its supported credential types by advertising EDHOC Application Profiles , specifically by using the "cred_types" element. Regarding the secure channel between V and W, the choice of protocols may affect which type of credential and methods should be used by V. For example, in case V and W select TLS for the secure channel and PoP, then CRED_V is an X.509 certificate, and the EDHOC method used by V is signature-based. Some of the possible combinations of protocols to secure the connection between V and W are listed in below. Examples of how to secure the connection between V and W.

Secure channel between V and W	Proof-of-Possession from V to W	Type of CRED_V	EDHOC method used by V
[D]TLS 1.3 with mutual authentication, where V is the client and W is the server.	Provided by [D]TLS.	Restricted to types that are supported by both [D]TLS and EDHOC, e.g., X.509 certificates.	V MUST authenticate using a signature.
[D]TLS 1.3, where V is the client and W is the server.	Run an EDHOC session on top of the TLS-protected channel.	Any type supported by EDHOC, e.g., X.509, C509, CWT, or CCS.	Any method may be used.
EDHOC and OSCORE, where V is the initiator and W is the responder.	Already provided by EDHOC during the setup of the secure channel.	Any type supported by EDHOC.	Any method may be used.

Note also that the secure connection between V and W may be long-lived and reused for multiple voucher requests/responses. Other details of proof-of-possession related to CRED_V and transport of CRED_V are out of scope of this document.

Enrollment Server (W) The enrollment server (W) is assumed to have the private key corresponding to PK_W, which is used to establish secure communication with the device (see ). W provides to U the authorization decision for enrollment with V in the form of a voucher (see ). Authorization policies are out of scope for this document. Authentication credentials and communication security with V is described in . To calculate the voucher, W needs access to the hash of EDHOC message_1 and message_2 (H_12), ID_CRED_I, and CRED_V as used in the EDHOC session between U and V, see .

• W MUST verify that CRED_V is bound to the secure connection between W and V
• W MUST verify that V is in possession of the private key corresponding to the public key of CRED_V

W needs to be available during the execution of the protocol between U and V.

The Protocol

Overview The ELA protocol consists of three security sessions going on in parallel:

1. The EDHOC session between device (U) and (domain) authenticator (V)
2. Voucher Request/Response between authenticator (V) and enrollment server (W)
3. An exchange of voucher-related information, including the voucher itself, between device (U) and enrollment server (W), mediated by the authenticator (V).

provides an overview of the message flow detailed in this section. An outline of EDHOC is given in .

Overview of ELA: W-assisted authorization of U and V to each other: EDHOC between U and V, and Voucher Request/Response between V and W. Before the protocol, V and W are assumed to have established a secure channel and performed proof-of-possession of relevant keys. Credential lookup of CRED_U may involve W or other credential database. | | | (e.g., TLS with server cert.) | | | | | | Proof-of-possession w.r.t. CRED_V | | +<--- --- --- --- --- --- --- -->| | | (e.g., EDHOC) | | | | | | | | | | ------------------------------------------------------------------------ CORE PROTOCOL | | | | | | | EDHOC message_1 | | +----------------------------->| | | | | | EDHOC message_2 | | |<-----------------------------+ | | | | | | | | EDHOC message_3 | | +----------------------------->| | | (EAD_3 = LOC_W, EK_CT) | | | | | | | Voucher Request (VREQ) | | +-------------------------------------->| | | (SS, EK_CT, H_12, | | | ID_CRED_I, Fetch_CRED_U) | | | | | | Voucher Response (VRES) | | |<--------------------------------------+ | | (?Voucher, ?CRED_U) | | | | | EDHOC message_4 | | |<-----------------------------+ | | (?EAD_4 = Voucher) | | | | | ]]>

Reuse of EDHOC The ELA protocol illustrated in reuses several components of EDHOC:

• SUITES_I includes the cipher suite for EDHOC selected by U, and also defines the algorithms used between U and W (see ):
  • EDHOC AEAD algorithm: used to generate voucher
  • EDHOC hash algorithm: used for key derivation
  • EDHOC key exchange algorithm: used to calculate the shared secret between U and W
• EAD_3, EAD_4 are the External Authorization Data message fields of message_3 and message_4, respectively, see . In case U acts as Responder (see ), EAD_2 and EAD_3 are used in message_2 and message_3, respectively. This document specifies two new EAD items, with ead_label = TBD1 and TBD2, see .
• ID_CRED_I and ID_CRED_R are used to identify the authentication credentials CRED_U and CRED_V, respectively. As shown at the bottom of , V may use W to obtain CRED_U. By default, CRED_V is transported in ID_CRED_R in message_2, see . In case U is Responder, CRED_V is transported in ID_CRED_I in message_3.

The protocol also reuses the EDHOC_Extract and EDHOC_Expand key derivation from EDHOC (see ). The intermediate pseudo-random key PRK is derived using EDHOC_Extract():

• PRK = EDHOC_Extract(salt, IKM)
  • where salt = 0x (the zero-length byte string)
  • Computation of IKM depends on the EDHOC method in use.
    • If the method is based on Diffie-Hellman, IKM is computed as an ECDH cofactor Diffie-Hellman shared secret from the public key of W, PK_W, and the private key corresponding to G_U (or vice versa), see Section 5.7.1.2 of and .
    • If the method is based on a Key Encapsulation Mechanism (KEM), IKM is the KEM shared secret resulting from encapsulating PK_W, see Section 2.2 of . For example, the use of ML-KEM in COSE is currently being specified at .

The output keying material OKM is derived from PRK using EDHOC_Expand(), which is defined in terms of the EDHOC hash algorithm of the selected cipher suite SS, see :

• OKM = EDHOC_Expand(PRK, info, length) where

Finally, since the ELA authorization flow happens in EDHOC message_3 and message_4, ELA is also compatible with EDHOC application profiles, as defined in where advertisement of supported profiles happens in message_1 and message_2. This can be used, for example, to enable U or V to learn about each other's capability for executing the ELA protocol, see . Specifically, support for ELA can be advertised by indicating support for EAD items defined in this document.

Device <-> Enrollment Server (U <-> W) The protocol between U and W is carried between U and V in message_3 and message_4 (), and between V and W in the Voucher Request/Response (). The data is protected between the endpoints using secret keys derived from a shared secret (see ) as further detailed in this section.

Voucher_Info The external authorization data EAD_3 contains a critical EAD item with ead_label = -TBD1 and ead_value = Voucher_Info, which is a CBOR byte string: where

• LOC_W is a text string used by V to locate W, e.g., a URI or a domain name.
• EK_CT is a field containing either an ephemeral Diffie-Hellman key or a KEM ciphertext, depending on the EDHOC method being used in the current session:
  • if the method is based on Diffie-Hellman, the device generates an ephemeral Diffie-Hellman key pair, where the public part G_U is placed in the EK_CT field. The private part of G_U will be used to decrypt and verify the voucher, see and .
  • if the method is based on a PQC KEM, the device performs key encapsulation and places the resulting ciphertext CT in the EK_CT field. Here, the secret emitted by the encapsulation mechanism will be used to decrypt and verify the voucher, see and .

Voucher If W generates a Voucher, as determined by the application, the external authorization data EAD_4 contains an EAD item with ead_label = -TBD2 and ead_value = Voucher. The voucher is an assertion to U that W has authorized V. It is encrypted using the EDHOC AEAD algorithm of the selected cipher suite SS specified in SUITES_I of EDHOC message_1. It consists of the 'ciphertext' field of a COSE_Encrypt0 object , which is a byte string, as defined below. Its corresponding plaintext value consists of an opaque field that can be used by W to convey information to U, such as a voucher scope. The authentication tag present in the ciphertext is also bound to the current EDHOC handshake, the identity of U, and the credential of V as described below.

• The encryption key K and nonce IV are derived as specified below.
• 'protected' is a byte string of size 0
• 'plaintext' and 'external_aad' as below:

where

• OPAQUE_INFO is an opaque field provided by the application. If present, it will contain application data that W may want to convey to U, e.g., a voucher scope. Note that OPAQUE_INFO is opaque when viewed as an information element in EDHOC. It is opaque to V, while the application in U and W can read its contents.
• H_12 is H(H(message_1), message_2), used to bind the voucher to the current EDHOC session. It is computed using the EDHOC hash algorithm of the selected cipher suite SS specified in SUITES_I of EDHOC message_1. H_12 is sent to W as part of the voucher request, see .
• ID_CRED_I is the identifier of U transmitted via the voucher request.
• CRED_V is the credential used by V to authenticate to U and W, see and .

The derivation of K = EDHOC_Expand(PRK, info, length) uses the following input to the info struct (see ):

• info_label = 2
• context = h'' (the empty CBOR string)
• length is length of the key of the EDHOC AEAD algorithm in bytes

The derivation of IV = EDHOC_Expand(PRK, info, length) uses the following input to the info struct (see ):

• info_label = 3
• context = h'' (the empty CBOR string)
• length is length of the nonce of the EDHOC AEAD algorithm in bytes

Device <-> Authenticator (U <-> V) This section describes the processing in U and V, which includes the EDHOC protocol, see . Normal EDHOC processing is omitted here.

Message 1

Processing in U U composes EDHOC message_1 using authentication method, identifiers, etc. according to an agreed application profile, see . The selected cipher suite, in this document denoted SS, applies also to the interaction with W as detailed in , in particular, with respect to the key agreement algorithm used between U and W. U sends EDHOC message_1 to V.

Processing in V V processes EDHOC message_1 as specified in . Note that as part of normal EDHOC processing, U and V negotiate a selected cipher suite SS, as specified in .

Message 2

Processing in V V composes EDHOC message_2 as specified in . The type of CRED_V may depend on the selected mechanism for the establishment of a secure channel between V and W, See . In case the network between U and V is constrained, it is recommended that CRED_V be a CWT Claims Set (CCS) . The CCS contains the public authentication key of V encoded as a COSE_Key in the 'cnf' claim, see . ID_CRED_R contains the CWT Claims Set with 'kccs' as COSE header_map, see .

Processing in U U receives EDHOC message_2 from V and processes it as specified in .

Message 3

Processing in U U prepares EDHOC message_3 with EAD item (-TBD1, Voucher_Info) included in EAD_3, where Voucher_Info is specified in . The negative sign indicates that the EAD item is critical, see .

Processing in V V receives EDHOC message_3 from U and processes it as specified in , with the additional step of processing the EAD item in EAD_3. Since the EAD item is critical, if V does not recognize it or it contains information that V cannot process, then V MUST abort the EDHOC session, see . The ead_label = -TBD1 triggers the voucher request to W as described in . The exchange between V and W needs to be completed successfully for the EDHOC session to be continued. As part of normal processing of EDHOC message_3, V must verify the credential of U. It is up to the application to decide whether to verify the credential of U before or after the voucher request to W, see pre and post -verification processing of EAD items in . In case V has access to a credential database, it MAY query it with ID_CRED_I to obtain a corresponding CRED_U and verify the identity of U before making the Voucher request to W. If the verification of CRED_U fails, the EDHOC session is aborted. In this scenario, the EAD item in EAD_3 is processed as a post-verification item . Alternatively, V MAY proceed and perform a voucher request and wait for a voucher response. If the response contains CRED_U, V then continues processing EDHOC message_3 where it verifies the credential of U. Even upon reception of a successful voucher response from W, if the verification of CRED_U fails, the EDHOC session is aborted. In this scenario, the EAD item in EAD_3 is processed as a pre-verification item . In case V fails to obtain CRED_U, the session is aborted.

Message 4

Processing in V At this point, V has authenticated U, and received a valid voucher response from W as described in . V prepares EDHOC message_4 where, if the voucher response contains a voucher, V includes the critical EAD item (-TBD2, Voucher) in EAD_4, i.e., ead_label = -TBD2 and ead_value = Voucher, as specified in .

Processing in U U receives EDHOC message_4 from V and processes it as specified in , with the additional step of processing EAD_4. If EAD_4 contains an EAD item with label = -TBD2, U MUST verify the Voucher using H_12, ID_CRED_I, CRED_V, and the keys derived as in . If the verification fails then U MUST abort the EDHOC session. If U does not recognize the EAD item or the EAD item contains information that U cannot process, then U MUST abort the EDHOC session, see . If OPAQUE_INFO is present, it is made available to the application.

Authenticator <-> Enrollment Server (V <-> W) It is assumed that V and W have set up a secure connection, W has accessed the authentication credential CRED_V to be used in the EDHOC session between V and U, and that W has verified that V is in possession of the private key corresponding to CRED_V, see and . V and W run the Voucher Request/Response protocol over the secure connection.

Voucher Request

Processing in V V sends the voucher request to W. The Voucher Request SHALL be a CBOR array as defined below: where

• SS is the selected cipher suite used in the EDHOC session between U and V.
• EK_CT is either an ephemeral DH public key or a KEM ciphertext set by U, as defined in .
• H_12 corresponds to H(H(message_1), message_2). It is computed as defined in .
• ID_CRED_I is an identifier of CRED_U and is used as the identity of U during ELA execution, see .
• Fetch_CRED_U is a flag indicating whether W should try to load and return the credential CRED_U corresponding to ID_CRED_I.

Processing in W W receives and parses the voucher request received over the secure connection with V. W extracts from Voucher_Request:

• SS - the selected cipher suite.
• EK_CT - either an ephemeral DH public key or a KEM ciphertext.
• H_12 - the hash of message_1 and message_2.
• ID_CRED_I - the identifier of U.
• Fetch_CRED_U - flag indicating whether V requests W to return CRED_U.

W verifies that it supports the cipher suite SS, and uses the corresponding EDHOC Key Exchange Algorithm to determine whether EK_CT contains an ephemeral Diffie-Hellman public key or a KEM ciphertext. W uses H_12 as a session identifier, and associates it to the device identifier ID_CRED_I. Note that EK_CT is unique, as the ephemeral key or the ciphertext MUST not be reused, therefore H_12 is expected to be unique. If processing fails up until this point, the protocol SHALL be aborted with an error code signaling a generic issue with the request, see . W uses ID_CRED_I to look up the associated authorization policies for U and enforces them. This is out of scope for the specification. If ID_CRED_I is known by W, but authorization fails, the protocol SHALL be aborted with an error code signaling an access control issue, see and . If Fetch_CRED_U is true, W uses ID_CRED_I to try to retrieve the corresponding credential CRED_U. If retrieval succeeds, W MUST include CRED_U in the voucher response, see . If the retrieval fails, W sends the voucher response without CRED_U. If Fetch_CRED_U is false, W MUST NOT include CRED_U in the voucher response.

Voucher Response

Processing in W In case a Voucher is needed (as determined by the application), W retrieves CRED_V associated with the secure connection with V, and constructs the Voucher for the device with identifier ID_CRED_I (see ). W generates the voucher response and sends it to V over the secure connection. The Voucher_Response SHALL be a CBOR array as defined below: where

• The Voucher is defined in , if present.
• CRED_U is the credential of U corresponding to ID_CRED_I passed in the voucher request. CRED_U is included only if Fetch_CRED_U was set in the voucher request and W successfully retrieved the credential.

W signals the successful processing of Voucher_Request via a status code in the REST interface, as defined in .

Processing in V V receives the voucher response from W over the secure connection. If the voucher response is successfully received from W, then V responds to U with EDHOC message_4 as described in .

Error Handling This section specifies a new EDHOC error code and how it is used in ELA.

EDHOC Error "Access denied" This section specifies the new EDHOC error "Access denied", see .

EDHOC error code and error information for ‘Access denied’.

Error code TBD3 is used to indicate to the receiver that access control has been applied and the sender has aborted the EDHOC session. The ERR_INFO field contains error_content which is a CBOR Sequence consisting of an integer and an optional byte string. Where:

• REJECT_TYPE specifies the type and handling of the optional REJECT_INFO field.
• REJECT_INFO, if present, provides verifiable and actionable information to the receiver about the error, so that an automated action may be taken to try to obtain access, e.g. in the form of a retry request.

REJECT_TYPE and REJECT_INFO for ‘Access denied’.

Error handling in W, V, and U ELA uses the EDHOC Error "Access denied" in the following way:

• W generates error_content and transfers it to V via the secure connection. If REJECT_TYPE is 1, then REJECT_INFO is encrypted from W to U using the EDHOC AEAD algorithm. W signals the error via an appropriate status code in the REST interface, as defined in .
• V receives error_content, prepares an EDHOC "Access denied" error, and sends it to U.
• U receives the error message and extracts the error_content. If REJECT_TYPE is 1, then U decrypts REJECT_INFO, based on which it may retry to gain access.

The encryption of REJECT_INFO follows a procedure analogous to the one defined in , with the following differences: where

• OPAQUE_INFO is an opaque field that contains actionable information about the error. It may contain, for example, a list of suggested Vs through which U should join instead.
• H_12 is the hash of EDHOC message_1 and message_2, obtained from the associated voucher request, see .

Reverse flow with U as Responder This section presents a protocol variant in which U is the EDHOC Responder. This may allow optimizations in certain constrained network technologies. For example, one use case is having V broadcast message_1, to which U responds with a message_2 whose EAD_2 field contains Voucher_Info. Note that this is different from the EDHOC reverse message flow defined in , since we make no assumption about whether U or V is a CoAP server.

Baseline: U is the Initiator For clarity, we first present the regular flow with U as Initiator, as described in and . Note that Voucher_Info and Voucher are carried in EDHOC message_3 and message_4, respectively.

In ELA regular flow, U is the EDHOC Initiator. | | | | EDHOC message_2 | +<------------------------------| | | | EDHOC message_3 | W +------------------------------>| | | EAD_3 = (-TBD1, Voucher_info) | | | | VREQ | | +----------------------------->| | | (SS, EK_CT, H_12, | | | ID_CRED_I, Fetch_CRED_U) | | | | | | VRES | | |<-----------------------------+ | | (?Voucher, ?CRED_U) | | | | EDHOC message_4 | +<------------------------------| | ?EAD_4 = (-TBD2, Voucher) | | | ]]>

In the ELA regular flow, once message_4 processing is finalized (including processing of EAD_4), both U and V are authorized to interact.

U is the Responder ELA also works with U as the EDHOC Responder, a setup we refer to as the "ELA reverse flow", as shown in . We present this variant as a set of changes to the regular protocol flow. That is, here we only describe the differences in processing, when compared to the ELA regular flow. Here is a summary of the changes needed in the ELA reverse flow:

• Voucher_Info and Voucher are transported in EDHOC message_2 and message_3, respectively (instead of message_3 and message_4).
• The EAD_2 and EAD_3 fields carry critical EAD items identified with labels -TBD1 and -TBD2, respectively.
• The VREQ / VRES protocol takes place between message_2 and message_3.

ELA when U is the EDHOC Responder. | | | | EDHOC message_1 | +<------------------------------| | | | EDHOC message_2 | W +------------------------------>| | | EAD_2 = (-TBD1, Voucher_info) | | | | VREQ | | +----------------------------->| | | (SS, EK_CT, H_12, | | | ID_CRED_I, Fetch_CRED_U) | | | | | | VRES | | |<-----------------------------+ | | (?Voucher, ?CRED_U) | | | | EDHOC message_3 | +<------------------------------| | ?EAD_3 = (-TBD2, Voucher) | | | | | ]]>

The following sections detail how the processing of ELA reverse flow changes in each of the three security sessions (U-W, U-V, V-W), when compared to the baseline ELA regular flow described in sections to .

Reverse U <-> W The protocol between U and W is carried between U and V in message_2 and message_3, and between V and W in the Voucher Request/Response (). Voucher_Info:

• Voucher_Info is carried in EAD_2.
• It uses a critical EAD item with ead_label = -TBD1 and ead_value = Voucher_Info.

Voucher:

• The Voucher is carried in EAD_3.
• It uses a critical EAD item with ead_label = -TBD2 and ead_value = Voucher.

Reverse U <-> V Message 1:

• V composes message_1 and sends it to U.
• U processes message_1 and extracts SS.

Message 2:

• U composes message_2 with a critical EAD item (-TBD1, Voucher_Info) included in EAD_2.
• U sends message_2 to V.
• V processes message_2 and the EAD item in EAD_2, extracting the Voucher_Info struct.
• V sends the voucher request to W.

Here, V can choose to validate CRED_U before or after making the voucher request, depending on application requirements and availability of CRED_U, as detailed in . Message 3:

• V receives the voucher response from W.
• V sends message_3 with critical EAD item (-TBD2, Voucher) included in EAD_3.
• U processes message_3 and the EAD item in EAD_3.

The ELA reverse flow does not require sending a final EDHOC message_4.

Reverse V <-> W Processing in V:

• The Voucher_Request fields are prepared as defined in , with the following changes:
  • EK_CT is as extracted from the EAD_2 field of message_2.

Processing in W happens as specified in .

Interoperability considerations A Device (U) MUST implement one of the ELA flows, and it MAY choose to implement both. V MUST support both regular and reverse flows. From the point of view of W, there is no difference whether U and V run as EDHOC Initiator or Responder.

Security implications In the reverse flow, Voucher_Info is confidentiality and integrity protected, while Voucher is also authenticated. These properties are inherited from EDHOC message_2 and message_3. In contrast, the ELA regular flow provides confidentiality, integrity protection, and authentication to both Voucher_Info and Voucher, as inherited from EDHOC message_3 and message_4.

REST Interface at W The interaction between V and W is enabled through a RESTful interface exposed by W. This RESTful interface MAY be implemented using either HTTP or CoAP. V SHOULD access the resources exposed by W through the protocol indicated by the scheme in the LOC_W URI.

Scheme "https" In case the scheme indicates "https", V MUST perform a TLS handshake with W and access the resources defined in using HTTP. If the authentication credential CRED_V can be used in a TLS handshake, e.g., an X.509 certificate of a signature public key, then V SHOULD use it to authenticate to W as a client. If the authentication credential CRED_V cannot be used in a TLS handshake, e.g., if the public key is a static key, then V SHOULD first perform a TLS handshake with W using available compatible keys. V MUST then perform an EDHOC session over the TLS connection proving to W the possession of the private key corresponding to CRED_V. Performing the EDHOC session is only necessary if V did not authenticate with CRED_V in the TLS handshake with W. The relationship between V and W is long-lived. HTTP/1.1 and higher support persistent connections, and SHOULD be used in order to reduce overhead if a flood of new devices need to be onboarded. Support for TLS session resumptions tickets is appropriate for longer term associations. While a policy for renewal of the TLS connection should be applied, it is out of scope of this document.

Scheme "coaps" In case the scheme indicates "coaps", V SHOULD perform a DTLS handshake with W and access the resources defined in using CoAP. The normative requirements in on performing the DTLS handshake and EDHOC session remain the same, except that TLS is replaced with DTLS. As in , it is RECOMMENDED to allow reuse of the DTLS session.

Scheme "coap" In case the scheme indicates "coap", V SHOULD perform an EDHOC session with W, as specified in and access the resources defined in using OSCORE and CoAP. The authentication credential in this EDHOC session MUST be CRED_V. As in , it is RECOMMENDED to allow reuse of the EDHOC session.

URIs The URIs defined below are valid for both HTTP and CoAP. W MUST support the use of the path-prefix "/.well-known/", as defined in , and the registered name "lake-authz". A valid URI in case of HTTP thus begins with

• "https://www.example.com/.well-known/lake-authz"

In case of CoAP with DTLS:

• "coaps://example.com/.well-known/lake-authz"

In case of EDHOC and OSCORE:

• "coap://example.com/.well-known/lake-authz"

Each operation specified in the following is indicated by a path-suffix.

Voucher Request (/voucherrequest) To request a voucher, V MUST issue a request such that:

• Method is POST
• Payload is the serialization of the Voucher Request object, as specified in .
• Content-Format (Content-Type) is set to "application/lake-authz-voucherrequest+cbor"

In case of successful processing at W, W MUST issue a response such that:

• Status code is 200 OK if using HTTP, or 2.04 Changed if using CoAP
• Payload is the serialized Voucher Response object, as specified in
• Content-Format (Content-Type) is set to "application/lake-authz-voucherresponse+cbor"

In case of error, two cases should be considered:

• Voucher Request processing fails. In this case, W MUST reply with 400 Bad Request if using HTTP, or 4.00 if using CoAP.
• U is not authorized: this happens if W is able to process the Voucher Request, but the access policies forbid authorization. For example, the policy could enforce enrollment to a restricted list of identities, within a delimited time window, via a specific V, etc. In this case, W MUST reply with a 403 Forbidden code if using HTTP, or 4.03 if using CoAP; the payload is the serialized error_content object, with Content-Format (Content-Type) set to "application/lake-authz-vouchererror+cbor". The payload MAY be used by V to prepare an EDHOC error "Access Denied", see .

Certificate Request (/certrequest) V requests the public key certificate of U from W through the "/certrequest" path-suffix. To request U's authentication credential, V MUST issue a request such that:

• Method is POST
• Payload is the serialization of the ID_CRED_I (ID_CRED_R) object, as received in EDHOC message_3 (message_2).
• Content-Format (Content-Type) is set to "application/lake-authz-certrequest+cbor"

In case of a successful lookup of the authentication credential at W, W MUST issue a response such that:

• Status code is 200 OK if using HTTP, or 2.04 Changed if using CoAP
• Payload is the serialized CRED_U
• Content-Format (Content-Type) is set to "application/lake-authz-certresponse+cbor"

Security Considerations This specification builds on and reuses many of the security constructions of EDHOC, e.g., shared secret calculation and key derivation. The security considerations of EDHOC apply with modifications discussed here. These considerations apply to the ELA regular flow. For considerations about the ELA reverse flow, see . The Voucher_Info and Voucher structs are sent over authenticated channels that are confidentiality and integrity protected between U and V, i.e., in EDHOC fields EAD_3 and EAD_4. While ELA reuses several components of EDHOC, it does not reuse keys from EDHOC (such as the ephemeral key G_X when using DH) to protect fields Voucher_Info and Voucher. Reuse of G_X is avoided since ephemeral keys are expected to be used only once. Similarly, for KEM-based methods a fresh encapsulation is performed for each session. ELA is compatible with the currently standardized Diffie-Hellman shared secret derivation of EDHOC. Considering cryptographic recommendations by government agencies and the industry, ELA is also compatible with post-quantum cryptography primitives for deriving a shared secret, namely via the EK_CT field which can contain a KEM ciphertext according to the selected cipher suite. Post-quantum KEMs that could be used in EDHOC are currently under standardization in COSE . EDHOC provides identity protection of the Initiator, here the device. In ELA, the device U will share its identity with an authenticated V, albeit before knowing (via the Voucher received from W) whether U is authorized to interact with W. W may be used for lookup of CRED_U from ID_CRED_I, or this credential lookup function may be separate from the authorization function of W, see . The trust model used here is that U reveals its identity to any V, before knowing if the ELA authorization flow will be successfully completed. In onboarding use cases, U MAY choose to use an onboarding-only identity, whereas future operational communications can use a different identity under the already established secure channel. In the ELA regular flow, EDHOC message_4 is mandatory since it carries the Voucher. Implementations MUST NOT omit message_4 when ELA is in use.

IANA Considerations

EDHOC External Authorization Data Registry IANA has registered the following entries in the "EDHOC External Authorization Data" registry under the group name "Ephemeral Diffie- Hellman Over COSE (EDHOC)". Addition to the EDHOC EAD registry

Name	Label	Description
Voucher_Info	TBD1	Voucher_Info structure (a byte string), prepared by the Device (U).
Voucher	TBD2	Voucher structure (a byte string), prepared by the Enrollment Server (W).

The ead_label = TBD1 corresponds to the ead_value = Voucher_Info, which can be carried in either EAD_2 or EAD_3, depending on whether U acts as EDHOC Initiator or Responder, see . The ead_label = TBD2 corresponds to ead_value = Voucher, and can be carried in either EAD_3 or EAD_4, see . Note for IANA reviewers: the preferred value range is 0-23 (Standards Action with Expert Review).

The Well-Known URI Registry IANA has registered the following entry in "The Well-Known URI Registry", using the template from :

• URI suffix: lake-authz
• Change controller: IETF
• Specification document: [[this document]]
• Status: permanent
• Related information: None

Well-Known Name Under ".arpa" Name Space This document allocates a well-known name under the .arpa name space according to the rules given in and . The name "lake-authz.arpa" is requested. No subdomains are expected, and addition of any such subdomains requires the publication of an IETF Standards Track RFC. No A, AAAA, or PTR record is requested.

Domain Name Reservation Considerations As required by , the following considerations apply to the reservation of "lake-authz.arpa":

1. Users: Are human users expected to recognize these names as special and use them differently? In what way?

No. This name is not intended for direct use or recognition by human users.

1. Application Software: Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way? (For example, if a human user enters such a name, should the application software reject it with an error message?)

Yes. Applications that implement ELA and use CoAP may include "lake-authz.arpa" in the URI-Host option when the Device (U) does not yet know the address or identity of the Authenticator (V), such as during zero-touch enrollment.

1. Name Resolution APIs and Libraries: Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?

No.

1. Caching DNS Servers: Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?

No.

1. Authoritative DNS Servers: Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?

No.

1. DNS Server Operators: Does this reserved Special-Use Domain Name have any potential impact on DNS server operators? If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid? Do DNS server operators need to know about that and understand why? Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware?

No.

1. DNS Registries/Registrars: How should DNS Registries/Registrars treat requests to register this reserved domain name? Should such requests be denied? Should such requests be allowed, but only to a specially designated entity? (For example, the name "www.example.org" is reserved for documentation examples and is not available for registration; however, the name is in fact registered; and there is even a website at that name, which states circularly that the name is reserved for use in documentation and cannot be registered!)

Any requests to register this domain name should be denied.

Media Types Registry IANA has added the media types "application/lake-authz-voucherrequest+cbor" to the "Media Types" registry.

application/lake-authz-voucherrequest+cbor Media Type Registration

• Type name: application
• Subtype name: lake-authz-voucherrequest+cbor
• Required parameters: N/A
• Optional parameters: N/A
• Encoding considerations: binary (CBOR)
• Security considerations: See of this document.
• Interoperability considerations: N/A
• Published specification: [[this document]] (this document)
• Application that use this media type: To be identified
• Fragment identifier considerations: N/A
• Additional information:
  • Magic number(s): N/A
  • File extension(s): N/A
  • Macintosh file type code(s): N/A
• Person & email address to contact for further information: IETF LAKE Working Group (lake@ietf.org)
• Intended usage: COMMON
• Restrictions on usage: N/A
• Author: LAKE WG
• Change Controller: IETF

CoAP Content-Formats Registry IANA has added the following Content-Format number in the "CoAP Content-Formats" registry under the registry group "Constrained RESTful Environments (CoRE) Parameters". Addition to the CoAP Content-Formats registry

Content Type	Content Coding	ID	Reference
application/lake-authz-voucherrequest+cbor	-	TBD3	[[this document]]

Note for IANA reviewers: the preferred value range is 0-255 (Expert Review).

References Normative References This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. 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. 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. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. 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. 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. Informative References 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. This memo describes the management and operational requirements for the address and routing parameter area ("arpa") domain. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names. 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. This document describes the architecture of the eduroam service for federated (wireless) network access in academia. The combination of IEEE 802.1X, the Extensible Authentication Protocol (EAP), and RADIUS that is used in eduroam provides a secure, scalable, and deployable service for roaming network access. The successful deployment of eduroam over the last decade in the educational sector may serve as an example for other sectors, hence this document. In particular, the initial architectural choices and selection of standards are described, along with the changes that were prompted by operational experience. IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to extend 802.15.4 in an interoperable manner. The IEEE 802.15 Assigned Numbers Authority (ANA) manages the registry of the Information Elements. This document formulates a request for ANA to allocate a number from that registry for the IETF and describes how the IE is formatted to provide subtypes. 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. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. This document specifies automated bootstrapping of an Autonomic Control Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. This document describes the minimal framework required for a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network. The framework requires that the pledge and the JRC (Join Registrar/Coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework. This document describes conventions for using Post-Quantum Key Encapsulation Mechanisms (PQ-KEMs) with CBOR Object Signing and Encryption (COSE). Inria Ericsson AB Ericsson AB Odin Solutions S.L. This document compiles the requirements for a lightweight authenticated key exchange protocol for OSCORE. This draft has completed a working group last call (WGLC) in the LAKE working group. Post-WGLC, the requirements are considered sufficiently stable for the working group to proceed with its work. It is not currently planned to publish this draft as an RFC. RISE AB This document provides considerations for guiding the implementation of the authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). RISE AB RISE AB The lightweight authenticated key exchange protocol Ephemeral Diffie- Hellman Over COSE (EDHOC) requires certain parameters to be agreed out-of-band, in order to ensure its successful completion. To this end, application profiles specify the intended use of EDHOC to allow for the relevant processing and verifications to be made. In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Furthermore, in order to facilitate interoperability between EDHOC implementations and support EDHOC extensibility for additional integrations, this document defines a number of means to coordinate the use of EDHOC application profiles. Finally, this document defines a set of well- known EDHOC application profiles. n.d.

Optimization Strategies When ELA is used for zero-touch enrollment of IoT devices, U may have little to no knowledge about V's available in its vicinity. This may lead to situations where U retries several times at different V's until it finds one that works. This section presents two optimization strategies and different approaches to implement it. These strategies were developed to address scenarios where V's are radio gateways to which U wants to enroll, but may also be applicable to other use cases.

Using EDHOC Application Profiles This section provides an example of how support for ELA can be advertised using EDHOC application profiles. Application Profiles for EDHOC defines mechanisms to describe and distribute parameters regarding the supported capabilities of EDHOC peers. Specifically, describes how EDHOC peers can advertise supported profiles by using fields EAD_1 and EAD_2 in EDHOC message_1 and message_2, respectively. Since the ELA regular flow uses message_3 and message_4, peers can advertise support for ELA, and refrain from attempting the protocol in case one does not support it. In the case of the reverse flow, V can advertise a profile in message_1, while the protocol happens in message_2 and message_3. For example, to advertise support for ELA in the regular flow, U prepares EAD_1 containing an item where ead_label = TBD_EAD_LABEL and ead_value encodes a profile_id_with_eads, containing the following value: > ]]> Where:

• true indicates that U expects an application profile response from V in EAD_2, see
• APP-PROF-MINIMAL-CS-2 corresponds to a well-known EDHOC application profile (Method 3; Cipher Suite 2; CCS; kid), see
• TBD1 and TBD2 correspond to the EAD labels registered in this document, see

In the reply, V prepares EAD_2 containing an item where ead_label = TBD_EAD_LABEL and ead_value encodes a profile_id_with_eads, containing the following value: > ]]> Where APP-PROF-EXTENSIVE corresponds to a well-known EDHOC application profile, see .

V advertises support for ELA In this strategy, V shares some information (V_INFO) with a potential U, that can help it decide whether to try to enroll with that V. The exact contents of the V_INFO structure, as well as the mechanism used to transport it, will depend on the underlying communication technology and also on application needs. For example, V_INFO may state that:

• V implements ELA -- similarly to how EAPOL frames state support for IEEE 802.1X.
• V is part of a certain domain -- similarly to how Eduroam is used in the SSID field of IEEE 802.11 packets

V_INFO can be sent over a network beacon (see ), which may require technology specific profiling, e.g., the IEEE 802.15.4 enhanced beacon may be extended according to . Alternatively, V_INFO can be sent as part of an EAD field, as shown in . As a guideline for implementers, we define the following field that can be included in a V_INFO structure: The DOMAIN_ID field identifies the domain to which V belongs to, for example an URL or UUID. Below are three examples of how the advertisement strategy may be applied according to different application needs. The examples include sending V_INFO in network beacons, as part of EAD_1 in reverse message flow, or as part of a periodic CoAP multicast packet. The advantages, costs, and security impacts of each approach are also discussed.

V_INFO in network beacons This approach allows carrying V_INFO in beacons sent over the network layer, as shown in . It requires that the network layer offers a mechanism to configure its beacon packets. Depending on the network type, a solicitation packet may also be needed, as is the case of non-beaconed IEEE 802.15.4 and BLE with GATT.

Advertising ELA using V_INFO in network-layer beacons. | | Optional network solicitation | | | |<------------------------------------------+ | Network advertisement (contains V_INFO) | | | | | | EDHOC message_1 | +------------------------------------------>| | | | EDHOC message_2 | +<------------------------------------------| | | | EDHOC message_3 | +------------------------------------------>| | (EAD_3 = Voucher_Info) | | | ( ... protocol continues normally ... ) ]]>

This strategy can be used, for example, in IEEE 802.15.4, where an Enhanced Beacon can be used to transmit V_INFO. Specifically, a new information element for carrying V_INFO can be defined according to . This approach has the advantage of requiring minimal changes to the regular protocol as presented in , i.e., it does not require using the ELA reverse flow. It requires, however, some profiling of the lower layer beacons.

V_INFO in EAD_1 The ELA reverse flow (see ) allows implementing advertising where U first sends a trigger packet, in the format of a CoAP request that is broadcasted to the network. When a suitable V receives the solicitation, if it implements ELA, it should respond with an EDHOC message_1 whose EAD_1 has label -TBD4 and value V_INFO (see ).

Advertising ELA using V_INFO in EAD_1, employing the EDHOC reverse flow with U as responder. | | CoAP discovery/solicitation | | | | EDHOC message_1 | +<--------------------------------| | (?EAD_1 = V_INFO) | | | ( ... reverse flow continues normally ... ) ]]>

Note that V will only reply if it supports ELA. V_INFO can be structured to contain only an optional domain identifier: This approach enables a simple filtering mechanism, where only V's that support ELA will reply. In addition, it may not require layer-two profiling (in case the network allows transporting data before authorization).

V_INFO in a CoAP Multicast Packet In this approach, V periodically multicasts a CoAP packet containing V_INFO, see . Upon receiving one or more CoAP messages and processing V_INFO, U can decide whether or not to initiate the ELA protocol with a given V. Next, the application can either keep U acting as a server, and thus employ the EDHOC reverse flow, or implement a CoAP client and use the forward flow.

Advertising ELA using the network layer. | | | | EDHOC message_2 | +<------------------------------------------| | | | EDHOC message_3 | +------------------------------------------>| | (EAD_3 = Voucher_Info) | | | ( ... protocol continues normally ... ) ]]>

The V_INFO structure is sent as part of the CoAP payload. It is encoded as a CBOR sequence: In this approach, the periodic multicast may have resource usage impacts in the network.

Examples of protocol execution This section presents high level examples of the protocol execution. Note: the examples below include samples of access policies used by W. These are provided for the sake of completeness only, since the authorization mechanism used by W is out of scope in this document.

Minimal This is a simple example that demonstrates a successful execution of ELA. Premises:

• device u1 has identity ID_CRED_I = key id = 14
• the access policy in W specifies, via a list of identities, that device u1 can enroll via any domain authenticator, i.e., the list contains ID_CRED_I = 14. In this case, the policy only specifies a restriction in terms of U, effectively allowing enrollment via any V.

Execution:

1. device u1 discovers a gateway (v1) and tries to enroll
2. gateway v1 identifies the zero-touch join attempt by checking that the label of the EAD item in EAD_3 is -TBD1, and prepares a Voucher Request using the information contained in the value of the EAD item
3. upon receiving the request, W obtains ID_CRED_I = 14, authorizes the access, and replies with Voucher Response

Wrong gateway In this example, a device u1 tries to enroll a domain via gateway v1, but W denies the request because the pairing (u1, v1) is not configured in its access policies. This example also illustrates how the REJECT_INFO field of the EDHOC error Access Denied could be used, in this case to suggest that the device should select another gateway for the join procedure. Premises:

• devices and gateways communicate via Bluetooth Low Energy (BLE), therefore their network identifiers are MAC addresses (EUI-48)
• device u1 has ID_CRED_I = key id = 14
• there are 3 gateways in the radio range of u1:
  • v1 with MAC address = A2-A1-88-EE-97-75
  • v2 with MAC address = 28-0F-70-84-51-E4
  • v3 with MAC address = 39-63-C9-D0-5C-62
• the access policy in W specifies, via a mapping of shape (ID_CRED_I; MAC1, MAC2, ...) that device u1 can only join via gateway v3, i.e., the mapping is: (14; 39-63-C9-D0-5C-62)
• W is able to map the PoP key of the gateways to their respective MAC addresses

Execution:

1. device u1 tries to join via gateway v1, which forwards the request to W
2. W determines that MAC address A2-A1-88-EE-97-75 is not in the access policy mapping, and replies with an error. The error_content has REJECT_TYPE = 1, and the plaintext OPAQUE_INFO (used to compute the encrypted REJECT_INFO) specifies a list of suggested gateways = [h'3963C9D05C62']. The single element in the list is the 6-byte MAC address of v3, serialized as a bstr.
3. gateway v1 assembles an EDHOC error "Access Denied" with error_content, and sends it to u1
4. device u1 processes the error, decrypts REJECT_INFO, and retries the protocol via gateway v3

Acknowledgments The authors sincerely thank for his contribution in the initial phase of this work, and Marco Tiloca for extensively reviewing the document. We also thank Christian Amsüss for his active participation in discussions that led to improvements in the document. Work on this document has in part been supported by the Horizon Europe Framework Programme project OpenSwarm (grant agreement No. 101093046).