idnits 2.17.00 (12 Aug 2021)
/tmp/idnits14499/draft-ietf-rats-ar4si-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
-- The document date (7 March 2022) is 68 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'
** 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'
Summary: 1 error (**), 0 flaws (~~), 0 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: 8 September 2022 Fraunhofer SIT
6 T. Hardjono
7 MIT
8 T. Fossati
9 Arm Limited
10 V. Scarlata
11 Intel
12 7 March 2022
14 Attestation Results for Secure Interactions
15 draft-ietf-rats-ar4si-02
17 Abstract
19 This document defines reusable Attestation Result information
20 elements. When these elements are offered to Relying Parties as
21 Evidence, different aspects of Attester trustworthiness can be
22 evaluated. Additionally, where the Relying Party is interfacing with
23 a heterogeneous mix of Attesting Environment and Verifier types,
24 consistent policies can be applied to subsequent information exchange
25 between each Attester and the Relying Party.
27 Status of This Memo
29 This Internet-Draft is submitted in full conformance with the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF). Note that other groups may also distribute
34 working documents as Internet-Drafts. The list of current Internet-
35 Drafts is at https://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 This Internet-Draft will expire on 8 September 2022.
44 Copyright Notice
46 Copyright (c) 2022 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents (https://trustee.ietf.org/
51 license-info) in effect on the date of publication of this document.
52 Please review these documents carefully, as they describe your rights
53 and restrictions with respect to this document. Code Components
54 extracted from this document must include Revised BSD License text as
55 described in Section 4.e of the Trust Legal Provisions and are
56 provided without warranty as described in the Revised BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . 6
65 2.2. Non-repudiable Identity . . . . . . . . . . . . . . . . . 6
66 2.2.1. Attester and Attesting Environment . . . . . . . . . 7
67 2.2.2. Verifier . . . . . . . . . . . . . . . . . . . . . . 10
68 2.2.3. Communicating Identity . . . . . . . . . . . . . . . 10
69 2.3. Trustworthiness Claims . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . 14
74 2.3.5. Trustworthiness Vector . . . . . . . . . . . . . . . 18
75 2.3.6. Trustworthiness Vector for a type of Attesting
76 Environment . . . . . . . . . . . . . . . . . . . . . 19
77 2.4. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 19
78 3. Secure Interactions Models . . . . . . . . . . . . . . . . . 20
79 3.1. Background-Check . . . . . . . . . . . . . . . . . . . . 20
80 3.1.1. Verifier Retrieval . . . . . . . . . . . . . . . . . 20
81 3.1.2. Co-resident Verifier . . . . . . . . . . . . . . . . 20
82 3.2. Below Zero Trust . . . . . . . . . . . . . . . . . . . . 21
83 3.3. Mutual Attestation . . . . . . . . . . . . . . . . . . . 25
84 3.4. Transport Protocol Integration . . . . . . . . . . . . . 26
85 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26
87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
89 7.1. Normative References . . . . . . . . . . . . . . . . . . 26
90 7.2. Informative References . . . . . . . . . . . . . . . . . 27
91 Appendix A. Implementation Guidance . . . . . . . . . . . . . . 28
92 A.1. Supplementing Trustworthiness Claims . . . . . . . . . . 28
93 Appendix B. Supportable Trustworthiness Claims . . . . . . . . . 28
94 B.1. Supportable Trustworthiness Claims for HSM-based CC . . . 29
95 B.2. Supportable Trustworthiness Claims for process-based
96 CC . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
98 B.3. Supportable Trustworthiness Claims for VM-based CC . . . 33
99 Appendix C. Some issues being worked . . . . . . . . . . . . . . 34
100 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 34
101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
103 1. Introduction
105 The first paragraph of the May 2021 US Presidential Executive Order
106 on Improving the Nation's Cybersecurity [US-Executive-Order] ends
107 with the statement "the trust we place in our digital infrastructure
108 should be proportional to how trustworthy and transparent that
109 infrastructure is." Later this order explores aspects of
110 trustworthiness such as an auditable trust relationship, which it
111 defines as an "agreed-upon relationship between two or more system
112 elements that is governed by criteria for secure interaction,
113 behavior, and outcomes."
115 The Remote ATtestation procedureS (RATS) architecture
116 [I-D.ietf-rats-architecture] provides a useful context for
117 programmatically establishing and maintaining such auditable trust
118 relationships. Specifically, the architecture defines conceptual
119 messages conveyed between architectural subsystems to support
120 trustworthiness appraisal. The RATS conceptual message used to
121 convey evidence of trustworthiness is the Attestation Results. The
122 Attestation Results includes Verifier generated appraisals of an
123 Attester including such information as the identity of the Attester,
124 the security mechanisms employed on this Attester, and the Attester's
125 current state of trustworthiness.
127 Generated Attestation Results are ultimately conveyed to one or more
128 Relying Parties. Reception of an Attestation Result enables a
129 Relying Party to determine what action to take with regards to an
130 Attester. Frequently, this action will be to choose whether to allow
131 the Attester to securely interact with the Relying Party over some
132 connection between the two.
134 When determining whether to allow secure interactions with an
135 Attester, a Relying Party is challenged with a number of difficult
136 problems which it must be able to handle successfully. These
137 problems include:
139 * What Attestation Results (AR) might a Relying Party be willing to
140 trust from a specific Verifier?
142 * What information does a Relying Party need before allowing
143 interactions or choosing policies to apply to a connection?
145 * What are the operating/environmental realities of the Attesting
146 Environment where a Relying Party should only be able to associate
147 a certain confidence regarding Attestation Results out of the
148 Verifier? (In other words, different types of Trusted Execution
149 Environments (TEE) need not be treated as equivalent.)
151 * How to make direct comparisons where there is a heterogeneous mix
152 of Attesting Environments and Verifier types.
154 To address these problems, it is important that specific Attestation
155 Result information elements are framed independently of Attesting
156 Environment specific constraints. If they are not, a Relying Party
157 would be forced to adapt to the syntax and semantics of many vendor
158 specific environments. This is not a reasonable ask as there can be
159 many types of Attesters interacting with or connecting to a Relying
160 Party.
162 The business need therefore is for common Attestation Result
163 information element definitions. With these definitions, consistent
164 interaction or connectivity decisions can be made by a Relying Party
165 where there is a heterogenous mix of Attesting Environment types and
166 Verifier types.
168 This document defines information elements for Attestation Results in
169 a way which normalizes the trustworthiness assertions that can be
170 made from a diverse set of Attesters.
172 1.1. Requirements Notation
174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
176 "OPTIONAL" in this document are to be interpreted as described in
177 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
178 capitals, as shown here.
180 1.2. Terminology
182 The following terms are imported from [I-D.ietf-rats-architecture]:
183 Appraisal Policy for Attestation Results, Attester, Attesting
184 Environment, Claims, Evidence, Relying Party, Target Environment and
185 Verifier.
187 [I-D.ietf-rats-architecture] also describes topological patterns that
188 illustrate the need for interoperable conceptual messages. The two
189 patterns called "background-check model" and "passport model" are
190 imported from the RATS architecture and used in this document as a
191 reference to the architectural concepts: Background-Check Model and
192 Passport Model.
194 Newly defined terms for this document:
196 AR-augmented Evidence: a bundle of Evidence which includes at least
197 the following:
199 1. Verifier signed Attestation Results. These Attestation
200 Results must include Identity Evidence for the Attester, a
201 Trustworthiness Vector describing a Verifier's most recent
202 appraisal of an Attester, and some Verifier Proof-of-Freshness
203 (PoF).
205 2. A Relying Party PoF which is bound to the Attestation Results
206 of (1) by the Attester's Attesting Environment signature.
208 3. Sufficient information to determine the elapsed interval
209 between the Verifier PoF and Relying Party PoF.
211 Identity Evidence: Evidence which unambiguously identifies an
212 identity. Identity Evidence could take different forms, such as a
213 certificate, or a signature which can be appraised to have only
214 been generated by a specific private/public key pair.
216 Trustworthiness Claim: a specific quanta of trustworthiness which
217 can be assigned by a Verifier based on its appraisal policy.
219 Trustworthiness Tier: a categorization of the levels of
220 trustworthiness which may be assigned by a Verifier to a specific
221 Trustworthiness Claim. These enumerated categories are: Affirmed,
222 Warning, Contraindicated, and None.
224 Trustworthiness Vector: a set of zero to many Trustworthiness Claims
225 assigned during a single appraisal procedure by a Verifier using
226 Evidence generated by an Attester. The vector is included within
227 Attestation Results.
229 2. Attestation Results for Secure Interactions
231 A Verifier generates the Attestation Results used by a Relying Party.
232 When a Relying Party needs to determine whether to permit
233 communications with an Attester, these Attestation Results must
234 contain a specific set of information elements. This section defines
235 those information elements, and in some cases encodings for
236 information elements.
238 2.1. Information driving a Relying Party Action
240 When the action is a communication establishment attempt with an
241 Attester, there is only a limited set of actions which a Relying
242 Party might take. These actions include:
244 * Allow or deny information exchange with the Attester. When there
245 is a deny, reasons should be returned to the Attester.
247 * Establish a transport connection between an Attester and a
248 specific context within a Relying Party (e.g., a TEE, or Virtual
249 Routing Function (VRF).)
251 * Apply policies on this connection (e.g., rate limits).
253 There are three categories of information which must be conveyed to
254 the Relying Party (which also is integrated with a Verifier) before
255 it determines which of these actions to take.
257 1. Non-repudiable Identity Evidence - Evidence which undoubtably
258 identifies one or more entities involved with a communication.
260 2. Trustworthiness Claims - Specifics a Verifier asserts with
261 regards to its trustworthiness findings about an Attester.
263 3. Claim Freshness - Establishes the time of last update (or
264 refresh) of Trustworthiness Claims.
266 The following sections detail requirements for these three
267 categories.
269 2.2. Non-repudiable Identity
271 Identity Evidence must be conveyed during the establishment of any
272 trust-based relationship. Specific use cases will define the minimum
273 types of identities required by a particular Relying Party as it
274 evaluates Attestation Results, and perhaps additional associated
275 Evidence. At a bare minimum, a Relying Party MUST start with the
276 ability to verify the identity of a Verifier it chooses to trust.
277 Attester identities may then be acquired through signed or encrypted
278 communications with the Verifier identity and/or the pre-provisioning
279 Attester public keys in the Attester.
281 During the Remote Attestation process, the Verifier's identity must
282 be established with a Relying Party, often via a Verifier signature
283 across recent Attestation Results. This Verifier identity could only
284 have come from a key pair maintained by a trusted developer or
285 operator of the Verifier.
287 Additionally, each set of Attestation Results must be provably and
288 non-reputably bound to the identity of the original Attesting
289 Environment which was evaluated by the Verifier. This is
290 accomplished via satisfying two requirements. First the Verifier
291 signed Attestation Results MUST include sufficient Identity Evidence
292 to ensure that this Attesting Environment signature refers to the
293 same Attesting Environment appraised by the Verifier. Second, where
294 the passport model is used as a subsystem, an Attesting Environment
295 signature which spans the Verifier signature MUST also be included.
296 As the Verifier signature already spans the Attester Identity as well
297 as the Attestation Results, this restricts the viability of spoofing
298 attacks.
300 In a subset of use cases, these two pieces of Identity Evidence may
301 be sufficient for a Relying Party to successfully meet the criteria
302 for its Appraisal Policy for Attestation Results. If the use case is
303 a connection request, a Relying Party may simply then establish a
304 transport session with an Attester after a successful appraisal.
305 However an Appraisal Policy for Attestation Results will often be
306 more nuanced, and the Relying Party may need additional information.
307 Some Identity Evidence related policy questions which the Relying
308 Party may consider include:
310 * Does the Relying Party only trust this Verifier to make
311 Trustworthiness Claims on behalf a specific type of Attesting
312 Environment? Might a mix of Verifiers be necessary to cover all
313 mandatory Trustworthiness Claims?
315 * Does the Relying Party only accept connections from a verified-
316 authentic software build from a specific software developer?
318 * Does the Relying Party only accept connections from specific
319 preconfigured list of Attesters?
321 For any of these more nuanced appraisals, additional Identity
322 Evidence or other policy related information must be conveyed or pre-
323 provisioned during the formation of a trust context between the
324 Relying Party, the Attester, the Attester's Attesting Environment,
325 and the Verifier.
327 2.2.1. Attester and Attesting Environment
329 Per [I-D.ietf-rats-architecture] Figure 2, an Attester and a
330 corresponding Attesting Environment might not share common code or
331 even hardware boundaries. Consequently, an Attester implementation
332 needs to ensure that any Evidence which originates from outside the
333 Attesting Environment MUST have been collected and delivered securely
334 before any Attesting Environment signing may occur. After the
335 Verifier performs its appraisal, it will include sufficient
336 information in the Attestation Results to enable a Relying Party to
337 have confidence that the Attester's trustworthiness is represented
338 via Trustworthiness Claims signed by the appropriate Attesting
339 Environment.
341 This document recognizes three general categories of Attesters.
343 1. HSM-based: A Hardware Security Module (HSM) based cryptoprocessor
344 which hashes one or more streams of security measurements from an
345 Attester within the Attesting Environment. Maintenance of this
346 hash enables detection of an Attester which is lying about the
347 set of security measurements taken. An example of a HSM is a
348 TPM2.0 [TPM2.0].
350 2. Process-based: An individual process which has its runtime memory
351 encrypted by an Attesting Environment in a way that no other
352 processes can read and decrypt that memory (e.g., [SGX] or
353 [I-D.tschofenig-rats-psa-token].)
355 3. VM-based: An entire Guest VM (or a set of containers within a
356 host) have been encrypted as a walled-garden unit by an Attesting
357 Environment. The result is that the host operating system cannot
358 read and decrypt what is executing within that VM (e.g.,
359 [SEV-SNP] or [TDX].)
361 Each of these categories of Attesters above will be capable of
362 generating Evidence which is protected using private keys /
363 certificates which are not accessible outside of the corresponding
364 Attesting Environment. The owner of these secrets is the owner of
365 the identity which is bound within the Attesting Environment.
366 Effectively this means that for any Attester identity, there will
367 exist a chain of trust ultimately bound to a hardware-based root of
368 trust in the Attesting Environment. It is upon this root of trust
369 that unique, non-repudiable Attester identities may be founded.
371 There are several types of Attester identities defined in this
372 document. This list is extensible:
374 * chip-vendor: the vendor of the hardware chip used for the
375 Attesting Environment (e.g., a primary Endorsement Key from a TPM)
377 * chip-hardware: specific hardware with specific firmware from an
378 'chip-vendor'
380 * target-environment: a unique instance of a software build running
381 in an Attester (e.g., MRENCLAVE [SGX], an Instance ID
382 [I-D.tschofenig-rats-psa-token], an Identity Block [SEV-SNP], or a
383 hash which represents a set of software loaded since boot (e.g.,
384 TPM based integrity verification.))
386 * target-developer: the organizational unit responsible for a
387 particular 'target-environment' (e.g., MRSIGNER [SGX])
389 * instance: a unique instantiated instance of an Attesting
390 Environment running on 'chip-hardware' (e.g., an LDevID
391 [IEEE802.1AR])
393 Based on the category of the Attesting Environment, different types
394 of identities might be exposed by an Attester.
396 +========================+===============+===========+===========+
397 | Attester Identity type | Process-based | VM-based | HSM-based |
398 +========================+===============+===========+===========+
399 | chip-vendor | Mandatory | Mandatory | Mandatory |
400 +------------------------+---------------+-----------+-----------+
401 | chip-hardware | Mandatory | Mandatory | Mandatory |
402 +------------------------+---------------+-----------+-----------+
403 | target-environment | Mandatory | Mandatory | Optional |
404 +------------------------+---------------+-----------+-----------+
405 | target-developer | Mandatory | Optional | Optional |
406 +------------------------+---------------+-----------+-----------+
407 | instance | Optional | Optional | Optional |
408 +------------------------+---------------+-----------+-----------+
410 Table 1
412 It is expected that drafts subsequent to this specification will
413 provide the definitions and value domains for specific identities,
414 each of which falling within the Attester identity types listed
415 above. In some cases the actual unique identities might encoded as
416 complex structures. An example complex structure might be a 'target-
417 environment' encoded as a Software Bill of Materials (SBOM).
419 With the identity definitions and value domains, a Relying Party will
420 have sufficient information to ensure that the Attester identities
421 and Trustworthiness Claims asserted are actually capable of being
422 supported by the underlying type of Attesting Environment.
423 Consequently, the Relying Party SHOULD require Identity Evidence
424 which indicates of the type of Attesting Environment when it
425 considers its Appraisal Policy for Attestation Results.
427 2.2.2. Verifier
429 For the Verifier identity, it is critical for a Relying Party to
430 review the certificate and chain of trust for that Verifier.
431 Additionally, the Relying Party must have confidence that the
432 Trustworthiness Claims being relied upon from the Verifier considered
433 the chain of trust for the Attesting Environment.
435 There are two categorizations Verifier identities defined in this
436 document.
438 * verifier build: a unique instance of a software build running as a
439 Verifier.
441 * verifier developer: the organizational unit responsible for a
442 particular 'verifier build'.
444 Within each category, communicating the identity can be accomplished
445 via a variety of objects and encodings.
447 2.2.3. Communicating Identity
449 Any of the above identities used by the Appraisal Policy for
450 Attestation Results needed to be pre-established by the Relying Party
451 before, or provided during, the exchange of Attestation Results.
452 When provided during this exchange, the identity may be communicated
453 either implicitly or explicitly.
455 An example of explicit communication would be to include the
456 following Identity Evidence directly within the Attestation Results:
457 a unique identifier for an Attesting Environment, the name of a key
458 which can be provably associated with that unique identifier, and the
459 set of Attestation Results which are signed using that key. As these
460 Attestation Results are signed by the Verifier, it is the Verifier
461 which is explicitly asserting the credentials it believes are
462 trustworthy.
464 An example of implicit communication would be to include Identity
465 Evidence in the form of a signature which has been placed over the
466 Attestation Results asserted by a Verifier. It would be then up to
467 the Relying Party's Appraisal Policy for Attestation Results to
468 extract this signature and confirm that it only could have been
469 generated by an Attesting Environment having access to a specific
470 private key. This implicit identity communication is only viable if
471 the Attesting Environment's public key is already known by the
472 Relying Party.
474 One final step in communicating identity is proving the freshness of
475 the Attestation Results to the degree needed by the Relying Party. A
476 typical way to accomplish this is to include an element of freshness
477 be embedded within a signed portion of the Attestation Results. This
478 element of freshness reduces the identity spoofing risks from a
479 replay attack. For more on this, see Section 2.4.
481 2.3. Trustworthiness Claims
483 2.3.1. Design Principles
485 Trust is not absolute. Trust is a belief in some aspect about an
486 entity (in this case an Attester), and that this aspect is something
487 which can be depended upon (in this case by a Relying Party.) Within
488 the context of Remote Attestation, believability of this aspect is
489 facilitated by a Verifier. This facilitation depends on the
490 Verifier's ability to parse detailed Evidence from an Attester and
491 then to assert conclusions about this aspect in a way interpretable
492 by a Relying Party.
494 Specific aspects for which a Verifier will assert trustworthiness are
495 defined in this section. These are known as Trustworthiness Claims.
496 These claims have been designed to enable a common understanding
497 between a broad array of Attesters, Verifiers, and Relying Parties.
498 The following set of design principles have been applied in the
499 Trustworthiness Claim definitions:
501 1. Expose a small number of Trustworthiness Claims.
503 Reason: a plethora of similar Trustworthiness Claims will result
504 in divergent choices made on which to support between different
505 Verifiers. This would place a lot of complexity in the Relying
506 Party as it would be up to the Relying Party (and its policy
507 language) to enable normalization across rich but incompatible
508 Verifier object definitions.
510 2. Each Trustworthiness Claim enumerates only the specific states
511 that could viably result in a different outcome after the Policy
512 for Attestation Results has been applied.
514 Reason: by explicitly disallowing the standardization of
515 enumerated states which cannot easily be connected to a use case,
516 we avoid forcing implementers from making incompatible guesses on
517 what these states might mean.
519 3. Verifier and RP developers need explicit definitions of each
520 state in order to accomplish the goals of (1) and (2).
522 Reason: without such guidance, the Verifier will append plenty of
523 raw supporting info. This relieves the Verifier of making the
524 hard decisions. Of course, this raw info will be mostly non-
525 interpretable and therefore non-actionable by the Relying Party.
527 4. Support standards and non-standard extensibility for (1) and (2).
529 Reason: standard types of Verifier generated Trustworthiness
530 Claims should be vetted by the full RATS working group, rather
531 than being maintained in a repository which doesn't follow the
532 RFC process. This will keep a tight lid on extensions which must
533 be considered by the Relying Party's policy language. Because
534 this process takes time, non-standard extensions will be needed
535 for implementation speed and flexibility.
537 These design principles are important to keep the number of Verifier
538 generated claims low, and to retain the complexity in the Verifier
539 rather than the Relying Party.
541 2.3.2. Enumeration Encoding
543 Per design principle (2), each Trustworthiness Claim will only expose
544 specific encoded values. To simplify the processing of these
545 enumerations by the Relying Party, the enumeration will be encoded as
546 a single signed 8 bit integer. These value assignments for this
547 integer will be in four Trustworthiness Tiers which follow these
548 guidelines:
550 None: The Verifier makes no assertions regarding this aspect of
551 trustworthiness.
553 * Value 0: The Evidence received is insufficient to make a
554 conclusion. Note: this should always be always treated
555 equivalently by the Relying Party as no claim being made. I.e.,
556 the RP's Appraisal Policy for Attestation Results SHOULD NOT make
557 any distinction between a Trustworthiness Claim with enumeration
558 '0', and no Trustworthiness Claim being provided.
560 * Value 1: The Evidence received contains unexpected elements which
561 the Verifier is unable to parse. An example might be that the
562 wrong type of Evidence has been delivered.
564 * Value -1: A verifier malfunction occurred during the Verifier's
565 appraisal processing.
567 Affirming: The Verifier affirms the Attester support for this aspect
568 of trustworthiness.
570 * Values 2 to 31: A standards enumerated reason for affirming.
572 * Values -2 to -32: A non-standard reason for affirming.
574 Warning: The Verifier warns about this aspect of trustworthiness.
576 * Values 32 to 95: A standards enumerated reason for the warning.
578 * Values -33 to -96: A non-standard reason for the warning.
580 Contraindicated: The Verifier asserts the Attester is explicitly
581 untrustworthy in regard to this aspect.
583 * Values 96 to 127: A standards enumerated reason for the
584 contraindication.
586 * Values -97 to -128: A non-standard reason for the
587 contraindication.
589 This enumerated encoding listed above will simplify the Appraisal
590 Policy for Attestation Results. Such a policies may be as simple as
591 saying that a specific Verifier has recently asserted Trustworthiness
592 Claims, all of which are Affirming.
594 2.3.3. Assigning a Trustworthiness Claim value
596 In order to simplify design, only a single encoded value is asserted
597 by a Verifier for any Trustworthiness Claim within a using the
598 following process.
600 1. If applicable, a Verifier MUST assign a standardized value from
601 the Contraindicated tier.
603 2. Else if applicable, a Verifier MUST assign a non-standardized
604 value from the Contraindicated tier.
606 3. Else if applicable, a Verifier MUST assign a standardized value
607 from the Warning tier.
609 4. Else if applicable, a Verifier MUST assign a non-standardized
610 value from the Warning tier.
612 5. Else if applicable, a Verifier MUST assign a standardized value
613 from the Affirming tier.
615 6. Else if applicable, a Verifier MUST assign a non-standardized
616 value from the Affirming tier.
618 7. Else a Verifier MAY assign a 0 or -1.
620 2.3.4. Specific Claims
622 Following are the Trustworthiness Claims and their supported
623 enumerations which may be asserted by a Verifier:
625 configuration: A Verifier has appraised an Attester's configuration,
626 and is able to make conclusions regarding the exposure of known
627 vulnerabilities
629 0: No assertion
631 1: Verifer cannot parse unexpected Evidence.
633 -1: Verifier malfunction
635 2: The configuration is a known and approved config.
637 3: The configuration includes or exposes no known
638 vulnerabilities.
640 32: The configuration includes or exposes known vulnerabilities.
642 96: The configuration is unsupportable as it exposes unacceptable
643 security vulnerabilities.
645 99: Cryptographic validation of the Evidence has failed.
647 executables: A Verifier has appraised and evaluated relevant runtime
648 files, scripts, and/or other objects which have been loaded into
649 the Target environment's memory.
651 0: No assertion
653 1: Verifer cannot parse unexpected Evidence.
655 -1: Verifier malfunction
657 2: Only a recognized genuine set of approved executables,
658 scripts, files, and/or objects have been loaded during and
659 after the boot process.
661 3: Only a recognized genuine set of approved executables have
662 been loaded during the boot process.
664 32: Only a recognized genuine set of executables, scripts, files,
665 and/or objects have been loaded. However the Verifier cannot
666 vouch for a subset of these due to known bugs or other known
667 vulnerabilities.
669 33: Runtime memory includes executables, scripts, files, and/or
670 objects which are not recognized.
672 96: Runtime memory includes executables, scripts, files, and/or
673 object which are contraindicated.
675 99: Cryptographic validation of the Evidence has failed.
677 file-system: A Verifier has evaluated a specific set of directories
678 within the Attester's file system. (Note: the Verifier may or may
679 not indicate what these directory and expected files are via an
680 unspecified management interface.)
682 0: No assertion
684 1: Verifer cannot parse unexpected Evidence.
686 -1: Verifier malfunction
688 2: Only a recognized set of approved files are found.
690 32: The file system includes unrecognized executables, scripts,
691 or files.
693 96: The file system includes contraindicated executables,
694 scripts, or files.
696 99: Cryptographic validation of the Evidence has failed.
698 hardware: A Verifier has appraised any Attester hardware and
699 firmware which are able to expose fingerprints of their identity
700 and running code.
702 0: No assertion
704 1: Verifer cannot parse unexpected Evidence.
706 -1: Verifier malfunction
708 2: An Attester has passed its hardware and/or firmware
709 verifications needed to demonstrate that these are genuine/
710 supported.
712 32: An Attester contains only genuine/supported hardware and/or
713 firmware, but there are known security vulnerabilities.
715 96: Attester hardware and/or firmware is recognized, but its
716 trustworthiness is contraindicated.
718 97: A Verifier does not recognize an Attester's hardware or
719 firmware, but it should be recognized.
721 99: Cryptographic validation of the Evidence has failed.
723 instance-identity: A Verifier has appraised an Attesting
724 Environment's unique identity based upon private key signed
725 Evidence which can be correlated to a unique instantiated instance
726 of the Attester. (Note: this Trustworthiness Claim should only be
727 generated if the Verifier actually expects to recognize the unique
728 identity of the Attester.)
730 0: No assertion
732 1: Verifer cannot parse unexpected Evidence.
734 -1: Verifier malfunction
736 2: The Attesting Environment is recognized, and the associated
737 instance of the Attester is not known to be compromised.
739 96: The Attesting Environment is recognized, and but its unique
740 private key indicates a device which is not trustworthy.
742 97: The Attesting Environment is not recognized; however the
743 Verifier believes it should be.
745 99: Cryptographic validation of the Evidence has failed.
747 runtime-opaque: A Verifier has appraised the visibility of Attester
748 objects in memory from perspectives outside the Attester.
750 0: No assertion
752 1: Verifer cannot parse unexpected Evidence.
754 -1: Verifier malfunction
756 2: the Attester's executing Target Environment and Attesting
757 Environments are encrypted and within Trusted Execution
758 Environment(s) opaque to the operating system, virtual machine
759 manager, and peer applications. (Note: This value corresponds
760 to the protections asserted by O.RUNTIME_CONFIDENTIALITY from
761 [GP-TEE-PP])
763 32: the Attester's executing Target Environment and Attesting
764 Environments inaccessible from any other parallel application
765 or Guest VM running on the Attester's physical device. (Note
766 that unlike "1" these environments are not encrypted in a way
767 which restricts the Attester's root operator visibility. See
768 O.TA_ISOLATION from [GP-TEE-PP].)
770 96: The Verifier has concluded that in memory objects are
771 unacceptably visible within the physical host that supports the
772 Attester.
774 99: Cryptographic validation of the Evidence has failed.
776 sourced-data: A Verifier has evaluated of the integrity of data
777 objects from external systems used by the Attester.
779 0: No assertion
781 1: Verifer cannot parse unexpected Evidence.
783 -1: Verifier malfunction
785 2: All essential Attester source data objects have been provided
786 by other Attester(s) whose most recent appraisal(s) had both no
787 Trustworthiness Claims of "0" where the current Trustworthiness
788 Claim is "Affirming", as well as no "Warning" or
789 "Contraindicated" Trustworthiness Claims.
791 32: Attester source data objects come from unattested sources, or
792 attested sources with "Warning" type Trustworthiness Claims.
794 96: Attester source data objects come from contraindicated
795 sources.
797 99: Cryptographic validation of the Evidence has failed.
799 storage-opaque: A Verifier has appraised that an Attester is capable
800 of encrypting persistent storage. (Note: Protections must meet
801 the capabilities of [OMTP-ATE] Section 5, but need not be hardware
802 tamper resistant.)
804 0: No assertion
805 1: Verifer cannot parse unexpected Evidence.
807 -1: Verifier malfunction
809 2: the Attester encrypts all secrets in persistent storage via
810 using keys which are never visible outside an HSM or the
811 Trusted Execution Environment hardware.
813 32: the Attester encrypts all persistently stored secrets, but
814 without using hardware backed keys
816 96: There are persistent secrets which are stored unencrypted in
817 an Attester.
819 99: Cryptographic validation of the Evidence has failed.
821 It is possible for additonal Trustworthiness Claims and enumerated
822 values to be defined in subsequent documents. At the same time, the
823 standardized Trustworthiness Claim values listed above have been
824 designed so there is no overlap within a Trustworthiness Tier. As a
825 result, it is possible to imagine a future where overlapping
826 Trustworthiness Claims within a single Trustworthiness Tier may be
827 defined. Wherever possible, the Verifier SHOULD assign the best
828 fitting standardized value.
830 Where a Relying Party doesn't know how to handle a particular
831 Trustworthiness Claim, it MAY choose an appropriate action based on
832 the Trustworthiness Tier under which the enumerated value fits.
834 It is up to the Verifier to publish the types of evaluations it
835 performs when determining how Trustworthiness Claims are derived for
836 a type of any particular type of Attester. It is out of the scope of
837 this document for the Verifier to provide proof or specific logic on
838 how a particular Trustworthiness Claim which it is asserting was
839 derived.
841 2.3.5. Trustworthiness Vector
843 Multiple Trustworthiness Claims may be asserted about an Attesting
844 Environment at single point in time. The set of Trustworthiness
845 Claims inserted into an instance of Attestation Results by a Verifier
846 is known as a Trustworthiness Vector. The order of Claims in the
847 vector is NOT meaningful. A Trustworthiness Vector with no
848 Trustworthiness Claims (i.e., a null Trustworthiness Vector) is a
849 valid construct. In this case, the Verifier is making no
850 Trustworthiness Claims but is confirming that an appraisal has been
851 made.
853 2.3.6. Trustworthiness Vector for a type of Attesting Environment
855 Some Trustworthiness Claims are implicit based on the underlying type
856 of Attesting Environment. For example, a validated MRSIGNER identity
857 can be present where the underlying [SGX] hardware is 'hw-authentic'.
858 Where such implicit Trustworthiness Claims exist, they do not have to
859 be explicitly included in the Trustworthiness Vector. However, these
860 implicit Trustworthiness Claims SHOULD be considered as being present
861 by the Relying Party. Another way of saying this is if a
862 Trustworthiness Claim is automatically supported as a result of
863 coming from a specific type of TEE, that claim need not be
864 redundantly articulated. Such implicit Trustworthiness Claims can be
865 seen in the tables within Appendix B.2 and Appendix B.3.
867 Additionally, there are some Trustworthiness Claims which cannot be
868 adequately supported by an Attesting Environment. For example, it
869 would be difficult for an Attester that includes only a TPM (and no
870 other TEE) from ever having a Verifier appraise support for 'runtime-
871 opaque'. As such, a Relying Party would be acting properly if it
872 rejects any non-supportable Trustworthiness Claims asserted from a
873 Verifier.
875 As a result, the need for the ability to carry a specific
876 Trustworthiness Claim will vary by the type of Attesting Environment.
877 Example mappings can be seen in Appendix B.
879 2.4. Freshness
881 A Relying Party will care about the recentness of the Attestation
882 Results, and the specific Trustworthiness Claims which are embedded.
883 All freshness mechanisms of [I-D.ietf-rats-architecture], Section 10
884 are supportable by this specification.
886 Additionally, a Relying Party may track when a Verifier expires its
887 confidence for the Trustworthiness Claims or the Trustworthiness
888 Vector as a whole. Mechanisms for such expiry are not defined within
889 this document.
891 There is a subset of secure interactions where the freshness of
892 Trustworthiness Claims may need to be revisited asynchronously. This
893 subset is when trustworthiness depends on the continuous availability
894 of a transport session between the Attester and Relying Party. With
895 such connectivity dependent Attestation Results, if there is a reboot
896 which resets transport connectivity, all established Trustworthiness
897 Claims should be cleared. Subsequent connection re-establishment
898 will allow fresh new Trustworthiness Claims to be delivered.
900 3. Secure Interactions Models
902 There are multiple ways of providing a Trustworthiness Vector to a
903 Relying Party. This section describes two alternatives.
905 3.1. Background-Check
907 3.1.1. Verifier Retrieval
909 It is possible to for a Relying Party to follow the Background-Check
910 Model defined in Section 5.2 of [I-D.ietf-rats-architecture]. In
911 this case, a Relying Party will receive Attestation Results
912 containing the Trustworthiness Vector directly from a Verifier.
913 These Attestation Results can then be used by the Relying Party in
914 determining the appropriate treatment for interactions with the
915 Attester.
917 While applicable in some cases, the utilization of the Background-
918 Check Model without modification has potential drawbacks in other
919 cases. These include:
921 * Verifier scale: if the Attester has many Relying Parties, a
922 Verifier appraising that Attester could be frequently be queried
923 based on the same Evidence.
925 * Information leak: Evidence which the Attester might consider
926 private can be visible to the Relying Party. Hiding that Evidence
927 could devalue any resulting appraisal.
929 * Latency: a Relying Party will need to wait for the Verifier to
930 return Attestation Results before proceeding with secure
931 interactions with the Attester.
933 An implementer should examine these potential drawbacks before
934 selecting this alternative.
936 3.1.2. Co-resident Verifier
938 A simplified Background-Check Model may exist in a very specific
939 case.
940 This is where the Relying Party and Verifier functions are co-
941 resident. This model is appropriate when:
943 * Some hardware-based private key is used by an Attester while
944 proving its identity as part of a mutually authenticated secure
945 channel establishment with the Relying Party, and
947 * this Attester identity is accepted as sufficient proof of Attester
948 integrity.
950 Effectively this means that detailed forensic capabilities of a
951 robust Verifier are unnecessary because it is accepted that the code
952 and operational behavior of the Attester cannot be manipulated after
953 TEE initialization.
955 An example of such a scenario may be when an SGX's MRENCLAVE and
956 MRSIGNER values have been associated with a known QUOTE value. And
957 the code running within the TEE is not modifiable after launch.
959 3.2. Below Zero Trust
961 Zero Trust Architectures are referenced in [US-Executive-Order]
962 eleven times. However despite this high profile, there is an
963 architectural gap with Zero Trust. The credentials used for
964 authentication and admission control can be manipulated on the
965 endpoint. Attestation can fill this gap through the generation of a
966 compound credential called AR-augmented Evidence.
967 This compound credential is rooted in the hardware based Attesting
968 Environment of an endpoint, plus the trustworthiness of a Verifier.
969 The overall solution is known as "Below Zero Trust" as the compound
970 credential cannot be manipulated or spoofed by an administrator of an
971 endpoint with root access. This solution is not adversely impacted
972 by the potential drawbacks with pure background-check described
973 above.
975 To kick-off the "Below Zero Trust" compound credential creation
976 sequence, a Verifier evaluates an Attester and returns signed
977 Attestation Results back to this original Attester no less frequently
978 than a well-known interval. This interval may also be asynchronous,
979 based on the changing of certain Evidence as described in
980 [I-D.ietf-rats-network-device-subscription].
982 When a Relying Party is to receive information about the Attester's
983 trustworthiness, the Attesting Environment assembles the minimal set
984 of Evidence which can be used to confirm or refute whether the
985 Attester remains in the state of trustworthiness represented by the
986 AR. To this Evidence, the Attesting Environment appends the
987 signature from the most recent AR as well as a Relying Party Proof-
988 of-Freshness. The Attesting Environment then signs the combination.
990 The Attester then assembles AR Augmented Evidence by taking the
991 signed combination and appending the full AR. The assembly now
992 consists of two independent but semantically bound sets of signed
993 Evidence.
995 The AR Augmented Evidence is then sent to the Relying Party. The
996 Relying Party then can appraise these semantically bound sets of
997 signed Evidence by applying an Appraisal Policy for Attestation
998 Results as described below. This policy will consider both the AR as
999 well as additional information about the Attester within the AR
1000 Augmented Evidence the when determining what action to take.
1002 This alternative combines the [I-D.ietf-rats-architecture] Sections
1003 5.1 Passport Model and Section 5.2 Background-Check Model. Figure 1
1004 describes this flow of information. The flows within this combined
1005 model are mapped to [I-D.ietf-rats-architecture] in the following
1006 way. "Verifier A" below corresponds to the "Verifier" Figure 5
1007 within [I-D.ietf-rats-architecture]. And "Relying Party/Verifier B"
1008 below corresponds to the union of the "Relying Party" and "Verifier"
1009 boxes within Figure 6 of [I-D.ietf-rats-architecture]. This union is
1010 possible because Verifier B can be implemented as a simple, self-
1011 contained process. The resulting combined process can appraise the
1012 AR-augmented Evidence to determine whether an Attester qualifies for
1013 secure interactions with the Relying Party. The specific steps of
1014 this process are defined later in this section.
1016 .----------------.
1017 | Attester |
1018 | .-------------.|
1019 | | Attesting || .----------. .---------------.
1020 | | Environment || | Verifier | | Relying Party |
1021 | '-------------'| | A | | / Verifier B |
1022 '----------------' '----------' '---------------'
1023 time(VG) | |
1024 |<------Verifier PoF-------time(NS) |
1025 | | |
1026 time(EG)(1)------Evidence------------>| |
1027 | time(RG) |
1028 |<------Attestation Results-(2) |
1029 ~ ~ ~
1030 time(VG')? | |
1031 ~ ~ ~
1032 |<------Relying Party PoF-----------------(3)time(NS')
1033 | | |
1034 time(EG')(4)------AR-augmented Evidence----------------->|
1035 | | time(RG',RA')(5)
1036 (6)
1037 ~
1038 time(RX')
1040 Figure 1: Below Zero Trust
1042 The interaction model depicted above includes specific time related
1043 events from Appendix A of [I-D.ietf-rats-architecture]. With the
1044 identification of these time related events, time duration/interval
1045 tracking becomes possible. Such duration/interval tracking can
1046 become important if the Relying Party cares if too much time has
1047 elapsed between the Verifier PoF and Relying Party PoF. If too much
1048 time has elapsed, perhaps the Attestation Results themselves are no
1049 longer trustworthy.
1051 Note that while time intervals will often be relevant, there is a
1052 simplified case that does not require a Relying Party's PoF in step
1053 (3). In this simplified case, the Relying Party trusts that the
1054 Attester cannot be meaningfully changed from the outside during any
1055 reportable interval. Based on that assumption, and when this is the
1056 case then the step of the Relying Party PoF can be safely omitted.
1058 In all cases, appraisal policies define the conditions and
1059 prerequisites for when an Attester does qualify for secure
1060 interactions. To qualify, an Attester has to be able to provide all
1061 of the mandatory affirming Trustworthiness Claims and identities
1062 needed by a Relying Party's Appraisal Policy for Attestation Results,
1063 and none of the disqualifying detracting Trustworthiness Claims.
1065 More details on each interaction step of Below Zero Trust are as
1066 follows. The numbers used in this sequence match to the numbered
1067 steps in Figure 1:
1069 1. An Attester sends Evidence which is provably fresh to Verifier A
1070 at time(EG). Freshness from the perspective of Verifier A MAY be
1071 established with Verifier PoF such as a nonce.
1073 2. Verifier A appraises (1), then sends the following items back to
1074 that Attester within Attestation Results:
1076 1. the verified identity of the Attesting Environment,
1078 2. the Verifier A appraised Trustworthiness Vector of an
1079 Attester,
1081 3. a freshness proof associated with the Attestation Results,
1083 4. a Verifier signature across (2.1) though (2.3).
1085 3. At time(EG') a Relying Party PoF (such as a nonce) known to the
1086 Relying Party is sent to the Attester.
1088 4. The Attester generates and sends AR-augmented Evidence to the
1089 Relying Party/Verifier B. This AR-augmented Evidence includes:
1091 1. The Attestation Results from (2)
1093 2. Any (optionally) new incremental Evidence from the Attesting
1094 Environment
1096 3. Attestation Environment signature which spans a hash of the
1097 Attestation Results (such as the signature of (2.4)), the
1098 proof-of-freshness from (3), and (4.2). Note: this construct
1099 allows the delta of time between (2.3) and (3) to be
1100 definitively calculated by the Relying Party.
1102 5. On receipt of (4), the Relying Party applies its Appraisal Policy
1103 for Attestation Results. At minimum, this appraisal policy
1104 process must include the following:
1106 1. Verify that (4.3) includes the nonce from (3).
1108 2. Use a local certificate to validate the signature (4.1).
1110 3. Verify that the hash from (4.3) matches (4.1)
1112 4. Use the identity of (2.1) to validate the signature of (4.3).
1114 5. Failure of any steps (5.1) through (5.4) means the link does
1115 not meet minimum validation criteria, therefore appraise the
1116 link as having a null Verifier B Trustworthiness Vector.
1117 Jump to step (6.1).
1119 6. When there is large or uncertain time gap between time(EG)
1120 and time(EG'), the link should be assigned a null Verifier B
1121 Trustworthiness Vector. Jump to step (6.1).
1123 7. Assemble the Verifier B Trustworthiness Vector
1125 1. Copy Verifier A Trustworthiness Vector to Verifier B
1126 Trustworthiness Vector
1128 2. Add implicit Trustworthiness Claims inherent to the type
1129 of TEE.
1131 3. Prune any Trustworthiness Claims unsupportable by the
1132 Attesting Environment.
1134 4. Prune any Trustworthiness Claims the Relying Party
1135 doesn't accept from this Verifier.
1137 6. The Relying Party takes action based on Verifier B's appraised
1138 Trustworthiness Vector, and applies the Appraisal Policy for
1139 Attestation Results. Following is a reasonable process for such
1140 evaluation:
1142 1. Prune any Trustworthiness Claims from the Trustworthiness
1143 Vector not used in the Appraisal Policy for Attestation
1144 Results.
1146 2. Allow the information exchange from the Attester into a
1147 Relying Party context in the Appraisal Policy for Attestation
1148 Results where the Verifier B appraised Trustworthiness Vector
1149 includes all the mandatory Trustworthiness Claims are in the
1150 "Affirming" value range, and none of the disqualifying
1151 Trustworthiness Claims are in the "Contraindicated" value
1152 range.
1154 3. Disallow any information exchange into a Relying Party
1155 context for which that Verifier B appraised Trustworthiness
1156 Vector is not qualified.
1158 As link layer protocols re-authenticate, steps (1) to (2) and steps
1159 (3) to (6) will independently refresh. This allows the
1160 Trustworthiness of Attester to be continuously re-appraised. There
1161 are only specific event triggers which will drive the refresh of
1162 Evidence generation (1), Attestation Result generation (2), or AR-
1163 augmented Evidence generation (4):
1165 * life-cycle events, e.g. a change to an Authentication Secret of
1166 the Attester or an update of a software component.
1168 * uptime-cycle events, e.g. a hard reset or a re-initialization of
1169 an Attester.
1171 * authentication-cycle events, e.g. a link-layer interface reset
1172 could result in a new (4).
1174 3.3. Mutual Attestation
1176 In the interaction models described above, each device on either side
1177 of a secure interaction may require remote attestation of its peer.
1178 This process is known as mutual-attestation. To support mutual-
1179 attestation, the interaction models listed above may be run
1180 independently on either side of the connection.
1182 3.4. Transport Protocol Integration
1184 Either unidirectional attestation or mutual attestation may be
1185 supported within the protocol interactions needed for the
1186 establishment of a single transport session. While this document
1187 does not mandate specific transport protocols, messages containing
1188 the Attestation Results and AR Augmented Evidence can be passed
1189 within an authentication framework such the EAP protocol [RFC5247]
1190 over TLS [RFC8446].
1192 4. Privacy Considerations
1194 Privacy Considerations Text
1196 5. Security Considerations
1198 Security Considerations Text
1200 6. IANA Considerations
1202 See Body.
1204 7. References
1206 7.1. Normative References
1208 [GP-TEE-PP]
1209 "Global Platform TEE Protection Profile v1.3", September
1210 2020, .
1213 [I-D.ietf-rats-architecture]
1214 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
1215 W. Pan, "Remote Attestation Procedures Architecture", Work
1216 in Progress, Internet-Draft, draft-ietf-rats-architecture-
1217 15, 8 February 2022, .
1220 [OMTP-ATE] "Open Mobile Terminal Platform - Advanced Trusted
1221 Environment", May 2009, .
1225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1226 Requirement Levels", BCP 14, RFC 2119,
1227 DOI 10.17487/RFC2119, March 1997,
1228 .
1230 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1231 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1232 May 2017, .
1234 7.2. Informative References
1236 [I-D.ietf-rats-network-device-subscription]
1237 Birkholz, H., Voit, E., and W. Pan, "Attestation Event
1238 Stream Subscription", Work in Progress, Internet-Draft,
1239 draft-ietf-rats-network-device-subscription-01, 7 March
1240 2022, .
1243 [I-D.tschofenig-rats-psa-token]
1244 Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T.
1245 Fossati, "Arm's Platform Security Architecture (PSA)
1246 Attestation Token", Work in Progress, Internet-Draft,
1247 draft-tschofenig-rats-psa-token-09, 7 March 2022,
1248 .
1251 [IEEE802.1AR]
1252 "802.1AR: Secure Device Identity", 2 August 2018,
1253 .
1255 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
1256 Authentication Protocol (EAP) Key Management Framework",
1257 RFC 5247, DOI 10.17487/RFC5247, August 2008,
1258 .
1260 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1261 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1262 .
1264 [SEV-SNP] "AMD SEV-SNP: Stregthening VM Isolation with Integrity
1265 Protection and More", 2020,
1266 .
1270 [SGX] "Supporting Third Party Attestation for Intel SGX with
1271 Intel Data Center Attestation Primitives", 2017, .
1276 [TDX] "Intel Trust Domain Extensions", 2020, .
1280 [TPM-ID] "TPM Keys for Platform Identity for TPM 1.2", August 2015,
1281 .
1284 [TPM2.0] "Trusted Platform Module Library - Part 1: Architecture",
1285 n.d., .
1289 [US-Executive-Order]
1290 "Executive Order on Improving the Nation's Cybersecurity",
1291 12 May 2021, .
1295 Appendix A. Implementation Guidance
1297 A.1. Supplementing Trustworthiness Claims
1299 What has been encoded into each Trustworthiness Claim is the domain
1300 of integer values which is likely to drive a different programmatic
1301 decision in the Relying Party's Appraisal Policy for Attestation
1302 Results. This will not be the only thing a Relying Party's
1303 Operations team might care to track for measurement or debugging
1304 purposes.
1306 There is also the opportunity for the Verifier to include
1307 supplementary Evidence beyond a set of asserted Trustworthiness
1308 Claims. It is recommended that if supplementary Evidence is provided
1309 by the Verifier within the Attestation Results, that this
1310 supplementary Evidence includes a reference to a specific
1311 Trustworthiness Claim. This will allow a deeper understanding of
1312 some of the reasoning behind the integer value assigned.
1314 Appendix B. Supportable Trustworthiness Claims
1316 The following is a table which shows what Claims are supportable by
1317 different Attesting Environment types. Note that claims MAY BE
1318 implicit to an Attesting Environment type, and therefore do not have
1319 to be included in the Trustworthiness Vector to be considered as set
1320 by the Relying Party.
1322 B.1. Supportable Trustworthiness Claims for HSM-based CC
1324 Following are Trustworthiness Claims which MAY be set for a HSM-based
1325 Confidential Computing Attester. (Such as a TPM [TPM-ID].)
1326 +===================+===========+==================================+
1327 | Trustworthiness | Required? | Appraisal Method |
1328 | Claim | | |
1329 +===================+===========+==================================+
1330 | configuration | Optional | Verifier evaluation of Attester |
1331 | | | reveals no configuration lines |
1332 | | | which expose the Attester to |
1333 | | | known security vulnerabilities. |
1334 | | | This may be done with or without |
1335 | | | the involvement of a TPM PCR. |
1336 +-------------------+-----------+----------------------------------+
1337 | executables | Yes | Checks the TPM PCRs for the |
1338 | | | static operating system, and for |
1339 | | | any tracked files subsequently |
1340 | | | loaded |
1341 +-------------------+-----------+----------------------------------+
1342 | file-system | No | Can be supported, but TPM |
1343 | | | tracking is unlikely |
1344 +-------------------+-----------+----------------------------------+
1345 | hardware | Yes | If TPM PCR check ok from BIOS |
1346 | | | checks, through Master Boot |
1347 | | | Record configuration |
1348 +-------------------+-----------+----------------------------------+
1349 | instance-identity | Optional | Check IDevID |
1350 +-------------------+-----------+----------------------------------+
1351 | runtime-opaque | n/a | TPMs are not recommended to |
1352 | | | provide a sufficient technology |
1353 | | | base for this Trustworthiness |
1354 | | | Claim. |
1355 +-------------------+-----------+----------------------------------+
1356 | sourced-data | n/a | TPMs are not recommended to |
1357 | | | provide a sufficient technology |
1358 | | | base for this Trustworthiness |
1359 | | | Claim. |
1360 +-------------------+-----------+----------------------------------+
1361 | storage-opaque | Minimal | With a TPM, secure storage space |
1362 | | | exists and is writeable by |
1363 | | | external applications. But the |
1364 | | | space is so limited that it |
1365 | | | often is used just be used to |
1366 | | | store keys. |
1367 +-------------------+-----------+----------------------------------+
1369 Table 2
1371 Setting the Trustworthiness Claims may follow the following logic at
1372 the Verifier A within (2) of Figure 1:
1374 Start: Evidence received starts the generation of a new
1375 Trustworthiness Vector. (e.g., TPM Quote Received, log received,
1376 or appraisal timer expired)
1378 Step 0: set Trustworthiness Vector = Null
1380 Step 1: Is there sufficient fresh signed evidence to appraise?
1381 (yes) - No Action
1382 (no) - Goto Step 6
1384 Step 2: Appraise Hardware Integrity PCRs
1385 if (hardware NOT "0") - push onto vector
1386 if (hardware NOT affirming or warning), go to Step 6
1388 Step 3: Appraise Attesting Environment identity
1389 if (instance-identity <> "0") - push onto vector
1391 Step 4: Appraise executable loaded and filesystem integrity
1392 if (executables NOT "0") - push onto vector
1393 if (executables NOT affirming or warning), go to Step 6
1395 Step 5: Appraise all remaining Trustworthiness Claims
1396 Independently and set as appropriate.
1398 Step 6: Assemble Attestation Results, and push to Attester
1400 End
1402 B.2. Supportable Trustworthiness Claims for process-based CC
1404 Following are Trustworthiness Claims which MAY be set for a process-
1405 based Confidential Computing based Attester. (Such as a SGX Enclaves
1406 and TrustZone.)
1407 +===================+===========+==================================+
1408 | Trustworthiness | Required? | Appraisal Method |
1409 | Claim | | |
1410 +===================+===========+==================================+
1411 | instance-identity | Optional | Internally available in TEE. |
1412 | | | But keys might not be known/ |
1413 | | | exposed to the Relying Party by |
1414 | | | the Attesting Environment. |
1415 +-------------------+-----------+----------------------------------+
1416 | configuration | Optional | If done, this is at the |
1417 | | | Application Layer. Plus each |
1418 | | | process needs it own protection |
1419 | | | mechanism as the protection is |
1420 | | | limited to the process itself. |
1421 +-------------------+-----------+----------------------------------+
1422 | executables | Optional | Internally available in TEE. |
1423 | | | But keys might not be known/ |
1424 | | | exposed to the Relying Party by |
1425 | | | the Attesting Environment. |
1426 +-------------------+-----------+----------------------------------+
1427 | file-system | Optional | Can be supported by application, |
1428 | | | but process-based CC is not a |
1429 | | | sufficient technology base for |
1430 | | | this Trustworthiness Claim. |
1431 +-------------------+-----------+----------------------------------+
1432 | hardware | Implicit | At least the TEE is protected |
1433 | | in | here. Other elements of the |
1434 | | signature | system outside of the TEE might |
1435 | | | need additional protections is |
1436 | | | used by the application process. |
1437 +-------------------+-----------+----------------------------------+
1438 | runtime-opaque | Implicit | From the TEE |
1439 | | in | |
1440 | | signature | |
1441 +-------------------+-----------+----------------------------------+
1442 | storage-opaque | Implicit | Although the application must |
1443 | | in | assert that this function is |
1444 | | signature | used by the code itself. |
1445 +-------------------+-----------+----------------------------------+
1446 | sourced-data | Optional | Will need to be supported by |
1447 | | | application code |
1448 +-------------------+-----------+----------------------------------+
1450 Table 3
1452 B.3. Supportable Trustworthiness Claims for VM-based CC
1454 Following are Trustworthiness Claims which MAY be set for a VM-based
1455 Confidential Computing based Attester. (Such as SEV, TDX, ACCA, SEV-
1456 SNP.)
1458 +===================+===========+===================================+
1459 | Trustworthiness | Required? | Appraisal Method |
1460 | Claim | | |
1461 +===================+===========+===================================+
1462 | instance-identity | Optional | Internally available in TEE. |
1463 | | | But keys might not be known/ |
1464 | | | exposed to the Relying Party by |
1465 | | | the Attesting Environment. |
1466 +-------------------+-----------+-----------------------------------+
1467 | configuration | Optional | Requires application |
1468 | | | integration. Easier than with |
1469 | | | process-based solution, as the |
1470 | | | whole protected machine can be |
1471 | | | evaluated. |
1472 +-------------------+-----------+-----------------------------------+
1473 | executables | Optional | Internally available in TEE. |
1474 | | | But keys might not be known/ |
1475 | | | exposed to the Relying Party by |
1476 | | | the Attesting Environment. |
1477 +-------------------+-----------+-----------------------------------+
1478 | file-system | Optional | Can be supported by application |
1479 +-------------------+-----------+-----------------------------------+
1480 | hardware | Chip | At least the TEE is protected |
1481 | | dependent | here. Other elements of the |
1482 | | | system outside of the TEE might |
1483 | | | need additional protections is |
1484 | | | used by the application process. |
1485 +-------------------+-----------+-----------------------------------+
1486 | runtime-opaque | Implicit | From the TEE |
1487 | | in | |
1488 | | signature | |
1489 +-------------------+-----------+-----------------------------------+
1490 | storage-opaque | Chip | Although the application must |
1491 | | dependent | assert that this function is |
1492 | | | used by the code itself. |
1493 +-------------------+-----------+-----------------------------------+
1494 | sourced-data | Optional | Will need to be supported by |
1495 | | | application code |
1496 +-------------------+-----------+-----------------------------------+
1498 Table 4
1500 Appendix C. Some issues being worked
1502 It is possible for a cluster/hierarchy of Verifiers to have aggregate
1503 AR which are perhaps signed/endorsed by a lead Verifier. What should
1504 be the Proof-of-Freshness or Verifier associated with any of the
1505 aggregate set of Trustworthiness Claims?
1507 There will need to be a subsequent document which documents how these
1508 objects which will be translated into a protocol on a wire (e.g. EAP
1509 on TLS). Some breakpoint between what is in this draft, and what is
1510 in specific drafts for wire encoding will need to be determined.
1511 Questions like architecting the cluster/hierarchy of Verifiers fall
1512 into this breakdown.
1514 For some Trustworthiness Claims, there could be value in identifying
1515 a specific Appraisal Policy for Attestation Results applied within
1516 the Attester. One way this could be done would be a URI which
1517 identifies the policy used at Verifier A, and this URI would
1518 reference a specific Trustworthiness Claim. As the URI also could
1519 encode the version of the software, it might also act as a mechanism
1520 to signal the Relying Party to refresh/re-evaluate its view of
1521 Verifier A. Do we need this type of structure to be included here?
1522 Should it be in subsequent documents?
1524 Expand the variant of Figure 1 which requires no Relying Party PoF
1525 into its own picture.
1527 In what document (if any) do we attempt normalization of the identity
1528 claims between different types of TEE. E.g., does MRSIGNER plus
1529 extra loaded software = the sum of TrustZone Signer IDs for loaded
1530 components?
1532 Appendix D. Contributors
1534 Guy Fedorkow
1536 Email: gfedorkow@juniper.net
1538 Dave Thaler
1540 Email: dthaler@microsoft.com
1542 Ned Smith
1544 Email: ned.smith@intel.com
1546 Lawrence Lundblade
1547 Email: lgl@island-resort.com
1549 Authors' Addresses
1551 Eric Voit
1552 Cisco Systems
1553 Email: evoit@cisco.com
1555 Henk Birkholz
1556 Fraunhofer SIT
1557 Rheinstrasse 75
1558 64295 Darmstadt
1559 Germany
1560 Email: henk.birkholz@sit.fraunhofer.de
1562 Thomas Hardjono
1563 MIT
1564 Email: hardjono@mit.edu
1566 Thomas Fossati
1567 Arm Limited
1568 Email: Thomas.Fossati@arm.com
1570 Vincent Scarlata
1571 Intel
1572 Email: vincent.r.scarlata@intel.com