Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC)
Internet-Draft draft-tiloca-lake-app-profiles-02
Marco Tiloca
RISE AB
Isafjordsgatan 22
Kista
16440 Stockholm
Sweden
marco.tiloca@ri.se
Rikard Höglund
RISE AB
Isafjordsgatan 22
Kista
16440 Stockholm
Sweden
rikard.hoglund@ri.se
08 July 2024
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. This document defines a number of means to coordinate the use and discovery 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, it defines a well-known EDHOC application profile.
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 https://mailarchive.ietf.org/arch/browse/lake/.
Source for this draft and an issue tracker can be found at https://gitlab.com/crimson84/draft-tiloca-lake-app-profiles.
Introduction
Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] is a lightweight authenticated key exchange protocol, especially intended for use in constrained scenarios.
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 Section 3.9 of [RFC9528], 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.
This document defines a number of means to coordinate the use and discovery of EDHOC application profiles, that is:
- The new IANA registry "EDHOC Application Profiles" defined in Section 7.3, where to register integer identifiers of EDHOC application profiles.
- The new target attribute "ed-prof" defined in Section 2, which can be used in a web link [RFC8288] to an EDHOC resource. This can be used, for instance, in a link-format document [RFC6690] describing EDHOC resources at a server, when EDHOC is transferred over CoAP [RFC7252] (see Appendix A.2 of [RFC9528] as well as [I-D.ietf-core-oscore-edhoc]).
- The new parameter "app_prof" for the EDHOC_Information object specified in [I-D.ietf-ace-edhoc-oscore-profile]. The parameter is defined in Section 3, and can be used, for example, in the EDHOC and OSCORE profile of the ACE framework [I-D.ietf-ace-edhoc-oscore-profile] to indicate the EDHOC application profiles supported by a Resource Server.
Furthermore, this document defines a canonical, CBOR-based representation that can be used to describe, distribute, and store EDHOC application profiles (see Section 4), as well as a well-known EDHOC application profile (see Section 5).
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 [RFC2119] [RFC8174] 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 [RFC9528], and with the use of EDHOC with CoAP [RFC7252] and OSCORE [RFC8613] defined in [I-D.ietf-core-oscore-edhoc].
Concise Binary Object Representation (CBOR) [RFC8949] and Concise Data Definition Language (CDDL) [RFC8610] 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.
Web Linking
Section 6 of [I-D.ietf-core-oscore-edhoc] defines a number of target attributes that can be used in a web link [RFC8288] with resource type "core.edhoc" (see Section 10.10 of [RFC9528]). This is the case, e.g., when using a link-format document [RFC6690] describing EDHOC resources at a server, when EDHOC is transferred over CoAP [RFC7252] as defined in Appendix A.2 of [RFC9528]. 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 Section 7.3 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., Section 6 of [I-D.ietf-core-oscore-edhoc]), 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 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 Figure 1 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 Section 5 of [RFC6690] 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.

REQ: GET /.well-known/core

RES: 2.05 Content
    </sensors/temp>;osc,
    </sensors/light>;if=sensor,
    </.well-known/edhoc>;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,
    </edhoc-alt>;rt=core.edhoc;ed-prof=500;ed-ead=333

EDHOC_Information Parameters
Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile] 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 Table 1 and described further below.
EDHOC_Information Parameter "app_prof"
Name | CBOR label | CBOR type | Registry | Description
app_prof | 14 | 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 14. The integer values are taken from the 'Profile ID' column of the "EDHOC Application Profiles" registry defined in Section 7.3 of this document.
Use in the EDHOC and OSCORE Profile of the ACE Framework
Section 3.2 of [I-D.ietf-ace-edhoc-oscore-profile] 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) [RFC9200].
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 "edhoc_info" claim, with value an EDHOC_Information object.
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", "osc_ms_len", "osc_salt_len", "osc_version", "cred_types", "id_cred_types", "initiator", and "responder". These are all defined in Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile].
- If the EDHOC_Information object 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 RS 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".
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 [RFC8949]. Each element of the CBOR map is an element of the CBOR-encoded EDHOC_Information object defined in Section 3.3 of [I-D.ietf-ace-edhoc-oscore-profile], and thus uses the corresponding CBOR abbreviations from the 'CBOR label' column of the "EDHOC Information" registry defined in [I-D.ietf-ace-edhoc-oscore-profile].
The CBOR map encoding the EDHOC application profile MUST include the element "app_prof" defined in this document. Its value is the unique identifier of the EDHOC application profile in question, 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".
The CBOR map MAY include other elements defined for the EDHOC_Information object. Consistently with Sections 8 and A.1 of [RFC9528] and with Section 5.4 of [RFC8613]:
- 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.
- 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.
- If the element "osc_ms_len" is not present in the CBOR map, this indicates that, when using EDHOC to key OSCORE [RFC8613], 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:

EDHOC_Application_Profile = {
      1 => int / array,    ; methods
      9 => int / array,    ; cred_types
     14 => int,            ; app_prof
   * int / tstr => any
}

[ NOTE:
Based on Sections 3.9 and F of [RFC9528], further parameters can be defined for the EDHOC_Information object specified in Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile], and then used for the EDHOC_Application_Profile object defined in this document. For example:
- The way(s) to express the identity of endpoints within authentication credentials, e.g., EUI-64.
- Limitations in the size of EDHOC messages (see Section 3.4 of [RFC9528]).
- The transport(s) to use for EDHOC. How to indicate that? It is actually about multiple pieces of information, often transport-dependent.
  - For example, if CoAP is indicated, it should be said over what CoAP is in turn transported, if any of the EDHOC-related CoAP Content-Format has to be indicated, etc. See, for instance, point 1 in Sections 3.9 and F of [RFC9528].
This might require another registry about "transport suites" to be used with EDHOC, each of which registered with a unique identifier, specifying the transport protocol together with additional (transport-dependent) pieces of information.
  - At the same time, Section 3.9 of [RFC9528] says:
"Note that it is not necessary for the endpoints to specify a single transport for the EDHOC messages. For example, a mix of CoAP and HTTP may be used along the path, and this may still allow correlation between messages."
In order to take this into account, an application profile can specify two sets of supported transports, i.e., with a parameter "tp_i" pertaining to an Initiator that uses this profile and a parameter "tp_r" pertaining to a Responder that uses this profile. The two sets can independently specify the expected support for multiple transports, each together with related transport-dependent information.
In order to handle the case where both "tp_i" and "tp_r" are equal, a single parameter "tp" can be used instead. In that case, an Initiator and a Responder using this profile are expected to use any of the transports from the set specified by the parameter "tp".
]
Well-known EDHOC Application Profile
TBD
[ NOTE:
This well-known EDHOC application profile is not intended to be a "default" profile to use, in case no other indication is provided to the EDHOC peers.
With particular reference to using EDHOC with CoAP, it must not be silently assumed that, unless otherwise indicated, the EDHOC resource at /.well-known/edhoc is used according to such a well-known profile.
If this well-known EDHOC application profile was treated as a "default" profile, it might be suggesting what is generally mandatory to implement, which is instead limited to what is already defined by the compliance requirements in Section 8 of [RFC9528] (i.e., simply support for "kid" as type of credential identifier, as well as for cipher suites 2 and 3).
That is, this well-known EDHOC application profile is not intended to practically replace the compliance requirements from Section 8 of [RFC9528], which defines what is a de-facto, unnamed default EDHOC application profile.
Instead, this well-known EDHOC application profile should reflect what is the most common and expected way to use EDHOC.
]
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 [RFC6838].
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 [RFC8742] of CBOR maps. Each element of each CBOR map is also defined as an element of the CBOR-encoded EDHOC_Information object from Section 3.3 of [I-D.ietf-ace-edhoc-oscore-profile].
Security considerations: See Section 6 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 Section 3.9 of [RFC9528]).
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
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 [RFC9528].
As registration policy, the registry uses either "Standards Action with Expert Review", or "Specification Required" per Section 4.6 of [RFC8126]. Expert Review guidelines are provided in Section 7.6.
All assignments according to "Standards Action with Expert Review" are made on a "Standards Action" basis per Section 4.9 of [RFC8126], with Expert Review additionally required per Section 4.5 of [RFC8126]. The procedure for early IANA allocation of Standards Track code points defined in [RFC7120] also applies. When such a procedure is used, review and approval by the designated expert are also required, in order for the WG chairs to determine that the conditions for early allocation are met (see step 2 in Section 3.1 of [RFC7120]).
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 an unsigned integer or a negative integer. Different ranges of values use different registration policies [RFC8126]:
  - 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.
Target Attributes Registry
IANA is asked to register the following entry in the "Target Attributes" registry within the "Constrained RESTful Environments (CoRE) Parameters", as per [RFC9423].
- Attribute Name: ed-prof
- Brief Description: A supported EDHOC application profile
- Change Controller: IETF
- Reference: [RFC-XXXX]
EDHOC Information Registry
IANA is asked to register the following entry in the "EDHOC Information" registry defined in [I-D.ietf-ace-edhoc-oscore-profile].
- Name: app_prof
- CBOR label: 14
- CBOR type: int or array
- Registry: EDHOC Application Profiles Registry
- Description: Set of supported EDHOC Application Profiles
- Specification: [RFC-XXXX], [RFC9528]
Expert Review Instructions
The IANA registry established in this document is defined as "Standards Action with Expert Review" or "Specification Required", depending on the range of values for which an assignment is requested. 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 registered identifiers indicate an EDHOC application profile that is clearly defined in the corresponding specification. Identifiers of EDHOC application profiles 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. The fact that there is a range for Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that 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.
Normative References
[RFC6690]

Constrained RESTful Environments (CoRE) Link Format
Z. Shelby
August 2012
RFC 6690
DOI 10.17487/RFC6690
[RFC6838]

Media Type Specifications and Registration Procedures
N. Freed
J. Klensin
T. Hansen
January 2013
BCP 13
RFC 6838
DOI 10.17487/RFC6838
[RFC7120]

Early IANA Allocation of Standards Track Code Points
M. Cotton
January 2014
BCP 100
RFC 7120
DOI 10.17487/RFC7120
[RFC7252]

The Constrained Application Protocol (CoAP)
Z. Shelby
K. Hartke
C. Bormann
June 2014
RFC 7252
DOI 10.17487/RFC7252
[RFC8126]

Guidelines for Writing an IANA Considerations Section in RFCs
M. Cotton
B. Leiba
T. Narten
June 2017
BCP 26
RFC 8126
DOI 10.17487/RFC8126
[RFC8288]

Web Linking
M. Nottingham
October 2017
RFC 8288
DOI 10.17487/RFC8288
[RFC8610]

Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
H. Birkholz
C. Vigano
C. Bormann
June 2019
RFC 8610
DOI 10.17487/RFC8610
[RFC8613]

Object Security for Constrained RESTful Environments (OSCORE)
G. Selander
J. Mattsson
F. Palombini
L. Seitz
July 2019
RFC 8613
DOI 10.17487/RFC8613
[RFC8742]

Concise Binary Object Representation (CBOR) Sequences
C. Bormann
February 2020
RFC 8742
DOI 10.17487/RFC8742
[RFC8949]

Concise Binary Object Representation (CBOR)
C. Bormann
P. Hoffman
December 2020
STD 94
RFC 8949
DOI 10.17487/RFC8949
[RFC9200]

Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)
L. Seitz
G. Selander
E. Wahlstroem
S. Erdtman
H. Tschofenig
August 2022
RFC 9200
DOI 10.17487/RFC9200
[RFC9423]

Constrained RESTful Environments (CoRE) Target Attributes Registry
C. Bormann
April 2024
RFC 9423
DOI 10.17487/RFC9423
[RFC9528]

Ephemeral Diffie-Hellman Over COSE (EDHOC)
G. Selander
J. Preuß Mattsson
F. Palombini
March 2024
RFC 9528
DOI 10.17487/RFC9528
[I-D.ietf-core-oscore-edhoc]

Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE)
Francesca Palombini
Ericsson
Marco Tiloca
RISE AB
Rikard Höglund
RISE AB
Stefan Hristozov
Fraunhofer AISEC
Göran Selander
Ericsson
9 April 2024
Internet-Draft draft-ietf-core-oscore-edhoc-11
[I-D.ietf-ace-edhoc-oscore-profile]

Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object Security for Constrained Environments (OSCORE) Profile for Authentication and Authorization for Constrained Environments (ACE)
Göran Selander
Ericsson
John Preuß Mattsson
Ericsson
Marco Tiloca
RISE
Rikard Höglund
RISE
4 March 2024
Internet-Draft draft-ietf-ace-edhoc-oscore-profile-04
[COSE.Header.Parameters]

COSE Header Parameters
IANA
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Acknowledgments
The authors sincerely thank Christian Amsüss, Göran Selander, and Brian Sipos for their feedback and comments.
This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS.