draft-ietf-teep-otrp-over-http-12.txt		draft-ietf-teep-otrp-over-http-13.txt
	TEEP WG D. Thaler		TEEP WG D. Thaler
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Standards Track 26 July 2021		Intended status: Standards Track 28 February 2022
	Expires: 27 January 2022		Expires: 1 September 2022
	HTTP Transport for Trusted Execution Environment Provisioning: Agent		HTTP Transport for Trusted Execution Environment Provisioning: Agent
	Initiated Communication		Initiated Communication
	draft-ietf-teep-otrp-over-http-12		draft-ietf-teep-otrp-over-http-13
	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 https://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 27 January 2022.		This Internet-Draft will expire on 1 September 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Use of Abstract APIs . . . . . . . . . . . . . . . . . . 4		3.1. Use of Abstract APIs . . . . . . . . . . . . . . . . . . 4
	4. Use of HTTP as a Transport . . . . . . . . . . . . . . . . . 5		4. Use of HTTP as a Transport . . . . . . . . . . . . . . . . . 5
	5. TEEP/HTTP Client Behavior . . . . . . . . . . . . . . . . . . 6		5. TEEP/HTTP Client Behavior . . . . . . . . . . . . . . . . . . 6
	5.1. Receiving a request to install a new Trusted		5.1. Receiving a request to install a new Trusted
	Application . . . . . . . . . . . . . . . . . . . . . . . 6		Application . . . . . . . . . . . . . . . . . . . . . . . 6
	5.1.1. Session Creation . . . . . . . . . . . . . . . . . . 7		5.1.1. Session Creation . . . . . . . . . . . . . . . . . . 7
	5.2. Receiving a notification that a Trusted Application is no		5.2. Receiving a notification that a Trusted Application is no
	longer needed . . . . . . . . . . . . . . . . . . . . . . 7		longer needed . . . . . . . . . . . . . . . . . . . . . . 7
	5.3. Getting a message buffer back from a TEEP Agent . . . . . 8		5.3. Getting a TAM URI and message buffer back from a TEEP
			Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.4. Receiving an HTTP response . . . . . . . . . . . . . . . 8		5.4. Receiving an HTTP response . . . . . . . . . . . . . . . 8
	5.5. Handling checks for policy changes . . . . . . . . . . . 9		5.5. Handling checks for policy changes . . . . . . . . . . . 9
	5.6. Error handling . . . . . . . . . . . . . . . . . . . . . 9		5.6. Error handling . . . . . . . . . . . . . . . . . . . . . 9
	6. TEEP/HTTP Server Behavior . . . . . . . . . . . . . . . . . . 9		6. TEEP/HTTP Server Behavior . . . . . . . . . . . . . . . . . . 10
	6.1. Receiving an HTTP POST request . . . . . . . . . . . . . 10		6.1. Receiving an HTTP POST request . . . . . . . . . . . . . 10
	6.2. Getting an empty buffer back from the TAM . . . . . . . . 10		6.2. Getting an empty buffer back from the TAM . . . . . . . . 10
	6.3. Getting a message buffer from the TAM . . . . . . . . . . 10		6.3. Getting a message buffer from the TAM . . . . . . . . . . 10
	6.4. Error handling . . . . . . . . . . . . . . . . . . . . . 10		6.4. Error handling . . . . . . . . . . . . . . . . . . . . . 10
	7. Sample message flow . . . . . . . . . . . . . . . . . . . . . 10		7. Sample message flow . . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	10.1. Normative References . . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . 13
	10.2. Informative References . . . . . . . . . . . . . . . . . 13		10.2. Informative References . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	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
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 26 ¶
	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 MUST NOT be automatically followed. Cookies are not used.		Redirects MUST NOT be automatically followed. 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 header fields
	explained in Section 4.12 of [I-D.ietf-httpbis-bcp56bis] (using the		as explained in Section 4.13 of [I-D.ietf-httpbis-bcp56bis] (using
	relevant TEEP content type defined in [I-D.ietf-teep-protocol]):		the TEEP media type defined in [I-D.ietf-teep-protocol]):
	Content-Type: application/teep+cbor		Content-Type: application/teep+cbor
	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
	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.
	skipping to change at page 6, line 6 ¶		skipping to change at page 6, line 6 ¶
	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].
	However, there may be constrained nodes where code space is an issue.		However, there may be constrained nodes where code space is an issue.
	[RFC7925] provides TLS profiles that can be used in many constrained		[RFC7925] provides TLS profiles that can be used in many constrained
	nodes, but in rare cases the most constrained nodes might need to use		nodes, but in rare cases the most constrained nodes might need to use
	HTTP without a TLS stack, relying on the end-to-end security provided		HTTP without a TLS stack, relying on the end-to-end security provided
	by the TEEP protocol.		by the TEEP protocol.
	When HTTPS is used, clients MUST use the procedures detailed in		When HTTPS is used, clients MUST use the procedures detailed in
	Section 6 of [RFC6125] to verify the authenticity of the server. See		Section 4.3.4 of [I-D.ietf-httpbis-semantics] to verify the
	[BCP195] for additional TLS recommendations and [RFC7925] for TLS		authenticity of the server. See [BCP195] for additional TLS
	recommendations related to IoT devices.		recommendations and [RFC7925] for TLS recommendations related to IoT
			devices.
	5. TEEP/HTTP Client Behavior		5. TEEP/HTTP Client Behavior
	5.1. Receiving a request to install a new Trusted Application		5.1. Receiving a request to install a new Trusted Application
	In some environments, an application installer can determine (e.g.,		In some environments, an application installer can determine (e.g.,
	from an application manifest) that the application being installed or		from an application manifest) that the application being installed or
	updated has a dependency on a given Trusted Application (TA) being		updated has a dependency on a given Trusted Application (TA) being
	available in a given type of TEE. In such a case, it will notify a		available in a given type of TEE. In such a case, it will notify a
	TEEP Broker, where the notification will contain the following:		TEEP Broker, where the notification will contain the following:
	skipping to change at page 7, line 12 ¶		skipping to change at page 7, line 12 ¶
	the TEEP Agent's configuration. If they differ, the TEEP/HTTP Client		the TEEP Agent's configuration. If they differ, the TEEP/HTTP Client
	MUST use the TAM URI passed back.		MUST use the TAM URI passed back.
	5.1.1. Session Creation		5.1.1. Session Creation
	If no data is passed back, the TEEP/HTTP Client simply informs its		If no data is passed back, the TEEP/HTTP Client simply informs its
	caller (e.g., the application installer) of success.		caller (e.g., the application installer) of success.
	If the TEEP Agent passes back a TAM URI with no message buffer, the		If the TEEP Agent passes back a TAM URI with no message buffer, the
	TEEP/HTTP Client attempts to create session state, then sends an		TEEP/HTTP Client attempts to create session state, then sends an
	HTTP(S) POST to the TAM URI with an Accept header with the TEEP media		HTTP(S) POST to the TAM URI with an Accept header field with the TEEP
	type requested, and an empty body. The HTTP request is then		media type specified in [I-D.ietf-teep-protocol], and an empty body.
	associated with the TEEP/HTTP Client's session state.		The HTTP request is then associated with the TEEP/HTTP Client's
			session state.
	If the TEEP Agent instead passes back a TAM URI with a message		If the TEEP Agent instead passes back a TAM URI with a message
	buffer, the TEEP/HTTP Client attempts to create session state and		buffer, the TEEP/HTTP Client attempts to create session state and
	handles the message buffer as specified in Section 5.3.		handles the message buffer as specified in Section 5.3.
	Session state consists of:		Session state consists of:
	* Any context (e.g., a handle) that identifies the API session with		* Any context (e.g., a handle) that identifies the API session with
	the TEEP Agent.		the TEEP Agent.
	skipping to change at page 7, line 40 ¶		skipping to change at page 7, line 41 ¶
	In some environments, an application installer can determine (e.g.,		In some environments, an application installer can determine (e.g.,
	from an application manifest) that a given Trusted Application is no		from an application manifest) that a given Trusted Application is no
	longer needed, such as if the application that previously depended on		longer needed, such as if the application that previously depended on
	the TA is uninstalled or updated in a way that removes the		the TA is uninstalled or updated in a way that removes the
	dependency. In such a case, it will notify a TEEP Broker, where the		dependency. In such a case, it will notify a TEEP Broker, where the
	notification will contain the following:		notification will contain the following:
	* A unique identifier of the TA		* A unique identifier of the TA
			* Optionally, any metadata to provide to the TEEP Agent. This might
			include a TAM URI provided in the original application manifest,
			for example.
	* Optionally, any requirements that may affect the choice of TEE, if		* Optionally, any requirements that may affect the choice of TEE, if
	multiple are available to the TEEP Broker.		multiple are available to the TEEP Broker.
	When a TEEP Broker receives such a notification, it first identifies		When a TEEP Broker receives such a notification, it first identifies
	in an implementation-dependent way which TEE (if any) is appropriate		in an implementation-dependent way which TEE (if any) is believed to
	based on the constraints expressed, as in Section 5.1.		contain the TA that is no longer needed, similar to the process in
			Section 5.1. Once the TEEP Broker picks a TEE, it passes the
			notification to the TEEP/HTTP Client for that TEE.
	The TEEP/HTTP Client then informs the TEEP Agent in that TEE by		The TEEP/HTTP Client then informs the TEEP Agent in that TEE by
	invoking an appropriate "UnrequestTA" API that identifies the		invoking an appropriate "UnrequestTA" API that identifies the
	unneeded TA. The TEEP/HTTP Client need not know whether the TEE		unneeded TA. The TEEP/HTTP Client need not know whether the TEE
	actually has the TA installed.		actually has the TA installed.
	The TEEP Agent will either (a) pass no data back, (b) pass back a TAM		The TEEP Agent will either (a) pass no data back, (b) pass back a TAM
	URI to connect to, or (c) pass back a message buffer and TAM URI to		URI to connect to, or (c) pass back a message buffer and TAM URI to
	send it to. The TAM URI passed back may or may not be the same as		send it to. The TAM URI passed back may or may not be the same as
	the TAM URI, if any, provided by the TEEP/HTTP Client, depending on		the TAM URI, if any, provided by the TEEP/HTTP Client, depending on
	the TEEP Agent's configuration. If they differ, the TEEP/HTTP Client		the TEEP Agent's configuration. If they differ, the TEEP/HTTP Client
	MUST use the TAM URI passed back.		MUST use the TAM URI passed back.
	Processing then continues as in Section 5.1.1.		Processing then continues as in Section 5.1.1.
	5.3. Getting a message buffer back from a TEEP Agent		5.3. Getting a TAM URI and message buffer back from a TEEP Agent
	When a TEEP Agent passes a message buffer (and TAM URI) to a TEEP/		When a TEEP Agent passes a TAM URI and optionally a message buffer to
	HTTP Client, the TEEP/HTTP Client MUST do the following, using the		a TEEP/HTTP Client, the TEEP/HTTP Client MUST do the following, using
	TEEP/HTTP Client's session state associated with its API call to the		the TEEP/HTTP Client's session state associated with its API call to
	TEEP Agent.		the TEEP Agent.
	The TEEP/HTTP Client sends an HTTP POST request to the TAM URI with		The TEEP/HTTP Client sends an HTTP POST request to the TAM URI with
	Accept and Content-Type headers with the TEEP media type in use, and		Accept and Content-Type header fields with the TEEP media type, and a
	a body containing the TEEP message buffer provided by the TEEP Agent.		body containing the TEEP message buffer (if any) provided by the TEEP
	The HTTP request is then associated with the TEEP/HTTP Client's		Agent. The HTTP request is then associated with the TEEP/HTTP
	session state.		Client's session state.
	5.4. Receiving an HTTP response		5.4. Receiving an HTTP response
	When an HTTP response is received in response to a request associated		When an HTTP response is received in response to a request associated
	with a given session state, the TEEP/HTTP Client MUST do the		with a given session state, the TEEP/HTTP Client MUST do the
	following.		following.
	If the HTTP response body is empty, the TEEP/HTTP Client's task is		If the HTTP response body is empty, the TEEP/HTTP Client's task is
	complete, and it can delete its session state, and its task is done.		complete, and it can delete its session state, and its task is done.
	If instead the HTTP response body is not empty, the TEEP/HTTP Client		If instead the HTTP response body is not empty, the TEEP/HTTP Client
	passes (e.g., using "ProcessTeepMessage" API as mentioned in		passes (e.g., using the "ProcessTeepMessage" API as mentioned in
	Section 6.2.1 of [I-D.ietf-teep-architecture]) the response body up		Section 6.2.1 of [I-D.ietf-teep-architecture]) the response body up
	to the TEEP Agent associated with the session. The TEEP Agent will		to the TEEP Agent associated with the session. The TEEP Agent will
	then either pass no data back, or pass back a message buffer.		then either pass no data back, or pass back a message buffer.
	If no data is passed back, the TEEP/HTTP Client's task is complete,		If no data is passed back, the TEEP/HTTP Client's task is complete,
	and it can delete its session state, and inform its caller (e.g., the		and it can delete its session state, and inform its caller (e.g., the
	application installer) of success.		application installer) of success.
	If instead the TEEP Agent passes back a message buffer, the TEEP/HTTP		If instead the TEEP Agent passes back a message buffer, the TEEP/HTTP
	Client handles the message buffer as specified in Section 5.3.		Client handles the message buffer as specified in Section 5.3.
	5.5. Handling checks for policy changes		5.5. Handling checks for policy changes
	An implementation MUST provide a way to periodically check for TAM		An implementation MUST provide a way to periodically check for TAM
	policy changes, such as a Trusted Application needing to be deleted		policy changes, such as a Trusted Application needing to be deleted
	from a TEE because it is no longer permitted, or needing to be		from a TEE because it is no longer permitted, or needing to be
	updated to a later version. This can be done in any implementation-		updated to a later version. This can be done in any implementation-
	specific manner, such as:		specific manner, such as any of the following or a combination
			thereof:
	A) The TEEP/HTTP Client might call up to the TEEP Agent at an		A) The TEEP/HTTP Client might call up to the TEEP Agent at an
	interval previously specified by the TEEP Agent. This approach		interval previously specified by the TEEP Agent. This approach
	requires that the TEEP/HTTP Client be capable of running a periodic		requires that the TEEP/HTTP Client be capable of running a periodic
	timer.		timer.
	B) The TEEP/HTTP Client might be informed when an existing TA is		B) The TEEP/HTTP Client might be informed when an existing TA is
	invoked, and call up to the TEEP Agent if more time has passed than		invoked, and call up to the TEEP Agent if more time has passed than
	was previously specified by the TEEP Agent. This approach allows the		was previously specified by the TEEP Agent. This approach allows the
	device to go to sleep for a potentially long period of time.		device to go to sleep for a potentially long period of time.
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 44 ¶
	The TEEP Agent might need to talk to multiple TAMs, however, as shown		The TEEP Agent might need to talk to multiple TAMs, however, as shown
	in Figure 1 of [I-D.ietf-teep-architecture]. To accomplish this, the		in Figure 1 of [I-D.ietf-teep-architecture]. To accomplish this, the
	TEEP/HTTP Client keeps invoking the "RequestPolicyCheck" API until		TEEP/HTTP Client keeps invoking the "RequestPolicyCheck" API until
	the TEEP Agent passes no data back, so that the TEEP Agent can return		the TEEP Agent passes no data back, so that the TEEP Agent can return
	each TAM URI in response to a separate API call.		each TAM URI in response to a separate API call.
	5.6. Error handling		5.6. Error handling
	If any local error occurs where the TEEP/HTTP Client cannot get a		If any local error occurs where the TEEP/HTTP Client cannot get a
	message buffer (empty or not) back from the TEEP Agent, the TEEP/HTTP		message buffer (empty or not) back from the TEEP Agent, the TEEP/HTTP
	Client deletes its session state, and informs its caller (e.g., the		Client deletes its session state, and informs its caller (if any,
	application installer) of a failure.		e.g., the application installer) of a failure.
	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 header		If the TAM does not receive the appropriate Content-Type header field
	fields, the TAM SHOULD fail the request, returning a 415 Unsupported		value, the TAM SHOULD fail the request, returning a 415 Unsupported
	Media Type response. Similarly, if an appropriate Accept header		Media Type response. Similarly, if an appropriate Accept header
	field is not present, the TAM SHOULD fail the request with an		field is not present, the TAM SHOULD fail the request with an
	appropriate error response. (This is for consistency with common		appropriate error response. (This is for consistency with common
	implementation practice to allow the HTTP server to choose a default		implementation practice to allow the HTTP server to choose a default
	error response, since in some implementations the choice is done at		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		the HTTP layer rather than the layer at which TEEP-over-HTTP would be
	implemented.) Otherwise, processing continues as follows.		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, this
	HTTP Server invokes the TAM's "ProcessConnect" API. The TAM will		indicates a request for a new TEEP session, and the TEEP/HTTP Server
	then pass back a (possibly empty) message buffer.		invokes the TAM's "ProcessConnect" API. The TAM will then pass back
			a 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, this
	TEEP/HTTP Server passes the request body to the TAM (e.g., using the		indicates a message on an existing TEEP session, and 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.
	6.2. Getting an empty buffer back from the TAM		6.2. Getting an empty buffer back from the TAM
	If the TAM passes back an empty buffer, the TEEP/HTTP Server sends a		If the TAM passes back an empty buffer, the TEEP/HTTP Server sends a
	successful (2xx) response with no body. It SHOULD be status 204 (No		successful (2xx) response with no body. It SHOULD be status 204 (No
	Content).		Content).
	6.3. Getting a message buffer from the TAM		6.3. Getting a message buffer from the TAM
	If the TAM passes back a non-empty buffer, the TEEP/HTTP Server		If the TAM passes back a non-empty buffer, the TEEP/HTTP Server
	generates a successful (2xx) response with a Content-Type header with		generates a successful (2xx) response with a Content-Type header
	the appropriate media type in use, and with the message buffer as the		field with the TEEP media type, and with the message buffer as the
	body.		body.
	6.4. Error handling		6.4. Error handling
	If any error occurs where the TEEP/HTTP Server cannot get a message		If any error occurs where the TEEP/HTTP Server cannot get a message
	buffer (empty or not) back from the TAM, the TEEP/HTTP Server		buffer (empty or not) back from the TAM, the TEEP/HTTP Server
	generates an appropriate HTTP 5xx error response.		generates an appropriate HTTP 5xx error response.
	7. Sample message flow		7. Sample message flow
	skipping to change at page 11, line 13 ¶		skipping to change at page 11, line 17 ¶
	passes this notification to the TEEP Broker. The TEEP Broker		passes this notification to the TEEP Broker. The TEEP Broker
	picks a TEE (e.g., the only one available) based on this		picks a TEE (e.g., the only one available) based on this
	notification, and passes the information to the TEEP/HTTP Cient		notification, and passes the information to the TEEP/HTTP Cient
	for that TEE.		for that TEE.
	2. The TEEP/HTTP Client calls the TEEP Agent's "RequestTA" API,		2. The TEEP/HTTP Client calls the TEEP Agent's "RequestTA" API,
	passing TA Needed = X.		passing TA Needed = X.
	3. The TEEP Agent finds that no such TA is already installed, but		3. The TEEP Agent finds that no such TA is already installed, but
	that it can be obtained from a given TAM. The TEEP Agent passes		that it can be obtained from a given TAM. The TEEP Agent passes
	the TAM URI (e.g., "https://example.com/tam") to the TEEP/HTTP		back the TAM URI (e.g., "https://example.com/tam") to the TEEP/
	Client.		HTTP Client.
	4. The TEEP/HTTP Client sends an HTTP POST request to the TAM URI:		4. The TEEP/HTTP Client sends an HTTP POST request to the TAM URI:
	POST /tam HTTP/1.1		POST /tam HTTP/1.1
	Host: example.com		Host: example.com
	Accept: application/teep+cbor		Accept: application/teep+cbor
	Content-Length: 0		Content-Length: 0
	User-Agent: Foo/1.0		User-Agent: Foo/1.0
	where the TEEP/HTTP Client fills in an implementation-specific		where the TEEP/HTTP Client fills in an implementation-specific
	value in the User-Agent header.		value in the User-Agent header field.
	5. On the TAM side, the TEEP/HTTP Server receives the HTTP POST		5. On the TAM side, the TEEP/HTTP Server receives the HTTP POST
	request, and calls the TAM's "ProcessConnect" API.		request, and calls the TAM's "ProcessConnect" API.
	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:
	skipping to change at page 11, line 47 ¶		skipping to change at page 11, line 51 ¶
	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
	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 field.
	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
	response, extracts the TEEP message and pass it up to the TEEP		response, extracts the TEEP message and pass it up to the TEEP
	Agent.		Agent.
	9. The TEEP Agent processes the TEEP message, and generates a TEEP		9. The TEEP Agent processes the TEEP message, and generates a TEEP
	response (e.g., QueryResponse) which it passes back to the TEEP/		response (e.g., QueryResponse) which it passes back to the TEEP/
	HTTP Client.		HTTP Client.
	10. The TEEP/HTTP Client gets the TEEP message buffer and sends an		10. The TEEP/HTTP Client gets the TEEP message buffer and sends an
	skipping to change at page 12, line 40 ¶		skipping to change at page 12, line 44 ¶
	HTTP/1.1 204 No Content		HTTP/1.1 204 No Content
	Server: Bar/2.2		Server: Bar/2.2
	14. The TEEP/HTTP Client deletes its session state.		14. The TEEP/HTTP Client deletes its session state.
	8. Security Considerations		8. Security Considerations
	Section 4 discussed security recommendations for HTTPS transport of		Section 4 discussed security recommendations for HTTPS transport of
	TEEP messages. See Section 6 of [I-D.ietf-httpbis-bcp56bis] for		TEEP messages. See Section 6 of [I-D.ietf-httpbis-bcp56bis] for
	additional discussion of HTTP(S) security considerations.		additional discussion of HTTP(S) security considerations. See
			section 9 of [I-D.ietf-teep-architecture] for security considerations
			specific to the use of TEEP.
	9. IANA Considerations		9. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	10. References		10. References
	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. T., Nottingham, M., and J. Reschke, "HTTP		Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	skipping to change at page 13, line 14 ¶		skipping to change at page 13, line 15 ¶
	[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. T., Nottingham, M., and J. Reschke, "HTTP		Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	Semantics", Work in Progress, Internet-Draft, draft-ietf-		Semantics", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-semantics-17, 25 July 2021,		httpbis-semantics-19, 12 September 2021,
	<https://www.ietf.org/archive/id/draft-ietf-httpbis-		<https://www.ietf.org/archive/id/draft-ietf-httpbis-
	semantics-17.txt>.		semantics-19.txt>.
	[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", Work in Progress, Internet-Draft, draft-		(TEEP) Protocol", Work in Progress, Internet-Draft, draft-
	ietf-teep-protocol-06, 12 July 2021,		ietf-teep-protocol-07, 25 October 2021,
	<https://www.ietf.org/archive/id/draft-ietf-teep-protocol-		<https://www.ietf.org/archive/id/draft-ietf-teep-protocol-
	06.txt>.		07.txt>.
	[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-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
	Verification of Domain-Based Application Service Identity
	within Internet Public Key Infrastructure Using X.509
	(PKIX) Certificates in the Context of Transport Layer
	Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
	2011, <https://www.rfc-editor.org/info/rfc6125>.
	[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer		[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
	Security (TLS) / Datagram Transport Layer Security (DTLS)		Security (TLS) / Datagram Transport Layer Security (DTLS)
	Profiles for the Internet of Things", RFC 7925,		Profiles for the Internet of Things", RFC 7925,
	DOI 10.17487/RFC7925, July 2016,		DOI 10.17487/RFC7925, July 2016,
	<https://www.rfc-editor.org/info/rfc7925>.		<https://www.rfc-editor.org/info/rfc7925>.
	[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>.
	10.2. Informative References		10.2. Informative References
	[GP-OTrP] Global Platform, "TEE Management Framework: Open Trust		[GP-OTrP] Global Platform, "TEE Management Framework: Open Trust
	Protocol (OTrP) Profile Version 1.0", Global		Protocol (OTrP) Profile Version 1.0", Global
	Platform GPD_SPE_123, May 2019,		Platform GPD_SPE_123, May 2019,
	<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", Work in		Nottingham, M., "Building Protocols with HTTP", Work in
	Progress, Internet-Draft, draft-ietf-httpbis-bcp56bis-12,		Progress, Internet-Draft, draft-ietf-httpbis-bcp56bis-15,
	27 April 2021, <https://www.ietf.org/archive/id/draft-		27 August 2021, <https://www.ietf.org/archive/id/draft-
	ietf-httpbis-bcp56bis-12.txt>.		ietf-httpbis-bcp56bis-15.txt>.
	[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", Work in Progress, Internet-Draft, draft-		Architecture", Work in Progress, Internet-Draft, draft-
	ietf-teep-architecture-15, 12 July 2021,		ietf-teep-architecture-15, 12 July 2021,
	<https://www.ietf.org/archive/id/draft-ietf-teep-		<https://www.ietf.org/archive/id/draft-ietf-teep-
	architecture-15.txt>.		architecture-15.txt>.
	[I-D.ietf-teep-opentrustprotocol]		[I-D.ietf-teep-opentrustprotocol]
End of changes. 34 change blocks.
	61 lines changed or deleted		68 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/