idnits 2.17.1 draft-ietf-teep-otrp-over-http-07.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 (July 23, 2020) is 1373 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-10 == Outdated reference: A later version (-18) exists of draft-ietf-teep-protocol-03 ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** 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 (-34) exists of draft-ietf-quic-transport-29 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-12 Summary: 3 errors (**), 0 flaws (~~), 6 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 July 23, 2020 5 Expires: January 24, 2021 7 HTTP Transport for Trusted Execution Environment Provisioning: Agent-to- 8 TAM Communication 9 draft-ietf-teep-otrp-over-http-07 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 January 24, 2021. 39 Copyright Notice 41 Copyright (c) 2020 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 Models . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Use of Abstract APIs . . . . . . . . . . . . . . . . . . 5 60 4. Use of HTTP as a Transport . . . . . . . . . . . . . . . . . 6 61 5. TEEP/HTTP Client Behavior . . . . . . . . . . . . . . . . . . 7 62 5.1. Receiving a request to install a new Trusted Application 7 63 5.1.1. Session Creation . . . . . . . . . . . . . . . . . . 8 64 5.2. Getting a message buffer back from a TEEP Agent . . . . . 8 65 5.3. Receiving an HTTP response . . . . . . . . . . . . . . . 9 66 5.4. Handling checks for policy changes . . . . . . . . . . . 9 67 5.5. Error handling . . . . . . . . . . . . . . . . . . . . . 10 68 6. TEEP/HTTP Server Behavior . . . . . . . . . . . . . . . . . . 10 69 6.1. Receiving an HTTP POST request . . . . . . . . . . . . . 10 70 6.2. Getting an empty buffer back from the TAM . . . . . . . . 10 71 6.3. Getting a message buffer from the TAM . . . . . . . . . . 10 72 6.4. Error handling . . . . . . . . . . . . . . . . . . . . . 11 73 7. Sample message flow . . . . . . . . . . . . . . . . . . . . . 11 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 78 10.2. Informative References . . . . . . . . . . . . . . . . . 14 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 A Trusted Execution Environment (TEE) is an environment that enforces 84 that any code within that environment cannot be tampered with, and 85 that any data used by such code cannot be read or tampered with by 86 any code outside that environment. The Trusted Execution Environment 87 Provisioning (TEEP) protocol is designed to provision authorized code 88 and configuration into TEEs. 90 To be secure against malware, a TEEP implementation (referred to as a 91 TEEP "Agent" on the client side, and a "Trusted Application Manager 92 (TAM)" on the server side) SHOULD themselves run inside a TEE, 93 although a TAM running outside a TEE is also supported. However, the 94 transport for TEEP, along with the underlying TCP/IP stack, does not 95 necessarily run inside a TEE. This split allows the set of highly 96 trusted code to be kept as small as possible, including allowing code 97 (e.g., TCP/IP or QUIC [I-D.ietf-quic-transport]) that only sees 98 encrypted messages, to be kept out of the TEE. 100 The TEEP specification [I-D.ietf-teep-protocol] (like its 101 predecessors [I-D.ietf-teep-opentrustprotocol] and [GP-OTrP]) 102 describes the behavior of TEEP Agents and TAMs, but does not specify 103 the details of the transport. The purpose of this document is to 104 provide such details. That is, a TEEP-over-HTTP (TEEP/HTTP) 105 implementation delivers messages up to a TEEP implementation, and 106 accepts messages from the TEEP implementation to be sent over a 107 network. The TEEP-over-HTTP implementation can be implemented either 108 outside a TEE (i.e., in a TEEP "Broker") or inside a TEE. 110 There are two topological scenarios in which TEEP could be deployed: 112 1. TAMs are reachable on the Internet, and Agents are on networks 113 that might be behind a firewall or stateful NAT, so that 114 communication must be initiated by an Agent. Thus, the Agent has 115 an HTTP Client and the TAM has an HTTP Server. 117 2. Agents are reachable on the Internet, and TAMs are on networks 118 that might be behind a firewall or stateful NAT, so that 119 communication must be initiated by a TAM. Thus, the Agent has an 120 HTTP Server and the TAM has an HTTP Client. 122 The remainder of this document focuses primarily on the first 123 scenario as depicted in Figure 1, but some sections (Section 4 and 124 Section 8) may apply to the second scenario as well. A fuller 125 discussion of the second scenario may be handled by a separate 126 document. 128 +------------------+ TEEP +------------------+ 129 | TEEP Agent | <----------------------> | TAM | 130 +------------------+ +------------------+ 131 | | 132 +------------------+ TEEP-over-HTTP +------------------+ 133 | TEEP/HTTP Client | <----------------------> | TEEP/HTTP Server | 134 +------------------+ +------------------+ 135 | | 136 +------------------+ HTTP +------------------+ 137 | HTTP Client | <----------------------> | HTTP Server | 138 +------------------+ +------------------+ 140 Figure 1: Agent-to-TAM Communication 142 This document specifies the middle layer (TEEP-over-HTTP), whereas 143 the top layer (TEEP) is specified in [I-D.ietf-teep-protocol]. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 This document also uses various terms defined in 154 [I-D.ietf-teep-architecture], including Trusted Execution Environment 155 (TEE), Trusted Application (TA), Trusted Application Manager (TAM), 156 TEEP Agent, TEEP Broker, and Rich Execution Environment (REE). 158 3. TEEP Broker Models 160 Section 6 of the TEEP architecture [I-D.ietf-teep-architecture] 161 defines a TEEP "Broker" as being a component on the device, but 162 outside the TEE, that facilitates communication with a TAM. As 163 depicted in Figure 2, there are multiple ways in which this can be 164 implemented, with more or fewer layers being inside the TEE. For 165 example, in model A, the model with the smallest TEE footprint, only 166 the TEEP implementation is inside the TEE, whereas the TEEP/HTTP 167 implementation is in the TEEP Broker outside the TEE. 169 Model: A B C ... 171 TEE TEE TEE 172 +----------------+ | | | 173 | TEEP | Agent | | | Agent 174 | implementation | | | | 175 +----------------+ v | | 176 | | | 177 +----------------+ ^ | | 178 | TEEP/HTTP | Broker | | | 179 | implementation | | | | 180 +----------------+ | v | 181 | | | 182 +----------------+ | ^ | 183 | HTTP | | | | 184 | implementation | | | | 185 +----------------+ | | v 186 | | | 187 +----------------+ | | ^ 188 | TCP or QUIC | | | | Broker 189 | implementation | | | | 190 +----------------+ | | | 191 REE REE REE 193 Figure 2: TEEP Broker Models 195 In other models, additional layers are moved into the TEE, increasing 196 the TEE footprint, with the Broker either containing or calling the 197 topmost protocol layer outside of the TEE. An implementation is free 198 to choose any of these models, although model A is the one we will 199 use in our examples. 201 Passing information from an REE component to a TEE component is 202 typically spoken of as being passed "in" to the TEE, and informaton 203 passed in the opposite direction is spoken of as being passed "out". 204 In the protocol layering sense, information is typically spoken of as 205 being passed "up" or "down" the stack. Since the layer at which 206 information is passed in/out may vary by implementation, we will 207 generally use "up" and "down" in this document. 209 3.1. Use of Abstract APIs 211 This document refers to various APIs between a TEEP implementation 212 and a TEEP/HTTP implementation in the abstract, meaning the literal 213 syntax and programming language are not specified, so that various 214 concrete APIs can be designed (outside of the IETF) that are 215 compliant. 217 Some TEE architectures (e.g., SGX) may support API calls both into 218 and out of a TEE. In other TEE architectures, there may be no calls 219 out from a TEE, but merely data returned from calls into a TEE. This 220 document attempts to be agnostic as to the concrete API architecture 221 for Broker/Agent communication. Since in model A, the Broker/Agent 222 communication is done at the layer between the TEEP and TEEP/HTTP 223 implementations, and there may be some architectures that do not 224 support calls out of the TEE (which would be downcalls from TEEP in 225 model A), we will refer to passing information up to the TEEP 226 implementation as API calls, but will simply refer to "passing data" 227 back down from a TEEP implementation. A concrete API might pass data 228 back via an API downcall or via data returned from an API upcall. 230 This document will also refer to passing "no" data back out of a TEEP 231 implementation. In a concrete API, this might be implemented by not 232 making any downcall, or by returning 0 bytes from an upcall, for 233 example. 235 4. Use of HTTP as a Transport 237 This document uses HTTP [I-D.ietf-httpbis-semantics] as a transport. 238 For the motivation behind the HTTP recommendations in this document, 239 see the discussion of HTTP as a transport in 240 [I-D.ietf-httpbis-bcp56bis]. 242 Redirects MAY be automatically followed, and no additional request 243 headers beyond those specified by HTTP need be modified or removed 244 upon following such a redirect. Cookies are not used. 246 Content is not intended to be treated as active by browsers and so 247 HTTP responses with content SHOULD have the following headers as 248 explained in Section 4.12 of [I-D.ietf-httpbis-bcp56bis] (using the 249 relevant TEEP content type defined in [I-D.ietf-teep-protocol]): 251 Content-Type: application/teep+cbor 252 Cache-Control: no-store 253 X-Content-Type-Options: nosniff 254 Content-Security-Policy: default-src 'none' 255 Referrer-Policy: no-referrer 257 The "Cache-control" header SHOULD be set to no-store to disable 258 caching of any TEEP protocol messages by HTTP intermediaries. 259 Otherwise, there is the risk of stale TEEP messages. 261 Only the POST method is specified for TAM resources exposed over 262 HTTP. A URI of such a resource is referred to as a "TAM URI". A TAM 263 URI can be any HTTP(S) URI. The URI to use is configured in a TEEP 264 Agent via an out-of-band mechanism, as discussed in the next section. 266 It is strongly RECOMMENDED that implementations use HTTPS. Although 267 TEEP is protected end-to-end inside of HTTP, there is still value in 268 using HTTPS for transport, since HTTPS can provide additional 269 protections as discussed in Sections 4.4.2 and 6 of 270 [I-D.ietf-httpbis-bcp56bis]. 272 However, there may be constrained nodes where code space is an issue. 273 [RFC7925] provides TLS profiles that can be used in many constrained 274 nodes, but in rare cases the most constrained nodes might need to use 275 HTTP without a TLS stack, relying on the end-to-end security provided 276 by the TEEP protocol. 278 When HTTPS is used, TLS certificates MUST be checked according to 279 [RFC2818], as well as [RFC6125] if PKIX certificates are used. See 280 [BCP195] for additional TLS recommendations and [RFC7925] for TLS 281 recommandations related to IoT devices. 283 5. TEEP/HTTP Client Behavior 285 5.1. Receiving a request to install a new Trusted Application 287 In some environments, an application installer can determine (e.g., 288 from an app manifest) that the application being installed or updated 289 has a dependency on a given Trusted Application (TA) being available 290 in a given type of TEE. In such a case, it will notify a TEEP 291 Broker, where the notification will contain the following: 293 - A unique identifier of the TA 295 - Optionally, any metadata to provide to the TEEP Agent. This might 296 include a TAM URI provided in the application manifest, for 297 example. 299 - Optionally, any requirements that may affect the choice of TEE, if 300 multiple are available to the TEEP Broker. 302 When a TEEP Broker receives such a notification, it first identifies 303 in an implementation-dependent way which TEE (if any) is most 304 appropriate based on the constraints expressed. If there is only one 305 TEE, the choice is obvious. Otherwise, the choice might be based on 306 factors such as capabilities of available TEE(s) compared with TEE 307 requirements in the notification. Once the TEEP Broker picks a TEE, 308 it passes the notification to the TEEP/HTTP Client for that TEE. 310 The TEEP/HTTP Client then informs the TEEP Agent in that TEE by 311 invoking an appropriate "RequestTA" API that identifies the TA needed 312 and any other associated metadata. The TEEP/HTTP Client need not 313 know whether the TEE already has such a TA installed or whether it is 314 up to date. 316 The TEEP Agent will either (a) pass no data back, (b) pass back a TAM 317 URI to connect to, or (c) pass back a message buffer and TAM URI to 318 send it to. The TAM URI passed back may or may not be the same as 319 the TAM URI, if any, provided by the TEEP/HTTP Client, depending on 320 the TEEP Agent's configuration. If they differ, the TEEP/HTTP Client 321 MUST use the TAM URI passed back. 323 5.1.1. Session Creation 325 If no data is passed back, the TEEP/HTTP Client simply informs its 326 caller (e.g., the application installer) of success. 328 If the TEEP Agent passes back a TAM URI with no message buffer, the 329 TEEP/HTTP Client attempts to create session state, then sends an 330 HTTP(S) POST to the TAM URI with an Accept header with the TEEP media 331 type requested, and an empty body. The HTTP request is then 332 associated with the TEEP/HTTP Client's session state. 334 If the TEEP Agent instead passes back a TAM URI with a message 335 buffer, the TEEP/HTTP Client attempts to create session state and 336 handles the message buffer as specified in Section 5.2. 338 Session state consists of: 340 - Any context (e.g., a handle) that identifies the API session with 341 the TEEP Agent. 343 - Any context that identifies an HTTP request, if one is 344 outstanding. Initially, none exists. 346 5.2. Getting a message buffer back from a TEEP Agent 348 When a TEEP Agent passes a message buffer (and TAM URI) to a TEEP/ 349 HTTP Client, the TEEP/HTTP Client MUST do the following, using the 350 TEEP/HTTP Client's session state associated with its API call to the 351 TEEP Agent. 353 The TEEP/HTTP Client sends an HTTP POST request to the TAM URI with 354 Accept and Content-Type headers with the TEEP media type in use, and 355 a body containing the TEEP message buffer provided by the TEEP Agent. 356 The HTTP request is then associated with the TEEP/HTTP Client's 357 session state. 359 5.3. Receiving an HTTP response 361 When an HTTP response is received in response to a request associated 362 with a given session state, the TEEP/HTTP Client MUST do the 363 following. 365 If the HTTP response body is empty, the TEEP/HTTP Client's task is 366 complete, and it can delete its session state, and its task is done. 368 If instead the HTTP response body is not empty, the TEEP/HTTP Client 369 passes (e.g., using "ProcessTeepMessage" API as mentioned in 370 Section 6.2.1 of [I-D.ietf-teep-architecture]) the response body up 371 to the TEEP Agent associated with the session. The TEEP Agent will 372 then either pass no data back, or pass back a message buffer. 374 If no data is passed back, the TEEP/HTTP Client's task is complete, 375 and it can delete its session state, and inform its caller (e.g., the 376 application installer) of success. 378 If instead the TEEP Agent passes back a message buffer, the TEEP/HTTP 379 Client handles the message buffer as specified in Section 5.2. 381 5.4. Handling checks for policy changes 383 An implementation MUST provide a way to periodically check for TAM 384 policy changes, such as a Trusted Application needing to be deleted 385 from a TEE because it is no longer permitted, or needing to be 386 updated to a later version. This can be done in any implementation- 387 specific manner, such as: 389 A) The TEEP/HTTP Client might call up to the TEEP Agent at an 390 interval previously specified by the TEEP Agent. This approach 391 requires that the TEEP/HTTP Client be capable of running a periodic 392 timer. 394 B) The TEEP/HTTP Client might be informed when an existing TA is 395 invoked, and call up to the TEEP Agent if more time has passed than 396 was previously specified by the TEEP Agent. This approach allows the 397 device to go to sleep for a potentially long period of time. 399 C) The TEEP/HTTP Client might be informed when any attestation 400 attempt determines that the device is out of compliance, and call up 401 to the TEEP Agent to remediate. 403 The TEEP/HTTP Client informs the TEEP Agent by invoking an 404 appropriate "RequestPolicyCheck" API. The TEEP Agent will either (a) 405 pass no data back, (b) pass back a TAM URI to connect to, or (c) pass 406 back a message buffer and TAM URI to send it to. Processing then 407 continues as specified in Section 5.1.1. 409 5.5. Error handling 411 If any local error occurs where the TEEP/HTTP Client cannot get a 412 message buffer (empty or not) back from the TEEP Agent, the TEEP/HTTP 413 Client deletes its session state, and informs its caller (e.g., the 414 application installer) of a failure. 416 If any HTTP request results in an HTTP error response or a lower 417 layer error (e.g., network unreachable), the TEEP/HTTP Client calls 418 the TEEP Agent's "ProcessError" API, and then deletes its session 419 state and informs its caller of a failure. 421 6. TEEP/HTTP Server Behavior 423 6.1. Receiving an HTTP POST request 425 If the TAM does not receive the appropriate Content-Type and Accept 426 header fields, the TAM SHOULD fail the request, returning a 406 (not 427 acceptable) response. Otherwise, processing continues as follows. 429 When an HTTP POST request is received with an empty body, the TEEP/ 430 HTTP Server invokes the TAM's "ProcessConnect" API. The TAM will 431 then pass back a (possibly empty) message buffer. 433 When an HTTP POST request is received with a non-empty body, the 434 TEEP/HTTP Server passes the request body to the TAM (e.g., using the 435 "ProcessTeepMessage" API mentioned in [I-D.ietf-teep-architecture]). 436 The TAM will then pass back a (possibly empty) message buffer. 438 6.2. Getting an empty buffer back from the TAM 440 If the TAM passes back an empty buffer, the TEEP/HTTP Server sends a 441 successful (2xx) response with no body. It SHOULD be status 204 (No 442 Content). 444 6.3. Getting a message buffer from the TAM 446 If the TAM passes back a non-empty buffer, the TEEP/HTTP Server 447 generates a successful (2xx) response with a Content-Type header with 448 the appropriate media type in use, and with the message buffer as the 449 body. 451 6.4. Error handling 453 If any error occurs where the TEEP/HTTP Server cannot get a message 454 buffer (empty or not) back from the TAM, the TEEP/HTTP Server 455 generates an appropriate HTTP 5xx error response. 457 7. Sample message flow 459 The following shows a sample TEEP message flow that uses application/ 460 teep+cbor as the Content-Type. 462 1. An application installer determines (e.g., from an app manifest) 463 that the application has a dependency on TA "X", and passes this 464 notification to the TEEP Broker. The TEEP Broker picks a TEE 465 (e.g., the only one available) based on this notification, and 466 passes the information to the TEEP/HTTP Cient for that TEE. 468 2. The TEEP/HTTP Client calls the TEEP Agent's "RequestTA" API, 469 passing TA Needed = X. 471 3. The TEEP Agent finds that no such TA is already installed, but 472 that it can be obtained from a given TAM. The TEEP Agent passes 473 the TAM URI (e.g., "https://example.com/tam") to the TEEP/HTTP 474 Client. 476 4. The TEEP/HTTP Client sends an HTTP POST request to the TAM URI: 478 POST /tam HTTP/1.1 479 Host: example.com 480 Accept: application/teep+cbor 481 Content-Length: 0 482 User-Agent: Foo/1.0 484 where the TEEP/HTTP Client fills in an implementation-specific 485 value in the User-Agent header. 487 5. On the TAM side, the TEEP/HTTP Server receives the HTTP POST 488 request, and calls the TAM's "ProcessConnect" API. 490 6. The TAM generates a TEEP message (where typically QueryRequest 491 is the first message) and passes it to the TEEP/HTTP Server. 493 7. The TEEP/HTTP Server sends an HTTP successful response with the 494 TEEP message in the body: 496 HTTP/1.1 200 OK 497 Content-Type: application/teep+cbor 498 Content-Length: [length of TEEP message here] 499 Server: Bar/2.2 500 Cache-Control: no-store 501 X-Content-Type-Options: nosniff 502 Content-Security-Policy: default-src 'none' 503 Referrer-Policy: no-referrer 505 [TEEP message here] 507 where the TEEP/HTTP Server fills in an implementation-specific 508 value in the Server header. 510 8. Back on the TEEP Agent side, the TEEP/HTTP Client gets the HTTP 511 response, extracts the TEEP message and pass it up to the TEEP 512 Agent. 514 9. The TEEP Agent processes the TEEP message, and generates a TEEP 515 response (e.g., QueryResponse) which it passes back to the TEEP/ 516 HTTP Client. 518 10. The TEEP/HTTP Client gets the TEEP message buffer and sends an 519 HTTP POST request to the TAM URI, with the TEEP message in the 520 body: 522 POST /tam HTTP/1.1 523 Host: example.com 524 Accept: application/teep+cbor 525 Content-Type: application/teep+cbor 526 Content-Length: [length of TEEP message here] 527 User-Agent: Foo/1.0 529 [TEEP message here] 531 11. The TEEP/HTTP Server receives the HTTP POST request, and passes 532 the payload up to the TAM. 534 12. Steps 6-11 are then repeated until the TAM passes no data back 535 to the TEEP/HTTP Server in step 6. 537 13. The TEEP/HTTP Server sends an HTTP successful response with no 538 body: 540 HTTP/1.1 204 No Content 541 Server: Bar/2.2 543 14. The TEEP/HTTP Client deletes its session state. 545 8. Security Considerations 547 Section 4 discussed security recommendations for HTTPS transport of 548 TEEP messages. See Section 6 of [I-D.ietf-httpbis-bcp56bis] for 549 additional discussion of HTTP(S) security considerations. 551 9. IANA Considerations 553 This document has no actions for IANA. 555 10. References 557 10.1. Normative References 559 [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, 560 "Recommendations for Secure Use of Transport Layer 561 Security (TLS) and Datagram Transport Layer Security 562 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 563 2015, . 565 [I-D.ietf-httpbis-semantics] 566 Fielding, R., Nottingham, M., and J. Reschke, "HTTP 567 Semantics", draft-ietf-httpbis-semantics-10 (work in 568 progress), July 2020. 570 [I-D.ietf-teep-protocol] 571 Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A. 572 Tsukamoto, "Trusted Execution Environment Provisioning 573 (TEEP) Protocol", draft-ietf-teep-protocol-03 (work in 574 progress), July 2020. 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, 578 DOI 10.17487/RFC2119, March 1997, . 581 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 582 DOI 10.17487/RFC2818, May 2000, . 585 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 586 Verification of Domain-Based Application Service Identity 587 within Internet Public Key Infrastructure Using X.509 588 (PKIX) Certificates in the Context of Transport Layer 589 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 590 2011, . 592 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 593 Security (TLS) / Datagram Transport Layer Security (DTLS) 594 Profiles for the Internet of Things", RFC 7925, 595 DOI 10.17487/RFC7925, July 2016, . 598 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 599 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 600 May 2017, . 602 10.2. Informative References 604 [GP-OTrP] Global Platform, "TEE Management Framework: Open Trust 605 Protocol (OTrP) Profile Version 1.0", Global 606 Platform GPD_SPE_123, May 2019, 607 . 610 [I-D.ietf-httpbis-bcp56bis] 611 Nottingham, M., "Building Protocols with HTTP", draft- 612 ietf-httpbis-bcp56bis-09 (work in progress), November 613 2019. 615 [I-D.ietf-quic-transport] 616 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 617 and Secure Transport", draft-ietf-quic-transport-29 (work 618 in progress), June 2020. 620 [I-D.ietf-teep-architecture] 621 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 622 "Trusted Execution Environment Provisioning (TEEP) 623 Architecture", draft-ietf-teep-architecture-12 (work in 624 progress), July 2020. 626 [I-D.ietf-teep-opentrustprotocol] 627 Pei, M., Atyeo, A., Cook, N., Yoo, M., and H. Tschofenig, 628 "The Open Trust Protocol (OTrP)", draft-ietf-teep- 629 opentrustprotocol-03 (work in progress), May 2019. 631 Author's Address 633 Dave Thaler 634 Microsoft 636 EMail: dthaler@microsoft.com