| Internet-Draft | SUIT TV | January 2022 |
| Birkholz & Moran | Expires 16 July 2022 | [Page] |
The IETF Remote Attestation Procedures (RATS) architecture defines Conceptual Messages as input and output of the appraisal process that assesses the trustworthiness of remote peers: Evidence and Attestation Results. Based on the Trustworthiness Vectors defined in Trusted Path Routing, this document defines a core set of Claims to be used in Evidence and Attestation Results for the Software Update for the Internet of Things (SUIT) Workflow Model. Consecutively, this document is in support of the Trusted Execution Environment Provisioning (TEEP) architecture, which defines the assessment of remote peers via RATS and uses SUIT for evidence generation as well as a remediation measure to improve trustworthiness of given remote peers.¶
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 16 July 2022.¶
Copyright (c) 2022 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.¶
Attestation Results are an essential output of Verifiers as defined in the Remote ATtestation procedureS (RATS) architecture [I-D.ietf-rats-architecture]. They are consumed by Relying Parties: the entities that intend to build future decisions on trustworthiness assessments of remote peers. Attestation Results must be easily appraised by Relying Parties -- in contrast to the rather complex or domain-specific Evidence appraised by Verifiers.¶
In order to create Attestation Results, a Verifier must consume Evidence generated by a given Attester (amongst other Conceptual Messages, such as Endorsements and Attestation Policies). Both Evidence and Attestation Results are composed of Claims. This document highlights and defines a set of Claims to be used in Evidence and Attestation Results that are based on the SUIT Workflow Model [I-D.ietf-suit-manifest]. In the scope of this document, an Attester takes on the role of a SUIT Recipient: the system that receives a SUIT Manifest.¶
This document focuses on Evidence and Attestation Results that can be generated based on the output of SUIT Procedures. The SUIT Workflow Model allows for two types of SUIT Procedures generating Reports on the Attester as defined in the SUIT Manifest specification [I-D.ietf-suit-manifest]:¶
A procedure that updates a device by fetching dependencies, software images, and installing them.¶
An Update Procedure creates a Report about mutable software components that are installed or updated on hardware components.¶
A procedure that boots a device by checking dependencies and images, loading images, and invoking one or more image.¶
A Boot Procedure creates a Report on measured boot events (e.g. during Secure Boot).¶
The Records contained in each type of Report can be used as Claims in Evidence generation on the Attester for Remote Attestation Procedures as described in this document. Analogously, a corresponding Verifier appraising that Evidence can generate Attestation Results using the Claims defined in this document.¶
Both types of SUIT Procedures pass several stages (e.g. dependency-checking is one stage). The type and sequence of stages are defined by the Command Sequences included in a SUIT Manifest. For each stage in which a Command from the Command Sequence is executed a Record is created. All Records of a SUIT procedure contain binary results limited to "fail" or "pass". The aggregated sequence of all Records is composed into a Report.¶
This document specifies new Claims derived from Command Sequence Reports and relates them to Claims defined in Attestation Results for Secure Interactions [I-D.ietf-rats-ar4si] -- if applicable to the operational state of installed and updated software.¶
The Claims defined in this document are in support of the Trusted Execution Environment Provisioning (TEEP) architecture. During TEEP, the current operational state of an Attester is assessed via RATS. If the corresponding Attestation Results -- as covered in this document -- indicate insufficient Trustworthiness Tiers in a Trustworthiness Vector with respect to installed software, the SUIT Workflow Model is used for remediation.¶
This document uses the terms and concepts defined in [I-D.ietf-rats-architecture], [I-D.ietf-suit-manifest], and [I-D.ietf-teep-architecture].¶
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.¶
While there are usage scenarios where Attestation Results can be binary decisions, more often than not the assessment of trustworthiness is represented by a more fine-grained spectrum or based on multiple factors. These shades of Attestation Results are captured by the definition of Trustworthiness Vectors in Attestation Results for Secure Interaction [I-D.ietf-rats-ar4si]. Trustworthiness Vectors are sets of Trustworthiness Claims representing appraisal outputs produced by a Verifier (Attestation Results). Each of these Trustworthiness Claims has a Trustworthiness Tier ranging from Affirmed to None.¶
An Attester processing SUIT Manifests can manages three types of information about it's Target Environments:¶
Every SUIT Manifest maps to a certain intended state of a device. Every intended device composition of software components associated with hardware components can therefore be expressed based on a SUIT Manifest. The current operational state of a device can be represented in the same form, including the initial state.¶
As a result, the Claims defined in this document are bundled by the scope of the information represented in SUIT Manifests, i.e., dedicated blobs of software that are the payload of a SUIT Manifest. All Claims associated with an identifiable SUIT Manifest MUST always be bundled together in a Claims set that is limited to the Claims defined in this document.¶
The Claim description in this document uses CDDL as the formal modeling language for Claims. This approach is aligned with [I-D.ietf-rats-eat]. All Claims are based on information elements as used in the SUIT Manifest specification [I-D.ietf-suit-manifest]. For instance, a SUIT Class ID is represented as an UUID. Analogously, the corresponding class-identifier Claim found below is based on a UUID. SUIT Claims are differentiated in:¶
Each type of Claims is always bundled in a dedicated Claim Set. Implementations can encode this information in various different ways (data models), e.g., sets, sequences, or nested structures.¶
The SUIT Report is defined in [I-D.ietf-suit-report]. It is used verbatim in this draft. The following subsections define the SUIT Report Claims for RATS.¶
System Properties Claims are composed of:¶
Correspondingly, the Claim definitions below highlight if a Claim is generic or hw/sw-component specific.¶
A RFC 4122 UUID representing the vendor of the Attester or one of its hardware and/or software components.¶
$$system-property-claim //= (vendor-identifier =>
(RFC4122_UUID / cbor-pen))
cbor-pen = #6.112(bstr)
¶
A RFC 4122 UUID representing the class of the Attester or one of its hardware and/or software components.¶
$$system-property-claim //= ( class-identifier => RFC4122_UUID )¶
A RFC 4122 UUID representing the Attester.¶
$$system-property-claim //= ( device-identifier => RFC4122_UUID )¶
A fingerprint computed over a software component image on the Attester. This Claim is always bundled with a component-identifier or component-index.¶
$$system-property-claim //= ( image-digest => digest )¶
The size of a firmware image on the Attester.¶
$$system-property-claim //= ( image-size => size )¶
This class of Claims represents the content of SUIT Records generated by Interpreters running on Recipients. They are always bundled into Claim Sets representing SUIT Reports and are intended to be included in Evidence generated by an Attester. The Interpreter Record Claims appraised by a Verifier can steer a corresponding a Firmware Appraisal procedures that consumes this Evidence. Analogously, these Claims can be re-used in generated Attestation Results as Trustworthiness Vectors [I-D.ietf-rats-ar4si].¶
The result of a Command that was executed by the Interpreter on an Attester.¶
$$interpreter-record-claim //= ( record-success => bool )¶
A positive integer representing an entry in a flat list of indices mapped to software component identifiers to be updated.¶
$$system-property-claim //= ( component-index => uint )¶
A thumbprint of a software component that an update depends on.¶
$$interpreter-record-claim //= ( dependency-index => digest )¶
A positive integer representing an entry in a SUIT_Command_Sequence identifying a Command encoded as a SUIT Manifest Directive or SUIT Manifest Condition.¶
$$interpreter-record-claim //= ( command-index => uint )¶
A list of SUIT_Parameters associated with a specific Command that was executed by the Interpreter on an Attester.¶
$$interpreter-record-claim //= ( actual-parameters => parameter-list )¶