RATS Working Group E. Voit
Internet-Draft Cisco
Intended status: Standards Track H. Birkholz
Expires: October 28, 2021 Fraunhofer SIT
T. Hardjono
MIT
T. Fossati
Arm Limited
V. Scarlata
Intel
April 26, 2021
Attestation Results for Connectivity
draft-voit-rats-attestation-results-00
Abstract
This document defines reusable Attestation Result information
elements. When these elements are offered to Relying Parties as
Evidence, different aspects of Attester trustworthiness can be
evaluated. Additionally, where the Relying Party is interfacing with
a heterogenous mix of Attesting Environment and Verifier types,
consistent policies can be applied to subsequent information exchange
between each Attester and the Relying Party.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 28, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Voit, et al. Expires October 28, 2021 [Page 1]
Internet-Draft Attestation Results April 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Attestation Results and Actions . . . . . . . . . . . . . . . 5
2.1. Attestation Results for Connectivity . . . . . . . . . . 5
2.2. Non-repudiable Identity . . . . . . . . . . . . . . . . . 6
2.2.1. Verifier . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Attesting Environment . . . . . . . . . . . . . . . . 7
2.2.3. Attester . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4. Communicating Identity . . . . . . . . . . . . . . . 7
2.3. Trustworthiness Claims . . . . . . . . . . . . . . . . . 8
2.3.1. Specific Claims . . . . . . . . . . . . . . . . . . . 8
2.3.2. Trustworthiness Vector . . . . . . . . . . . . . . . 10
2.3.3. Trustworthiness Vector for a type of Attesting
Environment . . . . . . . . . . . . . . . . . . . . . 10
2.4. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Connectivity Model . . . . . . . . . . . . . . . . . . . . . 11
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Supportable Trustworthiness Claims . . . . . . . . . 16
Appendix B. Supportable Trustworthiness Claims for TPMs . . . . 16
Appendix C. Supportable Trustworthiness Claims for SGX Enclaves 18
Appendix D. Supportable Trustworthiness Claims for TrustZone . . 19
Appendix E. Some issues being worked . . . . . . . . . . . . . . 20
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
The Remote ATtestation procedureS (RATS) architecture
[I-D.ietf-rats-architecture] defines conceptual messages conveyed
between architectural subsystems to support trustworthiness
Voit, et al. Expires October 28, 2021 [Page 2]
Internet-Draft Attestation Results April 2021
appraisal. Within RATS, the Attestation Results conceptual message
consists of "output generated by a Verifier, typically including
information about an Attester, where the Verifier vouches for the
validity of the results".
Generated Attestation Results are ultimately conveyed to one or more
Relying Parties. Reception of an Attestation Result enables a
Relying Party to determine what action to take with regards to an
Attester. Frequently, this action will be to choose whether to allow
the Attester to interact with the Relying Party over a connection
between the two.
When determining whether to allow connectivity-based interactions
with an Attester, a Relying Party is challenged with a number of
difficult problems which it must be able to handle successfully.
These problems include:
o What types of Attestation Results (AR) might a Relying Party be
willing to trust from a specific type of Verifier?
o What supplemental information must the Verifier need to include
within Attestation Results to convince a Relying Party to allow
interactions, or to apply policies to any connections, based on
these Attestation Results?
o What are the operating/environmental realities of the Attesting
Environment where a Relying Party should only be able to associate
a certain confidence regarding Attestation Results out of the
Verifier? (In other words, different types of Trusted Execution
Environments (TEE) need not be treated as equivalent.)
o How to make direct comparisons where there is a heterogeneous mix
of Attesting Environments and Verifier types.
To address these problems, it is important that specific Attestation
Result information elements are framed independently of Attesting
Environment specific constraints. If they are not, a Relying Party
would be forced to adapt to the syntax and semantics of many vendor
specific environments. This is not a reasonable ask as there can be
many types of Attesters connecting into a Relying Party.
The business need therefore is for common Attestation Result
information element definitions. With these definitions, consistent
connectivity decisions can be made by a Relying Party where there is
a heterogenous mix of Attesting Environment types and Verifier types.
This document defines information elements for Attestation Results in
a way which normalizes the trustworthiness assertions that can be
Voit, et al. Expires October 28, 2021 [Page 3]
Internet-Draft Attestation Results April 2021
made from a diverse set of Attesters. Of specific focus are TPM,
TrustZone, and SGX based Attesting Environments. Extensions to this
document can enable additional TEE environments and additional
information elements to be supported.
1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Terminology
The following terms are imported from [I-D.ietf-rats-architecture]:
Appraisal Policy for Attestation Results, Attester, Attesting
Environment, Claims, Evidence, Relying Party, and Verifier.
[I-D.ietf-rats-architecture] also describes topological patterns that
illustrate the need for interoperable conceptual messages. The two
patterns called "background-check model" and "passport model" are
imported from the RATS architecture and used in this document as a
reference to the architectural concepts: Background-Check Model and
Passport Model.
Newly defined terms for this document:
AR-augmented Evidence: a bundle of Evidence which includes at least
the following:
1. Verifier signed Attestation Results. These Attestation
Results must include a Trustworthiness Vector describing a
Verifier's most recent appraisal of an Attester, and some
Verifier Proof-of-Freshness (PoF).
2. A Relying Party PoF which is bound to the Attestation Results
of (1) by the Attester's Attesting Environment signature.
3. Sufficient information to determine the elapsed interval
between the Verifier PoF and Relying Party PoF.
Identity Evidence: Evidence which unambiguously identifies an
identity. Identity Evidence could take different forms, such as a
certificate, or a signature which can be appraised to have only
been generated by a specific private/public key pair.
Voit, et al. Expires October 28, 2021 [Page 4]
Internet-Draft Attestation Results April 2021
Trustworthiness Claim: a specific quanta of trustworthiness which
can be assigned by a Verifier based on its appraisal policy.
Trustworthiness Vector: a set of zero to many Trustworthiness Claims
assigned during a single appraisal procedure by a Verifier using
Evidence generated by an Attester. The vector is included within
Attestation Results.
2. Attestation Results and Actions
When a Relying Party receives Attestation Results, it will receive
them as part of a protocol from an endpoint which expects some result
from this communication. Upon receipt, the Relying Party will apply
an Appraisal Policy for Attestation Results. This policy will
consider the Attestation Results as well as additional information
about the Attester and Verifier when determining what action to take.
2.1. Attestation Results for Connectivity
When the action is a communication establishment attempt with an
Attester, there is only a limited set of actions which a Relying
Party might take. These actions include:
o Allow or deny information exchange with the Attester (i.e.,
connectivity). When there is a deny, reasons should be returned
to the Attester.
o Connect the Attester to a specific context within a Relying Party.
o Apply policies on the connection to or from the Attester (e.g.,
rate limits).
There are three categories of information which must be conveyed to
the Relying Party before it determines which of these actions to
take.
1. Non-repudiable Identity Evidence - Evidence which undoubtably
identifies one or more entities involved with a connection.
2. Trustworthiness Claims - Specifics a Verifier asserts with
regards to its trustworthiness findings about an Attester.
3. Claim Freshness - Establishes the time of last update (or
refresh) of Trustworthiness Claims.
The following sections detail requirements for these three
categories.
Voit, et al. Expires October 28, 2021 [Page 5]
Internet-Draft Attestation Results April 2021
2.2. Non-repudiable Identity
Identity Evidence must be conveyed during the establishment of any
trust-based relationship. Specific use cases will define the minimum
types of identities required by a particular Relying Party. At
minimum, a Relying Party MUST able to verify the identity of a
Verifier it chooses to trust. This Identity Evidence will often
consist of a Verifier signature aross the Attestation Results; and
this signature could only have come from a key pair maintained by a
trusted developer or operator of the Verifier. Also at minimum for
connectivity related relationships, each set of Attestation Results
must be provably and non-reputably bound to the identity of the
specific Attesting Environment.
In a subset of use cases, these two pieces of Identity Evidence may
be sufficient for a Relying Party to successfully meet the criteria
for its Appraisal Policy for Attestation Results. In this case a
Relying Party will simply connect to any device successfully
appraised and verified by a Verifier. However where the Appraisal
Policy for Attestation Results is more nuanced, the Relying Party may
need additional information. Some Identity Evidence related
questions which the Relying Party may consider include:
o Does the Relying Party only trust this Verifier to make
Trustworthiness Claims on behalf a specific type of hardware
rooted Attesting Environment? Might a mix of Verifiers be
necessary to cover all mandatory Trustworthiness Claims?
o Does the Relying Party only accept connections from a verified-
authentic software build from a specific software developer?
o Does the Relying Party only accept connections from specific
preconfigured list of Attesters?
For any of these more nuanced appraisals, additional Identity
Evidence or other policy related information must be conveyed or pre-
provisioned during the formation of a trust context between the
Relying Party, the Attester, the Attester's Attesting Environment,
and the Verifier.
2.2.1. Verifier
For the Verifier identity, it is important to review the chain of
trust for that Verifier. Additionally, the Relying Party must have
confidence that the Trustworthiness Claims being relied upon from the
Verifier considered the chain of trust for the Attesting Environment
.
Voit, et al. Expires October 28, 2021 [Page 6]
Internet-Draft Attestation Results April 2021
2.2.2. Attesting Environment
For the Attesting Environment identity, there MUST exist a chain of
trust ultimately bound to a hardware-based root of trust in the
Attesting Environment. It is upon this root of trust that unique,
non-repudiable identities may be founded. Example attested
identities may include:
o a type of hardware chip used for the Attesting Environment
o a specific instance of a running Attesting Environment
o a software build executing within an Attesting Environment
o the developer(s) responsible for the code executing within an
Attesting Environment
This document only defines the domain of the first of these four
identities. The reason the first is especially important in this
document's context is that each type of hardware chip might support a
different set of Trustworthiness Claims. Consequently, the Relying
Party might require Identity Evidence which indicates of the type of
hardware chip when it considers its Appraisal Policy for Attestation
Results. For more see Appendix A.
2.2.3. Attester
Per [I-D.ietf-rats-architecture] Section 3.3, an Attester and a
corresponding Attesting Environment might not share common
boundaries. In such cases, where connections are being established
directly to an Attester but not to the Attesting Environment, the
Verifier must include sufficient information in the Attestation
Results to enable the Relying Party to have confidence that the
Attester's trustworthiness is represented by Trustworthiness Claims
signed by the appropriate Attesting Environment.
2.2.4. Communicating Identity
Any of the above identities may be needed to be established by the
Relying Party during the connectivity establishment process.
(text below needs work)
The mechanism for communicating the Attesting Environment identity
(and if it is different, the Attester identity ) may be either
implicit or explicit within an instance of Attestation Results. An
example of explicit communication would be to include the following
Identity Evidence directly in the Attestation Results: a unique
Voit, et al. Expires October 28, 2021 [Page 7]
Internet-Draft Attestation Results April 2021
identifier for an Attesting Environment, the name of a key which can
be provably associated with that unique identifier, and the set of
Attestation Results are signed using that key. An example of
implicit communication would be to include the following Identity
Evidence: a signature which has been made across the Attestation
Results. It would be then up to the Relying Party's Appraisal Policy
for Attestation Results to verify that this signature could only have
come from an entity having access to the associated private key.
Note that proving identity also requires some element of freshness be
embedded within a signed portion of the Attestation Results. This
element of freshness significantly reduces the identity spoofing
risks from a replay attack.
2.3. Trustworthiness Claims
2.3.1. Specific Claims
A Verifier must be able to assert different aspects of Attester
trustworthiness. Therefore specific Claims of Verifier appraised
trustworthiness have been defined in this section. These are known
as Trustworthiness Claims. These Trustworthiness Claims may be
either affirming (positive) or detracting (negative). It is these
Trustworthiness Claims which are asserted within the Attestation
Results produced by a Verifier. It is out of the scope of this
document for the Verifier to provide proof or logic on how the
assertion was derived.
Following are the set of Trustworthiness Claims defined within this
document:
+------------------------+-----------------------------+------------+
| Trustworthiness Claim | Definition | +/- |
+------------------------+-----------------------------+------------+
| hw-authentic | A Verifier has appraised an | affirming |
| | Attester as having | |
| | authentic hardware and | |
| | firmware | |
| | | |
| hw-verification-fail | A Verifier has appraised | detracting |
| | that an Attester has failed | |
| | its hardware or firmware | |
| | verification | |
| | | |
| hw-instance-recognized | A Verifier has verified an | affirming |
| | Attesting Environment's | |
| | unique identity based on | |
| | some hardware based private | |
Voit, et al. Expires October 28, 2021 [Page 8]
Internet-Draft Attestation Results April 2021
| | key signing | |
| | | |
| hw-instance-unknown | A Verifier has attempted | detracting |
| | and failed to verify an | |
| | Attesting Environment's | |
| | unique hardware protected | |
| | identity | |
| | | |
| executables-verified | A Verifier has appraised | affirming |
| | that an Attester has | |
| | installed into runtime | |
| | memory only a genuine set | |
| | of approved files during | |
| | and after boot | |
| | | |
| executables-fail | A Verifier has appraised | detracting |
| | that an Attester has | |
| | installed into runtime | |
| | memory files other than | |
| | approved files | |
| | | |
| file-system-anomaly | A Verifier has found a file | detracting |
| | on an Attester which should | |
| | not be present | |
| | | |
| config-secure | A Verifier has appraised an | affirming |
| | Attester's configuration, | |
| | and has found no security | |
| | issues | |
| | | |
| config-insecure | A Verifier has appraised an | detracting |
| | Attester's configuration, | |
| | and has found security | |
| | issues which should be | |
| | addressed | |
| | | |
| runtime-confidential | A Verifier has appraised | affirming |
| | that an Attester is opaque | |
| | to the device operator. See | |
| | O.RUNTIME_CONFIDENTIALITY | |
| | from [GP-TEE-PP]. | |
| | | |
| isolation | A Verifier has appraised an | affirming |
| | Attester has execution and | |
| | storage space which is | |
| | separated from the spaces | |
| | of any other application or | |
| | Attester. See | |
Voit, et al. Expires October 28, 2021 [Page 9]
Internet-Draft Attestation Results April 2021
| | O.TA_ISOLATION from | |
| | [GP-TEE-PP]. | |
| | | |
| secure-storage | A Verifier has appraised | affirming |
| | that an Attester has a | |
| | Trusted Execution | |
| | Environment which encrypts | |
| | persistent storage using | |
| | keys unavailable outside | |
| | protected hardware. | |
| | Protections must meet the | |
| | capabilities of [OMTP-ATE] | |
| | Section 5, but need not be | |
| | hardware tamper resistant. | |
| | | |
| source-data-integrity | A Verifier has appraised | affirming |
| | that the Attester is | |
| | operating upon data inputs | |
| | from an external Attester | |
| | having a Trustworthiness | |
| | Vector with no less than | |
| | the current Vector. | |
+------------------------+-----------------------------+------------+
Each type of Attesting Environment MUST be able to support one or
more of the set of affirming Trustworthiness Claims listed above.
Additional Trustworthiness Claims may be defined in subsequent
documents, but the goal is to minimize these Trustworthiness Claims
to just Verifier appaisals which are directly actionable by the
Relying Party.
2.3.2. Trustworthiness Vector
Multiple Trustworthiness Claims may be asserted about an Attesting
Environment at single point in time. The set of Trustworthiness
Claims inserted into an instance of Attestation Results by a Verifier
is known as a Trustworthiness Vector. The order of Claims in the
vector is NOT meaningful. A Trustworthiness Vector with no
Trustworthiness Claims (i.e., a null Trustworthiness Vector) is a
valid construct. In this case, the Verifier is making no affirming
or detracting Claims.
2.3.3. Trustworthiness Vector for a type of Attesting Environment
Some Trustworthiness Claims are implicit based on the underlying type
of Attesting Environment. Where such implicit Trustworthiness Claims
exist, they do not have to be explicitly included in the
Voit, et al. Expires October 28, 2021 [Page 10]
Internet-Draft Attestation Results April 2021
Trustworthiness Vector. However these implicit Trustworthiness
Claims SHOULD be considered as being present by the Relying Party.
Additionally, there are some Trustworthiness Claims which cannot be
adequately supported by an Attesting Environment. For example, it
would be difficult for an Attester that includes only a TPM (and no
other TEE) from ever having a Verifier appraise support for 'runtime-
confidential'. As such, a Relying Party would be acting properly, if
it rejects any non-supportable Trustworthiness Claims asserted from a
Verifier.
As a result, the need for the ability to carry a specific
Trustworthiness Claim will vary by the type of Attesting Environment.
Example mappings for SGX, Trustzone, and TPMs can be seen in
Appendix A. (This is work in progress)
2.4. Freshness
(Work needed in this Section. The intent is that all freshness
mechanisms of [I-D.ietf-rats-architecture], Section 20 will be
supported.) A Relying Party will care about the recentness of
specific Trustworthiness Claims. And a Relying Party will often
track when there is an Expiry of Verifier Confidence for the
Trustworthiness Vector itself. With connectivity related Attestation
Results, sometimes reboot will reset various Trustworthiness Claims.
In this case you don't have to worry about seeing the reboot itself
as connectivity reestablishment will refresh the recentness timers.
3. Connectivity Model
The establishment and maintenance of a connection between an Attester
and a Relying Party will follow the Passport Model from Section 5.1
of [I-D.ietf-rats-architecture]. Figure 1 describes this flow of
information using the time definitions described in
[I-D.ietf-rats-architecture]. Corresponding messages are passed
within an authentication framework, such the EAP protocol [RFC5247]
over TLS [RFC8446].
Voit, et al. Expires October 28, 2021 [Page 11]
Internet-Draft Attestation Results April 2021
.----------------.
| Attester |
| .-------------.|
| | Attesting || .----------. .---------------.
| | Environment || | Verifier | | Relying Party |
| '-------------'| | A | | / Verifier B |
'----------------' '----------' '---------------'
time(VG) | |
|<------Verifier PoF-------time(NS) |
| | |
time(EG)(1)------Evidence------------>| |
| time(RG) |
|<------Attestation Results-(2) |
~ ~ ~
time(VG')? | |
~ ~ ~
|<------Relying Party PoF-----------------(3)time(NS')
| | |
time(EG')(4)------AR-augmented Evidence----------------->|
| | time(RG',RA')(5)
(6)
~
time(RX')
Figure 1: Interaction Model
Figure 1 assumes that some form of time interval tracking is possible
between the Verifer PoF and Relying Party PoF. However, there is a
simplified case that does not require a Relying Party's PoF. In that
second variant, the Relying Party trusts that the Attester cannot be
meaningfully changed from the outside during that interval. Based on
that assumption, the Relying Party PoF can be safely omitted. In
essence, the AR-augmented Evidence is replaced by the stand-alone
Attestation Results.
In the first variant illustrated in Figure 1, a Verifier B is often
implemented as a code module within the Relying Party. In these
cases, the role Relying Party and the role Verifier are collapsed in
one entity. As a result, the entity can appraise both the
Attestation Result parts as well as the Evidence parts of AR-
augmented Evidence to determine whether an Attester qualifies for
connection to the Relying Party's resources. Appraisal policies
define the conditions and prerequisites for when an Attester
qualifies for connection. In essence, an Attester has to be able to
provide all of the mandatory affirming Trustworthiness Claims and
none of the disqualifying detracting Trustworthiness Claims.
Voit, et al. Expires October 28, 2021 [Page 12]
Internet-Draft Attestation Results April 2021
More details on each interaction step are as follows. The numbers
used match to the numbered steps in Figure 1:
1. An Attester sends Evidence which is provably fresh to Verifier A
at time(EG). Freshness from the perspective of Verifer A MAY be
established with Verifier PoF such as a nonce.
2. Verifier A appraises (1), then sends the following items back to
that Attester within Attestation Results:
1. the verified identity of the Attesting Environment,
2. the Verifier A appraised Trustworthiness Vector of an
Attester,
3. a freshness proof associated with the Attestation Results,
4. a Verifier signature across (2.1) though (2.3).
3. At time(EG') a Relying Party PoF (such as a nonce) known to the
Relying Party is sent to the Attester.
4. The Attester generates and sends AR-augmented Evidence to the
Relying Party/Verifier B. This AR-augmented Evidence includes:
1. The Attestation Results from (2)
2. Attestation Environment signing of a hash of the Attestation
Results plus the proof-of-freshness from (3). This allows
the delta of time between (2.3) and (3) to be definitively
calculated by the Relying Party.
5. On receipt of (4), the Relying Party applies its Appraisal Policy
for Attestation Results. At minimum, this appraisal policy
process must include the following:
1. Verify that (4.2) includes the nonce from (3).
2. Use a local certificate to validate the signature (4.1).
3. Verify that the hash from (4.2) matches (4.1)
4. Use the identity of (2.1) to validate the signature of (4.2).
5. Failure of any steps (5.1) through (5.4) means the link does
not meet minimum validation criteria, therefore appraise the
link as having a null Verifier B Trustworthiness Vector.
Jump to step (6.1).
Voit, et al. Expires October 28, 2021 [Page 13]
Internet-Draft Attestation Results April 2021
6. When there is large or uncertain time gap between time(EG)
and time(EG'), the link should be assigned a null Verifier B
Trustworthiness Vector. Jump to step (6.1).
7. Assemble the Verifier B Trustworthiness Vector
1. Copy Verifier A Trustworthiness Vector to Verifier B
Trustworthiness Vector
2. Add implicit Trustworthiness Claims inherent to the type
of TEE.
3. Prune any unbelieveable Trustworthiness Claims
4. Prune any Trustworthiness Claims the Relying Party
doesn't accept from this Verifier.
6. The Relying Party takes action based on Verifier B's appraised
Trustworthiness Vector:
1. Allow the information exchange from the Attester into a
Relying Party context where the Verifier B appraised
Trustworthiness Vector includes all the mandatory affirming
Trustworthiness Claims, and none of the disqualifying
detracting Trustworthiness Claims.
2. Disallow any information exchange into a Relying Party
context for which that Verifier B appraised Trustworthiness
Vector not qualified.
As link layer protocols re-authenticate, steps (1) to (2) and steps
(3) to (6) will independently refresh. This allows the
Trustworthiness of Attester to be continuously re-appraised.
Additionally, it will be common that each device on either side of a
connection will want to attest the other. This will be a process
known as multual-attestation. To support this, the process listed
above may be run independently on each side of the connection.
4. Privacy Considerations
Privacy Considerations Text
5. Security Considerations
Security Considerations Text
Voit, et al. Expires October 28, 2021 [Page 14]
Internet-Draft Attestation Results April 2021
6. IANA Considerations
See Body.
7. References
7.1. Normative References
[GP-TEE-PP]
"Global Platform TEE Protection Profile v1.3", September
2020, <https://globalplatform.org/specs-library/tee-
protection-profile-v1-3/>.
[I-D.ietf-rats-architecture]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote Attestation Procedures Architecture",
draft-ietf-rats-architecture-08 (work in progress),
December 2020.
[OMTP-ATE]
"Open Mobile Terminal Platform - Advanced Trusted
Environment", May 2009, <https://www.gsma.com/newsroom/wp-
content/uploads/2012/03/
omtpadvancedtrustedenvironmentomtptr1v11.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, DOI 10.17487/RFC5247, August 2008,
<https://www.rfc-editor.org/info/rfc5247>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
Voit, et al. Expires October 28, 2021 [Page 15]
Internet-Draft Attestation Results April 2021
[TPM-ID] "TPM Keys for Platform Identity for TPM 1.2", August 2015,
<https://www.trustedcomputinggroup.org/wp-content/uploads/
TPM_Keys_for_Platform_Identity_v1_0_r3_Final.pdf>.
Appendix A. Supportable Trustworthiness Claims
The following is a table which shows what Claims are supportable by
different Attesting Environment types. Note that claims MAY BE
implicit to an Attesting Environment type, and therefore do not have
to be included in the Trustworthiness Vector to be considered as set
by the Relying Party.
Appendix B. Supportable Trustworthiness Claims for TPMs
Following are Trustworthiness Claims which MAY be set for a TPM based
Attester.
Voit, et al. Expires October 28, 2021 [Page 16]
Internet-Draft Attestation Results April 2021
+------------------------+------------------------------------------+
| Trustworthiness Claim | TPM |
+------------------------+------------------------------------------+
| hw-authentic | If PCR check ok from BIOS checks, |
| | through Master Boot Record configuration |
| | |
| hw-verification-fail | If PCR don't check ok |
| | |
| hw-instance-recognized | Optional |
| | |
| hw-instance-unknown | Optional |
| | |
| executables-verified | If PCRs check for the static operating |
| | system, and for any tracked files |
| | subsequently loaded. |
| | |
| executables-refuted | If PCR checks fail for the static |
| | operating system, and for any tracked |
| | files subsequently loaded. |
| | |
| file-system-anomaly | Verifier evaluation of Attester reveals |
| | an unexpected file. |
| | |
| config-secure | Verifier evaluation of Attester reveals |
| | no configuration lines which expose the |
| | Attester to known security |
| | vulnerabilities. |
| | |
| config-insecure | Optional |
| | |
| runtime-confidential | TPMs do not provide a sufficient |
| | technology base for this claim. |
| | |
| isolation | This can be set only if no other |
| | applications are running on the Attester |
| | |
| secure-storage | Minimal secure storage space exists and |
| | is writeable by external applications. |
| | This space would typically just be used |
| | to store keys. |
+------------------------+------------------------------------------+
Setting the Trustworthiness Claims may follow the following logic at
the Verifier A within (2) of Figure 1:
Voit, et al. Expires October 28, 2021 [Page 17]
Internet-Draft Attestation Results April 2021
Start: Evidence received starts the generation of a new
Trustworthiness Vector. (e.g., TPM Quote Received, log received,
or appraisal timer expired)
Step 0: set Trustworthiness Vector = Null
Step 1: Is there sufficient fresh signed evidence to appraise?
(yes) - No Action
(no) - Goto Step 6
Step 2: Appraise Hardware Integrity PCRs
(if hw-verification-fail) - push onto vector, go to Step 6
else (if hw-authentic) - push onto vector
(if not evaluated, or insufficient data to conclude: take no action)
Step 3: Appraise Attesting Environment identity
(if hw-instance-recognized) - push onto vector
else (if hw-instance-unknown) - push onto vector
(if not evaluated, or insufficient data to conclude: take no action)
Step 4: Appraise executable loaded and filesystem integrity
(if executables-verified) - push onto vector
else (if executables-fail) - push onto vector, go to Step 6
(if file-system-anomaly) - push onto vector, go to Step 6
(if not evaluated, or insufficient data to conclude: take no action)
Step 5: Appraise all remaining Trustworthiness Claims and set as
appropriate.
Step 6: Assemble Attestation Results, and push to Attester
End
Appendix C. Supportable Trustworthiness Claims for SGX Enclaves
Voit, et al. Expires October 28, 2021 [Page 18]
Internet-Draft Attestation Results April 2021
+------------------------+------------------------------+
| Trustworthiness Claim | SGX |
+------------------------+------------------------------+
| hw-authentic | Implicit in signature |
| | |
| hw-verification-fail | Implicit if signature not ok |
| | |
| hw-instance-recognized | Optional |
| | |
| hw-instance-unknown | Optional |
| | |
| executables-verified | Optional |
| | |
| executables-refuted | Optional |
| | |
| file-system-anomaly | Optional |
| | |
| config-secure | Optional |
| | |
| config-insecure | Optional |
| | |
| runtime-confidential | Implicit in signature |
| | |
| isolation | Implicit in signature |
| | |
| secure-storage | Implicit in signature |
+------------------------+------------------------------+
Appendix D. Supportable Trustworthiness Claims for TrustZone
Voit, et al. Expires October 28, 2021 [Page 19]
Internet-Draft Attestation Results April 2021
+------------------------+------------------------------+
| Trustworthiness Claim | TrustZone |
+------------------------+------------------------------+
| hw-authentic | Implicit in signature |
| | |
| hw-verification-fail | Implicit if signature not ok |
| | |
| hw-instance-recognized | ? |
| | |
| hw-instance-unknown | ? |
| | |
| executables-verified | Optional |
| | |
| executables-refuted | Optional |
| | |
| file-system-anomaly | Optional |
| | |
| config-secure | Optional |
| | |
| config-insecure | Optional |
| | |
| runtime-confidential | (?) |
| | |
| isolation | Implicit in signature |
| | |
| secure-storage | Implicit in signature |
+------------------------+------------------------------+
Appendix E. Some issues being worked
It is possible for a cluster/hierarchy of Verifiers to have aggregate
AR which are perhaps signed/endorsed by a lead Verifier. What should
be the Proof-of-Freshness or Verifier associated with any of the
aggregate set of Trustworthiness Claims?
There will need to be a subsequent document which documents how these
objects which will be translated into a protocol on a wire (e.g. EAP
on TLS). Some breakpoint between what is in this draft, and what is
in specific drafts for wire encoding will need to be determined.
Questions like architecting the cluster/hierarchy of Verifiers fall
into this breakdown.
For Trustworthiness Claims such as "exectables verified", there could
be value in identifying a specific Appraisal Policy for Attestation
Results applied. One way this could be done would be a URI which
identifies this policy. As the URI also could encode the version of
the software, it might also act as a mechanism to signal the Relying
Party to refresh/re-evaluate its view of Verifier A.
Voit, et al. Expires October 28, 2021 [Page 20]
Internet-Draft Attestation Results April 2021
Expand the variant of Figure 1 which requires no Relying Party PoF
into its own picture.
Appendix F. Contributors
Guy Fedorkow
Email: gfedorkow@juniper.net
Authors' Addresses
Eric Voit
Cisco Systems
Email: evoit@cisco.com
Henk Birkholz
Fraunhofer SIT
Rheinstrasse 75
Darmstadt 64295
Germany
Email: henk.birkholz@sit.fraunhofer.de
Thomas Hardjono
MIT
Email: hardjono@mit.edu
Thomas Fossati
Arm Limited
Email: Thomas.Fossati@arm.com
Vincent Scarlata
Intel
Email: vincent.r.scarlata@intel.com
Voit, et al. Expires October 28, 2021 [Page 21]