draft-ietf-teep-otrp-over-http-03.txt   draft-ietf-teep-otrp-over-http-04.txt 
TEEP WG D. Thaler TEEP WG D. Thaler
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Informational November 04, 2019 Intended status: Informational February 10, 2020
Expires: May 7, 2020 Expires: August 13, 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-03 draft-ietf-teep-otrp-over-http-04
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 May 7, 2020. This Internet-Draft will expire on August 13, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 31 skipping to change at page 2, line 31
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 . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
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) that only sees encrypted messages, to be
kept out of the TEE. kept out of the TEE.
The TEEP specification [I-D.tschofenig-teep-protocol] (and 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:
skipping to change at page 8, line 42 skipping to change at page 8, line 42
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 "ProcessOTrPMessage" API as mentioned in passes (e.g., using "ProcessTeepMessage" API as mentioned in
Section 6.2 of [I-D.ietf-teep-opentrustprotocol] if OTrP rather than Section 6.2.1 of [I-D.ietf-teep-architecture]) the response body up
TEEP is used for provisioning) the response body up to the TEEP to the TEEP implementation associated with the session. The TEEP
implementation associated with the session. The TEEP implementation implementation will then either pass no data back, or pass back a
will 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 implementation passes back a message buffer, the
TEEP/HTTP Client handles the message buffer as specified in TEEP/HTTP 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
skipping to change at page 10, line 12 skipping to change at page 10, line 12
6. TEEP/HTTP Server Behavior 6. TEEP/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 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
"ProcessOTrPMessage" API mentioned in "ProcessTeepMessage" API mentioned in [I-D.ietf-teep-architecture]).
[I-D.ietf-teep-opentrustprotocol] if OTrP rather than TEEP is used The TAM will then pass back a (possibly empty) message buffer.
for provisioning). 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 TEEP implementation
If the TEEP implementation passes back an empty buffer, the TEEP/HTTP If the TEEP implementation passes back an empty buffer, the TEEP/HTTP
Server sends a successful (2xx) response with no body. Server sends a successful (2xx) response with no body.
6.3. Getting a message buffer from the TEEP implementation 6.3. Getting a message buffer from the TEEP implementation
If the TEEP implementation passes back a non-empty buffer, the TEEP/ If the TEEP implementation passes back a non-empty buffer, the TEEP/
HTTP Server generates a successful (2xx) response with a Content-Type HTTP Server generates a successful (2xx) response with a Content-Type
skipping to change at page 13, line 11 skipping to change at page 12, line 48
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
[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-06 (work in
progress), July 2019. progress), November 2019.
[I-D.ietf-teep-opentrustprotocol]
Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig,
"The Open Trust Protocol (OTrP)", draft-ietf-teep-
opentrustprotocol-03 (work in progress), May 2019.
[I-D.tschofenig-teep-protocol] [I-D.ietf-teep-protocol]
Pei, M., Tschofenig, H., and D. Wheeler, "Trusted Tschofenig, H., Pei, M., Wheeler, D., and D. Thaler,
Execution Environment Provisioning (TEEP) Protocol", "Trusted Execution Environment Provisioning (TEEP)
draft-tschofenig-teep-protocol-00 (work in progress), Protocol", draft-ietf-teep-protocol-00 (work in progress),
November 2019. December 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>.
skipping to change at page 14, line 6 skipping to change at page 13, line 38
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-teep-architecture] [I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
Liu, "Trusted Execution Environment Provisioning (TEEP) "Trusted Execution Environment Provisioning (TEEP)
Architecture", draft-ietf-teep-architecture-03 (work in Architecture", draft-ietf-teep-architecture-06 (work in
progress), July 2019. progress), February 2020.
Author's Address [I-D.ietf-teep-opentrustprotocol]
Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig,
"The Open Trust Protocol (OTrP)", draft-ietf-teep-
opentrustprotocol-03 (work in progress), May 2019.
Author's Address
Dave Thaler Dave Thaler
Microsoft Microsoft
EMail: dthaler@microsoft.com EMail: dthaler@microsoft.com
 End of changes. 14 change blocks. 
35 lines changed or deleted 32 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/