Internet-Draft TA Hints in EDHOC October 2024
Serafin & Selander Expires 23 April 2025 [Page]
Workgroup:
Lightweight Authenticated Key Exchange
Internet-Draft:
draft-serafin-lake-ta-hint-latest
Published:
Intended Status:
Standards Track
Expires:
Authors:
M. Serafin
ASSA ABLOY
G. Selander
Ericsson

Trust Anchor Hints in Ephemeral Diffie-Hellman Over COSE (EDHOC)

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

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.

Table of Contents

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.

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

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.

Table 1: 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

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.

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.

Table 2: 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]

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"}} >>

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:

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, , <https://www.rfc-editor.org/rfc/rfc2119>.
[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, , <https://www.rfc-editor.org/rfc/rfc5905>.
[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, , <https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9052]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, , <https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9334]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, , <https://www.rfc-editor.org/rfc/rfc9334>.
[RFC9360]
Schaad, J., "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates", RFC 9360, DOI 10.17487/RFC9360, , <https://www.rfc-editor.org/rfc/rfc9360>.
[RFC9528]
Selander, G., Preuß Mattsson, J., and F. Palombini, "Ephemeral Diffie-Hellman Over COSE (EDHOC)", RFC 9528, DOI 10.17487/RFC9528, , <https://www.rfc-editor.org/rfc/rfc9528>.
[RFC9562]
Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, , <https://www.rfc-editor.org/rfc/rfc9562>.

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, , <https://datatracker.ietf.org/doc/html/draft-ietf-cose-cbor-encoded-cert-11>.

Acknowledgments

TODO

Authors' Addresses

Marek Serafin
ASSA ABLOY
Göran Selander
Ericsson