]> RISE AB

Isafjordsgatan 22 Kista 16440 Stockholm Sweden marco.tiloca@ri.se

RISE AB

Isafjordsgatan 22 Kista 16440 Stockholm Sweden rikard.hoglund@ri.se

Security LAKE Working Group Internet-Draft 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 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. Also, it defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles. Finally, this document defines a set of well-known EDHOC application profiles. Discussion Venues Discussion of this document takes place on the Lightweight Authenticated Key Exchange Working Group mailing list (lake@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight authenticated key exchange protocol, especially intended for use in constrained scenarios. A main use case for EDHOC is to establish a Security Context for Object Security for Constrained RESTful Environments (OSCORE) . In order to successfully run EDHOC, the two peers acting as Initiator and Responder have to agree on certain parameters. Some of those are in-band and communicated through the protocol execution, during which a few of them may even be negotiated. However, other parameters have to be known out-of-band, before running the EDHOC protocol. As discussed in , applications can use EDHOC application profiles, which specify the intended usage of EDHOC to allow for the relevant processing and verifications to be made. In particular, an EDHOC application profile may include both in-band and out-of-band parameters. In order to facilitate interoperability between EDHOC implementations and to support EDHOC extensibility for additional integrations (e.g., of external security applications, handling of authentication credentials, and message transports), this document defines a number of means to coordinate the use of EDHOC application profiles, that is:

• The new IANA registry "EDHOC Application Profiles" defined in , where to register integer identifiers of EDHOC application profiles to use as corresponding Profile IDs.
• The new parameter "ed-prof" defined in . This parameter is employed to specify an EDHOC application profile identified by its Profile ID, and can be used as target attribute in a web link to an EDHOC resource, or as filter criteria in a discovery request to discover EDHOC resources. For instance, the target attribute can be used in a link-format document describing EDHOC resources at a server, when EDHOC is transferred over the Constrained Application Protocol (CoAP) (see as well as ).
• The new parameter "app_prof" defined in for the EDHOC_Information object specified in . This parameter is employed to specify a set of EDHOC application profiles, each identified by its Profile ID. For instance, the parameter can be used in the EDHOC and OSCORE profile of the ACE framework for authentication and authorization in constrained environments (ACE) , in order to indicate the EDHOC application profiles supported by an ACE resource server.
• Additional parameters that provide information about an EDHOC application profile. These parameters correspond to elements of the EDHOC_Information object and are to be used as target attributes in a web link to an EDHOC resource, or as filter criteria in a discovery request to discover EDHOC resources (see ).
• A new EDHOC External Authorization Data (EAD) item (see ) and a new error code for the EDHOC error message (see ). When running EDHOC, a peer can use those in order to advertise the EDHOC application profiles that it supports to the other peer.

In order to ensure the applicability of such parameters and information beyond transport- or setup-specific scenarios, this document also defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles as CBOR data items (see ). The defined representation is transport- and setup-independent, and avoids the need to reinvent an encoding for the available options to run the EDHOC protocol or the selection logic to apply on those. The CBOR-based representation of an EDHOC application profile can be, for example: retrieved as a result of a discovery process; or retrieved/provided during the retrieval/provisioning of an EDHOC peer's public authentication credential; or obtained during the execution of a device on-boarding/registration workflow. Finally, this document defines a set of well-known EDHOC application profiles (see ). These application profiles are meant to reflect what is most common and expected to be supported by EDHOC peers, while they are not to be intended as "default" application profiles or as a deviation from what is mandatory to support for EDHOC peers (see ). On the other hand, they provide implementers and users with a quick overview of the several, available options to run the EDHOC protocol and of their most expected combinations.

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. The reader is expected to be familiar with terms and concepts defined in EDHOC , and with the use of EDHOC with CoAP and OSCORE defined in . Concise Binary Object Representation (CBOR) and Concise Data Definition Language (CDDL) are used in this document. CDDL predefined type names, especially bstr for CBOR byte strings and tstr for CBOR text strings, are used extensively in this document. CBOR data items are represented using the CBOR extended diagnostic notation as defined in and ("diagnostic notation"). Diagnostic notation comments are used to provide a textual representation of the parameters' keys and values. In the CBOR diagnostic notation used in this document, constructs of the form e'SOME_NAME' are replaced by the value assigned to SOME_NAME in the CDDL model shown in of . For example, {e'methods' : [0, 1, 2, 3], e'cipher_suites': 3} stands for {1 : [0, 1, 2, 3], 2 : 3}. Note to RFC Editor: Please delete the paragraph immediately preceding this note. Also, in the CBOR diagnostic notation used in this document, please replace the constructs of the form e'SOME_NAME' with the value assigned to SOME_NAME in the CDDL model shown in of . Finally, please delete this note.

Identifying EDHOC Application Profiles by Profile ID This document introduces the concept of Profile IDs, i.e., integer values that uniquely identify EDHOC application profiles, for which an IANA registry is defined in . This section defines two parameters to convey such Profile IDs, i.e.:

• The parameter "ed-prof" for web linking (see ).
• The parameter "app_prof" of the EDHOC_Information object specified in (see ).

As defined later in this document, Profile IDs can be used to identify EDHOC application profiles also:

• Within certain EDHOC messages, sent during an EDHOC session by a peer that supports such EDHOC application profiles (see ).
• Within the canonical, CBOR-encoded representation of such EDHOC application profiles (see ).

In Web Linking defines a number of target attributes that can be used in a web link with resource type "core.edhoc" (see ). This is the case, e.g., when using a link-format document describing EDHOC resources at a server, when EDHOC is transferred over CoAP as defined in . This allows a client to obtain relevant information about the EDHOC application profile(s) to be used with a certain EDHOC resource. In the same spirit, this section defines the following additional parameter, which can be optionally specified as a target attribute with the same name in the link to the respective EDHOC resource, or among the filter criteria in a discovery request from a client.

• 'ed-prof', specifying an EDHOC application profile supported by the server. This parameter MUST specify a single value, which is taken from the 'Profile ID' column of the "EDHOC Application Profiles" registry defined in of this document. This parameter MAY occur multiple times, with each occurrence specifying an EDHOC application profile.

When specifying the parameter 'ed-prof' in a link to an EDHOC resource, the target attribute rt="core.edhoc" MUST be included. If a link to an EDHOC resource includes occurrences of the target attribute 'ed-prof', then the following applies.

• The link MUST NOT include other target attributes that provide information about an EDHOC application profile (see, e.g., and of this document), with the exception of the target attribute 'ed-ead' that MAY be included. The recipient MUST ignore other target attributes that provide information about an EDHOC application profile, with the exception of the target attribute 'ed-ead'.
• If the link includes occurrences of the target attribute 'ed-ead', the link provides the following information: when using the target EDHOC resource as per the EDHOC application profile indicated by any occurrence of the target attribute 'ed-prof', the server supports the External Authorization Data (EAD) items that are specified in the definition of that EDHOC application profile, as well as the EAD items indicated by the occurrences of the target attribute 'ed-ead'.

The example in shows how a CoAP client discovers two EDHOC resources at a CoAP server, and obtains information about the application profile corresponding to each of those resources. The Link Format notation from is used. The example assumes the existence of an EDHOC application profile identified by the integer Profile ID 500, which is supported by the EDHOC resource at /edhoc-alt and whose definition includes the support for the EAD items with EAD label 111 and 222. Therefore, the link to the EDHOC resource at /edhoc-alt indicates that, when using that EDHOC resource as per the EDHOC application profile with Profile ID 500, the server supports the EAD items with EAD label 111, 222, and 333.

The Web Link. ;osc, ;if=sensor, ;rt=core.edhoc;ed-csuite=0;ed-csuite=2; ed-method=0;ed-cred-t=1;ed-cred-t=3;ed-idcred-t=4; ed-i;ed-r;ed-comb-req, ;rt=core.edhoc;ed-prof=500;ed-ead=333 ]]>

In the EDHOC_Information Object defines the EDHOC_Information object, as including information that guides two peers towards executing the EDHOC protocol, and defines an initial set of its parameters. This document defines the new parameter "app_prof" of the EDHOC_Information object, as summarized in and described further below. EDHOC_Information Parameter "app_prof"

Name	CBOR label	CBOR type	Registry	Description
app_prof	23	int or array	EDHOC Application Profiles Registry	Set of supported EDHOC Application Profiles

• app_prof: This parameter specifies a set of supported EDHOC application profiles, identified by their Profile ID. If the set is composed of a single EDHOC application profile, its Profile ID is encoded as an integer. Otherwise, the set is encoded as an array of integers, where each array element encodes one Profile ID. In JSON, the "app_prof" value is an integer or an array of integers. In CBOR, "app_prof" is an integer or an array of integers, and has label 23. The integer values are taken from the 'Profile ID' column of the "EDHOC Application Profiles" registry defined in of this document.

Use in the EDHOC and OSCORE Profile of the ACE Framework defines how the EDHOC_Information object can be used within the workflow of the EDHOC and OSCORE transport profile of the ACE framework for authentication and authorization in constrained environments (ACE) . In particular, the AS-to-C Access Token Response includes the parameter "edhoc_info", with value an EDHOC_Information object. This allows the ACE authorization server (AS) to provide the ACE client (C) with information about how to run the EDHOC protocol with the ACE resource server (RS) for which the access token is issued. Similarly, the access token includes the corresponding claim "edhoc_info", with value an EDHOC_Information object. This allows the AS to provide the ACE RS with information about how to run the EDHOC protocol with the ACE client, according to the issued access token. In turn, the EDHOC_Information object can include the parameter "app_prof" defined in this document. This parameter indicates a set of EDHOC application profiles associated with the EDHOC resource to use at the RS, which is either implied or specified by the parameter "uri_path" within the same EDHOC_Information object. If the EDHOC_Information object specified as value of "edhoc_info" includes the "app_prof" parameter, then the following applies.

• The object MUST NOT include other parameters that provide information pertaining to an EDHOC application profile, with the exception of the parameter "eads" that MAY be included. C and RS MUST ignore other parameters present in the EDHOC_Information object, with the exception of the parameter "eads". At the time of writing this document, such parameters are: "methods", "cipher_suites", "message_4", "comb_req", "uri_path", "osc_ms_len", "osc_salt_len", "osc_version", "cred_types", "id_cred_types", "initiator", "responder", "max_msgsize", "coap_ct", "ep_id_types", "transports", and "trust_anchors", which are all defined in .
• If the EDHOC_Information object specified in the parameter "edhoc_info" of the AS-to-C Access Token Response includes the parameter "eads", the object provides the following information. When using the target EDHOC resource as per any EDHOC application profile indicated by the parameter "app_prof", the ACE RS for which the access token is issued supports the EAD items that are specified in the definition of that EDHOC application profile, as well as the EAD items indicated by the parameter "eads".
• If the EDHOC_Information object specified in the claim "edhoc_info" of the access token includes the parameter "eads", the object provides the following information. When using the target EDHOC resource as per any EDHOC application profile indicated by the parameter "app_prof", the ACE client to which the access token is issued supports the EAD items that are specified in the definition of that EDHOC application profile, as well as the EAD items indicated by the parameter "eads".

Additional Parameters for Web Linking Building on what is defined and prescribed in , this section defines additional parameters for web linking , which can be used to obtain relevant pieces of information from the EDHOC application profile associated with an EDHOC resource. These parameters can be optionally specified as target attributes with the same name in a link with resource type "core.edhoc" (see ) targeting an EDHOC resource, or as filter criteria in a discovery request from a client. When specifying any of the parameters defined below in a link to an EDHOC resource, the target attribute rt="core.edhoc" MUST be included.

• 'ed-max-msgsize', specifying the admitted maximum size of EDHOC messages in bytes. This parameter MUST specify a single unsigned integer value.
• 'ed-coap-ct', specifying that CoAP messages have to include the CoAP Content-Format Option with value 64 (application/edhoc+cbor-seq) or 65 (application/cid-edhoc+cbor-seq) as appropriate, when the message payload includes exclusively an EDHOC message possibly prepended by an EDHOC connection identifier (see Sections and of ). A value MUST NOT be given to this parameter and any present value MUST be ignored by the recipient.
• 'ed-epid-t', specifying a type of endpoint identity for EDHOC supported by the server. This parameter MUST specify a single value, which is taken from the 'CBOR Label' column of the "EDHOC Endpoint Identity Types" registry defined in . This parameter MAY occur multiple times, with each occurrence specifying a type of endpoint identity for EDHOC.
• 'ed-tp', specifying a means for transporting EDHOC messages supported by the server. This parameter MUST specify a single value, which is taken from the 'Transport ID' column of the "EDHOC Transports" registry defined in . This parameter MAY occur multiple times, with each occurrence specifying a means for transporting EDHOC messages.
• 'ed-ta-edcred-uuid', specifying the identifier of a trust anchor supported by the server for verifying authentication credentials of other EDHOC peers, as a UUID . This parameter MUST specify a single value, which is the UUID in its string format (see Section 4 of ). This parameter MAY occur multiple times, with each occurrence specifying one trust anchor identifier.
• 'ed-ta-edcred-kid', specifying the identifier of a trust anchor supported by the server for verifying authentication credentials of other EDHOC peers, as a binary key identifier. This parameter MUST specify a single value, which is the base64url-encoded text string of the binary representation of the key identifier. This parameter MAY occur multiple times, with each occurrence specifying one trust anchor identifier.
• 'ed-ta-edcred-c5t', specifying the identifier of a trust anchor supported by the server for verifying authentication credentials of other EDHOC peers, as a hash of a C509 certificate . This parameter MUST specify a single value, which is the base64url-encoded text string of the binary representation of the certificate hash encoded as a COSE_CertHash . This parameter MAY occur multiple times, with each occurrence specifying one trust anchor identifier.
• 'ed-ta-edcred-c5u', specifying the identifier of a trust anchor supported by the server for verifying authentication credentials of other EDHOC peers, as a URI pointing to a C509 certificate . This parameter MUST specify a single value, which is the URI pointing to the certificate. This parameter MAY occur multiple times, with each occurrence specifying one trust anchor identifier.
• 'ed-ta-edcred-x5t', specifying the identifier of a trust anchor supported by the server for verifying authentication credentials of other EDHOC peers, as a hash of an X.509 certificate . This parameter MUST specify a single value, which is the base64url-encoded text string of the binary representation of the certificate hash encoded as a COSE_CertHash . This parameter MAY occur multiple times, with each occurrence specifying one trust anchor identifier.
• 'ed-ta-edcred-x5u', specifying the identifier of a trust anchor supported by the server for verifying authentication credentials of other EDHOC peers, as a URI pointing to an X.509 certificate . This parameter MUST specify a single value, which is the URI pointing to the certificate. This parameter MAY occur multiple times, with each occurrence specifying one trust anchor identifier.

Advertising Supported EDHOC Application Profiles during an EDHOC Session The rest of this section defines means that an EDHOC peer can use in order to advertise the EDHOC application profiles that it supports to another EDHOC peer, when running EDHOC with that other peer. Such means are an EDHOC EAD item (see ) and an error code for the EDHOC error message (see ).

In EDHOC Message 1 and Message 2 This section defines the EDHOC EAD item "Supported EDHOC application profiles", which is registered in of this document. The EAD item MAY be included:

• In the EAD_1 field of EDHOC message_1, in order to specify EDHOC application profiles supported by the Initiator.
• In the EAD_2 field of EDHOC message_2, in order to specify EDHOC application profiles supported by the Responder.

The EAD item MUST NOT be included in the EAD fields of EDHOC message_3 or message_4. Within an EAD_1 field or EAD_2 field, the EAD item MUST NOT occur more than once. When the EAD item is present, its ead_label TBD_EAD_LABEL MUST be used only with positive sign, i.e., the use of the EAD item is always non-critical (see ). The EAD item MUST specify an ead_value, as a CBOR byte string with value the binary representation of a CBOR sequence APP_PROF_SEQ. The CBOR sequence is composed of one or more items, whose order has no meaning. Each item of the CBOR sequence MUST be either of the following:

• A CBOR integer, specifying the Profile ID of an EDHOC application profile. The integer value is taken from the 'Profile ID' column of the "EDHOC Application Profiles" registry defined in of this document. This item of the CBOR sequence indicates that the message sender supports the EDHOC application profile identified by the Profile ID.
• A CBOR array including at least one element. In particular:
  • The first element MUST be a CBOR integer, specifying the Profile ID of an EDHOC application profile. The integer value is taken from the 'Profile ID' column of the "EDHOC Application Profiles" registry.
  • Each of the elements following the first one MUST be a CBOR unsigned integer, specifying the ead_label of an EAD item.
  This item of the CBOR sequence indicates that the message sender supports:
  • The EDHOC application profile PROFILE identified by the Profile ID in the first element of the array; and
  • The EAD items identified by the ead_label in the elements following the first one, in addition to the EAD items that are specified in the definition of the EDHOC application profile PROFILE.
• An EDHOC_Information object encoded in CBOR, i.e., as a CBOR map (see ). The EDHOC_Information object MUST NOT include the elements "session_id" and "app_prof". The recipient MUST ignore those elements if they are included in the EDHOC_Information object. This item of the CBOR sequence indicates that the message sender supports an EDHOC application profile consistent with the pieces of information specified by the EDHOC_Information object.

The CDDL grammar describing the ead_value for the EAD item "Supported EDHOC application profiles" is:

CDDL Definition of ead_value for the EAD item "Supported EDHOC application profiles" > ; This defines an array, the elements of which ; are to be used in the CBOR Sequence APP_PROF_SEQ: APP_PROF_SEQ = [ 1* element ] element = profile_id / profile_id_with_eads / EDHOC_Information profile_id = int profile_id_with_eads = [ profile_id, 1* uint ] ; The full definition is provided in ; draft-ietf-ace-edhoc-oscore-profile EDHOC_Information : map ]]>

In the EDHOC Error Message This section defines the error code TBD_ERROR_CODE, which is registered in of this document. Error code TBD_ERROR_CODE MUST only be used when replying to EDHOC message_1. If an EDHOC error message with error code TBD_ERROR_CODE is received as reply to an EDHOC message different from EDHOC message_1, then the recipient of the error message MUST ignore what is specified in ERR_INFO. The Responder MUST NOT abort an EDHOC session exclusively due to the wish of sending an error message with error code TBD_ERROR_CODE. Instead, the Responder can advertise the EDHOC application profiles that it supports to the Initiator by means of the EAD item "Supported EDHOC application profiles" defined in , specifying it in the EAD_2 field of the EDHOC message_2 to send in the EDHOC session. When replying to an EDHOC message_1 with an error message, the Responder has to consider the reason for which it is aborting the EDHOC session and MUST NOT specify error code TBD_ERROR_CODE if a different, more appropriate error code can be specified instead. For example, if the negotiation of the selected cipher suite fails (see ), the error message MUST NOT specify error code TBD_ERROR_CODE, since the error message intended to be used in that case specifies error code 2 (Wrong selected cipher suite) and conveys SUITES_R as ERR_INFO. When using error code TBD_ERROR_CODE, the error information specified in ERR_INFO MUST be a CBOR sequence formatted like APP_PROF_SEQ defined in . Note that the CBOR sequence specified in ERR_INFO is not wrapped into a CBOR byte string.

Canonical Representation of an EDHOC Application Profile This section defines the EDHOC_Application_Profile object, which can be used as a canonical representation of EDHOC application profiles for their description, distribution, and storage. An EDHOC_Application_Profile object is encoded as a CBOR map . Each element of the CBOR map is an element of the CBOR-encoded EDHOC_Information object specified in , and thus uses the corresponding CBOR abbreviations from the 'CBOR label' column of the "EDHOC Information" registry defined in . The CBOR map encoding an EDHOC_Application_Profile object MUST include the element "app_prof" defined in this document. The value of the element "app_prof" is the unique identifier of the EDHOC application profile described by the EDHOC_Application_Profile object, taken from the 'Profile ID' column of the "EDHOC Application Profiles" registry defined in this document, and encoded as a CBOR integer. The CBOR map MUST include the following elements defined for the EDHOC_Information object: "methods" and "cred_types". The CBOR map MUST NOT include the following elements defined for the EDHOC_Information object: "session_id", "uri_path", "initiator", and "responder". A consumer MUST ignore those elements if they are included in the EDHOC_Application_Profile object. The CBOR map MAY include other elements defined for the EDHOC_Information object. Furthermore, consistent with Sections and of and with , the following applies:

• If the element "cipher_suites" is not present in the CBOR map, this indicates that the EDHOC application profile uses the EDHOC cipher suites 2 and 3, and possibly other cipher suites.
• If the element "id_cred_types" is not present in the CBOR map, this indicates that the EDHOC application profile uses "kid" as type of authentication credential identifiers for EDHOC, and possibly other types of authentication credential identifiers.
• If the element "osc_ms_len" is not present in the CBOR map, this indicates that, when using EDHOC to key OSCORE , the size of the OSCORE Master Secret in bytes is equal to the size of the key length for the application AEAD Algorithm of the selected cipher suite for the EDHOC session.
• If the element "osc_salt_len" is not present in the CBOR map, this indicates that, when using EDHOC to key OSCORE, the size of the OSCORE Master Salt in bytes is 8.
• If the element "osc_version" is not present in the CBOR map, this indicates that, when using EDHOC to key OSCORE, the OSCORE Version Number has value 1.
• The absence of any other elements in the CBOR map MUST NOT result in assuming any value.

If an element is present in the CBOR map and the information that it specifies is intrinsically a set of one or more co-existing alternatives, then all the specified alternatives apply for the EDHOC application profile in question. For example, the element "cipher_suites" with value the CBOR array [0, 2] means that, in order to adhere to the EDHOC application profile in question, an EDHOC peer has to implement both the EDHOC cipher suites 0 and 2, because either of them can be used by another EDHOC peer also adhering to the same EDHOC application profile. The CDDL grammar describing the EDHOC_Application_Profile object is:

CDDL Definition of the EDHOC_Application_Profile object int / array, ; methods 9 => int / array, ; cred_types 23 => int, ; app_prof * int / tstr => any } ]]>

Well-known EDHOC Application Profiles This section defines a set of well-known EDHOC application profiles that are meant to reflect what is most common and expected to be supported by EDHOC peers. The well-known application profiles are not to be intended as "default" profiles to use, in case no other indication is provided to EDHOC peers. In particular, an EDHOC peer MUST NOT assume that, unless otherwise indicated, any of such profiles is used when running EDHOC through a well-known EDHOC resource, such as the resource at /.well-known/edhoc when EDHOC messages are transported as payload of CoAP messages (see ). Building on the above, the well-known application profiles are not intended to deviate from what is mandatory to support for EDHOC peers, which is defined by the compliance requirements in . The rest of this section defines the well-known application profiles, each of which is represented by means of an EDHOC_Application_Profile object (see ) using the CBOR extended diagnostic notation. An entry for each well-known application profile is also registered at the "EDHOC Application Profiles" registry defined in of this document.

Well-Known Application Profile MINIMAL_CS_2 This application profile is aligned with the example trace of EDHOC compiled in .

Well-Known Application Profile MINIMAL_CS_0

Well-Known Application Profile BASIC_CS_2_X509 This application profile is aligned with the example trace of EDHOC compiled in .

Well-Known Application Profile BASIC_CS_0_X509 This application profile is aligned with the example trace of EDHOC compiled in .

Well-Known Application Profile BASIC_CS_2_C509

Well-Known Application Profile BASIC_CS_0_C509

Well-Known Application Profile INTERMEDIATE_CS_2 This application profile is aligned with the example trace of EDHOC compiled in .

Well-Known Application Profile INTERMEDIATE_CS_0 This application profile is aligned with the example trace of EDHOC compiled in .

Well-Known Application Profile EXTENSIVE This application profile is aligned with the example traces of EDHOC compiled in Sections and of .

Identifiers of Well-known EDHOC Application Profiles This document defines the following identifiers of well-known EDHOC application profiles. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph. EDHOC Well-known Application Profiles

Profile ID	Name	Description	Reference
0	MINIMAL-CS-2	Method 3; Cipher Suite 2; CCS; kid	[RFC-XXXX]
1	MINIMAL-CS-0	Method 3; Cipher Suite 0; CCS; kid	[RFC-XXXX]
2	BASIC-CS-2-X509	Methods (0, 3); Cipher Suite 2; (CCS, X.509 certificates); (kid, x5t)	[RFC-XXXX]
3	BASIC-CS-0-X509	Methods (0, 3); Cipher Suite 0; (CCS, X.509 certificates); (kid, x5t)	[RFC-XXXX]
4	BASIC-CS-2-C509	Methods (0, 3); Cipher Suite 2; (CCS, C509 certificates); (kid, c5t)	[RFC-XXXX]
5	BASIC-CS_0-C509	Methods (0, 3); Cipher Suite 0; (CCS, C509 certificates); (kid, c5t)	[RFC-XXXX]
6	INTERMEDIATE-CS-2	Methods (0, 3); Cipher Suite 2; (CCS, X.509/C509 certificates); (kid, kccs, x5t, x5chain, c5t, c5c)	[RFC-XXXX]
7	INTERMEDIATE-CS-0	Methods (0, 3); Cipher Suite 0; (CCS, X.509/C509 certificates); (kid, kccs, x5t, x5chain, c5t, c5c)	[RFC-XXXX]
8	EXTENSIVE	Methods (0, 1, 2, 3); Cipher Suites (0, 1, 2, 3); (CCS, CWT, X.509/C509 certificates); (kid, kccs, kcwt, x5t, x5chain, c5t, c5c)	[RFC-XXXX]

Security Considerations TBD

IANA Considerations This document has the following actions for IANA. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.

Media Type Registrations IANA is asked to register the media type "application/edhoc-app-profile+cbor-seq". This registration follows the procedures specified in . Type name: application Subtype name: edhoc-app-profile+cbor-seq Required parameters: N/A Optional parameters: N/A Encoding considerations: Must be encoded as a CBOR sequence of CBOR maps . Each element of each CBOR map is also defined as an element of the CBOR-encoded EDHOC_Information object from . Security considerations: See of [RFC-XXXX]. Interoperability considerations: N/A Published specification: [RFC-XXXX] Applications that use this media type: Applications that need to describe, distribute, and store a representation of an EDHOC application profile (see ). Fragment identifier considerations: N/A Additional information: N/A Person & email address to contact for further information: LAKE WG mailing list (lake@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org) Intended usage: COMMON Restrictions on usage: None Author/Change controller: IETF Provisional registration: No

CoAP Content-Formats Registry IANA is asked to add the following entry to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group. Content Type: application/edhoc-app-profile+cbor-seq Content Coding: - ID: TBD (range 0-255) Reference: [RFC-XXXX]

Target Attributes Registry IANA is asked to register the following entries in the "Target Attributes" registry within the "Constrained RESTful Environments (CoRE) Parameters", as per .

• Attribute Name: ed-max-msgsize
• Brief Description: The admitted maximum size of EDHOC messages in bytes
• Change Controller: IETF
• Reference: [RFC-XXXX]

• Attribute Name: ed-coap-ct
• Brief Description: Requested use of the CoAP Content-Format Option in CoAP messages whose payload includes exclusively an EDHOC message, possibly prepended by an EDHOC connection identifier
• Change Controller: IETF
• Reference: [RFC-XXXX]

• Attribute Name: ed-epid-t
• Brief Description: A supported type of endpoint identity for EDHOC
• Change Controller: IETF
• Reference: [RFC-XXXX]

• Attribute Name: ed-tp
• Brief Description: A supported means for transporting EDHOC messages
• Change Controller: IETF
• Reference: [RFC-XXXX]

• Attribute Name: ed-prof
• Brief Description: A supported EDHOC application profile
• Change Controller: IETF
• Reference: [RFC-XXXX]

• Attribute Name: ed-ta-edcred-uuid
• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other EDHOC peers, as a UUID
• Change Controller: IETF
• Reference: [RFC-XXXX]

• Attribute Name: ed-ta-edcred-kid
• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other EDHOC peers, as a binary key identifier
• Change Controller: IETF
• Reference: [RFC-XXXX]

• Attribute Name: ed-ta-edcred-c5t
• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other EDHOC peers, as a hash of a C509 certificate
• Change Controller: IETF
• Reference: [RFC-XXXX]

• Attribute Name: ed-ta-edcred-c5u
• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other EDHOC peers, as a URI pointing to a C509 certificate
• Change Controller: IETF
• Reference: [RFC-XXXX]

• Attribute Name: ed-ta-edcred-x5t
• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other EDHOC peers, as a hash of an X.509 certificate
• Change Controller: IETF
• Reference: [RFC-XXXX]

• Attribute Name: ed-ta-edcred-x5u
• Brief Description: Identifier of a supported trust anchor for verifying authentication credentials of other EDHOC peers, as a URI pointing to an X.509 certificate
• Change Controller: IETF
• Reference: [RFC-XXXX]

EDHOC Information Registry IANA is asked to register the following entry in the "EDHOC Information" registry defined in .

• Name: app_prof
• CBOR label: 23 (suggested)
• CBOR type: int or array
• Registry: EDHOC Application Profiles registry
• Description: Set of supported EDHOC application profiles
• Specification: [RFC-XXXX]

EDHOC External Authorization Data Registry IANA is asked to register the following entry in the "EDHOC External Authorization Data" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in .

• Name: Supported EDHOC application profiles
• Label: TBD_EAD_LABEL (range 0-23)
• Description: Set of supported EDHOC application profiles
• Reference: [RFC-XXXX]

EDHOC Error Codes Registry IANA is asked to register the following entry in the "EDHOC Error Codes" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in .

• ERR_CODE: TBD_ERROR_CODE (range -24 to 23)
• ERR_INFO Type: app_profiles
• Description: Supported EDHOC application profiles
• Change Controller: IETF
• Reference: [RFC-XXXX]

EDHOC Application Profiles Registry IANA is requested to create a new "EDHOC Application Profiles" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group defined in . The registration policy is either "Private Use", "Standards Action with Expert Review", or "Specification Required" per . "Expert Review" guidelines are provided in . All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per , with Expert Review additionally required per . The procedure for early IANA allocation of Standards Track code points defined in also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the expert(s) early during the process outlined in . The columns of this registry are:

• Profile ID: This field contains the value used to identify the EDHOC application profile. These values MUST be unique. The value can be a positive integer or a negative integer. Different ranges of values use different registration policies . Integer values from -24 to 23 are designated as "Standards Action With Expert Review". Integer values from -65536 to -25 and from 24 to 65535 are designated as "Specification Required". Integer values smaller than -65536 and greater than 65535 are marked as "Private Use".
• Name: This field contains the name of the EDHOC application profile.
• Description: This field contains a short description of the EDHOC application profile.
• Reference: This field contains a pointer to the public specification for the EDHOC application profile.

This registry has been initially populated with the values in .

Expert Review Instructions "Standards Action with Expert Review" and "Specification Required" are two of the registration policies defined for the IANA registry established in this document. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason so they should be given substantial latitude. Expert reviewers should take into consideration the following points:

• Clarity and correctness of registrations. Experts are expected to check the clarity of purpose and use of the requested entries. Experts need to make sure that the object of registration is clearly defined in the corresponding specification. Entries that do not meet these objective of clarity and completeness must not be registered.
• Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate one that is already registered and that the point is likely to be used in deployments. The zones tagged as "Private Use" are intended for testing purposes and closed environments. Code points in other ranges should not be assigned for testing.
• Specifications are required for the "Standards Action With Expert Review" range of point assignment. Specifications should exist for "Specification Required" ranges, but early assignment before a specification is available is considered to be permissible. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.
• Experts should take into account the expected usage of fields when approving point assignment. Documents published via Standards Action can also register points outside the Standards Action range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.

References Normative References A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] 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 specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents. 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. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. 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 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 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. 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. This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. 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 specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. 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. Ericsson Ericsson RISE RISE This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Ephemeral Diffie-Hellman Over COSE (EDHOC) for achieving mutual authentication between an ACE-OAuth client and resource server, and it binds an authentication credential of the client to an ACE-OAuth access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications between the client and resource server when accessing protected resources according to the authorization information indicated in the access token. This profile can be used to delegate management of authorization information from a resource-constrained server to a trusted host with less severe limitations regarding processing power and memory. Ericsson AB Ericsson AB RISE AB RISE AB Nexus Group This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 Certificate Signing Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. 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 The Constrained RESTful Environments (CoRE) specifications apply web technologies to constrained environments. One such important technology is Web Linking (RFC 8288), which CoRE specifications use as the basis for a number of discovery protocols, such as the Link Format (RFC 6690) in the Constrained Application Protocol's (CoAP's) resource discovery process (Section 7.2 of RFC 7252) and the Resource Directory (RD) (RFC 9176). Web Links can have target attributes, the names of which are not generally coordinated by the Web Linking specification (Section 2.2 of RFC 8288). This document introduces an IANA registry for coordinating names of target attributes when used in CoRE. It updates the "RD Parameters" IANA registry created by RFC 9176 to coordinate with this registry. This document contains example traces of Ephemeral Diffie-Hellman Over COSE (EDHOC). ASSA ABLOY Ericsson This document defines a format for transport of hints about Trust Anchors of trusted third parties when using the lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC).

CDDL Model

CDDL model

Document Updates

Version -00 to -01

• Clarified motivation in the abstract and introduction.
• Moved definition of EDHOC_Information parameters to draft-ietf-ace-edhoc-oscore-profile.
• Renamed ed-idep-t x as ed-epid-t.
• Content-Format abbreviated as "ct" (not "cf").
• CBOR abbreviation of "app_prof" changed to 23.
• Added preamble on identifying application profiles by Profile ID.
• Defined target attributes "ed-ta-*" for specifying supported trust anchors.
• Defined new EAD item and error code to advertise supported EDHOC application profiles.
• Defined how to handle non admitted parameters.
• Renamed well-known EDHOC application profiles.
• Updated IANA considerations:
  • Suggested range 0-255 for CoAP Content-Format ID.
  • Requested registration for target attributes "ed-ta-*".
  • Removed requests for registration of removed parameters.
• Updated references.
• Editorial improvements.

Acknowledgments The authors sincerely thank , , , , and for their feedback and comments. The target attributes "ed-ta-*" for specifying supported trust anchors build on a proposal originally described in . This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS.