draft-ietf-rats-architecture-14.txt   draft-ietf-rats-architecture-15.txt 
RATS Working Group H. Birkholz RATS Working Group H. Birkholz
Internet-Draft Fraunhofer SIT Internet-Draft Fraunhofer SIT
Intended status: Informational D. Thaler Intended status: Informational D. Thaler
Expires: 12 June 2022 Microsoft Expires: 12 August 2022 Microsoft
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
N. Smith N. Smith
Intel Intel
W. Pan W. Pan
Huawei Technologies Huawei Technologies
9 December 2021 8 February 2022
Remote Attestation Procedures Architecture Remote Attestation Procedures Architecture
draft-ietf-rats-architecture-14 draft-ietf-rats-architecture-15
Abstract Abstract
In network protocol exchanges it is often useful for one end of a In network protocol exchanges it is often useful for one end of a
communication to know whether the other end is in an intended communication to know whether the other end is in an intended
operating state. This document provides an architectural overview of operating state. This document provides an architectural overview of
the entities involved that make such tests possible through the the entities involved that make such tests possible through the
process of generating, conveying, and evaluating evidentiary claims. process of generating, conveying, and evaluating evidentiary claims.
An attempt is made to provide for a model that is neutral toward An attempt is made to provide for a model that is neutral toward
processor architectures, the content of claims, and protocols. processor architectures, the content of claims, and protocols.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 June 2022. This Internet-Draft will expire on 12 August 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 5 2. Reference Use Cases . . . . . . . . . . . . . . . . . . . . . 5
2.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 5 2.1. Network Endpoint Assessment . . . . . . . . . . . . . . . 5
2.2. Confidential Machine Learning Model Protection . . . . . 5 2.2. Confidential Machine Learning Model Protection . . . . . 6
2.3. Confidential Data Protection . . . . . . . . . . . . . . 6 2.3. Confidential Data Protection . . . . . . . . . . . . . . 6
2.4. Critical Infrastructure Control . . . . . . . . . . . . . 6 2.4. Critical Infrastructure Control . . . . . . . . . . . . . 6
2.5. Trusted Execution Environment Provisioning . . . . . . . 7 2.5. Trusted Execution Environment Provisioning . . . . . . . 7
2.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 7 2.6. Hardware Watchdog . . . . . . . . . . . . . . . . . . . . 7
2.7. FIDO Biometric Authentication . . . . . . . . . . . . . . 7 2.7. FIDO Biometric Authentication . . . . . . . . . . . . . . 8
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8
3.1. Two Types of Environments of an Attester . . . . . . . . 9 3.1. Two Types of Environments of an Attester . . . . . . . . 10
3.2. Layered Attestation Environments . . . . . . . . . . . . 11 3.2. Layered Attestation Environments . . . . . . . . . . . . 12
3.3. Composite Device . . . . . . . . . . . . . . . . . . . . 13 3.3. Composite Device . . . . . . . . . . . . . . . . . . . . 14
3.4. Implementation Considerations . . . . . . . . . . . . . . 15 3.4. Implementation Considerations . . . . . . . . . . . . . . 16
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Topological Patterns . . . . . . . . . . . . . . . . . . . . 18 5. Topological Patterns . . . . . . . . . . . . . . . . . . . . 19
5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 18 5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 19
5.2. Background-Check Model . . . . . . . . . . . . . . . . . 20 5.2. Background-Check Model . . . . . . . . . . . . . . . . . 21
5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 21 5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 22
6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 22 6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 23
7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 23 7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Attester . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2. Attester . . . . . . . . . . . . . . . . . . . . . . . . 25
7.3. Relying Party Owner . . . . . . . . . . . . . . . . . . . 24 7.3. Relying Party Owner . . . . . . . . . . . . . . . . . . . 25
7.4. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 25 7.4. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 26
7.5. Endorser, Reference Value Provider, and Verifier Owner . 27 7.5. Endorser, Reference Value Provider, and Verifier Owner . 28
8. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 27 8. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 28
8.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 28
8.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 29
8.3. Reference Values . . . . . . . . . . . . . . . . . . . . 28 8.3. Reference Values . . . . . . . . . . . . . . . . . . . . 29
8.4. Attestation Results . . . . . . . . . . . . . . . . . . . 28 8.4. Attestation Results . . . . . . . . . . . . . . . . . . . 29
8.5. Appraisal Policies . . . . . . . . . . . . . . . . . . . 30 8.5. Appraisal Policies . . . . . . . . . . . . . . . . . . . 31
9. Claims Encoding Formats . . . . . . . . . . . . . . . . . . . 30 9. Claims Encoding Formats . . . . . . . . . . . . . . . . . . . 31
10. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Explicit Timekeeping using Synchronized Clocks . . . . . 32 10.1. Explicit Timekeeping using Synchronized Clocks . . . . . 33
10.2. Implicit Timekeeping using Nonces . . . . . . . . . . . 33 10.2. Implicit Timekeeping using Nonces . . . . . . . . . . . 34
10.3. Implicit Timekeeping using Epoch IDs . . . . . . . . . . 33 10.3. Implicit Timekeeping using Epoch IDs . . . . . . . . . . 34
10.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 34 10.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 35
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36
12. Security Considerations . . . . . . . . . . . . . . . . . . . 36 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
12.1. Attester and Attestation Key Protection . . . . . . . . 36 12.1. Attester and Attestation Key Protection . . . . . . . . 37
12.1.1. On-Device Attester and Key Protection . . . . . . . 36 12.1.1. On-Device Attester and Key Protection . . . . . . . 37
12.1.2. Attestation Key Provisioning Processes . . . . . . . 37 12.1.2. Attestation Key Provisioning Processes . . . . . . . 38
12.2. Integrity Protection . . . . . . . . . . . . . . . . . . 38 12.2. Integrity Protection . . . . . . . . . . . . . . . . . . 39
12.3. Epoch ID-based Attestation . . . . . . . . . . . . . . . 39 12.3. Epoch ID-based Attestation . . . . . . . . . . . . . . . 40
12.4. Trust Anchor Protection . . . . . . . . . . . . . . . . 40 12.4. Trust Anchor Protection . . . . . . . . . . . . . . . . 41
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
15. Notable Contributions . . . . . . . . . . . . . . . . . . . . 40 15. Notable Contributions . . . . . . . . . . . . . . . . . . . . 42
16. Appendix A: Time Considerations . . . . . . . . . . . . . . . 41 16. Appendix A: Time Considerations . . . . . . . . . . . . . . . 42
16.1. Example 1: Timestamp-based Passport Model Example . . . 42 16.1. Example 1: Timestamp-based Passport Model Example . . . 44
16.2. Example 2: Nonce-based Passport Model Example . . . . . 44 16.2. Example 2: Nonce-based Passport Model Example . . . . . 45
16.3. Example 3: Epoch ID-based Passport Model Example . . . . 45 16.3. Example 3: Epoch ID-based Passport Model Example . . . . 46
16.4. Example 4: Timestamp-based Background-Check Model 16.4. Example 4: Timestamp-based Background-Check Model
Example . . . . . . . . . . . . . . . . . . . . . . . . 46 Example . . . . . . . . . . . . . . . . . . . . . . . . 47
16.5. Example 5: Nonce-based Background-Check Model Example . 47 16.5. Example 5: Nonce-based Background-Check Model Example . 48
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
17.1. Normative References . . . . . . . . . . . . . . . . . . 48 17.1. Normative References . . . . . . . . . . . . . . . . . . 49
17.2. Informative References . . . . . . . . . . . . . . . . . 48 17.2. Informative References . . . . . . . . . . . . . . . . . 49
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
The question of how one system can know that another system can be The question of how one system can know that another system can be
trusted has found new interest and relevance in a world where trusted trusted has found new interest and relevance in a world where trusted
computing elements are maturing in processor architectures. computing elements are maturing in processor architectures.
Systems that have been attested and verified to be in a good state Systems that have been attested and verified to be in a good state
(for some value of "good") can improve overall system posture. (for some value of "good") can improve overall system posture.
Conversely, systems that cannot be attested and verified to be in a Conversely, systems that cannot be attested and verified to be in a
skipping to change at page 5, line 33 skipping to change at page 5, line 33
attached to their network. Examples of reports include purposes, attached to their network. Examples of reports include purposes,
such as inventory summaries, audit results, anomaly notifications, such as inventory summaries, audit results, anomaly notifications,
typically including the maintenance of log records or trend reports. typically including the maintenance of log records or trend reports.
The network operator may also want a policy by which full access is The network operator may also want a policy by which full access is
only granted to devices that meet some definition of hygiene, and so only granted to devices that meet some definition of hygiene, and so
wants to get Claims about such information and verify its validity. wants to get Claims about such information and verify its validity.
Remote attestation is desired to prevent vulnerable or compromised Remote attestation is desired to prevent vulnerable or compromised
devices from getting access to the network and potentially harming devices from getting access to the network and potentially harming
others. others.
Typically, solutions start with a specific component (called a root Typically, a trustworthy solution starts with a specific component
of trust) that is intended to provide trustworthy device identity and (sometimes referred to as a root of trust) that often provides
protected storage for measurements. The system components perform a trustworthy device identity, and performs a series of operations that
series of measurements that may be signed via functions provided by a enables trustworthiness appraisals for other components. Such
root of trust, considered as Evidence about present system components perform operations that help determine the trustworthiness
components, such as hardware, firmware, BIOS, software, etc. of yet other components, by collecting, protecting or signing
measurements. Measurements that have been signed by such components
comprise Evidence that when evaluated either supports or refutes a
claim of trustworthiness. Measurements can describe a variety of
attributes of system components, such as hardware, firmware, BIOS,
software, etc.
Attester: A device desiring access to a network. Attester: A device desiring access to a network.
Relying Party: Network equipment such as a router, switch, or access Relying Party: Network equipment such as a router, switch, or access
point, responsible for admission of the device into the network. point, responsible for admission of the device into the network.
2.2. Confidential Machine Learning Model Protection 2.2. Confidential Machine Learning Model Protection
A device manufacturer wants to protect its intellectual property. A device manufacturer wants to protect its intellectual property.
The intellectual property's scope primarily encompasses the machine The intellectual property's scope primarily encompasses the machine
skipping to change at page 9, line 6 skipping to change at page 9, line 34
| Evidence | | | Evidence | |
| | | | | |
| v v | v v
.----------. .---------------. .----------. .---------------.
| Attester | | Relying Party | | Attester | | Relying Party |
'----------' '---------------' '----------' '---------------'
Figure 1: Conceptual Data Flow Figure 1: Conceptual Data Flow
The text below summarizes the activities conducted by the roles The text below summarizes the activities conducted by the roles
illustrated in Figure 1. illustrated in Figure 1. Roles are assigned to entities. Entities
are often system components [RFC4949], such as devices. As the term
device is typically more intuitive than the term entity or system
component, device is often used as a illustrative synonym throughout
this document.
An Attester creates Evidence that is conveyed to a Verifier. The Attester role is assigned to entities that create Evidence that
is conveyed to a Verifier.
A Verifier uses the Evidence, any Reference Values from Reference The Verifier role is assigned to entities that use the Evidence, any
Value Providers, and any Endorsements from Endorsers, by applying an Reference Values from Reference Value Providers, and any Endorsements
Appraisal Policy for Evidence to assess the trustworthiness of the from Endorsers, by applying an Appraisal Policy for Evidence to
Attester. This procedure is called the appraisal of Evidence. assess the trustworthiness of the Attester. This procedure is called
the appraisal of Evidence.
Subsequently, the Verifier generates Attestation Results for use by Subsequently, the Verifier role generates Attestation Results for use
Relying Parties. by Relying Parties.
The Appraisal Policy for Evidence might be obtained from the Verifier The Appraisal Policy for Evidence might be obtained from the Verifier
Owner via some protocol mechanism, or might be configured into the Owner via some protocol mechanism, or might be configured into the
Verifier by the Verifier Owner, or might be programmed into the Verifier by the Verifier Owner, or might be programmed into the
Verifier, or might be obtained via some other mechanism. Verifier, or might be obtained via some other mechanism.
A Relying Party uses Attestation Results by applying its own The Relying Party role is assigned to entities that uses Attestation
appraisal policy to make application-specific decisions, such as Results by applying its own appraisal policy to make application-
authorization decisions. This procedure is called the appraisal of specific decisions, such as authorization decisions. This procedure
Attestation Results. is called the appraisal of Attestation Results.
The Appraisal Policy for Attestation Results might be obtained from The Appraisal Policy for Attestation Results might be obtained from
the Relying Party Owner via some protocol mechanism, or might be the Relying Party Owner via some protocol mechanism, or might be
configured into the Relying Party by the Relying Party Owner, or configured into the Relying Party by the Relying Party Owner, or
might be programmed into the Relying Party, or might be obtained via might be programmed into the Relying Party, or might be obtained via
some other mechanism. some other mechanism.
See Section 8 for further discussion of the conceptual messages shown See Section 8 for further discussion of the conceptual messages shown
in Figure 1. in Figure 1. Section Section 4 provides a more complete definition
of all RATS roles.
3.1. Two Types of Environments of an Attester 3.1. Two Types of Environments of an Attester
As shown in Figure 2, an Attester consists of at least one Attesting As shown in Figure 2, an Attester consists of at least one Attesting
Environment and at least one Target Environment. In some Environment and at least one Target Environment co-located in one
implementations, the Attesting and Target Environments might be entity. In some implementations, the Attesting and Target
combined. Other implementations might have multiple Attesting and Environments might be combined into one environment. Other
Target Environments, such as in the examples described in more detail implementations might have multiple Attesting and Target
in Section 3.2 and Section 3.3. Other examples may exist. All Environments, such as in the examples described in more detail in
Section 3.2 and Section 3.3. Other examples may exist. All
compositions of Attesting and Target Environments discussed in this compositions of Attesting and Target Environments discussed in this
architecture can be combined into more complex implementations. architecture can be combined into more complex implementations.
.--------------------------------. .--------------------------------.
| | | |
| Verifier | | Verifier |
| | | |
'--------------------------------' '--------------------------------'
^ ^
| |
skipping to change at page 11, line 12 skipping to change at page 12, line 12
collection are referred to in this document as Attesting collection are referred to in this document as Attesting
Environments. For example, a TPM doesn't actively collect Claims Environments. For example, a TPM doesn't actively collect Claims
itself, it instead requires another component to feed various values itself, it instead requires another component to feed various values
to the TPM. Thus, an Attesting Environment in such a case would be to the TPM. Thus, an Attesting Environment in such a case would be
the combination of the TPM together with whatever component is the combination of the TPM together with whatever component is
feeding it the measurements. feeding it the measurements.
3.2. Layered Attestation Environments 3.2. Layered Attestation Environments
By definition, the Attester role generates Evidence. An Attester may By definition, the Attester role generates Evidence. An Attester may
consist of one or more nested environments (layers). The root layer consist of one or more nested environments (layers). The bottom
of an Attester includes at least one root of trust. In order to layer of an Attester has an Attesting Environment that is typically
appraise Evidence generated by an Attester, the Verifier needs to designed to be immutable or difficult to modify by malicious code.
trust the Attester's root of trust. Trust in the Attester's root of In order to appraise Evidence generated by an Attester, the Verifier
trust can be established in various ways as discussed in Section 7.4. needs to trust various layers, including the bottom Attesting
Environment. Trust in the Attester's layers, including the bottom
layer, can be established in various ways as discussed in
Section 7.4.
In layered attestation, a root of trust is the initial Attesting In layered attestation, Claims can be collected from or about each
Environment. Claims can be collected from or about each layer. The layer beginning with an initial layer. The corresponding Claims can
corresponding Claims can be structured in a nested fashion that be structured in a nested fashion that reflects the nesting of the
reflects the nesting of the Attester's layers. Normally, Claims are Attester's layers. Normally, Claims are not self-asserted, rather a
not self-asserted, rather a previous layer acts as the Attesting previous layer acts as the Attesting Environment for the next layer.
Environment for the next layer. Claims about a root of trust Claims about an initial layer typically are asserted by an Endorser.
typically are asserted by an Endorser.
The example device illustrated in Figure 3 includes (A) a BIOS stored The example device illustrated in Figure 3 includes (A) a BIOS stored
in read-only memory, (B) a bootloader, and (C) an operating system in read-only memory, (B) a bootloader, and (C) an operating system
kernel. kernel.
.-------------. Endorsement for ROM .-------------. Endorsement for ROM
| Endorser |-----------------------. | Endorser |-----------------------.
'-------------' | '-------------' |
v v
.-------------. Reference .----------. .-------------. Reference .----------.
skipping to change at page 13, line 5 skipping to change at page 14, line 5
| | ROM | | | | ROM | |
| | | | | | | |
| | Attesting | | | | Attesting | |
| | Environment | | | | Environment | |
| '---------------------------' | | '---------------------------' |
| | | |
'------------------------------------' '------------------------------------'
Figure 3: Layered Attester Figure 3: Layered Attester
The first Attesting Environment, the read-only BIOS in this example, The first Attesting Environment, the ROM in this example, has to
has to ensure the integrity of the bootloader (the first Target ensure the integrity of the bootloader (the first Target
Environment). There are potentially multiple kernels to boot, and Environment). There are potentially multiple kernels to boot, and
the decision is up to the bootloader. Only a bootloader with intact the decision is up to the bootloader. Only a bootloader with intact
integrity will make an appropriate decision. Therefore, the Claims integrity will make an appropriate decision. Therefore, the Claims
relating to the integrity of the bootloader have to be measured relating to the integrity of the bootloader have to be measured
securely. At this stage of the boot-cycle of the device, the Claims securely. At this stage of the boot-cycle of the device, the Claims
collected typically cannot be composed into Evidence. collected typically cannot be composed into Evidence.
After the boot sequence is started, the BIOS conducts the most After the boot sequence is started, the BIOS conducts the most
important and defining feature of layered attestation, which is that important and defining feature of layered attestation, which is that
the successfully measured bootloader now becomes (or contains) an the successfully measured bootloader now becomes (or contains) an
skipping to change at page 23, line 27 skipping to change at page 24, line 27
Verifier that can appraise the trustworthiness of information about Verifier that can appraise the trustworthiness of information about
an Attester. Such trust is expressed by storing one or more "trust an Attester. Such trust is expressed by storing one or more "trust
anchors" in a secure location known as a trust anchor store. anchors" in a secure location known as a trust anchor store.
As defined in [RFC6024], "A trust anchor represents an authoritative As defined in [RFC6024], "A trust anchor represents an authoritative
entity via a public key and associated data. The public key is used entity via a public key and associated data. The public key is used
to verify digital signatures, and the associated data is used to to verify digital signatures, and the associated data is used to
constrain the types of information for which the trust anchor is constrain the types of information for which the trust anchor is
authoritative." The trust anchor may be a certificate or it may be a authoritative." The trust anchor may be a certificate or it may be a
raw public key along with additional data if necessary such as its raw public key along with additional data if necessary such as its
public key algorithm and parameters. public key algorithm and parameters. In the context of this
document, a trust anchor may also be a symmetric key, as in
[TCG-DICE-SIBDA] or the symmetric mode described in
[I-D.tschofenig-rats-psa-token].
Thus, trusting a Verifier might be expressed by having the Relying Thus, trusting a Verifier might be expressed by having the Relying
Party store the Verifier's public key or certificate in its trust Party store the Verifier's key or certificate in its trust anchor
anchor store, or might be expressed by storing the public key or store, or might be expressed by storing the public key or certificate
certificate of an entity (e.g., a Certificate Authority) that is in of an entity (e.g., a Certificate Authority) that is in the
the Verifier's certificate path. For example, the Relying Party can Verifier's certificate path. For example, the Relying Party can
verify that the Verifier is an expected one by out of band verify that the Verifier is an expected one by out of band
establishment of key material, combined with a protocol like TLS to establishment of key material, combined with a protocol like TLS to
communicate. There is an assumption that between the establishment communicate. There is an assumption that between the establishment
of the trusted key material and the creation of the Evidence, that of the trusted key material and the creation of the Evidence, that
the Verifier has not been compromised. the Verifier has not been compromised.
For a stronger level of security, the Relying Party might require For a stronger level of security, the Relying Party might require
that the Verifier first provide information about itself that the that the Verifier first provide information about itself that the
Relying Party can use to assess the trustworthiness of the Verifier Relying Party can use to assess the trustworthiness of the Verifier
before accepting its Attestation Results. Such process would provide before accepting its Attestation Results. Such process would provide
skipping to change at page 26, line 43 skipping to change at page 27, line 43
1. The key material used to authenticate and integrity protect the 1. The key material used to authenticate and integrity protect the
conveyance channel is trusted by the Verifier to speak for the conveyance channel is trusted by the Verifier to speak for the
Attesting Environment(s) that collected Claims about the Target Attesting Environment(s) that collected Claims about the Target
Environment(s). Environment(s).
2. All unprotected Evidence that is conveyed is supplied exclusively 2. All unprotected Evidence that is conveyed is supplied exclusively
by the Attesting Environment that has the key material that by the Attesting Environment that has the key material that
protects the conveyance channel protects the conveyance channel
3. The root of trust protects both the conveyance channel key 3. A trusted environment protects the conveyance channel's key
material and the Attesting Environment with equivalent strength material which may depend on other Attesting Environments with
protections. equivalent strength protections.
As illustrated in [I-D.birkholz-rats-uccs], an entity that receives As illustrated in [I-D.birkholz-rats-uccs], an entity that receives
unprotected Evidence via a trusted conveyance channel always takes on unprotected Evidence via a trusted conveyance channel always takes on
the responsibility of vouching for the Evidence's authenticity and the responsibility of vouching for the Evidence's authenticity and
freshness. If protected Evidence is generated, the Attester's freshness. If protected Evidence is generated, the Attester's
Attesting Environments take on that responsibility. In cases where Attesting Environments take on that responsibility. In cases where
unprotected Evidence is processed by a Verifier, Relying Parties have unprotected Evidence is processed by a Verifier, Relying Parties have
to trust that the Verifier is capable of handling Evidence in a to trust that the Verifier is capable of handling Evidence in a
manner that preserves the Evidence's authenticity and freshness. manner that preserves the Evidence's authenticity and freshness.
Generating and conveying unprotected Evidence always creates Generating and conveying unprotected Evidence always creates
skipping to change at page 32, line 10 skipping to change at page 33, line 10
'--------------' `-------------------' '--------------' `-------------------'
Figure 9: Multiple Attesters and Relying Parties with Different Figure 9: Multiple Attesters and Relying Parties with Different
Formats Formats
10. Freshness 10. Freshness
A Verifier or Relying Party might need to learn the point in time A Verifier or Relying Party might need to learn the point in time
(i.e., the "epoch") an Evidence or Attestation Result has been (i.e., the "epoch") an Evidence or Attestation Result has been
produced. This is essential in deciding whether the included Claims produced. This is essential in deciding whether the included Claims
and their values can be considered fresh, meaning they still reflect can be considered fresh, meaning they still reflect the latest state
the latest state of the Attester, and that any Attestation Result was of the Attester, and that any Attestation Result was generated using
generated using the latest Appraisal Policy for Evidence. the latest Appraisal Policy for Evidence.
This section provides a number of details. It does not however This section provides a number of details. It does not however
define any protocol formats, the interactions shown are abstract. define any protocol formats, the interactions shown are abstract.
This section is intended for those creating protocols and solutions This section is intended for those creating protocols and solutions
to understand the options available to ensure freshness. The way in to understand the options available to ensure freshness. The way in
which freshness is provisioned in a protocol is an architectural which freshness is provisioned in a protocol is an architectural
decision. Provisioning of freshness has an impact on the number of decision. Provisioning of freshness has an impact on the number of
needed round trips in a protocol, and therefore must be made very needed round trips in a protocol, and therefore must be made very
early in the design. Different decisions will have significant early in the design. Different decisions will have significant
impacts on resulting interoperability, which is why this section goes impacts on resulting interoperability, which is why this section goes
skipping to change at page 36, line 8 skipping to change at page 37, line 8
Verifiers. Some Attesters might want a stronger level of assurance Verifiers. Some Attesters might want a stronger level of assurance
of the trustworthiness of a Verifier before sending Evidence to it. of the trustworthiness of a Verifier before sending Evidence to it.
In such cases, an Attester can first act as a Relying Party and ask In such cases, an Attester can first act as a Relying Party and ask
for the Verifier's own Attestation Result, and appraising it just as for the Verifier's own Attestation Result, and appraising it just as
a Relying Party would appraise an Attestation Result for any other a Relying Party would appraise an Attestation Result for any other
purpose. purpose.
Another approach to deal with Evidence is to remove PII from the Another approach to deal with Evidence is to remove PII from the
Evidence while still being able to verify that the Attester is one of Evidence while still being able to verify that the Attester is one of
a large set. This approach is often called "Direct Anonymous a large set. This approach is often called "Direct Anonymous
Attestation". See [CCC-DeepDive] section 6.2 for more discussion. Attestation". See [CCC-DeepDive] section 6.2 and [I-D.ietf-rats-daa]
for more discussion.
12. Security Considerations 12. Security Considerations
This document provides an architecture for doing remote attestation. This document provides an architecture for doing remote attestation.
No specific wire protocol is documented here. Without a specific No specific wire protocol is documented here. Without a specific
proposal to compare against, it is impossible to know if the security proposal to compare against, it is impossible to know if the security
threats listed below have been mitigated well. threats listed below have been mitigated well.
The security considerations below should be read as being essentially The security considerations below should be read as being essentially
requirements against realizations of the RATS Architecture. Some requirements against realizations of the RATS Architecture. Some
skipping to change at page 40, line 26 skipping to change at page 41, line 26
been compromised. been compromised.
Reordering and dropping attacks are mitigated if the transport Reordering and dropping attacks are mitigated if the transport
provides the ability to detect reordering and drop. However, the provides the ability to detect reordering and drop. However, the
delay attack described above can't be thwarted in this manner. delay attack described above can't be thwarted in this manner.
12.4. Trust Anchor Protection 12.4. Trust Anchor Protection
As noted in Section 7, Verifiers and Relying Parties have trust As noted in Section 7, Verifiers and Relying Parties have trust
anchor stores that must be secured. [RFC6024] contains more anchor stores that must be secured. [RFC6024] contains more
discussion of trust anchor store requirements. Specifically, a trust discussion of trust anchor store requirements for protecting public
anchor store must resist modification against unauthorized insertion, keys. Section 6 of [NIST-800-57-p1] contains a comprehensive
deletion, and modification. treatment of the topic, including the protection of symmetric key
material. Specifically, a trust anchor store must resist
modification against unauthorized insertion, deletion, and
modification. Additionally, if the trust anchor is a symmetric key,
the trust anchor store must not allow unauthorized read.
If certificates are used as trust anchors, Verifiers and Relying If certificates are used as trust anchors, Verifiers and Relying
Parties are also responsible for validating the entire certificate Parties are also responsible for validating the entire certificate
path up to the trust anchor, which includes checking for certificate path up to the trust anchor, which includes checking for certificate
revocation. See Section 6 of [RFC5280] for details. revocation. See Section 6 of [RFC5280] for details.
13. IANA Considerations 13. IANA Considerations
This document does not require any actions by IANA. This document does not require any actions by IANA.
skipping to change at page 49, line 8 skipping to change at page 50, line 8
<https://confidentialcomputing.io/whitepaper-02-latest>. <https://confidentialcomputing.io/whitepaper-02-latest>.
[CTAP] FIDO Alliance, "Client to Authenticator Protocol", n.d., [CTAP] FIDO Alliance, "Client to Authenticator Protocol", n.d.,
<https://fidoalliance.org/specs/fido-v2.0-id-20180227/ <https://fidoalliance.org/specs/fido-v2.0-id-20180227/
fido-client-to-authenticator-protocol-v2.0-id- fido-client-to-authenticator-protocol-v2.0-id-
20180227.html>. 20180227.html>.
[I-D.birkholz-rats-tuda] [I-D.birkholz-rats-tuda]
Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann, Fuchs, A., Birkholz, H., McDonald, I. E., and C. Bormann,
"Time-Based Uni-Directional Attestation", Work in "Time-Based Uni-Directional Attestation", Work in
Progress, Internet-Draft, draft-birkholz-rats-tuda-05, 12 Progress, Internet-Draft, draft-birkholz-rats-tuda-06, 12
July 2021, <https://www.ietf.org/archive/id/draft- January 2022, <https://www.ietf.org/archive/id/draft-
birkholz-rats-tuda-05.txt>. birkholz-rats-tuda-06.txt>.
[I-D.birkholz-rats-uccs] [I-D.birkholz-rats-uccs]
Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C. Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
Bormann, "A CBOR Tag for Unprotected CWT Claims Sets", Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",
Work in Progress, Internet-Draft, draft-birkholz-rats- Work in Progress, Internet-Draft, draft-birkholz-rats-
uccs-03, 8 March 2021, <https://www.ietf.org/archive/id/ uccs-03, 8 March 2021, <https://www.ietf.org/archive/id/
draft-birkholz-rats-uccs-03.txt>. draft-birkholz-rats-uccs-03.txt>.
[I-D.ietf-rats-daa]
Birkholz, H., Newton, C., Chen, L., and D. Thaler, "Direct
Anonymous Attestation for the Remote Attestation
Procedures Architecture", Work in Progress, Internet-
Draft, draft-ietf-rats-daa-00, 2 December 2021,
<https://www.ietf.org/archive/id/draft-ietf-rats-daa-
00.txt>.
[I-D.ietf-teep-architecture] [I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
"Trusted Execution Environment Provisioning (TEEP) "Trusted Execution Environment Provisioning (TEEP)
Architecture", Work in Progress, Internet-Draft, draft- Architecture", Work in Progress, Internet-Draft, draft-
ietf-teep-architecture-15, 12 July 2021, ietf-teep-architecture-15, 12 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-teep- <https://www.ietf.org/archive/id/draft-ietf-teep-
architecture-15.txt>. architecture-15.txt>.
[I-D.tschofenig-rats-psa-token]
Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T.
Fossati, "Arm's Platform Security Architecture (PSA)
Attestation Token", Work in Progress, Internet-Draft,
draft-tschofenig-rats-psa-token-08, 24 March 2021,
<https://www.ietf.org/archive/id/draft-tschofenig-rats-
psa-token-08.txt>.
[I-D.tschofenig-tls-cwt] [I-D.tschofenig-tls-cwt]
Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens
(CWTs) in Transport Layer Security (TLS) and Datagram (CWTs) in Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS)", Work in Progress, Transport Layer Security (DTLS)", Work in Progress,
Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020, Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020,
<https://www.ietf.org/archive/id/draft-tschofenig-tls-cwt- <https://www.ietf.org/archive/id/draft-tschofenig-tls-cwt-
02.txt>. 02.txt>.
[NIST-800-57-p1]
Barker, E., "Recommendation for Key Managemement: Part 1 -
General", May 2020,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-57pt1r5.pdf>.
[OPCUA] OPC Foundation, "OPC Unified Architecture Specification, [OPCUA] OPC Foundation, "OPC Unified Architecture Specification,
Part 2: Security Model, Release 1.03", OPC 10000-2 , 25 Part 2: Security Model, Release 1.03", OPC 10000-2 , 25
November 2015, <https://opcfoundation.org/developer-tools/ November 2015, <https://opcfoundation.org/developer-tools/
specifications-unified-architecture/part-2-security- specifications-unified-architecture/part-2-security-
model/>. model/>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
skipping to change at page 50, line 29 skipping to change at page 52, line 5
[strengthoffunction] [strengthoffunction]
NISC, "Strength of Function", n.d., NISC, "Strength of Function", n.d.,
<https://csrc.nist.gov/glossary/term/ <https://csrc.nist.gov/glossary/term/
strength_of_function>. strength_of_function>.
[TCG-DICE] Trusted Computing Group, "DICE Certificate Profiles", [TCG-DICE] Trusted Computing Group, "DICE Certificate Profiles",
n.d., <https://trustedcomputinggroup.org/wp- n.d., <https://trustedcomputinggroup.org/wp-
content/uploads/DICE-Certificate-Profiles- content/uploads/DICE-Certificate-Profiles-
r01_3june2020-1.pdf>. r01_3june2020-1.pdf>.
[TCG-DICE-SIBDA]
Trusted Computing Group, "Symmetric Identity Based Device
Attestation for DICE", 24 July 2019,
<https://trustedcomputinggroup.org/wp-content/uploads/
TCG_DICE_SymIDAttest_v1_r0p94_pubrev.pdf>.
[TCGarch] Trusted Computing Group, "Trusted Platform Module Library [TCGarch] Trusted Computing Group, "Trusted Platform Module Library
- Part 1: Architecture", 8 November 2019, - Part 1: Architecture", 8 November 2019,
<https://trustedcomputinggroup.org/wp-content/uploads/ <https://trustedcomputinggroup.org/wp-content/uploads/
TCG_TPM2_r1p59_Part1_Architecture_pub.pdf>. TCG_TPM2_r1p59_Part1_Architecture_pub.pdf>.
[WebAuthN] W3C, "Web Authentication: An API for accessing Public Key [WebAuthN] W3C, "Web Authentication: An API for accessing Public Key
Credentials", n.d., <https://www.w3.org/TR/webauthn-1/>. Credentials", n.d., <https://www.w3.org/TR/webauthn-1/>.
Contributors Contributors
 End of changes. 31 change blocks. 
115 lines changed or deleted 166 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/