idnits 2.17.1 draft-ietf-teep-otrp-over-http-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (28 February 2022) is 788 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7525 (ref. 'BCP195') (Obsoleted by RFC 9325) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-semantics' == Outdated reference: A later version (-18) exists of draft-ietf-teep-protocol-07 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-15 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEEP WG D. Thaler 3 Internet-Draft Microsoft 4 Intended status: Standards Track 28 February 2022 5 Expires: 1 September 2022 7 HTTP Transport for Trusted Execution Environment Provisioning: Agent 8 Initiated Communication 9 draft-ietf-teep-otrp-over-http-13 11 Abstract 13 The Trusted Execution Environment Provisioning (TEEP) Protocol is 14 used to manage code and configuration data in a Trusted Execution 15 Environment (TEE). This document specifies the HTTP transport for 16 TEEP communication where a Trusted Application Manager (TAM) service 17 is used to manage code and data in TEEs on devices that can initiate 18 communication to the TAM. An implementation of this document can (if 19 desired) run outside of any TEE, but interacts with a TEEP 20 implementation that runs inside a TEE. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 1 September 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Use of Abstract APIs . . . . . . . . . . . . . . . . . . 4 59 4. Use of HTTP as a Transport . . . . . . . . . . . . . . . . . 5 60 5. TEEP/HTTP Client Behavior . . . . . . . . . . . . . . . . . . 6 61 5.1. Receiving a request to install a new Trusted 62 Application . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.1.1. Session Creation . . . . . . . . . . . . . . . . . . 7 64 5.2. Receiving a notification that a Trusted Application is no 65 longer needed . . . . . . . . . . . . . . . . . . . . . . 7 66 5.3. Getting a TAM URI and message buffer back from a TEEP 67 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.4. Receiving an HTTP response . . . . . . . . . . . . . . . 8 69 5.5. Handling checks for policy changes . . . . . . . . . . . 9 70 5.6. Error handling . . . . . . . . . . . . . . . . . . . . . 9 71 6. TEEP/HTTP Server Behavior . . . . . . . . . . . . . . . . . . 10 72 6.1. Receiving an HTTP POST request . . . . . . . . . . . . . 10 73 6.2. Getting an empty buffer back from the TAM . . . . . . . . 10 74 6.3. Getting a message buffer from the TAM . . . . . . . . . . 10 75 6.4. Error handling . . . . . . . . . . . . . . . . . . . . . 10 76 7. Sample message flow . . . . . . . . . . . . . . . . . . . . . 10 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 81 10.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 A Trusted Execution Environment (TEE) is an environment that enforces 87 that any code within that environment cannot be tampered with, and 88 that any data used by such code cannot be read or tampered with by 89 any code outside that environment. The Trusted Execution Environment 90 Provisioning (TEEP) protocol is designed to provision authorized code 91 and configuration into TEEs. 93 To be secure against malware, a TEEP implementation (referred to as a 94 TEEP "Agent" on the client side, and a "Trusted Application Manager 95 (TAM)" on the server side) SHOULD themselves run inside a TEE, 96 although a TAM running outside a TEE is also supported. However, the 97 transport for TEEP, along with the underlying TCP/IP stack, does not 98 necessarily run inside a TEE. This split allows the set of highly 99 trusted code to be kept as small as possible, including allowing code 100 (e.g., TCP/IP or QUIC [RFC9000]) that only sees encrypted messages, 101 to be kept out of the TEE. 103 The TEEP specification [I-D.ietf-teep-protocol] (like its 104 predecessors [I-D.ietf-teep-opentrustprotocol] and [GP-OTrP]) 105 describes the behavior of TEEP Agents and TAMs, but does not specify 106 the details of the transport. The purpose of this document is to 107 provide such details. That is, a TEEP-over-HTTP (TEEP/HTTP) 108 implementation delivers messages up to a TEEP implementation, and 109 accepts messages from the TEEP implementation to be sent over a 110 network. The TEEP-over-HTTP implementation can be implemented either 111 outside a TEE (i.e., in a TEEP "Broker") or inside a TEE. 113 There are two topological scenarios in which TEEP could be deployed: 115 1. TAMs are reachable on the Internet, and Agents are on networks 116 that might be behind a firewall or stateful NAT, so that 117 communication must be initiated by an Agent. Thus, the Agent has 118 an HTTP Client and the TAM has an HTTP Server. 120 2. Agents are reachable on the Internet, and TAMs are on networks 121 that might be behind a firewall or stateful NAT, so that 122 communication must be initiated by a TAM. Thus, the Agent has an 123 HTTP Server and the TAM has an HTTP Client. 125 The remainder of this document focuses primarily on the first 126 scenario as depicted in Figure 1, but some sections (Section 4 and 127 Section 8) may apply to the second scenario as well. A fuller 128 discussion of the second scenario may be handled by a separate 129 document. 131 +------------------+ TEEP +------------------+ 132 | TEEP Agent | <----------------------> | TAM | 133 +------------------+ +------------------+ 134 | | 135 +------------------+ TEEP-over-HTTP +------------------+ 136 | TEEP/HTTP Client | <----------------------> | TEEP/HTTP Server | 137 +------------------+ +------------------+ 138 | | 139 +------------------+ HTTP +------------------+ 140 | HTTP Client | <----------------------> | HTTP Server | 141 +------------------+ +------------------+ 143 Figure 1: Agent Initiated Communication 145 This document specifies the middle layer (TEEP-over-HTTP), whereas 146 the top layer (TEEP) is specified in [I-D.ietf-teep-protocol]. 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 This document also uses various terms defined in 157 [I-D.ietf-teep-architecture], including Trusted Execution Environment 158 (TEE), Trusted Application (TA), Trusted Application Manager (TAM), 159 TEEP Agent, TEEP Broker, and Rich Execution Environment (REE). 161 3. TEEP Broker 163 Section 6 of the TEEP architecture [I-D.ietf-teep-architecture] 164 defines a TEEP "Broker" as being a component on the device, but 165 outside the TEE, that facilitates communication with a TAM. That 166 document further explains that the protocol layer at which the TEEP 167 broker operates may vary by implementation, and it depicts several 168 exemplary models. An implementation is free to choose any of these 169 models, although model A is the one we will use in our examples. 171 Passing information from an REE component to a TEE component is 172 typically spoken of as being passed "in" to the TEE, and information 173 passed in the opposite direction is spoken of as being passed "out". 174 In the protocol layering sense, information is typically spoken of as 175 being passed "up" or "down" the stack. Since the layer at which 176 information is passed in/out may vary by implementation, we will 177 generally use "up" and "down" in this document. 179 3.1. Use of Abstract APIs 181 This document refers to various APIs between a TEEP implementation 182 and a TEEP/HTTP implementation in the abstract, meaning the literal 183 syntax and programming language are not specified, so that various 184 concrete APIs can be designed (outside of the IETF) that are 185 compliant. 187 Some TEE architectures (e.g., SGX) may support API calls both into 188 and out of a TEE. In other TEE architectures, there may be no calls 189 out from a TEE, but merely data returned from calls into a TEE. This 190 document attempts to be agnostic as to the concrete API architecture 191 for Broker/Agent communication. Since in model A, the Broker/Agent 192 communication is done at the layer between the TEEP and TEEP/HTTP 193 implementations, and there may be some architectures that do not 194 support calls out of the TEE (which would be downcalls from TEEP in 195 model A), we will refer to passing information up to the TEEP 196 implementation as API calls, but will simply refer to "passing data" 197 back down from a TEEP implementation. A concrete API might pass data 198 back via an API downcall or via data returned from an API upcall. 200 This document will also refer to passing "no" data back out of a TEEP 201 implementation. In a concrete API, this might be implemented by not 202 making any downcall, or by returning 0 bytes from an upcall, for 203 example. 205 4. Use of HTTP as a Transport 207 This document uses HTTP [I-D.ietf-httpbis-semantics] as a transport. 208 For the motivation behind the HTTP recommendations in this document, 209 see the discussion of HTTP as a transport in 210 [I-D.ietf-httpbis-bcp56bis]. 212 Redirects MUST NOT be automatically followed. Cookies are not used. 214 Content is not intended to be treated as active by browsers and so 215 HTTP responses with content SHOULD have the following header fields 216 as explained in Section 4.13 of [I-D.ietf-httpbis-bcp56bis] (using 217 the TEEP media type defined in [I-D.ietf-teep-protocol]): 219 Content-Type: application/teep+cbor 220 X-Content-Type-Options: nosniff 221 Content-Security-Policy: default-src 'none' 222 Referrer-Policy: no-referrer 224 Only the POST method is specified for TAM resources exposed over 225 HTTP. A URI of such a resource is referred to as a "TAM URI". A TAM 226 URI can be any HTTP(S) URI. The URI to use is configured in a TEEP 227 Agent via an out-of-band mechanism, as discussed in the next section. 229 It is strongly RECOMMENDED that implementations use HTTPS. Although 230 TEEP is protected end-to-end inside of HTTP, there is still value in 231 using HTTPS for transport, since HTTPS can provide additional 232 protections as discussed in Sections 4.4.2 and 6 of 233 [I-D.ietf-httpbis-bcp56bis]. 235 However, there may be constrained nodes where code space is an issue. 236 [RFC7925] provides TLS profiles that can be used in many constrained 237 nodes, but in rare cases the most constrained nodes might need to use 238 HTTP without a TLS stack, relying on the end-to-end security provided 239 by the TEEP protocol. 241 When HTTPS is used, clients MUST use the procedures detailed in 242 Section 4.3.4 of [I-D.ietf-httpbis-semantics] to verify the 243 authenticity of the server. See [BCP195] for additional TLS 244 recommendations and [RFC7925] for TLS recommendations related to IoT 245 devices. 247 5. TEEP/HTTP Client Behavior 249 5.1. Receiving a request to install a new Trusted Application 251 In some environments, an application installer can determine (e.g., 252 from an application manifest) that the application being installed or 253 updated has a dependency on a given Trusted Application (TA) being 254 available in a given type of TEE. In such a case, it will notify a 255 TEEP Broker, where the notification will contain the following: 257 * A unique identifier of the TA 259 * Optionally, any metadata to provide to the TEEP Agent. This might 260 include a TAM URI provided in the application manifest, for 261 example. 263 * Optionally, any requirements that may affect the choice of TEE, if 264 multiple are available to the TEEP Broker. 266 When a TEEP Broker receives such a notification, it first identifies 267 in an implementation-dependent way which TEE (if any) is most 268 appropriate based on the constraints expressed. If there is only one 269 TEE, the choice is obvious. Otherwise, the choice might be based on 270 factors such as capabilities of available TEE(s) compared with TEE 271 requirements in the notification. Once the TEEP Broker picks a TEE, 272 it passes the notification to the TEEP/HTTP Client for that TEE. 274 The TEEP/HTTP Client then informs the TEEP Agent in that TEE by 275 invoking an appropriate "RequestTA" API that identifies the TA needed 276 and any other associated metadata. The TEEP/HTTP Client need not 277 know whether the TEE already has such a TA installed or whether it is 278 up to date. 280 The TEEP Agent will either (a) pass no data back, (b) pass back a TAM 281 URI to connect to, or (c) pass back a message buffer and TAM URI to 282 send it to. The TAM URI passed back may or may not be the same as 283 the TAM URI, if any, provided by the TEEP/HTTP Client, depending on 284 the TEEP Agent's configuration. If they differ, the TEEP/HTTP Client 285 MUST use the TAM URI passed back. 287 5.1.1. Session Creation 289 If no data is passed back, the TEEP/HTTP Client simply informs its 290 caller (e.g., the application installer) of success. 292 If the TEEP Agent passes back a TAM URI with no message buffer, the 293 TEEP/HTTP Client attempts to create session state, then sends an 294 HTTP(S) POST to the TAM URI with an Accept header field with the TEEP 295 media type specified in [I-D.ietf-teep-protocol], and an empty body. 296 The HTTP request is then associated with the TEEP/HTTP Client's 297 session state. 299 If the TEEP Agent instead passes back a TAM URI with a message 300 buffer, the TEEP/HTTP Client attempts to create session state and 301 handles the message buffer as specified in Section 5.3. 303 Session state consists of: 305 * Any context (e.g., a handle) that identifies the API session with 306 the TEEP Agent. 308 * Any context that identifies an HTTP request, if one is 309 outstanding. Initially, none exists. 311 5.2. Receiving a notification that a Trusted Application is no longer 312 needed 314 In some environments, an application installer can determine (e.g., 315 from an application manifest) that a given Trusted Application is no 316 longer needed, such as if the application that previously depended on 317 the TA is uninstalled or updated in a way that removes the 318 dependency. In such a case, it will notify a TEEP Broker, where the 319 notification will contain the following: 321 * A unique identifier of the TA 323 * Optionally, any metadata to provide to the TEEP Agent. This might 324 include a TAM URI provided in the original application manifest, 325 for example. 327 * Optionally, any requirements that may affect the choice of TEE, if 328 multiple are available to the TEEP Broker. 330 When a TEEP Broker receives such a notification, it first identifies 331 in an implementation-dependent way which TEE (if any) is believed to 332 contain the TA that is no longer needed, similar to the process in 333 Section 5.1. Once the TEEP Broker picks a TEE, it passes the 334 notification to the TEEP/HTTP Client for that TEE. 336 The TEEP/HTTP Client then informs the TEEP Agent in that TEE by 337 invoking an appropriate "UnrequestTA" API that identifies the 338 unneeded TA. The TEEP/HTTP Client need not know whether the TEE 339 actually has the TA installed. 341 The TEEP Agent will either (a) pass no data back, (b) pass back a TAM 342 URI to connect to, or (c) pass back a message buffer and TAM URI to 343 send it to. The TAM URI passed back may or may not be the same as 344 the TAM URI, if any, provided by the TEEP/HTTP Client, depending on 345 the TEEP Agent's configuration. If they differ, the TEEP/HTTP Client 346 MUST use the TAM URI passed back. 348 Processing then continues as in Section 5.1.1. 350 5.3. Getting a TAM URI and message buffer back from a TEEP Agent 352 When a TEEP Agent passes a TAM URI and optionally a message buffer to 353 a TEEP/HTTP Client, the TEEP/HTTP Client MUST do the following, using 354 the TEEP/HTTP Client's session state associated with its API call to 355 the TEEP Agent. 357 The TEEP/HTTP Client sends an HTTP POST request to the TAM URI with 358 Accept and Content-Type header fields with the TEEP media type, and a 359 body containing the TEEP message buffer (if any) provided by the TEEP 360 Agent. The HTTP request is then associated with the TEEP/HTTP 361 Client's session state. 363 5.4. Receiving an HTTP response 365 When an HTTP response is received in response to a request associated 366 with a given session state, the TEEP/HTTP Client MUST do the 367 following. 369 If the HTTP response body is empty, the TEEP/HTTP Client's task is 370 complete, and it can delete its session state, and its task is done. 372 If instead the HTTP response body is not empty, the TEEP/HTTP Client 373 passes (e.g., using the "ProcessTeepMessage" API as mentioned in 374 Section 6.2.1 of [I-D.ietf-teep-architecture]) the response body up 375 to the TEEP Agent associated with the session. The TEEP Agent will 376 then either pass no data back, or pass back a message buffer. 378 If no data is passed back, the TEEP/HTTP Client's task is complete, 379 and it can delete its session state, and inform its caller (e.g., the 380 application installer) of success. 382 If instead the TEEP Agent passes back a message buffer, the TEEP/HTTP 383 Client handles the message buffer as specified in Section 5.3. 385 5.5. Handling checks for policy changes 387 An implementation MUST provide a way to periodically check for TAM 388 policy changes, such as a Trusted Application needing to be deleted 389 from a TEE because it is no longer permitted, or needing to be 390 updated to a later version. This can be done in any implementation- 391 specific manner, such as any of the following or a combination 392 thereof: 394 A) The TEEP/HTTP Client might call up to the TEEP Agent at an 395 interval previously specified by the TEEP Agent. This approach 396 requires that the TEEP/HTTP Client be capable of running a periodic 397 timer. 399 B) The TEEP/HTTP Client might be informed when an existing TA is 400 invoked, and call up to the TEEP Agent if more time has passed than 401 was previously specified by the TEEP Agent. This approach allows the 402 device to go to sleep for a potentially long period of time. 404 C) The TEEP/HTTP Client might be informed when any attestation 405 attempt determines that the device is out of compliance, and call up 406 to the TEEP Agent to remediate. 408 The TEEP/HTTP Client informs the TEEP Agent by invoking an 409 appropriate "RequestPolicyCheck" API. The TEEP Agent will either (a) 410 pass no data back, (b) pass back a TAM URI to connect to, or (c) pass 411 back a message buffer and TAM URI to send it to. Processing then 412 continues as specified in Section 5.1.1. 414 The TEEP Agent might need to talk to multiple TAMs, however, as shown 415 in Figure 1 of [I-D.ietf-teep-architecture]. To accomplish this, the 416 TEEP/HTTP Client keeps invoking the "RequestPolicyCheck" API until 417 the TEEP Agent passes no data back, so that the TEEP Agent can return 418 each TAM URI in response to a separate API call. 420 5.6. Error handling 422 If any local error occurs where the TEEP/HTTP Client cannot get a 423 message buffer (empty or not) back from the TEEP Agent, the TEEP/HTTP 424 Client deletes its session state, and informs its caller (if any, 425 e.g., the application installer) of a failure. 427 If any HTTP request results in an HTTP error response or a lower 428 layer error (e.g., network unreachable), the TEEP/HTTP Client calls 429 the TEEP Agent's "ProcessError" API, and then deletes its session 430 state and informs its caller of a failure. 432 6. TEEP/HTTP Server Behavior 434 6.1. Receiving an HTTP POST request 436 If the TAM does not receive the appropriate Content-Type header field 437 value, the TAM SHOULD fail the request, returning a 415 Unsupported 438 Media Type response. Similarly, if an appropriate Accept header 439 field is not present, the TAM SHOULD fail the request with an 440 appropriate error response. (This is for consistency with common 441 implementation practice to allow the HTTP server to choose a default 442 error response, since in some implementations the choice is done at 443 the HTTP layer rather than the layer at which TEEP-over-HTTP would be 444 implemented.) Otherwise, processing continues as follows. 446 When an HTTP POST request is received with an empty body, this 447 indicates a request for a new TEEP session, and the TEEP/HTTP Server 448 invokes the TAM's "ProcessConnect" API. The TAM will then pass back 449 a message buffer. 451 When an HTTP POST request is received with a non-empty body, this 452 indicates a message on an existing TEEP session, and the TEEP/HTTP 453 Server passes the request body to the TAM (e.g., using the 454 "ProcessTeepMessage" API mentioned in [I-D.ietf-teep-architecture]). 455 The TAM will then pass back a (possibly empty) message buffer. 457 6.2. Getting an empty buffer back from the TAM 459 If the TAM passes back an empty buffer, the TEEP/HTTP Server sends a 460 successful (2xx) response with no body. It SHOULD be status 204 (No 461 Content). 463 6.3. Getting a message buffer from the TAM 465 If the TAM passes back a non-empty buffer, the TEEP/HTTP Server 466 generates a successful (2xx) response with a Content-Type header 467 field with the TEEP media type, and with the message buffer as the 468 body. 470 6.4. Error handling 472 If any error occurs where the TEEP/HTTP Server cannot get a message 473 buffer (empty or not) back from the TAM, the TEEP/HTTP Server 474 generates an appropriate HTTP 5xx error response. 476 7. Sample message flow 478 The following shows a sample TEEP message flow that uses application/ 479 teep+cbor as the Content-Type. 481 1. An application installer determines (e.g., from an application 482 manifest) that the application has a dependency on TA "X", and 483 passes this notification to the TEEP Broker. The TEEP Broker 484 picks a TEE (e.g., the only one available) based on this 485 notification, and passes the information to the TEEP/HTTP Cient 486 for that TEE. 488 2. The TEEP/HTTP Client calls the TEEP Agent's "RequestTA" API, 489 passing TA Needed = X. 491 3. The TEEP Agent finds that no such TA is already installed, but 492 that it can be obtained from a given TAM. The TEEP Agent passes 493 back the TAM URI (e.g., "https://example.com/tam") to the TEEP/ 494 HTTP Client. 496 4. The TEEP/HTTP Client sends an HTTP POST request to the TAM URI: 498 POST /tam HTTP/1.1 499 Host: example.com 500 Accept: application/teep+cbor 501 Content-Length: 0 502 User-Agent: Foo/1.0 504 where the TEEP/HTTP Client fills in an implementation-specific 505 value in the User-Agent header field. 507 5. On the TAM side, the TEEP/HTTP Server receives the HTTP POST 508 request, and calls the TAM's "ProcessConnect" API. 510 6. The TAM generates a TEEP message (where typically QueryRequest 511 is the first message) and passes it to the TEEP/HTTP Server. 513 7. The TEEP/HTTP Server sends an HTTP successful response with the 514 TEEP message in the body: 516 HTTP/1.1 200 OK 517 Content-Type: application/teep+cbor 518 Content-Length: [length of TEEP message here] 519 Server: Bar/2.2 520 X-Content-Type-Options: nosniff 521 Content-Security-Policy: default-src 'none' 522 Referrer-Policy: no-referrer 524 [TEEP message here] 526 where the TEEP/HTTP Server fills in an implementation-specific 527 value in the Server header field. 529 8. Back on the TEEP Agent side, the TEEP/HTTP Client gets the HTTP 530 response, extracts the TEEP message and pass it up to the TEEP 531 Agent. 533 9. The TEEP Agent processes the TEEP message, and generates a TEEP 534 response (e.g., QueryResponse) which it passes back to the TEEP/ 535 HTTP Client. 537 10. The TEEP/HTTP Client gets the TEEP message buffer and sends an 538 HTTP POST request to the TAM URI, with the TEEP message in the 539 body: 541 POST /tam HTTP/1.1 542 Host: example.com 543 Accept: application/teep+cbor 544 Content-Type: application/teep+cbor 545 Content-Length: [length of TEEP message here] 546 User-Agent: Foo/1.0 548 [TEEP message here] 550 11. The TEEP/HTTP Server receives the HTTP POST request, and passes 551 the payload up to the TAM. 553 12. Steps 6-11 are then repeated until the TAM passes no data back 554 to the TEEP/HTTP Server in step 6. 556 13. The TEEP/HTTP Server sends an HTTP successful response with no 557 body: 559 HTTP/1.1 204 No Content 560 Server: Bar/2.2 562 14. The TEEP/HTTP Client deletes its session state. 564 8. Security Considerations 566 Section 4 discussed security recommendations for HTTPS transport of 567 TEEP messages. See Section 6 of [I-D.ietf-httpbis-bcp56bis] for 568 additional discussion of HTTP(S) security considerations. See 569 section 9 of [I-D.ietf-teep-architecture] for security considerations 570 specific to the use of TEEP. 572 9. IANA Considerations 574 This document has no actions for IANA. 576 10. References 577 10.1. Normative References 579 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 580 "Recommendations for Secure Use of Transport Layer 581 Security (TLS) and Datagram Transport Layer Security 582 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 583 2015, . 585 [I-D.ietf-httpbis-semantics] 586 Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 587 Semantics", Work in Progress, Internet-Draft, draft-ietf- 588 httpbis-semantics-19, 12 September 2021, 589 . 592 [I-D.ietf-teep-protocol] 593 Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A. 594 Tsukamoto, "Trusted Execution Environment Provisioning 595 (TEEP) Protocol", Work in Progress, Internet-Draft, draft- 596 ietf-teep-protocol-07, 25 October 2021, 597 . 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, 602 DOI 10.17487/RFC2119, March 1997, 603 . 605 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 606 Security (TLS) / Datagram Transport Layer Security (DTLS) 607 Profiles for the Internet of Things", RFC 7925, 608 DOI 10.17487/RFC7925, July 2016, 609 . 611 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 612 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 613 May 2017, . 615 10.2. Informative References 617 [GP-OTrP] Global Platform, "TEE Management Framework: Open Trust 618 Protocol (OTrP) Profile Version 1.0", Global 619 Platform GPD_SPE_123, May 2019, 620 . 623 [I-D.ietf-httpbis-bcp56bis] 624 Nottingham, M., "Building Protocols with HTTP", Work in 625 Progress, Internet-Draft, draft-ietf-httpbis-bcp56bis-15, 626 27 August 2021, . 629 [I-D.ietf-teep-architecture] 630 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 631 "Trusted Execution Environment Provisioning (TEEP) 632 Architecture", Work in Progress, Internet-Draft, draft- 633 ietf-teep-architecture-15, 12 July 2021, 634 . 637 [I-D.ietf-teep-opentrustprotocol] 638 Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig, 639 "The Open Trust Protocol (OTrP)", Work in Progress, 640 Internet-Draft, draft-ietf-teep-opentrustprotocol-03, 15 641 May 2019, . 644 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 645 Multiplexed and Secure Transport", RFC 9000, 646 DOI 10.17487/RFC9000, May 2021, 647 . 649 Author's Address 651 Dave Thaler 652 Microsoft 654 Email: dthaler@microsoft.com