]> RISE AB

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

Robert Bosch GmbH

Markwiesenstraße 58 Reutlingen 72770 Germany Tobias.Mueller9@de.bosch.com

Security LAKE Working Group Internet-Draft This document adds Private Use ranges to IANA registries that pertain to the Lightweight Authenticated Key Exchange (LAKE) protocol. 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 The Lightweight Authenticated Key Exchange (LAKE) protocol provides points of extensibility, for which related IANA registries exist. When they were created, some of those registries did not include ranges with registration procedure "Private Use" (see ). Later on, it was brought to attention that having such ranges available would be convenient for private deployments. Private Use ranges enable controlled proprietary ecosystems to use LAKE extensibility points consistently without making their application-specific protocol semantics public. They also support the development and testing of additional LAKE-based procedures before a decision is made to specify them publicly. Furthermore, Private Use ranges separate locally chosen values from IANA-assigned values, preserving the other ranges for publicly specified uses. Deployments using Private Use values are responsible for preventing collisions within their intended scope; independent deployments might use the same value differently. This document rectifies the original situation: As specified in , it adds Private Use ranges to three IANA registries of the LAKE protocol that originally did not include such ranges.

Terminology This document uses the acronym LAKE, expanded to Lightweight Authenticated Key Exchange, to denote the protocol specified as EDHOC in . Identifiers defined literally in or in IANA registries (e.g., the names of the EDHOC registries themselves) are unchanged.

Use of Values from Private Use Ranges

Range Boundaries and Encoding The Private Use ranges defined in extend beyond the values that are admitted by the existing ranges with other registration policies in the same IANA registries. The values admitted by the new Private Use ranges are bounded by the values that can be encoded as CBOR integers with a four-byte argument (see ). For an unsigned integer N, a four-byte argument makes it possible to represent values of N up to 4294967295. For a negative integer N, a four-byte argument encodes the absolute value of N minus 1 and thus makes it possible to represent values of N down to -4294967296. Together with the initial byte of the CBOR integer, these encodings result in a total of five bytes. These bounds preserve the existing ranges for registry values that result in shorter encodings, while limiting the newly defined Private Use ranges to values with five-byte encodings. In contrast, the "EDHOC Authentication Credential Types" registry defined in includes open-ended Private Use ranges. With respect to the Private Use ranges defined in this document, no values are designated whose CBOR encoding requires an eight-byte argument. When using values from these Private Use ranges, implementations need to account for the additional message size compared with the case where values with shorter encodings are used. Method types and error codes in the new ranges are each encoded in five bytes. For EAD items, positive labels in the new range are each encoded in five bytes as well. When using a critical EAD item (see ), the negative ead_label in the EAD item is encoded in five bytes, except for -65536 that is encoded in three bytes (i.e., its two-byte argument is 65535). The four-byte argument does not imply that the decoded integer fits in a signed 32-bit type. In particular, neither 4294967295 nor -4294967296 is representable in such a type. Implementations supporting the newly defined Private Use ranges in full also need to support a representation that preserves all the values admitted by those ranges, such as a signed 64-bit integer or a separate sign and unsigned argument. Range checks and, for EAD labels, absolute-value calculations also need to preserve the full values of decoded integers.

EAD Labels As specified in , the "EDHOC External Authorization Data" registry records the absolute values of the integer values used as ead_label in EAD items. Consistent with that, the Private Use range added to this registry pertains to both positive and negative ead_label values used in EAD items on the wire, with the absolute values listed in that range. The sign of ead_label retains its existing meaning: A negative value indicates that the EAD item is critical, and a nonnegative value indicates that the EAD item is non-critical. For example, the ead_label values 65536 and -65536 identify the same privately-defined EAD item as non-critical and critical, respectively. The processing rules for critical and non-critical EAD items in continue to apply.

Security Considerations This document and the Private Use ranges defined in do not impact the security of the LAKE protocol. When using values from such Private Use ranges, the security considerations compiled in still apply.

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 Method Types Registry IANA is asked to add the following two ranges to the "EDHOC Method Types" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group:

• -4294967296 to -65537
• 65536 to 4294967295

For both ranges, the registration procedure is "Private Use" per . Consistent with the above, the following two entries are added to the registry, thereby registering the indicated values as reserved for private use:

• Value: -4294967296 to -65537
• Initiator Authentication Key: N/A
• Responder Authentication Key: N/A
• Reference: [RFC-XXXX]

• Value: 65536 to 4294967295
• Initiator Authentication Key: N/A
• Responder Authentication Key: N/A
• Reference: [RFC-XXXX]

EDHOC Error Codes Registry IANA is asked to add the following two ranges to the "EDHOC Error Codes" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group.

• -4294967296 to -65537
• 65536 to 4294967295

For both ranges, the registration procedure is "Private Use" per . Consistent with the above, the following two entries are added to the registry, thereby registering the indicated values as reserved for private use:

• ERR_CODE: -4294967296 to -65537
• ERR_INFO Type: N/A
• Description: Reserved for Private Use
• Change Controller: IETF
• Reference: [RFC-XXXX]

• ERR_CODE: 65536 to 4294967295
• ERR_INFO Type: N/A
• Description: Reserved for Private Use
• Change Controller: IETF
• Reference: [RFC-XXXX]

EDHOC External Authorization Data Registry IANA is asked to add the following range to the "EDHOC External Authorization Data" registry within the "Ephemeral Diffie-Hellman Over COSE (EDHOC)" registry group:

• 65536 to 4294967295

For this range, the registration procedure is "Private Use" per . Consistent with the above, the following entry is added to the registry, thereby registering the indicated values as reserved for private use:

• Name: N/A
• Label: 65536 to 4294967295
• Description: Reserved for Private Use
• Reference: [RFC-XXXX]

References Normative References 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. 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 IANA IANA Informative References 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. The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including 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. IANA

Acknowledgments The authors thank and for their early feedback during the preparation of this document.