draft-ietf-teep-otrp-over-http-07.txt		draft-ietf-teep-otrp-over-http-08.txt
	TEEP WG D. Thaler		TEEP WG D. Thaler
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Informational July 23, 2020		Intended status: Informational October 09, 2020
	Expires: January 24, 2021		Expires: April 12, 2021
	HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-		HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-
	TAM Communication		TAM Communication
	draft-ietf-teep-otrp-over-http-07		draft-ietf-teep-otrp-over-http-08
	Abstract		Abstract
	The Trusted Execution Environment Provisioning (TEEP) Protocol is		The Trusted Execution Environment Provisioning (TEEP) Protocol is
	used to manage code and configuration data in a Trusted Execution		used to manage code and configuration data in a Trusted Execution
	Environment (TEE). This document specifies the HTTP transport for		Environment (TEE). This document specifies the HTTP transport for
	TEEP communication where a Trusted Application Manager (TAM) service		TEEP communication where a Trusted Application Manager (TAM) service
	is used to manage code and data in TEEs on devices that can initiate		is used to manage code and data in TEEs on devices that can initiate
	communication to the TAM. An implementation of this document can (if		communication to the TAM. An implementation of this document can (if
	desired) run outside of any TEE, but interacts with a TEEP		desired) run outside of any TEE, but interacts with a TEEP
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 January 24, 2021.		This Internet-Draft will expire on April 12, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. TEEP Broker Models . . . . . . . . . . . . . . . . . . . . . 4		3. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Use of Abstract APIs . . . . . . . . . . . . . . . . . . 5		3.1. Use of Abstract APIs . . . . . . . . . . . . . . . . . . 4
	4. Use of HTTP as a Transport . . . . . . . . . . . . . . . . . 6		4. Use of HTTP as a Transport . . . . . . . . . . . . . . . . . 5
	5. TEEP/HTTP Client Behavior . . . . . . . . . . . . . . . . . . 7		5. TEEP/HTTP Client Behavior . . . . . . . . . . . . . . . . . . 6
	5.1. Receiving a request to install a new Trusted Application 7		5.1. Receiving a request to install a new Trusted Application 6
	5.1.1. Session Creation . . . . . . . . . . . . . . . . . . 8		5.1.1. Session Creation . . . . . . . . . . . . . . . . . . 6
	5.2. Getting a message buffer back from a TEEP Agent . . . . . 8		5.2. Getting a message buffer back from a TEEP Agent . . . . . 7
	5.3. Receiving an HTTP response . . . . . . . . . . . . . . . 9		5.3. Receiving an HTTP response . . . . . . . . . . . . . . . 7
	5.4. Handling checks for policy changes . . . . . . . . . . . 9		5.4. Handling checks for policy changes . . . . . . . . . . . 8
	5.5. Error handling . . . . . . . . . . . . . . . . . . . . . 10		5.5. Error handling . . . . . . . . . . . . . . . . . . . . . 8
	6. TEEP/HTTP Server Behavior . . . . . . . . . . . . . . . . . . 10		6. TEEP/HTTP Server Behavior . . . . . . . . . . . . . . . . . . 9
	6.1. Receiving an HTTP POST request . . . . . . . . . . . . . 10		6.1. Receiving an HTTP POST request . . . . . . . . . . . . . 9
	6.2. Getting an empty buffer back from the TAM . . . . . . . . 10		6.2. Getting an empty buffer back from the TAM . . . . . . . . 9
	6.3. Getting a message buffer from the TAM . . . . . . . . . . 10		6.3. Getting a message buffer from the TAM . . . . . . . . . . 9
	6.4. Error handling . . . . . . . . . . . . . . . . . . . . . 11		6.4. Error handling . . . . . . . . . . . . . . . . . . . . . 9
	7. Sample message flow . . . . . . . . . . . . . . . . . . . . . 11		7. Sample message flow . . . . . . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 13		8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	10.1. Normative References . . . . . . . . . . . . . . . . . . 13		10.1. Normative References . . . . . . . . . . . . . . . . . . 12
	10.2. Informative References . . . . . . . . . . . . . . . . . 14		10.2. Informative References . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	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. The Trusted Execution Environment		any code outside that environment. The Trusted Execution Environment
	Provisioning (TEEP) protocol is designed to provision authorized code		Provisioning (TEEP) protocol is designed to provision authorized code
	and configuration into TEEs.		and configuration into TEEs.
	skipping to change at page 4, line 18 ¶		skipping to change at page 4, line 18 ¶
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	This document also uses various terms defined in		This document also uses various terms defined in
	[I-D.ietf-teep-architecture], including Trusted Execution Environment		[I-D.ietf-teep-architecture], including Trusted Execution Environment
	(TEE), Trusted Application (TA), Trusted Application Manager (TAM),		(TEE), Trusted Application (TA), Trusted Application Manager (TAM),
	TEEP Agent, TEEP Broker, and Rich Execution Environment (REE).		TEEP Agent, TEEP Broker, and Rich Execution Environment (REE).
	3. TEEP Broker Models		3. TEEP Broker
	Section 6 of the TEEP architecture [I-D.ietf-teep-architecture]		Section 6 of the TEEP architecture [I-D.ietf-teep-architecture]
	defines a TEEP "Broker" as being a component on the device, but		defines a TEEP "Broker" as being a component on the device, but
	outside the TEE, that facilitates communication with a TAM. As		outside the TEE, that facilitates communication with a TAM. That
	depicted in Figure 2, there are multiple ways in which this can be		document further explains that the protocol layer at which the TEEP
	implemented, with more or fewer layers being inside the TEE. For		broker operates may vary by implementation, and it depicts several
	example, in model A, the model with the smallest TEE footprint, only		exemplary models. An implementation is free to choose any of these
	the TEEP implementation is inside the TEE, whereas the TEEP/HTTP		models, although model A is the one we will use in our examples.
	implementation is in the TEEP Broker outside the TEE.
	Model: A B C ...
	TEE TEE TEE
	+----------------+ | | |
	| TEEP | Agent | | | Agent
	| implementation | | | |
	+----------------+ v | |
	| | |
	+----------------+ ^ | |
	| TEEP/HTTP | Broker | | |
	| implementation | | | |
	+----------------+ | v |
	| | |
	+----------------+ | ^ |
	| HTTP | | | |
	| implementation | | | |
	+----------------+ | | v
	| | |
	+----------------+ | | ^
	| TCP or QUIC | | | | Broker
	| implementation | | | |
	+----------------+ | | |
	REE REE REE
	Figure 2: TEEP Broker Models
	In other models, additional layers are moved into the TEE, increasing
	the TEE footprint, with the Broker either containing or calling the
	topmost protocol layer outside of the TEE. An implementation is free
	to choose any of these models, although model A is the one we will
	use in our examples.
	Passing information from an REE component to a TEE component is		Passing information from an REE component to a TEE component is
	typically spoken of as being passed "in" to the TEE, and informaton		typically spoken of as being passed "in" to the TEE, and informaton
	passed in the opposite direction is spoken of as being passed "out".		passed in the opposite direction is spoken of as being passed "out".
	In the protocol layering sense, information is typically spoken of as		In the protocol layering sense, information is typically spoken of as
	being passed "up" or "down" the stack. Since the layer at which		being passed "up" or "down" the stack. Since the layer at which
	information is passed in/out may vary by implementation, we will		information is passed in/out may vary by implementation, we will
	generally use "up" and "down" in this document.		generally use "up" and "down" in this document.
	3.1. Use of Abstract APIs		3.1. Use of Abstract APIs
	skipping to change at page 6, line 30 ¶		skipping to change at page 5, line 20 ¶
	making any downcall, or by returning 0 bytes from an upcall, for		making any downcall, or by returning 0 bytes from an upcall, for
	example.		example.
	4. Use of HTTP as a Transport		4. Use of HTTP as a Transport
	This document uses HTTP [I-D.ietf-httpbis-semantics] as a transport.		This document uses HTTP [I-D.ietf-httpbis-semantics] as a transport.
	For the motivation behind the HTTP recommendations in this document,		For the motivation behind the HTTP recommendations in this document,
	see the discussion of HTTP as a transport in		see the discussion of HTTP as a transport in
	[I-D.ietf-httpbis-bcp56bis].		[I-D.ietf-httpbis-bcp56bis].
	Redirects MAY be automatically followed, and no additional request		Redirects MUST NOT be automatically followed. Cookies are not used.
	headers beyond those specified by HTTP need be modified or removed
	upon following such a redirect. Cookies are not used.
	Content is not intended to be treated as active by browsers and so		Content is not intended to be treated as active by browsers and so
	HTTP responses with content SHOULD have the following headers as		HTTP responses with content SHOULD have the following headers as
	explained in Section 4.12 of [I-D.ietf-httpbis-bcp56bis] (using the		explained in Section 4.12 of [I-D.ietf-httpbis-bcp56bis] (using the
	relevant TEEP content type defined in [I-D.ietf-teep-protocol]):		relevant TEEP content type defined in [I-D.ietf-teep-protocol]):
	Content-Type: application/teep+cbor		Content-Type: application/teep+cbor
	Cache-Control: no-store
	X-Content-Type-Options: nosniff		X-Content-Type-Options: nosniff
	Content-Security-Policy: default-src 'none'		Content-Security-Policy: default-src 'none'
	Referrer-Policy: no-referrer		Referrer-Policy: no-referrer
	The "Cache-control" header SHOULD be set to no-store to disable
	caching of any TEEP protocol messages by HTTP intermediaries.
	Otherwise, there is the risk of stale TEEP messages.
	Only the POST method is specified for TAM resources exposed over		Only the POST method is specified for TAM resources exposed over
	HTTP. A URI of such a resource is referred to as a "TAM URI". A TAM		HTTP. A URI of such a resource is referred to as a "TAM URI". A TAM
	URI can be any HTTP(S) URI. The URI to use is configured in a TEEP		URI can be any HTTP(S) URI. The URI to use is configured in a TEEP
	Agent via an out-of-band mechanism, as discussed in the next section.		Agent via an out-of-band mechanism, as discussed in the next section.
	It is strongly RECOMMENDED that implementations use HTTPS. Although		It is strongly RECOMMENDED that implementations use HTTPS. Although
	TEEP is protected end-to-end inside of HTTP, there is still value in		TEEP is protected end-to-end inside of HTTP, there is still value in
	using HTTPS for transport, since HTTPS can provide additional		using HTTPS for transport, since HTTPS can provide additional
	protections as discussed in Sections 4.4.2 and 6 of		protections as discussed in Sections 4.4.2 and 6 of
	[I-D.ietf-httpbis-bcp56bis].		[I-D.ietf-httpbis-bcp56bis].
	skipping to change at page 10, line 23 ¶		skipping to change at page 9, line 9 ¶
	If any HTTP request results in an HTTP error response or a lower		If any HTTP request results in an HTTP error response or a lower
	layer error (e.g., network unreachable), the TEEP/HTTP Client calls		layer error (e.g., network unreachable), the TEEP/HTTP Client calls
	the TEEP Agent's "ProcessError" API, and then deletes its session		the TEEP Agent's "ProcessError" API, and then deletes its session
	state and informs its caller of a failure.		state and informs its caller of a failure.
	6. TEEP/HTTP Server Behavior		6. TEEP/HTTP Server Behavior
	6.1. Receiving an HTTP POST request		6.1. Receiving an HTTP POST request
	If the TAM does not receive the appropriate Content-Type and Accept		If the TAM does not receive the appropriate Content-Type header
	header fields, the TAM SHOULD fail the request, returning a 406 (not		fields, the TAM SHOULD fail the request, returning a 415 Unsupported
	acceptable) response. Otherwise, processing continues as follows.		Media Type response. Similarly, if an appropriate Accept header
			field is not present, the TAM SHOULD fail the request with an
			appropriate error response. (This is for consistency with common
			implementation practice to allow the HTTP server to choose a default
			error response, since in some implementations the choice is done at
			the HTTP layer rather than the layer at which TEEP-over-HTTP would be
			implemented.) Otherwise, processing continues as follows.
	When an HTTP POST request is received with an empty body, the TEEP/		When an HTTP POST request is received with an empty body, the TEEP/
	HTTP Server invokes the TAM's "ProcessConnect" API. The TAM will		HTTP Server invokes the TAM's "ProcessConnect" API. The TAM will
	then pass back a (possibly empty) message buffer.		then pass back a (possibly empty) message buffer.
	When an HTTP POST request is received with a non-empty body, the		When an HTTP POST request is received with a non-empty body, the
	TEEP/HTTP Server passes the request body to the TAM (e.g., using the		TEEP/HTTP Server passes the request body to the TAM (e.g., using the
	"ProcessTeepMessage" API mentioned in [I-D.ietf-teep-architecture]).		"ProcessTeepMessage" API mentioned in [I-D.ietf-teep-architecture]).
	The TAM will then pass back a (possibly empty) message buffer.		The TAM will then pass back a (possibly empty) message buffer.
	skipping to change at page 12, line 9 ¶		skipping to change at page 10, line 43 ¶
	6. The TAM generates a TEEP message (where typically QueryRequest		6. The TAM generates a TEEP message (where typically QueryRequest
	is the first message) and passes it to the TEEP/HTTP Server.		is the first message) and passes it to the TEEP/HTTP Server.
	7. The TEEP/HTTP Server sends an HTTP successful response with the		7. The TEEP/HTTP Server sends an HTTP successful response with the
	TEEP message in the body:		TEEP message in the body:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/teep+cbor		Content-Type: application/teep+cbor
	Content-Length: [length of TEEP message here]		Content-Length: [length of TEEP message here]
	Server: Bar/2.2		Server: Bar/2.2
	Cache-Control: no-store
	X-Content-Type-Options: nosniff		X-Content-Type-Options: nosniff
	Content-Security-Policy: default-src 'none'		Content-Security-Policy: default-src 'none'
	Referrer-Policy: no-referrer		Referrer-Policy: no-referrer
	[TEEP message here]		[TEEP message here]
	where the TEEP/HTTP Server fills in an implementation-specific		where the TEEP/HTTP Server fills in an implementation-specific
	value in the Server header.		value in the Server header.
	8. Back on the TEEP Agent side, the TEEP/HTTP Client gets the HTTP		8. Back on the TEEP Agent side, the TEEP/HTTP Client gets the HTTP
	skipping to change at page 13, line 32 ¶		skipping to change at page 12, line 21 ¶
	10.1. Normative References		10.1. Normative References
	[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,		[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of Transport Layer		"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security		Security (TLS) and Datagram Transport Layer Security
	(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May		(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
	2015, <https://www.rfc-editor.org/info/rfc7525>.		2015, <https://www.rfc-editor.org/info/rfc7525>.
	[I-D.ietf-httpbis-semantics]		[I-D.ietf-httpbis-semantics]
	Fielding, R., Nottingham, M., and J. Reschke, "HTTP		Fielding, R., Nottingham, M., and J. Reschke, "HTTP
	Semantics", draft-ietf-httpbis-semantics-10 (work in		Semantics", draft-ietf-httpbis-semantics-12 (work in
	progress), July 2020.		progress), October 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-03 (work in
	progress), July 2020.		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, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	skipping to change at page 14, line 37 ¶		skipping to change at page 13, line 24 ¶
	<https://globalplatform.org/specs-library/tee-management-		<https://globalplatform.org/specs-library/tee-management-
	framework-open-trust-protocol/>.		framework-open-trust-protocol/>.
	[I-D.ietf-httpbis-bcp56bis]		[I-D.ietf-httpbis-bcp56bis]
	Nottingham, M., "Building Protocols with HTTP", draft-		Nottingham, M., "Building Protocols with HTTP", draft-
	ietf-httpbis-bcp56bis-09 (work in progress), November		ietf-httpbis-bcp56bis-09 (work in progress), November
	2019.		2019.
	[I-D.ietf-quic-transport]		[I-D.ietf-quic-transport]
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", draft-ietf-quic-transport-29 (work		and Secure Transport", draft-ietf-quic-transport-31 (work
	in progress), June 2020.		in progress), September 2020.
	[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-12 (work in		Architecture", draft-ietf-teep-architecture-12 (work in
	progress), July 2020.		progress), July 2020.
	[I-D.ietf-teep-opentrustprotocol]		[I-D.ietf-teep-opentrustprotocol]
	Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig,		Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig,
	"The Open Trust Protocol (OTrP)", draft-ietf-teep-		"The Open Trust Protocol (OTrP)", draft-ietf-teep-
End of changes. 13 change blocks.
	81 lines changed or deleted		46 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/