LAKE Working Group M. Tiloca
Internet-Draft R. Höglund
Intended status: Standards Track RISE AB
Expires: 25 April 2024 23 October 2023
Coordinating the Use of Application Profiles for Ephemeral Diffie-
Hellman Over COSE (EDHOC)
draft-tiloca-lake-app-profiles-00
Abstract
The lightweight authenticated key exchange protocol 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
This note is to be removed before publishing as an RFC.
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.
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."
Tiloca & Höglund Expires 25 April 2024 [Page 1]
Internet-Draft EDHOC Application Profiles October 2023
This Internet-Draft will expire on 25 April 2024.
Copyright Notice
Copyright (c) 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. EDHOC_Information Parameters . . . . . . . . . . . . . . . . 5
3.1. Use in the EDHOC and OSCORE Profile of the ACE
Framework . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Representation of an EDHOC Application Profile . . . . . . . 9
5. Well-known EDHOC Application Profile . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. Media Type Registrations . . . . . . . . . . . . . . . . 12
7.2. CoAP Content-Formats Registry . . . . . . . . . . . . . . 13
7.3. EDHOC Application Profiles Registry . . . . . . . . . . . 13
7.4. Target Attributes Registry . . . . . . . . . . . . . . . 14
7.5. EDHOC Information Registry . . . . . . . . . . . . . . . 14
7.6. Expert Review Instructions . . . . . . . . . . . . . . . 16
8. Normative References . . . . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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.
Tiloca & Höglund Expires 25 April 2024 [Page 2]
Internet-Draft EDHOC Application Profiles October 2023
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 8 of [I-D.ietf-lake-edhoc], applications are
expected to define EDHOC application profiles, which specify the
intended use 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 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].
* Additional parameters for the EDHOC_Information object specified
in [I-D.ietf-ace-edhoc-oscore-profile]. These are defined in
Section 3 and include the new parameter "app_prof", which 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).
1.1. 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.
Tiloca & Höglund Expires 25 April 2024 [Page 3]
Internet-Draft EDHOC Application Profiles October 2023
The reader is expected to be familiar with terms and concepts defined
in EDHOC [I-D.ietf-lake-edhoc], 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.
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
as 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.
Tiloca & Höglund Expires 25 April 2024 [Page 4]
Internet-Draft EDHOC Application Profiles October 2023
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
Figure 1: The Web Link.
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 following new parameters of the
EDHOC_Information object. These are summarized in Figure 2 and
described further below.
Tiloca & Höglund Expires 25 April 2024 [Page 5]
Internet-Draft EDHOC Application Profiles October 2023
+---------------+-------+--------+----------------+-------------------+
| Name | CBOR | CBOR | Registry | Description |
| | Value | Type | | |
+---------------+-------+--------+----------------+-------------------+
| cred_types | 9 | int / | EDHOC | Set of supported |
| | | array | Authentication | types of |
| | | of int | Credential | authentication |
| | | | Types Registry | credentials for |
| | | | | EDHOC |
+---------------+-------+--------+----------------+-------------------+
| id_cred_types | 10 | int / | COSE Header | Set of supported |
| | | tstr / | Parameters | types of |
| | | array | Registry | authentication |
| | | of int | | credential |
| | | or of | | identifiers for |
| | | tstr | | EDHOC |
+---------------+-------+--------+----------------+-------------------+
| eads | 11 | uint / | EDHOC External | Set of supported |
| | | array | Authorization | EDHOC External |
| | | of | Data Registry | Authorization |
| | | uint | | Data (EAD) items |
+---------------+-------+--------+----------------+-------------------+
| initiator | 12 | simple | | Support for the |
| | | value | | EDHOC Initiator |
| | | "true" | | role |
| | | or | | |
| | | "false"| | |
+---------------+-------+--------+----------------+-------------------+
| responder | 13 | simple | | Support for the |
| | | value | | EDHOC Responder |
| | | "true" | | role |
| | | or | | |
| | | "false"| | |
+---------------+-------+--------+----------------+-------------------+
| app_prof | 14 | int / | EDHOC | Set of supported |
| | | array | Application | EDHOC Application |
| | | of int | Profiles | Profiles |
| | | | Registry | |
+---------------+-------+--------+----------------+-------------------+
Figure 2: EDHOC_Information Parameters
* cred_types: This parameter specifies a set of supported types of
authentication credentials for EDHOC (see Section 3.5.2 of
[I-D.ietf-lake-edhoc]). If the set is composed of a single type
of authentication credential, this is encoded as an integer.
Otherwise, the set is encoded as an array of integers, where each
array element encodes one type of authentication credential. In
Tiloca & Höglund Expires 25 April 2024 [Page 6]
Internet-Draft EDHOC Application Profiles October 2023
JSON, the "cred_types" value is an integer or an array of
integers. In CBOR, "cred_types" is an integer or an array of
integers, and has label 9. The integer values are taken from the
"EDHOC Authentication Credential Types" registry defined in
[I-D.ietf-core-oscore-edhoc].
* id_cred_types: This parameter specifies a set of supported types
of authentication credential identifiers for EDHOC (see
Section 3.5.3 of [I-D.ietf-lake-edhoc]). If the set is composed
of a single type of authentication credential identifier, this is
encoded as an integer or a text string. Otherwise, the set is
encoded as an array, where each array element encodes one type of
authentication credential identifier, as an integer or a text
string. In JSON, the "id_cred_types" value is an integer, or a
text string, or an array of integers and text strings. In CBOR,
"id_cred_types" is an integer or a text string, or an array of
integers and text strings, and has label 10. The integer or text
string values are taken from the 'Label' column of the "COSE
Header Parameters" registry [COSE.Header.Parameters].
* eads: This parameter specifies a set of supported EDHOC External
Authorization Data (EAD) items, identified by their ead_label (see
Section 3.8 of [I-D.ietf-lake-edhoc]). If the set is composed of
a single ead_label, this is encoded as an unsigned integer.
Otherwise, the set is encoded as an array of unsigned integers,
where each array element encodes one ead_label. In JSON, the
"eads" value is an unsigned integer or an array of unsigned
integers. In CBOR, "eads" is an unsigned integer or an array of
unsigned integers, and has label 11. The unsigned integer values
are taken from the 'Label' column of the "EDHOC External
Authorization Data" registry defined in [I-D.ietf-lake-edhoc].
* initiator: This parameter specifies whether the EDHOC Initiator
role is supported. In JSON, the "initiator" value is a boolean.
In CBOR, "initiator" is the simple value "true" (0xf5) or "false"
(0xf4), and has label 12.
* responder: This parameter specifies whether the EDHOC Responder
role is supported. In JSON, the "responder" value is a boolean.
In CBOR, "responder" is the simple value "true" (0xf5) or "false"
(0xf4), and has label 13.
* 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
Tiloca & Höglund Expires 25 April 2024 [Page 7]
Internet-Draft EDHOC Application Profiles October 2023
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.
3.1. Use in the EDHOC and OSCORE Profile of the ACE Framework
[ NOTE:
Consider whether to move the content of this section into
[I-D.ietf-ace-edhoc-oscore-profile].
]
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 can include 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.
In such a case, the EDHOC_Information object above 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, the object MUST NOT include other
parameters that provide information pertaining to an EDHOC
application profile. Such parameters MUST be ignored by C, if
present in an EDHOC_Information object that also includes the
"app_prof" parameter.
At the time of writing this document, such parameters are:
* "methods", "cipher_suites", "message_4", "comb_req", "osc_ms_len",
"osc_salt_len", and "osc_version", defined in Section 3.4 of
[I-D.ietf-ace-edhoc-oscore-profile].
* "cred_types", "id_cred_types", "eads", "initiator", and
"responder", defined in Section 3 of this document.
Tiloca & Höglund Expires 25 April 2024 [Page 8]
Internet-Draft EDHOC Application Profiles October 2023
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 Value' 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: "id" and "uri_path".
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.
Tiloca & Höglund Expires 25 April 2024 [Page 9]
Internet-Draft EDHOC Application Profiles October 2023
* 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, ; cred_types
12 => int, ; app_prof
* int / tstr => any
}
[ NOTE:
Based on Sections 3.9 and F of [I-D.ietf-lake-edhoc], further
parameters can be added to the EDHOC_Information object defined in
Section 3.4 of [I-D.ietf-ace-edhoc-oscore-profile], and then used for
the EDHOC_Application_Profile defined in this document. For example:
* The way(s) to express the identity of endpoints within
authentication credentials, e.g., EUI-64.
* 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].
Tiloca & Höglund Expires 25 April 2024 [Page 10]
Internet-Draft EDHOC Application Profiles October 2023
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.
]
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.
Tiloca & Höglund Expires 25 April 2024 [Page 11]
Internet-Draft EDHOC Application Profiles October 2023
7.1. 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 [I-D.ietf-lake-edhoc]).
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
Tiloca & Höglund Expires 25 April 2024 [Page 12]
Internet-Draft EDHOC Application Profiles October 2023
7.2. CoAP Content-Formats Registry
IANA is asked to add the following entry to the "CoAP Content-
Formats" registry within the "CoRE Parameters" registry group.
Content Type: application/edhoc-app-profile+cbor-seq
Content Coding: -
ID: TBD
Reference: [RFC-XXXX]
7.3. 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 [I-D.ietf-lake-edhoc].
The registry uses the "Expert Review" registration procedure
[RFC8126]. Expert Review guidelines are provided in Section 7.6.
Values in this registry are covered by different registration
policies as indicated. It should be noted that, in addition to the
expert review, some portions of the registry require a specification,
potentially a Standards Track RFC, to be supplied as well.
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.
Tiloca & Höglund Expires 25 April 2024 [Page 13]
Internet-Draft EDHOC Application Profiles October 2023
* Reference: This field contains a pointer to the public
specification for the EDHOC application profile.
7.4. Target Attributes Registry
IANA is asked to register the following entry in the "Target
Attributes" registry within the "CoRE Parameters" registry group, as
per [I-D.ietf-core-target-attr].
* Attribute Name: ed-prof
* Brief Description: A supported EDHOC application profile
* Change Controller: IETF
* Reference: [RFC-XXXX]
7.5. 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: cred_types
* CBOR Value: 9
* CBOR Type: int / array of int
* Registry: EDHOC Authentication Credential Types Registry
* Description: Set of supported types of authentication credentials
for EDHOC
* Specification: [RFC-XXXX], [I-D.ietf-lake-edhoc]
* Name: id_cred_types
* CBOR Value: 10
* CBOR Type: int / tstr / array of int or of tstr
* Registry: COSE Header Parameters Registry
* Description: Set of supported types of authentication credential
identifiers for EDHOC
Tiloca & Höglund Expires 25 April 2024 [Page 14]
Internet-Draft EDHOC Application Profiles October 2023
* Specification: [RFC-XXXX], [I-D.ietf-lake-edhoc]
* Name: eads
* CBOR Value: 11
* CBOR Type: uint / array of uint
* Registry: EDHOC External Authorizaton Data Registry
* Description: Set of supported EDHOC External Authorization Data
(EAD) items
* Specification: [RFC-XXXX], [I-D.ietf-lake-edhoc]
* Name: initiator
* CBOR Value: 12
* CBOR Type: simple value "true" / simple value "false"
* Registry: -
* Description: Support for the EDHOC Initiator role
* Specification: [RFC-XXXX], [I-D.ietf-lake-edhoc]
* Name: responder
* CBOR Value: 13
* CBOR Type: simple value "true" / simple value "false"
* Registry: -
* Description: Support for the EDHOC Responder role
* Specification: [RFC-XXXX], [I-D.ietf-lake-edhoc]
* Name: app_prof
Tiloca & Höglund Expires 25 April 2024 [Page 15]
Internet-Draft EDHOC Application Profiles October 2023
* CBOR Value: 14
* CBOR Type: int / array of int
* Registry: EDHOC Application Profiles Registry
* Description: Set of supported EDHOC Application Profiles
* Specification: [RFC-XXXX], [I-D.ietf-lake-edhoc]
7.6. Expert Review Instructions
The IANA registry established in this document is defined as "Expert
Review". 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
Tiloca & Höglund Expires 25 April 2024 [Page 16]
Internet-Draft EDHOC Application Profiles October 2023
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.
8. Normative References
[COSE.Header.Parameters]
IANA, "COSE Header Parameters",
<https://www.iana.org/assignments/cose/cose.xhtml#header-
parameters>.
[I-D.ietf-ace-edhoc-oscore-profile]
Selander, G., Mattsson, J. P., Tiloca, M., and R. Höglund,
"Ephemeral Diffie-Hellman Over COSE (EDHOC) and Object
Security for Constrained Environments (OSCORE) Profile for
Authentication and Authorization for Constrained
Environments (ACE)", Work in Progress, Internet-Draft,
draft-ietf-ace-edhoc-oscore-profile-03, 23 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ace-
edhoc-oscore-profile-03>.
[I-D.ietf-core-oscore-edhoc]
Palombini, F., Tiloca, M., Höglund, R., Hristozov, S., and
G. Selander, "Using EDHOC with CoAP and OSCORE", Work in
Progress, Internet-Draft, draft-ietf-core-oscore-edhoc-09,
13 October 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-oscore-edhoc-09>.
[I-D.ietf-core-target-attr]
Bormann, C., "CoRE Target Attributes Registry", Work in
Progress, Internet-Draft, draft-ietf-core-target-attr-06,
11 October 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-core-target-attr-06>.
[I-D.ietf-lake-edhoc]
Selander, G., Mattsson, J. P., and F. Palombini,
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in
Progress, Internet-Draft, draft-ietf-lake-edhoc-22, 25
August 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-lake-edhoc-22>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Tiloca & Höglund Expires 25 April 2024 [Page 17]
Internet-Draft EDHOC Application Profiles October 2023
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/rfc/rfc6690>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/rfc/rfc6838>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/rfc/rfc7252>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/rfc/rfc8288>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/rfc/rfc8613>.
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/rfc/rfc8742>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
Tiloca & Höglund Expires 25 April 2024 [Page 18]
Internet-Draft EDHOC Application Profiles October 2023
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/rfc/rfc9200>.
Acknowledgments
The authors sincerely thank Christian Amsüss and Göran Selander for
their feedback and comments.
Authors' Addresses
Marco Tiloca
RISE AB
Isafjordsgatan 22
SE-16440 Stockholm Kista
Sweden
Email: marco.tiloca@ri.se
Rikard Höglund
RISE AB
Isafjordsgatan 22
SE-16440 Stockholm Kista
Sweden
Email: rikard.hoglund@ri.se
Tiloca & Höglund Expires 25 April 2024 [Page 19]