draft-ietf-rats-architecture-13.txt   draft-ietf-rats-architecture-14.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 May 2022 Microsoft Expires: 12 June 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
8 November 2021 9 December 2021
Remote Attestation Procedures Architecture Remote Attestation Procedures Architecture
draft-ietf-rats-architecture-13 draft-ietf-rats-architecture-14
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 May 2022. This Internet-Draft will expire on 12 June 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 Simplified BSD License text extracted from this document must include Revised BSD License text as
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 Simplified 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 . . . . . 5
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 . . . . . . . . . . . . . . 7
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8 3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8
3.1. Two Types of Environments of an Attester . . . . . . . . 10 3.1. Two Types of Environments of an Attester . . . . . . . . 9
3.2. Layered Attestation Environments . . . . . . . . . . . . 12 3.2. Layered Attestation Environments . . . . . . . . . . . . 11
3.3. Composite Device . . . . . . . . . . . . . . . . . . . . 14 3.3. Composite Device . . . . . . . . . . . . . . . . . . . . 13
3.4. Implementation Considerations . . . . . . . . . . . . . . 16 3.4. Implementation Considerations . . . . . . . . . . . . . . 15
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Topological Patterns . . . . . . . . . . . . . . . . . . . . 19 5. Topological Patterns . . . . . . . . . . . . . . . . . . . . 18
5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 20 5.1. Passport Model . . . . . . . . . . . . . . . . . . . . . 18
5.2. Background-Check Model . . . . . . . . . . . . . . . . . 21 5.2. Background-Check Model . . . . . . . . . . . . . . . . . 20
5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 22 5.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 21
6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 23 6. Roles and Entities . . . . . . . . . . . . . . . . . . . . . 22
7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Relying Party . . . . . . . . . . . . . . . . . . . . . . 23
7.2. Attester . . . . . . . . . . . . . . . . . . . . . . . . 25 7.2. Attester . . . . . . . . . . . . . . . . . . . . . . . . 24
7.3. Relying Party Owner . . . . . . . . . . . . . . . . . . . 25 7.3. Relying Party Owner . . . . . . . . . . . . . . . . . . . 24
7.4. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 25 7.4. Verifier . . . . . . . . . . . . . . . . . . . . . . . . 25
7.5. Endorser, Reference Value Provider, and Verifier Owner . 27 7.5. Endorser, Reference Value Provider, and Verifier Owner . 27
8. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 28 8. Conceptual Messages . . . . . . . . . . . . . . . . . . . . . 27
8.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 27
8.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Endorsements . . . . . . . . . . . . . . . . . . . . . . 28
8.3. Reference Values . . . . . . . . . . . . . . . . . . . . 29 8.3. Reference Values . . . . . . . . . . . . . . . . . . . . 28
8.4. Attestation Results . . . . . . . . . . . . . . . . . . . 29 8.4. Attestation Results . . . . . . . . . . . . . . . . . . . 28
8.5. Appraisal Policies . . . . . . . . . . . . . . . . . . . 30 8.5. Appraisal Policies . . . . . . . . . . . . . . . . . . . 30
9. Claims Encoding Formats . . . . . . . . . . . . . . . . . . . 31 9. Claims Encoding Formats . . . . . . . . . . . . . . . . . . . 30
10. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Freshness . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1. Explicit Timekeeping using Synchronized Clocks . . . . . 33 10.1. Explicit Timekeeping using Synchronized Clocks . . . . . 32
10.2. Implicit Timekeeping using Nonces . . . . . . . . . . . 33 10.2. Implicit Timekeeping using Nonces . . . . . . . . . . . 33
10.3. Implicit Timekeeping using Epoch IDs . . . . . . . . . . 33 10.3. Implicit Timekeeping using Epoch IDs . . . . . . . . . . 33
10.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 35 10.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . 34
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35
12. Security Considerations . . . . . . . . . . . . . . . . . . . 36 12. Security Considerations . . . . . . . . . . . . . . . . . . . 36
12.1. Attester and Attestation Key Protection . . . . . . . . 36 12.1. Attester and Attestation Key Protection . . . . . . . . 36
12.1.1. On-Device Attester and Key Protection . . . . . . . 37 12.1.1. On-Device Attester and Key Protection . . . . . . . 36
12.1.2. Attestation Key Provisioning Processes . . . . . . . 37 12.1.2. Attestation Key Provisioning Processes . . . . . . . 37
12.2. Integrity Protection . . . . . . . . . . . . . . . . . . 39 12.2. Integrity Protection . . . . . . . . . . . . . . . . . . 38
12.3. Epoch ID-based Attestation . . . . . . . . . . . . . . . 39 12.3. Epoch ID-based Attestation . . . . . . . . . . . . . . . 39
12.4. Trust Anchor Protection . . . . . . . . . . . . . . . . 40 12.4. Trust Anchor Protection . . . . . . . . . . . . . . . . 40
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
15. Notable Contributions . . . . . . . . . . . . . . . . . . . . 41 15. Notable Contributions . . . . . . . . . . . . . . . . . . . . 40
16. Appendix A: Time Considerations . . . . . . . . . . . . . . . 41 16. Appendix A: Time Considerations . . . . . . . . . . . . . . . 41
16.1. Example 1: Timestamp-based Passport Model Example . . . 43 16.1. Example 1: Timestamp-based Passport Model Example . . . 42
16.2. Example 2: Nonce-based Passport Model Example . . . . . 44 16.2. Example 2: Nonce-based Passport Model Example . . . . . 44
16.3. Example 3: Epoch ID-based Passport Model Example . . . . 46 16.3. Example 3: Epoch ID-based Passport Model Example . . . . 45
16.4. Example 4: Timestamp-based Background-Check Model 16.4. Example 4: Timestamp-based Background-Check Model
Example . . . . . . . . . . . . . . . . . . . . . . . . 47 Example . . . . . . . . . . . . . . . . . . . . . . . . 46
16.5. Example 5: Nonce-based Background-Check Model Example . 48 16.5. Example 5: Nonce-based Background-Check Model Example . 47
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
17.1. Normative References . . . . . . . . . . . . . . . . . . 49 17.1. Normative References . . . . . . . . . . . . . . . . . . 48
17.2. Informative References . . . . . . . . . . . . . . . . . 49 17.2. Informative References . . . . . . . . . . . . . . . . . 48
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
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
good state can be taken out of service, or otherwise flagged for good state can be given reduced access or privileges, taken out of
repair. service, or otherwise flagged for repair.
For example: For example:
* A bank back-end system might refuse to transact with another * A bank back-end system might refuse to transact with another
system that is not known to be in a good state. system that is not known to be in a good state.
* A healthcare system might refuse to transmit electronic healthcare * A healthcare system might refuse to transmit electronic healthcare
records to a system that is not known to be in a good state. records to a system that is not known to be in a good state.
In Remote Attestation Procedures (RATS), one peer (the "Attester") In Remote Attestation Procedures (RATS), one peer (the "Attester")
skipping to change at page 5, line 21 skipping to change at page 5, line 21
and this document does not intend to have a complete list, only to and this document does not intend to have a complete list, only to
illustrate a set of use cases that collectively cover all the illustrate a set of use cases that collectively cover all the
functionality required in the architecture. functionality required in the architecture.
Each use case includes a description followed by an additional Each use case includes a description followed by an additional
summary of the Attester and Relying Party roles derived from the use summary of the Attester and Relying Party roles derived from the use
case. case.
2.1. Network Endpoint Assessment 2.1. Network Endpoint Assessment
Network operators want a trustworthy report that includes identity Network operators want trustworthy reports that include identity and
and version information about the hardware and software on the version information about the hardware and software on the machines
machines attached to their network, for purposes such as inventory, attached to their network. Examples of reports include purposes,
audit, anomaly detection, record maintenance and/or trending reports such as inventory summaries, audit results, anomaly notifications,
(logging). The network operator may also want a policy by which full typically including the maintenance of log records or trend reports.
access is only granted to devices that meet some definition of The network operator may also want a policy by which full access is
hygiene, and so wants to get Claims about such information and verify only granted to devices that meet some definition of hygiene, and so
its validity. Remote attestation is desired to prevent vulnerable or wants to get Claims about such information and verify its validity.
compromised devices from getting access to the network and Remote attestation is desired to prevent vulnerable or compromised
potentially harming others. devices from getting access to the network and potentially harming
others.
Typically, solutions start with a specific component (called a root Typically, solutions start with a specific component (called a root
of trust) that is intended to provide trustworthy device identity and of trust) that is intended to provide trustworthy device identity and
protected storage for measurements. The system components perform a protected storage for measurements. The system components perform a
series of measurements that may be signed via functions provided by a series of measurements that may be signed via functions provided by a
root of trust, considered as Evidence about present system root of trust, considered as Evidence about present system
components, such as hardware, firmware, BIOS, software, etc. components, such as hardware, firmware, BIOS, software, etc.
Attester: A device desiring access to a network. Attester: A device desiring access to a network.
skipping to change at page 8, line 14 skipping to change at page 8, line 14
the server. For the Relying Party to know that the authentication is the server. For the Relying Party to know that the authentication is
trustworthy, the Relying Party needs to know that the Authenticator trustworthy, the Relying Party needs to know that the Authenticator
part of the device is trustworthy. The FIDO protocol employs remote part of the device is trustworthy. The FIDO protocol employs remote
attestation for this. attestation for this.
The FIDO protocol supports several remote attestation protocols and a The FIDO protocol supports several remote attestation protocols and a
mechanism by which new ones can be registered and added. Remote mechanism by which new ones can be registered and added. Remote
attestation defined by RATS is thus a candidate for use in the FIDO attestation defined by RATS is thus a candidate for use in the FIDO
protocol. protocol.
Other biometric authentication protocols such as the Chinese IFAA Attester: FIDO Authenticator.
standard and WeChat Pay as well as Google Pay make use of remote
attestation in one form or another.
Attester: Every FIDO Authenticator contains an Attester.
Relying Party: Any web site, mobile application back-end, or service Relying Party: Any web site, mobile application back-end, or service
that relies on authentication data based on biometric information. that relies on authentication data based on biometric information.
3. Architectural Overview 3. Architectural Overview
Figure 1 depicts the data that flows between different roles, Figure 1 depicts the data that flows between different roles,
independent of protocol or use case. independent of protocol or use case.
************ ************* ************ ***************** ************ ************* ************ *****************
skipping to change at page 15, line 31 skipping to change at page 14, line 31
Another example is a multi-chassis router composed of multiple single Another example is a multi-chassis router composed of multiple single
carrier-grade routers. Multi-chassis router setups create redundancy carrier-grade routers. Multi-chassis router setups create redundancy
groups that provide higher throughput by interconnecting multiple groups that provide higher throughput by interconnecting multiple
routers in these groups, which can be treated as one logical router routers in these groups, which can be treated as one logical router
for simpler management. A multi-chassis router setup provides a for simpler management. A multi-chassis router setup provides a
management point that connects to the Verifier. Typically one router management point that connects to the Verifier. Typically one router
in the group is designated as the main router. Other routers in the in the group is designated as the main router. Other routers in the
multi-chassis setup are connected to the main router only via multi-chassis setup are connected to the main router only via
physical network links and are therefore managed and appraised via physical network links and are therefore managed and appraised via
the main router's help. In consequence, a multi-chassis router setup the main router's help. Consequently, a multi-chassis router setup
is a composite device, each router is an Attester, and the main is a composite device, each router is an Attester, and the main
router is the lead Attester. router is the lead Attester.
Figure 4 depicts the conceptual data flow for a composite device. Figure 4 depicts the conceptual data flow for a composite device.
.-----------------------------. .-----------------------------.
| Verifier | | Verifier |
'-----------------------------' '-----------------------------'
^ ^
| |
skipping to change at page 17, line 31 skipping to change at page 16, line 31
the Attester is considered trustworthy, such as when deciding the Attester is considered trustworthy, such as when deciding
whether it is authorized to perform some operation. whether it is authorized to perform some operation.
Produces: Evidence Produces: Evidence
Relying Party: A role performed by an entity that depends on the Relying Party: A role performed by an entity that depends on the
validity of information about an Attester, for purposes of validity of information about an Attester, for purposes of
reliably applying application specific actions. Compare /relying reliably applying application specific actions. Compare /relying
party/ in [RFC4949]. party/ in [RFC4949].
Consumes: Attestation Results Consumes: Attestation Results, Appraisal Policy for Attestation
Results
Verifier: A role performed by an entity that appraises the validity Verifier: A role performed by an entity that appraises the validity
of Evidence about an Attester and produces Attestation Results to of Evidence about an Attester and produces Attestation Results to
be used by a Relying Party. be used by a Relying Party.
Consumes: Evidence, Reference Values, Endorsements, Appraisal Consumes: Evidence, Reference Values, Endorsements, Appraisal
Policy for Evidence Policy for Evidence
Produces: Attestation Results Produces: Attestation Results
skipping to change at page 18, line 8 skipping to change at page 17, line 8
Produces: Appraisal Policy for Attestation Results Produces: Appraisal Policy for Attestation Results
Verifier Owner: A role performed by an entity (typically an Verifier Owner: A role performed by an entity (typically an
administrator), that is authorized to configure Appraisal Policy administrator), that is authorized to configure Appraisal Policy
for Evidence in a Verifier. for Evidence in a Verifier.
Produces: Appraisal Policy for Evidence Produces: Appraisal Policy for Evidence
Endorser: A role performed by an entity (typically a manufacturer) Endorser: A role performed by an entity (typically a manufacturer)
whose Endorsements help Verifiers appraise the authenticity of whose Endorsements may help Verifiers appraise the authenticity of
Evidence. Evidence and infer further capabilities of the Attester.
Produces: Endorsements Produces: Endorsements
Reference Value Provider: A role performed by an entity (typically a Reference Value Provider: A role performed by an entity (typically a
manufacturer) whose Reference Values help Verifiers appraise manufacturer) whose Reference Values help Verifiers appraise
Evidence to determine if acceptable known Claims have been Evidence to determine if acceptable known Claims have been
recorded by the Attester. recorded by the Attester.
Produces: Reference Values Produces: Reference Values
skipping to change at page 20, line 16 skipping to change at page 18, line 52
The passport model is so named because of its resemblance to how The passport model is so named because of its resemblance to how
nations issue passports to their citizens. The nature of the nations issue passports to their citizens. The nature of the
Evidence that an individual needs to provide to its local authority Evidence that an individual needs to provide to its local authority
is specific to the country involved. The citizen retains control of is specific to the country involved. The citizen retains control of
the resulting passport document and presents it to other entities the resulting passport document and presents it to other entities
when it needs to assert a citizenship or identity Claim, such as an when it needs to assert a citizenship or identity Claim, such as an
airport immigration desk. The passport is considered sufficient airport immigration desk. The passport is considered sufficient
because it vouches for the citizenship and identity Claims, and it is because it vouches for the citizenship and identity Claims, and it is
issued by a trusted authority. Thus, in this immigration desk issued by a trusted authority. Thus, in this immigration desk
analogy, the passport issuing agency is a Verifier, the passport is analogy, the citizen is the Attester, the passport issuing agency is
an Attestation Result, and the immigration desk is a Relying Party. a Verifier, the passport application and identifying information
(e.g., birth certificate) is the the Evidence, the passport is an
Attestation Result, and the immigration desk is a Relying Party.
In this model, an Attester conveys Evidence to a Verifier, which In this model, an Attester conveys Evidence to a Verifier, which
compares the Evidence against its appraisal policy. The Verifier compares the Evidence against its appraisal policy. The Verifier
then gives back an Attestation Result. If the Attestation Result was then gives back an Attestation Result which the Attester treats as
a successful one, the Attester can then present the Attestation opaque data. The Attester does not consume the Attestation Result,
but might cache it. The Attester can then present the Attestation
Result (and possibly additional Claims) to a Relying Party, which Result (and possibly additional Claims) to a Relying Party, which
then compares this information against its own appraisal policy. then compares this information against its own appraisal policy.
Three ways in which the process may fail include: Three ways in which the process may fail include:
* First, the Verifier may not issue a positive Attestation Result * First, the Verifier may not issue a positive Attestation Result
due to the Evidence not passing the Appraisal Policy for Evidence. due to the Evidence not passing the Appraisal Policy for Evidence.
* The second way in which the process may fail is when the * The second way in which the process may fail is when the
Attestation Result is examined by the Relying Party, and based Attestation Result is examined by the Relying Party, and based
upon the Appraisal Policy for Attestation Results, the result does upon the Appraisal Policy for Attestation Results, the result does
not pass the policy. not pass the policy.
* The third way is when the Verifier is unreachable or unavailable. * The third way is when the Verifier is unreachable or unavailable.
Since the resource access protocol between the Attester and Relying As with any other information needed by the Relying Party to make an
Party includes an Attestation Result, in this model the details of authorization decision, an Attestation Result can be carried in a
that protocol constrain the serialization format of the Attestation resource access protocol between the Attester and Relying Party. In
Result. The format of the Evidence on the other hand is only this model the details of the resource access protocol constrain the
constrained by the Attester-Verifier remote attestation protocol. serialization format of the Attestation Result. The format of the
This implies that interoperability and standardization is more Evidence on the other hand is only constrained by the Attester-
relevant for Attestation Results than it is for Evidence. Verifier remote attestation protocol. This implies that
interoperability and standardization is more relevant for Attestation
Results than it is for Evidence.
+------------+ +------------+
| | Compare Evidence | | Compare Evidence
| Verifier | against appraisal policy | Verifier | against appraisal policy
| | | |
+------------+ +------------+
^ | ^ |
Evidence | | Attestation Evidence | | Attestation
| | Result | | Result
| v | v
skipping to change at page 21, line 36 skipping to change at page 20, line 20
When a prospective employee provides Claims about education or When a prospective employee provides Claims about education or
previous experience, the employer will contact the respective previous experience, the employer will contact the respective
institutions or former employers to validate the Claim. Volunteer institutions or former employers to validate the Claim. Volunteer
organizations often perform police background checks on volunteers in organizations often perform police background checks on volunteers in
order to determine the volunteer's trustworthiness. Thus, in this order to determine the volunteer's trustworthiness. Thus, in this
analogy, a prospective volunteer is an Attester, the organization is analogy, a prospective volunteer is an Attester, the organization is
the Relying Party, and the organization that issues a report is a the Relying Party, and the organization that issues a report is a
Verifier. Verifier.
In this model, an Attester conveys Evidence to a Relying Party, which In this model, an Attester conveys Evidence to a Relying Party, which
simply passes it on to a Verifier. The Verifier then compares the treats it as opaque and simply forwards it on to a Verifier. The
Evidence against its appraisal policy, and returns an Attestation Verifier compares the Evidence against its appraisal policy, and
Result to the Relying Party. The Relying Party then compares the returns an Attestation Result to the Relying Party. The Relying
Attestation Result against its own appraisal policy. Party then compares the Attestation Result against its own appraisal
policy.
The resource access protocol between the Attester and Relying Party The resource access protocol between the Attester and Relying Party
includes Evidence rather than an Attestation Result, but that includes Evidence rather than an Attestation Result, but that
Evidence is not processed by the Relying Party. Since the Evidence Evidence is not processed by the Relying Party. Since the Evidence
is merely forwarded on to a trusted Verifier, any serialization is merely forwarded on to a trusted Verifier, any serialization
format can be used for Evidence because the Relying Party does not format can be used for Evidence because the Relying Party does not
need a parser for it. The only requirement is that the Evidence can need a parser for it. The only requirement is that the Evidence can
be _encapsulated in_ the format required by the resource access be _encapsulated in_ the format required by the resource access
protocol between the Attester and Relying Party. protocol between the Attester and Relying Party.
skipping to change at page 24, line 18 skipping to change at page 23, line 18
In essence, an entity that combines more than one role creates and In essence, an entity that combines more than one role creates and
consumes the corresponding conceptual messages as defined in this consumes the corresponding conceptual messages as defined in this
document. document.
7. Trust Model 7. Trust Model
7.1. Relying Party 7.1. Relying Party
This document covers scenarios for which a Relying Party trusts a This document covers scenarios for which a Relying Party trusts a
Verifier that can appraise the trustworthiness of information about Verifier that can appraise the trustworthiness of information about
an Attester. Such trust might come by the Relying Party trusting the an Attester. Such trust is expressed by storing one or more "trust
Verifier (or its public key) directly, or might come by trusting an anchors" in a secure location known as a trust anchor store.
entity (e.g., a Certificate Authority) that is in the Verifier's
certificate path. Such trust is expressed by storing one or more
"trust 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.
The Relying Party might implicitly trust a Verifier, such as in a Thus, trusting a Verifier might be expressed by having the Relying
Verifier/Relying Party combination where the Verifier and Relying Party store the Verifier's public key or certificate in its trust
Party roles are combined. Or, for a stronger level of security, the anchor store, or might be expressed by storing the public key or
Relying Party might require that the Verifier first provide certificate of an entity (e.g., a Certificate Authority) that is in
information about itself that the Relying Party can use to assess the the Verifier's certificate path. For example, the Relying Party can
trustworthiness of the Verifier before accepting its Attestation verify that the Verifier is an expected one by out of band
Results. establishment of key material, combined with a protocol like TLS to
communicate. There is an assumption that between the establishment
of the trusted key material and the creation of the Evidence, that
the Verifier has not been compromised.
For example, one explicit way for a Relying Party "A" to establish For a stronger level of security, the Relying Party might require
such trust in a Verifier "B", would be for B to first act as an that the Verifier first provide information about itself that the
Attester where A acts as a combined Verifier/Relying Party. If A Relying Party can use to assess the trustworthiness of the Verifier
then accepts B as trustworthy, it can choose to accept B as a before accepting its Attestation Results. Such process would provide
Verifier for other Attesters. a stronger level of confidence in the correctness of the information
provided, such as a belief that the authentic Verifier has not been
compromised by malware.
As another example, the Relying Party can establish trust in the For example, one explicit way for a Relying Party "A" to establish
Verifier by out of band establishment of key material, combined with such confidence in the correctness of a Verifier "B", would be for B
a protocol like TLS to communicate. There is an assumption that to first act as an Attester where A acts as a combined Verifier/
between the establishment of the trusted key material and the Relying Party. If A then accepts B as trustworthy, it can choose to
creation of the Evidence, that the Verifier has not been compromised. accept B as a Verifier for other Attesters.
Similarly, the Relying Party also needs to trust the Relying Party Similarly, the Relying Party also needs to trust the Relying Party
Owner for providing its Appraisal Policy for Attestation Results, and Owner for providing its Appraisal Policy for Attestation Results, and
in some scenarios the Relying Party might even require that the in some scenarios the Relying Party might even require that the
Relying Party Owner go through a remote attestation procedure with it Relying Party Owner go through a remote attestation procedure with it
before the Relying Party will accept an updated policy. This can be before the Relying Party will accept an updated policy. This can be
done similarly to how a Relying Party could establish trust in a done similarly to how a Relying Party could establish trust in a
Verifier as discussed above. Verifier as discussed above, i.e., verifying credentials against a
trust anchor store and optionally requiring Attestation Results from
the Relying Party Owner.
7.2. Attester 7.2. Attester
In some scenarios, Evidence might contain sensitive information such In some scenarios, Evidence might contain sensitive information such
as Personally Identifiable Information (PII) or system identifiable as Personally Identifiable Information (PII) or system identifiable
information. Thus, an Attester must trust entities to which it information. Thus, an Attester must trust entities to which it
conveys Evidence, to not reveal sensitive data to unauthorized conveys Evidence, to not reveal sensitive data to unauthorized
parties. The Verifier might share this information with other parties. The Verifier might share this information with other
authorized parties, according to a governing policy that address the authorized parties, according to a governing policy that address the
handling of sensitive information (potentially included in Appraisal handling of sensitive information (potentially included in Appraisal
skipping to change at page 26, line 7 skipping to change at page 25, line 16
The Verifier trusts (or more specifically, the Verifier's security The Verifier trusts (or more specifically, the Verifier's security
policy is written in a way that configures the Verifier to trust) a policy is written in a way that configures the Verifier to trust) a
manufacturer, or the manufacturer's hardware, so as to be able to manufacturer, or the manufacturer's hardware, so as to be able to
appraise the trustworthiness of that manufacturer's devices. Such appraise the trustworthiness of that manufacturer's devices. Such
trust is expressed by storing one or more trust anchors in the trust is expressed by storing one or more trust anchors in the
Verifier's trust anchor store. Verifier's trust anchor store.
In a typical solution, a Verifier comes to trust an Attester In a typical solution, a Verifier comes to trust an Attester
indirectly by having an Endorser (such as a manufacturer) vouch for indirectly by having an Endorser (such as a manufacturer) vouch for
the Attester's ability to securely generate Evidence, in which case the Attester's ability to securely generate Evidence through
the Endorser's key material is stored in the Verifier's trust anchor Endorsements (see Section 8.2). Endorsements might describe the ways
store. in which the Attester resists attack, protects secrets and measures
Target Environments. Consequently, the Endorser's key material is
stored in the Verifier's trust anchor store so that Endorsements can
be authenticated and used in the Verifier's appraisal process.
In some solutions, a Verifier might be configured to directly trust In some solutions, a Verifier might be configured to directly trust
an Attester by having the Verifier have the Attester's key material an Attester by having the Verifier have the Attester's key material
(rather than the Endorser's) in its trust anchor store. (rather than the Endorser's) in its trust anchor store.
Such direct trust must first be established at the time of trust Such direct trust must first be established at the time of trust
anchor store configuration either by checking with an Endorser at anchor store configuration either by checking with an Endorser at
that time, or by conducting a security analysis of the specific that time, or by conducting a security analysis of the specific
device. Having the Attester directly in the trust anchor store device. Having the Attester directly in the trust anchor store
narrows the Verifier's trust to only specific devices rather than all narrows the Verifier's trust to only specific devices rather than all
skipping to change at page 28, line 25 skipping to change at page 27, line 40
implementation considerations. It is the responsibility of protocol implementation considerations. It is the responsibility of protocol
specifications to define the actual data format and semantics of any specifications to define the actual data format and semantics of any
relevant conceptual messages. relevant conceptual messages.
8.1. Evidence 8.1. Evidence
Evidence is a set of Claims about the target environment that reveal Evidence is a set of Claims about the target environment that reveal
operational status, health, configuration or construction that have operational status, health, configuration or construction that have
security relevance. Evidence is appraised by a Verifier to establish security relevance. Evidence is appraised by a Verifier to establish
its relevance, compliance, and timeliness. Claims need to be its relevance, compliance, and timeliness. Claims need to be
collected in a manner that is reliable. Evidence needs to be collected in a manner that is reliable such that a Target Environment
securely associated with the target environment so that the Verifier cannot lie to the Attesting Environment about its trustworthiness
cannot be tricked into accepting Claims originating from a different properties. Evidence needs to be securely associated with the target
environment (that may be more trustworthy). Evidence also must be environment so that the Verifier cannot be tricked into accepting
protected from man-in-the-middle attackers who may observe, change or Claims originating from a different environment (that may be more
misdirect Evidence as it travels from Attester to Verifier. The trustworthy). Evidence also must be protected from man-in-the-middle
timeliness of Evidence can be captured using Claims that pinpoint the attackers who may observe, change or misdirect Evidence as it travels
time or interval when changes in operational status, health, and so from Attester to Verifier. The timeliness of Evidence can be
forth occur. captured using Claims that pinpoint the time or interval when changes
in operational status, health, and so forth occur.
8.2. Endorsements 8.2. Endorsements
An Endorsement is a secure statement that some entity (e.g., a An Endorsement is a secure statement that some entity (e.g., a
manufacturer) vouches for the integrity of the device's signing manufacturer) vouches for the integrity of the device's various
capability. For example, if the signing capability is in hardware, capabilities such as claims collection, signing, launching code,
then an Endorsement might be a manufacturer certificate that signs a transitioning to other environments, storing secrets, and more. For
public key whose corresponding private key is only known inside the example, if the device's signing capability is in hardware, then an
device's hardware. Thus, when Evidence and such an Endorsement are Endorsement might be a manufacturer certificate that signs a public
used together, an appraisal procedure can be conducted based on key whose corresponding private key is only known inside the device's
appraisal policies that may not be specific to the device instance, hardware. Thus, when Evidence and such an Endorsement are used
but merely specific to the manufacturer providing the Endorsement. together, an appraisal procedure can be conducted based on appraisal
For example, an appraisal policy might simply check that devices from policies that may not be specific to the device instance, but merely
a given manufacturer have information matching a set of Reference specific to the manufacturer providing the Endorsement. For example,
Values, or an appraisal policy might have a set of more complex logic an appraisal policy might simply check that devices from a given
on how to appraise the validity of information. manufacturer have information matching a set of Reference Values, or
an appraisal policy might have a set of more complex logic on how to
appraise the validity of information.
However, while an appraisal policy that treats all devices from a However, while an appraisal policy that treats all devices from a
given manufacturer the same may be appropriate for some use cases, it given manufacturer the same may be appropriate for some use cases, it
would be inappropriate to use such an appraisal policy as the sole would be inappropriate to use such an appraisal policy as the sole
means of authorization for use cases that wish to constrain _which_ means of authorization for use cases that wish to constrain _which_
compliant devices are considered authorized for some purpose. For compliant devices are considered authorized for some purpose. For
example, an enterprise using remote attestation for Network Endpoint example, an enterprise using remote attestation for Network Endpoint
Assessment [RFC5209] may not wish to let every healthy laptop from Assessment [RFC5209] may not wish to let every healthy laptop from
the same manufacturer onto the network, but instead only want to let the same manufacturer onto the network, but instead only want to let
devices that it legally owns onto the network. Thus, an Endorsement devices that it legally owns onto the network. Thus, an Endorsement
skipping to change at page 30, line 12 skipping to change at page 29, line 33
compliant. Upon receipt of an authentic Attestation Result and given compliant. Upon receipt of an authentic Attestation Result and given
the Appraisal Policy for Attestation Results is satisfied, the the Appraisal Policy for Attestation Results is satisfied, the
Attester is allowed to perform the prescribed actions or access. The Attester is allowed to perform the prescribed actions or access. The
simplest such appraisal policy might authorize granting the Attester simplest such appraisal policy might authorize granting the Attester
full access or control over the resources guarded by the Relying full access or control over the resources guarded by the Relying
Party. A more complex appraisal policy might involve using the Party. A more complex appraisal policy might involve using the
information provided in the Attestation Result to compare against information provided in the Attestation Result to compare against
expected values, or to apply complex analysis of other information expected values, or to apply complex analysis of other information
contained in the Attestation Result. contained in the Attestation Result.
Thus, Attestation Results often need to include detailed information Thus, Attestation Results can contain detailed information about an
about the Attester, for use by Relying Parties, much like physical Attester, which can include privacy sensitive information as
passports and drivers licenses include personal information such as discussed in section Section 11. Unlike Evidence, which is often
name and date of birth. Unlike Evidence, which is often very device- very device- and vendor-specific, Attestation Results can be vendor-
and vendor-specific, Attestation Results can be vendor-neutral, if neutral, if the Verifier has a way to generate vendor-agnostic
the Verifier has a way to generate vendor-agnostic information based information based on the appraisal of vendor-specific information in
on the appraisal of vendor-specific information in Evidence. This Evidence. This allows a Relying Party's appraisal policy to be
allows a Relying Party's appraisal policy to be simpler, potentially simpler, potentially based on standard ways of expressing the
based on standard ways of expressing the information, while still information, while still allowing interoperability with heterogeneous
allowing interoperability with heterogeneous devices. devices.
Finally, whereas Evidence is signed by the device (or indirectly by a Finally, whereas Evidence is signed by the device (or indirectly by a
manufacturer, if Endorsements are used), Attestation Results are manufacturer, if Endorsements are used), Attestation Results are
signed by a Verifier, allowing a Relying Party to only need a trust signed by a Verifier, allowing a Relying Party to only need a trust
relationship with one entity, rather than a larger set of entities, relationship with one entity, rather than a larger set of entities,
for purposes of its appraisal policy. for purposes of its appraisal policy.
8.5. Appraisal Policies 8.5. Appraisal Policies
The Verifier, when appraising Evidence, or the Relying Party, when The Verifier, when appraising Evidence, or the Relying Party, when
skipping to change at page 32, line 37 skipping to change at page 32, line 14
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 and their values can be considered fresh, meaning they still reflect
the latest state of the Attester, and that any Attestation Result was the latest state of the Attester, and that any Attestation Result was
generated using the latest Appraisal Policy for Evidence. generated using the latest Appraisal Policy for Evidence.
This section provides a number of details. It does not however
define any protocol formats, the interactions shown are abstract.
This section is intended for those creating protocols and solutions
to understand the options available to ensure freshness. The way in
which freshness is provisioned in a protocol is an architectural
decision. Provisioning of freshness has an impact on the number of
needed round trips in a protocol, and therefore must be made very
early in the design. Different decisions will have significant
impacts on resulting interoperability, which is why this section goes
into sufficient detail such that choices in freshness will be
compatible across interacting protocols, such as depicted in
Figure 9.
Freshness is assessed based on the Appraisal Policy for Evidence or Freshness is assessed based on the Appraisal Policy for Evidence or
Attestation Results that compares the estimated epoch against an Attestation Results that compares the estimated epoch against an
"expiry" threshold defined locally to that policy. There is, "expiry" threshold defined locally to that policy. There is,
however, always a race condition possible in that the state of the however, always a race condition possible in that the state of the
Attester, and the appraisal policies might change immediately after Attester, and the appraisal policies might change immediately after
the Evidence or Attestation Result was generated. The goal is merely the Evidence or Attestation Result was generated. The goal is merely
to narrow their recentness to something the Verifier (for Evidence) to narrow their recentness to something the Verifier (for Evidence)
or Relying Party (for Attestation Result) is willing to accept. Some or Relying Party (for Attestation Result) is willing to accept. Some
flexibility on the freshness requirement is a key component for flexibility on the freshness requirement is a key component for
enabling caching and reuse of both Evidence and Attestation Results, enabling caching and reuse of both Evidence and Attestation Results,
skipping to change at page 35, line 28 skipping to change at page 35, line 9
established to the remote Verifier and a nonce is obtained. established to the remote Verifier and a nonce is obtained.
A more detailed discussion with examples appears in Section 16. A more detailed discussion with examples appears in Section 16.
For a discussion on the security of epoch IDs see Section 12.3. For a discussion on the security of epoch IDs see Section 12.3.
11. Privacy Considerations 11. Privacy Considerations
The conveyance of Evidence and the resulting Attestation Results The conveyance of Evidence and the resulting Attestation Results
reveal a great deal of information about the internal state of a reveal a great deal of information about the internal state of a
device as well as potentially any users of the device. In many device as well as potentially any users of the device.
cases, the whole point of attestation procedures is to provide
reliable information about the type of the device and the firmware/
software that the device is running. This information might be
particularly interesting to many attackers. For example, knowing
that a device is running a weak version of firmware provides a way to
aim attacks better.
Many Claims in Evidence and Attestation Results are potentially In many cases, the whole point of attestation procedures is to
Personally Identifying Information (PII) depending on the end-to-end provide reliable information about the type of the device and the
use case of the remote attestation procedure. Remote attestation firmware/software that the device is running.
that goes up to include containers and applications, e.g., a blood
pressure monitor, may further reveal details about specific systems This information might be particularly interesting to many attackers.
or users. For example, knowing that a device is running a weak version of
firmware provides a way to aim attacks better.
In some circumstances, if an attacker can become aware of
Endorsements, Reference Values, or appraisal policies, it could
potentially provide an attacker with insight into defensive
mitigations. It is recommended that attention be paid to
confidentiality of such information.
Additionally, many Claims in Evidence, many Claims in Attestation
Results, and appraisal policies potentially contain Personally
Identifying Information (PII) depending on the end-to-end use case of
the remote attestation procedure. Remote attestation that includes
containers and applications, e.g., a blood pressure monitor, may
further reveal details about specific systems or users.
In some cases, an attacker may be able to make inferences about the In some cases, an attacker may be able to make inferences about the
contents of Evidence from the resulting effects or timing of the contents of Evidence from the resulting effects or timing of the
processing. For example, an attacker might be able to infer the processing. For example, an attacker might be able to infer the
value of specific Claims if it knew that only certain values were value of specific Claims if it knew that only certain values were
accepted by the Relying Party. accepted by the Relying Party.
Evidence and Attestation Results are expected to be integrity Conceptual messages (see Section 8) carrying sensitive or
protected (i.e., either via signing or a secure channel) and confidential information are expected to be integrity protected
optionally might be confidentiality protected via encryption. If (i.e., either via signing or a secure channel) and optionally might
confidentiality protection of the conceptual messages is omitted or be confidentiality protected via encryption. If there isn't
unavailable, the protecting protocols that convey Evidence or confidentiality protection of conceptual messages themselves, the
Attestation Results are responsible for detailing what kinds of underlying conveyance protocol should provide these protections.
information are disclosed, and to whom they are exposed.
As Evidence might contain sensitive or confidential information, As Evidence might contain sensitive or confidential information,
Attesters are responsible for only sending such Evidence to trusted Attesters are responsible for only sending such Evidence to trusted
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 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. The security threats listed below have been mitigated well.
considerations below should be read as being essentially requirements
against realizations of the RATS Architecture. Some threats apply to The security considerations below should be read as being essentially
protocols, some are against implementations (code), and some threats requirements against realizations of the RATS Architecture. Some
are against physical infrastructure (such as factories). threats apply to protocols, some are against implementations (code),
and some threats are against physical infrastructure (such as
factories).
The fundamental purpose of the RATS architecture is to allow a
Relying Party to establish a basis for trusting the Attester.
12.1. Attester and Attestation Key Protection 12.1. Attester and Attestation Key Protection
Implementers need to pay close attention to the protection of the Implementers need to pay close attention to the protection of the
Attester and the manufacturing processes for provisioning attestation Attester and the manufacturing processes for provisioning attestation
key material. If either of these are compromised, intended levels of key material. If either of these are compromised, intended levels of
assurance for RATS are compromised because attackers can forge assurance for RATS are compromised because attackers can forge
Evidence or manipulate the Attesting Environment. For example, a Evidence or manipulate the Attesting Environment. For example, a
Target Environment should not be able to tamper with the Attesting Target Environment should not be able to tamper with the Attesting
Environment that measures it, by isolating the two environments from Environment that measures it, by isolating the two environments from
skipping to change at page 37, line 22 skipping to change at page 37, line 12
chip, a TEE, a virtual machine, or another secure mode of operation. chip, a TEE, a virtual machine, or another secure mode of operation.
The Attesting Environment must be protected from unauthorized The Attesting Environment must be protected from unauthorized
modification to ensure it behaves correctly. Confidentiality modification to ensure it behaves correctly. Confidentiality
protection of the Attesting Environment's signing key is vital so it protection of the Attesting Environment's signing key is vital so it
cannot be misused to forge Evidence. cannot be misused to forge Evidence.
In many cases the user or owner of a device that includes the role of In many cases the user or owner of a device that includes the role of
Attester must not be able to modify or extract keys from the Attester must not be able to modify or extract keys from the
Attesting Environments, to prevent creating forged Evidence. Some Attesting Environments, to prevent creating forged Evidence. Some
common examples include the user of a mobile phone or FIDO common examples include the user of a mobile phone or FIDO
authenticator. An essential value-add provided by RATS is for the authenticator.
Relying Party to be able to trust the Attester even if the user or
owner is not trusted.
Measures for a minimally protected system might include process or Measures for a minimally protected system might include process or
application isolation provided by a high-level operating system, and application isolation provided by a high-level operating system, and
restricted access to root or system privileges. In contrast, For restricted access to root or system privileges. In contrast, For
really simple single-use devices that don't use a protected mode really simple single-use devices that don't use a protected mode
operating system, like a Bluetooth speaker, the only factual operating system, like a Bluetooth speaker, the only factual
isolation might be the sturdy housing of the device. isolation might be the sturdy housing of the device.
Measures for a moderately protected system could include a special Measures for a moderately protected system could include a special
restricted operating environment, such as a TEE. In this case, only restricted operating environment, such as a TEE. In this case, only
skipping to change at page 37, line 47 skipping to change at page 37, line 35
Measures for a highly protected system could include specialized Measures for a highly protected system could include specialized
hardware that is used to provide protection against chip decapping hardware that is used to provide protection against chip decapping
attacks, power supply and clock glitching, faulting injection and RF attacks, power supply and clock glitching, faulting injection and RF
and power side channel attacks. and power side channel attacks.
12.1.2. Attestation Key Provisioning Processes 12.1.2. Attestation Key Provisioning Processes
Attestation key provisioning is the process that occurs in the Attestation key provisioning is the process that occurs in the
factory or elsewhere to establish signing key material on the device factory or elsewhere to establish signing key material on the device
and the validation key material off the device. Sometimes this is and the validation key material off the device. Sometimes this
procedure is referred to as personalization or customization. procedure is referred to as personalization or customization.
The keys generated in the factory, whether generated in the device or
off-device by the factory SHOULD be generated by a Cryptographically
Strong Sequence ([RFC4086], Section 6.2).
12.1.2.1. Off-Device Key Generation 12.1.2.1. Off-Device Key Generation
One way to provision key material is to first generate it external to One way to provision key material is to first generate it external to
the device and then copy the key onto the device. In this case, the device and then copy the key onto the device. In this case,
confidentiality protection of the generator, as well as for the path confidentiality protection of the generator, as well as for the path
over which the key is provisioned, is necessary. The manufacturer over which the key is provisioned, is necessary. The manufacturer
needs to take care to protect corresponding key material with needs to take care to protect corresponding key material with
measures appropriate for its value. measures appropriate for its value.
The degree of protection afforded to this key material can vary by The degree of protection afforded to this key material can vary by
device, based upon considerations as to a cost/benefit evaluation of the intended function of the device and the specific practices of the
the intended function of the device. The confidentiality protection device manufacturer or integrator. The confidentiality protection is
is fundamentally based upon some amount of physical protection: while fundamentally based upon some amount of physical protection: while
encryption is often used to provide confidentiality when a key is encryption is often used to provide confidentiality when a key is
conveyed across a factory, where the attestation key is created or conveyed across a factory, where the attestation key is created or
applied, it must be available in an unencrypted form. The physical applied, it must be available in an unencrypted form. The physical
protection can therefore vary from situations where the key is protection can therefore vary from situations where the key is
unencrypted only within carefully controlled secure enclaves within unencrypted only within carefully controlled secure enclaves within
silicon, to situations where an entire facility is considered secure, silicon, to situations where an entire facility is considered secure,
by the simple means of locked doors and limited access. by the simple means of locked doors and limited access.
The cryptography that is used to enable confidentiality protection of The cryptography that is used to enable confidentiality protection of
the attestation key comes with its own requirements to be secured. the attestation key comes with its own requirements to be secured.
skipping to change at page 39, line 7 skipping to change at page 38, line 42
key cryptography, it is, by definition, not necessary to maintain key cryptography, it is, by definition, not necessary to maintain
confidentiality of the public key: however integrity of the chain of confidentiality of the public key: however integrity of the chain of
custody of the public key is necessary in order to avoid attacks custody of the public key is necessary in order to avoid attacks
where an attacker is able get a key they control endorsed. where an attacker is able get a key they control endorsed.
To summarize: attestation key provisioning must ensure that only To summarize: attestation key provisioning must ensure that only
valid attestation key material is established in Attesters. valid attestation key material is established in Attesters.
12.2. Integrity Protection 12.2. Integrity Protection
Any solution that conveys information used for security purposes, Any solution that conveys information in any conceptual message (see
whether such information is in the form of Evidence, Attestation Section 8) must support end-to-end integrity protection and replay
Results, Endorsements, or appraisal policy must support end-to-end attack prevention, and often also needs to support additional
integrity protection and replay attack prevention, and often also security properties, including:
needs to support additional security properties, including:
* end-to-end encryption, * end-to-end encryption,
* denial of service protection, * denial of service protection,
* authentication, * authentication,
* auditing, * auditing,
* fine grained access controls, and * fine grained access controls, and
* logging. * logging.
Section 10 discusses ways in which freshness can be used in this Section 10 discusses ways in which freshness can be used in this
architecture to protect against replay attacks. architecture to protect against replay attacks.
To assess the security provided by a particular appraisal policy, it To assess the security provided by a particular appraisal policy, it
skipping to change at page 39, line 34 skipping to change at page 39, line 19
Section 10 discusses ways in which freshness can be used in this Section 10 discusses ways in which freshness can be used in this
architecture to protect against replay attacks. architecture to protect against replay attacks.
To assess the security provided by a particular appraisal policy, it To assess the security provided by a particular appraisal policy, it
is important to understand the strength of the root of trust, e.g., is important to understand the strength of the root of trust, e.g.,
whether it is mutable software, or firmware that is read-only after whether it is mutable software, or firmware that is read-only after
boot, or immutable hardware/ROM. boot, or immutable hardware/ROM.
It is also important that the appraisal policy was itself obtained It is also important that the appraisal policy was itself obtained
securely. If an attacker can configure appraisal policies for a securely. If an attacker can configure or modify appraisal policies,
Relying Party or for a Verifier, then integrity of the process is Endorsements or Reference Values for a Relying Party or for a
compromised. Verifier, then integrity of the process is compromised.
Security protections in RATS may be applied at different layers, Security protections in RATS may be applied at different layers,
whether by a conveyance protocol, or an information encoding format. whether by a conveyance protocol, or an information encoding format.
This architecture expects conceptual messages (see Section 8) to be This architecture expects conceptual messages to be end-to-end
end-to-end protected based on the role interaction context. For protected based on the role interaction context. For example, if an
example, if an Attester produces Evidence that is relayed through Attester produces Evidence that is relayed through some other entity
some other entity that doesn't implement the Attester or the intended that doesn't implement the Attester or the intended Verifier roles,
Verifier roles, then the relaying entity should not expect to have then the relaying entity should not expect to have access to the
access to the Evidence. Evidence.
12.3. Epoch ID-based Attestation 12.3. Epoch ID-based Attestation
Epoch IDs, described in Section 10.3, can be tampered with, replayed, Epoch IDs, described in Section 10.3, can be tampered with, replayed,
dropped, delayed, and reordered by an attacker. dropped, delayed, and reordered by an attacker.
An attacker could be either external or belong to the distribution An attacker could be either external or belong to the distribution
group, for example, if one of the Attester entities have been group, for example, if one of the Attester entities have been
compromised. compromised.
skipping to change at page 40, line 37 skipping to change at page 40, line 25
from a past epoch as fresh, while in the meantime the Attester has from a past epoch as fresh, while in the meantime the Attester has
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. Specifically, a trust anchor anchor stores that must be secured. [RFC6024] contains more
store must resist modification against unauthorized insertion, discussion of trust anchor store requirements. Specifically, a trust
anchor store must resist modification against unauthorized insertion,
deletion, and modification. deletion, and modification.
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 50, line 41 skipping to change at page 49, line 41
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>.
[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,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<https://www.rfc-editor.org/info/rfc5209>. <https://www.rfc-editor.org/info/rfc5209>.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
 End of changes. 51 change blocks. 
185 lines changed or deleted 230 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/