idnits 2.17.1 draft-voit-rats-attestation-results-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 07, 2021) is 961 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'GP-TEE-PP' == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-12 ** Downref: Normative reference to an Informational draft: draft-ietf-rats-architecture (ref. 'I-D.ietf-rats-architecture') -- Possible downref: Non-RFC (?) normative reference: ref. 'OMTP-ATE' == Outdated reference: A later version (-22) exists of draft-tschofenig-rats-psa-token-08 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RATS Working Group E. Voit 3 Internet-Draft Cisco 4 Intended status: Standards Track H. Birkholz 5 Expires: March 11, 2022 Fraunhofer SIT 6 T. Hardjono 7 MIT 8 T. Fossati 9 Arm Limited 10 V. Scarlata 11 Intel 12 September 07, 2021 14 Attestation Results for Secure Interactions 15 draft-voit-rats-attestation-results-02 17 Abstract 19 This document defines reusable Attestation Result information 20 elements. When these elements are offered to Relying Parties as 21 Evidence, different aspects of Attester trustworthiness can be 22 evaluated. Additionally, where the Relying Party is interfacing with 23 a heterogeneous mix of Attesting Environment and Verifier types, 24 consistent policies can be applied to subsequent information exchange 25 between each Attester and the Relying Party. 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 March 11, 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Attestation Results for Secure Interactions . . . . . . . . . 5 65 2.1. Information driving a Relying Party Action . . . . . . . 5 66 2.2. Non-repudiable Identity . . . . . . . . . . . . . . . . . 6 67 2.2.1. Attester and Attesting Environment . . . . . . . . . 7 68 2.2.2. Verifier . . . . . . . . . . . . . . . . . . . . . . 9 69 2.2.3. Communicating Identity . . . . . . . . . . . . . . . 10 70 2.3. Trustworthiness Claims . . . . . . . . . . . . . . . . . 10 71 2.3.1. Design Principles . . . . . . . . . . . . . . . . . . 10 72 2.3.2. Enumeration Encoding . . . . . . . . . . . . . . . . 12 73 2.3.3. Assigning a Trustworthiness Claim value . . . . . . . 13 74 2.3.4. Specific Claims . . . . . . . . . . . . . . . . . . . 13 75 2.3.5. Trustworthiness Vector . . . . . . . . . . . . . . . 17 76 2.3.6. Trustworthiness Vector for a type of Attesting 77 Environment . . . . . . . . . . . . . . . . . . . . . 17 78 2.4. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 18 79 3. Secure Interactions Models . . . . . . . . . . . . . . . . . 18 80 3.1. Pure Background-Check retrieval . . . . . . . . . . . . . 19 81 3.2. Attestation Result Augmented Evidence . . . . . . . . . . 19 82 3.3. Mutual Attestation . . . . . . . . . . . . . . . . . . . 24 83 3.4. Transport Protocol Integration . . . . . . . . . . . . . 24 84 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 88 7.1. Normative References . . . . . . . . . . . . . . . . . . 24 89 7.2. Informative References . . . . . . . . . . . . . . . . . 25 90 Appendix A. Supportable Trustworthiness Claims . . . . . . . . . 26 91 A.1. Supportable Trustworthiness Claims for HSM-based CC . . . 26 92 A.2. Supportable Trustworthiness Claims for process-based CC . 28 93 A.3. Supportable Trustworthiness Claims for VM-based CC . . . 29 94 Appendix B. Some issues being worked . . . . . . . . . . . . . . 30 95 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 31 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 98 1. Introduction 100 The first paragraph of the May 2021 US Presidential Executive Order 101 on Improving the Nation's Cybersecurity [US-Executive-Order] ends 102 with the statement "the trust we place in our digital infrastructure 103 should be proportional to how trustworthy and transparent that 104 infrastructure is." Later this order explores aspects of 105 trustworthiness such as an auditable trust relationship, which it 106 defines as an "agreed-upon relationship between two or more system 107 elements that is governed by criteria for secure interaction, 108 behavior, and outcomes." 110 The Remote ATtestation procedureS (RATS) architecture 111 [I-D.ietf-rats-architecture] provides a useful context for 112 programmatically establishing and maintaining such auditable trust 113 relationships. Specifically, the architecture defines conceptual 114 messages conveyed between architectural subsystems to support 115 trustworthiness appraisal. The RATS conceptual message used to 116 convey evidence of trustworthiness is the Attestation Results. The 117 Attestation Results includes Verifier generated appraisals of an 118 Attester including such information as the identity of the Attester, 119 the security mechanisms employed on this Attester, and the Attester's 120 current state of trustworthiness. 122 Generated Attestation Results are ultimately conveyed to one or more 123 Relying Parties. Reception of an Attestation Result enables a 124 Relying Party to determine what action to take with regards to an 125 Attester. Frequently, this action will be to choose whether to allow 126 the Attester to securely interact with the Relying Party over some 127 connection between the two. 129 When determining whether to allow secure interactions with an 130 Attester, a Relying Party is challenged with a number of difficult 131 problems which it must be able to handle successfully. These 132 problems include: 134 o What Attestation Results (AR) might a Relying Party be willing to 135 trust from a specific Verifier? 137 o What information does a Relying Party need before allowing 138 interactions or choosing policies to apply to a connection? 140 o What are the operating/environmental realities of the Attesting 141 Environment where a Relying Party should only be able to associate 142 a certain confidence regarding Attestation Results out of the 143 Verifier? (In other words, different types of Trusted Execution 144 Environments (TEE) need not be treated as equivalent.) 146 o How to make direct comparisons where there is a heterogeneous mix 147 of Attesting Environments and Verifier types. 149 To address these problems, it is important that specific Attestation 150 Result information elements are framed independently of Attesting 151 Environment specific constraints. If they are not, a Relying Party 152 would be forced to adapt to the syntax and semantics of many vendor 153 specific environments. This is not a reasonable ask as there can be 154 many types of Attesters interacting with or connecting to a Relying 155 Party. 157 The business need therefore is for common Attestation Result 158 information element definitions. With these definitions, consistent 159 interaction or connectivity decisions can be made by a Relying Party 160 where there is a heterogenous mix of Attesting Environment types and 161 Verifier types. 163 This document defines information elements for Attestation Results in 164 a way which normalizes the trustworthiness assertions that can be 165 made from a diverse set of Attesters. 167 1.1. Requirements Notation 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in 172 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 173 capitals, as shown here. 175 1.2. Terminology 177 The following terms are imported from [I-D.ietf-rats-architecture]: 178 Appraisal Policy for Attestation Results, Attester, Attesting 179 Environment, Claims, Evidence, Relying Party, Target Environment and 180 Verifier. 182 [I-D.ietf-rats-architecture] also describes topological patterns that 183 illustrate the need for interoperable conceptual messages. The two 184 patterns called "background-check model" and "passport model" are 185 imported from the RATS architecture and used in this document as a 186 reference to the architectural concepts: Background-Check Model and 187 Passport Model. 189 Newly defined terms for this document: 191 AR-augmented Evidence: a bundle of Evidence which includes at least 192 the following: 194 1. Verifier signed Attestation Results. These Attestation 195 Results must include Identity Evidence for the Attester, a 196 Trustworthiness Vector describing a Verifier's most recent 197 appraisal of an Attester, and some Verifier Proof-of-Freshness 198 (PoF). 200 2. A Relying Party PoF which is bound to the Attestation Results 201 of (1) by the Attester's Attesting Environment signature. 203 3. Sufficient information to determine the elapsed interval 204 between the Verifier PoF and Relying Party PoF. 206 Identity Evidence: Evidence which unambiguously identifies an 207 identity. Identity Evidence could take different forms, such as a 208 certificate, or a signature which can be appraised to have only 209 been generated by a specific private/public key pair. 211 Trustworthiness Claim: a specific quanta of trustworthiness which 212 can be assigned by a Verifier based on its appraisal policy. 214 Trustworthiness Tier: a categorization of the levels of 215 trustworthiness which may be assigned by a Verifier to a specific 216 Trustworthiness Claim. These enumerated categories are: Affirmed, 217 Warning, Contraindicated, and None. 219 Trustworthiness Vector: a set of zero to many Trustworthiness Claims 220 assigned during a single appraisal procedure by a Verifier using 221 Evidence generated by an Attester. The vector is included within 222 Attestation Results. 224 2. Attestation Results for Secure Interactions 226 A Verifier generates the Attestation Results used by a Relying Party. 227 When a Relying Party needs to determine whether to permit 228 communications with an Attester, these Attestation Results must 229 contain a specific set of information elements. This section defines 230 those information elements, and in some cases encodings for 231 information elements. 233 2.1. Information driving a Relying Party Action 235 When the action is a communication establishment attempt with an 236 Attester, there is only a limited set of actions which a Relying 237 Party might take. These actions include: 239 o Allow or deny information exchange with the Attester. When there 240 is a deny, reasons should be returned to the Attester. 242 o Establish a transport connection between an Attester and a 243 specific context within a Relying Party (e.g., a TEE, or Virtual 244 Routing Function (VRF).) 246 o Apply policies on this connection (e.g., rate limits). 248 There are three categories of information which must be conveyed to 249 the Relying Party (which also is integrated with a Verifier) before 250 it determines which of these actions to take. 252 1. Non-repudiable Identity Evidence - Evidence which undoubtably 253 identifies one or more entities involved with a connection. 255 2. Trustworthiness Claims - Specifics a Verifier asserts with 256 regards to its trustworthiness findings about an Attester. 258 3. Claim Freshness - Establishes the time of last update (or 259 refresh) of Trustworthiness Claims. 261 The following sections detail requirements for these three 262 categories. 264 2.2. Non-repudiable Identity 266 Identity Evidence must be conveyed during the establishment of any 267 trust-based relationship. Specific use cases will define the minimum 268 types of identities required by a particular Relying Party as it 269 evaluates Attestation Results, and perhaps additional associated 270 Evidence. At a bare minimum, a Relying Party MUST start with the 271 ability to verify the identity of a Verifier it chooses to trust. 272 Attester identities may then be acquired through signed 273 communications with the Verifier identity and/or the pre-provisioning 274 Attester public keys in the Attester. 276 During the Remote Attestation process, the Verifier's identity will 277 be established with a Relying Party via a Verifier signature across 278 recent Attestation Results. This Verifier identity could only have 279 come from a key pair maintained by a trusted developer or operator of 280 the Verifier. 282 Additionally, each set of Attestation Results must be provably and 283 non-reputably bound to the identity of the original Attesting 284 Environment which was evaluated by the Verifier. This will be 285 accomplished via two items. 286 First the Verifier signed Attestation Results MUST include sufficient 287 Identity Evidence to ensure that this Attesting Environment signature 288 refers to the same Attesting Environment appraised by the Verifier. 289 Second, where the passport model is used as a subsystem, an Attesting 290 Environment signature which spans the Verifier signature MUST also be 291 included. As the Verifier signature already spans the Attester 292 Identity as well as the Attestation Results, this restricts the 293 viability of spoofing attacks. 295 In a subset of use cases, these two pieces of Identity Evidence may 296 be sufficient for a Relying Party to successfully meet the criteria 297 for its Appraisal Policy for Attestation Results. If the use case is 298 a connection request, a Relying Party may simply then establish a 299 transport session with an Attester after a successful appraisal. 300 However an Appraisal Policy for Attestation Results will often be 301 more nuanced, and the Relying Party may need additional information. 302 Some Identity Evidence related policy questions which the Relying 303 Party may consider include: 305 o Does the Relying Party only trust this Verifier to make 306 Trustworthiness Claims on behalf a specific type of Attesting 307 Environment? Might a mix of Verifiers be necessary to cover all 308 mandatory Trustworthiness Claims? 310 o Does the Relying Party only accept connections from a verified- 311 authentic software build from a specific software developer? 313 o Does the Relying Party only accept connections from specific 314 preconfigured list of Attesters? 316 For any of these more nuanced appraisals, additional Identity 317 Evidence or other policy related information must be conveyed or pre- 318 provisioned during the formation of a trust context between the 319 Relying Party, the Attester, the Attester's Attesting Environment, 320 and the Verifier. 322 2.2.1. Attester and Attesting Environment 324 Per [I-D.ietf-rats-architecture] Figure 2, an Attester and a 325 corresponding Attesting Environment might not share common code or 326 even hardware boundaries. Consequently, an Attester implementation 327 needs to ensure that any Evidence which originates from outside the 328 Attesting Environment MUST have been collected and delivered securely 329 before any Attesting Environment signing may occur. After the 330 Verifier performs its appraisal, it will include sufficient 331 information in the Attestation Results to enable a Relying Party to 332 have confidence that the Attester's trustworthiness is represented 333 via Trustworthiness Claims signed by the appropriate Attesting 334 Environment. 336 This document recognizes three general categories of Attesters. 338 1. HSM-based: A Hardware Security Module (HSM) based cryptoprocessor 339 which continually hashes security measurements in a way which 340 prevents an Attester from lying about measurements which have 341 been extended into the Attesting Environment (e.g., TPM2.0.) 343 2. Process-based: An individual process which has its runtime memory 344 encrypted by an Attesting Environment in a way that no other 345 processes can read and decrypt that memory (e.g., [SGX] or 346 [I-D.tschofenig-rats-psa-token].) 348 3. VM-based: An entire Guest VM (or a set of containers within a 349 host) have been encrypted as a walled-garden unit by an Attesting 350 Environment. The result is that the host operating system cannot 351 read and decrypt what is executing within that VM (e.g., 352 [SEV-SNP] or [TDX].) 354 Each of these categories of Attesters above will be capable of 355 generating Evidence which is protected using private keys / 356 certificates which are not accessible outside of the corresponding 357 Attesting Environment. The owner of these secrets is the owner of 358 the identity which is bound within the Attesting Environment. 359 Effectively this means that for any Attester identity, there will 360 exist a chain of trust ultimately bound to a hardware-based root of 361 trust in the Attesting Environment. It is upon this root of trust 362 that unique, non-repudiable Attester identities may be founded. 364 There are several types of Attester identities defined in this 365 document. This list is extensible: 367 o chip-vendor: the vendor of the hardware chip used for the 368 Attesting Environment (e.g., a primary Endorsement Key from a TPM) 370 o chip-hardware: specific hardware with specific firmware from an 371 'ae-vendor' 373 o target-environment: a unique instance of a software build running 374 in an Attester (e.g., MRENCLAVE [SGX], an Instance ID 375 [I-D.tschofenig-rats-psa-token], an Identity Block [SEV-SNP], or a 376 hash which represents a set of software loaded since boot (e.g., 377 TPM based integrity verification.)) 379 o target-developer: the organizational unit responsible for a 380 particular 'target-environment' (e.g., MRSIGNER [SGX]) 382 o instance: a unique instantiated instance of an Attesting 383 Environment running on 'chip-hardware' (e.g., an LDevID 384 [IEEE802.1AR]) 386 Based on the category of the Attesting Environment, different types 387 of identities might be exposed by an Attester. 389 +------------------------+---------------+-----------+-----------+ 390 | Attester Identity type | Process-based | VM-based | HSM-based | 391 +------------------------+---------------+-----------+-----------+ 392 | chip-vendor | Mandatory | Mandatory | Mandatory | 393 | | | | | 394 | chip-hardware | Mandatory | Mandatory | Mandatory | 395 | | | | | 396 | target-environment | Mandatory | Mandatory | Optional | 397 | | | | | 398 | target-developer | Mandatory | Optional | Optional | 399 | | | | | 400 | instance | Optional | Optional | Optional | 401 +------------------------+---------------+-----------+-----------+ 403 It is expected that drafts subsequent to this specification will 404 provide the definitions and value domains for specific identities, 405 each of which falling within the Attester identity types listed 406 above. In some cases the actual unique identities might encoded as 407 complex structures. An example complex structure might be a 'target- 408 environment' encoded as a Software Bill of Materials (SBOM). 410 With the identity definitions and value domains, a Relying Party will 411 have sufficient information to ensure that the Attester identities 412 and Trustworthiness Claims asserted are actually capable of being 413 supported by the underlying type of Attesting Environment. 414 Consequently, the Relying Party SHOULD require Identity Evidence 415 which indicates of the type of Attesting Environment when it 416 considers its Appraisal Policy for Attestation Results. 418 2.2.2. Verifier 420 For the Verifier identity, it is critical for a Relying Party to 421 review the certificate and chain of trust for that Verifier. 422 Additionally, the Relying Party must have confidence that the 423 Trustworthiness Claims being relied upon from the Verifier considered 424 the chain of trust for the Attesting Environment. 426 There are two categorizations Verifier identities defined in this 427 document. 429 o verifier build: a unique instance of a software build running as a 430 Verifier. 432 o verifier developer: the organizational unit responsible for a 433 particular 'verifier build'. 435 Within each category, communicating the identity can be accomplished 436 via a variety of objects and encodings. 438 2.2.3. Communicating Identity 440 Any of the above identities used by the Appraisal Policy for 441 Attestation Results needed to be pre-established by the Relying Party 442 before, or provided during, the exchange of Attestation Results. 443 When provided during this exchange, the identity may be communicated 444 either implicitly or explicitly. 446 An example of explicit communication would be to include the 447 following Identity Evidence directly within the Attestation Results: 448 a unique identifier for an Attesting Environment, the name of a key 449 which can be provably associated with that unique identifier, and the 450 set of Attestation Results which are signed using that key. As these 451 Attestation Results are signed by the Verifier, it is the Verifier 452 which is explicitly asserting the credentials it believes are 453 trustworthy. 455 An example of implicit communication would be to include Identity 456 Evidence in the form of a signature which has been placed over the 457 Attestation Results asserted by a Verifier. It would be then up to 458 the Relying Party's Appraisal Policy for Attestation Results to 459 extract this signature and confirm that it only could have been 460 generated by an Attesting Environment having access to a specific 461 private key. This implicit identity communication is only viable if 462 the Attesting Environment's public key is already known by the 463 Relying Party. 465 One final step in communicating identity is proving the freshness of 466 the Attestation Results to the degree needed by the Relying Party. A 467 typical way to accomplish this is to include an element of freshness 468 be embedded within a signed portion of the Attestation Results. This 469 element of freshness reduces the identity spoofing risks from a 470 replay attack. For more on this, see Section 2.4. 472 2.3. Trustworthiness Claims 474 2.3.1. Design Principles 476 Trust is not absolute. Trust is a belief in some aspect about an 477 entity (in this case an Attester), and that this aspect is something 478 which can be depended upon (in this case by a Relying Party.) Within 479 the context of Remote Attestation, believability of this aspect is 480 facilitated by a Verifier. This facilitation depends on the 481 Verifier's ability to parse detailed Evidence from an Attester and 482 then to assert conclusions about this aspect in a way interpretable 483 by a Relying Party. 485 Specific aspects for which a Verifier will assert trustworthiness are 486 defined in this section. These are known as Trustworthiness Claims. 487 These claims have been designed to enable a common understanding 488 between a broad array of Attesters, Verifiers, and Relying Parties. 489 The following set of design principles have been applied in the 490 Trustworthiness Claim definitions: 492 1. Expose a small number of Trustworthiness Claims. 494 Reason: a plethora of similar Trustworthiness Claims will result 495 in divergent choices made on which to support between different 496 Verifiers. This would place a lot of complexity in the Relying 497 Party as it would be up to the Relying Party (and its policy 498 language) to enable normalization across rich but incompatible 499 Verifier object definitions. 501 2. Each Trustworthiness Claim enumerates only the specific states 502 that could viably result in a different outcome after the Policy 503 for Attestation Results has been applied. 505 Reason: by explicitly disallowing the standardization of 506 enumerated states which cannot easily be connected to a use case, 507 we avoid forcing implementers from making incompatible guesses on 508 what these states might mean. 510 3. Verifier and RP developers need explicit definitions of each 511 state in order to accomplish the goals of (1) and (2). 513 Reason: without such guidance, the Verifier will append plenty of 514 raw supporting info. This relieves the Verifier of making the 515 hard decisions. Of course, this raw info will be mostly non- 516 interpretable and therefore non-actionable by the Relying Party. 518 4. Support standards and non-standard extensibility for (1) and (2). 520 Reason: standard types of Verifier generated Trustworthiness 521 Claims should be vetted by the full RATS working group, rather 522 than being maintained in a repository which doesn't follow the 523 RFC process. This will keep a tight lid on extensions which must 524 be considered by the Relying Party's policy language. Because 525 this process takes time, non-standard extensions will be needed 526 for implementation speed and flexibility. 528 These design principles are important to keep the number of Verifier 529 generated claims low, and to retain the complexity in the Verifier 530 rather than the Relying Party. 532 2.3.2. Enumeration Encoding 534 Per design principle (2), each Trustworthiness Claim will only expose 535 specific encoded values. To simplify the processing of these 536 enumerations by the Relying Party, the enumeration will be encoded as 537 a single signed 8 bit integer. These value assignments for this 538 integer will be in four Trustworthiness Tiers which follow these 539 guidelines: 541 Affirming: The Verifier affirms the Attester support for this aspect 542 of trustworthiness 544 o Values 1 to 31: A standards enumerated reason for affirming. 546 o Values -2 to -32: A non-standard reason for affirming. 548 Warning: The Verifier warns about this aspect of trustworthiness. 550 o Values 32 to 95: A standards enumerated reason for the warning. 552 o Values -33 to -96: A non-standard reason for the warning. 554 Contraindicated: The Verifier asserts the Attester is explicitly 555 untrustworthy in regard to this aspect. 557 o Values 96 to 127: A standards enumerated reason for the 558 contraindication. 560 o Values -97 to -128: A non-standard reason for the 561 contraindication. 563 None: The Verifier makes no assertions about this Trustworthiness 564 Claim. 566 o Value 0: Note: this should always be always treated equivalently 567 by the Relying Party as no claim being made. I.e., the RP's 568 Appraisal Policy for Attestation Results SHOULD NOT make any 569 distinction between a Trustworthiness Claim with enumeration '0', 570 and no Trustworthiness Claim being provided. 572 o Value -1: An unexpected error occurred during the Verifier's 573 appraisal processing. Note: while no claim is being made, the 574 Relying Party MAY make a distinction between a Trustworthiness 575 Claim with enumeration '-1', and no Trustworthiness Claim being 576 provided. 578 This enumerated encoding listed above will simplify the Appraisal 579 Policy for Attestation Results. Such a policies may be as simple as 580 saying that a specific Verifier has recently asserted Trustworthiness 581 Claims, all of which are Affirming. 583 2.3.3. Assigning a Trustworthiness Claim value 585 In order to simplify design, only a single encoded value is asserted 586 by a Verifier for any Trustworthiness Claim within a using the 587 following process. 589 1. If applicable, a Verifier MUST assign a standardized value from 590 the Contraindicated tier. 592 2. Else if applicable, a Verifier MUST assign a non-standardized 593 value from the Contraindicated tier. 595 3. Else if applicable, a Verifier MUST assign a standardized value 596 from the Warning tier. 598 4. Else if applicable, a Verifier MUST assign a non-standardized 599 value from the Warning tier. 601 5. Else if applicable, a Verifier MUST assign a standardized value 602 from the Affirming tier. 604 6. Else if applicable, a Verifier MUST assign a non-standardized 605 value from the Affirming tier. 607 7. Else a Verifier MAY assign a 0 or -1. 609 2.3.4. Specific Claims 611 Following are the Trustworthiness Claims and their supported 612 enumerations which may be asserted by a Verifier: 614 configuration: A Verifier has appraised an Attester's configuration, 615 and is able to make conclusions regarding the exposure of known 616 vulnerabilities 618 0: No assertion 620 1: The configuration is a known and approved config 622 2: The configuration includes or exposes no known vulnerabilities 623 32: The configuration includes or exposes known vulnerabilities 625 96: The configuration is unsupportable as it exposes unacceptable 626 security vulnerabilities 628 -1: Unexpected error 630 executables: A Verifier has appraised and evaluated relevant runtime 631 files, scripts, and/or other objects which have been loaded into 632 the Target environment's memory. 634 0: No assertion 636 1: Only a recognized genuine set of approved executables, scripts, 637 files, and/or objects have been loaded during and after the 638 boot process. 640 2: Only a recognized genuine set of approved executables have been 641 loaded during the boot process. 643 32: Only a recognized genuine set of executables, scripts, files, 644 and/or objects have been loaded. However the Verifier cannot 645 vouch for a subset of these due to known bugs or other known 646 vulnerabilities. 648 33: Runtime memory includes executables, scripts, files, and/or 649 objects which are not recognized. 651 96: Runtime memory includes executables, scripts, files, and/or 652 object which are contraindicated. 654 -1: Unexpected error 656 file-system: A Verifier has evaluated the Attester's file system. 658 0: No assertion 660 1: Only a recognized set of approved files are found. 662 32: The file system includes unrecognized executables, scripts, 663 or files. 665 96: The file system includes contraindicated executables, 666 scripts, or files 668 -1: Unexpected error 670 hardware: A Verifier has appraised any Attester hardware and 671 firmware which are able to expose fingerprints of their identity 672 and running code. 674 0: No assertion 676 1: An Attester has passed its hardware and/or firmware 677 verifications needed to demonstrate that these are genuine/ 678 supported. 680 32: An Attester contains only genuine/supported hardware and/or 681 firmware, but there are known security vulnerabilities. 683 96: Attester hardware and/or firmware is recognized, but its 684 trustworthiness is contraindicated. 686 97: A Verifier does not recognize an Attester's hardware or 687 firmware, but it should be recognized. 689 -1: Unexpected error 691 instance-identity: A Verifier has appraised an Attesting 692 Environment's unique identity based upon private key signed 693 Evidence which can be correlated to a unique instantiated instance 694 of the Attester. (Note: this Trustworthiness Claim should only be 695 generated if the Verifier actually expects to recognize the unique 696 identity of the Attester.) 698 0: No assertion 700 1: The Attesting Environment is recognized, and the associated 701 instance of the Attester is not known to be compromised. 703 96: The Attesting Environment is recognized, and but its unique 704 private key indicates a device which is not trustworthy. 706 97: The Attesting Environment is not recognized; however the 707 Verifier believes it should be. 709 -1: Unexpected error 711 runtime-opaque: A Verifier has appraised the visibility of Attester 712 objects in memory from perspectives outside the Attester. 714 0: No assertion 716 1: the Attester's executing Target Environment and Attesting 717 Environments are encrypted and within Trusted Execution 718 Environment(s) opaque to the operating system, virtual machine 719 manager, and peer applications. (Note: This value corresponds 720 to the protections asserted by O.RUNTIME_CONFIDENTIALITY from 721 [GP-TEE-PP]) 723 32: the Attester's executing Target Environment and Attesting 724 Environments inaccessible from any other parallel application 725 or Guest VM running on the Attester's physical device. (Note 726 that unlike "1" these environments are not encrypted in a way 727 which restricts the Attester's root operator visibility. See 728 O.TA_ISOLATION from [GP-TEE-PP].) 730 96: The Verifier has concluded that in memory objects are 731 unacceptably visible within the physical host that supports the 732 Attester. 734 -1: Unexpected error 736 sourced-data: A Verifier has evaluated of the integrity of data 737 objects from external systems used by the Attester. 739 0: No assertion 741 1: All essential Attester source data objects have been provided 742 by other Attester(s) whose most recent appraisal(s) had both no 743 Trustworthiness Claims of "0" where the current Trustworthiness 744 Claim is "Affirming", as well as no "Warning" or 745 "Contraindicated" Trustworthiness Claims. 747 32: Attester source data objects come from unattested sources, or 748 attested sources with "Warning" type Trustworthiness Claims. 750 96: Attester source data objects come from contraindicated 751 sources. 753 -1: Unexpected error 755 storage-opaque: A Verifier has appraised that an Attester is capable 756 of encrypting persistent storage. (Note: Protections must meet 757 the capabilities of [OMTP-ATE] Section 5, but need not be hardware 758 tamper resistant.) 760 0: No assertion 762 1: the Attester encrypts all secrets in persistent storage via 763 using keys which are never visible outside an HSM or the 764 Trusted Execution Environment hardware. 766 32: the Attester encrypts all persistently stored secrets, but 767 without using hardware backed keys 769 96: There are persistent secrets which are stored unencrypted in 770 an Attester. 772 -1: Unexpected error 774 It is possible for additonal Trustworthiness Claims and enumerated 775 values to be defined in subsequent documents. At the same time, the 776 standardized Trustworthiness Claim values listed above have been 777 designed so there is no overlap within a Trustworthiness Tier. As a 778 result, it is possible to imagine a future where overlapping 779 Trustworthiness Claims within a single Trustworthiness Tier may be 780 defined. Wherever possible, the Verifier SHOULD assign the best 781 fitting standardized value. 783 Where a Relying Party doesn't know how to handle a particular 784 Trustworthiness Claim, it MAY choose an appropriate action based on 785 the Trustworthiness Tier under which the enumerated value fits. 787 It is up to the Verifier to publish the types of evaluations it 788 performs when determining how Trustworthiness Claims are derived for 789 a type of any particular type of Attester. It is out of the scope of 790 this document for the Verifier to provide proof or specific logic on 791 how a particular Trustworthiness Claim which it is asserting was 792 derived. 794 2.3.5. Trustworthiness Vector 796 Multiple Trustworthiness Claims may be asserted about an Attesting 797 Environment at single point in time. The set of Trustworthiness 798 Claims inserted into an instance of Attestation Results by a Verifier 799 is known as a Trustworthiness Vector. The order of Claims in the 800 vector is NOT meaningful. A Trustworthiness Vector with no 801 Trustworthiness Claims (i.e., a null Trustworthiness Vector) is a 802 valid construct. In this case, the Verifier is making no 803 Trustworthiness Claims but is confirming that an appraisal has been 804 made. 806 2.3.6. Trustworthiness Vector for a type of Attesting Environment 808 Some Trustworthiness Claims are implicit based on the underlying type 809 of Attesting Environment. For example, a validated MRSIGNER identity 810 can be present where the underlying [SGX] hardware is 'hw-authentic'. 811 Where such implicit Trustworthiness Claims exist, they do not have to 812 be explicitly included in the Trustworthiness Vector. However, these 813 implicit Trustworthiness Claims SHOULD be considered as being present 814 by the Relying Party. Another way of saying this is if a 815 Trustworthiness Claim is automatically supported as a result of 816 coming from a specific type of TEE, that claim need not be 817 redundantly articulated. Such implicit Trustworthiness Claims can be 818 seen in the tables within Appendix A.2 and Appendix A.3. 820 Additionally, there are some Trustworthiness Claims which cannot be 821 adequately supported by an Attesting Environment. For example, it 822 would be difficult for an Attester that includes only a TPM (and no 823 other TEE) from ever having a Verifier appraise support for 'runtime- 824 opaque'. As such, a Relying Party would be acting properly if it 825 rejects any non-supportable Trustworthiness Claims asserted from a 826 Verifier. 828 As a result, the need for the ability to carry a specific 829 Trustworthiness Claim will vary by the type of Attesting Environment. 830 Example mappings can be seen in Appendix A. 832 2.4. Freshness 834 A Relying Party will care about the recentness of the Attestation 835 Results, and the specific Trustworthiness Claims which are embedded. 836 All freshness mechanisms of [I-D.ietf-rats-architecture], Section 10 837 are supportable by this specification. 839 Additionally, a Relying Party may track when a Verifier expires its 840 confidence for the Trustworthiness Claims or the Trustworthiness 841 Vector as a whole. Mechanisms for such expiry are not defined within 842 this document. 844 There is a subset of secure interactions where the freshness of 845 Trustworthiness Claims may need to be revisited asynchronously. This 846 subset is when trustworthiness depends on the continuous availability 847 of a transport session between the Attester and Relying Party. With 848 such connectivity dependent Attestation Results, if there is a reboot 849 which resets transport connectivity, all established Trustworthiness 850 Claims should be cleared. Subsequent connection re-establishment 851 will allow fresh new Trustworthiness Claims to be delivered. 853 3. Secure Interactions Models 855 There are multiple ways of providing a Trustworthiness Vector to a 856 Relying Party. This section describes two alternatives. 858 3.1. Pure Background-Check retrieval 860 It is possible to for a Relying Party to follow the Background-Check 861 Model defined in Section 5.2 of [I-D.ietf-rats-architecture]. In 862 this case, a Relying Party will receive Attestation Results 863 containing the Trustworthiness Vector directly from a Verifier. 864 These Attestation Results can then be used by the Relying Party in 865 determining the appropriate treatment for interactions with the 866 Attester. 868 While applicable in some cases, the utilization of the Background- 869 Check Model without modification has potential drawbacks in other 870 cases. These include: 872 o Verifier scale: if the Attester has many Relying Parties, a 873 Verifier appraising that Attester could be frequently be queried 874 based on the same Evidence. 876 o Information leak: Evidence which the Attester might consider 877 private can be visible to the Relying Party. Hiding that Evidence 878 could devalue any resulting appraisal. 880 o Latency: a Relying Party will need to wait for the Verifier to 881 return Attestation Results before proceeding with secure 882 interactions with the Attester. 884 An implementer should examine these potential drawbacks before 885 selecting this alternative. 887 3.2. Attestation Result Augmented Evidence 889 There is a hybrid alternative for the establishment and maintenance 890 of trustworthiness between an Attester and a Relying Party which is 891 not adversely impacted by the potential drawbacks with pure 892 background-check. In this alternative, a Verifier evaluates an 893 Attester and returns signed Attestation Results back to this original 894 Attester no less frequently than a well-known interval. This 895 interval may also be asynchronous, based on the changing of certain 896 Evidence as described in 897 [I-D.birkholz-rats-network-device-subscription]. 899 When a Relying Party is to receive information about the Attester's 900 trustworthiness, the Attesting Environment assembles the minimal set 901 of Evidence which can be used to confirm or refute whether the 902 Attester remains in the state of trustworthiness represented by the 903 AR. To this Evidence, the Attesting Environment appends the 904 signature from the most recent AR as well as a Relying Party Proof- 905 of-Freshness. The Attesting Environment then signs the combination. 907 The Attester then assembles AR Augmented Evidence by taking the 908 signed combination and appending the full AR. The assembly now 909 consists of two independent but semantically bound sets of signed 910 Evidence. 912 The AR Augmented Evidence is then sent to the Relying Party. The 913 Relying Party then can appraise these semantically bound sets of 914 signed Evidence by applying an Appraisal Policy for Attestation 915 Results as described below. This policy will consider both the AR as 916 well as additional information about the Attester within the AR 917 Augmented Evidence the when determining what action to take. 919 This alternative combines the [I-D.ietf-rats-architecture] Sections 920 5.1 Passport Model and Section 5.2 Background-Check Model. Figure 1 921 describes this flow of information. The flows within this combined 922 model are mapped to [I-D.ietf-rats-architecture] in the following 923 way. "Verifier A" below corresponds to the "Verifier" Figure 5 924 within [I-D.ietf-rats-architecture]. And "Relying Party/Verifier B" 925 below corresponds to the union of the "Relying Party" and "Verifier" 926 boxes within Figure 6 of [I-D.ietf-rats-architecture]. This union is 927 possible because Verifier B can be implemented as a simple, self- 928 contained process. The resulting combined process can appraise the 929 AR-augmented Evidence to determine whether an Attester qualifies for 930 secure interactions with the Relying Party. The specific steps of 931 this process are defined later in this section. 933 .----------------. 934 | Attester | 935 | .-------------.| 936 | | Attesting || .----------. .---------------. 937 | | Environment || | Verifier | | Relying Party | 938 | '-------------'| | A | | / Verifier B | 939 '----------------' '----------' '---------------' 940 time(VG) | | 941 |<------Verifier PoF-------time(NS) | 942 | | | 943 time(EG)(1)------Evidence------------>| | 944 | time(RG) | 945 |<------Attestation Results-(2) | 946 ~ ~ ~ 947 time(VG')? | | 948 ~ ~ ~ 949 |<------Relying Party PoF-----------------(3)time(NS') 950 | | | 951 time(EG')(4)------AR-augmented Evidence----------------->| 952 | | time(RG',RA')(5) 953 (6) 954 ~ 955 time(RX') 957 Figure 1: Secure Interactions Model 959 The interaction model depicted above includes specific time related 960 events from Appendix A of [I-D.ietf-rats-architecture]. With the 961 identification of these time related events, time duration/interval 962 tracking becomes possible. Such duration/interval tracking can 963 become important if the Relying Party cares if too much time has 964 elapsed between the Verifier PoF and Relying Party PoF. If too much 965 time has elapsed, perhaps the Attestation Results themselves are no 966 longer trustworthy. 968 Note that while time intervals will often be relevant, there is a 969 simplified case that does not require a Relying Party's PoF in step 970 (3). In this simplified case, the Relying Party trusts that the 971 Attester cannot be meaningfully changed from the outside during any 972 reportable interval. Based on that assumption, and when this is the 973 case then the step of the Relying Party PoF can be safely omitted. 975 In all cases, appraisal policies define the conditions and 976 prerequisites for when an Attester does qualify for secure 977 interactions. To qualify, an Attester has to be able to provide all 978 of the mandatory affirming Trustworthiness Claims and identities 979 needed by a Relying Party's Appraisal Policy for Attestation Results, 980 and none of the disqualifying detracting Trustworthiness Claims. 982 More details on each interaction step are as follows. The numbers 983 used in this sequence match to the numbered steps in Figure 1: 985 1. An Attester sends Evidence which is provably fresh to Verifier A 986 at time(EG). Freshness from the perspective of Verifier A MAY be 987 established with Verifier PoF such as a nonce. 989 2. Verifier A appraises (1), then sends the following items back to 990 that Attester within Attestation Results: 992 1. the verified identity of the Attesting Environment, 994 2. the Verifier A appraised Trustworthiness Vector of an 995 Attester, 997 3. a freshness proof associated with the Attestation Results, 999 4. a Verifier signature across (2.1) though (2.3). 1001 3. At time(EG') a Relying Party PoF (such as a nonce) known to the 1002 Relying Party is sent to the Attester. 1004 4. The Attester generates and sends AR-augmented Evidence to the 1005 Relying Party/Verifier B. This AR-augmented Evidence includes: 1007 1. The Attestation Results from (2) 1009 2. Any (optionally) new incremental Evidence from the Attesting 1010 Environment 1012 3. Attestation Environment signature which spans a hash of the 1013 Attestation Results (such as the signature of (2.4)), the 1014 proof-of-freshness from (3), and (4.2). Note: this construct 1015 allows the delta of time between (2.3) and (3) to be 1016 definitively calculated by the Relying Party. 1018 5. On receipt of (4), the Relying Party applies its Appraisal Policy 1019 for Attestation Results. At minimum, this appraisal policy 1020 process must include the following: 1022 1. Verify that (4.3) includes the nonce from (3). 1024 2. Use a local certificate to validate the signature (4.1). 1026 3. Verify that the hash from (4.3) matches (4.1) 1028 4. Use the identity of (2.1) to validate the signature of (4.3). 1030 5. Failure of any steps (5.1) through (5.4) means the link does 1031 not meet minimum validation criteria, therefore appraise the 1032 link as having a null Verifier B Trustworthiness Vector. 1033 Jump to step (6.1). 1035 6. When there is large or uncertain time gap between time(EG) 1036 and time(EG'), the link should be assigned a null Verifier B 1037 Trustworthiness Vector. Jump to step (6.1). 1039 7. Assemble the Verifier B Trustworthiness Vector 1041 1. Copy Verifier A Trustworthiness Vector to Verifier B 1042 Trustworthiness Vector 1044 2. Add implicit Trustworthiness Claims inherent to the type 1045 of TEE. 1047 3. Prune any Trustworthiness Claims unsupportable by the 1048 Attesting Environment. 1050 4. Prune any Trustworthiness Claims the Relying Party 1051 doesn't accept from this Verifier. 1053 6. The Relying Party takes action based on Verifier B's appraised 1054 Trustworthiness Vector: 1056 1. Prune any Trustworthiness Claims not used in the Appraisal 1057 Policy for Attestation Results. 1059 2. Allow the information exchange from the Attester into a 1060 Relying Party context where the Verifier B appraised 1061 Trustworthiness Vector includes all the mandatory 1062 Trustworthiness Claims of value "1", and none of the 1063 disqualifying Trustworthiness Claims containing values that 1064 are not "0" or "1". 1066 3. Disallow any information exchange into a Relying Party 1067 context for which that Verifier B appraised Trustworthiness 1068 Vector is not qualified. 1070 As link layer protocols re-authenticate, steps (1) to (2) and steps 1071 (3) to (6) will independently refresh. This allows the 1072 Trustworthiness of Attester to be continuously re-appraised. There 1073 are only specific event triggers which will drive the refresh of 1074 Evidence generation (1), Attestation Result generation (2), or AR- 1075 augmented Evidence generation (4): 1077 o life-cycle events, e.g. a change to an Authentication Secret of 1078 the Attester or an update of a software component. 1080 o uptime-cycle events, e.g. a hard reset or a re-initialization of 1081 an Attester. 1083 o authentication-cycle events, e.g. a link-layer interface reset 1084 could result in a new (4). 1086 3.3. Mutual Attestation 1088 In the interaction models described above, each device on either side 1089 of a secure interaction may require remote attestation of its peer. 1090 This process is known as mutual-attestation. To support mutual- 1091 attestation, the interaction models listed above may be run 1092 independently on either side of the connection. 1094 3.4. Transport Protocol Integration 1096 Either unidirectional attestation or mutual attestation may be 1097 supported within the protocol interactions needed for the 1098 establishment of a single transport session. While this document 1099 does not mandate specific transport protocols, messages containing 1100 the Attestation Results and AR Augmented Evidence can be passed 1101 within an authentication framework such the EAP protocol [RFC5247] 1102 over TLS [RFC8446]. 1104 4. Privacy Considerations 1106 Privacy Considerations Text 1108 5. Security Considerations 1110 Security Considerations Text 1112 6. IANA Considerations 1114 See Body. 1116 7. References 1118 7.1. Normative References 1120 [GP-TEE-PP] 1121 "Global Platform TEE Protection Profile v1.3", September 1122 2020, . 1125 [I-D.ietf-rats-architecture] 1126 Fraunhofer SIT, Microsoft, Sandelman Software Works, Intel 1127 Corporation, and Huawei Technologies, "Remote Attestation 1128 Procedures Architecture", draft-ietf-rats-architecture-12 1129 (work in progress), April 2021. 1131 [OMTP-ATE] 1132 "Open Mobile Terminal Platform - Advanced Trusted 1133 Environment", May 2009, . 1137 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1138 Requirement Levels", BCP 14, RFC 2119, 1139 DOI 10.17487/RFC2119, March 1997, 1140 . 1142 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1143 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1144 May 2017, . 1146 7.2. Informative References 1148 [I-D.birkholz-rats-network-device-subscription] 1149 Fraunhofer SIT, Cisco Systems, Inc., and Huawei 1150 Technologies, "Attestation Event Stream Subscription", 1151 draft-birkholz-rats-network-device-subscription-03 (work 1152 in progress), August 2021. 1154 [I-D.tschofenig-rats-psa-token] 1155 Arm Limited, Arm Limited, Arm Limited, Arm Limited, and 1156 Arm Limited, "Arm's Platform Security Architecture (PSA) 1157 Attestation Token", draft-tschofenig-rats-psa-token-08 1158 (work in progress), March 2021. 1160 [IEEE802.1AR] 1161 "802.1AR: Secure Device Identity", August 2018, 1162 . 1164 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1165 Authentication Protocol (EAP) Key Management Framework", 1166 RFC 5247, DOI 10.17487/RFC5247, August 2008, 1167 . 1169 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1170 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1171 . 1173 [SEV-SNP] "AMD SEV-SNP: Stregthening VM Isolation with Integrity 1174 Protection and More", 2020, 1175 . 1179 [SGX] "Supporting Third Party Attestation for Intel SGX with 1180 Intel Data Center Attestation Primitives", 2017, . 1185 [TDX] "Intel Trust Domain Extensions", 2020, . 1189 [TPM-ID] "TPM Keys for Platform Identity for TPM 1.2", August 2015, 1190 . 1193 [US-Executive-Order] 1194 "Executive Order on Improving the Nation's Cybersecurity", 1195 May 2021, . 1199 Appendix A. Supportable Trustworthiness Claims 1201 The following is a table which shows what Claims are supportable by 1202 different Attesting Environment types. Note that claims MAY BE 1203 implicit to an Attesting Environment type, and therefore do not have 1204 to be included in the Trustworthiness Vector to be considered as set 1205 by the Relying Party. 1207 A.1. Supportable Trustworthiness Claims for HSM-based CC 1209 Following are Trustworthiness Claims which MAY be set for a HSM-based 1210 Confidential Computing Attester. (Such as a TPM [TPM-ID].) 1211 +-------------------+-----------+-----------------------------------+ 1212 | Trustworthiness | Required? | Appraisal Method | 1213 | Claim | | | 1214 +-------------------+-----------+-----------------------------------+ 1215 | configuration | Optional | Verifier evaluation of Attester | 1216 | | | reveals no configuration lines | 1217 | | | which expose the Attester to | 1218 | | | known security vulnerabilities. | 1219 | | | This may be done with or without | 1220 | | | the involvement of a TPM PCR. | 1221 | | | | 1222 | executables | Yes | Checks the TPM PCRs for the | 1223 | | | static operating system, and for | 1224 | | | any tracked files subsequently | 1225 | | | loaded | 1226 | | | | 1227 | file-system | No | Can be supported, but TPM | 1228 | | | tracking is unlikely | 1229 | | | | 1230 | hardware | Yes | If TPM PCR check ok from BIOS | 1231 | | | checks, through Master Boot | 1232 | | | Record configuration | 1233 | | | | 1234 | instance-identity | Optional | Check IDevID | 1235 | | | | 1236 | runtime-opaque | n/a | TPMs are not recommended to | 1237 | | | provide a sufficient technology | 1238 | | | base for this Trustworthiness | 1239 | | | Claim. | 1240 | | | | 1241 | sourced-data | n/a | TPMs are not recommended to | 1242 | | | provide a sufficient technology | 1243 | | | base for this Trustworthiness | 1244 | | | Claim. | 1245 | | | | 1246 | storage-opaque | Minimal | With a TPM, secure storage space | 1247 | | | exists and is writeable by | 1248 | | | external applications. But the | 1249 | | | space is so limited that it often | 1250 | | | is used just be used to store | 1251 | | | keys. | 1252 +-------------------+-----------+-----------------------------------+ 1254 Setting the Trustworthiness Claims may follow the following logic at 1255 the Verifier A within (2) of Figure 1: 1257 Start: Evidence received starts the generation of a new 1258 Trustworthiness Vector. (e.g., TPM Quote Received, log received, 1259 or appraisal timer expired) 1261 Step 0: set Trustworthiness Vector = Null 1263 Step 1: Is there sufficient fresh signed evidence to appraise? 1264 (yes) - No Action 1265 (no) - Goto Step 6 1267 Step 2: Appraise Hardware Integrity PCRs 1268 if (hardware NOT "0") - push onto vector 1269 if (hardware NOT affirming or warning), go to Step 6 1271 Step 3: Appraise Attesting Environment identity 1272 if (instance-identity <> "0") - push onto vector 1274 Step 4: Appraise executable loaded and filesystem integrity 1275 if (executables NOT "0") - push onto vector 1276 if (executables NOT affirming or warning), go to Step 6 1278 Step 5: Appraise all remaining Trustworthiness Claims 1279 Independently and set as appropriate. 1281 Step 6: Assemble Attestation Results, and push to Attester 1283 End 1285 A.2. Supportable Trustworthiness Claims for process-based CC 1287 Following are Trustworthiness Claims which MAY be set for a process- 1288 based Confidential Computing based Attester. (Such as a SGX Enclaves 1289 and TrustZone.) 1290 +-------------------+-----------+-----------------------------------+ 1291 | Trustworthiness | Required? | Appraisal Method | 1292 | Claim | | | 1293 +-------------------+-----------+-----------------------------------+ 1294 | instance-identity | Optional | Internally available in TEE. But | 1295 | | | keys might not be known/exposed | 1296 | | | to the Relying Party by the | 1297 | | | Attesting Environment. | 1298 | | | | 1299 | configuration | Optional | If done, this is at the | 1300 | | | Application Layer. Plus each | 1301 | | | process needs it own protection | 1302 | | | mechanism as the protection is | 1303 | | | limited to the process itself. | 1304 | | | | 1305 | executables | Optional | Internally available in TEE. But | 1306 | | | keys might not be known/exposed | 1307 | | | to the Relying Party by the | 1308 | | | Attesting Environment. | 1309 | | | | 1310 | file-system | Optional | Can be supported by application, | 1311 | | | but process-based CC is not a | 1312 | | | sufficient technology base for | 1313 | | | this Trustworthiness Claim. | 1314 | | | | 1315 | hardware | Implicit | At least the TEE is protected | 1316 | | in | here. Other elements of the | 1317 | | signature | system outside of the TEE might | 1318 | | | need additional protections is | 1319 | | | used by the application process. | 1320 | | | | 1321 | runtime-opaque | Implicit | From the TEE | 1322 | | in | | 1323 | | signature | | 1324 | | | | 1325 | storage-opaque | Implicit | Although the application must | 1326 | | in | assert that this function is used | 1327 | | signature | by the code itself. | 1328 | | | | 1329 | sourced-data | Optional | Will need to be supported by | 1330 | | | application code | 1331 +-------------------+-----------+-----------------------------------+ 1333 A.3. Supportable Trustworthiness Claims for VM-based CC 1335 Following are Trustworthiness Claims which MAY be set for a VM-based 1336 Confidential Computing based Attester. (Such as SEV, TDX, ACCA, SEV- 1337 SNP.) 1338 +-------------------+-----------+-----------------------------------+ 1339 | Trustworthiness | Required? | Appraisal Method | 1340 | Claim | | | 1341 +-------------------+-----------+-----------------------------------+ 1342 | instance-identity | Optional | Internally available in TEE. But | 1343 | | | keys might not be known/exposed | 1344 | | | to the Relying Party by the | 1345 | | | Attesting Environment. | 1346 | | | | 1347 | configuration | Optional | Requires application integration. | 1348 | | | Easier than with process-based | 1349 | | | solution, as the whole protected | 1350 | | | machine can be evaluated. | 1351 | | | | 1352 | executables | Optional | Internally available in TEE. But | 1353 | | | keys might not be known/exposed | 1354 | | | to the Relying Party by the | 1355 | | | Attesting Environment. | 1356 | | | | 1357 | file-system | Optional | Can be supported by application | 1358 | | | | 1359 | hardware | Chip | At least the TEE is protected | 1360 | | dependent | here. Other elements of the | 1361 | | | system outside of the TEE might | 1362 | | | need additional protections is | 1363 | | | used by the application process. | 1364 | | | | 1365 | runtime-opaque | Implicit | From the TEE | 1366 | | in | | 1367 | | signature | | 1368 | | | | 1369 | storage-opaque | Chip | Although the application must | 1370 | | dependent | assert that this function is used | 1371 | | | by the code itself. | 1372 | | | | 1373 | sourced-data | Optional | Will need to be supported by | 1374 | | | application code | 1375 +-------------------+-----------+-----------------------------------+ 1377 Appendix B. Some issues being worked 1379 It is possible for a cluster/hierarchy of Verifiers to have aggregate 1380 AR which are perhaps signed/endorsed by a lead Verifier. What should 1381 be the Proof-of-Freshness or Verifier associated with any of the 1382 aggregate set of Trustworthiness Claims? 1384 There will need to be a subsequent document which documents how these 1385 objects which will be translated into a protocol on a wire (e.g. EAP 1386 on TLS). Some breakpoint between what is in this draft, and what is 1387 in specific drafts for wire encoding will need to be determined. 1388 Questions like architecting the cluster/hierarchy of Verifiers fall 1389 into this breakdown. 1391 For some Trustworthiness Claims, there could be value in identifying 1392 a specific Appraisal Policy for Attestation Results applied within 1393 the Attester. One way this could be done would be a URI which 1394 identifies the policy used at Verifier A, and this URI would 1395 reference a specific Trustworthiness Claim. As the URI also could 1396 encode the version of the software, it might also act as a mechanism 1397 to signal the Relying Party to refresh/re-evaluate its view of 1398 Verifier A. Do we need this type of structure to be included here? 1399 Should it be in subsequent documents? 1401 Expand the variant of Figure 1 which requires no Relying Party PoF 1402 into its own picture. 1404 In what document (if any) do we attempt normalization of the identity 1405 claims between different types of TEE. E.g., does MRSIGNER plus 1406 extra loaded software = the sum of TrustZone Signer IDs for loaded 1407 components? 1409 Appendix C. Contributors 1411 Guy Fedorkow 1413 Email: gfedorkow@juniper.net 1415 Dave Thaler 1417 Email: dthaler@microsoft.com 1419 Ned Smith 1421 Email: ned.smith@intel.com 1423 Authors' Addresses 1425 Eric Voit 1426 Cisco Systems 1428 Email: evoit@cisco.com 1429 Henk Birkholz 1430 Fraunhofer SIT 1431 Rheinstrasse 75 1432 Darmstadt 64295 1433 Germany 1435 Email: henk.birkholz@sit.fraunhofer.de 1437 Thomas Hardjono 1438 MIT 1440 Email: hardjono@mit.edu 1442 Thomas Fossati 1443 Arm Limited 1445 Email: Thomas.Fossati@arm.com 1447 Vincent Scarlata 1448 Intel 1450 Email: vincent.r.scarlata@intel.com