idnits 2.17.1 draft-birkholz-rats-suit-claims-03.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 is 1 instance of too long lines in the document, the longest one being 1 character 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 date (12 January 2022) is 834 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) == Unused Reference: 'I-D.ietf-sacm-coswid' is defined on line 428, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-rats-ar4si-01 == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-14 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-11 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-19 == Outdated reference: A later version (-25) exists of draft-ietf-suit-manifest-16 == Outdated reference: A later version (-08) exists of draft-ietf-suit-report-00 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-15 Summary: 3 errors (**), 0 flaws (~~), 9 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: 16 July 2022 Arm Limited 6 12 January 2022 8 Trustworthiness Vectors for the Software Updates of Internet of Things 9 (SUIT) Workflow Model 10 draft-birkholz-rats-suit-claims-03 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 16 July 2022. 44 Copyright Notice 46 Copyright (c) 2022 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 Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised 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. image-digest . . . . . . . . . . . . . . . . . . . . 6 70 3.1.5. image-size . . . . . . . . . . . . . . . . . . . . . 6 71 3.1.6. version . . . . . . . . . . . . . . . . . . . . . . . 6 72 3.2. Interpreter Record Claims . . . . . . . . . . . . . . . . 7 73 3.2.1. record-success . . . . . . . . . . . . . . . . . . . 7 74 3.2.2. component-index . . . . . . . . . . . . . . . . . . . 7 75 3.2.3. dependency-index . . . . . . . . . . . . . . . . . . 7 76 3.2.4. command-index . . . . . . . . . . . . . . . . . . . . 7 77 3.2.5. nominal-parameters . . . . . . . . . . . . . . . . . 7 78 3.3. Generic Record Conditions (TBD) . . . . . . . . . . . . . 7 79 4. List of Commands (TBD) . . . . . . . . . . . . . . . . . . . 8 80 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 5.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 5.2. Informative References . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 Attestation Results are an essential output of Verifiers as defined 88 in the Remote ATtestation procedureS (RATS) architecture 89 [I-D.ietf-rats-architecture]. They are consumed by Relying Parties: 90 the entities that intend to build future decisions on trustworthiness 91 assessments of remote peers. Attestation Results must be easily 92 appraised by Relying Parties -- in contrast to the rather complex or 93 domain-specific Evidence appraised by Verifiers. 95 In order to create Attestation Results, a Verifier must consume 96 Evidence generated by a given Attester (amongst other Conceptual 97 Messages, such as Endorsements and Attestation Policies). Both 98 Evidence and Attestation Results are composed of Claims. This 99 document highlights and defines a set of Claims to be used in 100 Evidence and Attestation Results that are based on the SUIT Workflow 101 Model [I-D.ietf-suit-manifest]. In the scope of this document, an 102 Attester takes on the role of a SUIT Recipient: the system that 103 receives a SUIT Manifest. 105 1.1. SUIT Workflow Model and Procedures 107 This document focuses on Evidence and Attestation Results that can be 108 generated based on the output of SUIT Procedures. The SUIT Workflow 109 Model allows for two types of SUIT Procedures generating Reports on 110 the Attester as defined in the SUIT Manifest specification 111 [I-D.ietf-suit-manifest]: 113 Update Procedures: A procedure that updates a device by fetching 114 dependencies, software images, and installing them. 116 An Update Procedure creates a Report about mutable software 117 components that are installed or updated on hardware components. 119 Boot Procedures: A procedure that boots a device by checking 120 dependencies and images, loading images, and invoking one or more 121 image. 123 A Boot Procedure creates a Report on measured boot events (e.g. 124 during Secure Boot). 126 The Records contained in each type of Report can be used as Claims in 127 Evidence generation on the Attester for Remote Attestation Procedures 128 as described in this document. Analogously, a corresponding Verifier 129 appraising that Evidence can generate Attestation Results using the 130 Claims defined in this document. 132 Both types of SUIT Procedures pass several stages (e.g. dependency- 133 checking is one stage). The type and sequence of stages are defined 134 by the Command Sequences included in a SUIT Manifest. For each stage 135 in which a Command from the Command Sequence is executed a Record is 136 created. All Records of a SUIT procedure contain binary results 137 limited to "fail" or "pass". The aggregated sequence of all Records 138 is composed into a Report. 140 This document specifies new Claims derived from Command Sequence 141 Reports and relates them to Claims defined in Attestation Results for 142 Secure Interactions [I-D.ietf-rats-ar4si] -- if applicable to the 143 operational state of installed and updated software. 145 The Claims defined in this document are in support of the Trusted 146 Execution Environment Provisioning (TEEP) architecture. During TEEP, 147 the current operational state of an Attester is assessed via RATS. 148 If the corresponding Attestation Results -- as covered in this 149 document -- indicate insufficient Trustworthiness Tiers in a 150 Trustworthiness Vector with respect to installed software, the SUIT 151 Workflow Model is used for remediation. 153 1.2. Terminology 155 This document uses the terms and concepts defined in 156 [I-D.ietf-rats-architecture], [I-D.ietf-suit-manifest], and 157 [I-D.ietf-teep-architecture]. 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in 162 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 163 capitals, as shown here. 165 2. Trustworthiness Vectors 167 While there are usage scenarios where Attestation Results can be 168 binary decisions, more often than not the assessment of 169 trustworthiness is represented by a more fine-grained spectrum or 170 based on multiple factors. These shades of Attestation Results are 171 captured by the definition of Trustworthiness Vectors in Attestation 172 Results for Secure Interaction [I-D.ietf-rats-ar4si]. 173 Trustworthiness Vectors are sets of Trustworthiness Claims 174 representing appraisal outputs produced by a Verifier (Attestation 175 Results). Each of these Trustworthiness Claims has a Trustworthiness 176 Tier ranging from Affirmed to None. 178 An Attester processing SUIT Manifests can manages three types of 179 information about it's Target Environments: 181 * installed manifests including initial state (e.g. factory 182 default), 184 * hardware component identifiers that represent identifiable targets 185 of updates, and 187 * SUIT Interpreter results (e.g. test-failed) generated during 188 updates. 190 Every SUIT Manifest maps to a certain intended state of a device. 191 Every intended device composition of software components associated 192 with hardware components can therefore be expressed based on a SUIT 193 Manifest. The current operational state of a device can be 194 represented in the same form, including the initial state. 196 As a result, the Claims defined in this document are bundled by the 197 scope of the information represented in SUIT Manifests, i.e., 198 dedicated blobs of software that are the payload of a SUIT Manifest. 199 All Claims associated with an identifiable SUIT Manifest MUST always 200 be bundled together in a Claims set that is limited to the Claims 201 defined in this document. 203 3. SUIT Claims 205 The Claim description in this document uses CDDL as the formal 206 modeling language for Claims. This approach is aligned with 207 [I-D.ietf-rats-eat]. All Claims are based on information elements as 208 used in the SUIT Manifest specification [I-D.ietf-suit-manifest]. 209 For instance, a SUIT Class ID is represented as an UUID. 210 Analogously, the corresponding class-identifier Claim found below is 211 based on a UUID. SUIT Claims are differentiated in: 213 * software and hardware characteristics (System Properties), and 215 * reports about updates and their SUIT Commands (SUIT Records). 217 * success/failure reports 219 Each type of Claims is always bundled in a dedicated Claim Set. 220 Implementations can encode this information in various different ways 221 (data models), e.g., sets, sequences, or nested structures. 223 The SUIT Report is defined in [I-D.ietf-suit-report]. It is used 224 verbatim in this draft. The following subsections define the SUIT 225 Report Claims for RATS. 227 3.1. System Properties Claims 229 System Properties Claims are composed of: 231 * Hardware Component Claims and 233 * Software Component Claims. 235 Correspondingly, the Claim definitions below highlight if a Claim is 236 generic or hw/sw-component specific. 238 3.1.1. vendor-identifier 240 A RFC 4122 UUID representing the vendor of the Attester or one of its 241 hardware and/or software components. 243 $$system-property-claim //= (vendor-identifier => 244 (RFC4122_UUID / cbor-pen)) 245 cbor-pen = #6.112(bstr) 247 3.1.2. class-identifier 249 A RFC 4122 UUID representing the class of the Attester or one of its 250 hardware and/or software components. 252 $$system-property-claim //= ( class-identifier => RFC4122_UUID ) 254 3.1.3. device-identifier 256 A RFC 4122 UUID representing the Attester. 258 $$system-property-claim //= ( device-identifier => RFC4122_UUID ) 260 3.1.4. image-digest 262 A fingerprint computed over a software component image on the 263 Attester. This Claim is always bundled with a component-identifier 264 or component-index. 266 $$system-property-claim //= ( image-digest => digest ) 268 3.1.5. image-size 270 The size of a firmware image on the Attester. 272 $$system-property-claim //= ( image-size => size ) 274 3.1.6. version 276 The Version of a hardware or software component of the Attester. 278 $$system-property-claim //= ( version => version-value ) 280 3.2. Interpreter Record Claims 282 This class of Claims represents the content of SUIT Records generated 283 by Interpreters running on Recipients. They are always bundled into 284 Claim Sets representing SUIT Reports and are intended to be included 285 in Evidence generated by an Attester. The Interpreter Record Claims 286 appraised by a Verifier can steer a corresponding a Firmware 287 Appraisal procedures that consumes this Evidence. Analogously, these 288 Claims can be re-used in generated Attestation Results as 289 Trustworthiness Vectors [I-D.ietf-rats-ar4si]. 291 3.2.1. record-success 293 The result of a Command that was executed by the Interpreter on an 294 Attester. 296 $$interpreter-record-claim //= ( record-success => bool ) 298 3.2.2. component-index 300 A positive integer representing an entry in a flat list of indices 301 mapped to software component identifiers to be updated. 303 $$system-property-claim //= ( component-index => uint ) 305 3.2.3. dependency-index 307 A thumbprint of a software component that an update depends on. 309 $$interpreter-record-claim //= ( dependency-index => digest ) 311 3.2.4. command-index 313 A positive integer representing an entry in a SUIT_Command_Sequence 314 identifying a Command encoded as a SUIT Manifest Directive or SUIT 315 Manifest Condition. 317 $$interpreter-record-claim //= ( command-index => uint ) 319 3.2.5. nominal-parameters 321 A list of SUIT_Parameters associated with a specific Command that was 322 executed by the Interpreter on an Attester. 324 $$interpreter-record-claim //= ( actual-parameters => parameter-list ) 326 3.3. Generic Record Conditions (TBD) 327 * test-failed 329 * unsupported-command 331 * unsupported-parameter 333 * unsupported-component-id 335 * payload-unavailable 337 * dependency-unavailable 339 * critical-application-failure 341 * watchdog-timeout 343 4. List of Commands (TBD) 345 * Check Vendor Identifier 347 * Check Class Identifier 349 * Verify Image 351 * Set Component Index 353 * Override Parameters 355 * Set Dependency Index 357 * Set Parameters 359 * Process Dependency 361 * Run 363 * Fetch 365 * Use Before 367 * Check Component Offset 369 * Check Device Identifier 371 * Check Image Not Match 373 * Check Minimum Battery 374 * Check Update Authorized 376 * Check Version 378 * Abort 380 * Try Each 382 * Copy 384 * Swap 386 * Wait For Event 388 * Run Sequence 390 * Run with Arguments 392 5. References 394 5.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, 398 DOI 10.17487/RFC2119, March 1997, 399 . 401 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 402 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 403 May 2017, . 405 5.2. Informative References 407 [I-D.ietf-rats-ar4si] 408 Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V. 409 Scarlata, "Attestation Results for Secure Interactions", 410 Work in Progress, Internet-Draft, draft-ietf-rats-ar4si- 411 01, 2 December 2021, . 414 [I-D.ietf-rats-architecture] 415 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 416 W. Pan, "Remote Attestation Procedures Architecture", Work 417 in Progress, Internet-Draft, draft-ietf-rats-architecture- 418 14, 9 December 2021, . 421 [I-D.ietf-rats-eat] 422 Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity 423 Attestation Token (EAT)", Work in Progress, Internet- 424 Draft, draft-ietf-rats-eat-11, 24 October 2021, 425 . 428 [I-D.ietf-sacm-coswid] 429 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 430 Waltermire, "Concise Software Identification Tags", Work 431 in Progress, Internet-Draft, draft-ietf-sacm-coswid-19, 20 432 October 2021, . 435 [I-D.ietf-suit-manifest] 436 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 437 "A Concise Binary Object Representation (CBOR)-based 438 Serialization Format for the Software Updates for Internet 439 of Things (SUIT) Manifest", Work in Progress, Internet- 440 Draft, draft-ietf-suit-manifest-16, 25 October 2021, 441 . 444 [I-D.ietf-suit-report] 445 Moran, B., "Secure Reporting of Update Status", Work in 446 Progress, Internet-Draft, draft-ietf-suit-report-00, 12 447 July 2021, . 450 [I-D.ietf-teep-architecture] 451 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 452 "Trusted Execution Environment Provisioning (TEEP) 453 Architecture", Work in Progress, Internet-Draft, draft- 454 ietf-teep-architecture-15, 12 July 2021, 455 . 458 Authors' Addresses 460 Henk Birkholz 461 Fraunhofer SIT 463 Email: henk.birkholz@sit.fraunhofer.de 465 Brendan Moran 466 Arm Limited 467 Email: Brendan.Moran@arm.com