idnits 2.17.1 draft-birkholz-rats-suit-claims-01.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.) 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 (January 13, 2021) is 1199 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-08 == Outdated reference: A later version (-25) exists of draft-ietf-rats-eat-06 == Outdated reference: A later version (-24) exists of draft-ietf-sacm-coswid-16 == Outdated reference: A later version (-25) exists of draft-ietf-suit-manifest-11 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-13 Summary: 2 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: July 17, 2021 Arm Limited 6 January 13, 2021 8 Trustworthiness Vectors for the Software Updates of Internet of Things 9 (SUIT) Workflow Model 10 draft-birkholz-rats-suit-claims-01 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 July 17, 2021. 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 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. SUIT Workflow Model and Procedures . . . . . . . . . . . 3 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Trustworthiness Vectors . . . . . . . . . . . . . . . . . . . 4 65 3. SUIT Claims . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. System Properties Claims . . . . . . . . . . . . . . . . 5 67 3.1.1. vendor-identifier . . . . . . . . . . . . . . . . . . 6 68 3.1.2. class-identifier . . . . . . . . . . . . . . . . . . 6 69 3.1.3. device-identifier . . . . . . . . . . . . . . . . . . 6 70 3.1.4. component-identifier . . . . . . . . . . . . . . . . 6 71 3.1.5. image-digest . . . . . . . . . . . . . . . . . . . . 6 72 3.1.6. image-size . . . . . . . . . . . . . . . . . . . . . 6 73 3.1.7. minimum-battery . . . . . . . . . . . . . . . . . . . 7 74 3.1.8. version . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.2. Interpreter Record Claims . . . . . . . . . . . . . . . . 7 76 3.2.1. record-success . . . . . . . . . . . . . . . . . . . 7 77 3.2.2. component-index . . . . . . . . . . . . . . . . . . . 7 78 3.2.3. dependency-index . . . . . . . . . . . . . . . . . . 7 79 3.2.4. command-index . . . . . . . . . . . . . . . . . . . . 7 80 3.2.5. nominal-parameters . . . . . . . . . . . . . . . . . 8 81 3.2.6. nominal-parameters . . . . . . . . . . . . . . . . . 8 82 3.3. Generic Record Conditions (TBD) . . . . . . . . . . . . . 8 83 4. List of Commands (TBD) . . . . . . . . . . . . . . . . . . . 8 84 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 5.1. Normative References . . . . . . . . . . . . . . . . . . 9 86 5.2. Informative References . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 89 1. Introduction 91 Attestation Results are an essential output of Verifiers as defined 92 in the Remote ATtestation procedureS (RATS) architecture 93 [I-D.ietf-rats-architecture]. They are consumed by Relying Parties: 94 the entities that intend to build future decisions on trustworthiness 95 assessments of remote peers. Attestation Results must be easily 96 appraised by Relying Parties - in contrast to the rather complex or 97 domain-specific Evidence appraised by Verifiers. 99 In order to create Attestation Results, a Verifier must consume 100 Evidence generated by a given Attester (amongst other Conceptual 101 Messages, such as Endorsements and Attestation Policies). Both 102 Evidence and Attestation Results are composed of Claims. This 103 document highlights and defines a set of Claims to be used in 104 Evidence and Attestation Results that are based on the SUIT Workflow 105 Model [I-D.ietf-suit-manifest]. In the scope of this document, an 106 Attester takes on the role of a SUIT Recipient: the system that 107 receives a SUIT Manifest. 109 1.1. SUIT Workflow Model and Procedures 111 This document focuses on Evidence and Attestation Results that can be 112 generated based on the output of SUIT Procedures. The SUIT Workflow 113 Model allows for two types of SUIT Procedures generating Reports on 114 the Attester as defined in the SUIT Manifest specification 115 [I-D.ietf-suit-manifest]: 117 Update Procedures: A procedure that updates a device by fetching 118 dependencies, software images, and installing them. 120 An Update Procedure creates a Report about mutable software 121 components that are installed or updated on hardware components. 123 Boot Procedures: A procedure that boots a device by checking 124 dependencies and images, loading images, and invoking one or more 125 image. 127 A Boot Procedure creates a Report on measured boot events (e.g. 128 during Secure Boot). 130 The Records contained in each type of Report can be used as Claims in 131 Evidence generation on the Attester for Remote Attestation Procedures 132 as described in this document. Analogously, a corresponding Verifier 133 appraising that Evidence can generate Attestation Results using the 134 Claims defined in this document. 136 Both types of SUIT Procedures pass several stages (e.g. dependency- 137 checking is one stage). The type and sequence of stages are defined 138 by the Command Sequences included in a SUIT Manifest. For each stage 139 in which a Command from the Command Sequence is executed a Record is 140 created. All Records of a SUIT procedure contain binary results 141 limited to "fail" or "pass". The aggregated sequence of all Records 142 is composed into a Report. 144 This document specifies new Claims derived from Command Sequence 145 Reports and highlights existing Claims as defined in Trusted Path 146 Routing [I-D.voit-rats-trusted-path-routing] that are applicable to 147 the operational state of installed and updated software. 149 The Claims defined in this document are in support of the Trusted 150 Execution Environment Provisioning (TEEP) architecture. During TEEP, 151 the current operational state of an Attester is assessed via RATS. 152 If the corresponding Attestation Results - as covered in this 153 document - indicate insufficient Trustworthiness Levels with respect 154 to installed software, the SUIT Workflow Model is used for 155 remediation. 157 1.2. Terminology 159 This document uses the terms and concepts defined in 160 [I-D.ietf-rats-architecture], [I-D.ietf-suit-manifest], and 161 [I-D.ietf-teep-architecture]. 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in 166 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 167 capitals, as shown here. 169 2. Trustworthiness Vectors 171 While there are usage scenarios where Attestation Results can be 172 binary decisions, more often than not the assessment of 173 trustworthiness is represented by a more fine-grained spectrum or 174 based on multiple factors. These shades of Attestation Results are 175 captured by the definition of Trustworthiness Vectors in Trusted Path 176 Routing [I-D.voit-rats-trusted-path-routing]. Trustworthiness 177 Vectors are sets of Claims representing appraisal outputs created by 178 a Verifier. Each of these Claims is called a Trustworthiness Level. 179 Multiple Trustworthiness Levels are composed into a vector. 181 An Attester processing SUIT Manifests can create three types of 182 Claims about its Target Environments. This includes Claims about: 184 o installed manifests including initial state (e.g. factory 185 default), 187 o hardware component identifiers that represent the targets of 188 updates, and 190 o SUIT Interpreter results (e.g. test-failed) created during 191 updates. 193 Every SUIT Manifest maps to a certain intended state of a device. 194 Every intended device composition of software components associated 195 with hardware components can therefore be expressed based on a SUIT 196 Manifest. The current operational state of a device can be 197 represented in the same form, including the initial state. 199 As a result, the Claims defined in this document are bundled by the 200 scope of the information represented in SUIT Manifests, i.e., 201 dedicated blobs of software that are the payload of a SUIT Manifest. 202 All Claims associated with an identifiable SUIT Manifest must always 203 be bundled together in a Claims set that is limited to the Claims 204 defined in this document. 206 3. SUIT Claims 208 The Claim description in this document uses CDDL as the formal 209 modeling language for Claims. This approach is derived from 210 [I-D.ietf-rats-eat]. All Claims are based on information elements as 211 used in the SUIT Manifest specification [I-D.ietf-suit-manifest]. 212 For instance, a SUIT Vendor ID is represented as an UUID. 213 Analogously, the corresponding vendor-identifier Claim found below is 214 based on a UUID. SUIT Claims are differentiated in: 216 o software and hardware characteristics (System Properties), and 218 o reports about updates their SUIT Commands (SUIT Records). 220 Both types of Claims are always bundled in dedicated Claim Sets. 221 Implementations can encode this information in various different ways 222 (data models), e.g., sets, sequences, or nested structures. The 223 following subsections define the SUIT Report Claims for RATS and are 224 structured according to the following CDDL expression. 226 suit-report = { 227 suit-system-properties => [ + system-property-claims ], 228 suit-records => [ + interpreter-record-claims ], 229 } 231 system-property-claims => { + $$system-property-claim } 232 interpreter-record-claims => { + $$interpreter-record-claim } 234 3.1. System Properties Claims 236 System Properties Claims are composed of: 238 o Hardware Component Claims and 240 o Software Component Claims. 242 Correspondingly, the Claim definitions below highlight if a Claim is 243 generic or hw/sw-component specific. 245 3.1.1. vendor-identifier 247 A RFC 4122 UUID representing the vendor of the Attester or one of its 248 hardware and/or software components. 250 $$system-property-claim //= ( vendor-identifier => RFC4122_UUID ) 252 3.1.2. class-identifier 254 A RFC 4122 UUID representing the class of the Attester or one of its 255 hardware and/or software components. 257 $$system-property-claim //= ( class-identifier => RFC4122_UUID ) 259 3.1.3. device-identifier 261 A RFC 4122 UUID representing the Attester. 263 $$system-property-claim //= ( device-identifier => RFC4122_UUID ) 265 3.1.4. component-identifier 267 A sequence of binary identifiers that is intended to identify a 268 software-component of an Attester uniquely. A binary identifier can 269 represent a CoSWID [I-D.ietf-sacm-coswid] tag-id. 271 $$system-property-claim //= ( class-identifier => [ + identifier ] ) 273 3.1.5. image-digest 275 A fingerprint computed over a software component image on the 276 Attester. This Claim is always bundled with a component-identifier 277 or component-index. 279 $$system-property-claim //= ( image-digest => digest ) 281 3.1.6. image-size 283 The size of a firmware image on the Attester. 285 $$system-property-claim //= ( image-size => size ) 287 3.1.7. minimum-battery 289 The configured minimum battery level of the Attester in mWh. 291 $$system-property-claim //= ( minimum-battery => charge ) 293 3.1.8. version 295 The Version of a hardware or software component of the Attester. 297 $$system-property-claim //= ( version => version-value ) 299 3.2. Interpreter Record Claims 301 This class of Claims represents the content of SUIT Records generated 302 by Interpreters running on Recipients. They are always bundled into 303 Claim Sets representing SUIT Reports and are intended to be included 304 in Evidence generated by an Attester. The Interpreter Record Claims 305 appraised by a Verifier can steer a corresponding a Firmware 306 Appraisal procedures that consumes this Evidence. Analogously, these 307 Claims can be re-used in generated Attestation Results as 308 Trustworthiness Vectors [I-D.voit-rats-trusted-path-routing]. 310 3.2.1. record-success 312 The result of a Command that was executed by the Interpreter on an 313 Attester. 315 $$interpreter-record-claim //= ( record-success => bool ) 317 3.2.2. component-index 319 A positive integer representing an entry in a flat list of indices 320 mapped to software component identifiers to be updated. 322 $$system-property-claim //= ( component-index => uint ) 324 3.2.3. dependency-index 326 A thumbprint of a software component that an update depends on. 328 $$interpreter-record-claim //= ( dependency-index => digest ) 330 3.2.4. command-index 332 A positive integer representing an entry in a SUIT_Command_Sequence 333 identifying a Command encoded as a SUIT Manifest Directive or SUIT 334 Manifest Condition. 336 $$interpreter-record-claim //= ( command-index => uint ) 338 3.2.5. nominal-parameters 340 A list of SUIT_Parameters associated with a specific Command encoded 341 as a SUIT Manifest Directive. 343 $$interpreter-record-claim //= ( nominal-parameters => parameter-list ) 345 3.2.6. nominal-parameters 347 A list of SUIT_Parameters associated with a specific Command that was 348 executed by the Interpreter on an Attester. 350 $$interpreter-record-claim //= ( actual-parameters => parameter-list ) 352 3.3. Generic Record Conditions (TBD) 354 o test-failed 356 o unsupported-command 358 o unsupported-parameter 360 o unsupported-component-id 362 o payload-unavailable 364 o dependency-unavailable 366 o critical-application-failure 368 o watchdog-timeout 370 4. List of Commands (TBD) 372 o Check Vendor Identifier 374 o Check Class Identifier 376 o Verify Image 378 o Set Component Index 380 o Override Parameters 382 o Set Dependency Index 383 o Set Parameters 385 o Process Dependency 387 o Run 389 o Fetch 391 o Use Before 393 o Check Component Offset 395 o Check Device Identifier 397 o Check Image Not Match 399 o Check Minimum Battery 401 o Check Update Authorized 403 o Check Version 405 o Abort 407 o Try Each 409 o Copy 411 o Swap 413 o Wait For Event 415 o Run Sequence 417 o Run with Arguments 419 5. References 421 5.1. Normative References 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, 425 DOI 10.17487/RFC2119, March 1997, 426 . 428 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 429 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 430 May 2017, . 432 5.2. Informative References 434 [I-D.ietf-rats-architecture] 435 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 436 W. Pan, "Remote Attestation Procedures Architecture", 437 draft-ietf-rats-architecture-08 (work in progress), 438 December 2020. 440 [I-D.ietf-rats-eat] 441 Mandyam, G., Lundblade, L., Ballesteros, M., and J. 442 O'Donoghue, "The Entity Attestation Token (EAT)", draft- 443 ietf-rats-eat-06 (work in progress), December 2020. 445 [I-D.ietf-sacm-coswid] 446 Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D. 447 Waltermire, "Concise Software Identification Tags", draft- 448 ietf-sacm-coswid-16 (work in progress), November 2020. 450 [I-D.ietf-suit-manifest] 451 Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg, 452 "A Concise Binary Object Representation (CBOR)-based 453 Serialization Format for the Software Updates for Internet 454 of Things (SUIT) Manifest", draft-ietf-suit-manifest-11 455 (work in progress), December 2020. 457 [I-D.ietf-teep-architecture] 458 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 459 "Trusted Execution Environment Provisioning (TEEP) 460 Architecture", draft-ietf-teep-architecture-13 (work in 461 progress), November 2020. 463 [I-D.voit-rats-trusted-path-routing] 464 Voit, E., "Trusted Path Routing", draft-voit-rats-trusted- 465 path-routing-02 (work in progress), June 2020. 467 Authors' Addresses 469 Henk Birkholz 470 Fraunhofer SIT 472 EMail: henk.birkholz@sit.fraunhofer.de 474 Brendan Moran 475 Arm Limited 477 EMail: Brendan.Moran@arm.com