Coordinating the Use of Application Profiles for Ephemeral Diffie-Hellman Over COSE (EDHOC)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 5 September 2024.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Ephemeral Diffie-Hellman Over COSE (EDHOC) [I-D.ietf-lake-edhoc] 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 [I-D.ietf-lake-edhoc], 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 [I-D.ietf-lake-edhoc] 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).¶

2. 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 [I-D.ietf-lake-edhoc]). 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 [I-D.ietf-lake-edhoc]. This allows a client to obtain relevant pieces of information from 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', the link MUST NOT include other target attributes that provide information pertaining to an EDHOC application profile (see, e.g., Section 6 of [I-D.ietf-core-oscore-edhoc]), which, if present, MUST be ignored by the recipient.¶

The example in Figure 1 shows how a CoAP client discovers two EDHOC resources at a CoAP server, obtaining information elements from the respective application profile. 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.¶

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

3. 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 Figure 2 and described further below.¶

+----------+-------+-------+-------------+-----------------+
| Name     | CBOR  | CBOR  | Registry    | Description     |
|          | label | type  |             |                 |
+----------+-------+-------+-------------+-----------------+
| app_prof | 14    | int / | EDHOC       | Set of          |
|          |       | array | Application | supported EDHOC |
|          |       |       | Profiles    | Application     |
|          |       |       | Registry    | 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.¶

4. 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 following elements defined for the EDHOC_Information object MUST also be present: "methods" and "cred_types".¶

The following elements defined for the EDHOC_Information object MUST NOT be present: "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 [I-D.ietf-lake-edhoc] 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 [I-D.ietf-lake-edhoc], 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 [I-D.ietf-lake-edhoc]).¶

• 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 [I-D.ietf-lake-edhoc].¶

    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 [I-D.ietf-lake-edhoc] 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".¶

]¶

5. 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 [I-D.ietf-lake-edhoc] (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 [I-D.ietf-lake-edhoc], 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.¶

]¶

6. Security Considerations

TBD¶

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

Acknowledgments

The authors sincerely thank Christian Amsüss, Göran Selander, and Brian Sipos for their feedback and comments.¶

Authors' Addresses