]> 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 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 . 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. 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 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 , where to register identifiers of EDHOC application profiles.
• The new target attribute "ed-prof" defined in , which can be used in a web link to an EDHOC resource. This can be used, for instance, in a link-format document describing EDHOC resources at a server, when EDHOC is transferred over CoAP , see as well as .
• Additional parameters for the EDHOC_Information object specified in . These are defined in and include the new parameter "app_prof", which can be used, for example, in the EDHOC and OSCORE profile of the ACE framework 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 ), as well as a well-known EDHOC application profile (see ).

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.

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 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 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., ), which, if present, MUST be ignored by the recipient. The example in 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 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.

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 ]]>

EDHOC_Information Parameters 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 and described further below.

EDHOC_Information Parameters

• cred_types: This parameter specifies a set of supported types of authentication credentials for EDHOC (see ). 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 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 .
• id_cred_types: This parameter specifies a set of supported types of authentication credential identifiers for EDHOC (see ). 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 .
• eads: This parameter specifies a set of supported EDHOC External Authorization Data (EAD) items, identified by their ead_label (see ). 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 .
• 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 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 of this document.

Use in the EDHOC and OSCORE Profile of the ACE Framework [ NOTE: Consider whether to move the content of this section into . ] 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 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 .
• "cred_types", "id_cred_types", "eads", "initiator", and "responder", defined in of this document.

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 defined in , and thus uses the corresponding CBOR abbreviations from the 'CBOR Value' column of the "EDHOC Information" registry defined in . 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 and of and with :

• 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 , 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: int / array, ; methods 9 => int, ; cred_types 12 => int, ; app_prof * int / tstr => any } ]]> [ NOTE: Based on Sections and of , further parameters can be added to the EDHOC_Information object defined in , 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 and of . 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.

]

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 (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 , 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 . 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 "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 . The registry uses the "Expert Review" registration procedure . Expert Review guidelines are provided in . 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 :
  • 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 "CoRE Parameters" registry group, as per .

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

• 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],

• 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
• Specification: [RFC-XXXX],

• 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],

• Name: initiator
• CBOR Value: 12
• CBOR Type: simple value "true" / simple value "false"
• Registry: -
• Description: Support for the EDHOC Initiator role
• Specification: [RFC-XXXX],

• Name: responder
• CBOR Value: 13
• CBOR Type: simple value "true" / simple value "false"
• Registry: -
• Description: Support for the EDHOC Responder role
• Specification: [RFC-XXXX],

• Name: app_prof
• CBOR Value: 14
• CBOR Type: int / array of int
• Registry: EDHOC Application Profiles Registry
• Description: Set of supported EDHOC Application Profiles
• Specification: [RFC-XXXX],

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 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 In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This 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. 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. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This 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. Ericsson AB Ericsson AB Ericsson AB 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 OSCORE security context. By reusing COSE for cryptography, CBOR for encoding, and CoAP for transport, the additional code size can be kept very low. Universität Bremen TZI The Constrained RESTful Environments (CoRE) specifications apply Web technologies to constrained environments. One important such 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 CoAP's Resource Discovery Protocol (Section 7.2 of RFC7252) 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. Ericsson RISE AB RISE AB Fraunhofer AISEC Ericsson The lightweight authenticated key exchange protocol EDHOC can be run over CoAP and used by two peers to establish an OSCORE Security Context. This document details this use of the EDHOC protocol, by specifying a number of additional and optional mechanisms. These especially include 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 OAuth 2.0 Client and Resource Server, and it binds an authentication credential of the Client to an OAuth 2.0 access token. EDHOC also establishes an Object Security for Constrained RESTful Environments (OSCORE) Security Context, which is used to secure communications 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. IANA

Acknowledgments The authors sincerely thank and for their feedback and comments.