HTTP Transport for Trusted Execution Environment Provisioning: Agent Initiated Communication

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 28 September 2023.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

A Trusted Execution Environment (TEE) is an environment that enforces that any code within that environment cannot be tampered with, and that any data used by such code cannot be read or tampered with by any code outside that environment. The Trusted Execution Environment Provisioning (TEEP) protocol is designed to provision authorized code and configuration into TEEs.¶

To be secure against malware, a TEEP implementation (referred to as a TEEP "Agent" on the client side is expected to run inside a TEE, and a "Trusted Application Manager (TAM)" on the server side) might or might not run inside a TEE. However, the transport for TEEP, along with the underlying TCP/IP 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 allowing code (e.g., TCP/IP or QUIC [RFC9000]) that only sees encrypted messages, to be kept out of the TEE. See section 6.2 of [I-D.ietf-teep-architecture] for a depiction of various implementation models.¶

The TEEP specification [I-D.ietf-teep-protocol] describes the behavior of TEEP Agents and TAMs, but does not specify the details of the transport. The purpose of this document is to provide such details. That is, a TEEP-over-HTTP (TEEP/HTTP) implementation delivers messages up to a TEEP implementation, and accepts messages from the TEEP implementation to be sent over a network. The TEEP-over-HTTP implementation can be implemented either outside a TEE (i.e., in a TEEP "Broker") or inside a TEE.¶

There are two topological scenarios (among others) in which TEEP could be deployed:¶

1. TAMs are reachable on the Internet, and Agents are on networks that might be behind a firewall or stateful NAT, 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 or stateful NAT, 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 more complete discussion of the second scenario may be handled by a separate document.¶

    +------------------+           TEEP           +------------------+
    |    TEEP Agent    | <----------------------> |        TAM       |
    +------------------+                          +------------------+
             |                                              |
    +------------------+      TEEP-over-HTTP      +------------------+
    | TEEP/HTTP Client | <----------------------> | TEEP/HTTP Server |
    +------------------+                          +------------------+
             |                                              |
    +------------------+           HTTP           +------------------+
    |    HTTP Client   | <----------------------> |    HTTP Server   |
    +------------------+                          +------------------+

This document specifies the middle layer (TEEP-over-HTTP), whereas the top layer (TEEP) is specified in [I-D.ietf-teep-protocol] and the bottom layer (HTTP) is specified in [RFC9110].¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document also uses various terms defined in [I-D.ietf-teep-architecture], including Trusted Execution Environment (TEE), Trusted Application (TA), Trusted Application Manager (TAM), TEEP Agent, TEEP Broker, and Rich Execution Environment (REE).¶

3. TEEP Broker

Section 6 of the TEEP architecture [I-D.ietf-teep-architecture] defines a TEEP "Broker" as being a component on the device, but outside the TEE, that facilitates communication with a TAM. That document further explains that the protocol layer at which the TEEP broker operates may vary by implementation, and it depicts several exemplary models. 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 information 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.¶

4. Use of HTTP as a Transport

This document uses HTTP [RFC9110] as a transport. For the motivation behind the HTTP recommendations in this document, see the discussion of HTTP as a transport in [RFC9205].¶

Redirects MUST NOT be automatically followed. Cookies are not used.¶

Content is not intended to be treated as active by browsers and so HTTP responses with content MUST have the following header fields as explained in Section 4.13 of [RFC9205] (using the TEEP media type defined in [I-D.ietf-teep-protocol]):¶

    Content-Type: application/teep+cbor
    X-Content-Type-Options: nosniff
    Content-Security-Policy: default-src 'none'
    Referrer-Policy: no-referrer

Only the POST method is specified for TAM resources exposed over HTTP. Since POST responses without explicit freshness information are uncacheable (see Section 9.3.3 of [RFC9110]), the Cache-Control header MUST NOT be used.¶

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 Agent via an out-of-band mechanism, as discussed in the next section.¶

It is 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 Section 6 of [RFC9205].¶

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. See Sections 4.4.2 and 6 of [RFC9205] for more discussion of additional security considerations that apply in this case.¶

When HTTPS is used, clients MUST use the procedures detailed in Section 4.3.4 of [RFC9110] to verify the authenticity of the server. See [BCP195] for additional TLS recommendations and [RFC7925] for TLS recommendations related to IoT devices.¶

5. TEEP/HTTP Client Behavior

6. TEEP/HTTP Server Behavior

7. Sample message flow

The following shows a sample TEEP message flow that uses application/teep+cbor as the Content-Type.¶

1. An application installer determines (e.g., from an application manifest) that the application has a dependency on TA "X", and passes this notification to the TEEP Broker. The TEEP Broker picks a TEE (e.g., the only one available) based on this notification, and passes the information to the TEEP/HTTP Client for that TEE.¶
2. The TEEP/HTTP Client calls the TEEP Agent's "RequestTA" API, passing TA Needed = X.¶
3. The TEEP Agent finds that no such TA is already installed, but that it can be obtained from a given TAM. The TEEP Agent passes back the TAM URI (e.g., "https://example.com/tam") to the TEEP/HTTP Client.¶

4. The TEEP/HTTP Client sends an HTTP POST request to the TAM URI:¶

           POST /tam HTTP/1.1
           Host: example.com
           Accept: application/teep+cbor
           Content-Length: 0
           User-Agent: Foo/1.0
   

   ¶

   where the TEEP/HTTP Client fills in an implementation-specific value in the User-Agent header field.¶

5. On the TAM side, the TEEP/HTTP Server receives the HTTP POST request, and calls the TAM's "ProcessConnect" API.¶
6. The TAM generates a TEEP message (where typically QueryRequest is the first message) and passes it to the TEEP/HTTP Server.¶

7. The TEEP/HTTP Server sends an HTTP successful response with the TEEP message in the body:¶

           HTTP/1.1 200 OK
           Content-Type: application/teep+cbor
           Content-Length: [length of TEEP message here]
           Server: Bar/2.2
           X-Content-Type-Options: nosniff
           Content-Security-Policy: default-src 'none'
           Referrer-Policy: no-referrer
   
           [TEEP message here]
   

   ¶

   where the TEEP/HTTP Server fills in an implementation-specific value in the Server header field.¶

8. Back on the TEEP Agent side, the TEEP/HTTP Client gets the HTTP response, extracts the TEEP message and passes it up to the TEEP Agent.¶
9. The TEEP Agent processes the TEEP message, and generates a TEEP response (e.g., QueryResponse) which it passes back to the TEEP/HTTP Client.¶

10. The TEEP/HTTP Client gets the TEEP message and sends an HTTP POST request to the TAM URI, with the TEEP message in the body:¶

           POST /tam HTTP/1.1
           Host: example.com
           Accept: application/teep+cbor
           Content-Type: application/teep+cbor
           Content-Length: [length of TEEP message here]
           User-Agent: Foo/1.0
    
           [TEEP message here]
    

    ¶
11. The TEEP/HTTP Server receives the HTTP POST request, and passes the payload up to the TAM.¶
12. Steps 6-11 are then repeated until the TAM passes no data back to the TEEP/HTTP Server in step 6.¶

13. The TEEP/HTTP Server sends an HTTP successful response with no body:¶

           HTTP/1.1 204 No Content
           Server: Bar/2.2
    

    ¶
14. The TEEP/HTTP Client deletes its session state.¶

8. Security Considerations

Section 4 discussed security recommendations for HTTPS transport of TEEP messages. See Section 6 of [RFC9205] for additional discussion of HTTP(S) security considerations. See section 9 of [I-D.ietf-teep-architecture] for security considerations specific to the use of TEEP. See Section 7 of [RFC3986] for security considerations on dereferencing URIs.¶

9. IANA Considerations

This document has no actions for IANA.¶

Author's Address