Trust Anchor Hints in Ephemeral Diffie-Hellman Over COSE (EDHOC)
draft-serafin-lake-ta-hint-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Marek Serafin , Göran Selander | ||
| Last updated | 2024-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-serafin-lake-ta-hint-00
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,
<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, June 2010,
<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, June 2017,
<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,
May 2017, <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, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
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, <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, February
2023, <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, March 2024,
<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, May
2024, <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, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cbor-encoded-cert-11>.
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]