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