< draft-ietf-teep-protocol-02.txt		draft-ietf-teep-protocol-03.txt >
	TEEP H. Tschofenig		TEEP H. Tschofenig
	Internet-Draft Arm Ltd.		Internet-Draft Arm Ltd.
	Intended status: Standards Track M. Pei		Intended status: Standards Track M. Pei
	Expires: October 16, 2020 Broadcom		Expires: January 14, 2021 Broadcom
	D. Wheeler		D. Wheeler
	Intel		Intel
	D. Thaler		D. Thaler
	Microsoft		Microsoft
	A. Tsukamoto		A. Tsukamoto
	AIST		AIST
	April 14, 2020		July 13, 2020
	Trusted Execution Environment Provisioning (TEEP) Protocol		Trusted Execution Environment Provisioning (TEEP) Protocol
	draft-ietf-teep-protocol-02		draft-ietf-teep-protocol-03
	Abstract		Abstract
	This document specifies a protocol that installs, updates, and		This document specifies a protocol that installs, updates, and
	deletes Trusted Applications (TAs) in a device with a Trusted		deletes Trusted Applications (TAs) in a device with a Trusted
	Execution Environment (TEE). This specification defines an		Execution Environment (TEE). This specification defines an
	interoperable protocol for managing the lifecycle of TAs.		interoperable protocol for managing the lifecycle of TAs.
	The protocol name is pronounced teepee. This conjures an image of a		The protocol name is pronounced teepee. This conjures an image of a
	wedge-shaped protective covering for one's belongings, which sort of		wedge-shaped protective covering for one's belongings, which sort of
	matches the intent of this protocol.		matches the intent of this protocol.
	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 https://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 October 16, 2020.		This Internet-Draft will expire on January 14, 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
	(https://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
	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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	4.1.2. Validating a TEEP Message . . . . . . . . . . . . . . 6		4.1.2. Validating a TEEP Message . . . . . . . . . . . . . . 6
	4.2. QueryRequest . . . . . . . . . . . . . . . . . . . . . . 6		4.2. QueryRequest . . . . . . . . . . . . . . . . . . . . . . 6
	4.3. QueryResponse . . . . . . . . . . . . . . . . . . . . . . 8		4.3. QueryResponse . . . . . . . . . . . . . . . . . . . . . . 8
	4.4. TrustedAppInstall . . . . . . . . . . . . . . . . . . . . 10		4.4. TrustedAppInstall . . . . . . . . . . . . . . . . . . . . 10
	4.5. TrustedAppDelete . . . . . . . . . . . . . . . . . . . . 11		4.5. TrustedAppDelete . . . . . . . . . . . . . . . . . . . . 11
	4.6. Success . . . . . . . . . . . . . . . . . . . . . . . . . 11		4.6. Success . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.7. Error . . . . . . . . . . . . . . . . . . . . . . . . . . 12		4.7. Error . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5. Mapping of TEEP Message Parameters to CBOR Labels . . . . . . 15		5. Mapping of TEEP Message Parameters to CBOR Labels . . . . . . 15
	6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 15		6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 15
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 16		7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	8.1. Media Type Registration . . . . . . . . . . . . . . . . . 17		8.1. Media Type Registration . . . . . . . . . . . . . . . . . 18
	8.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 18		8.2. Error Code Registry . . . . . . . . . . . . . . . . . . . 19
	8.3. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 19		8.3. Ciphersuite Registry . . . . . . . . . . . . . . . . . . 19
	8.4. CBOR Tag Registry . . . . . . . . . . . . . . . . . . . . 19		8.4. CBOR Tag Registry . . . . . . . . . . . . . . . . . . . . 19
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9.1. Normative References . . . . . . . . . . . . . . . . . . 20		9.1. Normative References . . . . . . . . . . . . . . . . . . 20
	9.2. Informative References . . . . . . . . . . . . . . . . . 21		9.2. Informative References . . . . . . . . . . . . . . . . . 21
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
	B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21		B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
	C. Complete CDDL . . . . . . . . . . . . . . . . . . . . . . . . 21		C. Complete CDDL . . . . . . . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	The Trusted Execution Environment (TEE) concept has been designed to		The Trusted Execution Environment (TEE) concept has been designed to
	skipping to change at page 10, line 18 ¶		skipping to change at page 10, line 18 ¶
	(trusted apps) via the TEEP Agent.		(trusted apps) via the TEEP Agent.
	Like other TEEP messages, the TrustedAppInstall message is signed,		Like other TEEP messages, the TrustedAppInstall message is signed,
	and the relevant CDDL snippet is shown below. The complete CDDL		and the relevant CDDL snippet is shown below. The complete CDDL
	structure is shown in [CDDL].		structure is shown in [CDDL].
	trusted-app-install = [		trusted-app-install = [
	type: TEEP-TYPE-trusted-app-install,		type: TEEP-TYPE-trusted-app-install,
	token: uint,		token: uint,
	option: {		option: {
	? manifest-list => [ + SUIT-envelope ],		? manifest-list => [ + SUIT_Envelope ],
	* $$trusted-app-install-extensions,		* $$trusted-app-install-extensions,
	* $$teep-option-extensions		* $$teep-option-extensions
	}		}
	]		]
	The TrustedAppInstall message has the following fields:		The TrustedAppInstall message has the following fields:
	type		type
	The value of (3) corresponds to a TrustedAppInstall message sent		The value of (3) corresponds to a TrustedAppInstall message sent
	from the TAM to the TEEP Agent. In case of successful processing,		from the TAM to the TEEP Agent. In case of successful processing,
	skipping to change at page 16, line 35 ¶		skipping to change at page 16, line 35 ¶
	A TAM may rely on the attestation information provided by the TEEP		A TAM may rely on the attestation information provided by the TEEP
	Agent and the Entity Attestation Token is re-used to convey this		Agent and the Entity Attestation Token is re-used to convey this
	information. To sign the Entity Attestation Token it is necessary		information. To sign the Entity Attestation Token it is necessary
	for the device to possess a public key (usually in the form of a		for the device to possess a public key (usually in the form of a
	certificate) along with the corresponding private key. Depending		certificate) along with the corresponding private key. Depending
	on the properties of the attestation mechanism it is possible to		on the properties of the attestation mechanism it is possible to
	uniquely identify a device based on information in the attestation		uniquely identify a device based on information in the attestation
	information or in the certificate used to sign the attestation		information or in the certificate used to sign the attestation
	token. This uniqueness may raise privacy concerns. To lower the		token. This uniqueness may raise privacy concerns. To lower the
	privacy implications the TEEP Agent MUST present its attestation		privacy implications the TEEP Agent MUST present its attestation
	information only to an authenticated and authorized TAM.		information only to an authenticated and authorized TAM and SHOULD
			use encryption in EATs as discussed in [I-D.ietf-rats-eat] since
			confidentiality is not provided by the TEEP protocol itself, and
			the transport protocol under the TEEP protocol might be
			implemented outside of any TEE.
	TA Binaries		TA Binaries
	TA binaries are provided by the SP. It is the responsibility of		TA binaries are provided by the SP. It is the responsibility of
	the TAM to relay only verified TAs from authorized SPs. Delivery		the TAM to relay only verified TAs from authorized SPs. Delivery
	of that TA to the TEEP Agent is then the responsibility of the TAM		of that TA to the TEEP Agent is then the responsibility of the TAM
	and the TEEP Broker, using the security mechanisms provided by the		and the TEEP Broker, using the security mechanisms provided by the
	TEEP protocol. To protect the TA binary the SUIT manifest is re-		TEEP protocol. To protect the TA binary the SUIT manifest is re-
	used and it offers a varity of security features, including		used and it offers a varity of security features, including
	digitial signatures and symmetric encryption.		digitial signatures and symmetric encryption.
	skipping to change at page 19, line 44 ¶		skipping to change at page 20, line 4 ¶
	The registry contents is:		The registry contents is:
	o CBOR Tag: TBD1		o CBOR Tag: TBD1
	o Data Item: TEEP Message		o Data Item: TEEP Message
	o Semantics: TEEP Message, as defined in [[TBD: This RFC]]		o Semantics: TEEP Message, as defined in [[TBD: This RFC]]
	o Reference: [[TBD: This RFC]]		o Reference: [[TBD: This RFC]]
	o Point of Contact: TEEP working group (teep@ietf.org)		o Point of Contact: TEEP working group (teep@ietf.org)
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-rats-eat]		[I-D.ietf-rats-eat]
	Mandyam, G., Lundblade, L., Ballesteros, M., and J.		Mandyam, G., Lundblade, L., Ballesteros, M., and J.
	O'Donoghue, "The Entity Attestation Token (EAT)", draft-		O'Donoghue, "The Entity Attestation Token (EAT)", draft-
	ietf-rats-eat-03 (work in progress), February 2020.		ietf-rats-eat-03 (work in progress), February 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-04		of Things (SUIT) Manifest", draft-ietf-suit-manifest-08
	(work in progress), March 2020.		(work in progress), July 2020.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.		[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
	Adams, "X.509 Internet Public Key Infrastructure Online		Adams, "X.509 Internet Public Key Infrastructure Online
	Certificate Status Protocol - OCSP", RFC 2560,		Certificate Status Protocol - OCSP", RFC 2560,
	DOI 10.17487/RFC2560, June 1999,		DOI 10.17487/RFC2560, June 1999, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc2560>.		editor.org/info/rfc2560>.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November		10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
	2003, <https://www.rfc-editor.org/info/rfc3629>.		2003, <https://www.rfc-editor.org/info/rfc3629>.
	[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network		[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
	Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,		Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
	<https://www.rfc-editor.org/info/rfc5198>.		<https://www.rfc-editor.org/info/rfc5198>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	skipping to change at page 21, line 10 ¶		skipping to change at page 21, line 10 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-teep-architecture]		[I-D.ietf-teep-architecture]
	Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,		Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
	"Trusted Execution Environment Provisioning (TEEP)		"Trusted Execution Environment Provisioning (TEEP)
	Architecture", draft-ietf-teep-architecture-08 (work in		Architecture", draft-ietf-teep-architecture-11 (work in
	progress), April 2020.		progress), July 2020.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data		[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
	Definition Language (CDDL): A Notational Convention to		Definition Language (CDDL): A Notational Convention to
	Express Concise Binary Object Representation (CBOR) and		Express Concise Binary Object Representation (CBOR) and
	JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,		JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
	skipping to change at page 21, line 45 ¶		skipping to change at page 21, line 45 ¶
	We would like to thank Kohei Isobe (TRASIO/SECOM), Kuniyasu Suzaki		We would like to thank Kohei Isobe (TRASIO/SECOM), Kuniyasu Suzaki
	(TRASIO/AIST), Tsukasa Oi (TRASIO), and Yuichi Takita (SECOM) for		(TRASIO/AIST), Tsukasa Oi (TRASIO), and Yuichi Takita (SECOM) for
	their valuable implementation feedback.		their valuable implementation feedback.
	We would also like to thank Carsten Bormann and Henk Birkholz for		We would also like to thank Carsten Bormann and Henk Birkholz for
	their help with the CDDL.		their help with the CDDL.
	C. Complete CDDL		C. Complete CDDL
	teep-message = $teep-message-type .within teep-message-framework		Valid TEEP messages MUST adhere to the following CDDL data
			definitions, except that "SUIT_Envelope" is specified in
			[I-D.ietf-suit-manifest].
	SUIT-envelope = bstr ; placeholder		teep-message = $teep-message-type .within teep-message-framework
			SUIT_Envelope = any
	teep-message-framework = [		teep-message-framework = [
	type: 0..23 / $teep-type-extension,		type: 0..23 / $teep-type-extension,
	token: uint,		token: uint,
	options: { * teep-option },		options: { * teep-option },
	* int; further integers, e.g. for data-item-requested		* int; further integers, e.g. for data-item-requested
	]		]
	teep-option = (uint => any)		teep-option = (uint => any)
	; messages defined below:		; messages defined below:
	skipping to change at page 22, line 22 ¶		skipping to change at page 22, line 26 ¶
	$teep-message-type /= trusted-app-install		$teep-message-type /= trusted-app-install
	$teep-message-type /= trusted-app-delete		$teep-message-type /= trusted-app-delete
	$teep-message-type /= teep-error		$teep-message-type /= teep-error
	$teep-message-type /= teep-success		$teep-message-type /= teep-success
	; message type numbers		; message type numbers
	TEEP-TYPE-query-request = 1		TEEP-TYPE-query-request = 1
	TEEP-TYPE-query-response = 2		TEEP-TYPE-query-response = 2
	TEEP-TYPE-trusted-app-install = 3		TEEP-TYPE-trusted-app-install = 3
	TEEP-TYPE-trusted-app-delete = 4		TEEP-TYPE-trusted-app-delete = 4
	TEEP-TYPE-teep-error = 5		TEEP-TYPE-teep-success = 5
	TEEP-TYPE-teep-success = 6		TEEP-TYPE-teep-error = 6
	version = uint .size 4		version = uint .size 4
	ext-info = uint		ext-info = uint
	; data items as bitmaps		; data items as bitmaps
	data-item-requested = $data-item-requested .within uint .size 8		data-item-requested = $data-item-requested .within uint .size 8
	attestation = 1		attestation = 1
	$data-item-requested /= attestation		$data-item-requested /= attestation
	trusted-apps = 2		trusted-apps = 2
	$data-item-requested /= trusted-apps		$data-item-requested /= trusted-apps
	skipping to change at page 23, line 31 ¶		skipping to change at page 23, line 36 ¶
	? ext-list => [ + ext-info ],		? ext-list => [ + ext-info ],
	* $$query-response-extensions,		* $$query-response-extensions,
	* $$teep-option-extensions		* $$teep-option-extensions
	}		}
	]		]
	trusted-app-install = [		trusted-app-install = [
	type: TEEP-TYPE-trusted-app-install,		type: TEEP-TYPE-trusted-app-install,
	token: uint,		token: uint,
	option: {		option: {
	? manifest-list => [ + SUIT-envelope ],		? manifest-list => [ + SUIT_Envelope ],
	* $$trusted-app-install-extensions,		* $$trusted-app-install-extensions,
	* $$teep-option-extensions		* $$teep-option-extensions
	}		}
	]		]
	trusted-app-delete = [		trusted-app-delete = [
	type: TEEP-TYPE-trusted-app-delete,		type: TEEP-TYPE-trusted-app-delete,
	token: uint,		token: uint,
	option: {		option: {
	? ta-list => [ + bstr ],		? ta-list => [ + bstr ],
End of changes. 21 change blocks.
	26 lines changed or deleted		33 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/