idnits 2.17.1
draft-ietf-rats-ar4si-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 (2 December 2021) is 877 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-13
** 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: 5 June 2022 Fraunhofer SIT
6 T. Hardjono
7 MIT
8 T. Fossati
9 Arm Limited
10 V. Scarlata
11 Intel
12 2 December 2021
14 Attestation Results for Secure Interactions
15 draft-ietf-rats-ar4si-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 5 June 2022.
44 Copyright Notice
46 Copyright (c) 2021 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents (https://trustee.ietf.org/
51 license-info) in effect on the date of publication of this document.
52 Please review these documents carefully, as they describe your rights
53 and restrictions with respect to this document. Code Components
54 extracted from this document must include Revised BSD License text as
55 described in Section 4.e of the Trust Legal Provisions and are
56 provided without warranty as described in the Revised BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
61 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
63 2. Attestation Results for Secure Interactions . . . . . . . . . 5
64 2.1. Information driving a Relying Party Action . . . . . . . 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. Design Principles . . . . . . . . . . . . . . . . . . 11
71 2.3.2. Enumeration Encoding . . . . . . . . . . . . . . . . 12
72 2.3.3. Assigning a Trustworthiness Claim value . . . . . . . 13
73 2.3.4. Specific Claims . . . . . . . . . . . . . . . . . . . 13
74 2.3.5. Trustworthiness Vector . . . . . . . . . . . . . . . 17
75 2.3.6. Trustworthiness Vector for a type of Attesting
76 Environment . . . . . . . . . . . . . . . . . . . . . 18
77 2.4. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 18
78 3. Secure Interactions Models . . . . . . . . . . . . . . . . . 19
79 3.1. Pure Background-Check retrieval . . . . . . . . . . . . . 19
80 3.2. Attestation Result Augmented Evidence . . . . . . . . . . 19
81 3.3. Mutual Attestation . . . . . . . . . . . . . . . . . . . 24
82 3.4. Transport Protocol Integration . . . . . . . . . . . . . 24
83 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
87 7.1. Normative References . . . . . . . . . . . . . . . . . . 24
88 7.2. Informative References . . . . . . . . . . . . . . . . . 25
89 Appendix A. Supportable Trustworthiness Claims . . . . . . . . . 26
90 A.1. Supportable Trustworthiness Claims for HSM-based CC . . . 26
91 A.2. Supportable Trustworthiness Claims for process-based
92 CC . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
93 A.3. Supportable Trustworthiness Claims for VM-based CC . . . 30
94 Appendix B. Some issues being worked . . . . . . . . . . . . . . 31
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 * What Attestation Results (AR) might a Relying Party be willing to
135 trust from a specific Verifier?
137 * What information does a Relying Party need before allowing
138 interactions or choosing policies to apply to a connection?
140 * 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 * 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 heterogeneous 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 * Allow or deny information exchange with the Attester. When there
240 is a deny, reasons should be returned to the Attester.
242 * 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 * 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. First the Verifier signed Attestation
286 Results MUST include sufficient Identity Evidence to ensure that this
287 Attesting Environment signature refers to the same Attesting
288 Environment appraised by the Verifier. Second, where the passport
289 model is used as a subsystem, an Attesting Environment signature
290 which spans the Verifier signature MUST also be included. As the
291 Verifier signature already spans the Attester Identity as well as the
292 Attestation Results, this restricts the viability of spoofing
293 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 * 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 * Does the Relying Party only accept connections from a verified-
311 authentic software build from a specific software developer?
313 * 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 * chip-vendor: the vendor of the hardware chip used for the
368 Attesting Environment (e.g., a primary Endorsement Key from a TPM)
370 * chip-hardware: specific hardware with specific firmware from an
371 'ae-vendor'
373 * 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 * target-developer: the organizational unit responsible for a
380 particular 'target-environment' (e.g., MRSIGNER [SGX])
382 * 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 Table 1
405 It is expected that drafts subsequent to this specification will
406 provide the definitions and value domains for specific identities,
407 each of which falling within the Attester identity types listed
408 above. In some cases the actual unique identities might encoded as
409 complex structures. An example complex structure might be a 'target-
410 environment' encoded as a Software Bill of Materials (SBOM).
412 With the identity definitions and value domains, a Relying Party will
413 have sufficient information to ensure that the Attester identities
414 and Trustworthiness Claims asserted are actually capable of being
415 supported by the underlying type of Attesting Environment.
416 Consequently, the Relying Party SHOULD require Identity Evidence
417 which indicates of the type of Attesting Environment when it
418 considers its Appraisal Policy for Attestation Results.
420 2.2.2. Verifier
422 For the Verifier identity, it is critical for a Relying Party to
423 review the certificate and chain of trust for that Verifier.
424 Additionally, the Relying Party must have confidence that the
425 Trustworthiness Claims being relied upon from the Verifier considered
426 the chain of trust for the Attesting Environment.
428 There are two categorizations Verifier identities defined in this
429 document.
431 * verifier build: a unique instance of a software build running as a
432 Verifier.
434 * verifier developer: the organizational unit responsible for a
435 particular 'verifier build'.
437 Within each category, communicating the identity can be accomplished
438 via a variety of objects and encodings.
440 2.2.3. Communicating Identity
442 Any of the above identities used by the Appraisal Policy for
443 Attestation Results needed to be pre-established by the Relying Party
444 before, or provided during, the exchange of Attestation Results.
445 When provided during this exchange, the identity may be communicated
446 either implicitly or explicitly.
448 An example of explicit communication would be to include the
449 following Identity Evidence directly within the Attestation Results:
450 a unique identifier for an Attesting Environment, the name of a key
451 which can be provably associated with that unique identifier, and the
452 set of Attestation Results which are signed using that key. As these
453 Attestation Results are signed by the Verifier, it is the Verifier
454 which is explicitly asserting the credentials it believes are
455 trustworthy.
457 An example of implicit communication would be to include Identity
458 Evidence in the form of a signature which has been placed over the
459 Attestation Results asserted by a Verifier. It would be then up to
460 the Relying Party's Appraisal Policy for Attestation Results to
461 extract this signature and confirm that it only could have been
462 generated by an Attesting Environment having access to a specific
463 private key. This implicit identity communication is only viable if
464 the Attesting Environment's public key is already known by the
465 Relying Party.
467 One final step in communicating identity is proving the freshness of
468 the Attestation Results to the degree needed by the Relying Party. A
469 typical way to accomplish this is to include an element of freshness
470 be embedded within a signed portion of the Attestation Results. This
471 element of freshness reduces the identity spoofing risks from a
472 replay attack. For more on this, see Section 2.4.
474 2.3. Trustworthiness Claims
475 2.3.1. Design Principles
477 Trust is not absolute. Trust is a belief in some aspect about an
478 entity (in this case an Attester), and that this aspect is something
479 which can be depended upon (in this case by a Relying Party.) Within
480 the context of Remote Attestation, believability of this aspect is
481 facilitated by a Verifier. This facilitation depends on the
482 Verifier's ability to parse detailed Evidence from an Attester and
483 then to assert conclusions about this aspect in a way interpretable
484 by a Relying Party.
486 Specific aspects for which a Verifier will assert trustworthiness are
487 defined in this section. These are known as Trustworthiness Claims.
488 These claims have been designed to enable a common understanding
489 between a broad array of Attesters, Verifiers, and Relying Parties.
490 The following set of design principles have been applied in the
491 Trustworthiness Claim definitions:
493 1. Expose a small number of Trustworthiness Claims.
495 Reason: a plethora of similar Trustworthiness Claims will result
496 in divergent choices made on which to support between different
497 Verifiers. This would place a lot of complexity in the Relying
498 Party as it would be up to the Relying Party (and its policy
499 language) to enable normalization across rich but incompatible
500 Verifier object definitions.
502 2. Each Trustworthiness Claim enumerates only the specific states
503 that could viably result in a different outcome after the Policy
504 for Attestation Results has been applied.
506 Reason: by explicitly disallowing the standardization of
507 enumerated states which cannot easily be connected to a use case,
508 we avoid forcing implementers from making incompatible guesses on
509 what these states might mean.
511 3. Verifier and RP developers need explicit definitions of each
512 state in order to accomplish the goals of (1) and (2).
514 Reason: without such guidance, the Verifier will append plenty of
515 raw supporting info. This relieves the Verifier of making the
516 hard decisions. Of course, this raw info will be mostly non-
517 interpretable and therefore non-actionable by the Relying Party.
519 4. Support standards and non-standard extensibility for (1) and (2).
521 Reason: standard types of Verifier generated Trustworthiness
522 Claims should be vetted by the full RATS working group, rather
523 than being maintained in a repository which doesn't follow the
524 RFC process. This will keep a tight lid on extensions which must
525 be considered by the Relying Party's policy language. Because
526 this process takes time, non-standard extensions will be needed
527 for implementation speed and flexibility.
529 These design principles are important to keep the number of Verifier
530 generated claims low, and to retain the complexity in the Verifier
531 rather than the Relying Party.
533 2.3.2. Enumeration Encoding
535 Per design principle (2), each Trustworthiness Claim will only expose
536 specific encoded values. To simplify the processing of these
537 enumerations by the Relying Party, the enumeration will be encoded as
538 a single signed 8 bit integer. These value assignments for this
539 integer will be in four Trustworthiness Tiers which follow these
540 guidelines:
542 Affirming: The Verifier affirms the Attester support for this aspect
543 of trustworthiness
545 * Values 1 to 31: A standards enumerated reason for affirming.
547 * Values -2 to -32: A non-standard reason for affirming.
549 Warning: The Verifier warns about this aspect of trustworthiness.
551 * Values 32 to 95: A standards enumerated reason for the warning.
553 * Values -33 to -96: A non-standard reason for the warning.
555 Contraindicated: The Verifier asserts the Attester is explicitly
556 untrustworthy in regard to this aspect.
558 * Values 96 to 127: A standards enumerated reason for the
559 contraindication.
561 * Values -97 to -128: A non-standard reason for the
562 contraindication.
564 None: The Verifier makes no assertions about this Trustworthiness
565 Claim.
567 * Value 0: Note: this should always be always treated equivalently
568 by the Relying Party as no claim being made. I.e., the RP's
569 Appraisal Policy for Attestation Results SHOULD NOT make any
570 distinction between a Trustworthiness Claim with enumeration '0',
571 and no Trustworthiness Claim being provided.
573 * Value -1: An unexpected error occurred during the Verifier's
574 appraisal processing. Note: while no claim is being made, the
575 Relying Party MAY make a distinction between a Trustworthiness
576 Claim with enumeration '-1', and no Trustworthiness Claim being
577 provided.
579 This enumerated encoding listed above will simplify the Appraisal
580 Policy for Attestation Results. Such a policies may be as simple as
581 saying that a specific Verifier has recently asserted Trustworthiness
582 Claims, all of which are Affirming.
584 2.3.3. Assigning a Trustworthiness Claim value
586 In order to simplify design, only a single encoded value is asserted
587 by a Verifier for any Trustworthiness Claim within a using the
588 following process.
590 1. If applicable, a Verifier MUST assign a standardized value from
591 the Contraindicated tier.
593 2. Else if applicable, a Verifier MUST assign a non-standardized
594 value from the Contraindicated tier.
596 3. Else if applicable, a Verifier MUST assign a standardized value
597 from the Warning tier.
599 4. Else if applicable, a Verifier MUST assign a non-standardized
600 value from the Warning tier.
602 5. Else if applicable, a Verifier MUST assign a standardized value
603 from the Affirming tier.
605 6. Else if applicable, a Verifier MUST assign a non-standardized
606 value from the Affirming tier.
608 7. Else a Verifier MAY assign a 0 or -1.
610 2.3.4. Specific Claims
612 Following are the Trustworthiness Claims and their supported
613 enumerations which may be asserted by a Verifier:
615 configuration: A Verifier has appraised an Attester's configuration,
616 and is able to make conclusions regarding the exposure of known
617 vulnerabilities
619 0: No assertion
621 1: The configuration is a known and approved config
623 2: The configuration includes or exposes no known vulnerabilities
625 32: The configuration includes or exposes known vulnerabilities
627 96: The configuration is unsupportable as it exposes unacceptable
628 security vulnerabilities
630 -1: Unexpected error
632 executables: A Verifier has appraised and evaluated relevant runtime
633 files, scripts, and/or other objects which have been loaded into
634 the Target environment's memory.
636 0: No assertion
638 1: Only a recognized genuine set of approved executables,
639 scripts, files, and/or objects have been loaded during and
640 after the boot process.
642 2: Only a recognized genuine set of approved executables have
643 been loaded during the boot process.
645 32: Only a recognized genuine set of executables, scripts, files,
646 and/or objects have been loaded. However the Verifier cannot
647 vouch for a subset of these due to known bugs or other known
648 vulnerabilities.
650 33: Runtime memory includes executables, scripts, files, and/or
651 objects which are not recognized.
653 96: Runtime memory includes executables, scripts, files, and/or
654 object which are contraindicated.
656 -1: Unexpected error
658 file-system: A Verifier has evaluated the Attester's file system.
660 0: No assertion
662 1: Only a recognized set of approved files are found.
664 32: The file system includes unrecognized executables, scripts,
665 or files.
667 96: The file system includes contraindicated executables,
668 scripts, or files
670 -1: Unexpected error
672 hardware: A Verifier has appraised any Attester hardware and
673 firmware which are able to expose fingerprints of their identity
674 and running code.
676 0: No assertion
678 1: An Attester has passed its hardware and/or firmware
679 verifications needed to demonstrate that these are genuine/
680 supported.
682 32: An Attester contains only genuine/supported hardware and/or
683 firmware, but there are known security vulnerabilities.
685 96: Attester hardware and/or firmware is recognized, but its
686 trustworthiness is contraindicated.
688 97: A Verifier does not recognize an Attester's hardware or
689 firmware, but it should be recognized.
691 -1: Unexpected error
693 instance-identity: A Verifier has appraised an Attesting
694 Environment's unique identity based upon private key signed
695 Evidence which can be correlated to a unique instantiated instance
696 of the Attester. (Note: this Trustworthiness Claim should only be
697 generated if the Verifier actually expects to recognize the unique
698 identity of the Attester.)
700 0: No assertion
702 1: The Attesting Environment is recognized, and the associated
703 instance of the Attester is not known to be compromised.
705 96: The Attesting Environment is recognized, and but its unique
706 private key indicates a device which is not trustworthy.
708 97: The Attesting Environment is not recognized; however the
709 Verifier believes it should be.
711 -1: Unexpected error
713 runtime-opaque: A Verifier has appraised the visibility of Attester
714 objects in memory from perspectives outside the Attester.
716 0: No assertion
718 1: the Attester's executing Target Environment and Attesting
719 Environments are encrypted and within Trusted Execution
720 Environment(s) opaque to the operating system, virtual machine
721 manager, and peer applications. (Note: This value corresponds
722 to the protections asserted by O.RUNTIME_CONFIDENTIALITY from
723 [GP-TEE-PP])
725 32: the Attester's executing Target Environment and Attesting
726 Environments inaccessible from any other parallel application
727 or Guest VM running on the Attester's physical device. (Note
728 that unlike "1" these environments are not encrypted in a way
729 which restricts the Attester's root operator visibility. See
730 O.TA_ISOLATION from [GP-TEE-PP].)
732 96: The Verifier has concluded that in memory objects are
733 unacceptably visible within the physical host that supports the
734 Attester.
736 -1: Unexpected error
738 sourced-data: A Verifier has evaluated of the integrity of data
739 objects from external systems used by the Attester.
741 0: No assertion
743 1: All essential Attester source data objects have been provided
744 by other Attester(s) whose most recent appraisal(s) had both no
745 Trustworthiness Claims of "0" where the current Trustworthiness
746 Claim is "Affirming", as well as no "Warning" or
747 "Contraindicated" Trustworthiness Claims.
749 32: Attester source data objects come from unattested sources, or
750 attested sources with "Warning" type Trustworthiness Claims.
752 96: Attester source data objects come from contraindicated
753 sources.
755 -1: Unexpected error
757 storage-opaque: A Verifier has appraised that an Attester is capable
758 of encrypting persistent storage. (Note: Protections must meet
759 the capabilities of [OMTP-ATE] Section 5, but need not be hardware
760 tamper resistant.)
761 0: No assertion
763 1: the Attester encrypts all secrets in persistent storage via
764 using keys which are never visible outside an HSM or the
765 Trusted Execution Environment hardware.
767 32: the Attester encrypts all persistently stored secrets, but
768 without using hardware backed keys
770 96: There are persistent secrets which are stored unencrypted in
771 an Attester.
773 -1: Unexpected error
775 It is possible for additonal Trustworthiness Claims and enumerated
776 values to be defined in subsequent documents. At the same time, the
777 standardized Trustworthiness Claim values listed above have been
778 designed so there is no overlap within a Trustworthiness Tier. As a
779 result, it is possible to imagine a future where overlapping
780 Trustworthiness Claims within a single Trustworthiness Tier may be
781 defined. Wherever possible, the Verifier SHOULD assign the best
782 fitting standardized value.
784 Where a Relying Party doesn't know how to handle a particular
785 Trustworthiness Claim, it MAY choose an appropriate action based on
786 the Trustworthiness Tier under which the enumerated value fits.
788 It is up to the Verifier to publish the types of evaluations it
789 performs when determining how Trustworthiness Claims are derived for
790 a type of any particular type of Attester. It is out of the scope of
791 this document for the Verifier to provide proof or specific logic on
792 how a particular Trustworthiness Claim which it is asserting was
793 derived.
795 2.3.5. Trustworthiness Vector
797 Multiple Trustworthiness Claims may be asserted about an Attesting
798 Environment at single point in time. The set of Trustworthiness
799 Claims inserted into an instance of Attestation Results by a Verifier
800 is known as a Trustworthiness Vector. The order of Claims in the
801 vector is NOT meaningful. A Trustworthiness Vector with no
802 Trustworthiness Claims (i.e., a null Trustworthiness Vector) is a
803 valid construct. In this case, the Verifier is making no
804 Trustworthiness Claims but is confirming that an appraisal has been
805 made.
807 2.3.6. Trustworthiness Vector for a type of Attesting Environment
809 Some Trustworthiness Claims are implicit based on the underlying type
810 of Attesting Environment. For example, a validated MRSIGNER identity
811 can be present where the underlying [SGX] hardware is 'hw-authentic'.
812 Where such implicit Trustworthiness Claims exist, they do not have to
813 be explicitly included in the Trustworthiness Vector. However, these
814 implicit Trustworthiness Claims SHOULD be considered as being present
815 by the Relying Party. Another way of saying this is if a
816 Trustworthiness Claim is automatically supported as a result of
817 coming from a specific type of TEE, that claim need not be
818 redundantly articulated. Such implicit Trustworthiness Claims can be
819 seen in the tables within Appendix A.2 and Appendix A.3.
821 Additionally, there are some Trustworthiness Claims which cannot be
822 adequately supported by an Attesting Environment. For example, it
823 would be difficult for an Attester that includes only a TPM (and no
824 other TEE) from ever having a Verifier appraise support for 'runtime-
825 opaque'. As such, a Relying Party would be acting properly if it
826 rejects any non-supportable Trustworthiness Claims asserted from a
827 Verifier.
829 As a result, the need for the ability to carry a specific
830 Trustworthiness Claim will vary by the type of Attesting Environment.
831 Example mappings can be seen in Appendix A.
833 2.4. Freshness
835 A Relying Party will care about the recentness of the Attestation
836 Results, and the specific Trustworthiness Claims which are embedded.
837 All freshness mechanisms of [I-D.ietf-rats-architecture], Section 10
838 are supportable by this specification.
840 Additionally, a Relying Party may track when a Verifier expires its
841 confidence for the Trustworthiness Claims or the Trustworthiness
842 Vector as a whole. Mechanisms for such expiry are not defined within
843 this document.
845 There is a subset of secure interactions where the freshness of
846 Trustworthiness Claims may need to be revisited asynchronously. This
847 subset is when trustworthiness depends on the continuous availability
848 of a transport session between the Attester and Relying Party. With
849 such connectivity dependent Attestation Results, if there is a reboot
850 which resets transport connectivity, all established Trustworthiness
851 Claims should be cleared. Subsequent connection re-establishment
852 will allow fresh new Trustworthiness Claims to be delivered.
854 3. Secure Interactions Models
856 There are multiple ways of providing a Trustworthiness Vector to a
857 Relying Party. This section describes two alternatives.
859 3.1. Pure Background-Check retrieval
861 It is possible to for a Relying Party to follow the Background-Check
862 Model defined in Section 5.2 of [I-D.ietf-rats-architecture]. In
863 this case, a Relying Party will receive Attestation Results
864 containing the Trustworthiness Vector directly from a Verifier.
865 These Attestation Results can then be used by the Relying Party in
866 determining the appropriate treatment for interactions with the
867 Attester.
869 While applicable in some cases, the utilization of the Background-
870 Check Model without modification has potential drawbacks in other
871 cases. These include:
873 * Verifier scale: if the Attester has many Relying Parties, a
874 Verifier appraising that Attester could be frequently be queried
875 based on the same Evidence.
877 * Information leak: Evidence which the Attester might consider
878 private can be visible to the Relying Party. Hiding that Evidence
879 could devalue any resulting appraisal.
881 * Latency: a Relying Party will need to wait for the Verifier to
882 return Attestation Results before proceeding with secure
883 interactions with the Attester.
885 An implementer should examine these potential drawbacks before
886 selecting this alternative.
888 3.2. Attestation Result Augmented Evidence
890 There is a hybrid alternative for the establishment and maintenance
891 of trustworthiness between an Attester and a Relying Party which is
892 not adversely impacted by the potential drawbacks with pure
893 background-check. In this alternative, a Verifier evaluates an
894 Attester and returns signed Attestation Results back to this original
895 Attester no less frequently than a well-known interval. This
896 interval may also be asynchronous, based on the changing of certain
897 Evidence as described in
898 [I-D.birkholz-rats-network-device-subscription].
900 When a Relying Party is to receive information about the Attester's
901 trustworthiness, the Attesting Environment assembles the minimal set
902 of Evidence which can be used to confirm or refute whether the
903 Attester remains in the state of trustworthiness represented by the
904 AR. To this Evidence, the Attesting Environment appends the
905 signature from the most recent AR as well as a Relying Party Proof-
906 of-Freshness. The Attesting Environment then signs the combination.
908 The Attester then assembles AR Augmented Evidence by taking the
909 signed combination and appending the full AR. The assembly now
910 consists of two independent but semantically bound sets of signed
911 Evidence.
913 The AR Augmented Evidence is then sent to the Relying Party. The
914 Relying Party then can appraise these semantically bound sets of
915 signed Evidence by applying an Appraisal Policy for Attestation
916 Results as described below. This policy will consider both the AR as
917 well as additional information about the Attester within the AR
918 Augmented Evidence the when determining what action to take.
920 This alternative combines the [I-D.ietf-rats-architecture] Sections
921 5.1 Passport Model and Section 5.2 Background-Check Model. Figure 1
922 describes this flow of information. The flows within this combined
923 model are mapped to [I-D.ietf-rats-architecture] in the following
924 way. "Verifier A" below corresponds to the "Verifier" Figure 5
925 within [I-D.ietf-rats-architecture]. And "Relying Party/Verifier B"
926 below corresponds to the union of the "Relying Party" and "Verifier"
927 boxes within Figure 6 of [I-D.ietf-rats-architecture]. This union is
928 possible because Verifier B can be implemented as a simple, self-
929 contained process. The resulting combined process can appraise the
930 AR-augmented Evidence to determine whether an Attester qualifies for
931 secure interactions with the Relying Party. The specific steps of
932 this process are defined later in this section.
934 .----------------.
935 | Attester |
936 | .-------------.|
937 | | Attesting || .----------. .---------------.
938 | | Environment || | Verifier | | Relying Party |
939 | '-------------'| | A | | / Verifier B |
940 '----------------' '----------' '---------------'
941 time(VG) | |
942 |<------Verifier PoF-------time(NS) |
943 | | |
944 time(EG)(1)------Evidence------------>| |
945 | time(RG) |
946 |<------Attestation Results-(2) |
947 ~ ~ ~
948 time(VG')? | |
949 ~ ~ ~
950 |<------Relying Party PoF-----------------(3)time(NS')
951 | | |
952 time(EG')(4)------AR-augmented Evidence----------------->|
953 | | time(RG',RA')(5)
954 (6)
955 ~
956 time(RX')
958 Figure 1: Secure Interactions Model
960 The interaction model depicted above includes specific time related
961 events from Appendix A of [I-D.ietf-rats-architecture]. With the
962 identification of these time related events, time duration/interval
963 tracking becomes possible. Such duration/interval tracking can
964 become important if the Relying Party cares if too much time has
965 elapsed between the Verifier PoF and Relying Party PoF. If too much
966 time has elapsed, perhaps the Attestation Results themselves are no
967 longer trustworthy.
969 Note that while time intervals will often be relevant, there is a
970 simplified case that does not require a Relying Party's PoF in step
971 (3). In this simplified case, the Relying Party trusts that the
972 Attester cannot be meaningfully changed from the outside during any
973 reportable interval. Based on that assumption, and when this is the
974 case then the step of the Relying Party PoF can be safely omitted.
976 In all cases, appraisal policies define the conditions and
977 prerequisites for when an Attester does qualify for secure
978 interactions. To qualify, an Attester has to be able to provide all
979 of the mandatory affirming Trustworthiness Claims and identities
980 needed by a Relying Party's Appraisal Policy for Attestation Results,
981 and none of the disqualifying detracting Trustworthiness Claims.
983 More details on each interaction step are as follows. The numbers
984 used in this sequence match to the numbered steps in Figure 1:
986 1. An Attester sends Evidence which is provably fresh to Verifier A
987 at time(EG). Freshness from the perspective of Verifier A MAY be
988 established with Verifier PoF such as a nonce.
990 2. Verifier A appraises (1), then sends the following items back to
991 that Attester within Attestation Results:
993 1. the verified identity of the Attesting Environment,
995 2. the Verifier A appraised Trustworthiness Vector of an
996 Attester,
998 3. a freshness proof associated with the Attestation Results,
1000 4. a Verifier signature across (2.1) though (2.3).
1002 3. At time(EG') a Relying Party PoF (such as a nonce) known to the
1003 Relying Party is sent to the Attester.
1005 4. The Attester generates and sends AR-augmented Evidence to the
1006 Relying Party/Verifier B. This AR-augmented Evidence includes:
1008 1. The Attestation Results from (2)
1010 2. Any (optionally) new incremental Evidence from the Attesting
1011 Environment
1013 3. Attestation Environment signature which spans a hash of the
1014 Attestation Results (such as the signature of (2.4)), the
1015 proof-of-freshness from (3), and (4.2). Note: this construct
1016 allows the delta of time between (2.3) and (3) to be
1017 definitively calculated by the Relying Party.
1019 5. On receipt of (4), the Relying Party applies its Appraisal Policy
1020 for Attestation Results. At minimum, this appraisal policy
1021 process must include the following:
1023 1. Verify that (4.3) includes the nonce from (3).
1025 2. Use a local certificate to validate the signature (4.1).
1027 3. Verify that the hash from (4.3) matches (4.1)
1029 4. Use the identity of (2.1) to validate the signature of (4.3).
1031 5. Failure of any steps (5.1) through (5.4) means the link does
1032 not meet minimum validation criteria, therefore appraise the
1033 link as having a null Verifier B Trustworthiness Vector.
1034 Jump to step (6.1).
1036 6. When there is large or uncertain time gap between time(EG)
1037 and time(EG'), the link should be assigned a null Verifier B
1038 Trustworthiness Vector. Jump to step (6.1).
1040 7. Assemble the Verifier B Trustworthiness Vector
1042 1. Copy Verifier A Trustworthiness Vector to Verifier B
1043 Trustworthiness Vector
1045 2. Add implicit Trustworthiness Claims inherent to the type
1046 of TEE.
1048 3. Prune any Trustworthiness Claims unsupportable by the
1049 Attesting Environment.
1051 4. Prune any Trustworthiness Claims the Relying Party
1052 doesn't accept from this Verifier.
1054 6. The Relying Party takes action based on Verifier B's appraised
1055 Trustworthiness Vector:
1057 1. Prune any Trustworthiness Claims not used in the Appraisal
1058 Policy for Attestation Results.
1060 2. Allow the information exchange from the Attester into a
1061 Relying Party context where the Verifier B appraised
1062 Trustworthiness Vector includes all the mandatory
1063 Trustworthiness Claims of value "1", and none of the
1064 disqualifying Trustworthiness Claims containing values that
1065 are not "0" or "1".
1067 3. Disallow any information exchange into a Relying Party
1068 context for which that Verifier B appraised Trustworthiness
1069 Vector is not qualified.
1071 As link layer protocols re-authenticate, steps (1) to (2) and steps
1072 (3) to (6) will independently refresh. This allows the
1073 Trustworthiness of Attester to be continuously re-appraised. There
1074 are only specific event triggers which will drive the refresh of
1075 Evidence generation (1), Attestation Result generation (2), or AR-
1076 augmented Evidence generation (4):
1078 * life-cycle events, e.g. a change to an Authentication Secret of
1079 the Attester or an update of a software component.
1081 * uptime-cycle events, e.g. a hard reset or a re-initialization of
1082 an Attester.
1084 * authentication-cycle events, e.g. a link-layer interface reset
1085 could result in a new (4).
1087 3.3. Mutual Attestation
1089 In the interaction models described above, each device on either side
1090 of a secure interaction may require remote attestation of its peer.
1091 This process is known as mutual-attestation. To support mutual-
1092 attestation, the interaction models listed above may be run
1093 independently on either side of the connection.
1095 3.4. Transport Protocol Integration
1097 Either unidirectional attestation or mutual attestation may be
1098 supported within the protocol interactions needed for the
1099 establishment of a single transport session. While this document
1100 does not mandate specific transport protocols, messages containing
1101 the Attestation Results and AR Augmented Evidence can be passed
1102 within an authentication framework such the EAP protocol [RFC5247]
1103 over TLS [RFC8446].
1105 4. Privacy Considerations
1107 Privacy Considerations Text
1109 5. Security Considerations
1111 Security Considerations Text
1113 6. IANA Considerations
1115 See Body.
1117 7. References
1119 7.1. Normative References
1121 [GP-TEE-PP]
1122 "Global Platform TEE Protection Profile v1.3", September
1123 2020, .
1126 [I-D.ietf-rats-architecture]
1127 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
1128 W. Pan, "Remote Attestation Procedures Architecture", Work
1129 in Progress, Internet-Draft, draft-ietf-rats-architecture-
1130 13, 8 November 2021, .
1133 [OMTP-ATE] "Open Mobile Terminal Platform - Advanced Trusted
1134 Environment", May 2009, .
1138 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1139 Requirement Levels", BCP 14, RFC 2119,
1140 DOI 10.17487/RFC2119, March 1997,
1141 .
1143 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1144 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1145 May 2017, .
1147 7.2. Informative References
1149 [I-D.birkholz-rats-network-device-subscription]
1150 Birkholz, H., Voit, E., and W. Pan, "Attestation Event
1151 Stream Subscription", Work in Progress, Internet-Draft,
1152 draft-birkholz-rats-network-device-subscription-03, 17
1153 August 2021, .
1156 [I-D.tschofenig-rats-psa-token]
1157 Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T.
1158 Fossati, "Arm's Platform Security Architecture (PSA)
1159 Attestation Token", Work in Progress, Internet-Draft,
1160 draft-tschofenig-rats-psa-token-08, 24 March 2021,
1161 .
1164 [IEEE802.1AR]
1165 "802.1AR: Secure Device Identity", 2 August 2018,
1166 .
1168 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
1169 Authentication Protocol (EAP) Key Management Framework",
1170 RFC 5247, DOI 10.17487/RFC5247, August 2008,
1171 .
1173 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1174 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1175 .
1177 [SEV-SNP] "AMD SEV-SNP: Stregthening VM Isolation with Integrity
1178 Protection and More", 2020,
1179 .
1183 [SGX] "Supporting Third Party Attestation for Intel SGX with
1184 Intel Data Center Attestation Primitives", 2017, .
1189 [TDX] "Intel Trust Domain Extensions", 2020, .
1193 [TPM-ID] "TPM Keys for Platform Identity for TPM 1.2", August 2015,
1194 .
1197 [US-Executive-Order]
1198 "Executive Order on Improving the Nation's Cybersecurity",
1199 12 May 2021, .
1203 Appendix A. Supportable Trustworthiness Claims
1205 The following is a table which shows what Claims are supportable by
1206 different Attesting Environment types. Note that claims MAY BE
1207 implicit to an Attesting Environment type, and therefore do not have
1208 to be included in the Trustworthiness Vector to be considered as set
1209 by the Relying Party.
1211 A.1. Supportable Trustworthiness Claims for HSM-based CC
1213 Following are Trustworthiness Claims which MAY be set for a HSM-based
1214 Confidential Computing Attester. (Such as a TPM [TPM-ID].)
1215 +===================+===========+==================================+
1216 | Trustworthiness | Required? | Appraisal Method |
1217 | Claim | | |
1218 +===================+===========+==================================+
1219 | configuration | Optional | Verifier evaluation of Attester |
1220 | | | reveals no configuration lines |
1221 | | | which expose the Attester to |
1222 | | | known security vulnerabilities. |
1223 | | | This may be done with or without |
1224 | | | the involvement of a TPM PCR. |
1225 +-------------------+-----------+----------------------------------+
1226 | executables | Yes | Checks the TPM PCRs for the |
1227 | | | static operating system, and for |
1228 | | | any tracked files subsequently |
1229 | | | loaded |
1230 +-------------------+-----------+----------------------------------+
1231 | file-system | No | Can be supported, but TPM |
1232 | | | tracking is unlikely |
1233 +-------------------+-----------+----------------------------------+
1234 | hardware | Yes | If TPM PCR check ok from BIOS |
1235 | | | checks, through Master Boot |
1236 | | | Record configuration |
1237 +-------------------+-----------+----------------------------------+
1238 | instance-identity | Optional | Check IDevID |
1239 +-------------------+-----------+----------------------------------+
1240 | runtime-opaque | n/a | TPMs are not recommended to |
1241 | | | provide a sufficient technology |
1242 | | | base for this Trustworthiness |
1243 | | | Claim. |
1244 +-------------------+-----------+----------------------------------+
1245 | sourced-data | n/a | TPMs are not recommended to |
1246 | | | provide a sufficient technology |
1247 | | | base for this Trustworthiness |
1248 | | | Claim. |
1249 +-------------------+-----------+----------------------------------+
1250 | storage-opaque | Minimal | With a TPM, secure storage space |
1251 | | | exists and is writeable by |
1252 | | | external applications. But the |
1253 | | | space is so limited that it |
1254 | | | often is used just be used to |
1255 | | | store keys. |
1256 +-------------------+-----------+----------------------------------+
1258 Table 2
1260 Setting the Trustworthiness Claims may follow the following logic at
1261 the Verifier A within (2) of Figure 1:
1263 Start: Evidence received starts the generation of a new
1264 Trustworthiness Vector. (e.g., TPM Quote Received, log received,
1265 or appraisal timer expired)
1267 Step 0: set Trustworthiness Vector = Null
1269 Step 1: Is there sufficient fresh signed evidence to appraise?
1270 (yes) - No Action
1271 (no) - Goto Step 6
1273 Step 2: Appraise Hardware Integrity PCRs
1274 if (hardware NOT "0") - push onto vector
1275 if (hardware NOT affirming or warning), go to Step 6
1277 Step 3: Appraise Attesting Environment identity
1278 if (instance-identity <> "0") - push onto vector
1280 Step 4: Appraise executable loaded and filesystem integrity
1281 if (executables NOT "0") - push onto vector
1282 if (executables NOT affirming or warning), go to Step 6
1284 Step 5: Appraise all remaining Trustworthiness Claims
1285 Independently and set as appropriate.
1287 Step 6: Assemble Attestation Results, and push to Attester
1289 End
1291 A.2. Supportable Trustworthiness Claims for process-based CC
1293 Following are Trustworthiness Claims which MAY be set for a process-
1294 based Confidential Computing based Attester. (Such as a SGX Enclaves
1295 and TrustZone.)
1296 +===================+===========+==================================+
1297 | Trustworthiness | Required? | Appraisal Method |
1298 | Claim | | |
1299 +===================+===========+==================================+
1300 | instance-identity | Optional | Internally available in TEE. |
1301 | | | But keys might not be known/ |
1302 | | | exposed to the Relying Party by |
1303 | | | the Attesting Environment. |
1304 +-------------------+-----------+----------------------------------+
1305 | configuration | Optional | If done, this is at the |
1306 | | | Application Layer. Plus each |
1307 | | | process needs it own protection |
1308 | | | mechanism as the protection is |
1309 | | | limited to the process itself. |
1310 +-------------------+-----------+----------------------------------+
1311 | executables | Optional | Internally available in TEE. |
1312 | | | But keys might not be known/ |
1313 | | | exposed to the Relying Party by |
1314 | | | the Attesting Environment. |
1315 +-------------------+-----------+----------------------------------+
1316 | file-system | Optional | Can be supported by application, |
1317 | | | but process-based CC is not a |
1318 | | | sufficient technology base for |
1319 | | | this Trustworthiness Claim. |
1320 +-------------------+-----------+----------------------------------+
1321 | hardware | Implicit | At least the TEE is protected |
1322 | | in | here. Other elements of the |
1323 | | signature | system outside of the TEE might |
1324 | | | need additional protections is |
1325 | | | used by the application process. |
1326 +-------------------+-----------+----------------------------------+
1327 | runtime-opaque | Implicit | From the TEE |
1328 | | in | |
1329 | | signature | |
1330 +-------------------+-----------+----------------------------------+
1331 | storage-opaque | Implicit | Although the application must |
1332 | | in | assert that this function is |
1333 | | signature | used by the code itself. |
1334 +-------------------+-----------+----------------------------------+
1335 | sourced-data | Optional | Will need to be supported by |
1336 | | | application code |
1337 +-------------------+-----------+----------------------------------+
1339 Table 3
1341 A.3. Supportable Trustworthiness Claims for VM-based CC
1343 Following are Trustworthiness Claims which MAY be set for a VM-based
1344 Confidential Computing based Attester. (Such as SEV, TDX, ACCA, SEV-
1345 SNP.)
1347 +===================+===========+===================================+
1348 | Trustworthiness | Required? | Appraisal Method |
1349 | Claim | | |
1350 +===================+===========+===================================+
1351 | instance-identity | Optional | Internally available in TEE. |
1352 | | | But keys might not be known/ |
1353 | | | exposed to the Relying Party by |
1354 | | | the Attesting Environment. |
1355 +-------------------+-----------+-----------------------------------+
1356 | configuration | Optional | Requires application |
1357 | | | integration. Easier than with |
1358 | | | process-based solution, as the |
1359 | | | whole protected machine can be |
1360 | | | evaluated. |
1361 +-------------------+-----------+-----------------------------------+
1362 | executables | Optional | Internally available in TEE. |
1363 | | | But keys might not be known/ |
1364 | | | exposed to the Relying Party by |
1365 | | | the Attesting Environment. |
1366 +-------------------+-----------+-----------------------------------+
1367 | file-system | Optional | Can be supported by application |
1368 +-------------------+-----------+-----------------------------------+
1369 | hardware | Chip | At least the TEE is protected |
1370 | | dependent | here. Other elements of the |
1371 | | | system outside of the TEE might |
1372 | | | need additional protections is |
1373 | | | used by the application process. |
1374 +-------------------+-----------+-----------------------------------+
1375 | runtime-opaque | Implicit | From the TEE |
1376 | | in | |
1377 | | signature | |
1378 +-------------------+-----------+-----------------------------------+
1379 | storage-opaque | Chip | Although the application must |
1380 | | dependent | assert that this function is |
1381 | | | used by the code itself. |
1382 +-------------------+-----------+-----------------------------------+
1383 | sourced-data | Optional | Will need to be supported by |
1384 | | | application code |
1385 +-------------------+-----------+-----------------------------------+
1387 Table 4
1389 Appendix B. Some issues being worked
1391 It is possible for a cluster/hierarchy of Verifiers to have aggregate
1392 AR which are perhaps signed/endorsed by a lead Verifier. What should
1393 be the Proof-of-Freshness or Verifier associated with any of the
1394 aggregate set of Trustworthiness Claims?
1396 There will need to be a subsequent document which documents how these
1397 objects which will be translated into a protocol on a wire (e.g. EAP
1398 on TLS). Some breakpoint between what is in this draft, and what is
1399 in specific drafts for wire encoding will need to be determined.
1400 Questions like architecting the cluster/hierarchy of Verifiers fall
1401 into this breakdown.
1403 For some Trustworthiness Claims, there could be value in identifying
1404 a specific Appraisal Policy for Attestation Results applied within
1405 the Attester. One way this could be done would be a URI which
1406 identifies the policy used at Verifier A, and this URI would
1407 reference a specific Trustworthiness Claim. As the URI also could
1408 encode the version of the software, it might also act as a mechanism
1409 to signal the Relying Party to refresh/re-evaluate its view of
1410 Verifier A. Do we need this type of structure to be included here?
1411 Should it be in subsequent documents?
1413 Expand the variant of Figure 1 which requires no Relying Party PoF
1414 into its own picture.
1416 In what document (if any) do we attempt normalization of the identity
1417 claims between different types of TEE. E.g., does MRSIGNER plus
1418 extra loaded software = the sum of TrustZone Signer IDs for loaded
1419 components?
1421 Appendix C. Contributors
1423 Guy Fedorkow
1425 Email: gfedorkow@juniper.net
1427 Dave Thaler
1429 Email: dthaler@microsoft.com
1431 Ned Smith
1433 Email: ned.smith@intel.com
1435 Authors' Addresses
1436 Eric Voit
1437 Cisco Systems
1439 Email: evoit@cisco.com
1441 Henk Birkholz
1442 Fraunhofer SIT
1443 Rheinstrasse 75
1444 64295 Darmstadt
1445 Germany
1447 Email: henk.birkholz@sit.fraunhofer.de
1449 Thomas Hardjono
1450 MIT
1452 Email: hardjono@mit.edu
1454 Thomas Fossati
1455 Arm Limited
1457 Email: Thomas.Fossati@arm.com
1459 Vincent Scarlata
1460 Intel
1462 Email: vincent.r.scarlata@intel.com