< draft-ietf-teep-architecture-13.txt		draft-ietf-teep-architecture-14.txt >
	TEEP M. Pei		TEEP M. Pei
	Internet-Draft Broadcom		Internet-Draft Broadcom
	Intended status: Informational H. Tschofenig		Intended status: Informational H. Tschofenig
	Expires: May 6, 2021 Arm Limited		Expires: August 26, 2021 Arm Limited
	D. Thaler		D. Thaler
	Microsoft		Microsoft
	D. Wheeler		D. Wheeler
	Intel		Intel
	November 02, 2020		February 22, 2021
	Trusted Execution Environment Provisioning (TEEP) Architecture		Trusted Execution Environment Provisioning (TEEP) Architecture
	draft-ietf-teep-architecture-13		draft-ietf-teep-architecture-14
	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.
	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 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 May 6, 2021.		This Internet-Draft will expire on August 26, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(https://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	skipping to change at page 2, line 39 ¶		skipping to change at page 2, line 39 ¶
	3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 8		3.2. Authentication . . . . . . . . . . . . . . . . . . . . . 8
	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 16		4.4.1. Example: Application Delivery Mechanisms in Intel SGX 16
	4.4.2. Example: Application Delivery Mechanisms in Arm		4.4.2. Example: Application Delivery Mechanisms in Arm
	TrustZone . . . . . . . . . . . . . . . . . . . . . . 16		TrustZone . . . . . . . . . . . . . . . . . . . . . . 17
	4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 17		4.5. Entity Relations . . . . . . . . . . . . . . . . . . . . 17
	5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 18		5. Keys and Certificate Types . . . . . . . . . . . . . . . . . 19
	5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 20		5.1. Trust Anchors in a TEEP Agent . . . . . . . . . . . . . . 21
	5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 20		5.2. Trust Anchors in a TEE . . . . . . . . . . . . . . . . . 21
	5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 20		5.3. Trust Anchors in a TAM . . . . . . . . . . . . . . . . . 21
	5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 20		5.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 21
	5.5. Message Security . . . . . . . . . . . . . . . . . . . . 21		5.5. Message Security . . . . . . . . . . . . . . . . . . . . 22
	6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 21		6. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 22
	6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 22		6.1. Role of the TEEP Broker . . . . . . . . . . . . . . . . . 23
	6.2. TEEP Broker Implementation Consideration . . . . . . . . 22		6.2. TEEP Broker Implementation Consideration . . . . . . . . 23
	6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 23		6.2.1. TEEP Broker APIs . . . . . . . . . . . . . . . . . . 24
	6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 24		6.2.2. TEEP Broker Distribution . . . . . . . . . . . . . . 25
	7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 24		7. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . 25
	8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 26		8. Algorithm and Attestation Agility . . . . . . . . . . . . . . 27
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 27		9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 27		9.1. Broker Trust Model . . . . . . . . . . . . . . . . . . . 28
	9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 27		9.2. Data Protection . . . . . . . . . . . . . . . . . . . . . 28
	9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 28		9.3. Compromised REE . . . . . . . . . . . . . . . . . . . . . 29
	9.4. CA Compromise or Expiry of CA Certificate . . . . . . . . 29		9.4. CA Compromise or Expiry of CA Certificate . . . . . . . . 30
	9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 29		9.5. Compromised TAM . . . . . . . . . . . . . . . . . . . . . 30
	9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 29		9.6. Malicious TA Removal . . . . . . . . . . . . . . . . . . 30
	9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 30		9.7. Certificate Expiry and Renewal . . . . . . . . . . . . . 31
	9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 31		9.8. Keeping Secrets from the TAM . . . . . . . . . . . . . . 32
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
	13. Informative References . . . . . . . . . . . . . . . . . . . 31		13. Informative References . . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
	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 5, line 22 ¶		skipping to change at page 5, line 22 ¶
	- A Device Administrator wants to check whether a TA in a device's		- A Device Administrator wants to check whether a TA in a device's
	TEE is the most up-to-date version, and if not, update the TA in		TEE is the most up-to-date version, and if not, update the TA in
	the TEE.		the TEE.
	- A Device Administrator wants to remove a TA from a device's TEE if		- A Device Administrator wants to remove a TA from a device's TEE if
	the TA developer is no longer maintaining that TA, when the TA has		the TA developer is no longer maintaining that TA, when the TA has
	been revoked or is not used for other reasons anymore (e.g., due		been revoked or is not used for other reasons anymore (e.g., due
	to an expired subscription).		to an expired subscription).
	- A TA developer wants to define the relationship between		For TEEs that simply verify and load signed TA's from an untrusted
	cooperating TAs under the TA developer's control, and specify		filesystem, classic application distribution protocols can be used
	whether the TAs can communicate, share data, and/or share key		without modification. The problems in the bullets above, on the
	material.		other hand, require a new protocol, i.e., the TEEP protocol, for TEEs
			that can install and enumerate TAs in a TEE-secured location and
			where another domain-specific protocol standard (e.g., [GSMA],
			[OTRP]) that meets the needs is not already in use.
	2. Terminology		2. Terminology
	The following terms are used:		The following terms are used:
	- Device: A physical piece of hardware that hosts one or more TEEs,		- Device: A physical piece of hardware that hosts one or more TEEs,
	often along with an REE.		often along with an REE.
	- Device Administrator: An entity that is responsible for		- Device Administrator: An entity that is responsible for
	administration of a device, which could be the Device Owner. A		administration of a device, which could be the Device Owner. A
	skipping to change at page 16, line 41 ¶		skipping to change at page 16, line 41 ¶
	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 enclave-to-enclave manner) to the REE's installation app,		in an SGX enclave-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.
			As long as signed files (TAs and/or Personalization Data) are
			installed into an untrusted filesystem and trust is verified by the
			TEE at load time, classic distribution mechanisms can be used. Some
			uses of SGX, however, allow a model where a TA can be dynamically
			installed into an SGX enclave that provides a runtime platform. The
			TEEP protocol can be used in such cases, where the runtime platform
			could include a TEEP Agent.
	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 such as a		TA is loaded by a trusted OS running in the TEE such as a
	GlobalPlatform compliant TEE, where the trusted OS is separate from		GlobalPlatform compliant TEE, where the trusted OS is separate from
	the OS in the REE. Thus Cases 2 and 3 are equally applicable. In		the OS in the REE. Thus Cases 2 and 3 are equally applicable. In
	addition, it is possible for TAs to communicate with each other		addition, it is possible for TAs to communicate with each other
	without involving any Untrusted Application, and so the complexity of		without involving any Untrusted Application, and so the complexity of
	Case 1 is lower than in the SGX example. Thus, Case 1 is possible as		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.		well, though still more complex than Cases 2 and 3.
			TEE OS's (e.g., OP-TEE) that support loading and verifying signed TAs
			from an untrusted filesystem can, like SGX, use classic file
			distribution mechanisms. If secure TA storage is used (e.g., a
			Replay-Protected Memory Block device) on the other hand, the TEEP
			protocol can be used to manage such storage.
	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 Trusted Component Signers; it may embed a list of default		TAMs and by Trusted Component Signers; it may embed a list of default
	Trust Anchors into the TEEP Agent and TEE for TAM trust verification		Trust Anchors into the TEEP Agent and TEE for TAM trust verification
	skipping to change at page 23, line 49 ¶		skipping to change at page 24, line 49 ¶
	6.2.1. TEEP Broker APIs		6.2.1. TEEP Broker APIs
	The following conceptual APIs exist from a TEEP Broker to a TEEP		The following conceptual APIs exist from a TEEP Broker to a TEEP
	Agent:		Agent:
	1. RequestTA: A notification from an REE application (e.g., an		1. RequestTA: A notification from an REE application (e.g., an
	installer, or an Untrusted Application) that it depends on a		installer, or an Untrusted Application) that it depends on a
	given Trusted Component, which may or may not already be		given Trusted Component, which may or may not already be
	installed in the TEE.		installed in the TEE.
	2. ProcessTeepMessage: A message arriving from the network, to be		2. UnrequestTA: A notification from an REE application (e.g., an
			installer, or an Untrusted Application) that it no longer depends
			on a given Trusted Component, which may or may not already be
			installed in the TEE. For example, if the Untrusted Application
			is uninstalled, the uninstaller might invoke this conceptual API.
			3. ProcessTeepMessage: A message arriving from the network, to be
	delivered to the TEEP Agent for processing.		delivered to the TEEP Agent for processing.
	3. RequestPolicyCheck: A hint (e.g., based on a timer) that the TEEP		4. RequestPolicyCheck: A hint (e.g., based on a timer) that the TEEP
	Agent may wish to contact the TAM for any changes, without the		Agent may wish to contact the TAM for any changes, without the
	device itself needing any particular change.		device itself needing any particular change.
	4. ProcessError: A notification that the TEEP Broker could not		5. ProcessError: A notification that the TEEP Broker could not
	deliver an outbound TEEP message to a TAM.		deliver an outbound TEEP message to a TAM.
	For comparison, similar APIs may exist on the TAM side, where a		For comparison, similar APIs may exist on the TAM side, where a
	Broker may or may not exist, depending on whether the TAM uses a TEE		Broker may or may not exist, depending on whether the TAM uses a TEE
	or not:		or not:
	1. ProcessConnect: A notification that an incoming TEEP session is		1. ProcessConnect: A notification that an incoming TEEP session is
	being requested by a TEEP Agent.		being requested by a TEEP Agent.
	2. ProcessTeepMessage: A message arriving from the network, to be		2. ProcessTeepMessage: A message arriving from the network, to be
	skipping to change at page 31, line 47 ¶		skipping to change at page 32, line 47 ¶
	Smith, Russ Housley, Jeremy O'Donoghue, and Anders Rundgren for their		Smith, Russ Housley, Jeremy O'Donoghue, and Anders Rundgren for their
	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/>.
			[GSMA] GSM Association, "GP.22 RSP Technical Specification,
			Version 2.2.2", June 2020, <https://www.gsma.com/esim/wp-
			content/uploads/2020/06/SGP.22-v2.2.2.pdf>.
	[I-D.ietf-rats-architecture]		[I-D.ietf-rats-architecture]
	Birkholz, H., Thaler, D., Richardson, M., Smith, N., and		Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
	W. Pan, "Remote Attestation Procedures Architecture",		W. Pan, "Remote Attestation Procedures Architecture",
	draft-ietf-rats-architecture-07 (work in progress),		draft-ietf-rats-architecture-08 (work in progress),
	October 2020.		December 2020.
	[I-D.ietf-suit-manifest]		[I-D.ietf-suit-manifest]
	Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,		Moran, B., Tschofenig, H., Birkholz, H., and K. Zandberg,
	"A Concise Binary Object Representation (CBOR)-based		"A Concise Binary Object Representation (CBOR)-based
	Serialization Format for the Software Updates for Internet		Serialization Format for the Software Updates for Internet
	of Things (SUIT) Manifest", draft-ietf-suit-manifest-09		of Things (SUIT) Manifest", draft-ietf-suit-manifest-11
	(work in progress), July 2020.		(work in progress), December 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-08 (work in progress),		draft-ietf-teep-otrp-over-http-09 (work in progress),
	October 2020.		November 2020.
	[I-D.ietf-teep-protocol]		[I-D.ietf-teep-protocol]
	Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A.		Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A.
	Tsukamoto, "Trusted Execution Environment Provisioning		Tsukamoto, "Trusted Execution Environment Provisioning
	(TEEP) Protocol", draft-ietf-teep-protocol-03 (work in		(TEEP) Protocol", draft-ietf-teep-protocol-04 (work in
	progress), July 2020.		progress), November 2020.
			[OTRP] GlobalPlatform, "Open Trust Protocol (OTrP) Profile v1.1",
			GlobalPlatform GPD_SPE_123, July 2020,
			<https://globalplatform.org/specs-library/tee-management-
			framework-open-trust-protocol/>.
	[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",		[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
	FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,		FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
	<https://www.rfc-editor.org/info/rfc4949>.		<https://www.rfc-editor.org/info/rfc4949>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
End of changes. 21 change blocks.
	50 lines changed or deleted		82 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/