Lightweight Authenticated Key Exchange M. Serafin Internet-Draft ASSA ABLOY Intended status: Standards Track G. Selander Expires: 23 April 2025 Ericsson 20 October 2024 Trust Anchor Hints in Ephemeral Diffie-Hellman Over COSE (EDHOC) draft-serafin-lake-ta-hint-00 Abstract 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 This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://gselander.github.io/lake-ta-hint/draft-serafin-lake-ta- hint.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-serafin-lake-ta-hint/. Discussion of this document takes place on the Lightweight Authenticated Key Exchange Working Group mailing list (mailto:lake@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/lake/. Subscribe at https://www.ietf.org/mailman/listinfo/lake/. Source for this draft and an issue tracker can be found at https://github.com/gselander/lake-ta-hint. 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/. Serafin & Selander Expires 23 April 2025 [Page 1] Internet-Draft TA Hints in EDHOC October 2024 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." This Internet-Draft will expire on 23 April 2025. Copyright Notice Copyright (c) 2024 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. Trust Anchor Hints . . . . . . . . . . . . . . . . . . . . . 3 2.1. Trust Anchor Purpose . . . . . . . . . . . . . . . . . . 4 2.2. EAD Item . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Authentication Processing . . . . . . . . . . . . . . . . . . 6 3.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5.1. EDHOC External Authorization Data Registry . . . . . . . 7 5.2. EDHOC Trust Anchor Hint Registry . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Ephemeral Diffie-Hellman Over COSE (EDHOC) [RFC9528] is a lightweight security handshake protocol with low processing and message overhead, especially suited for constrained devices and low-power networking. Serafin & Selander Expires 23 April 2025 [Page 2] Internet-Draft TA Hints in EDHOC October 2024 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 Section 3.8 of [RFC9528]. 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 Appendix E of [RFC9528]. 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 Section 2.2. However, the same scheme can be applied to hints about other trusted third parties, such as Verifiers of remote attestation evidence [RFC9334] or Time Servers for network time synchronization [RFC5905]. 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. 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. 2. Trust Anchor Hints Serafin & Selander Expires 23 April 2025 [Page 3] Internet-Draft TA Hints in EDHOC October 2024 2.1. Trust Anchor Purpose The EAD item defined in Section 2.2 provides hints to trust anchors for different purposes. Table 1 provides the currently defined list of purposes, which is extensible through the IANA registry defined in Section 5. +=======+===========================+============+ | Label | Purpose | Reference | +=======+===========================+============+ | 1 | Trust anchor of EDHOC | [RFC-XXXX] | | | authentication credential | | +-------+---------------------------+------------+ | 2 | Trust anchor of remote | [RFC-XXXX] | | | attestation verifier | | +-------+---------------------------+------------+ | 3 | Trust anchor of time | [RFC-XXXX] | | | server | | +-------+---------------------------+------------+ Table 1: EDHOC Trust Anchor purposes * 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 2.2. 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 Section 3 of [RFC9052], and contain one or more COSE header parameters. Serafin & Selander Expires 23 April 2025 [Page 4] Internet-Draft TA Hints in EDHOC October 2024 ead_ta_hint = ( ead_label: TBD1, ead_value: bstr .cbor ta_hint_map, ), ta_hint_map = { * int => header_map } Figure 1: EAD item Table 2 provides examples of COSE header_maps used as TA hint types. +=========+=======+===============+==============+===============+ | TA hint | CBOR | CBOR type | Description | Reference | | type | label | | | | +=========+=======+===============+==============+===============+ | kid | 4 | bstr | Key | [RFC-9052] | | | | | identifier | | +---------+-------+---------------+--------------+---------------+ | c5t | 22 | COSE_CertHash | C509 | [draft-ietf- | | | | | certificate | cose-cbor- | | | | | thumbprint | encoded-cert] | +---------+-------+---------------+--------------+---------------+ | c5u | 23 | uri | C509 | [draft-ietf- | | | | | certificate | cose-cbor- | | | | | URI | encoded-cert] | +---------+-------+---------------+--------------+---------------+ | x5t | 34 | COSE_CertHash | X.509 | [RFC-9360] | | | | | certificate | | | | | | thumbprint | | +---------+-------+---------------+--------------+---------------+ | x5u | 35 | uri | X.509 | [RFC-9360] | | | | | certificate | | | | | | URI | | +---------+-------+---------------+--------------+---------------+ | uuid | TBD2 | #6.37(bstr) | Binary CBOR- | [RFC-9562] | | | | | encoded UUID | | +---------+-------+---------------+--------------+---------------+ Table 2: EDHOC Trust Anchor hint types Serafin & Selander Expires 23 April 2025 [Page 5] Internet-Draft TA Hints in EDHOC October 2024 3. 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. 3.1. 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: TBD1, << { 1: { 4: h'6564686F632D6E6F632D6963612D32'}} >> 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. 3.2. 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: TBD1, << { -1: { 34: [-15, h'79f2a41b510c1f9b'], 35: "http://certs.tech.com"}} >> Serafin & Selander Expires 23 April 2025 [Page 6] Internet-Draft TA Hints in EDHOC October 2024 3.3. 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: TBD1, << { 1: { 4: h'6564686F632D6E6F632D6963612D32'} -1: { 34: [-15, h'79f2a41b510c1f9b'], 35: "http://certs.tech.com"}} >> Editor's note: Add examples using intermediate CAs 4. Security Considerations TODO 5. IANA Considerations 5.1. 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 [RFC9528]. The ead_label = TBD1 and the ead_value define TA hints transferred in an EAD item of an EDHOC message, with processing specified in Section 3. 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 [RFC9528] or of other assertions used with External Authorization Data of EDHOC. Reference: [RFC-XXXX] 5.2. 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 [RFC8126]. Guidelines for the experts are provided in TODO. The columns of the registry are: Serafin & Selander Expires 23 April 2025 [Page 7] Internet-Draft TA Hints in EDHOC October 2024 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 Table 1. The Reference column for all of these entries is this document. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, . Serafin & Selander Expires 23 April 2025 [Page 8] Internet-Draft TA Hints in EDHOC October 2024 [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9360] Schaad, J., "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates", RFC 9360, DOI 10.17487/RFC9360, February 2023, . [RFC9528] Selander, G., Preuß Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, DOI 10.17487/RFC9528, March 2024, . [RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, . 6.2. Informative References [I-D.ietf-cose-cbor-encoded-cert] Mattsson, J. P., Selander, G., Raza, S., Höglund, J., and M. Furuhed, "CBOR Encoded X.509 Certificates (C509 Certificates)", Work in Progress, Internet-Draft, draft- ietf-cose-cbor-encoded-cert-11, 8 July 2024, . Acknowledgments TODO Authors' Addresses Marek Serafin ASSA ABLOY Email: marek.serafin@assaabloy.com Göran Selander Ericsson Email: goran.selander@ericsson.com Serafin & Selander Expires 23 April 2025 [Page 9]