draft-ietf-teep-otrp-over-http-01.txt		draft-ietf-teep-otrp-over-http-02.txt
	TEEP WG D. Thaler		TEEP WG D. Thaler
	Internet-Draft Microsoft		Internet-Draft Microsoft
	Intended status: Informational July 08, 2019		Intended status: Informational October 22, 2019
	Expires: January 9, 2020		Expires: April 24, 2020
	HTTP Transport for the Open Trust Protocol (OTrP)		HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-
	draft-ietf-teep-otrp-over-http-01		TAM Communication
			draft-ietf-teep-otrp-over-http-02
	Abstract		Abstract
	This document specifies the HTTP transport for the Open Trust		The Open Trust Protocol (OTrP) is used to manage code and
	Protocol (OTrP), which is used to manage code and configuration data		configuration data in a Trusted Execution Environment (TEE). This
	in a Trusted Execution Environment (TEE). An implementation of this		document specifies the HTTP transport for OTrP communication where a
	document can run outside of any TEE, but interacts with an OTrP		Trusted Application Manager (TAM) service is used to manage TEEs in
	implementation that runs inside a TEE.		devices that can initiate communication to the TAM. An
			implementation of this document can (if desired) run outside of any
			TEE, but interacts with an OTrP implementation that runs inside a
			TEE.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 9, 2020.		This Internet-Draft will expire on April 24, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Use of Abstract APIs . . . . . . . . . . . . . . . . . . . . 3		3. TEEP Broker Models . . . . . . . . . . . . . . . . . . . . . 4
	4. Use of HTTP as a Transport . . . . . . . . . . . . . . . . . 3		3.1. Use of Abstract APIs . . . . . . . . . . . . . . . . . . 5
	5. TEEP Broker Behavior . . . . . . . . . . . . . . . . . . . . 4		4. Use of HTTP as a Transport . . . . . . . . . . . . . . . . . 6
	5.1. Receiving a request to install a new Trusted Application 4		5. OTrP/HTTP Client Behavior . . . . . . . . . . . . . . . . . . 7
	5.1.1. Session Creation . . . . . . . . . . . . . . . . . . 5		5.1. Receiving a request to install a new Trusted Application 7
	5.2. Getting a message buffer back from an TEEP Agent . . . . 5		5.1.1. Session Creation . . . . . . . . . . . . . . . . . . 7
	5.3. Receiving an HTTP response . . . . . . . . . . . . . . . 6		5.2. Getting a message buffer back from an OTrP implementation 8
	5.4. Handling checks for policy changes . . . . . . . . . . . 6		5.3. Receiving an HTTP response . . . . . . . . . . . . . . . 8
	5.5. Error handling . . . . . . . . . . . . . . . . . . . . . 7		5.4. Handling checks for policy changes . . . . . . . . . . . 9
	6. TAM Broker Behavior . . . . . . . . . . . . . . . . . . . . . 7		5.5. Error handling . . . . . . . . . . . . . . . . . . . . . 9
	6.1. Receiving an HTTP POST request . . . . . . . . . . . . . 7		6. OTrP/HTTP Server Behavior . . . . . . . . . . . . . . . . . . 10
	6.2. Getting an empty buffer back from the TAM . . . . . . . . 7		6.1. Receiving an HTTP POST request . . . . . . . . . . . . . 10
	6.3. Getting a message buffer from the TAM . . . . . . . . . . 7		6.2. Getting an empty buffer back from the OTrP implementation 10
	6.4. Error handling . . . . . . . . . . . . . . . . . . . . . 7		6.3. Getting a message buffer from the OTrP implementation . . 10
	7. Sample message flow . . . . . . . . . . . . . . . . . . . . . 7		6.4. Error handling . . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Sample message flow . . . . . . . . . . . . . . . . . . . . . 10
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	10.1. Normative References . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	10.2. Informative References . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11		10.2. Informative References . . . . . . . . . . . . . . . . . 13
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Trusted Execution Environments (TEEs), including Intel SGX, ARM		Trusted Execution Environments (TEEs), including environments based
	TrustZone, Secure Elements, and others, enforce that only authorized		on Intel SGX, ARM TrustZone, Secure Elements, and others, enforce
	code can execute within the TEE, and any memory used by such code is		that only authorized code can execute within the TEE, and any memory
	protected against tampering or disclosure outside the TEE. The Open		used by such code is protected against tampering or disclosure
	Trust Protocol (OTrP) is designed to provision authorized code and		outside the TEE. The Open Trust Protocol (OTrP) is designed to
	configuration into TEEs.		provision authorized code and configuration into TEEs.
	To be secure against malware, an OTrP implementation (referred to as		To be secure against malware, an OTrP implementation (referred to as
	an OTrP "Agent" on the client side, and a "Trusted Application		a TEEP "Agent" on the client side, and a "Trusted Application Manager
	Manager (TAM)" on the server side) must themselves run inside a TEE.		(TAM)" on the server side) must themselves run inside a TEE.
	However, the transport for OTrP, along with typical networking		However, the transport for OTrP, along with the underlying TCP/IP
	stacks, need not run inside a TEE. This split allows the set of		stack, does not necessarily run inside a TEE. This split allows the
	highly trusted code to be kept as small as possible, including		set of highly trusted code to be kept as small as possible, including
	allowing code (e.g., TCP/IP) that only sees encrypted messages to be		allowing code (e.g., TCP/IP) that only sees encrypted messages to be
	kept out of the TEE.		kept out of the TEE.
	The OTrP specification [I-D.ietf-teep-opentrustprotocol] describes		The OTrP specification ([I-D.ietf-teep-opentrustprotocol] or
	the behavior of TEEP Agents and TAMs, but does not specify the		[I-D.tschofenig-teep-otrp-v2]) describes the behavior of TEEP Agents
	details of the transport, an implementation of which is referred to		and TAMs, but does not specify the details of the transport. The
	as a "Broker". The purpose of this document is to provide such		purpose of this document is to provide such details. That is, an
	details. That is, the HTTP transport for OTrP is implemented in a		OTrP over HTTP (OTrP/HTTP) implementation delivers messages up to an
	Broker (typically outside a TEE) that delivers messages up to an OTrP		OTrP implementation, and accepts messages from the OTrP
	implementation, and accepts messages from the OTrP implementation to		implementation to be sent over a network. The OTrP over HTTP
	be sent over a network.		implementation can be implemented either outside a TEE (i.e., in a
			TEEP "Broker") or inside a TEE.
			There are two topological scenarios in which OTrP could be deployed:
			1. TAMs are reachable on the Internet, and Agents are on networks
			that might be behind a firewall, so that communication must be
			initiated by an Agent. Thus, the Agent has an HTTP Client and
			the TAM has an HTTP Server.
			2. Agents are reachable on the Internet, and TAMs are on networks
			that might be behind a firewall, so that communication must be
			initiated by a TAM. Thus, the Agent has an HTTP Server and the
			TAM has an HTTP Client.
			The remainder of this document focuses primarily on the first
			scenario as depicted in Figure 1, but some sections (Section 4 and
			Section 8) may apply to the second scenario as well. A fuller
			discussion of the second scenario may be handled by a separate
			document.
			+------------------+ OTrP +------------------+
			| TEEP Agent | <----------------------> | TAM |
			+------------------+ +------------------+
			| |
			+------------------+ OTrP over HTTP +------------------+
			| OTrP/HTTP Client | <----------------------> | OTrP/HTTP Server |
			+------------------+ +------------------+
			| |
			+------------------+ HTTP +------------------+
			| HTTP Client | <----------------------> | HTTP Server |
			+------------------+ +------------------+
			Figure 1: Agent-to-TAM Communication
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"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, and TEEP Broker.		TEEP Agent, TEEP Broker, and Rich Execution Environment (REE).
	3. Use of Abstract APIs		3. TEEP Broker Models
	This document refers to various APIs between a Broker and an OTrP		Section 6 of the TEEP architecture [I-D.ietf-teep-architecture]
	implementation in the abstract, meaning the literal syntax and		defines a TEEP "Broker" as being a component on the device, but
	programming language are not specified, so that various concrete APIs		outside the TEE, that facilitates communication with a TAM. As
	can be designed (outside of the IETF) that are compliant.		depicted in Figure 2, there are multiple ways in which this can be
			implemented, with more or fewer layers being inside the TEE. For
			example, in model A, the model with the smallest TEE footprint, only
			the OTrP implementation is inside the TEE, whereas the OTrP/HTTP
			implementation is in the TEEP Broker outside the TEE.
	It is common in some TEE architectures (e.g., SGX) to refer to calls		Model: A B C ...
	into a Trusted Application (TA) as "ECALLs" (or enclave-calls), and
	calls out from a Trusted Application (TA) as "OCALLs" (or out-calls).
	In other TEE architectures, there may be no OCALLs, but merely data		TEE TEE TEE
	returned from calls into a TA. This document attempts to be agnostic		+----------------+ | | |
	as to the concrete API architecture. As such, abstract APIs used in		| OTrP | Agent | | | Agent
	this document will refer to calls into a TA as API calls, and will		| implementation | | | |
	simply refer to "passing data" back out of the TA. A concrete API		+----------------+ v | |
	might pass data back via an OCALL or via data returned from an API		| | |
	call.		+----------------+ ^ | |
			| OTrP/HTTP | Broker | | |
			| implementation | | | |
			+----------------+ | v |
			| | |
			+----------------+ | ^ |
			| HTTP | | | |
			| implementation | | | |
			+----------------+ | | v
			| | |
			+----------------+ | | ^
			| TCP or QUIC | | | | Broker
			| implementation | | | |
			+----------------+ | | |
			REE REE REE
	This document will also refer to passing "no" data back out of a TA.		Figure 2: TEEP Broker Models
	In an OCALL-based architecture, this might be implemented by not
	making any such call. In a return-based architecture, this might be		In other models, additional layers are moved into the TEE, increasing
	implemented by returning 0 bytes.		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
			typically spoken of as being passed "in" to the TEE, and informaton
			passed in the opposite direction is spoken of as being passed "out".
			In the protocol layering sense, information is typically spoken of as
			being passed "up" or "down" the stack. Since the layer at which
			information is passed in/out may vary by implementation, we will
			generally use "up" and "down" in this document.
			3.1. Use of Abstract APIs
			This document refers to various APIs between an OTrP implementation
			and an OTrP/HTTP implementation in the abstract, meaning the literal
			syntax and programming language are not specified, so that various
			concrete APIs can be designed (outside of the IETF) that are
			compliant.
			Some TEE architectures (e.g., SGX) may support API calls both into
			and out of a TEE. In other TEE architectures, there may be no calls
			out from a TEE, but merely data returned from calls into a TEE. This
			document attempts to be agnostic as to the concrete API architecture
			for Broker/Agent communication. Since in model A, the Broker/Agent
			communication is done at the layer between the OTrP and OTrP/HTTP
			implementations, and there may be some architectures that do not
			support calls out of the TEE (which would be downcalls from OTrP in
			model A), we will refer to passing information up to the OTrP
			implementation as API calls, but will simply refer to "passing data"
			back down from an OTrP implementation. A concrete API might pass
			data back via an API downcall or via data returned from an API
			upcall.
			This document will also refer to passing "no" data back out of an
			OTrP implementation. In a concrete API, this might be implemented by
			not making any downcall, or by returning 0 bytes from an upcall, for
			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.
	When not called out explicitly in this document, all implementation		When not called out explicitly in this document, all implementation
	recommendations in [I-D.ietf-httpbis-bcp56bis] apply to use of HTTP		recommendations in [I-D.ietf-httpbis-bcp56bis] apply to use of HTTP
	by OTrP.		by OTrP.
	Redirects MAY be automatically followed, and no additional request		Redirects MAY be automatically followed, and no additional request
	headers beyond those specified by HTTP need be modified or removed		headers beyond those specified by HTTP need be modified or removed
	skipping to change at page 4, line 23 ¶		skipping to change at page 6, line 49 ¶
	specification):		specification):
	Content-Type: <content type>		Content-Type: <content type>
	Cache-Control: no-store		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
	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 an 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.
	When HTTPS is used, TLS certificates MUST be checked according to		When HTTPS is used, TLS certificates MUST be checked according to
	[RFC2818].		[RFC2818].
	5. TEEP Broker Behavior		5. OTrP/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
	When the TEEP Broker receives a notification (e.g., from an		In some environments, an application installer can determine (e.g.,
	application installer) that an application has a dependency on a		from an app manifest) that the application being installed or updated
	given Trusted Application (TA) being available in a given type of		has a dependency on a given Trusted Application (TA) being available
	TEE, the notification will contain the following:		in a given type of TEE. In such a case, it will notify a TEEP
			Broker, where the notification will contain the following:
	- A unique identifier of the TA		- A unique identifier of the TA
	- Optionally, any metadata to pass to the TEEP Agent. This might		- Optionally, any metadata to provide to the OTrP implementation.
	include a TAM URI provided in the application manifest, for		This might include a TAM URI provided in the application manifest,
	example.		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 such a notification is received, the TEEP Broker first		When a TEEP Broker receives such a notification, it first identifies
	identifies in an implementation-dependent way which TEE (if any) is		in an implementation-dependent way which TEE (if any) is most
	most appropriate based on the constraints expressed. If there is		appropriate based on the constraints expressed. If there is only one
	only one TEE, the choice is obvious. Otherwise, the choice might be		TEE, the choice is obvious. Otherwise, the choice might be based on
	based on factors such as capabilities of available TEE(s) compared		factors such as capabilities of available TEE(s) compared with TEE
	with TEE requirements in the notification.		requirements in the notification. Once the TEEP Broker picks a TEE,
			it passes the notification to the OTrP/HTTP Cient for that TEE.
	The TEEP Broker then informs the TEEP Agent in that TEE by invoking		The OTrP/HTTP Client then informs the OTrP implementation in that TEE
	an appropriate "RequestTA" API that identifies the TA needed and any		by invoking an appropriate "RequestTA" API that identifies the TA
	other associated metadata. The TEEP Broker need not know whether the		needed and any other associated metadata. The OTrP/HTTP Client need
	TEE already has such a TA installed or whether it is up to date.		not know whether the TEE already has such a TA installed or whether
			it is up to date.
	The TEEP Agent will either (a) pass no data back, (b) pass back a TAM		The OTrP implementation will either (a) pass no data back, (b) pass
	URI to connect to, or (c) pass back a message buffer and TAM URI to		back a TAM URI to connect to, or (c) pass back a message buffer and
	send it to. The TAM URI passed back may or may not be the same as		TAM URI to send it to. The TAM URI passed back may or may not be the
	the TAM URI, if any, provided by the broker, depending on the TEEP		same as the TAM URI, if any, provided by the OTrP/HTTP Client,
	Agent's configuration. If they differ, the TEEP Broker MUST use the		depending on the OTrP implementation's configuration. If they
	TAM URI passed back.		differ, the OTrP/HTTP Client 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 Broker simply informs its client		If no data is passed back, the OTrP/HTTP Client simply informs its
	(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 OTrP implementation passes back a TAM URI with no message
	TEEP Broker attempts to create session state, then sends an HTTP(S)		buffer, the OTrP/HTTP Client attempts to create session state, then
	POST to the TAM URI with an Accept header and an empty body. The		sends an HTTP(S) POST to the TAM URI with an Accept header and an
	HTTP request is then associated with the TEEP Broker's session state.		empty body. The HTTP request is then associated with the OTrP/HTTP
			Client's session state.
	If the TEEP Agent instead passes back a TAM URI with a message		If the OTrP implementation instead passes back a TAM URI with a
	buffer, the TEEP Broker attempts to create session state and handles		message buffer, the OTrP/HTTP Client attempts to create session state
	the message buffer as specified in Section 5.2.		and handles the message buffer as specified in Section 5.2.
	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 OTrP implementation.
	- Any context that identifies an HTTP request, if one is		- Any context that identifies an HTTP request, if one is
	outstanding. Initially, none exists.		outstanding. Initially, none exists.
	5.2. Getting a message buffer back from an TEEP Agent		5.2. Getting a message buffer back from an OTrP implementation
	When a message buffer (and TAM URI) is passed to a TEEP Broker from		When an OTrP implementation passes a message buffer (and TAM URI) to
	an TEEP Agent, the TEEP Broker MUST do the following, using the TEEP		an OTrP/HTTP Client, the OTrP/HTTP Client MUST do the following,
	Broker's session state associated with its API call to the TEEP		using the OTrP/HTTP Client's session state associated with its API
	Agent.		call to the OTrP implementation.
	The TEEP Broker sends an HTTP POST request to the TAM URI with Accept		The OTrP/HTTP Client sends an HTTP POST request to the TAM URI with
	and Content-Type headers with the OTrP media type in use, and a body		Accept and Content-Type headers with the OTrP media type in use, and
	containing the OTrP message buffer provided by the TEEP Agent. The		a body containing the OTrP message buffer provided by the OTrP
	HTTP request is then associated with the TEEP Broker's session state.		implementation. The HTTP request is then associated with the OTrP/
			HTTP Client's session state.
	5.3. Receiving an HTTP response		5.3. 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 Broker MUST do the following.		with a given session state, the OTrP/HTTP Client MUST do the
			following.
	If the HTTP response body is empty, the TEEP Broker's task is		If the HTTP response body is empty, the OTrP/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 Broker calls		If instead the HTTP response body is not empty, the OTrP/HTTP Client
	a "ProcessOTrPMessage" API (Section 6.2 of		calls a "ProcessOTrPMessage" API (Section 6.2 of
	[I-D.ietf-teep-opentrustprotocol]) to pass the response body to the		[I-D.ietf-teep-opentrustprotocol]) to pass the response body up to
	TEEP Agent associated with the session. The TEEP Agent will then		the OTrP implementation associated with the session. The OTrP
	pass no data back, or pass pack a message buffer.		implementation will then either pass no data back, or pass back a
			message buffer.
	If no data is passed back, the TEEP Broker's task is complete, and it		If no data is passed back, the OTrP/HTTP Client's task is complete,
	can delete its session state, and inform its client (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		If instead the OTrP implementation passes back a message buffer, the
	Broker handles the message buffer as specified in Section 5.2.		OTrP/HTTP Client handles the message buffer as specified in
			Section 5.2.
	5.4. Handling checks for policy changes		5.4. Handling checks for policy changes
	An implementation MUST provide a way to periodically check for OTrP		An implementation MUST provide a way to periodically check for OTrP
	policy changes. This can be done in any implementation-specific		policy changes. This can be done in any implementation-specific
	manner, such as:		manner, such as:
	A) The TEEP Broker might call into the TEEP Agent at an interval		A) The OTrP/HTTP Client might call up to the OTrP implementation at
	previously specified by the TEEP Agent. This approach requires that		an interval previously specified by the OTrP implementation. This
	the TEEP Broker be capable of running a periodic timer.		approach requires that the OTrP/HTTP Client be capable of running a
			periodic timer.
	B) The TEEP Broker might be informed when an existing TA is invoked,		B) The OTrP/HTTP Client might be informed when an existing TA is
	and call into the TEEP Agent if more time has passed than was		invoked, and call up to the OTrP implementation if more time has
	previously specified by the TEEP Agent. This approach allows the		passed than was previously specified by the OTrP implementation.
	device to go to sleep for a potentially long period of time.		This approach allows the device to go to sleep for a potentially long
			period of time.
	C) The TEEP Broker might be informed when any attestation attempt		C) The OTrP/HTTP Client might be informed when any attestation
	determines that the device is out of compliance, and call into the		attempt determines that the device is out of compliance, and call up
	TEEP Agent to remediate.		to the OTrP implementation to remediate.
	The TEEP Broker informs the TEEP Agent by invoking an appropriate		The OTrP/HTTP Client informs the OTrP implementation by invoking an
	"RequestPolicyCheck" API. The TEEP Agent will either (a) pass no		appropriate "RequestPolicyCheck" API. The OTrP implementation will
	data back, (b) pass back a TAM URI to connect to, or (c) pass back a		either (a) pass no data back, (b) pass back a TAM URI to connect to,
	message buffer and TAM URI to send it to. Processing then continues		or (c) pass back a message buffer and TAM URI to send it to.
	as specified in Section 5.1.1.		Processing then continues as specified in Section 5.1.1.
	5.5. Error handling		5.5. Error handling
	If any local error occurs where the TEEP Broker cannot get a message		If any local error occurs where the OTrP/HTTP Client cannot get a
	buffer (empty or not) back from the TEEP Agent, the TEEP Broker		message buffer (empty or not) back from the OTrP implementation, the
	deletes its session state, and informs its client (e.g., the		OTrP/HTTP Client deletes its session state, and informs its caller
	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 Broker calls the		layer error (e.g., network unreachable), the OTrP/HTTP Client calls
	TEEP Agent's "ProcessError" API, and then deletes its session state		the OTrP implementation's "ProcessError" API, and then deletes its
	and informs its client of a failure.		session state and informs its caller of a failure.
	6. TAM Broker Behavior		6. OTrP/HTTP Server Behavior
	6.1. Receiving an HTTP POST request		6.1. Receiving an HTTP POST request
	When an HTTP POST request is received with an empty body, the TAM		When an HTTP POST request is received with an empty body, the OTrP/
	Broker invokes the TAM's "ProcessConnect" API. The TAM will then		HTTP Server invokes the TAM's "ProcessConnect" API. The TAM will
	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 TAM		When an HTTP POST request is received with a non-empty body, the
	Broker calls the TAM's "ProcessOTrPMessage" API to pass it the		OTrP/HTTP Server calls the TAM's "ProcessOTrPMessage" API to pass it
	request body. The TAM will then pass back a (possibly empty) message		the request body. The TAM will then pass back a (possibly empty)
	buffer.		message buffer.
	6.2. Getting an empty buffer back from the TAM		6.2. Getting an empty buffer back from the OTrP implementation
	If the TAM passes back an empty buffer, the TAM Broker sends a		If the OTrP implementation passes back an empty buffer, the OTrP/HTTP
	successful (2xx) response with no body.		Server sends a successful (2xx) response with no body.
	6.3. Getting a message buffer from the TAM		6.3. Getting a message buffer from the OTrP implementation
	If the TAM passes back a non-empty buffer, the TAM Broker generates a		If the OTrP implementation passes back a non-empty buffer, the OTrP/
	successful (2xx) response with a Content-Type header with the OTrP		HTTP Server generates a successful (2xx) response with a Content-Type
	media type in use, and with the message buffer as the body.		header with the OTrP media type in use, and with the message buffer
			as the body.
	6.4. Error handling		6.4. Error handling
	If any error occurs where the TAM Broker cannot get a message buffer		If any error occurs where the OTrP/HTTP Server cannot get a message
	(empty or not) back from the TAM, the TAM Broker generates an		buffer (empty or not) back from the OTrP implementation, the OTrP/
	appropriate HTTP error response.		HTTP Server generates an appropriate HTTP error response.
	7. Sample message flow		7. Sample message flow
	The following shows a sample OTrP message flow that uses application/		The following shows a sample OTrP message flow that uses application/
	otrp+json as the Content-Type.		otrp+json as the Content-Type.
	1. An application installer determines (e.g., from an app manifest)		1. An application installer determines (e.g., from an app manifest)
	that the application has a dependency on TA "X", and passes this		that the application has a dependency on TA "X", and passes this
	notification to the TEEP Broker. The TEEP Broker picks an TEEP		notification to the TEEP Broker. The TEEP Broker picks a TEE
	Agent (e.g., the only one available) based on this notification.		(e.g., the only one available) based on this notification, and
			passes the information to the OTrP/HTTP Cient for that TEE.
	2. The TEEP Broker calls the TEEP Agent's "RequestTA" API, passing		2. The OTrP/HTTP Client calls the OTrP implementation's "RequestTA"
	TA Needed = X.		API, passing TA Needed = X.
	3. The TEEP Agent finds that no such TA is already installed, but		3. The OTrP implementation finds that no such TA is already
	that it can be obtained from a given TAM. The TEEP Agent passes		installed, but that it can be obtained from a given TAM. The
	the TAM URI (e.g., "https://example.com/tam") to the TEEP		TEEP Agent passes the TAM URI (e.g., "https://example.com/tam")
	Broker. (If the TEEP Agent already had a cached TAM certificate		to the OTrP/HTTP Client. (If the OTrP implementation already
	that it trusts, it could skip to step 9 instead and generate a		had a cached TAM certificate that it trusts, it could skip to
	GetDeviceStateResponse.)		step 9 instead and generate a GetDeviceStateResponse.)
	4. The TEEP Broker sends an HTTP POST request to the TAM URI:		4. The OTrP/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/otrp+json		Accept: application/otrp+json
	Content-Length: 0		Content-Length: 0
	User-Agent: Foo/1.0		User-Agent: Foo/1.0
	5. The TAM Broker receives the HTTP POST request, and calls the		5. On the TAM side, the OTrP/HTTP Server receives the HTTP POST
	TAM's "ProcessConnect" API.		request, and calls the OTrP implementation's "ProcessConnect"
			API.
	6. The TAM generates an OTrP message (typically		6. The OTrP implementation generates an OTrP message (where
	GetDeviceStateRequest is the first message) and passes it to the		typically GetDeviceStateRequest is the first message) and passes
	TAM Broker.		it to the OTrP/HTTP Server.
	7. The TAM Broker sends an HTTP successful response with the OTrP		7. The OTrP/HTTP Server sends an HTTP successful response with the
	message in the body:		OTrP message in the body:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/otrp+json		Content-Type: application/otrp+json
	Content-Length: [length of OTrP message here]		Content-Length: [length of OTrP message here]
	Server: Bar/2.2		Server: Bar/2.2
	Cache-Control: no-store		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
	[OTrP message here]		[OTrP message here]
	8. The TEEP Broker gets the HTTP response, extracts the OTrP		8. Back on the TEEP Agent side, the OTrP/HTTP Client gets the HTTP
	message and calls the TEEP Agent's "ProcessOTrPMessage" API to		response, extracts the OTrP message and calls the OTrP
	pass it the message.		implementation's "ProcessOTrPMessage" API to pass it the
			message.
	9. The TEEP Agent processes the OTrP message, and generates an OTrP		9. The OTrP implementation processes the OTrP message, and
	response (e.g., GetDeviceStateResponse) which it passes back to		generates an OTrP response (e.g., GetDeviceStateResponse) which
	the TEEP Broker.		it passes back to the OTrP/HTTP Client.
	10. The TEEP Broker gets the OTrP message buffer and sends an HTTP		10. The OTrP/HTTP Client gets the OTrP message buffer and sends an
	POST request to the TAM URI, with the OTrP message in the body:		HTTP POST request to the TAM URI, with the OTrP message in the
			body:
	POST /tam HTTP/1.1		POST /tam HTTP/1.1
	Host: example.com		Host: example.com
	Accept: application/otrp+json		Accept: application/otrp+json
	Content-Type: application/otrp+json		Content-Type: application/otrp+json
	Content-Length: [length of OTrP message here]		Content-Length: [length of OTrP message here]
	User-Agent: Foo/1.0		User-Agent: Foo/1.0
	[OTrP message here]		[OTrP message here]
	11. The TAM Broker receives the HTTP POST request, and calls the		11. The OTrP/HTTP Server receives the HTTP POST request, and calls
	TAM's "ProcessOTrPMessage" API.		the OTrP implementation's "ProcessOTrPMessage" API.
	12. Steps 6-11 are then repeated until the TAM passes no data back		12. Steps 6-11 are then repeated until the OTrP implementation
	to the TAM Broker in step 6.		passes no data back to the OTrP/HTTP Server in step 6.
	13. The TAM Broker sends an HTTP successful response with no body:		13. The OTrP/HTTP Server sends an HTTP successful response with no
			body:
	HTTP/1.1 204 No Content		HTTP/1.1 204 No Content
	Server: Bar/2.2		Server: Bar/2.2
	14. The TEEP Broker deletes its session state.		14. The OTrP/HTTP Client deletes its session state.
	8. Security Considerations		8. Security Considerations
	Although OTrP is protected end-to-end inside of HTTP, there is still		Although OTrP is protected end-to-end inside of HTTP, there is still
	value in using HTTPS for transport, since HTTPS can provide		value in using HTTPS for transport, since HTTPS can provide
	additional protections as discussed in Section 6 of		additional protections as discussed in Section 6 of
	[I-D.ietf-httpbis-bcp56bis]. As such, Broker implementations MUST		[I-D.ietf-httpbis-bcp56bis]. As such, OTrP/HTTP implementations MUST
	support HTTPS. The choice of HTTP vs HTTPS at runtime is up to		support HTTPS. The choice of HTTP vs HTTPS at runtime is up to
	policy, where an administrator configures the TAM URI to be used, but		policy, where an administrator configures the TAM URI to be used, but
	it is expected that real deployments will always use HTTPS TAM URIs.		it is expected that real deployments will always use HTTPS TAM URIs.
	9. IANA Considerations		9. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	10. References		10. References
	skipping to change at page 10, line 23 ¶		skipping to change at page 13, line 19 ¶
	[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-05 (work in		Semantics", draft-ietf-httpbis-semantics-05 (work in
	progress), July 2019.		progress), July 2019.
	[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-
	opentrustprotocol-03 (work in progress), May 2019.		opentrustprotocol-03 (work in progress), May 2019.
			[I-D.tschofenig-teep-otrp-v2]
			Pei, M., Tschofenig, H., and D. Wheeler, "The Open Trust
			Protocol (OTrP) v2", draft-tschofenig-teep-otrp-v2-00
			(work in progress), July 2019.
	[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-
	editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000, <https://www.rfc-		DOI 10.17487/RFC2818, May 2000, <https://www.rfc-
	editor.org/info/rfc2818>.		editor.org/info/rfc2818>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	skipping to change at page 10, line 46 ¶		skipping to change at page 13, line 47 ¶
	10.2. Informative References		10.2. Informative References
	[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-08 (work in progress), November		ietf-httpbis-bcp56bis-08 (work in progress), November
	2018.		2018.
	[I-D.ietf-teep-architecture]		[I-D.ietf-teep-architecture]
	Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D.		Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D.
	Liu, "Trusted Execution Environment Provisioning (TEEP)		Liu, "Trusted Execution Environment Provisioning (TEEP)
	Architecture", draft-ietf-teep-architecture-02 (work in		Architecture", draft-ietf-teep-architecture-03 (work in
	progress), March 2019.		progress), July 2019.
	Author's Address		Author's Address
	Dave Thaler		Dave Thaler
	Microsoft		Microsoft
	EMail: dthaler@microsoft.com		EMail: dthaler@microsoft.com
End of changes. 64 change blocks.
	201 lines changed or deleted		314 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/