EAT Measured Component

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 24 August 2025.¶

Copyright Notice

Copyright (c) 2025 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

Section 4.2.16 of [I-D.ietf-rats-eat] defines a Measurements claim that:¶

• "[c]ontains descriptions, lists, evidence or measurements of the software that exists on the entity or any other measurable subsystem of the entity."¶

This claim allows for different measurement formats, each identified by a different CoAP Content-Format (Section 12.3 of [RFC7252]). Currently, the only specified format is CoSWID of type "evidence", as per Section 2.9.4 of [RFC9393].¶

This document introduces a "measured component" format that can be used with the EAT Measurements claim in addition to or as an alternative to CoSWID.¶

The term "measured component" refers to any measurable object on a target environment, that is, an object whose state can be sampled and digested. This includes, for example: the invariant part of a firmware component that is loaded in memory at startup time, a run-time integrity check (RTIC), a file system object, or a CPU register.¶

2. Conventions and Definitions

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

In this document, CDDL [RFC8610] [RFC9165] [I-D.ietf-cbor-cddl-modules] [I-D.ietf-cbor-cddl-more-control] is used to describe the data formats.¶

3. Information Model

A "measured component" information element includes the digest of the component's sampled state along with metadata that helps in identifying the component. Optionally, any entities responsible for signing the installed component can also be specified.¶

The information model of a "measured component" is described in Table 1.¶

The format SHOULD also allow a limited amount of extensibility to accommodate profile-specific semantics.¶

4. Data Model

The data model is inspired by the "PSA software component" claim (Section 4.4.1 of [I-D.tschofenig-rats-psa-token]), which has been refactored to take into account the recommendations about new EAT claims design in Appendix E of [I-D.ietf-rats-eat].¶

bytes-b64u = text .b64u bytes
bytes8 = bytes .size 8
bytes8-b64u = text .b64u bytes8

;# import corim.digest from rfcYYYY as corim
;# import eat.JC from rfc9711 as eat

measured-component = {
  id-label => component-id
  measurement-label => corim.digest
  ? signers-label => [ + signer-type ]
  ? flags-label => flags-type
}

signer-type = eat.JC<bytes-b64u, bytes>
flags-type = eat.JC<bytes8-b64u, bytes8>

id-label = eat.JC<"id", 1>
measurement-label = eat.JC<"measurement", 2>
signers-label = eat.JC<"signers", 3>
flags-label = eat.JC<"flags", 4>

component-id = [
  name:      text
  ? version: version
]

;# import coswid.$version-scheme from rfc9393 as coswid

version = [
  val:      text
  ? scheme: coswid.$version-scheme
]

signer-type = eat.JC<bytes-b64u, bytes>

flags-type = eat.JC<bytes8-b64u, bytes8>

mc-cbor = bytes .cbor measured-component
mc-json = text .json measured-component

; EAT CBOR (`.feature "cbor"`)
$measurements-body-cbor /= mc-cbor ; native
$measurements-body-cbor /= mc-json ; tunnel

; EAT JSON (`.feature "json"`)
$measurements-body-json /= mc-json            ; native
$measurements-body-json /= text .b64u mc-cbor ; tunnel

5. EAT Profiles and Measured Components

The semantics of the signers and profile flags fields are defined by the applicable EAT profile, i.e., the profile of the wrapping EAT.¶

If the profile of the EAT is not known to the consumer and one or more Measured Components within that EAT include signers and/or profile flags, the consumer MUST reject the EAT.¶

6. Examples

The example in Figure 2 is a measured component with all the fields populated.¶

{
  / id / 1: [
    / name / "boot loader X",
    / version / [
      "1.2.3rc2",
      16384 / semver /
    ]
  ],
  / measurement / 2: [
    / alg / "sha-256",
    / val / h'3996003d486fb91ffb056f7d03f2b2992b215b31dbe7af4b37
              3431fc7d319da3'
  ],
  / signers / 3: [
    h'492e9b676c21f6012b1ceeb9032feb4141a880797355f6675015ec59c5
      1ca1ec',
    h'4277bb97ba7b51577a0d38151d3e08b40bdf946753f5b5bdeb814d6ff5
      7a8a5e'
  ],
  / profile-flags / 4: h'0000000000000101'
}

The example in Figure 3 is the same measured component as above but used as the format of a measurements claim in a EAT claims-set.¶

The example uses TBD1 as the content-type value of the measurements-format entry. (This will change to the value assigned by IANA to the mc+cbor Content-Format.)¶

Note that the array contains only one measured component, but additional entries could be added if the measured TCB is made of multiple, individually measured components.¶

{
  273: [
    [
      TBD1, / mc+cbor /
      <<
        {
          / id / 1: [
            / name / "boot loader X",
            / version / [
              "1.2.3rc2",
              16384 / semver /
            ]
          ],
          / measurement / 2: [
            / alg / "sha-256",
            / val / h'3996003d486fb91ffb056f7d03f2b2992b215b31db
                      e7af4b373431fc7d319da3'
          ],
          / signers / 3: [
            h'492e9b676c21f6012b1ceeb9032feb4141a880797355f66750
              15ec59c51ca1ec',
            h'4277bb97ba7b51577a0d38151d3e08b40bdf946753f5b5bdeb
              814d6ff57a8a5e'
          ]
        }
      >>
    ]
  ]
}

The example in Figure 4 illustrates the inclusion of a JSON measured component inside a JSON EAT.¶

The example uses TBD2 as the content-type value of the measurements-format entry. (This will change to the value assigned by IANA to the mc+json Content-Format.)¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

{
  "measurements": [
    [
      TBD2, / mc+json /
      "{ \"id\": [ \"boot loader X\", [ \"1.2.3rc2\", 16384 ] ], \"\
measurement\": [ \"sha-256\", \"\
OZYAPUhvuR_7BW99A_KymSshWzHb569LNzQx_H0xnaM\" ], \"signers\": [ \"\
SS6bZ2wh9gErHO65Ay_rQUGogHlzVfZnUBXsWcUcoew\", \"\
                   Qne7l7p7UVd6DTgVHT4ItAvflGdT9bW964FNb_V6il4\" ] }"
    ]
  ]
}

The example in Figure 5 is a measured component representing a boot loader identified by its path name:¶

{
  / id / 1: [
    / name / "/boot/loader.bin"
  ],
  / measurement / 2: [
    / alg / "sha-384",
    / val / h'66ec2fb4e02d8c8b3eee320e750d9389d66c52c51db11cc6
              9cc5e410816283ed60ba573795f5fcc85e513af57b3f6def'
  ],
  / profile-flags / 4: h'0000000000000101'
}

7. Security and Privacy Considerations

The Name and Version of a component can give an attacker detailed information about the software running on a device and its configuration settings. This information could offer an attacker valuable insights. Additionally, the stability requirement of the component's Name could potentially allow for tracking.¶

8. IANA Considerations

RFC Editor: replace "RFCthis" with the RFC number assigned to this document.¶

9. References

Appendix A. Open Issues

The list of currently open issues for this documents can be found at https://github.com/thomas-fossati/draft-fft-rats-eat-measured-component/issues.¶

Note to RFC Editor: please remove before publication.¶

Acknowledgments

The authors would like to thank Carl Wallace, Carsten Bormann, Dionna Glaze, Giridhar Mandyam and Laurence Lundblade for providing comments, reviews and suggestions that greatly improved this document.¶

Authors' Addresses