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/