draft-ietf-teep-architecture-07.txt		draft-ietf-teep-architecture-08.txt
	TEEP M. Pei		TEEP M. Pei
	Internet-Draft Symantec		Internet-Draft Symantec
	Intended status: Informational H. Tschofenig		Intended status: Informational H. Tschofenig
	Expires: September 8, 2020 Arm Limited		Expires: October 6, 2020 Arm Limited
	D. Thaler		D. Thaler
	Microsoft		Microsoft
	D. Wheeler		D. Wheeler
	Intel		Intel
	March 07, 2020		April 04, 2020
	Trusted Execution Environment Provisioning (TEEP) Architecture		Trusted Execution Environment Provisioning (TEEP) Architecture
	draft-ietf-teep-architecture-07		draft-ietf-teep-architecture-08
	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 within that environment, 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.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 September 8, 2020.		This Internet-Draft will expire on October 6, 2020.
	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 3, line 39 ¶		skipping to change at page 3, line 39 ¶
	complexity of features and applications on devices, and the		complexity of features and applications on devices, and the
	unintended interactions among those features and applications. The		unintended interactions among those features and applications. The
	danger of attacks on a system increases as the sensitivity of the		danger of attacks on a system increases as the sensitivity of the
	applications or data on the device increases. As an example,		applications or data on the device increases. As an example,
	exposure of emails from a mail client is likely to be of concern to		exposure of emails from a mail client is likely to be of concern to
	its owner, but a compromise of a banking application raises even		its owner, but a compromise of a banking application raises even
	greater concerns.		greater concerns.
	The Trusted Execution Environment (TEE) concept is designed to		The Trusted Execution Environment (TEE) concept is designed to
	execute applications in a protected environment that enforces that		execute applications in a protected environment that enforces that
	only authorized code can execute within that environment, 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 any		any data used by such code cannot be read or tampered with by any
	code outside that environment, including by a commodity operating		code outside that environment, including by a commodity operating
	system (if present).		system (if present).
	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),
	skipping to change at page 14, line 21 ¶		skipping to change at page 14, line 21 ¶
	Untrusted Application in the REE. However, the way the Untrusted		Untrusted Application in the REE. However, the way the Untrusted
	Application and its corresponding TAs are packaged, delivered, and		Application and its corresponding TAs 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
	a TEE. In addition to the Untrusted Application and TA(s), the TA(s)		a TEE. In addition to the Untrusted Application and TA(s), the TA(s)
	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 TA developer or the device or a user. This personalization data		the TA developer or the device or a user. This personalization data
	is dependent on the TEE, the TA, and the TA developer; an example of		is dependent on the TEE, the TA, and the TA developer; an example of
	personalization data might be a secret symmetric key used by the TA		personalization data might be a secret symmetric key used by the TA
	to communicate with the TA developer. The personalization data must		to communicate with the TA developer. Implementations must support
	be encrypted to preserve the confidentiality of potentially sensitive		encryption of personalization data to preserve the confidentiality of
	data contained within it. Other than this requirement to support		potentially sensitive data contained within it. Other than this
	confidentiality, the TEEP architecture places no limitations or		requirement to support confidentiality, the TEEP architecture places
	requirements on the personalization data.		no limitations or requirements on the personalization data.
	There are three possible cases for bundling of an Untrusted		There are three possible cases for bundling of an Untrusted
	Application, TA(s), and personalization data:		Application, TA(s), and personalization data:
	1. The Untrusted Application, TA(s), and personalization data are		1. The Untrusted Application, TA(s), and personalization data are
	all bundled together in a single package by a TA developer and		all bundled together in a single package by a TA developer and
	provided to the TEEP Broker through the TAM.		provided to the TEEP Broker through the TAM.
	2. The Untrusted Application and the TA(s) are bundled together in a		2. The Untrusted Application and the TA(s) 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 25, line 48 ¶		skipping to change at page 25, line 48 ¶
	9.3. Compromised REE		9.3. Compromised REE
	It is possible that the REE of a device is compromised. If the REE		It is possible that the REE of a device is compromised. If the REE
	is compromised, several DoS attacks may be launched. The compromised		is compromised, several DoS attacks may be launched. The compromised
	REE may terminate the TEEP Broker such that TEEP transactions cannot		REE may terminate the TEEP Broker such that TEEP transactions cannot
	reach the TEE, or might drop or delay messages between a TAM and a		reach the TEE, or might drop or delay messages between a TAM and a
	TEEP Agent. However, while a DoS attack cannot be prevented, the REE		TEEP Agent. However, while a DoS attack cannot be prevented, the REE
	cannot access anything in the TEE if it is implemented correctly.		cannot access anything in the TEE if it is implemented correctly.
	Some TEEs may have some watchdog scheme to observe REE state and		Some TEEs may have some watchdog scheme to observe REE state and
	mitigate DoS attacks against it but most TEEs don't have have such		mitigate DoS attacks against it but most TEEs don't have such a
	capability.		capability.
	In some other scenarios, the compromised REE may ask a TEEP Broker to		In some other scenarios, the compromised REE may ask a TEEP Broker to
	make repeated requests to a TEEP Agent in a TEE to install or		make repeated requests to a TEEP Agent in a TEE to install or
	uninstall a TA. A TA installation or uninstallation request		uninstall a TA. A TA installation or uninstallation request
	constructed by the TEEP Broker or REE will be rejected by the TEEP		constructed by the TEEP Broker or REE will be rejected by the TEEP
	Agent because the request won't have the correct signature from a TAM		Agent because the request won't have the correct signature from a TAM
	to pass the request signature validation.		to pass the request signature validation.
	This can become a DoS attack by exhausting resources in a TEE with		This can become a DoS attack by exhausting resources in a TEE with
	skipping to change at page 27, line 5 ¶		skipping to change at page 27, line 5 ¶
	apps in the first place. The TEEP architecture allows a TEEP Agent		apps in the first place. The TEEP architecture allows a TEEP Agent
	to decide which TAMs it trusts via Trust Anchors, and delegates the		to decide which TAMs it trusts via Trust Anchors, and delegates the
	TA authenticity check to the TAMs it trusts.		TA authenticity check to the TAMs it trusts.
	It may happen that a TA was previously considered trustworthy but is		It may happen that a TA was previously considered trustworthy but is
	later found to be buggy or compromised. In this case, the TAM can		later found to be buggy or compromised. In this case, the TAM can
	initiate the removal of the TA by notifying devices to remove the TA		initiate the removal of the TA by notifying devices to remove the TA
	(and potentially the REE or device owner to remove any Untrusted		(and potentially the REE or device owner to remove any Untrusted
	Application that depend on the TA). If the TAM does not currently		Application that depend on the TA). If the TAM does not currently
	have a connection to the TEEP Agent on a device, such a notification		have a connection to the TEEP Agent on a device, such a notification
	would occur the next time connectivity does exist.		would occur the next time connectivity does exist. That is, to
			recover, the TEEP Agent must be able to reach out to the TAM, for
			example whenever the RequestPolicyCheck API (Section 6.2.1) is
			invoked by a timer or other event.
	Furthermore the policy in the Verifier in an attestation process can		Furthermore the policy in the Verifier in an attestation process can
	be updated so that any evidence that includes the malicious TA would		be updated so that any evidence that includes the malicious TA would
	result in an attestation failure. There is, however, a time window		result in an attestation failure. There is, however, a time window
	during which a malicious TA might be able to operate successfully,		during which a malicious TA might be able to operate successfully,
	which is the validity time of the previous attestation result. For		which is the validity time of the previous attestation result. For
	example, if the Verifier in Figure 5 is updated to treat a previously		example, if the Verifier in Figure 5 is updated to treat a previously
	valid TA as no longer trustworthy, any attestation result it		valid TA as no longer trustworthy, any attestation result it
	previously generated saying that the TA is valid will continue to be		previously generated saying that the TA is valid will continue to be
	used until the attestation result expires. As such, the TAM's		used until the attestation result expires. As such, the TAM's
	skipping to change at page 28, line 30 ¶		skipping to change at page 28, line 30 ¶
	feedback.		feedback.
	13. Informative References		13. Informative References
	[GPTEE] GlobalPlatform, "GlobalPlatform Device Technology: TEE		[GPTEE] GlobalPlatform, "GlobalPlatform Device Technology: TEE
	System Architecture, v1.1", GlobalPlatform GPD_SPE_009,		System Architecture, v1.1", GlobalPlatform 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-rats-architecture]		[I-D.ietf-rats-architecture]
	Birkholz, H., Thaler, D., Richardson, M., and N. Smith,		Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
	"Remote Attestation Procedures Architecture", draft-ietf-		W. Pan, "Remote Attestation Procedures Architecture",
	rats-architecture-01 (work in progress), February 2020.		draft-ietf-rats-architecture-02 (work in progress), March
			2020.
	[I-D.ietf-suit-manifest]		[I-D.ietf-suit-manifest]
	Moran, B., Tschofenig, H., and H. Birkholz, "A Concise		Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,
	Binary Object Representation (CBOR)-based Serialization		"A Concise Binary Object Representation (CBOR)-based
	Format for the Software Updates for Internet of Things		Serialization Format for the Software Updates for Internet
	(SUIT) Manifest", draft-ietf-suit-manifest-03 (work in		of Things (SUIT) Manifest", draft-ietf-suit-manifest-04
	progress), February 2020.		(work in progress), March 2020.
	[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-04 (work in progress),		draft-ietf-teep-otrp-over-http-05 (work in progress),
	February 2020.		March 2020.
	[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>.
End of changes. 12 change blocks.
	23 lines changed or deleted		27 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/