]> ASSA ABLOY

marek.serafin@assaabloy.com

Ericsson

goran.selander@ericsson.com

Security Lightweight Authenticated Key Exchange Internet-Draft This document defines a format for transport of hints about Trust Anchors of trusted third parties when using the lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC). About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Lightweight Authenticated Key Exchange Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Ephemeral Diffie-Hellman Over COSE (EDHOC) is a lightweight security handshake protocol with low processing and message overhead, especially suited for constrained devices and low-power networking. Authentication and authorization, in addition to excuting a security handshake protocol, typically involves the validation of certificates or assertions using Trust Anchors (TAs). For this machinery to work, the endpoints need to use credentials issued by a TA of the other endpoint. Moreover, the validation of credentials against TAs can be a significant contribution to processing or time for completion, for example in embedded devices. Performance can be improved by providing the other endpoint with hints about which TAs are supported, or which TAs should be used to verify specific credentials. This document specifies how to transport hints of TAs between EDHOC peers. EDHOC allows authorization-related information in the External Authorization Data (EAD) message fields, see . EAD can be included in any of the three mandatory and fourth optional EDHOC messages, providing flexibility and extensibility to the protocol. Its main purpose is to embed authorization-related information directly into the key exchange process, reducing the need for additional message exchanges and optimizing the overall protocol flow. Information about TAs is explicitly mentioned as one example of such authorization-related information, see . The primary motivation for this specification is to provide hints of TAs for authentication, typically related to Certificate Authorities (CAs), where the TA includes the public key of the CA. The hint is a COSE header parameter intended to facilitate the retrieval of the TA, for example a key identifier (kid) or a hash of an X.509 certificate containing the CA root public key (x5t), see . However, the same scheme can be applied to hints about other trusted third parties, such as Verifiers of remote attestation evidence or Time Servers for network time synchronization . This document defines an EDHOC EAD item containing hints about certain type of TAs, and enables the extension to other kind of hints and TAs through the registration of the appropriate IANA parameters.

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.

Trust Anchor Hints

Trust Anchor Purpose The EAD item defined in provides hints to trust anchors for different purposes. provides the currently defined list of purposes, which is extensible through the IANA registry defined in . EDHOC Trust Anchor purposes

Label	Purpose	Reference
1	Trust anchor of EDHOC authentication credential	[RFC-XXXX]
2	Trust anchor of remote attestation verifier	[RFC-XXXX]
3	Trust anchor of time server	[RFC-XXXX]

• EDHOC authentication credential: This parameter hints at which TA to use for authentication credentials in EDHOC. The positive of the CBOR label (+1) in the EAD item indicates trust anchor to use for verifying the authentication credentials from the sender. The negative of the CBOR label (-1) indicates what trust anchors are supported by the sender and SHOULD be used in authentication credentials sent to the sender.
• Remote attestation verifier: TODO
• Time server: TODO

EAD Item This section defines the EAD item ead_ta_hint used to carry TA hints. Like all EAD items, ead_ta_hint consists of the ead_label, a predefined constant that identifies this particular EAD structure; and the ead_value, which in this case is a byte string containing a CBOR map with the CBOR-encoded TA hints. The following CDDL defines the EAD item, where header_map is defined in , and contain one or more COSE header parameters.

EAD item header_map } ]]>

provides examples of COSE header_maps used as TA hint types. EDHOC Trust Anchor hint types

TA hint type	CBOR label	CBOR type	Description	Reference
kid	4	bstr	Key identifier	[RFC-9052]
c5t	22	COSE_CertHash	C509 certificate thumbprint	[draft-ietf-cose-cbor-encoded-cert]
c5u	23	uri	C509 certificate URI	[draft-ietf-cose-cbor-encoded-cert]
x5t	34	COSE_CertHash	X.509 certificate thumbprint	[RFC-9360]
x5u	35	uri	X.509 certificate URI	[RFC-9360]
uuid	TBD2	#6.37(bstr)	Binary CBOR-encoded UUID	[RFC-9562]

Authentication Processing In EDHOC message_2, the ta_hint_map with label 1 is used in the EAD_2 field to include hints about authentication TAs, i.e. TAs of the Responder's authentication credential AUTH_CRED_R. This hint informs the Initiator about which TAs to prioritize when validating AUTH_CRED_R. For example, if the Initiator’s trust store contains multiple CA/intermediate CA certificates, the Responder can include a hint indicating that the credentials should be validated using a specific TA identified by kid, x5t, x5u, c5t, c5u or UUID. Similarly for EDHOC message_3 and the TAs of the Initiator's authentication credential AUTH_CRED_I.

Example 1 Consider a scenario where the Initiator trusts five CA/intermediate certificates. The Responder, when sending message_2, knows that the Initiator should use the TA identified by kid=edhoc-noc-ica-2 for verification. The Responder includes the following EAD item in EAD_2: > ]]> When the Initiator receives message_2, it will prioritize validating the Responder’s credentials using the TA associated with the provided kid. If the validation against the TAs specified with the EAD item defined in this specification fails or is not recognized, then the receiver SHOULD fall back to the default validation process using available TAs. If all validation against TAs fail, then an error SHOULD be sent.

Example 2 An EDHOC peer may include hints about its supported TAs for authentication by including a ta_hint_map with label -1 in an appropriate EAD field: EAD_1 related to the AUTH_CRED_R and EAD_2 for AUTH_CRED_I. This informs the other peer about what TAs to use in its credentials in the next EDHOC message. In the example below the TA is identified by its SHA-256/64 hash (-15) and the URI from which the root certificate can be retrieved. The EAD item ead_ta_hint could look like this: > ]]>

Example 3 In EAD_2, the Responder can include both the information about TAs to use for validating the AUTH_CRED_R (Example 1) and recommended TAs to use for AUTH_CRED_I by the Initiator (Example 2). The EAD item ead_ta_hint could look like this: > ]]> Editor's note: Add examples using intermediate CAs

Security Considerations TODO

IANA Considerations

EDHOC External Authorization Data Registry IANA is requested to register the following entry to the "EDHOC External Authorization Data" registry defined in Section 10.5 of . The ead_label = TBD1 and the ead_value define TA hints transferred in an EAD item of an EDHOC message, with processing specified in . Name: Trust Anchor Hint Label: TBD1 (from the unsigned range) Description: A hint for determination of Trust Anchors used for verifying authentication credentials in EDHOC or of other assertions used with External Authorization Data of EDHOC. Reference: [RFC-XXXX]

EDHOC Trust Anchor Hint Registry IANA has created a new registry entitled "EDHOC Trust Anchor Hint Registry". The registration procedure depends on the range of CBOR label values, following . Guidelines for the experts are provided in TODO. The columns of the registry are: Label: The value to be used to identify this type of authority. Map key labels MUST be unique. The registry contains only positive integers, but negative integers MAY be used in the EAD item for the same type of authority but with separate semantics. Integer values between 1 and 23 are designated as Standards Track document required. Integer values from 24 to 255 are designated as Specification Required. Integer values from 256 to 65535 are designated as Expert Review. Integer values greater than 65535 are marked as Private Use. Purpose: This field contains a brief description for the field. Reference: This contains a pointer to the public specification for the field, if one exists. This registry has been initially populated by the values in . The Reference column for all of these entries is this document.

References 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. The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK] 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. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. 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. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. Informative References Ericsson AB Ericsson AB RISE AB RISE AB Nexus Group This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 Certificate Signing Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format.

Acknowledgments TODO