idnits 2.17.1 draft-birkholz-rats-suit-claims-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (13 July 2021) is 1017 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-12 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-10 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-18 == Outdated reference: A later version (-25) exists of draft-ietf-suit-manifest-14 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-14 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS H. Birkholz 3 Internet-Draft Fraunhofer SIT 4 Intended status: Standards Track B. Moran 5 Expires: 14 January 2022 Arm Limited 6 13 July 2021 8 Trustworthiness Vectors for the Software Updates of Internet of Things 9 (SUIT) Workflow Model 10 draft-birkholz-rats-suit-claims-02 12 Abstract 14 The IETF Remote Attestation Procedures (RATS) architecture defines 15 Conceptual Messages as input and output of the appraisal process that 16 assesses the trustworthiness of remote peers: Evidence and 17 Attestation Results. Based on the Trustworthiness Vectors defined in 18 Trusted Path Routing, this document defines a core set of Claims to 19 be used in Evidence and Attestation Results for the Software Update 20 for the Internet of Things (SUIT) Workflow Model. Consecutively, 21 this document is in support of the Trusted Execution Environment 22 Provisioning (TEEP) architecture, which defines the assessment of 23 remote peers via RATS and uses SUIT for evidence generation as well 24 as a remediation measure to improve trustworthiness of given remote 25 peers. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 14 January 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. SUIT Workflow Model and Procedures . . . . . . . . . . . 3 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Trustworthiness Vectors . . . . . . . . . . . . . . . . . . . 4 64 3. SUIT Claims . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. System Properties Claims . . . . . . . . . . . . . . . . 5 66 3.1.1. vendor-identifier . . . . . . . . . . . . . . . . . . 6 67 3.1.2. class-identifier . . . . . . . . . . . . . . . . . . 6 68 3.1.3. device-identifier . . . . . . . . . . . . . . . . . . 6 69 3.1.4. component-identifier . . . . . . . . . . . . . . . . 6 70 3.1.5. image-digest . . . . . . . . . . . . . . . . . . . . 6 71 3.1.6. image-size . . . . . . . . . . . . . . . . . . . . . 6 72 3.1.7. minimum-battery . . . . . . . . . . . . . . . . . . . 7 73 3.1.8. version . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.2. Interpreter Record Claims . . . . . . . . . . . . . . . . 7 75 3.2.1. record-success . . . . . . . . . . . . . . . . . . . 7 76 3.2.2. component-index . . . . . . . . . . . . . . . . . . . 7 77 3.2.3. dependency-index . . . . . . . . . . . . . . . . . . 7 78 3.2.4. command-index . . . . . . . . . . . . . . . . . . . . 7 79 3.2.5. nominal-parameters . . . . . . . . . . . . . . . . . 8 80 3.2.6. nominal-parameters . . . . . . . . . . . . . . . . . 8 81 3.3. Generic Record Conditions (TBD) . . . . . . . . . . . . . 8 82 4. List of Commands (TBD) . . . . . . . . . . . . . . . . . . . 8 83 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 5.1. Normative References . . . . . . . . . . . . . . . . . . 9 85 5.2. Informative References . . . . . . . . . . . . . . . . . 10 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 88 1. Introduction 90 Attestation Results are an essential output of Verifiers as defined 91 in the Remote ATtestation procedureS (RATS) architecture 92 [I-D.ietf-rats-architecture]. They are consumed by Relying Parties: 93 the entities that intend to build future decisions on trustworthiness 94 assessments of remote peers. Attestation Results must be easily 95 appraised by Relying Parties -- in contrast to the rather complex or 96 domain-specific Evidence appraised by Verifiers. 98 In order to create Attestation Results, a Verifier must consume 99 Evidence generated by a given Attester (amongst other Conceptual 100 Messages, such as Endorsements and Attestation Policies). Both 101 Evidence and Attestation Results are composed of Claims. This 102 document highlights and defines a set of Claims to be used in 103 Evidence and Attestation Results that are based on the SUIT Workflow 104 Model [I-D.ietf-suit-manifest]. In the scope of this document, an 105 Attester takes on the role of a SUIT Recipient: the system that 106 receives a SUIT Manifest. 108 1.1. SUIT Workflow Model and Procedures 110 This document focuses on Evidence and Attestation Results that can be 111 generated based on the output of SUIT Procedures. The SUIT Workflow 112 Model allows for two types of SUIT Procedures generating Reports on 113 the Attester as defined in the SUIT Manifest specification 114 [I-D.ietf-suit-manifest]: 116 Update Procedures: A procedure that updates a device by fetching 117 dependencies, software images, and installing them. 119 An Update Procedure creates a Report about mutable software 120 components that are installed or updated on hardware components. 122 Boot Procedures: A procedure that boots a device by checking 123 dependencies and images, loading images, and invoking one or more 124 image. 126 A Boot Procedure creates a Report on measured boot events (e.g. 127 during Secure Boot). 129 The Records contained in each type of Report can be used as Claims in 130 Evidence generation on the Attester for Remote Attestation Procedures 131 as described in this document. Analogously, a corresponding Verifier 132 appraising that Evidence can generate Attestation Results using the 133 Claims defined in this document. 135 Both types of SUIT Procedures pass several stages (e.g. dependency- 136 checking is one stage). The type and sequence of stages are defined 137 by the Command Sequences included in a SUIT Manifest. For each stage 138 in which a Command from the Command Sequence is executed a Record is 139 created. All Records of a SUIT procedure contain binary results 140 limited to "fail" or "pass". The aggregated sequence of all Records 141 is composed into a Report. 143 This document specifies new Claims derived from Command Sequence 144 Reports and highlights existing Claims as defined in Trusted Path 145 Routing [I-D.voit-rats-trusted-path-routing] that are applicable to 146 the operational state of installed and updated software. 148 The Claims defined in this document are in support of the Trusted 149 Execution Environment Provisioning (TEEP) architecture. During TEEP, 150 the current operational state of an Attester is assessed via RATS. 151 If the corresponding Attestation Results -- as covered in this 152 document -- indicate insufficient Trustworthiness Levels with respect 153 to installed software, the SUIT Workflow Model is used for 154 remediation. 156 1.2. Terminology 158 This document uses the terms and concepts defined in 159 [I-D.ietf-rats-architecture], [I-D.ietf-suit-manifest], and 160 [I-D.ietf-teep-architecture]. 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in 165 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 2. Trustworthiness Vectors 170 While there are usage scenarios where Attestation Results can be 171 binary decisions, more often than not the assessment of 172 trustworthiness is represented by a more fine-grained spectrum or 173 based on multiple factors. These shades of Attestation Results are 174 captured by the definition of Trustworthiness Vectors in Trusted Path 175 Routing [I-D.voit-rats-trusted-path-routing]. Trustworthiness 176 Vectors are sets of Claims representing appraisal outputs created by 177 a Verifier. Each of these Claims is called a Trustworthiness Level. 178 Multiple Trustworthiness Levels are composed into a vector. 180 An Attester processing SUIT Manifests can create three types of 181 Claims about its Target Environments. This includes Claims about: 183 * installed manifests including initial state (e.g. factory 184 default), 186 * hardware component identifiers that represent the targets of 187 updates, and 189 * SUIT Interpreter results (e.g. test-failed) created during 190 updates. 192 Every SUIT Manifest maps to a certain intended state of a device. 193 Every intended device composition of software components associated 194 with hardware components can therefore be expressed based on a SUIT 195 Manifest. The current operational state of a device can be 196 represented in the same form, including the initial state. 198 As a result, the Claims defined in this document are bundled by the 199 scope of the information represented in SUIT Manifests, i.e., 200 dedicated blobs of software that are the payload of a SUIT Manifest. 201 All Claims associated with an identifiable SUIT Manifest must always 202 be bundled together in a Claims set that is limited to the Claims 203 defined in this document. 205 3. SUIT Claims 207 The Claim description in this document uses CDDL as the formal 208 modeling language for Claims. This approach is derived from 209 [I-D.ietf-rats-eat]. All Claims are based on information elements as 210 used in the SUIT Manifest specification [I-D.ietf-suit-manifest]. 211 For instance, a SUIT Vendor ID is represented as an UUID. 212 Analogously, the corresponding vendor-identifier Claim found below is 213 based on a UUID. SUIT Claims are differentiated in: 215 * software and hardware characteristics (System Properties), and 217 * reports about updates their SUIT Commands (SUIT Records). 219 Both types of Claims are always bundled in dedicated Claim Sets. 220 Implementations can encode this information in various different ways 221 (data models), e.g., sets, sequences, or nested structures. The 222 following subsections define the SUIT Report Claims for RATS and are 223 structured according to the following CDDL expression. 225 suit-report = { 226 suit-system-properties => [ + system-property-claims ], 227 suit-records => [ + interpreter-record-claims ], 228 } 230 system-property-claims => { + $$system-property-claim } 231 interpreter-record-claims => { + $$interpreter-record-claim } 233 3.1. System Properties Claims 235 System Properties Claims are composed of: 237 * Hardware Component Claims and 239 * Software Component Claims. 241 Correspondingly, the Claim definitions below highlight if a Claim is 242 generic or hw/sw-component specific. 244 3.1.1. vendor-identifier 246 A RFC 4122 UUID representing the vendor of the Attester or one of its 247 hardware and/or software components. 249 $$system-property-claim //= ( vendor-identifier => RFC4122_UUID ) 251 3.1.2. class-identifier 253 A RFC 4122 UUID representing the class of the Attester or one of its 254 hardware and/or software components. 256 $$system-property-claim //= ( class-identifier => RFC4122_UUID ) 258 3.1.3. device-identifier 260 A RFC 4122 UUID representing the Attester. 262 $$system-property-claim //= ( device-identifier => RFC4122_UUID ) 264 3.1.4. component-identifier 266 A sequence of binary identifiers that is intended to identify a 267 software-component of an Attester uniquely. A binary identifier can 268 represent a CoSWID [I-D.ietf-sacm-coswid] tag-id. 270 $$system-property-claim //= ( class-identifier => [ + identifier ] ) 272 3.1.5. image-digest 274 A fingerprint computed over a software component image on the 275 Attester. This Claim is always bundled with a component-identifier 276 or component-index. 278 $$system-property-claim //= ( image-digest => digest ) 280 3.1.6. image-size 282 The size of a firmware image on the Attester. 284 $$system-property-claim //= ( image-size => size ) 286 3.1.7. minimum-battery 288 The configured minimum battery level of the Attester in mWh. 290 $$system-property-claim //= ( minimum-battery => charge ) 292 3.1.8. version 294 The Version of a hardware or software component of the Attester. 296 $$system-property-claim //= ( version => version-value ) 298 3.2. Interpreter Record Claims 300 This class of Claims represents the content of SUIT Records generated 301 by Interpreters running on Recipients. They are always bundled into 302 Claim Sets representing SUIT Reports and are intended to be included 303 in Evidence generated by an Attester. The Interpreter Record Claims 304 appraised by a Verifier can steer a corresponding a Firmware 305 Appraisal procedures that consumes this Evidence. Analogously, these 306 Claims can be re-used in generated Attestation Results as 307 Trustworthiness Vectors [I-D.voit-rats-trusted-path-routing]. 309 3.2.1. record-success 311 The result of a Command that was executed by the Interpreter on an 312 Attester. 314 $$interpreter-record-claim //= ( record-success => bool ) 316 3.2.2. component-index 318 A positive integer representing an entry in a flat list of indices 319 mapped to software component identifiers to be updated. 321 $$system-property-claim //= ( component-index => uint ) 323 3.2.3. dependency-index 325 A thumbprint of a software component that an update depends on. 327 $$interpreter-record-claim //= ( dependency-index => digest ) 329 3.2.4. command-index 331 A positive integer representing an entry in a SUIT_Command_Sequence 332 identifying a Command encoded as a SUIT Manifest Directive or SUIT 333 Manifest Condition. 335 $$interpreter-record-claim //= ( command-index => uint ) 337 3.2.5. nominal-parameters 339 A list of SUIT_Parameters associated with a specific Command encoded 340 as a SUIT Manifest Directive. 342 $$interpreter-record-claim //= ( nominal-parameters => parameter-list ) 344 3.2.6. nominal-parameters 346 A list of SUIT_Parameters associated with a specific Command that was 347 executed by the Interpreter on an Attester. 349 $$interpreter-record-claim //= ( actual-parameters => parameter-list ) 351 3.3. Generic Record Conditions (TBD) 353 * test-failed 355 * unsupported-command 357 * unsupported-parameter 359 * unsupported-component-id 361 * payload-unavailable 363 * dependency-unavailable 365 * critical-application-failure 367 * watchdog-timeout 369 4. List of Commands (TBD) 371 * Check Vendor Identifier 373 * Check Class Identifier 375 * Verify Image 377 * Set Component Index 379 * Override Parameters 381 * Set Dependency Index 382 * Set Parameters 384 * Process Dependency 386 * Run 388 * Fetch 390 * Use Before 392 * Check Component Offset 394 * Check Device Identifier 396 * Check Image Not Match 398 * Check Minimum Battery 400 * Check Update Authorized 402 * Check Version 404 * Abort 406 * Try Each 408 * Copy 410 * Swap 412 * Wait For Event 414 * Run Sequence 416 * Run with Arguments 418 5. References 420 5.1. Normative References 422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 423 Requirement Levels", BCP 14, RFC 2119, 424 DOI 10.17487/RFC2119, March 1997, 425 . 427 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 428 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 429 May 2017, . 431 5.2. Informative References 433 [I-D.ietf-rats-architecture] 434 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 435 W. Pan, "Remote Attestation Procedures Architecture", Work 436 in Progress, Internet-Draft, draft-ietf-rats-architecture- 437 12, 23 April 2021, . 440 [I-D.ietf-rats-eat] 441 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 442 O'Donoghue, "The Entity Attestation Token (EAT)", Work in 443 Progress, Internet-Draft, draft-ietf-rats-eat-10, 7 June 444 2021, . 447 [I-D.ietf-sacm-coswid] 448 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 449 Waltermire, "Concise Software Identification Tags", Work 450 in Progress, Internet-Draft, draft-ietf-sacm-coswid-18, 12 451 July 2021, . 454 [I-D.ietf-suit-manifest] 455 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 456 "A Concise Binary Object Representation (CBOR)-based 457 Serialization Format for the Software Updates for Internet 458 of Things (SUIT) Manifest", Work in Progress, Internet- 459 Draft, draft-ietf-suit-manifest-14, 12 July 2021, 460 . 463 [I-D.ietf-teep-architecture] 464 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 465 "Trusted Execution Environment Provisioning (TEEP) 466 Architecture", Work in Progress, Internet-Draft, draft- 467 ietf-teep-architecture-14, 22 February 2021, 468 . 471 [I-D.voit-rats-trusted-path-routing] 472 Voit, E., "Trusted Path Routing", Work in Progress, 473 Internet-Draft, draft-voit-rats-trusted-path-routing-02, 474 10 June 2020, . 477 Authors' Addresses 478 Henk Birkholz 479 Fraunhofer SIT 481 Email: henk.birkholz@sit.fraunhofer.de 483 Brendan Moran 484 Arm Limited 486 Email: Brendan.Moran@arm.com