draft-ietf-teep-architecture-10.txt		draft-ietf-teep-architecture-11.txt
	TEEP M. Pei		TEEP M. Pei
	Internet-Draft Broadcom		Internet-Draft Broadcom
	Intended status: Informational H. Tschofenig		Intended status: Informational H. Tschofenig
	Expires: December 21, 2020 Arm Limited		Expires: January 3, 2021 Arm Limited
	D. Thaler		D. Thaler
	Microsoft		Microsoft
	D. Wheeler		D. Wheeler
	Intel		Intel
	June 19, 2020		July 02, 2020
	Trusted Execution Environment Provisioning (TEEP) Architecture		Trusted Execution Environment Provisioning (TEEP) Architecture
	draft-ietf-teep-architecture-10		draft-ietf-teep-architecture-11
	Abstract		Abstract
	A Trusted Execution Environment (TEE) is an environment that enforces		A Trusted Execution Environment (TEE) is an environment that enforces
	that any code within that environment cannot be tampered with, and		that any code within that environment cannot be tampered with, and
	that any data used by such code cannot be read or tampered with by		that any data used by such code cannot be read or tampered with by
	any code outside that environment. This architecture document		any code outside that environment. This architecture document
	motivates the design and standardization of a protocol for managing		motivates the design and standardization of a protocol for managing
	the lifecycle of trusted applications running inside such a TEE.		the lifecycle of trusted applications running inside such a TEE.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 December 21, 2020.		This Internet-Draft will expire on January 3, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 40 ¶		skipping to change at page 2, line 40 ¶
	3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 8		3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 8
	3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8		3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8
	4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. System Components . . . . . . . . . . . . . . . . . . . . 8		4.1. System Components . . . . . . . . . . . . . . . . . . . . 8
	4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 11		4.2. Multiple TEEs in a Device . . . . . . . . . . . . . . . . 11
	4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13		4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 13
	4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 14		4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 14
	4.4.1. Example: Application Delivery Mechanisms in Intel SGX 15		4.4.1. Example: Application Delivery Mechanisms in Intel SGX 15
	4.4.2. Example: Application Delivery Mechanisms in Arm		4.4.2. Example: Application Delivery Mechanisms in Arm
	TrustZone . . . . . . . . . . . . . . . . . . . . . . 16		TrustZone . . . . . . . . . . . . . . . . . . . . . . 16
	4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 16		4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 17
	5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 18		5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 18
	5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 19		5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 20
	5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 20		5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 20
	5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 20		5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 20
	5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 20		5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 20
	5.5. Message Security . . . . . . . . . . . . . . . . . . . . 20		5.5. Message Security . . . . . . . . . . . . . . . . . . . . 21
	6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 21		6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 21
	6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 21		6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 22
	6.2. TEEP Broker Implementation Consideration . . . . . . . . 22		6.2. TEEP Broker Implementation Consideration . . . . . . . . 22
	6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 22		6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 22
	6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 22		6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 23
	7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 23		7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 23
	7.1. Information Required in TEEP Claims . . . . . . . . . . . 24		7.1. Information Required in TEEP Claims . . . . . . . . . . . 25
	8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 25		8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 25
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 25		9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25		9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 26
	9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 26		9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 26
	9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 26		9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 27
	9.4. Compromised CA . . . . . . . . . . . . . . . . . . . . . 27		9.4. Compromised CA . . . . . . . . . . . . . . . . . . . . . 27
	9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 27		9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 28
	9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 27		9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 28
	9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 28		9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 28
	9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 28		9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 29
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
	13. Informative References . . . . . . . . . . . . . . . . . . . 29		13. Informative References . . . . . . . . . . . . . . . . . . . 30
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	Applications executing in a device are exposed to many different		Applications executing in a device are exposed to many different
	attacks intended to compromise the execution of the application or		attacks intended to compromise the execution of the application or
	reveal the data upon which those applications are operating. These		reveal the data upon which those applications are operating. These
	attacks increase with the number of other applications on the device,		attacks increase with the number of other applications on the device,
	with such other applications coming from potentially untrustworthy		with such other applications coming from potentially untrustworthy
	sources. The potential for attacks further increases with the		sources. The potential for attacks further increases with the
	complexity of features and applications on devices, and the		complexity of features and applications on devices, and the
	skipping to change at page 16, line 40 ¶		skipping to change at page 16, line 40 ¶
	which would in turn send this data to the SGX enclave (TA). This		which would in turn send this data to the SGX enclave (TA). This
	complexity is due to the fact that each SGX enclave is separate and		complexity is due to the fact that each SGX enclave is separate and
	does not have direct communication to other SGX enclaves.		does not have direct communication to other SGX enclaves.
	4.4.2. Example: Application Delivery Mechanisms in Arm TrustZone		4.4.2. Example: Application Delivery Mechanisms in Arm TrustZone
	In Arm TrustZone [TrustZone] for A-class devices, the Untrusted		In Arm TrustZone [TrustZone] for A-class devices, the Untrusted
	Application and TA may or may not be bundled together. This differs		Application and TA may or may not be bundled together. This differs
	from SGX since in TrustZone the TA lifetime is not inherently tied to		from SGX since in TrustZone the TA lifetime is not inherently tied to
	a specific Untrused Application process lifetime as occurs in SGX. A		a specific Untrused Application process lifetime as occurs in SGX. A
	TA is loaded by a trusted OS running in the TEE, where the trusted OS		TA is loaded by a trusted OS running in the TEE such as a
	is separate from the OS in the REE. Thus Cases 2 and 3 are equally		GlobalPlatform compliant TEE, where the trusted OS is separate from
	applicable. In addition, it is possible for TAs to communicate with		the OS in the REE. Thus Cases 2 and 3 are equally applicable. In
	each other without involving any Untrusted Application, and so the		addition, it is possible for TAs to communicate with each other
	complexity of Case 1 is lower than in the SGX example. Thus, Case 1		without involving any Untrusted Application, and so the complexity of
	is possible as well, though still more complex than Cases 2 and 3.		Case 1 is lower than in the SGX example. Thus, Case 1 is possible as
			well, though still more complex than Cases 2 and 3.
	4.5. Entity Relations		4.5. Entity Relations
	This architecture leverages asymmetric cryptography to authenticate a		This architecture leverages asymmetric cryptography to authenticate a
	device to a TAM. Additionally, a TEEP Agent in a device		device to a TAM. Additionally, a TEEP Agent in a device
	authenticates a TAM. The provisioning of Trust Anchors to a device		authenticates a TAM. The provisioning of Trust Anchors to a device
	may be different from one use case to the other. A Device		may be different from one use case to the other. A Device
	Administrator may want to have the capability to control what TAs are		Administrator may want to have the capability to control what TAs are
	allowed. A device manufacturer enables verification by one or more		allowed. A device manufacturer enables verification by one or more
	TAMs and by TA Signers; it may embed a list of default Trust Anchors		TAMs and by TA Signers; it may embed a list of default Trust Anchors
	skipping to change at page 24, line 25 ¶		skipping to change at page 24, line 51 ¶
	attestation keys of the TEE;		attestation keys of the TEE;
	- The source or local verification of claims within an attestation		- The source or local verification of claims within an attestation
	prior to a TEE signing a set of claims;		prior to a TEE signing a set of claims;
	- The level of protection afforded to attestation keys against		- The level of protection afforded to attestation keys against
	exfiltration, modification, and side channel attacks;		exfiltration, modification, and side channel attacks;
	- The limitations of use applied to TEE attestation keys;		- The limitations of use applied to TEE attestation keys;
	- The processes in place to discover or detect TEE breeches; and		- The processes in place to discover or detect TEE breaches; and
	- The revocation and recovery process of TEE attestation keys.		- The revocation and recovery process of TEE attestation keys.
	Some TAMs may require additional claims in order to properly		Some TAMs may require additional claims in order to properly
	authorize a device or TEE. The specific format for these additional		authorize a device or TEE. The specific format for these additional
	claims are outside the scope of this specification, but the TEEP		claims are outside the scope of this specification, but the TEEP
	protocol allows these additional claims to be included in the		protocol allows these additional claims to be included in the
	attestation messages.		attestation messages.
	For more discussion of the attestation and appraisal process, see the		For more discussion of the attestation and appraisal process, see the
	RATS Architecture [I-D.ietf-rats-architecture].		RATS Architecture [I-D.ietf-rats-architecture].
	7.1. Information Required in TEEP Claims		7.1. Information Required in TEEP Claims
	- Device Identifying Info: TEEP attestations may need to uniquely		- Device Identifying Information: TEEP attestations may need to
	identify a device to the TAM. Unique device identification allows		uniquely identify a device to the TAM. Unique device
	the TAM to provide services to the device, such as managing		identification allows the TAM to provide services to the device,
	installed TAs, and providing subscriptions to services, and		such as managing installed TAs, and providing subscriptions to
	locating device-specific keying material to communicate with or		services, and locating device-specific keying material to
	authenticate the device. In some use cases it may be sufficient		communicate with or authenticate the device. In some use cases it
	to identify only the class of the device. The security and		may be sufficient to identify only the class of the device. The
	privacy requirements regarding device identification will vary		security and privacy requirements regarding device identification
	with the type of TA provisioned to the TEE.		will vary with the type of TA provisioned to the TEE.
	- TEE Identifying info: The type of TEE that generated this		- TEE Identifying Information: The type of TEE that generated this
	attestation must be identified, including version identification		attestation must be identified, including version identification
	information such as the hardware, firmware, and software version		information such as the hardware, firmware, and software version
	of the TEE, as applicable by the TEE type. TEE manufacturer		of the TEE, as applicable by the TEE type. TEE manufacturer
	information for the TEE is required in order to disambiguate the		information for the TEE is required in order to disambiguate the
	same TEE type created by different manufacturers and address		same TEE type created by different manufacturers and address
	considerations around manufacturer provisioning, keying and		considerations around manufacturer provisioning, keying and
	support for the TEE.		support for the TEE.
	- Freshness Proof: A claim that includes freshness information must		- Freshness Proof: A claim that includes freshness information must
	be included, such as a nonce or timestamp.		be included, such as a nonce or timestamp.
End of changes. 19 change blocks.
	36 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/