idnits 2.17.1 draft-ietf-teep-otrp-over-http-10.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 (February 22, 2021) is 1158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7525 (ref. 'BCP195') (Obsoleted by RFC 9325) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-14 == Outdated reference: A later version (-18) exists of draft-ietf-teep-protocol-04 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-bcp56bis-09 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-13 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: Informational February 22, 2021 5 Expires: August 26, 2021 7 HTTP Transport for Trusted Execution Environment Provisioning: Agent-to- 8 TAM Communication 9 draft-ietf-teep-otrp-over-http-10 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 http://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 August 26, 2021. 39 Copyright Notice 41 Copyright (c) 2021 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 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. TEEP Broker . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Use of Abstract APIs . . . . . . . . . . . . . . . . . . 4 60 4. Use of HTTP as a Transport . . . . . . . . . . . . . . . . . 5 61 5. TEEP/HTTP Client Behavior . . . . . . . . . . . . . . . . . . 6 62 5.1. Receiving a request to install a new Trusted 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 message buffer back from a TEEP Agent . . . . . 8 67 5.4. Receiving an HTTP response . . . . . . . . . . . . . . . 8 68 5.5. Handling checks for policy changes . . . . . . . . . . . 9 69 5.6. Error handling . . . . . . . . . . . . . . . . . . . . . 9 70 6. TEEP/HTTP Server Behavior . . . . . . . . . . . . . . . . . . 10 71 6.1. Receiving an HTTP POST request . . . . . . . . . . . . . 10 72 6.2. Getting an empty buffer back from the TAM . . . . . . . . 10 73 6.3. Getting a message buffer from the TAM . . . . . . . . . . 10 74 6.4. Error handling . . . . . . . . . . . . . . . . . . . . . 10 75 7. Sample message flow . . . . . . . . . . . . . . . . . . . . . 10 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 80 10.2. Informative References . . . . . . . . . . . . . . . . . 14 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 A Trusted Execution Environment (TEE) is an environment that enforces 86 that any code within that environment cannot be tampered with, and 87 that any data used by such code cannot be read or tampered with by 88 any code outside that environment. The Trusted Execution Environment 89 Provisioning (TEEP) protocol is designed to provision authorized code 90 and configuration into TEEs. 92 To be secure against malware, a TEEP implementation (referred to as a 93 TEEP "Agent" on the client side, and a "Trusted Application Manager 94 (TAM)" on the server side) SHOULD themselves run inside a TEE, 95 although a TAM running outside a TEE is also supported. However, the 96 transport for TEEP, along with the underlying TCP/IP stack, does not 97 necessarily run inside a TEE. This split allows the set of highly 98 trusted code to be kept as small as possible, including allowing code 99 (e.g., TCP/IP or QUIC [I-D.ietf-quic-transport]) that only sees 100 encrypted messages, to be kept out of the TEE. 102 The TEEP specification [I-D.ietf-teep-protocol] (like its 103 predecessors [I-D.ietf-teep-opentrustprotocol] and [GP-OTrP]) 104 describes the behavior of TEEP Agents and TAMs, but does not specify 105 the details of the transport. The purpose of this document is to 106 provide such details. That is, a TEEP-over-HTTP (TEEP/HTTP) 107 implementation delivers messages up to a TEEP implementation, and 108 accepts messages from the TEEP implementation to be sent over a 109 network. The TEEP-over-HTTP implementation can be implemented either 110 outside a TEE (i.e., in a TEEP "Broker") or inside a TEE. 112 There are two topological scenarios in which TEEP could be deployed: 114 1. TAMs are reachable on the Internet, and Agents are on networks 115 that might be behind a firewall or stateful NAT, so that 116 communication must be initiated by an Agent. Thus, the Agent has 117 an HTTP Client and the TAM has an HTTP Server. 119 2. Agents are reachable on the Internet, and TAMs are on networks 120 that might be behind a firewall or stateful NAT, so that 121 communication must be initiated by a TAM. Thus, the Agent has an 122 HTTP Server and the TAM has an HTTP Client. 124 The remainder of this document focuses primarily on the first 125 scenario as depicted in Figure 1, but some sections (Section 4 and 126 Section 8) may apply to the second scenario as well. A fuller 127 discussion of the second scenario may be handled by a separate 128 document. 130 +------------------+ TEEP +------------------+ 131 | TEEP Agent | <----------------------> | TAM | 132 +------------------+ +------------------+ 133 | | 134 +------------------+ TEEP-over-HTTP +------------------+ 135 | TEEP/HTTP Client | <----------------------> | TEEP/HTTP Server | 136 +------------------+ +------------------+ 137 | | 138 +------------------+ HTTP +------------------+ 139 | HTTP Client | <----------------------> | HTTP Server | 140 +------------------+ +------------------+ 142 Figure 1: Agent-to-TAM Communication 144 This document specifies the middle layer (TEEP-over-HTTP), whereas 145 the top layer (TEEP) is specified in [I-D.ietf-teep-protocol]. 147 2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 This document also uses various terms defined in 156 [I-D.ietf-teep-architecture], including Trusted Execution Environment 157 (TEE), Trusted Application (TA), Trusted Application Manager (TAM), 158 TEEP Agent, TEEP Broker, and Rich Execution Environment (REE). 160 3. TEEP Broker 162 Section 6 of the TEEP architecture [I-D.ietf-teep-architecture] 163 defines a TEEP "Broker" as being a component on the device, but 164 outside the TEE, that facilitates communication with a TAM. That 165 document further explains that the protocol layer at which the TEEP 166 broker operates may vary by implementation, and it depicts several 167 exemplary models. An implementation is free to choose any of these 168 models, although model A is the one we will use in our examples. 170 Passing information from an REE component to a TEE component is 171 typically spoken of as being passed "in" to the TEE, and information 172 passed in the opposite direction is spoken of as being passed "out". 173 In the protocol layering sense, information is typically spoken of as 174 being passed "up" or "down" the stack. Since the layer at which 175 information is passed in/out may vary by implementation, we will 176 generally use "up" and "down" in this document. 178 3.1. Use of Abstract APIs 180 This document refers to various APIs between a TEEP implementation 181 and a TEEP/HTTP implementation in the abstract, meaning the literal 182 syntax and programming language are not specified, so that various 183 concrete APIs can be designed (outside of the IETF) that are 184 compliant. 186 Some TEE architectures (e.g., SGX) may support API calls both into 187 and out of a TEE. In other TEE architectures, there may be no calls 188 out from a TEE, but merely data returned from calls into a TEE. This 189 document attempts to be agnostic as to the concrete API architecture 190 for Broker/Agent communication. Since in model A, the Broker/Agent 191 communication is done at the layer between the TEEP and TEEP/HTTP 192 implementations, and there may be some architectures that do not 193 support calls out of the TEE (which would be downcalls from TEEP in 194 model A), we will refer to passing information up to the TEEP 195 implementation as API calls, but will simply refer to "passing data" 196 back down from a TEEP implementation. A concrete API might pass data 197 back via an API downcall or via data returned from an API upcall. 199 This document will also refer to passing "no" data back out of a TEEP 200 implementation. In a concrete API, this might be implemented by not 201 making any downcall, or by returning 0 bytes from an upcall, for 202 example. 204 4. Use of HTTP as a Transport 206 This document uses HTTP [I-D.ietf-httpbis-semantics] as a transport. 207 For the motivation behind the HTTP recommendations in this document, 208 see the discussion of HTTP as a transport in 209 [I-D.ietf-httpbis-bcp56bis]. 211 Redirects MUST NOT be automatically followed. Cookies are not used. 213 Content is not intended to be treated as active by browsers and so 214 HTTP responses with content SHOULD have the following headers as 215 explained in Section 4.12 of [I-D.ietf-httpbis-bcp56bis] (using the 216 relevant TEEP content type defined in [I-D.ietf-teep-protocol]): 218 Content-Type: application/teep+cbor 219 X-Content-Type-Options: nosniff 220 Content-Security-Policy: default-src 'none' 221 Referrer-Policy: no-referrer 223 Only the POST method is specified for TAM resources exposed over 224 HTTP. A URI of such a resource is referred to as a "TAM URI". A TAM 225 URI can be any HTTP(S) URI. The URI to use is configured in a TEEP 226 Agent via an out-of-band mechanism, as discussed in the next section. 228 It is strongly RECOMMENDED that implementations use HTTPS. Although 229 TEEP is protected end-to-end inside of HTTP, there is still value in 230 using HTTPS for transport, since HTTPS can provide additional 231 protections as discussed in Sections 4.4.2 and 6 of 232 [I-D.ietf-httpbis-bcp56bis]. 234 However, there may be constrained nodes where code space is an issue. 235 [RFC7925] provides TLS profiles that can be used in many constrained 236 nodes, but in rare cases the most constrained nodes might need to use 237 HTTP without a TLS stack, relying on the end-to-end security provided 238 by the TEEP protocol. 240 When HTTPS is used, clients MUST use the procedures detailed in 241 Section 6 of [RFC6125] to verify the authenticity of the server. See 242 [BCP195] for additional TLS recommendations and [RFC7925] for TLS 243 recommendations related to IoT devices. 245 5. TEEP/HTTP Client Behavior 247 5.1. Receiving a request to install a new Trusted Application 249 In some environments, an application installer can determine (e.g., 250 from an application manifest) that the application being installed or 251 updated has a dependency on a given Trusted Application (TA) being 252 available in a given type of TEE. In such a case, it will notify a 253 TEEP Broker, where the notification will contain the following: 255 - A unique identifier of the TA 257 - Optionally, any metadata to provide to the TEEP Agent. This might 258 include a TAM URI provided in the application manifest, for 259 example. 261 - Optionally, any requirements that may affect the choice of TEE, if 262 multiple are available to the TEEP Broker. 264 When a TEEP Broker receives such a notification, it first identifies 265 in an implementation-dependent way which TEE (if any) is most 266 appropriate based on the constraints expressed. If there is only one 267 TEE, the choice is obvious. Otherwise, the choice might be based on 268 factors such as capabilities of available TEE(s) compared with TEE 269 requirements in the notification. Once the TEEP Broker picks a TEE, 270 it passes the notification to the TEEP/HTTP Client for that TEE. 272 The TEEP/HTTP Client then informs the TEEP Agent in that TEE by 273 invoking an appropriate "RequestTA" API that identifies the TA needed 274 and any other associated metadata. The TEEP/HTTP Client need not 275 know whether the TEE already has such a TA installed or whether it is 276 up to date. 278 The TEEP Agent will either (a) pass no data back, (b) pass back a TAM 279 URI to connect to, or (c) pass back a message buffer and TAM URI to 280 send it to. The TAM URI passed back may or may not be the same as 281 the TAM URI, if any, provided by the TEEP/HTTP Client, depending on 282 the TEEP Agent's configuration. If they differ, the TEEP/HTTP Client 283 MUST use the TAM URI passed back. 285 5.1.1. Session Creation 287 If no data is passed back, the TEEP/HTTP Client simply informs its 288 caller (e.g., the application installer) of success. 290 If the TEEP Agent passes back a TAM URI with no message buffer, the 291 TEEP/HTTP Client attempts to create session state, then sends an 292 HTTP(S) POST to the TAM URI with an Accept header with the TEEP media 293 type requested, and an empty body. The HTTP request is then 294 associated with the TEEP/HTTP Client's session state. 296 If the TEEP Agent instead passes back a TAM URI with a message 297 buffer, the TEEP/HTTP Client attempts to create session state and 298 handles the message buffer as specified in Section 5.3. 300 Session state consists of: 302 - Any context (e.g., a handle) that identifies the API session with 303 the TEEP Agent. 305 - Any context that identifies an HTTP request, if one is 306 outstanding. Initially, none exists. 308 5.2. Receiving a notification that a Trusted Application is no longer 309 needed 311 In some environments, an application installer can determine (e.g., 312 from an application manifest) that a given Trusted Application is no 313 longer needed, such as if the application that previously depended on 314 the TA is uninstalled or updated in a way that removes the 315 dependency. In such a case, it will notify a TEEP Broker, where the 316 notification will contain the following: 318 - A unique identifier of the TA 320 - Optionally, any requirements that may affect the choice of TEE, if 321 multiple are available to the TEEP Broker. 323 When a TEEP Broker receives such a notification, it first identifies 324 in an implementation-dependent way which TEE (if any) is appropriate 325 based on the constraints expressed, as in Section 5.1. 327 The TEEP/HTTP Client then informs the TEEP Agent in that TEE by 328 invoking an appropriate "UnrequestTA" API that identifies the 329 unneeded TA. The TEEP/HTTP Client need not know whether the TEE 330 actually has the TA installed. 332 The TEEP Agent will either (a) pass no data back, (b) pass back a TAM 333 URI to connect to, or (c) pass back a message buffer and TAM URI to 334 send it to. The TAM URI passed back may or may not be the same as 335 the TAM URI, if any, provided by the TEEP/HTTP Client, depending on 336 the TEEP Agent's configuration. If they differ, the TEEP/HTTP Client 337 MUST use the TAM URI passed back. 339 Processing then continues as in Section 5.1.1. 341 5.3. Getting a message buffer back from a TEEP Agent 343 When a TEEP Agent passes a message buffer (and TAM URI) to a TEEP/ 344 HTTP Client, the TEEP/HTTP Client MUST do the following, using the 345 TEEP/HTTP Client's session state associated with its API call to the 346 TEEP Agent. 348 The TEEP/HTTP Client sends an HTTP POST request to the TAM URI with 349 Accept and Content-Type headers with the TEEP media type in use, and 350 a body containing the TEEP message buffer provided by the TEEP Agent. 351 The HTTP request is then associated with the TEEP/HTTP Client's 352 session state. 354 5.4. Receiving an HTTP response 356 When an HTTP response is received in response to a request associated 357 with a given session state, the TEEP/HTTP Client MUST do the 358 following. 360 If the HTTP response body is empty, the TEEP/HTTP Client's task is 361 complete, and it can delete its session state, and its task is done. 363 If instead the HTTP response body is not empty, the TEEP/HTTP Client 364 passes (e.g., using "ProcessTeepMessage" API as mentioned in 365 Section 6.2.1 of [I-D.ietf-teep-architecture]) the response body up 366 to the TEEP Agent associated with the session. The TEEP Agent will 367 then either pass no data back, or pass back a message buffer. 369 If no data is passed back, the TEEP/HTTP Client's task is complete, 370 and it can delete its session state, and inform its caller (e.g., the 371 application installer) of success. 373 If instead the TEEP Agent passes back a message buffer, the TEEP/HTTP 374 Client handles the message buffer as specified in Section 5.3. 376 5.5. Handling checks for policy changes 378 An implementation MUST provide a way to periodically check for TAM 379 policy changes, such as a Trusted Application needing to be deleted 380 from a TEE because it is no longer permitted, or needing to be 381 updated to a later version. This can be done in any implementation- 382 specific manner, such as: 384 A) The TEEP/HTTP Client might call up to the TEEP Agent at an 385 interval previously specified by the TEEP Agent. This approach 386 requires that the TEEP/HTTP Client be capable of running a periodic 387 timer. 389 B) The TEEP/HTTP Client might be informed when an existing TA is 390 invoked, and call up to the TEEP Agent if more time has passed than 391 was previously specified by the TEEP Agent. This approach allows the 392 device to go to sleep for a potentially long period of time. 394 C) The TEEP/HTTP Client might be informed when any attestation 395 attempt determines that the device is out of compliance, and call up 396 to the TEEP Agent to remediate. 398 The TEEP/HTTP Client informs the TEEP Agent by invoking an 399 appropriate "RequestPolicyCheck" API. The TEEP Agent will either (a) 400 pass no data back, (b) pass back a TAM URI to connect to, or (c) pass 401 back a message buffer and TAM URI to send it to. Processing then 402 continues as specified in Section 5.1.1. 404 The TEEP Agent might need to talk to multiple TAMs, however, as shown 405 in Figure 1 of [I-D.ietf-teep-architecture]. To accomplish this, the 406 TEEP/HTTP Client keeps invoking the "RequestPolicyCheck" API until 407 the TEEP Agent passes no data back, so that the TEEP Agent can return 408 each TAM URI in response to a separate API call. 410 5.6. Error handling 412 If any local error occurs where the TEEP/HTTP Client cannot get a 413 message buffer (empty or not) back from the TEEP Agent, the TEEP/HTTP 414 Client deletes its session state, and informs its caller (e.g., the 415 application installer) of a failure. 417 If any HTTP request results in an HTTP error response or a lower 418 layer error (e.g., network unreachable), the TEEP/HTTP Client calls 419 the TEEP Agent's "ProcessError" API, and then deletes its session 420 state and informs its caller of a failure. 422 6. TEEP/HTTP Server Behavior 424 6.1. Receiving an HTTP POST request 426 If the TAM does not receive the appropriate Content-Type header 427 fields, the TAM SHOULD fail the request, returning a 415 Unsupported 428 Media Type response. Similarly, if an appropriate Accept header 429 field is not present, the TAM SHOULD fail the request with an 430 appropriate error response. (This is for consistency with common 431 implementation practice to allow the HTTP server to choose a default 432 error response, since in some implementations the choice is done at 433 the HTTP layer rather than the layer at which TEEP-over-HTTP would be 434 implemented.) Otherwise, processing continues as follows. 436 When an HTTP POST request is received with an empty body, the TEEP/ 437 HTTP Server invokes the TAM's "ProcessConnect" API. The TAM will 438 then pass back a (possibly empty) message buffer. 440 When an HTTP POST request is received with a non-empty body, the 441 TEEP/HTTP Server passes the request body to the TAM (e.g., using the 442 "ProcessTeepMessage" API mentioned in [I-D.ietf-teep-architecture]). 443 The TAM will then pass back a (possibly empty) message buffer. 445 6.2. Getting an empty buffer back from the TAM 447 If the TAM passes back an empty buffer, the TEEP/HTTP Server sends a 448 successful (2xx) response with no body. It SHOULD be status 204 (No 449 Content). 451 6.3. Getting a message buffer from the TAM 453 If the TAM passes back a non-empty buffer, the TEEP/HTTP Server 454 generates a successful (2xx) response with a Content-Type header with 455 the appropriate media type in use, and with the message buffer as the 456 body. 458 6.4. Error handling 460 If any error occurs where the TEEP/HTTP Server cannot get a message 461 buffer (empty or not) back from the TAM, the TEEP/HTTP Server 462 generates an appropriate HTTP 5xx error response. 464 7. Sample message flow 466 The following shows a sample TEEP message flow that uses application/ 467 teep+cbor as the Content-Type. 469 1. An application installer determines (e.g., from an application 470 manifest) that the application has a dependency on TA "X", and 471 passes this notification to the TEEP Broker. The TEEP Broker 472 picks a TEE (e.g., the only one available) based on this 473 notification, and passes the information to the TEEP/HTTP Cient 474 for that TEE. 476 2. The TEEP/HTTP Client calls the TEEP Agent's "RequestTA" API, 477 passing TA Needed = X. 479 3. The TEEP Agent finds that no such TA is already installed, but 480 that it can be obtained from a given TAM. The TEEP Agent passes 481 the TAM URI (e.g., "https://example.com/tam") to the TEEP/HTTP 482 Client. 484 4. The TEEP/HTTP Client sends an HTTP POST request to the TAM URI: 486 POST /tam HTTP/1.1 487 Host: example.com 488 Accept: application/teep+cbor 489 Content-Length: 0 490 User-Agent: Foo/1.0 492 where the TEEP/HTTP Client fills in an implementation-specific 493 value in the User-Agent header. 495 5. On the TAM side, the TEEP/HTTP Server receives the HTTP POST 496 request, and calls the TAM's "ProcessConnect" API. 498 6. The TAM generates a TEEP message (where typically QueryRequest 499 is the first message) and passes it to the TEEP/HTTP Server. 501 7. The TEEP/HTTP Server sends an HTTP successful response with the 502 TEEP message in the body: 504 HTTP/1.1 200 OK 505 Content-Type: application/teep+cbor 506 Content-Length: [length of TEEP message here] 507 Server: Bar/2.2 508 X-Content-Type-Options: nosniff 509 Content-Security-Policy: default-src 'none' 510 Referrer-Policy: no-referrer 512 [TEEP message here] 514 where the TEEP/HTTP Server fills in an implementation-specific 515 value in the Server header. 517 8. Back on the TEEP Agent side, the TEEP/HTTP Client gets the HTTP 518 response, extracts the TEEP message and pass it up to the TEEP 519 Agent. 521 9. The TEEP Agent processes the TEEP message, and generates a TEEP 522 response (e.g., QueryResponse) which it passes back to the TEEP/ 523 HTTP Client. 525 10. The TEEP/HTTP Client gets the TEEP message buffer and sends an 526 HTTP POST request to the TAM URI, with the TEEP message in the 527 body: 529 POST /tam HTTP/1.1 530 Host: example.com 531 Accept: application/teep+cbor 532 Content-Type: application/teep+cbor 533 Content-Length: [length of TEEP message here] 534 User-Agent: Foo/1.0 536 [TEEP message here] 538 11. The TEEP/HTTP Server receives the HTTP POST request, and passes 539 the payload up to the TAM. 541 12. Steps 6-11 are then repeated until the TAM passes no data back 542 to the TEEP/HTTP Server in step 6. 544 13. The TEEP/HTTP Server sends an HTTP successful response with no 545 body: 547 HTTP/1.1 204 No Content 548 Server: Bar/2.2 550 14. The TEEP/HTTP Client deletes its session state. 552 8. Security Considerations 554 Section 4 discussed security recommendations for HTTPS transport of 555 TEEP messages. See Section 6 of [I-D.ietf-httpbis-bcp56bis] for 556 additional discussion of HTTP(S) security considerations. 558 9. IANA Considerations 560 This document has no actions for IANA. 562 10. References 564 10.1. Normative References 566 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 567 "Recommendations for Secure Use of Transport Layer 568 Security (TLS) and Datagram Transport Layer Security 569 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 570 2015, . 572 [I-D.ietf-httpbis-semantics] 573 Fielding, R., Nottingham, M., and J. Reschke, "HTTP 574 Semantics", draft-ietf-httpbis-semantics-14 (work in 575 progress), January 2021. 577 [I-D.ietf-teep-protocol] 578 Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A. 579 Tsukamoto, "Trusted Execution Environment Provisioning 580 (TEEP) Protocol", draft-ietf-teep-protocol-04 (work in 581 progress), November 2020. 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, 585 DOI 10.17487/RFC2119, March 1997, . 588 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 589 Verification of Domain-Based Application Service Identity 590 within Internet Public Key Infrastructure Using X.509 591 (PKIX) Certificates in the Context of Transport Layer 592 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 593 2011, . 595 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 596 Security (TLS) / Datagram Transport Layer Security (DTLS) 597 Profiles for the Internet of Things", RFC 7925, 598 DOI 10.17487/RFC7925, July 2016, . 601 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 602 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 603 May 2017, . 605 10.2. Informative References 607 [GP-OTrP] Global Platform, "TEE Management Framework: Open Trust 608 Protocol (OTrP) Profile Version 1.0", Global 609 Platform GPD_SPE_123, May 2019, 610 . 613 [I-D.ietf-httpbis-bcp56bis] 614 Nottingham, M., "Building Protocols with HTTP", draft- 615 ietf-httpbis-bcp56bis-09 (work in progress), November 616 2019. 618 [I-D.ietf-quic-transport] 619 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 620 and Secure Transport", draft-ietf-quic-transport-34 (work 621 in progress), January 2021. 623 [I-D.ietf-teep-architecture] 624 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 625 "Trusted Execution Environment Provisioning (TEEP) 626 Architecture", draft-ietf-teep-architecture-13 (work in 627 progress), November 2020. 629 [I-D.ietf-teep-opentrustprotocol] 630 Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig, 631 "The Open Trust Protocol (OTrP)", draft-ietf-teep- 632 opentrustprotocol-03 (work in progress), May 2019. 634 Author's Address 636 Dave Thaler 637 Microsoft 639 EMail: dthaler@microsoft.com