< draft-ietf-teep-architecture-04.txt		draft-ietf-teep-architecture-05.txt >
	TEEP M. Pei		TEEP M. Pei
	Internet-Draft Symantec		Internet-Draft Symantec
	Intended status: Informational H. Tschofenig		Intended status: Informational H. Tschofenig
	Expires: June 8, 2020 Arm Limited		Expires: June 14, 2020 Arm Limited
			D. Thaler
			Microsoft
	D. Wheeler		D. Wheeler
	Intel		Intel
	A. Atyeo		December 12, 2019
	Intercede
	L. Dapeng
	Alibaba Group
	December 06, 2019
	Trusted Execution Environment Provisioning (TEEP) Architecture		Trusted Execution Environment Provisioning (TEEP) Architecture
	draft-ietf-teep-architecture-04		draft-ietf-teep-architecture-05
	Abstract		Abstract
	A Trusted Execution Environment (TEE) is an environment that enforces		A Trusted Execution Environment (TEE) is an environment that enforces
	that only authorized code can execute with that environment, and that		that only authorized code can execute with that environment, and that
	any data used by such code cannot be read or tampered with by any		any data used by such code cannot be read or tampered with by any
	code outside that environment. This architecture document motivates		code outside that environment. This architecture document motivates
	the design and standardization of a protocol for managing the		the design and standardization of a protocol for managing the
	lifecycle of trusted applications running inside a TEE.		lifecycle of trusted applications running inside a TEE.
	skipping to change at page 1, line 42 ¶		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 June 8, 2020.		This Internet-Draft will expire on June 14, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 35 ¶		skipping to change at page 2, line 31 ¶
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Payment . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7		3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 7		3.3. Internet of Things . . . . . . . . . . . . . . . . . . . 7
	3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 8		3.4. Confidential Cloud Computing . . . . . . . . . . . . . . 7
	4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. System Components . . . . . . . . . . . . . . . . . . . . 8		4.1. System Components . . . . . . . . . . . . . . . . . . . . 8
	4.2. Different Renditions of TEEP Architecture . . . . . . . . 10		4.2. Different Renditions of TEEP Architecture . . . . . . . . 10
	4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 12		4.3. Multiple TAMs and Relationship to TAs . . . . . . . . . . 12
	4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 13		4.4. Untrusted Apps, Trusted Apps, and Personalization Data . 13
	4.5. Examples of Application Delivery Mechanisms in Existing		4.5. Examples of Application Delivery Mechanisms in Existing
	TEEs . . . . . . . . . . . . . . . . . . . . . . . . . . 14		TEEs . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.6. Entity Relations . . . . . . . . . . . . . . . . . . . . 15		4.6. Entity Relations . . . . . . . . . . . . . . . . . . . . 15
	5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 17		5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 17
	5.1. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 18		5.1. Trust Anchors in TEE . . . . . . . . . . . . . . . . . . 18
	5.2. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 18		5.2. Trust Anchors in TAM . . . . . . . . . . . . . . . . . . 19
	5.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 18		5.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 19
	5.4. Message Security . . . . . . . . . . . . . . . . . . . . 19		5.4. Message Security . . . . . . . . . . . . . . . . . . . . 19
	6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 19		6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 20		6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 20
	6.2. TEEP Broker Implementation Consideration . . . . . . . . 20		6.2. TEEP Broker Implementation Consideration . . . . . . . . 20
	6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 20		6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 20
	6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 21		6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 21
	6.2.3. Number of TEEP Brokers . . . . . . . . . . . . . . . 21		6.2.3. Number of TEEP Brokers . . . . . . . . . . . . . . . 21
	7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 21		7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 22
	7.1. Information Required in TEEP Claims . . . . . . . . . . . 23		7.1. Information Required in TEEP Claims . . . . . . . . . . . 23
	8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 24		8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 24
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 24		9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 24		9.1. TA Trust Check at TEE . . . . . . . . . . . . . . . . . . 25
	9.2. One TA Multiple SP Case . . . . . . . . . . . . . . . . . 25		9.2. One TA Multiple SP Case . . . . . . . . . . . . . . . . . 25
	9.3. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25		9.3. Broker Trust Model . . . . . . . . . . . . . . . . . . . 25
	9.4. Data Protection at TAM and TEE . . . . . . . . . . . . . 25		9.4. Data Protection at TAM and TEE . . . . . . . . . . . . . 25
	9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 25		9.5. Compromised CA . . . . . . . . . . . . . . . . . . . . . 26
	9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 25		9.6. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 26
	9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 26		9.7. Certificate Renewal . . . . . . . . . . . . . . . . . . . 26
	9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 26		9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 26
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
	12. Informative References . . . . . . . . . . . . . . . . . . . 26		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
	Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 28		13. Informative References . . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	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 increase with the		sources. The potential for attacks further increase with the
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 5 ¶
	This separation reduces the possibility of a successful attack on		This separation reduces the possibility of a successful attack on
	application components and the data contained inside the TEE.		application components and the data contained inside the TEE.
	Typically, application components are chosen to execute inside a TEE		Typically, application components are chosen to execute inside a TEE
	because those application components perform security sensitive		because those application components perform security sensitive
	operations or operate on sensitive data. An application component		operations or operate on sensitive data. An application component
	running inside a TEE is referred to as a Trusted Application (TA),		running inside a TEE is referred to as a Trusted Application (TA),
	while an application running outside any TEE is referred to as an		while an application running outside any TEE is referred to as an
	Untrusted Application (UA).		Untrusted Application (UA).
	The TEE typically uses hardware to enforce protections on the TA and		TEEs use hardware enforcement combined with software protection to
	its data, but also presents a more limited set of services to		secure TAs and its data. TEEs typically offer a more limited set of
	applications inside the TEE than is normally available to Untrusted		services to TAs than is normally available to Untrusted Applications.
	Applications.
	But not all TEEs are the same, and different vendors may have		But not all TEEs are the same, and different vendors may have
	different implementations of TEEs with different security properties,		different implementations of TEEs with different security properties,
	different features, and different control mechanisms to operate on		different features, and different control mechanisms to operate on
	TAs. Some vendors may themselves market multiple different TEEs with		TAs. Some vendors may themselves market multiple different TEEs with
	different properties attuned to different markets. A device vendor		different properties attuned to different markets. A device vendor
	may integrate one or more TEEs into their devices depending on market		may integrate one or more TEEs into their devices depending on market
	needs.		needs.
	To simplify the life of developers and service providers interacting		To simplify the life of developers and service providers interacting
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 32 ¶
	devices, and their TEEs. This trusted third party is the Trusted		devices, and their TEEs. This trusted third party is the Trusted
	Application Manager (TAM).		Application Manager (TAM).
	The Trusted Execution Provisioning (TEEP) protocol addresses the		The Trusted Execution Provisioning (TEEP) protocol addresses the
	following problems:		following problems:
	- A Service Provider (SP) intending to provide services through a TA		- A Service Provider (SP) intending to provide services through a TA
	to users of a device needs to determine security-relevant		to users of a device needs to determine security-relevant
	information of a device before provisioning their TA to the TEE		information of a device before provisioning their TA to the TEE
	within the device. An example is the verification of the type of		within the device. An example is the verification of the type of
	TEE included in a device.		TEE included in a device and that it is capable of providing the
			security protections required by a particular TA.
	- A TEE in a device needs to determine whether a Service Provider		- A TEE in a device needs to determine whether a Service Provider
	(SP) that wants to manage a TA in the device is authorized to		(SP) that wants to manage a TA in the device is authorized to
	manage TAs in the TEE, and what TAs the SP is permitted to manage.		manage TAs in the TEE, and what TAs the SP is permitted to manage.
	- The parties involved in the protocol must be able to attest that a
	TEE is genuine and capable of providing the security protections
	required by a particular TA.
	- A Service Provider (SP) must be able to determine if a TA exists		- A Service Provider (SP) must be able to determine if a TA exists
	(is installed) on a device (in the TEE), and if not, install the		(is installed) on a device (in the TEE), and if not, install the
	TA in the TEE.		TA in the TEE.
	- A Service Provider (SP) must be able to check whether a TA in a		- A Service Provider (SP) must be able to check whether a TA in a
	device's TEE is the most up-to-date version, and if not, update		device's TEE is the most up-to-date version, and if not, update
	the TA in the TEE.		the TA in the TEE.
	- A Service Provider (SP) must be able to remove a TA in a device's		- A Service Provider (SP) must be able to remove a TA in a device's
	TEE if the SP is no longer offering such services or the services		TEE if the SP is no longer offering such services or the services
	are being revoked from a particular user (or device). For		are being revoked from a particular user (or device). For
	example, if a subscription or contract for a particular service		example, if a subscription or contract for a particular service
	has expired, or a payment by the user has not been completed or		has expired, or a payment by the user has not been completed or
	has been rescinded.		has been rescinded.
	- A Service Provider (SP) must be able to define the relationship		- A Service Provider (SP) must be able to define the relationship
	between cooperating TAs under the SP's control, and specify		between cooperating TAs under the SP's control, and specify
	whether the TAs can communicate, share data, and/or share key		whether the TAs can communicate, share data, and/or share key
	material.		material.
			Note: The Service Provider requires the help of a TAM to provision
			the Trusted Applications to remote devices and the TEEP protocol
			exchanges messages between a Trusted Application Manager (TAM) and a
			TEEP Agent via a TEEP Broker.
	2. Terminology		2. Terminology
	The following terms are used:		The following terms are used:
	- Untrusted Application: An application running in a Rich Execution		- Untrusted Application: An application running in a Rich Execution
	Environment, such as an Android, Windows, or iOS application.		Environment, such as an Android, Windows, or iOS application.
	- Trusted Application Manager (TAM): An entity that manages Trusted		- Trusted Application Manager (TAM): An entity that manages Trusted
	Applications (TAs) running in different TEEs of various devices.		Applications (TAs) running in different TEEs of various devices.
	skipping to change at page 5, line 50 ¶		skipping to change at page 5, line 44 ¶
	Anchor to be removed or disabled.		Anchor to be removed or disabled.
	- Rich Execution Environment (REE): An environment that is provided		- Rich Execution Environment (REE): An environment that is provided
	and governed by a typical OS (e.g., Linux, Windows, Android, iOS),		and governed by a typical OS (e.g., Linux, Windows, Android, iOS),
	potentially in conjunction with other supporting operating systems		potentially in conjunction with other supporting operating systems
	and hypervisors; it is outside of any TEE. This environment and		and hypervisors; it is outside of any TEE. This environment and
	applications running on it are considered untrusted.		applications running on it are considered untrusted.
	- Service Provider (SP): An entity that wishes to provide a service		- Service Provider (SP): An entity that wishes to provide a service
	on Devices that requires the use of one or more Trusted		on Devices that requires the use of one or more Trusted
	Applications. A Service Provider requires the help of a TAM in		Applications.
	order to provision the Trusted Applications to remote devices.
	- Device User: A human being that uses a device. Many devices have		- Device User: A human being that uses a device. Many devices have
	a single device user. Some devices have a primary device user		a single device user. Some devices have a primary device user
	with other human beings as secondary device users (e.g., parent		with other human beings as secondary device users (e.g., parent
	allowing children to use their tablet or laptop). Other devices		allowing children to use their tablet or laptop). Other devices
	are not used by a human being and hence have no device user.		are not used by a human being and hence have no device user.
	Relates to Device Owner and Device Administrator.		Relates to Device Owner and Device Administrator.
	- Device Owner: A device is always owned by someone. In some cases,		- Device Owner: A device is always owned by someone. In some cases,
	it is common for the (primary) device user to also own the device,		it is common for the (primary) device user to also own the device,
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 18 ¶
	3.1. Payment		3.1. Payment
	A payment application in a mobile device requires high security and		A payment application in a mobile device requires high security and
	trust about the hosting device. Payments initiated from a mobile		trust about the hosting device. Payments initiated from a mobile
	device can use a Trusted Application to provide strong identification		device can use a Trusted Application to provide strong identification
	and proof of transaction.		and proof of transaction.
	For a mobile payment application, some biometric identification		For a mobile payment application, some biometric identification
	information could also be stored in a TEE. The mobile payment		information could also be stored in a TEE. The mobile payment
	application can use such information for authentication.		application can use such information for unlocking the phone and for
			local identification of the user.
	A secure user interface (UI) may be used in a mobile device to		A trusted user interface (UI) may be used in a mobile device to
	prevent malicious software from stealing sensitive user input data.		prevent malicious software from stealing sensitive user input data.
	Such an application implementation often relies on a TEE for user		Such an implementation often relies on a TEE for providing access to
	input protection.		peripherals, such as PIN input.
	3.2. Authentication		3.2. Authentication
	For better security of authentication, a device may store its		For better security of authentication, a device may store its keys
	sensitive authentication keys inside a TEE, providing TEE-protected		and cryptographic libraries inside a TEE limiting access to
	security key strength and trusted code execution.		cryptographic functions via a well-defined interface and thereby
			reducing access to keying material.
	3.3. Internet of Things		3.3. Internet of Things
	The Internet of Things (IoT) has been posing threats to networks and		The Internet of Things (IoT) has been posing threats to critical
	national infrastructures because of existing weak security in		infrastructure because of weak security in devices. It is desirable
	devices. It is very desirable that IoT devices can prevent malware		that IoT devices can prevent malware from manipulating actuators
	from manipulating actuators (e.g., unlocking a door), or stealing or		(e.g., unlocking a door), or stealing or modifying sensitive data,
	modifying sensitive data such as authentication credentials in the		such as authentication credentials in the device. A TEE can be the
	device. A TEE can be the best way to implement such IoT security		best way to implement such IoT security functions.
	functions.
	TEEs could be used to store variety of sensitive data for IoT
	devices. For example, a TEE could be used in smart door locks to
	store a user's biometric information for identification, and for
	protecting access the locking mechanism.
	3.4. Confidential Cloud Computing		3.4. Confidential Cloud Computing
	A tenant can store sensitive data in a TEE in a cloud computing		A tenant can store sensitive data in a TEE in a cloud computing
	server such that only the tenant can access the data, preventing the		server such that only the tenant can access the data, preventing the
	cloud hosting provider from accessing the data. A tenant can run TAs		cloud hosting provider from accessing the data. A tenant can run TAs
	inside a server TEE for secure operation and enhanced data security.		inside a server TEE for secure operation and enhanced data security.
	This provides benefits not only to tenants with better data security		This provides benefits not only to tenants with better data security
	but also to cloud hosting provider for reduced liability and		but also to cloud hosting provider for reduced liability and
	increased cloud adoption.		increased cloud adoption.
	skipping to change at page 9, line 18 ¶		skipping to change at page 9, line 4 ¶
	performing lifecycle management activity on TA's on behalf of		performing lifecycle management activity on TA's on behalf of
	Service Providers and Device Administrators. This includes		Service Providers and Device Administrators. This includes
	creation and deletion of TA's, and may include, for example, over-		creation and deletion of TA's, and may include, for example, over-
	the-air updates to keep an SP's TAs up-to-date and clean up when a		the-air updates to keep an SP's TAs up-to-date and clean up when a
	version should be removed. TAMs may provide services that make it		version should be removed. TAMs may provide services that make it
	easier for SPs or DAs to use the TAM's service to manage multiple		easier for SPs or DAs to use the TAM's service to manage multiple
	devices, although that is not required of a TAM.		devices, although that is not required of a TAM.
	The TAM performs its management of TA's through an interaction		The TAM performs its management of TA's through an interaction
	with a Device's TEEP Broker. As shown in Figure 1, the TAM cannot		with a Device's TEEP Broker. As shown in Figure 1, the TAM cannot
	directly contact a Device, but must wait for the TEEP Broker to		directly contact a TEEP Agent, but must wait for the TEEP Broker
	contact the TAM requesting a particular service. This		to contact the TAM requesting a particular service. This
	architecture is intentional in order to accommodate network and		architecture is intentional in order to accommodate network and
	application firewalls that normally protect user and enterprise		application firewalls that normally protect user and enterprise
	devices from arbitrary connections from external network entities.		devices from arbitrary connections from external network entities.
	A TAM may be publicly available for use by many SPs, or a TAM may		A TAM may be publicly available for use by many SPs, or a TAM may
	be private, and accessible by only one or a limited number of SPs.		be private, and accessible by only one or a limited number of SPs.
	It is expected that manufacturers and carriers will run their own		It is expected that manufacturers and carriers will run their own
	private TAM. Another example of a private TAM is a TAM running as		private TAM. Another example of a private TAM is a TAM running as
	a Software-as-a-Service (SaaS) within an SP.		a Software-as-a-Service (SaaS) within an SP.
	skipping to change at page 10, line 40 ¶		skipping to change at page 10, line 27 ¶
	There is nothing prohibiting a device from implementing multiple		There is nothing prohibiting a device from implementing multiple
	TEEs. In addition, some TEEs (for example, SGX) present themselves		TEEs. In addition, some TEEs (for example, SGX) present themselves
	as separate containers within memory without a controlling manager		as separate containers within memory without a controlling manager
	within the TEE. In these cases, the Rich Execution Environment hosts		within the TEE. In these cases, the Rich Execution Environment hosts
	multiple TEEP brokers, where each Broker manages a particular TEE or		multiple TEEP brokers, where each Broker manages a particular TEE or
	set of TEEs. Enumeration and access to the appropriate TEEP Broker		set of TEEs. Enumeration and access to the appropriate TEEP Broker
	is up to the Rich Execution Environment and the Untrusted		is up to the Rich Execution Environment and the Untrusted
	Applications. Verification that the correct TA has been reached then		Applications. Verification that the correct TA has been reached then
	becomes a matter of properly verifying TA attestations, which are		becomes a matter of properly verifying TA attestations, which are
	unforgeable. The multiple TEE approach is shown in the diagram		unforgeable. The multiple TEEP Broker approach is shown in the
	below. For brevity, TEEP Broker 2 is shown interacting with only one		diagram below. For brevity, TEEP Broker 2 is shown interacting with
	TAM and UA, but no such limitation is intended to be implied in the		only one TAM and UA, but no such limitation is intended to be implied
	architecture.		in the architecture.
	+-------------------------------------------+		+-------------------------------------------+
	| Device |		| Device |
	| +--------+ | Service Provider		| +--------+ | Service Provider
	| | |----------+ |		| | |----------+ |
	| +-------------+ | TEEP |---------+| |		| +-------------+ | TEEP |---------+| |
	| | TEE-1 | +---| Broker | | || +--------+ |		| | TEE-1 | +---| Broker | | || +--------+ |
	| | | | | 1 |<---+ | |+-->| |<-+		| | | | | 1 |<---+ | |+-->| |<-+
	| | +-------+ | | | | | | | | |		| | +-------+ | | | | | | | | |
	| | | TEEP | | | | | | | | | |		| | | TEEP | | | | | | | | | |
	skipping to change at page 14, line 7 ¶		skipping to change at page 14, line 7 ¶
	uses one or more TA's in a TEE appears no different from any other		uses one or more TA's in a TEE appears no different from any other
	Untrusted Application in the REE. However, the way the Untrusted		Untrusted Application in the REE. However, the way the Untrusted
	Application and its corresponding TA's are packaged, delivered, and		Application and its corresponding TA's are packaged, delivered, and
	installed on the device can vary. The variations depend on whether		installed on the device can vary. The variations depend on whether
	the Untrusted Application and TA are bundled together or are provided		the Untrusted Application and TA are bundled together or are provided
	separately, and this has implications to the management of the TAs in		separately, and this has implications to the management of the TAs in
	the TEE. In addition to the Untrusted Application and TA, the TA		the TEE. In addition to the Untrusted Application and TA, the TA
	and/or TEE may require some additional data to personalize the TA to		and/or TEE may require some additional data to personalize the TA to
	the service provider or the device or a user. This personalization		the service provider or the device or a user. This personalization
	data is dependent on the TEE, the TA and the SP; an example of		data is dependent on the TEE, the TA and the SP; an example of
	personalization data might be username and password of an account		personalization data might be a secret symmetric key used by the TA
	with the SP, or a secret symmetric key used by the TA to communicate		to communicate with the SP. The personalization data must be
	with the SP. The personalization data must be encrypted to preserve		encrypted to preserve the confidentiality of potentially sensitive
	the confidentiality of potentially sensitive data contained within		data contained within it. Other than this requirement to support
	it. Other than this requirement to support confidentiality, TEEP		confidentiality, TEEP place no limitations or requirements on the
	place no limitations or requirements on the personalization data.		personalization data.
	There are three possible cases for bundling of the Untrusted		There are three possible cases for bundling of the Untrusted
	Application, TA, and personalization data:		Application, TA, and personalization data:
	1. The Untrusted Application, TA, and personalization data are all		1. The Untrusted Application, TA, and personalization data are all
	bundled together in a single package by the SP and provided to		bundled together in a single package by the SP and provided to
	the TEEP Broker through the TAM.		the TEEP Broker through the TAM.
	2. The Untrusted Application and the TA are bundled together in a		2. The Untrusted Application and the TA are bundled together in a
	single package, which a TAM or a publicly accessible app store		single package, which a TAM or a publicly accessible app store
	skipping to change at page 15, line 33 ¶		skipping to change at page 15, line 33 ¶
	otherwise there is a significant problem in getting the SGX enclave		otherwise there is a significant problem in getting the SGX enclave
	code (the TA) from the TEE, through the installer and into the		code (the TA) from the TEE, through the installer and into the
	Untrusted Application in a trusted fashion. Finally, the		Untrusted Application in a trusted fashion. Finally, the
	personalization data would need to be sent out of the TEE (encrypted		personalization data would need to be sent out of the TEE (encrypted
	in an SGX encalve-to-enclave manner) to the REE's installation app,		in an SGX encalve-to-enclave manner) to the REE's installation app,
	which would pass this data to the installed Untrusted Application,		which would pass this data to the installed Untrusted Application,
	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.
	In ARM TrustZone based environments, the Untrusted Application and TA		In Arm TrustZone for A- and R-class devices, the Untrusted
	may or may not be bundled together. This differs from SGX since in		Application and TA may or may not be bundled together. This differs
	TrustZone the TA lifetime is not inherently tied to a specific		from SGX since in TrustZone the TA lifetime is not inherently tied to
	Untrused Application process lifetime as occurs in SGX. A TA is		a specific Untrused Application process lifetime as occurs in SGX. A
	loaded by a trusted OS running in the TEE, where the trusted OS is		TA is loaded by a trusted OS running in the TEE, where the trusted OS
	separate from the OS in the REE. Thus Cases 2 and 3 are equally		is separate from the OS in the REE. Thus Cases 2 and 3 are equally
	applicable. In addition, it is possible for TAs to communicate with		applicable. In addition, it is possible for TAs to communicate with
	each other without involving the Untrusted Application, and so the		each other without involving the Untrusted Application, and so the
	complexity of Case 1 is lower than in the SGX example, and so Case 1		complexity of Case 1 is lower than in the SGX example, and so Case 1
	is possible as well though still more complex than Cases 2 and 3.		is possible as well though still more complex than Cases 2 and 3.
	4.6. Entity Relations		4.6. Entity Relations
	This architecture leverages asymmetric cryptography to authenticate a		This architecture leverages asymmetric cryptography to authenticate a
	device to a TAM. Additionally, a TEE in a device authenticates a TAM		device to a TAM. Additionally, a TEE in a device authenticates a TAM
	and TA signer. The provisioning of Trust Anchors to a device may be		and TA signer. The provisioning of Trust Anchors to a device may be
	skipping to change at page 16, line 27 ¶		skipping to change at page 16, line 27 ¶
	Untrusted Application		Untrusted Application
	TA		TA
	|		|
	|		|
	Untrusted Application -- 2a. --> | ----- 3. Install -------> |		Untrusted Application -- 2a. --> | ----- 3. Install -------> |
	TA ----------------- 2b. Supply ------> | 4. Messaging-->|		TA ----------------- 2b. Supply ------> | 4. Messaging-->|
	| | | |		| | | |
	Figure 3: Developer Experience		Figure 3: Developer Experience
			Note that Figure 3 shows the app developer as a TA signer and not the
			SP. However, the App Developer is either closely associated with the
			SP or the SP delegates the signing authority to the app developer.
			For the purpose of this document there is no difference between the
			SP and the app developer.
	Figure 3 shows an application developer building two applications: 1)		Figure 3 shows an application developer building two applications: 1)
	an Untrusted Application; 2) a TA that provides some security		an Untrusted Application; 2) a TA that provides some security
	functions to be run inside a TEE. At step 2, the application		functions to be run inside a TEE. At step 2, the application
	developer uploads the Untrusted Application (2a) to an Application		developer uploads the Untrusted Application (2a) to an Application
	Store. The Untrusted Application may optionally bundle the TA		Store. The Untrusted Application may optionally bundle the TA
	binary. Meanwhile, the application developer may provide its TA to a		binary. Meanwhile, the application developer may provide its TA to a
	TAM provider that will be managing the TA in various devices. 3. A		TAM provider that will be managing the TA in various devices. 3. A
	user will go to an Application Store to download the Untrusted		user will go to an Application Store to download the Untrusted
	Application. The Untrusted Application will trigger TA installation		Application. The Untrusted Application will trigger TA installation
	by initiating communication with a TAM. This is the step 4. The		by initiating communication with a TAM. This is the step 4. The
	skipping to change at page 17, line 18 ¶		skipping to change at page 17, line 25 ¶
	with different TAMs and different TEEs in different devices. This is		with different TAMs and different TEEs in different devices. This is
	the role of the Broker, which is a software component that bridges		the role of the Broker, which is a software component that bridges
	communication between a TAM and a TEE. Furthermore the Broker		communication between a TAM and a TEE. Furthermore the Broker
	communicates with a Agent inside a TEE that is responsible to process		communicates with a Agent inside a TEE that is responsible to process
	TAM requests. The Broker in REE does not need to know the actual		TAM requests. The Broker in REE does not need to know the actual
	content of messages except for the TEE routing information.		content of messages except for the TEE routing information.
	5. Keys and Certificate Types		5. Keys and Certificate Types
	This architecture leverages the following credentials, which allow		This architecture leverages the following credentials, which allow
	delivering end-to-end security between a TAM and a TEEP Agent,		delivering end-to-end security between a TAM and a TEEP Agent.
	without relying on any transport security.
	Figure 4 summarizes the relationships between various keys and where		Figure 4 summarizes the relationships between various keys and where
	they are stored. Each public/private key identifies an SP, TAM, or		they are stored. Each public/private key identifies an SP, TAM, or
	TEE, and gets a certificate that chains up to some CA. A list of		TEE, and gets a certificate that chains up to some CA. A list of
	trusted certificates is then used to check a presented certificate		trusted certificates is then used to check a presented certificate
	against.		against.
	Different CAs can be used for different types of certificates. TEEP		Different CAs can be used for different types of certificates. TEEP
	messages are always signed, where the signer key is the message		messages are always signed, where the signer key is the message
	originator's private key such as that of a TAM, or a TEE's private		originator's private key such as that of a TAM, or a TEE's private
	skipping to change at page 17, line 46 ¶		skipping to change at page 18, line 5 ¶
	Purpose Private Key Signs CA Certs		Purpose Private Key Signs CA Certs
	------------------ ----------- ------------- -------------		------------------ ----------- ------------- -------------
	Authenticating TEE 1 per TEE TEEP responses TAM		Authenticating TEE 1 per TEE TEEP responses TAM
	Authenticating TAM 1 per TAM TEEP requests TEEP Agent		Authenticating TAM 1 per TAM TEEP requests TEEP Agent
	Code Signing 1 per SP TA binary TEE		Code Signing 1 per SP TA binary TEE
	Figure 4: Keys		Figure 4: Keys
			Note that personalization data is not included in the table above.
			The use of personalization data is dependent on how TAs are used and
			what their security requirements are.
	The TEE key pair and certificate are used for authenticating the TEE		The TEE key pair and certificate are used for authenticating the TEE
	to a remote TAM. Often, the key pair is burned into the TEE by the		to a remote TAM. Often, the key pair is burned into the TEE by the
	TEE manufacturer and the key pair and its certificate are valid for		TEE manufacturer and the key pair and its certificate are valid for
	the expected lifetime of the TEE. A TAM provider is responsible for		the expected lifetime of the TEE. A TAM provider is responsible for
	configuring its TAM with the manufacturer certificates or CAs that		configuring its TAM with the manufacturer certificates or CAs that
	are used to sign TEE keys.		are used to sign TEE keys.
	The TAM key pair and certificate are used for authenticating a TAM to		The TAM key pair and certificate are used for authenticating a TAM to
	a remote TEE. A TAM provider is responsible for acquiring a		a remote TEE. A TAM provider is responsible for acquiring a
	certificate from a CA that is trusted by the TEEs it manages.		certificate from a CA that is trusted by the TEEs it manages.
	skipping to change at page 23, line 34 ¶		skipping to change at page 23, line 45 ¶
	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. These additional claims may help clear up		authorize a device or TEE. These additional claims may help clear up
	any assumptions for which the TAM wants to alleviate. The specific		any assumptions for which the TAM wants to alleviate. The specific
	format for these additional claims are outside the scope of this		format for these additional claims are outside the scope of this
	specification, but the TEEP protocol allows these additional claims		specification, but the TEEP protocol allows these additional claims
	to be included in the attestation messages.		to be included in the attestation messages.
	7.1. Information Required in TEEP Claims		7.1. Information Required in TEEP Claims
	- Device Identifying Info: TEEP attestations must uniquely identify		- Device Identifying Info: TEEP attestations may need to uniquely
	a device to the TAM and SP. This identifier allows the TAM to		identify a device to the TAM and SP. Unique device identification
	provide services unique to the device, such as managing installed		allows the TAM to provide services to the device, such as managing
	TAs, and providing subscriptions to services, and locating device-		installed TAs, and providing subscriptions to services, and
	specific keying material to communicate with or authenticate the		locating device-specific keying material to communicate with or
	device. Additionally, device manufacturer information must be		authenticate the device. In some use cases it may be sufficient
	provided to provide better universal uniqueness qualities without		to identify only the class of the device. The security and
	requiring globally unique identifiers for all devices.		privacy requirements regarding device identification will vary
			with the type of TA provisioned to the TEE.
	- TEE Identifying info: The type of TEE that generated this		- TEE Identifying info: The type of TEE that generated this
	attestation must be identified. Standard TEE types are identified		attestation must be identified. Standard TEE types are identified
	by an IANA number, but also must include version identification		by an IANA number, but also must include 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 resolve		same TEE type created by different manufacturers and resolve
	potential assumptions around manufacturer provisioning, keying and		potential assumptions around manufacturer provisioning, keying and
	support for the TEE.		support for the TEE.
	skipping to change at page 26, line 36 ¶		skipping to change at page 27, line 9 ¶
	dependency in the manifest of the encrypted TA. Thus, the TEEP Agent		dependency in the manifest of the encrypted TA. Thus, the TEEP Agent
	would look at the TA manifest, determine there is a dependency with a		would look at the TA manifest, determine there is a dependency with a
	TAM URI of the SP's TAM. The Agent would then install the		TAM URI of the SP's TAM. The Agent would then install the
	dependency, and then continue with the TA installation steps,		dependency, and then continue with the TA installation steps,
	including decrypting the TA binary with the relevant key.		including decrypting the TA binary with the relevant key.
	10. IANA Considerations		10. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	11. Acknowledgements		11. Contributors
	Some content of this document is based on text in a previous OTrP		- Andrew Atyeo
	protocol document [I-D.ietf-teep-opentrustprotocol]. We thank the
	former co-authors Nick Cook and Minho Yoo for the initial document
	content, and contributors Brian Witten, Tyler Kim, and Alin Mutu.
	12. Informative References		- Intercede
			- andrew.atyeo@intercede.com
			- Liu Dapeng
			- Alibaba Group
			- maxpassion@gmail.com
			12. Acknowledgements
			We would like to thank Nick Cook, Minho Yoo, Brian Witten, Tyler Kim,
			Alin Mutu, Juergen Schoenwaelder, Nicolae Paladi, Sorin Faibish, Ned
			Smith, Russ Housley, Jeremy O'Donoghue, and Anders Rundgren for their
			feedback.
			13. Informative References
	[GPTEE] Global Platform, "GlobalPlatform Device Technology: TEE		[GPTEE] Global Platform, "GlobalPlatform Device Technology: TEE
	System Architecture, v1.1", Global Platform GPD_SPE_009,		System Architecture, v1.1", Global Platform GPD_SPE_009,
	January 2017, <https://globalplatform.org/specs-library/		January 2017, <https://globalplatform.org/specs-library/
	tee-system-architecture-v1-1/>.		tee-system-architecture-v1-1/>.
	[I-D.ietf-suit-manifest]		[I-D.ietf-suit-manifest]
	Moran, B., Tschofenig, H., and H. Birkholz, "A Concise		Moran, B., Tschofenig, H., and H. Birkholz, "A Concise
	Binary Object Representation (CBOR)-based Serialization		Binary Object Representation (CBOR)-based Serialization
	Format for the Software Updates for Internet of Things		Format for the Software Updates for Internet of Things
	(SUIT) Manifest", draft-ietf-suit-manifest-02 (work in		(SUIT) Manifest", draft-ietf-suit-manifest-02 (work in
	progress), November 2019.		progress), November 2019.
	[I-D.ietf-teep-opentrustprotocol]
	Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig,
	"The Open Trust Protocol (OTrP)", draft-ietf-teep-
	opentrustprotocol-03 (work in progress), May 2019.
	[I-D.ietf-teep-otrp-over-http]		[I-D.ietf-teep-otrp-over-http]
	Thaler, D., "HTTP Transport for Trusted Execution		Thaler, D., "HTTP Transport for Trusted Execution
	Environment Provisioning: Agent-to- TAM Communication",		Environment Provisioning: Agent-to- TAM Communication",
	draft-ietf-teep-otrp-over-http-03 (work in progress),		draft-ietf-teep-otrp-over-http-03 (work in progress),
	November 2019.		November 2019.
	[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management		[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
	Requirements", RFC 6024, DOI 10.17487/RFC6024, October		Requirements", RFC 6024, DOI 10.17487/RFC6024, October
	2010, <https://www.rfc-editor.org/info/rfc6024>.		2010, <https://www.rfc-editor.org/info/rfc6024>.
	[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm		[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
	Agility and Selecting Mandatory-to-Implement Algorithms",		Agility and Selecting Mandatory-to-Implement Algorithms",
	BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,		BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
	<https://www.rfc-editor.org/info/rfc7696>.		<https://www.rfc-editor.org/info/rfc7696>.
	Appendix A. History
	RFC EDITOR: PLEASE REMOVE THIS SECTION
	IETF Drafts
	draft-00: - Initial working group document
	Authors' Addresses		Authors' Addresses
	Mingliang Pei		Mingliang Pei
	Symantec		Symantec
	EMail: mingliang_pei@symantec.com		EMail: mingliang_pei@symantec.com
	Hannes Tschofenig		Hannes Tschofenig
	Arm Limited		Arm Limited
	EMail: hannes.tschofenig@arm.com		EMail: hannes.tschofenig@arm.com
			Dave Thaler
			Microsoft
			EMail: dthaler@microsoft.com
	David Wheeler		David Wheeler
	Intel		Intel
	EMail: david.m.wheeler@intel.com		EMail: david.m.wheeler@intel.com
	Andrew Atyeo
	Intercede
	EMail: andrew.atyeo@intercede.com
	Liu Dapeng
	Alibaba Group
	EMail: maxpassion@gmail.com
End of changes. 35 change blocks.
	97 lines changed or deleted		107 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/