draft-ietf-teep-otrp-over-http-05.txt   draft-ietf-teep-otrp-over-http-06.txt 
TEEP WG D. Thaler TEEP WG D. Thaler
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Informational March 31, 2020 Intended status: Informational April 02, 2020
Expires: October 2, 2020 Expires: October 4, 2020
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-05 draft-ietf-teep-otrp-over-http-06
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 TEEs in devices that can initiate communication to
the TAM. An implementation of this document can (if desired) run the TAM. An implementation of this document can (if desired) run
outside of any TEE, but interacts with a TEEP implementation that outside of any TEE, but interacts with a TEEP implementation that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 2, 2020. This Internet-Draft will expire on October 4, 2020.
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 30 skipping to change at page 2, line 30
5.3. Receiving an HTTP response . . . . . . . . . . . . . . . 8 5.3. Receiving an HTTP response . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . 9
6. TEEP/HTTP Server Behavior . . . . . . . . . . . . . . . . . . 9 6. TEEP/HTTP Server Behavior . . . . . . . . . . . . . . . . . . 9
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 TEEP implementation 10
6.3. Getting a message buffer from the TEEP implementation . . 10 6.3. Getting a message buffer from the TEEP implementation . . 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 . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Trusted Execution Environments (TEEs), including environments based Trusted Execution Environments (TEEs), including environments based
on Intel SGX, ARM TrustZone, Secure Elements, and others, enforce on Intel SGX, ARM TrustZone, Secure Elements, and others, enforce
that only authorized code can execute within the TEE, and any memory that only authorized code can execute within the TEE, and any memory
used by such code is protected against tampering or disclosure used by such code is protected against tampering or disclosure
outside the TEE. The Trusted Execution Environment Provisioning outside the TEE. The Trusted Execution Environment Provisioning
(TEEP) protocol is designed to provision authorized code and (TEEP) protocol is designed to provision authorized code 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) must themselves run inside a TEE.
However, the transport for TEEP, along with the underlying TCP/IP However, the transport for TEEP, along with the underlying TCP/IP
stack, does not necessarily run inside a TEE. This split allows the stack, does not necessarily run inside a TEE. This split allows the
set of 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 or QUIC [I-D.ietf-quic-transport]) that
kept out of the TEE. 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.
There are two topological scenarios in which TEEP could be deployed: There are two topological scenarios in which TEEP could be deployed:
1. TAMs are reachable on the Internet, and Agents are on networks 1. TAMs are reachable on the Internet, and Agents are on networks
that might be behind a firewall, so that communication must be that might be behind a firewall or stateful NAT, so that
initiated by an Agent. Thus, the Agent has an HTTP Client and communication must be initiated by an Agent. Thus, the Agent has
the TAM has an HTTP Server. an HTTP Client and the TAM has an HTTP Server.
2. Agents are reachable on the Internet, and TAMs are on networks 2. Agents are reachable on the Internet, and TAMs are on networks
that might be behind a firewall, so that communication must be that might be behind a firewall or stateful NAT, so that
initiated by a TAM. Thus, the Agent has an HTTP Server and the communication must be initiated by a TAM. Thus, the Agent has an
TAM has an HTTP Client. HTTP Server and the TAM has an HTTP Client.
The remainder of this document focuses primarily on the first The remainder of this document focuses primarily on the first
scenario as depicted in Figure 1, but some sections (Section 4 and scenario as depicted in Figure 1, but some sections (Section 4 and
Section 8) may apply to the second scenario as well. A fuller Section 8) may apply to the second scenario as well. A fuller
discussion of the second scenario may be handled by a separate discussion of the second scenario may be handled by a separate
document. document.
+------------------+ TEEP +------------------+ +------------------+ TEEP +------------------+
| TEEP Agent | <----------------------> | TAM | | TEEP Agent | <----------------------> | TAM |
+------------------+ +------------------+ +------------------+ +------------------+
skipping to change at page 6, line 52 skipping to change at page 6, line 52
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.
When HTTPS is used, TLS certificates MUST be checked according to When HTTPS is used, TLS certificates MUST be checked according to
[RFC2818]. [RFC2818]. See [BCP195] for additional TLS recommendations.
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:
skipping to change at page 11, line 4 skipping to change at page 10, line 51
(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 implementation's "RequestTA"
API, passing TA Needed = X. API, passing TA Needed = X.
3. The TEEP implementation finds that no such TA is already 3. The TEEP implementation finds that no such TA is already
installed, but that it can be obtained from a given TAM. The installed, but that it can be obtained from a given TAM. The
TEEP Agent passes the TAM URI (e.g., "https://example.com/tam") TEEP Agent passes the TAM URI (e.g., "https://example.com/tam")
to the TEEP/HTTP Client. (If the TEEP implementation already to the TEEP/HTTP Client. (If the TEEP implementation already
had a cached TAM certificate that it trusts, it could skip to had cached TAM OCSP_DATA that it trusts based on a previous
step 9 instead and generate a QueryResponse.) 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
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 TEEP implementation's "ProcessConnect"
API. API.
6. The TEEP implementation generates a TEEP message (where 6. The TEEP implementation generates a TEEP message (where
typically QueryRequest is the first message) and passes it to typically QueryRequest 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:
skipping to change at page 11, line 37 skipping to change at page 11, line 40
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
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. implementation.
9. The TEEP implementation processes the TEEP message, and 9. The TEEP implementation processes the TEEP message, and
generates a TEEP response (e.g., QueryResponse) which it passes generates a TEEP response (e.g., QueryResponse) which it passes
back to the TEEP/HTTP Client. back to the TEEP/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
skipping to change at page 12, line 46 skipping to change at page 13, line 13
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
10.1. Normative References 10.1. Normative References
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
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-07 (work in
progress), March 2020. progress), March 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., and D. Thaler,
"Trusted Execution Environment Provisioning (TEEP) "Trusted Execution Environment Provisioning (TEEP)
Protocol", draft-ietf-teep-protocol-01 (work in progress), Protocol", draft-ietf-teep-protocol-01 (work in progress),
March 2020. March 2020.
skipping to change at page 13, line 37 skipping to change at page 14, line 10
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]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-27 (work
in progress), February 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-07 (work in
progress), March 2020. progress), March 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.
 End of changes. 14 change blocks. 
19 lines changed or deleted 37 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/