draft-ietf-teep-otrp-over-http-06.txt   draft-ietf-teep-otrp-over-http-07.txt 
TEEP WG D. Thaler TEEP WG D. Thaler
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Informational April 02, 2020 Intended status: Informational July 23, 2020
Expires: October 4, 2020 Expires: January 24, 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-06 draft-ietf-teep-otrp-over-http-07
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 TEEs in devices that can initiate communication to is used to manage code and data in TEEs on devices that can initiate
the TAM. An implementation of this document can (if desired) run communication to the TAM. An implementation of this document can (if
outside of any TEE, but interacts with a TEEP implementation that desired) run outside of any TEE, but interacts with a TEEP
runs inside a TEE. 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 October 4, 2020. This Internet-Draft will expire on January 24, 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 Models . . . . . . . . . . . . . . . . . . . . . 4
3.1. Use of Abstract APIs . . . . . . . . . . . . . . . . . . 5 3.1. Use of Abstract APIs . . . . . . . . . . . . . . . . . . 5
4. Use of HTTP as a Transport . . . . . . . . . . . . . . . . . 6 4. Use of HTTP as a Transport . . . . . . . . . . . . . . . . . 6
5. TEEP/HTTP Client Behavior . . . . . . . . . . . . . . . . . . 7 5. TEEP/HTTP Client Behavior . . . . . . . . . . . . . . . . . . 7
5.1. Receiving a request to install a new Trusted Application 7 5.1. Receiving a request to install a new Trusted Application 7
5.1.1. Session Creation . . . . . . . . . . . . . . . . . . 7 5.1.1. Session Creation . . . . . . . . . . . . . . . . . . 8
5.2. Getting a message buffer back from a TEEP implementation 8 5.2. Getting a message buffer back from a TEEP Agent . . . . . 8
5.3. Receiving an HTTP response . . . . . . . . . . . . . . . 8 5.3. Receiving an HTTP response . . . . . . . . . . . . . . . 9
5.4. Handling checks for policy changes . . . . . . . . . . . 9 5.4. Handling checks for policy changes . . . . . . . . . . . 9
5.5. Error handling . . . . . . . . . . . . . . . . . . . . . 9 5.5. Error handling . . . . . . . . . . . . . . . . . . . . . 10
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 TEEP implementation 10 6.2. Getting an empty buffer back from the TAM . . . . . . . . 10
6.3. Getting a message buffer from the TEEP implementation . . 10 6.3. Getting a message buffer from the TAM . . . . . . . . . . 10
6.4. Error handling . . . . . . . . . . . . . . . . . . . . . 10 6.4. Error handling . . . . . . . . . . . . . . . . . . . . . 11
7. Sample message flow . . . . . . . . . . . . . . . . . . . . . 10 7. Sample message flow . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Trusted Execution Environments (TEEs), including environments based A Trusted Execution Environment (TEE) is an environment that enforces
on Intel SGX, ARM TrustZone, Secure Elements, and others, enforce that any code within that environment cannot be tampered with, and
that only authorized code can execute within the TEE, and any memory that any data used by such code cannot be read or tampered with by
used by such code is protected against tampering or disclosure any code outside that environment. The Trusted Execution Environment
outside the TEE. The Trusted Execution Environment Provisioning Provisioning (TEEP) protocol is designed to provision authorized code
(TEEP) protocol is designed to provision authorized code and and configuration into TEEs.
configuration into TEEs.
To be secure against malware, a TEEP implementation (referred to as a To be secure against malware, a TEEP implementation (referred to as a
TEEP "Agent" on the client side, and a "Trusted Application Manager TEEP "Agent" on the client side, and a "Trusted Application Manager
(TAM)" on the server side) must themselves run inside a TEE. (TAM)" on the server side) SHOULD themselves run inside a TEE,
However, the transport for TEEP, along with the underlying TCP/IP although a TAM running outside a TEE is also supported. However, the
stack, does not necessarily run inside a TEE. This split allows the transport for TEEP, along with the underlying TCP/IP stack, does not
set of highly trusted code to be kept as small as possible, including necessarily run inside a TEE. This split allows the set of highly
allowing code (e.g., TCP/IP or QUIC [I-D.ietf-quic-transport]) that trusted code to be kept as small as possible, including allowing code
only sees encrypted messages, to be kept out of the TEE. (e.g., TCP/IP or QUIC [I-D.ietf-quic-transport]) that only sees
encrypted messages, to be kept out of the TEE.
The TEEP specification [I-D.ietf-teep-protocol] (like its The TEEP specification [I-D.ietf-teep-protocol] (like its
predecessors [I-D.ietf-teep-opentrustprotocol] and [GP-OTrP]) predecessors [I-D.ietf-teep-opentrustprotocol] and [GP-OTrP])
describes the behavior of TEEP Agents and TAMs, but does not specify describes the behavior of TEEP Agents and TAMs, but does not specify
the details of the transport. The purpose of this document is to the details of the transport. The purpose of this document is to
provide such details. That is, a TEEP-over-HTTP (TEEP/HTTP) provide such details. That is, a TEEP-over-HTTP (TEEP/HTTP)
implementation delivers messages up to a TEEP implementation, and implementation delivers messages up to a TEEP implementation, and
accepts messages from the TEEP implementation to be sent over a accepts messages from the TEEP implementation to be sent over a
network. The TEEP-over-HTTP implementation can be implemented either network. The TEEP-over-HTTP implementation can be implemented either
outside a TEE (i.e., in a TEEP "Broker") or inside a TEE. outside a TEE (i.e., in a TEEP "Broker") or inside a TEE.
skipping to change at page 4, line 5 skipping to change at page 3, line 49
+------------------+ TEEP-over-HTTP +------------------+ +------------------+ TEEP-over-HTTP +------------------+
| TEEP/HTTP Client | <----------------------> | TEEP/HTTP Server | | TEEP/HTTP Client | <----------------------> | TEEP/HTTP Server |
+------------------+ +------------------+ +------------------+ +------------------+
| | | |
+------------------+ HTTP +------------------+ +------------------+ HTTP +------------------+
| HTTP Client | <----------------------> | HTTP Server | | HTTP Client | <----------------------> | HTTP Server |
+------------------+ +------------------+ +------------------+ +------------------+
Figure 1: Agent-to-TAM Communication Figure 1: Agent-to-TAM Communication
This document specifies the middle layer (TEEP-over-HTTP), whereas
the top layer (TEEP) is specified in [I-D.ietf-teep-protocol].
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, and Rich Execution Environment (REE). TEEP Agent, TEEP Broker, and Rich Execution Environment (REE).
3. TEEP Broker Models 3. TEEP Broker Models
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. As
depicted in Figure 2, there are multiple ways in which this can be depicted in Figure 2, there are multiple ways in which this can be
implemented, with more or fewer layers being inside the TEE. For implemented, with more or fewer layers being inside the TEE. For
example, in model A, the model with the smallest TEE footprint, only example, in model A, the model with the smallest TEE footprint, only
the TEEP implementation is inside the TEE, whereas the TEEP/HTTP the TEEP implementation is inside the TEE, whereas the TEEP/HTTP
skipping to change at page 6, line 26 skipping to change at page 6, line 26
back via an API downcall or via data returned from an API upcall. 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 a TEEP This document will also refer to passing "no" data back out of a TEEP
implementation. In a concrete API, this might be implemented by not implementation. In a concrete API, this might be implemented by not
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.
When not called out explicitly in this document, all implementation For the motivation behind the HTTP recommendations in this document,
recommendations in [I-D.ietf-httpbis-bcp56bis] apply to use of HTTP see the discussion of HTTP as a transport in
by TEEP. [I-D.ietf-httpbis-bcp56bis].
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
upon a following such a redirect. 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] (replacing explained in Section 4.12 of [I-D.ietf-httpbis-bcp56bis] (using the
the content type with the relevant TEEP content type per the TEEP relevant TEEP content type defined in [I-D.ietf-teep-protocol]):
specification):
Content-Type: <content type> Content-Type: application/teep+cbor
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
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
TEEP is protected end-to-end inside of HTTP, there is still value in
using HTTPS for transport, since HTTPS can provide additional
protections as discussed in Sections 4.4.2 and 6 of
[I-D.ietf-httpbis-bcp56bis].
However, there may be constrained nodes where code space is an issue.
[RFC7925] provides TLS profiles that can be used in many constrained
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
by the TEEP protocol.
When HTTPS is used, TLS certificates MUST be checked according to When HTTPS is used, TLS certificates MUST be checked according to
[RFC2818]. See [BCP195] for additional TLS recommendations. [RFC2818], as well as [RFC6125] if PKIX certificates are used. See
[BCP195] for additional TLS recommendations and [RFC7925] for TLS
recommandations 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 app manifest) that the application being installed or updated from an app manifest) that the application being installed or updated
has a dependency on a given Trusted Application (TA) being available 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 TEEP in a given type of TEE. In such a case, it will notify a TEEP
Broker, where the notification will contain the following: Broker, where the 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 implementation. - Optionally, any metadata to provide to the TEEP Agent. This might
This might include a TAM URI provided in the application manifest, include a TAM URI provided in the application manifest, for
for example. 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 most in an implementation-dependent way which TEE (if any) is most
appropriate based on the constraints expressed. If there is only one appropriate based on the constraints expressed. If there is only one
TEE, the choice is obvious. Otherwise, the choice might be based on TEE, the choice is obvious. Otherwise, the choice might be based on
factors such as capabilities of available TEE(s) compared with TEE factors such as capabilities of available TEE(s) compared with TEE
requirements in the notification. Once the TEEP Broker picks a TEE, requirements in the notification. Once the TEEP Broker picks a TEE,
it passes the notification to the TEEP/HTTP Client for that TEE. it passes the notification to the TEEP/HTTP Client for that TEE.
The TEEP/HTTP Client then informs the TEEP implementation in that TEE The TEEP/HTTP Client then informs the TEEP Agent in that TEE by
by invoking an appropriate "RequestTA" API that identifies the TA invoking an appropriate "RequestTA" API that identifies the TA needed
needed and any other associated metadata. The TEEP/HTTP Client need and any other associated metadata. The TEEP/HTTP Client need not
not know whether the TEE already has such a TA installed or whether know whether the TEE already has such a TA installed or whether it is
it is up to date. up to date.
The TEEP implementation will either (a) pass no data back, (b) pass The TEEP Agent will either (a) pass no data back, (b) pass back a TAM
back a TAM URI to connect to, or (c) pass back a message buffer and URI to connect to, or (c) pass back a message buffer and TAM URI to
TAM URI to send it to. The TAM URI passed back may or may not be the send it to. The TAM URI passed back may or may not be the same as
same as the TAM URI, if any, provided by the TEEP/HTTP Client, the TAM URI, if any, provided by the TEEP/HTTP Client, depending on
depending on the TEEP implementation's configuration. If they the TEEP Agent's configuration. If they differ, the TEEP/HTTP Client
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 implementation passes back a TAM URI with no message If the TEEP Agent passes back a TAM URI with no message buffer, the
buffer, the TEEP/HTTP Client attempts to create session state, then TEEP/HTTP Client attempts to create session state, then sends an
sends an HTTP(S) POST to the TAM URI with an Accept header and an HTTP(S) POST to the TAM URI with an Accept header with the TEEP media
empty body. The HTTP request is then associated with the TEEP/HTTP type requested, and an empty body. The HTTP request is then
Client's session state. associated with the TEEP/HTTP Client's session state.
If the TEEP implementation instead passes back a TAM URI with a If the TEEP Agent instead passes back a TAM URI with a message
message buffer, the TEEP/HTTP Client attempts to create session state buffer, the TEEP/HTTP Client attempts to create session state and
and handles the message buffer as specified in Section 5.2. 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 implementation. the TEEP Agent.
- 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 a TEEP implementation 5.2. Getting a message buffer back from a TEEP Agent
When a TEEP implementation passes a message buffer (and TAM URI) to a When a TEEP Agent passes a message buffer (and TAM URI) to a TEEP/
TEEP/HTTP Client, the TEEP/HTTP Client MUST do the following, using HTTP Client, the TEEP/HTTP Client MUST do the following, using the
the TEEP/HTTP Client's session state associated with its API call to TEEP/HTTP Client's session state associated with its API call to the
the TEEP implementation. 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 headers with the TEEP media type in use, and
a body containing the TEEP message buffer provided by the TEEP a body containing the TEEP message buffer provided by the TEEP Agent.
implementation. The HTTP request is then associated with the TEEP/ The HTTP request is then associated with the TEEP/HTTP Client's
HTTP Client's session state. 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/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 "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 implementation associated with the session. The TEEP to the TEEP Agent associated with the session. The TEEP Agent will
implementation will then either pass no data back, or pass back a then either pass no data back, or pass back a message buffer.
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 implementation passes back a message buffer, the If instead the TEEP Agent passes back a message buffer, the TEEP/HTTP
TEEP/HTTP Client handles the message buffer as specified in Client handles the message buffer as specified in Section 5.2.
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 TEEP An implementation MUST provide a way to periodically check for TAM
policy changes. This can be done in any implementation-specific policy changes, such as a Trusted Application needing to be deleted
manner, such as: 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-
specific manner, such as:
A) The TEEP/HTTP Client might call up to the TEEP implementation at A) The TEEP/HTTP Client might call up to the TEEP Agent at an
an interval previously specified by the TEEP implementation. This interval previously specified by the TEEP Agent. This approach
approach requires that the TEEP/HTTP Client be capable of running a requires that the TEEP/HTTP Client be capable of running a periodic
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 implementation if more time has invoked, and call up to the TEEP Agent if more time has passed than
passed than was previously specified by the TEEP implementation. was previously specified by the TEEP Agent. This approach allows the
This approach allows the device to go to sleep for a potentially long device to go to sleep for a potentially long period of time.
period of time.
C) The TEEP/HTTP Client might be informed when any attestation C) The TEEP/HTTP Client might be informed when any attestation
attempt determines that the device is out of compliance, and call up attempt determines that the device is out of compliance, and call up
to the TEEP implementation to remediate. to the TEEP Agent to remediate.
The TEEP/HTTP Client informs the TEEP implementation by invoking an The TEEP/HTTP Client informs the TEEP Agent by invoking an
appropriate "RequestPolicyCheck" API. The TEEP implementation will appropriate "RequestPolicyCheck" API. The TEEP Agent will either (a)
either (a) pass no data back, (b) pass back a TAM URI to connect to, pass no data back, (b) pass back a TAM URI to connect to, or (c) pass
or (c) pass back a message buffer and TAM URI to send it to. back a message buffer and TAM URI to send it to. Processing then
Processing then continues as specified in Section 5.1.1. continues as specified in Section 5.1.1.
5.5. Error handling 5.5. 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 implementation, the message buffer (empty or not) back from the TEEP Agent, the TEEP/HTTP
TEEP/HTTP Client deletes its session state, and informs its caller Client deletes its session state, and informs its caller (e.g., the
(e.g., the application installer) of a failure. 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 implementation's "ProcessError" API, and then deletes its the TEEP Agent's "ProcessError" API, and then deletes its session
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
header fields, the TAM SHOULD fail the request, returning a 406 (not
acceptable) response. 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.
6.2. Getting an empty buffer back from the TEEP implementation 6.2. Getting an empty buffer back from the TAM
If the TEEP implementation passes back an empty buffer, the TEEP/HTTP If the TAM passes back an empty buffer, the TEEP/HTTP Server sends a
Server sends a successful (2xx) response with no body. successful (2xx) response with no body. It SHOULD be status 204 (No
Content).
6.3. Getting a message buffer from the TEEP implementation 6.3. Getting a message buffer from the TAM
If the TEEP implementation passes back a non-empty buffer, the TEEP/ If the TAM passes back a non-empty buffer, the TEEP/HTTP Server
HTTP Server generates a successful (2xx) response with a Content-Type generates a successful (2xx) response with a Content-Type header with
header with the appropriate media type in use, and with the message the appropriate media type in use, and with the message buffer as the
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 TEEP implementation, the TEEP/ buffer (empty or not) back from the TAM, the TEEP/HTTP Server
HTTP Server generates an appropriate HTTP error response. generates an appropriate HTTP 5xx error response.
7. Sample message flow 7. Sample message flow
The following shows a sample TEEP message flow that uses application/ The following shows a sample TEEP message flow that uses application/
teep+cbor as the Content-Type. teep+cbor 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 a TEE notification to the TEEP Broker. The TEEP Broker picks a TEE
(e.g., the only one available) based on this notification, and (e.g., the only one available) based on this notification, and
passes the information to the TEEP/HTTP Cient for that TEE. passes the information to the TEEP/HTTP Cient for that TEE.
2. The TEEP/HTTP Client calls the TEEP implementation's "RequestTA" 2. The TEEP/HTTP Client calls the TEEP Agent's "RequestTA" API,
API, passing TA Needed = X. passing TA Needed = X.
3. The TEEP implementation finds that no such TA is already 3. The TEEP Agent finds that no such TA is already installed, but
installed, but that it can be obtained from a given TAM. The that it can be obtained from a given TAM. The TEEP Agent passes
TEEP Agent passes the TAM URI (e.g., "https://example.com/tam") the TAM URI (e.g., "https://example.com/tam") to the TEEP/HTTP
to the TEEP/HTTP Client. (If the TEEP implementation already Client.
had cached TAM OCSP_DATA that it trusts based on a previous
QueryRequest, it could skip to step 9 instead and generate a
QueryResponse.)
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.
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 TEEP implementation's "ProcessConnect" request, and calls the TAM's "ProcessConnect" API.
API.
6. The TEEP implementation generates a TEEP message (where 6. The TAM generates a TEEP message (where typically QueryRequest
typically QueryRequest is the first message) and passes it to is the first message) and passes it to the TEEP/HTTP Server.
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 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
response, extracts the TEEP message and pass it up to the TEEP response, extracts the TEEP message and pass it up to the TEEP
implementation. Agent.
9. The TEEP implementation processes the TEEP message, and 9. The TEEP Agent processes the TEEP message, and generates a TEEP
generates a TEEP response (e.g., QueryResponse) which it passes response (e.g., QueryResponse) which it passes back to the TEEP/
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
HTTP POST request to the TAM URI, with the TEEP message in the HTTP POST request to the TAM URI, with the TEEP message in the
body: body:
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-Type: application/teep+cbor Content-Type: application/teep+cbor
Content-Length: [length of TEEP message here] Content-Length: [length of TEEP message here]
User-Agent: Foo/1.0 User-Agent: Foo/1.0
[TEEP message here] [TEEP message here]
11. The TEEP/HTTP Server receives the HTTP POST request, and passes 11. The TEEP/HTTP Server receives the HTTP POST request, and passes
the payload up to the TAM implementation. the payload up to the TAM.
12. Steps 6-11 are then repeated until the TEEP implementation 12. Steps 6-11 are then repeated until the TAM passes no data back
passes no data back to the TEEP/HTTP Server in step 6. to the TEEP/HTTP Server in step 6.
13. The TEEP/HTTP Server sends an HTTP successful response with no 13. The TEEP/HTTP Server sends an HTTP successful response with no
body: body:
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
Although TEEP is protected end-to-end inside of HTTP, there is still Section 4 discussed security recommendations for HTTPS transport of
value in using HTTPS for transport, since HTTPS can provide TEEP messages. See Section 6 of [I-D.ietf-httpbis-bcp56bis] for
additional protections as discussed in Section 6 of additional discussion of HTTP(S) security considerations.
[I-D.ietf-httpbis-bcp56bis]. As such, TEEP/HTTP implementations MUST
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
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
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-07 (work in Semantics", draft-ietf-httpbis-semantics-10 (work in
progress), March 2020. progress), July 2020.
[I-D.ietf-teep-protocol] [I-D.ietf-teep-protocol]
Tschofenig, H., Pei, M., Wheeler, D., and D. Thaler, Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A.
"Trusted Execution Environment Provisioning (TEEP) Tsukamoto, "Trusted Execution Environment Provisioning
Protocol", draft-ietf-teep-protocol-01 (work in progress), (TEEP) Protocol", draft-ietf-teep-protocol-03 (work in
March 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-
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>.
[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
Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016, <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", 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-27 (work and Secure Transport", draft-ietf-quic-transport-29 (work
in progress), February 2020. in progress), June 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-07 (work in Architecture", draft-ietf-teep-architecture-12 (work in
progress), March 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-
opentrustprotocol-03 (work in progress), May 2019. opentrustprotocol-03 (work in progress), May 2019.
Author's Address Author's Address
Dave Thaler Dave Thaler
Microsoft Microsoft
 End of changes. 58 change blocks. 
150 lines changed or deleted 179 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/