idnits 2.17.1 draft-voit-rats-attestation-results-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 : ---------------------------------------------------------------------------- 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 (10 June 2021) is 1044 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: 'TPM-ID' is defined on line 887, but no explicit reference was found in the text -- 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 (~~), 4 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: 12 December 2021 Fraunhofer SIT 6 T. Hardjono 7 MIT 8 T. Fossati 9 Arm Limited 10 V. Scarlata 11 Intel 12 10 June 2021 14 Attestation Results for Secure Interactions 15 draft-voit-rats-attestation-results-01 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 heterogenous 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 12 December 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. AR Augmented Evidence and Actions . . . . . . . . . . . . . . 5 64 2.1. Attestation Results for Secure Interactions . . . . . . . 5 65 2.2. Non-repudiable Identity . . . . . . . . . . . . . . . . . 6 66 2.2.1. Attester and Attesting Environment . . . . . . . . . 7 67 2.2.2. Verifier . . . . . . . . . . . . . . . . . . . . . . 9 68 2.2.3. Communicating Identity . . . . . . . . . . . . . . . 10 69 2.3. Trustworthiness Claims . . . . . . . . . . . . . . . . . 10 70 2.3.1. Specific Claims . . . . . . . . . . . . . . . . . . . 10 71 2.3.2. Trustworthiness Vector . . . . . . . . . . . . . . . 13 72 2.3.3. Trustworthiness Vector for a type of Attesting 73 Environment . . . . . . . . . . . . . . . . . . . . . 14 74 2.4. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 14 75 3. Secure Interactions Model . . . . . . . . . . . . . . . . . . 15 76 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 81 7.2. Informative References . . . . . . . . . . . . . . . . . 19 82 Appendix A. Supportable Trustworthiness Claims . . . . . . . . . 20 83 A.1. Supportable Trustworthiness Claims for HSM-based CC . . . 20 84 A.2. Supportable Trustworthiness Claims for process-based 85 CC . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 A.3. Supportable Trustworthiness Claims for VM-based CC . . . 23 87 Appendix B. Some issues being worked . . . . . . . . . . . . . . 24 88 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 25 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 91 1. Introduction 93 The first paragraph of the May 2021 US Presidential Executive Order 94 on Improving the Nation's Cybersecurity [US-Executive-Order] ends 95 with the statement "the trust we place in our digital infrastructure 96 should be proportional to how trustworthy and transparent that 97 infrastructure is." Later this order explores aspects of 98 trustworthiness such as an auditable trust relationship, which it 99 defines as an "agreed-upon relationship between two or more system 100 elements that is governed by criteria for secure interaction, 101 behavior, and outcomes." 103 The Remote ATtestation procedureS (RATS) architecture 104 [I-D.ietf-rats-architecture] provides a useful context for 105 programmatically establishing and maintaining such auditable trust 106 relationships. Specifically, the architecture defines conceptual 107 messages conveyed between architectural subsystems to support 108 trustworthiness appraisal. The RATS conceptual message used to 109 convey evidence of trustworthiness is the Attestation Results. The 110 Attestation Results includes Verifier generated appraisals of an 111 Attester including such information as the identity of the Attester, 112 the security mechanisms employed on this Attester, and the Attester's 113 current state of trustworthiness. 115 Generated Attestation Results are ultimately conveyed to one or more 116 Relying Parties. Reception of an Attestation Result enables a 117 Relying Party to determine what action to take with regards to an 118 Attester. Frequently, this action will be to choose whether to allow 119 the Attester to securely interact with the Relying Party over some 120 connection between the two. 122 When determining whether to allow secure interactions with an 123 Attester, a Relying Party is challenged with a number of difficult 124 problems which it must be able to handle successfully. These 125 problems include: 127 * What types of Attestation Results (AR) might a Relying Party be 128 willing to trust from a specific type of Verifier? 130 * What supplemental information must the Verifier need to include 131 within Attestation Results to convince a Relying Party to allow 132 interactions, or to apply policies to any connections, based on 133 these Attestation Results? 135 * What are the operating/environmental realities of the Attesting 136 Environment where a Relying Party should only be able to associate 137 a certain confidence regarding Attestation Results out of the 138 Verifier? (In other words, different types of Trusted Execution 139 Environments (TEE) need not be treated as equivalent.) 141 * How to make direct comparisons where there is a heterogeneous mix 142 of Attesting Environments and Verifier types. 144 To address these problems, it is important that specific Attestation 145 Result information elements are framed independently of Attesting 146 Environment specific constraints. If they are not, a Relying Party 147 would be forced to adapt to the syntax and semantics of many vendor 148 specific environments. This is not a reasonable ask as there can be 149 many types of Attesters interacting with or connecting to a Relying 150 Party. 152 The business need therefore is for common Attestation Result 153 information element definitions. With these definitions, consistent 154 interaction or connectivity decisions can be made by a Relying Party 155 where there is a heterogenous mix of Attesting Environment types and 156 Verifier types. 158 This document defines information elements for Attestation Results in 159 a way which normalizes the trustworthiness assertions that can be 160 made from a diverse set of Attesters. 162 1.1. Requirements Notation 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in 167 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 168 capitals, as shown here. 170 1.2. Terminology 172 The following terms are imported from [I-D.ietf-rats-architecture]: 173 Appraisal Policy for Attestation Results, Attester, Attesting 174 Environment, Claims, Evidence, Relying Party, Target Environment and 175 Verifier. 177 [I-D.ietf-rats-architecture] also describes topological patterns that 178 illustrate the need for interoperable conceptual messages. The two 179 patterns called "background-check model" and "passport model" are 180 imported from the RATS architecture and used in this document as a 181 reference to the architectural concepts: Background-Check Model and 182 Passport Model. 184 Newly defined terms for this document: 186 AR-augmented Evidence: a bundle of Evidence which includes at least 187 the following: 189 1. Verifier signed Attestation Results. These Attestation 190 Results must include Identity Evidence for the Attester, a 191 Trustworthiness Vector describing a Verifier's most recent 192 appraisal of an Attester, and some Verifier Proof-of-Freshness 193 (PoF). 195 2. A Relying Party PoF which is bound to the Attestation Results 196 of (1) by the Attester's Attesting Environment signature. 198 3. Sufficient information to determine the elapsed interval 199 between the Verifier PoF and Relying Party PoF. 201 Identity Evidence: Evidence which unambiguously identifies an 202 identity. Identity Evidence could take different forms, such as a 203 certificate, or a signature which can be appraised to have only 204 been generated by a specific private/public key pair. 206 Trustworthiness Claim: a specific quanta of trustworthiness which 207 can be assigned by a Verifier based on its appraisal policy. 209 Trustworthiness Vector: a set of zero to many Trustworthiness Claims 210 assigned during a single appraisal procedure by a Verifier using 211 Evidence generated by an Attester. The vector is included within 212 Attestation Results. 214 2. AR Augmented Evidence and Actions 216 An Attester creates AR Augmented Evidence by appending Attestation 217 Results with supplemental Evidence. When a Relying Party receives AR 218 Augmented Evidence, it will receive them as part of a protocol from 219 an Attesting endpoint which expects some result from this 220 communication. Upon receipt, the Relying Party will apply an 221 Appraisal Policy for Attestation Results. This policy will consider 222 both the Attestation Results as well as additional information about 223 the Attester within the AR Agumented Evidence the when determining 224 what action to take. 226 2.1. Attestation Results for Secure Interactions 228 When the action is a communication establishment attempt with an 229 Attester, there is only a limited set of actions which a Relying 230 Party might take. These actions include: 232 * Allow or deny information exchange with the Attester (i.e., 233 connectivity). When there is a deny, reasons should be returned 234 to the Attester. 236 * Connect the Attester to a specific context within a Relying Party. 238 * Apply policies on the connection to or from the Attester (e.g., 239 rate limits). 241 There are three categories of information which must be conveyed to 242 the Relying Party (which also is integrated with a Verifier) before 243 it determines which of these actions to take. 245 1. Non-repudiable Identity Evidence - Evidence which undoubtably 246 identifies one or more entities involved with a connection. 248 2. Trustworthiness Claims - Specifics a Verifier asserts with 249 regards to its trustworthiness findings about an Attester. 251 3. Claim Freshness - Establishes the time of last update (or 252 refresh) of Trustworthiness Claims. 254 The following sections detail requirements for these three 255 categories. 257 2.2. Non-repudiable Identity 259 Identity Evidence must be conveyed during the establishment of any 260 trust-based relationship. Specific use cases will define the minimum 261 types of identities required by a particular Relying Party as it 262 evaluates AR-Augmented Evidence. At a bare minimum, a Relying Party 263 MUST start with the ability to verify the identity of a Verifier it 264 chooses to trust. Attester identities may then be acquired through 265 signed communications with the Verifier identity and/or the pre- 266 provisioning Attester public keys in the Attester. 268 During the Remote Attestation process, the Verifier's identity will 269 be established with a Relying Party via a Verifier signature across 270 recent Attestation Results. This Verifier identity could only have 271 come from a key pair maintained by a trusted developer or operator of 272 the Verifier. 274 Additionally, each set of AR Augmented Evidence must be provably and 275 non-reputably bound to the identity of the original Attesting 276 Environment which was evaluated by the Verifier. This will be 277 accomplished via two items. First the Verifier signed Attestation 278 Results MUST include sufficient Identity Evidence to ensure that this 279 Attesting Environment signature refers to the same Attesting 280 Environment appraised by the Verifier. Second, an Attesting 281 Environment signature which includes the Verifier signature of the 282 Attestation Results MUST also be included. 284 In a subset of use cases, these two pieces of Identity Evidence may 285 be sufficient for a Relying Party to successfully meet the criteria 286 for its Appraisal Policy for Attestation Results. If the use case is 287 a connection request, a Relying Party may simply then establish a 288 transport session with an Attester after successfully appraising 289 verified by a Verifier. However an Appraisal Policy for Attestation 290 Results will often be more nuanced, and the Relying Party may need 291 additional information. Some Identity Evidence related policy 292 questions which the Relying Party may consider include: 294 * Does the Relying Party only trust this Verifier to make 295 Trustworthiness Claims on behalf a specific type of hardware 296 rooted Attesting Environment? Might a mix of Verifiers be 297 necessary to cover all mandatory Trustworthiness Claims? 299 * Does the Relying Party only accept connections from a verified- 300 authentic software build from a specific software developer? 302 * Does the Relying Party only accept connections from specific 303 preconfigured list of Attesters? 305 For any of these more nuanced appraisals, additional Identity 306 Evidence or other policy related information must be conveyed or pre- 307 provisioned during the formation of a trust context between the 308 Relying Party, the Attester, the Attester's Attesting Environment, 309 and the Verifier. 311 2.2.1. Attester and Attesting Environment 313 Per [I-D.ietf-rats-architecture] Figure 2, an Attester and a 314 corresponding Attesting Environment might not share common code or 315 even hardware boundaries. Consequently, an Attester implementation 316 needs to ensure that any Evidence which originates from outside the 317 Attesting Environment MUST have been collected and delivered securely 318 before any Attesting Environment signing may occur. After the 319 Verifier performs its appraisal, it will include sufficient 320 information in Attestation Results to enable a Relying Party to have 321 confidence that the Attester's trustworthiness is represented via 322 Trustworthiness Claims signed by the appropriate Attesting 323 Environment. 325 This document recognizes three general categories of Attesters. 327 1. HSM-based: A Hardware Security Module (HSM) based cryptoprocessor 328 which continually hashes security measurements in a way which 329 prevents an Attester from lying about measurements which have 330 been extended into the Attesting Environment (e.g., TPM2.0.) 332 2. Process-based: An individual process which has its runtime memory 333 encrypted by an Attesting Environment in a way that no other 334 processes can read and decrypt that memory (e.g., [SGX] or 335 [I-D.tschofenig-rats-psa-token].) 337 3. VM-based: An entire Guest VM (or a set of containers within a 338 host) have been encrypted as a walled-garden unit by an Attesting 339 Environment. The result is that the host operating system cannot 340 read and decrypt what is executing within that VM (e.g., SEV or 341 TDX.) 343 Each of these categories of Attesters abover will be capable of 344 generating Evidence which is protected using private keys / 345 certificates which are not accessible outside of the corresponding 346 Attesting Environment. The owner of these secrets is the owner of 347 the identity which is bound within the Attesting Environment. 348 Effectively this means that for any Attester identity, there will 349 exist a chain of trust ultimately bound to a hardware-based root of 350 trust in the Attesting Environment. It is upon this root of trust 351 that unique, non-repudiable Attester identities may be founded. 353 There are several types of Attester identities defined in this 354 document. This list is extensible: 356 * chip-vendor: the vendor of the hardware chip used for the 357 Attesting Environment (e.g., a primary Endorsement Key from a TPM) 359 * chip-hardware: specific hardware with specific firmware from an 360 'ae-vendor' 362 * target-environment: a unique instance of a software build running 363 in an Attester (e.g., MRENCLAVE [SGX], an Instance ID 364 [I-D.tschofenig-rats-psa-token], or a hash which represents a set 365 of software loaded since boot (e.g., TPM based integrity 366 verification.)) 368 * target-developer: the organizational unit responsible for a 369 particular 'target-environment' (e.g., MRSIGNER [SGX]) 371 * ae-instance: a unique deployed instance of an Attesting 372 Environment running on 'chip-hardware' (e.g., an LDevID 373 [IEEE802.1AR]) 375 * (need to map SEV into above.) 377 Based on the category of the Attesting Environment, different types 378 of identities might be exposed by an Attester. 380 +========================+===============+===========+===========+ 381 | Attester Identity type | Process-based | VM-based | HSM-based | 382 +========================+===============+===========+===========+ 383 | chip-vendor | Mandatory | Mandatory | Mandatory | 384 +------------------------+---------------+-----------+-----------+ 385 | chip-hardware | Mandatory | Mandatory | Mandatory | 386 +------------------------+---------------+-----------+-----------+ 387 | target-environment | Mandatory | Mandatory | Optional | 388 +------------------------+---------------+-----------+-----------+ 389 | target-developer | Mandatory | Optional | Optional | 390 +------------------------+---------------+-----------+-----------+ 391 | ae-instance | Optional | Optional | Optional | 392 +------------------------+---------------+-----------+-----------+ 394 Table 1 396 It is expected that drafts subsequent to this specification will 397 provide the definitions and value domains for specific identities, 398 each of which falling within the Attester identity types listed 399 above. In some cases the actual unique identities might encoded as 400 complex structures. An example complex structure might be a 'target- 401 environment' encoded as a Software Bill of Materials (SBOM). 403 With the identity definitions and value domains, a Relying Party will 404 have sufficient information to ensure that the Attester identities 405 and Trustworthiness Claims asserted are actually capable of being 406 supported by the underlying type of Attesting Environment. 407 Consequently, the Relying Party SHOULD require Identity Evidence 408 which indicates of the type of Attesting Environment when it 409 considers its Appraisal Policy for Attestation Results. 411 For more see Appendix A. 413 2.2.2. Verifier 415 For the Verifier identity, it is critical for a Relying Party to 416 review the certificate and chain of trust for that Verifier. 417 Additionally, the Relying Party must have confidence that the 418 Trustworthiness Claims being relied upon from the Verifier considered 419 the chain of trust for the Attesting Environment . 421 2.2.3. Communicating Identity 423 Any of the above identities used by the Appraisal Policy for 424 Attestation Results needed to be pre-established by the Relying Party 425 before, or provided during, the exchange of Attestation Results. 426 When provided during this exchange, the identity may be communicated 427 either implicitly or explicitly. 429 An example of explicit communication would be to include the 430 following Identity Evidence directly within the Attestation Results: 431 a unique identifier for an Attesting Environment, the name of a key 432 which can be provably associated with that unique identifier, and the 433 set of Attestation Results which are signed using that key. As these 434 Attestation Results are signed by the Verifier, it is the Verifier 435 which is explicitly asserting the credentials it believes are 436 trustworthy. 438 An example of implicit communication would be to include Identity 439 Evidence in the form of a signature which has been placed over the 440 Attestation Results asserted by a Verifier. It would be then up to 441 the Relying Party's Appraisal Policy for Attestation Results to 442 extract this signature and confirm that it only could have been 443 generated by an Attesting Environment having access to a specific 444 private key. This implicit identity communication is only viable if 445 the Attesting Environment's public key is already known by the 446 Relying Party. 448 One final step in communicating identity is proving the freshness of 449 the Attestation Results to the degree needed by the Relying Party. A 450 typical way to accomplish this is to include an element of freshness 451 be embedded within a signed portion of the Attestation Results. This 452 element of freshness reduces the identity spoofing risks from a 453 replay attack. For more on this, see Section 2.4. 455 2.3. Trustworthiness Claims 457 2.3.1. Specific Claims 459 Trust is not absolute. Trust is a belief in some aspect of an 460 Attester, and that particular aspect is something upon which a 461 Relying Party depends. Consequently, a Verifier must be able to 462 assert different aspects of Attester trustworthiness. 464 Specific Claims of Verifier appraised trustworthiness have been 465 defined in this section. These are known as Trustworthiness Claims. 466 These Trustworthiness Claims may be either affirming (positive) or 467 detracting (negative). It is these Trustworthiness Claims which are 468 asserted within the Attestation Results produced by a Verifier. It 469 is up to the Verifier to publish the types of evaluations it performs 470 when determining how Trustworthiness Claims are derived for a type of 471 Attester. This is one of the ways a Verifier can establish its 472 trustworthiness to a Relying Party. But it is out of the scope of 473 this document for the Verifier to provide proof or specific logic on 474 how an particular Trustworthiness Claim which has been asserted was 475 derived. 477 Following are the set of Trustworthiness Claims defined within this 478 document: 480 +========================+=============================+============+ 481 | Trustworthiness Claim | Definition | +/- | 482 +========================+=============================+============+ 483 | ae-instance-recognized | A Verifier has verified an | affirming | 484 | | Attesting Environment's | | 485 | | unique identity based on | | 486 | | some hardware based | | 487 | | private key signing | | 488 +------------------------+-----------------------------+------------+ 489 | ae-instance-unknown | A Verifier has attempted | detracting | 490 | | and failed to verify an | | 491 | | Attesting Environment's | | 492 | | unique hardware protected | | 493 | | identity | | 494 +------------------------+-----------------------------+------------+ 495 | config-insecure | A Verifier has appraised | detracting | 496 | | an Attester's | | 497 | | configuration, and has | | 498 | | found security issues | | 499 | | which should be addressed | | 500 +------------------------+-----------------------------+------------+ 501 | config-secure | A Verifier has appraised | affirming | 502 | | an Attester's | | 503 | | configuration, and has | | 504 | | found no security issues | | 505 +------------------------+-----------------------------+------------+ 506 | executables-fail | A Verifier has appraised | detracting | 507 | | that an Attester has | | 508 | | installed into runtime | | 509 | | memory executables, | | 510 | | scripts, or files other | | 511 | | than approved ones | | 512 +------------------------+-----------------------------+------------+ 513 | executables-verified | A Verifier has appraised | affirming | 514 | | that an Attester has | | 515 | | installed into runtime | | 516 | | memory only a genuine set | | 517 | | of approved executables, | | 518 | | scripts, and files during | | 519 | | and after boot | | 520 +------------------------+-----------------------------+------------+ 521 | file-system-anomaly | A Verifier has found a | detracting | 522 | | passively stored file on | | 523 | | an Attester which should | | 524 | | not be present | | 525 +------------------------+-----------------------------+------------+ 526 | hw-authentic | A Verifier has appraised | affirming | 527 | | an Attester as having | | 528 | | authentic hardware and | | 529 | | firmware | | 530 +------------------------+-----------------------------+------------+ 531 | hw-verification-fail | A Verifier has appraised | detracting | 532 | | that an Attester has | | 533 | | failed its hardware or | | 534 | | firmware verification | | 535 +------------------------+-----------------------------+------------+ 536 | runtime-confidential | A Verifier has appraised | affirming | 537 | | that an Attester's | | 538 | | executing target | | 539 | | environment is opaque to | | 540 | | the operating system, any | | 541 | | virtual machine manager, | | 542 | | and any applications | | 543 | | outside the target | | 544 | | environment. This is a | | 545 | | more secure superset of | | 546 | | 'target-isolation'. See | | 547 | | O.RUNTIME_CONFIDENTIALITY | | 548 | | from [GP-TEE-PP] | | 549 +------------------------+-----------------------------+------------+ 550 | secure-storage | A Verifier has appraised | affirming | 551 | | that an Attester has a | | 552 | | Trusted Execution | | 553 | | Environment which encrypts | | 554 | | persistent storage using | | 555 | | keys unavailable outside | | 556 | | protected hardware. | | 557 | | Protections must meet the | | 558 | | capabilities of [OMTP-ATE] | | 559 | | Section 5, but need not be | | 560 | | hardware tamper resistant. | | 561 +------------------------+-----------------------------+------------+ 562 | source-data-integrity | A Verifier has appraised | affirming | 563 | | that the Attester is | | 564 | | operating upon data inputs | | 565 | | from an external Attester | | 566 | | having a Trustworthiness | | 567 | | Vector with no less than | | 568 | | the current Vector. | | 569 +------------------------+-----------------------------+------------+ 570 | target-isolation | A Verifier has appraised | affirming | 571 | | that an Attester has both | | 572 | | execution and storage | | 573 | | space which is | | 574 | | inaccessible from any | | 575 | | other parallel application | | 576 | | or Guest VM running on the | | 577 | | Attester's physical | | 578 | | device. Note that a host | | 579 | | operator may still have | | 580 | | target environment | | 581 | | visibility however. See | | 582 | | O.TA_ISOLATION from | | 583 | | [GP-TEE-PP] | | 584 +------------------------+-----------------------------+------------+ 586 Table 2 588 Each type of Attesting Environment MUST be able to support one or 589 more of the set of affirming Trustworthiness Claims listed above. 590 Additional Trustworthiness Claims may be defined in subsequent 591 documents, but the goal is to minimize these Trustworthiness Claims 592 to just Verifier appraisals which are directly actionable by the 593 Relying Party. 595 2.3.2. Trustworthiness Vector 597 Multiple Trustworthiness Claims may be asserted about an Attesting 598 Environment at single point in time. The set of Trustworthiness 599 Claims inserted into an instance of Attestation Results by a Verifier 600 is known as a Trustworthiness Vector. The order of Claims in the 601 vector is NOT meaningful. A Trustworthiness Vector with no 602 Trustworthiness Claims (i.e., a null Trustworthiness Vector) is a 603 valid construct. In this case, the Verifier is making no affirming 604 or detracting Trustworthiness Claims but is confirming that a 605 appraisal has been made. 607 2.3.3. Trustworthiness Vector for a type of Attesting Environment 609 Some Trustworthiness Claims are implicit based on the underlying type 610 of Attesting Environment. For example, a validated MRSIGNER identity 611 can be present where the underlying [SGX] hardware is 'hw-authentic'. 612 Where such implicit Trustworthiness Claims exist, they do not have to 613 be explicitly included in the Trustworthiness Vector. However these 614 implicit Trustworthiness Claims SHOULD be considered as being present 615 by the Relying Party. Another way of saying this is if a 616 Trustworthiness Claim is automatically supported as a result of 617 coming from a specific type of TEE, that claim need not be 618 redundantly articulated. Such implicit Trustworthiness Claims can be 619 seen in the tables within Appendix A.2 and Appendix A.3. 621 Additionally, there are some Trustworthiness Claims which cannot be 622 adequately supported by an Attesting Environment. For example, it 623 would be difficult for an Attester that includes only a TPM (and no 624 other TEE) from ever having a Verifier appraise support for 'runtime- 625 confidential'. As such, a Relying Party would be acting properly if 626 it rejects any non-supportable Trustworthiness Claims asserted from a 627 Verifier. 629 As a result, the need for the ability to carry a specific 630 Trustworthiness Claim will vary by the type of Attesting Environment. 631 Example mappings can be seen in Appendix A. 633 2.4. Freshness 635 A Relying Party will care about the recentness of the Attestation 636 Results, and the specific Trustworthiness Claims which are embedded. 637 All freshness mechanisms of [I-D.ietf-rats-architecture], Section 10 638 are supportable by this specification. 640 Additionally, a Relying Party may track when a Verifier expires its 641 confidence for the Trustworthiness Claims or the Trustworthiness 642 Vector as a whole. Mechanisms for such expiry are not defined within 643 this document. 645 There is a subset of secure interactions where the freshness of 646 Trustworthiness Claims may need to be revisited asynchronously. This 647 subset is when trustworthiness depends on the continuous availability 648 of a transport session between the Attester and Relying Party. With 649 such connectivity dependent Attestation Results, if there is a reboot 650 which resets transport connectivity, all established Trustworthiness 651 Claims should be cleared. Subsequent connection re-establishment 652 will allow fresh new Trustworthiness Claims to be delivered. 654 3. Secure Interactions Model 656 The establishment and maintenance of a connection between an Attester 657 and a Relying Party will follow the Passport Model from Section 5.1 658 of [I-D.ietf-rats-architecture]. Figure 1 describes this flow of 659 information using the time definitions described in 660 [I-D.ietf-rats-architecture]. Corresponding messages are passed 661 within an authentication framework, such the EAP protocol [RFC5247] 662 over TLS [RFC8446]. 664 .----------------. 665 | Attester | 666 | .-------------.| 667 | | Attesting || .----------. .---------------. 668 | | Environment || | Verifier | | Relying Party | 669 | '-------------'| | A | | / Verifier B | 670 '----------------' '----------' '---------------' 671 time(VG) | | 672 |<------Verifer PoF--------time(NS) | 673 | | | 674 time(EG)(1)------Evidence------------>| | 675 | time(RG) | 676 |<------Attestation Results-(2) | 677 ~ ~ ~ 678 time(VG')? | | 679 ~ ~ ~ 680 |<------Relying Party PoF-----------------(3)time(NS') 681 | | | 682 time(EG')(4)------AR-augmented Evidence----------------->| 683 | | time(RG',RA')(5) 684 (6) 685 ~ 686 time(RX') 688 Figure 1: Secure Interactions Model 690 Figure 1 assumes that some form of time interval tracking is possible 691 between the Verifer PoF and Relying Party PoF. However, there is a 692 simplified case that does not require a Relying Party's PoF. In that 693 second variant, the Relying Party trusts that the Attester cannot be 694 meaningfully changed from the outside during that interval. Based on 695 that assumption, the Relying Party PoF can be safely omitted. In 696 essence, the AR-augmented Evidence is replaced by the stand-alone 697 Attestation Results. 699 In the first variant illustrated in Figure 1, a Verifier B is often 700 implemented as a code module within the Relying Party. In these 701 cases, the role Relying Party and the role Verifier are collapsed in 702 one entity. As a result, the entity can appraise both the 703 Attestation Result parts as well as the Evidence parts of AR- 704 augmented Evidence to determine whether an Attester qualifies for 705 connection to the Relying Party's resources. Appraisal policies 706 define the conditions and prerequisites for when an Attester 707 qualifies for connection. In essence, an Attester has to be able to 708 provide all of the mandatory affirming Trustworthiness Claims needed 709 by a Relying Party's Appraisal Policy for Attestation Results, and 710 none of the disqualifying detracting Trustworthiness Claims. 712 More details on each interaction step are as follows. The numbers 713 used in this sequence match to the numbered steps in Figure 1: 715 1. An Attester sends Evidence which is provably fresh to Verifier A 716 at time(EG). Freshness from the perspective of Verifier A MAY be 717 established with Verifier PoF such as a nonce. 719 2. Verifier A appraises (1), then sends the following items back to 720 that Attester within Attestation Results: 722 1. the verified identity of the Attesting Environment, 724 2. the Verifier A appraised Trustworthiness Vector of an 725 Attester, 727 3. a freshness proof associated with the Attestation Results, 729 4. a Verifier signature across (2.1) though (2.3). 731 3. At time(EG') a Relying Party PoF (such as a nonce) known to the 732 Relying Party is sent to the Attester. 734 4. The Attester generates and sends AR-augmented Evidence to the 735 Relying Party/Verifier B. This AR-augmented Evidence includes: 737 1. The Attestation Results from (2) 739 2. Attestation Environment signing of a hash of the Attestation 740 Results plus the proof-of-freshness from (3). This allows 741 the delta of time between (2.3) and (3) to be definitively 742 calculated by the Relying Party. 744 5. On receipt of (4), the Relying Party applies its Appraisal Policy 745 for Attestation Results. At minimum, this appraisal policy 746 process must include the following: 748 1. Verify that (4.2) includes the nonce from (3). 750 2. Use a local certificate to validate the signature (4.1). 752 3. Verify that the hash from (4.2) matches (4.1) 754 4. Use the identity of (2.1) to validate the signature of (4.2). 756 5. Failure of any steps (5.1) through (5.4) means the link does 757 not meet minimum validation criteria, therefore appraise the 758 link as having a null Verifier B Trustworthiness Vector. 759 Jump to step (6.1). 761 6. When there is large or uncertain time gap between time(EG) 762 and time(EG'), the link should be assigned a null Verifier B 763 Trustworthiness Vector. Jump to step (6.1). 765 7. Assemble the Verifier B Trustworthiness Vector 767 1. Copy Verifier A Trustworthiness Vector to Verifier B 768 Trustworthiness Vector 770 2. Add implicit Trustworthiness Claims inherent to the type 771 of TEE. 773 3. Prune any unbelievable Trustworthiness Claims 775 4. Prune any Trustworthiness Claims the Relying Party 776 doesn't accept from this Verifier. 778 6. The Relying Party takes action based on Verifier B's appraised 779 Trustworthiness Vector: 781 1. Prune any Trustworthiness Claims not used in the Appraisal 782 Policy for Attestion Results. 784 2. Allow the information exchange from the Attester into a 785 Relying Party context where the Verifier B appraised 786 Trustworthiness Vector includes all the mandatory affirming 787 Trustworthiness Claims, and none of the disqualifying 788 detracting Trustworthiness Claims. 790 3. Disallow any information exchange into a Relying Party 791 context for which that Verifier B appraised Trustworthiness 792 Vector is not qualified. 794 As link layer protocols re-authenticate, steps (1) to (2) and steps 795 (3) to (6) will independently refresh. This allows the 796 Trustworthiness of Attester to be continuously re-appraised. There 797 are only specific triggers which will refresh Evidence generation 798 (1), Attestation Result generation (2), and in consequence AR- 799 augmented Evidence generation (4): 801 * life-cycle events, e.g. a change to an Authentication Secret of 802 the Attester or an update of a software component 804 * uptime-cycle events, e.g. a hard reset of a composite device or a 805 re-initialization of a TEE. 807 * authentication-cycle events, e.g. a link-layer interface resets or 808 new TLS session is spawned. 810 Additionally, it is common that each device on either side of a 811 connection will requires fresh remote attestation of its 812 corresponding peer. This process is known as mutual-attestation. To 813 support mutual-attestation, the process listed above may be run 814 independently on each side of the connection. 816 4. Privacy Considerations 818 Privacy Considerations Text 820 5. Security Considerations 822 Security Considerations Text 824 6. IANA Considerations 826 See Body. 828 7. References 830 7.1. Normative References 832 [GP-TEE-PP] 833 "Global Platform TEE Protection Profile v1.3", September 834 2020, . 837 [I-D.ietf-rats-architecture] 838 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 839 W. Pan, "Remote Attestation Procedures Architecture", Work 840 in Progress, Internet-Draft, draft-ietf-rats-architecture- 841 12, 23 April 2021, . 844 [OMTP-ATE] "Open Mobile Terminal Platform - Advanced Trusted 845 Environment", May 2009, . 849 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 850 Requirement Levels", BCP 14, RFC 2119, 851 DOI 10.17487/RFC2119, March 1997, 852 . 854 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 855 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 856 May 2017, . 858 7.2. Informative References 860 [I-D.tschofenig-rats-psa-token] 861 Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T. 862 Fossati, "Arm's Platform Security Architecture (PSA) 863 Attestation Token", Work in Progress, Internet-Draft, 864 draft-tschofenig-rats-psa-token-08, 24 March 2021, 865 . 868 [IEEE802.1AR] 869 "802.1AR: Secure Device Identity", 2 August 2018, 870 . 872 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 873 Authentication Protocol (EAP) Key Management Framework", 874 RFC 5247, DOI 10.17487/RFC5247, August 2008, 875 . 877 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 878 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 879 . 881 [SGX] "Supporting Third Party Attestation for Intel SGX with 882 Intel Data Center Attestation Primitives", 2017, . 887 [TPM-ID] "TPM Keys for Platform Identity for TPM 1.2", August 2015, 888 . 891 [US-Executive-Order] 892 "Executive Order on Improving the Nation's Cybersecurity", 893 12 May 2021, . 897 Appendix A. Supportable Trustworthiness Claims 899 The following is a table which shows what Claims are supportable by 900 different Attesting Environment types. Note that claims MAY BE 901 implicit to an Attesting Environment type, and therefore do not have 902 to be included in the Trustworthiness Vector to be considered as set 903 by the Relying Party. 905 A.1. Supportable Trustworthiness Claims for HSM-based CC 907 Following are Trustworthiness Claims which MAY be set for a HSM-based 908 Confidential Computing Attester. (Such as a TPM.) 909 +========================+=======================================+ 910 | Trustworthiness Claim | TPM | 911 +========================+=======================================+ 912 | ae-instance-recognized | Optional | 913 +------------------------+---------------------------------------+ 914 | ae-instance-unknown | Optional | 915 +------------------------+---------------------------------------+ 916 | config-insecure | Optional | 917 +------------------------+---------------------------------------+ 918 | config-secure | Verifier evaluation of Attester | 919 | | reveals no configuration lines which | 920 | | expose the Attester to known security | 921 | | vulnerabilities. | 922 +------------------------+---------------------------------------+ 923 | executables-refuted | If PCR checks fail for the static | 924 | | operating system, and for any tracked | 925 | | files subsequently loaded | 926 +------------------------+---------------------------------------+ 927 | executables-verified | If PCRs check for the static | 928 | | operating system, and for any tracked | 929 | | files subsequently loaded | 930 +------------------------+---------------------------------------+ 931 | file-system-anomaly | Verifier evaluation of Attester | 932 | | reveals an unexpected file. | 933 +------------------------+---------------------------------------+ 934 | hw-authentic | If PCR check ok from BIOS checks, | 935 | | through Master Boot Record | 936 | | configuration | 937 +------------------------+---------------------------------------+ 938 | hw-verification-fail | If PCR don't check ok | 939 +------------------------+---------------------------------------+ 940 | runtime-confidential | TPMs do not provide a sufficient | 941 | | technology base for this claim. | 942 +------------------------+---------------------------------------+ 943 | secure-storage | Minimal secure storage space exists | 944 | | and is writeable by external | 945 | | applications. This space would | 946 | | typically just be used to store keys. | 947 +------------------------+---------------------------------------+ 948 | source-data-integrity | Optional | 949 +------------------------+---------------------------------------+ 950 | target-isolation | This can be set only if no other | 951 | | applications are running on the | 952 | | Attester | 953 +------------------------+---------------------------------------+ 955 Table 3 957 Setting the Trustworthiness Claims may follow the following logic at 958 the Verifier A within (2) of Figure 1: 960 Start: Evidence received starts the generation of a new 961 Trustworthiness Vector. (e.g., TPM Quote Received, log received, 962 or appraisal timer expired) 964 Step 0: set Trustworthiness Vector = Null 966 Step 1: Is there sufficient fresh signed evidence to appraise? 967 (yes) - No Action 968 (no) - Goto Step 6 970 Step 2: Appraise Hardware Integrity PCRs 971 (if hw-verification-fail) - push onto vector, go to Step 6 972 else (if hw-authentic) - push onto vector 973 (if not evaluated, or insufficient data to conclude: take no action) 975 Step 3: Appraise Attesting Environment identity 976 (if hw-instance-recognized) - push onto vector 977 else (if hw-instance-unknown) - push onto vector 978 (if not evaluated, or insufficient data to conclude: take no action) 980 Step 4: Appraise executable loaded and filesystem integrity 981 (if executables-verified) - push onto vector 982 else (if executables-refuted) - push onto vector, go to Step 6 983 (if file-system-anomaly) - push onto vector, go to Step 6 984 (if not evaluated, or insufficient data to conclude: take no action) 986 Step 5: Appraise all remaining Trustworthiness Claims and set as 987 appropriate. 989 Step 6: Assemble Attestation Results, and push to Attester 991 End 993 A.2. Supportable Trustworthiness Claims for process-based CC 995 Following are Trustworthiness Claims which MAY be set for a process- 996 based Confidential Computing based Attester. (Such as a SGX Enclaves 997 and TrustZone.) 998 +========================+==============================+ 999 | Trustworthiness Claim | Process-based | 1000 +========================+==============================+ 1001 | ae-instance-recognized | Optional | 1002 +------------------------+------------------------------+ 1003 | ae-instance-unknown | Optional | 1004 +------------------------+------------------------------+ 1005 | config-insecure | Optional | 1006 +------------------------+------------------------------+ 1007 | config-secure | Optional | 1008 +------------------------+------------------------------+ 1009 | executables-refuted | Optional | 1010 +------------------------+------------------------------+ 1011 | executables-verified | Optional | 1012 +------------------------+------------------------------+ 1013 | file-system-anomaly | n/a | 1014 +------------------------+------------------------------+ 1015 | hw-authentic | Implicit in signature | 1016 +------------------------+------------------------------+ 1017 | hw-verification-fail | Implicit if signature not ok | 1018 +------------------------+------------------------------+ 1019 | runtime-confidential | Implicit in signature | 1020 +------------------------+------------------------------+ 1021 | target-isolation | Implicit in signature | 1022 +------------------------+------------------------------+ 1023 | secure-storage | Implicit in signature | 1024 +------------------------+------------------------------+ 1025 | source-data-integrity | Optional | 1026 +------------------------+------------------------------+ 1028 Table 4 1030 A.3. Supportable Trustworthiness Claims for VM-based CC 1032 Following are Trustworthiness Claims which MAY be set for a VM-based 1033 Confidential Computing based Attester. (Such as SEV, TDX, ACCA, SEV- 1034 SNP.) 1035 +========================+=======================+ 1036 | Trustworthiness Claim | Process-based | 1037 +========================+=======================+ 1038 | ae-instance-recognized | Optional | 1039 +------------------------+-----------------------+ 1040 | ae-instance-unknown | Optional | 1041 +------------------------+-----------------------+ 1042 | config-insecure | Optional | 1043 +------------------------+-----------------------+ 1044 | config-secure | Optional | 1045 +------------------------+-----------------------+ 1046 | executables-refuted | Optional | 1047 +------------------------+-----------------------+ 1048 | executables-verified | Optional | 1049 +------------------------+-----------------------+ 1050 | file-system-anomaly | Optional | 1051 +------------------------+-----------------------+ 1052 | hw-authentic | Chip dependent | 1053 +------------------------+-----------------------+ 1054 | hw-verification-fail | Chip dependent | 1055 +------------------------+-----------------------+ 1056 | runtime-confidential | Implicit | 1057 +------------------------+-----------------------+ 1058 | target-isolation | Implicit in signature | 1059 +------------------------+-----------------------+ 1060 | secure-storage | Chip dependent | 1061 +------------------------+-----------------------+ 1062 | source-data-integrity | Optional | 1063 +------------------------+-----------------------+ 1065 Table 5 1067 Appendix B. Some issues being worked 1069 It is possible for a cluster/hierarchy of Verifiers to have aggregate 1070 AR which are perhaps signed/endorsed by a lead Verifier. What should 1071 be the Proof-of-Freshness or Verifier associated with any of the 1072 aggregate set of Trustworthiness Claims? 1074 There will need to be a subsequent document which documents how these 1075 objects which will be translated into a protocol on a wire (e.g. EAP 1076 on TLS). Some breakpoint between what is in this draft, and what is 1077 in specific drafts for wire encoding will need to be determined. 1078 Questions like architecting the cluster/hierarchy of Verifiers fall 1079 into this breakdown. 1081 For Trustworthiness Claims such as 'exectables-verified', there could 1082 be value in identifying a specific Appraisal Policy for Attestation 1083 Results applied. One way this could be done would be a URI which 1084 identifies this policy. As the URI also could encode the version of 1085 the software, it might also act as a mechanism to signal the Relying 1086 Party to refresh/re-evaluate its view of Verifier A. 1088 Expand the variant of Figure 1 which requires no Relying Party PoF 1089 into its own picture. 1091 Rather than duplicating claim concepts for affirming vs detracting, 1092 perhaps we could collapse them and have affirming vs detracting be 1093 part of the value. Not collapsing complicates the test matrix. 1095 Normalization of the identity claims between different types of TEE. 1096 E.g., does MRSIGNER plus extra loaded software = the sum of TrustZone 1097 Signer IDs for loaded components? 1099 Appendix C. Contributors 1101 Guy Fedorkow 1103 Email: gfedorkow@juniper.net 1105 Dave Thaler 1107 Email: dthaler@microsoft.com 1109 Authors' Addresses 1111 Eric Voit 1112 Cisco Systems 1114 Email: evoit@cisco.com 1116 Henk Birkholz 1117 Fraunhofer SIT 1118 Rheinstrasse 75 1119 64295 Darmstadt 1120 Germany 1122 Email: henk.birkholz@sit.fraunhofer.de 1124 Thomas Hardjono 1125 MIT 1126 Email: hardjono@mit.edu 1128 Thomas Fossati 1129 Arm Limited 1131 Email: Thomas.Fossati@arm.com 1133 Vincent Scarlata 1134 Intel 1136 Email: vincent.r.scarlata@intel.com