]> RISE AB

Isafjordsgatan 22 Kista 164 40 Sweden marco.tiloca@ri.se

RISE AB

Isafjordsgatan 22 Kista 164 40 Sweden rikard.hoglund@ri.se

Inria

elsa.lopez-perez@inria.fr

SEC LAKE Working Group Internet-Draft The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) allows two peers to compute a shared secret session key. Once the session key is available, the two peers can use the EDHOC_Exporter interface, e.g., to derive keying material for an application protocol. This document defines an in-band approach that can be used by the two peers to agree about the lengths of the outputs produced with the EDHOC_Exporter interface. The defined approach relies on an EDHOC External Authorization Data (EAD) item that can be exchanged in the first two EDHOC messages of an EDHOC session. 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. Two peers participate in the EDHOC protocol, i.e., a peer acts as EDHOC Initiator and starts an EDHOC session with another peer acting as EDHOC Responder. The main output of a successfully completed EDHOC session is the shared secret session key PRK_out (see ). After having established PRK_out, the two peers can use the EDHOC_Exporter interface defined in , e.g., to derive keying material for an application protocol. Among its inputs, the EDHOC_Exporter interface includes "exporter_label" as a registered numeric identifier of the intended output and "length" as the length in bytes of the intended output. At the time of writing, notable uses of the EDHOC_Exporter interface include the derivation of:

• The Master Secret and Master Salt to use for establishing a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE) . These derivations are specified in .
• A symmetric Pre-Shared Key rPSK to use for session resumption in EDHOC and the corresponding credential identifier rID_CRED_PSK . These derivations are specified in .

When using the EDHOC_Exporter interface, it is crucial that the two peers agree about the length in bytes of each intended output, in order to ensure the correctness of their operations. To this end, the two peers can rely on pre-defined default lengths, or agree out-of-band on alternative lengths. However, the two peers might need or prefer to explicitly agree about specific output lengths to use on a per-session basis. This document defines an in-band approach that the two peers can use to agree about the lengths of the outputs produced with the EDHOC_Exporter interface. The defined approach relies on an EDHOC External Authorization Data (EAD) item (see ), which the two peers can exchange in the first two EDHOC messages of an EDHOC session.

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. Readers are expected to be familiar with the terms and concepts related to EDHOC , Concise Data Definition Language (CDDL) , and Concise Binary Object Representation (CBOR) . Examples throughout this document are expressed in CBOR diagnostic notation as defined in and . Diagnostic notation comments are often used to provide a textual representation of the numeric parameter names and values.

EAD Item "EDHOC_Exporter Output Lengths" This section defines the EDHOC EAD item "EDHOC_Exporter Output Lengths", which is registered in of this document. The EAD item MAY be included:

• In the EAD_1 field of EDHOC message_1, in order to specify the output lengths that the Initiator wishes to use with the EDHOC_Exporter interface in the present EDHOC session.
• In the EAD_2 field of EDHOC message_2, in order to specify the output lengths that the Responder wishes to use with the EDHOC_Exporter interface in the present EDHOC session.

Within an EAD_1 field or EAD_2 field, the EAD item MUST NOT occur more than once. The EAD item MUST NOT be included in the EAD fields of EDHOC message_3 or message_4. When the EAD item is present, its ead_label TBD_EAD_LABEL MUST be used only with negative sign, i.e., the use of the EAD item is always critical (see Section 3.8 of ). The EAD item MUST specify an ead_value, as a CBOR byte string with value the binary representation of a CBOR sequence , namely EXP_LEN_SEQ. As specified below, the CBOR sequence is composed of pairs of items, with the order of pairs having no meaning. Each pair (X, Y) of the CBOR sequence MUST be as follows.

• The first element X is a CBOR unsigned integer, specifying the value to use as first argument "exporter_label" when invoking the EDHOC_Exporter interface (see Section 4.2.1 of ). The unsigned integer value is taken from the 'Label' column of the "EDHOC Exporter Labels" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group .
• The second element Y is a CBOR unsigned integer, specifying the value to use as third argument "length" when invoking the EDHOC_Exporter interface using the value specified by X as first argument "exporter_label" (see Section 4.2.1 of ). The value specified by Y MUST be a valid value to use as "length" when using the value specified by X as "exporter_label". For example, when X specifies 0 as the "exporter_label" to derive an OSCORE Master Secret , Y is required to be not less than the "length" default value defined in , i.e., the key length (in bytes) of the application AEAD Algorithm of the selected cipher suite for the EDHOC session.

In the EAD item, ead_value MUST NOT specify multiple pairs that encode the same unsigned integer value in their first element X. The CDDL grammar describing the ead_value for the EAD item "EDHOC_Exporter Output Lengths" is provided in .

CDDL Definition of ead_value for the EAD Item "EDHOC_Exporter Output Lengths" > ; This defines an array, the elements of which ; are to be used in the CBOR Sequence EXP_LEN_SEQ: EXP_LEN_SEQ = [* pair] pair = ( exporter_label: uint, length: uint ) ]]>

An example of ead_value in CBOR diagnostic notation is provided in . In the example, ead_value indicates the wish to use the EDHOC_Exporter interface to derive an OSCORE Master Secret and an OSCORE Master Salt as per , such that:

• the OSCORE Master Secret (exporter_label: 0) has a length of 32 bytes; and
• the OSCORE Master Salt (exporter_label: 1) has a length of 16 bytes.

Example of ead_value for the EAD Item "EDHOC_Exporter Output Lengths" in CBOR Diagnostic Notation > ]]>

That is, assuming the second argument "context" of the EDHOC_Exporter interface to be the empty CBOR byte string (i.e., h'' in CBOR diagnostic notation), the example above is consistent with performing the following two invocations of the EDHOC_Exporter interface:

Processing at the Recipient Side In case the recipient peer supports the EAD item, the recipient peer MUST silently ignore the EAD item "EDHOC_Exporter Output Lengths" if this is specified in the EAD_3 field of EDHOC message_3 or in the EAD_4 field of EDHOC message_4. Upon receiving an EDHOC message_1 or EDHOC message_2 whose EAD field includes the EAD item "EDHOC_Exporter Output Lengths", the recipient peer MUST abort the EDHOC session and MUST reply with an EDHOC error message with error code (ERR_CODE) 1, if any of the following occurs:

• the EAD field includes multiple occurrences of the EAD item "EDHOC_Exporter Output Lengths";
• ead_value is malformed or does not conform with what is defined in ;
• the recipient peer does not recognize the value encoded by the first element X of a pair (X, Y) as a valid "exporter_label" to be used when invoking the EDHOC_Exporter interface;
• in a pair (X, Y), the value encoded by the second element Y is not valid to be used as "length" when invoking the EDHOC_Exporter interface using the value encoded by the first element X as "exporter_label"; or
• for a pair (X, Y), the recipient peer is not going to be able to invoke the EDHOC_Exporter interface using the values encoded by X and Y as the first argument "exporter_label" and the third argument "length", respectively.

If the Responder has received an EDHOC message_1 including the EAD item "EDHOC_Exporter Output Lengths" and the Responder includes the EAD item "EDHOC_Exporter Output Lengths" in EDHOC message_2, then the following applies. Within ead_value of the EAD item included in EDHOC message_2, the Responder MUST NOT specify any pair (X, Y) such that the unsigned integer value encoded by X was encoded by the first element of a pair of the EAD item included in the received EDHOC message_1. If the Initiator receives an EDHOC message_2 including the EAD item "EDHOC_Exporter Output Lengths" after having sent an EDHOC message_1 including the EAD item "EDHOC_Exporter Output Lengths", then the following applies. The Initiator MUST abort the EDHOC session and MUST reply with an EDHOC error message with error code (ERR_CODE) 1, if ead_value of the EAD item included in EDHOC message_2 specifies any pair (X, Y) such that the unsigned integer value encoded by X was encoded by the first element of a pair of the EAD item included in the sent EDHOC message_1. In an EDHOC session during which the EAD item "EDHOC_Exporter Output Lengths" has been included in EDHOC message_1 and/or message_2, the following applies.

• The Initiator (Responder) considers the successful verification of EDHOC message_2 (message_3) as a confirmed agreement with the other peer about how to invoke the EDHOC_Exporter interface, once the session key PRK_out for the present EDHOC session is available. That is, for each pair (X, Y) specified by the exchanged EAD items, the two peers MUST use the unsigned integer values encoded by X and Y as the first argument "exporter_label" and the third argument "length", respectively.
• If a particular "exporter_label" value is not specified by the exchanged EAD items, then a possible invocation of the EDHOC_Exporter interface using that value as its first argument takes as value for its third argument "length" a pre-defined default value, or an alternative value agreed out-of-band.

Security Considerations The same security considerations for EDHOC from hold for this document. Furthermore, the following considerations apply. 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.

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

• Name: EDHOC_Exporter Output Lengths
• Label: TBD_EAD_LABEL (range 0-23)
• Description: Set of output lengths to use with the EDHOC_Exporter interface
• Reference: [RFC-XXXX]

References Normative References 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 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 document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References 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. Inria Ericsson Ericsson University of Murcia This document specifies a Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) key exchange protocol. The PSK method enhances computational efficiency while providing mutual authentication, ephemeral key exchange, identity protection, and quantum resistance. It is particularly suited for systems where nodes share a PSK provided out-of-band (external PSK) and enables efficient session resumption with less computational overhead when the PSK is provided from a previous EDHOC session (resumption PSK). This document details the PSK method flow, key derivation changes, message formatting, processing, and security considerations.

Acknowledgments The authors sincerely thank for his comments and feedback. This work was supported by the Sweden's Innovation Agency VINNOVA within the EUREKA CELTIC-NEXT project CYPRESS.