| Internet-Draft | TA Hints in EDHOC | October 2024 |
| Serafin & Selander | Expires 23 April 2025 | [Page] |
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).¶
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.¶
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.¶
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.¶
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.¶
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.¶
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 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¶
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
}
Table 2 provides examples of COSE header_maps used as TA 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] |
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.¶
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.¶
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"}} >>
¶
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¶
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.¶
TODO¶