idnits 2.17.1 draft-yang-teep-ccican-00.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 (March 2022) is 771 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'CCC-White-Paper' is defined on line 424, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-rats-architecture-15 == Outdated reference: A later version (-19) exists of draft-ietf-teep-architecture-16 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Yang 3 Internet-Draft M. Chen 4 Intended status: Informational L. Su 5 Expires: 3 September 2022 China Mobile 6 March 2022 8 architecture of confidential computing in computing aware network 9 draft-yang-teep-ccican-00 11 Abstract 13 Confidential Computing is the protection of data in use by performing 14 computation in a hardware-based Trusted Execution Environment. 15 Especially in virtualization environments, confidential computing 16 could protect data and applications from access or tampering by 17 hypervisor or other privileged users. In Computing-Aware network, 18 computing resource is an essential element to provide computing 19 services for network users' applications. Introducing confidential 20 computing in Computing-Aware network could mitigate the distrust of 21 computing resource efficiently. This document provides the 22 architecture of confidential computing in Computing-Aware network 23 management plane to provide confidentiality and integrity for 24 applications. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 2 September 2022. 43 Copyright Notice 45 Copyright (c) 2022 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Revised BSD License text as 54 described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Revised BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Motivation and Scope . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. General Architecture of Confidential Computing in 65 Computing-Aware Network . . . . . . . . . . . . . . . . . 4 66 4. Environment Provisioning . . . . . . . . . . . . . . . . . . 6 67 5. Remote Attestation . . . . . . . . . . . . . . . . . . . . . 7 68 6. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 10.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 The Confidential Computing Consortium defined the concept of 80 confidential computing as "Confidential Computing is the protection 81 of data in use by performing computation in a hardware-based Trusted 82 Execution Environment"[CCC-White-Paper]. In detail, CPU with 83 confidential computing feature could generate an isolated hardware- 84 protected area, in which processing data or running code will be 85 protected from any illegal access or tampering. In cloud computing 86 scenario, CPU with confidential computing feature could be used to 87 protect users' applications and data from access or tampered by 88 hypervisor, privileged users or other attackers in the cloud 89 platform. In hardware industry, Intel, AMD, ARM and other chip 90 venders have already released their confidential computing CPU 91 series. 93 In Computing-Aware network, cloud-based computing resource prepared 94 for applications is from different places like edge or data center. 95 If the edge or data center is outsourced or even distributed in 96 different security domains, not only the network administrator but 97 also the application owner cannot trust the computing environment. 98 The potential leakage of secret data or intellectual property will 99 restrict the range of applications. With the protection of 100 confidential computing, users could trust the computing environment 101 and make sure their sensitive data and intellectual property will not 102 be leaked. 104 This document introduces confidential computing to Computing-Aware 105 network and illustrates the general architecture in network 106 management plane. Computing-Aware network designers and users could 107 use this document as a information reference to enhance their 108 security. 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 CC: Confidential Computing 118 CCR: Confidential Computing Resource 120 TEE: Trust Execution Environment 122 CCM: Confidential Computing Management 124 CCI: Confidential Computing Instance 126 TEEP: Trust Execution Environment Provisioning 128 TAM: Trusted Application Management 130 2. Motivation and Scope 132 2.1. Motivation 134 In Computing-Aware network, there is a suspicion about how to protect 135 users' application and data efficiently. Computing resource in 136 Computing-Aware network is more decentralized and ambiguous than 137 regular cloud computing. The network may distribute users' 138 applications in different computing platforms maintained by different 139 administrators. If the computing platform is malicious, secret data 140 and application intellectual property could be easily stolen or 141 tampered. Confidential computing provides a new security model in 142 where network users only need to trust the confidential computing 143 hardware, firmware and the applications provided by users themselves, 144 any other hypervisor or software in computing platform do not have to 145 be trusted. 147 2.2. Scope 149 This document mainly focuses on the unique features of confidential 150 computing in network management plane. Other network planes like 151 control/forwarding/data which have no direct interaction with 152 confidential computing features will be ignored. 154 3. General Architecture of Confidential Computing in Computing-Aware 155 Network 157 Targeting 158 +--> Environment 159 | +-------------+ +----------+ 160 | | Application | +->| APP Owner|<--+ 161 | +-------------+ | +----------+ | 162 | | Middleware |<-+ | 163 | +-------------+ | 164 | | TEEP Agent |<-----+ | 165 | +-------------+ | | 166 | | | 167 | +--------------------+------+ | 168 | | Hypervisor TEEP Broker |<--+ | 169 | +---------------------------+ | | 170 | | CPU/Firmware Attesting | | | 171 | | Environment| | | 172 | +---------------------+-----+ | | 173 | | | | 174 +------------------------+ | | 175 | | 176 +--------------------+--+-+ 177 | TAM & Middleware Repo | 178 | M/OC | 179 +-------------------------+ 181 Figure 1: Architecture of Confidential Computing in Computing- 182 Aware Network 184 Figure 1 shows the basic architecture of confidential computing in 185 Computing-Aware Network. This architecture refers to RATs 186 [I-D.ietf-rats-architecture] arch and 187 TEEP[I-D.ietf-teep-architecture] arch for remote attestation and 188 trust execution environment provisioning. Confidential computing 189 needs the support of CPU, in which MUST have the function of 190 generating isolated execution environment and attesting environment. 191 The layer of Hypervisor is for virtualization. 193 (1) Targeting Environment 195 Targeting Environment is the computing environment e.g. virtual 196 machine, process that could provide confidentiality and integrity for 197 applications. When used for remote attestation, the Targeting 198 Environment will be attested by application owner. Targeting 199 environment includes Application, Middleware, and TEEP Agent. 201 (2) Application 203 Application which runs in Computing-Aware network. 205 (3) Middleware 207 Middleware in CC has two functions: enable remote attestation and 208 environment provisioning; provide a user-friendly environment. Some 209 confidential computing CPU like SGX needs to use middleware to 210 provide a environment in where applications don't have to change 211 their source code, e.g. Enarx [Enarx] and Occlum [Occlum]. 213 (4) TEEP Agent 215 TEEP Agent is a module for provisioning middleware and application in 216 Targeting Environment. 218 (5) TEEP Broker 220 TEEP Broker is only for communication between TEEP Agent and TAM, it 221 doesn't have to know any confidential information. 223 (6) Attesting Environment 225 Attesting Environment is hardware based component, like Intel Quote 226 SGX, AMD SEV-SP, etc. This component is a part of TCB, and is used 227 to collect targeting environment evidence for remote attestation. 229 (7) M/OC 231 M/OC is the manage and orchestration console of Computing-Aware 232 Network. 234 (8) TAM 236 Trust Application Management, this entity is for provisioning of 237 application and relevant middleware. 239 (9) Middleware Repository 240 This repository keeps a variety of middleware packages, which is for 241 TAM to access based on Application type and confidential computing 242 hardware type. 244 4. Environment Provisioning 246 When deploying applications in Computing-Aware network, TAM will 247 choose confidential computing environment and relevant Middleware to 248 fit their applications. Meanwhile, Computing-Aware Network needs to 249 provide the secure procedure of provisioning middleware and 250 applications. This document uses TEEP as reference to provision 251 Middleware and applications in Computing-Aware network. 253 Targeting 254 Environment 255 +-------------+ +----------+ 256 | Application | | App Owner|<--+ 257 +-------------+ +----------+ | 258 | Middleware | | 259 +-------------+ | 260 | TEEP Agent |<-----+ | 261 +-------------+ |3 | 262 | | 263 +--------------------+------+ |1 264 | Hypervisor TEEP Broker |<--+ | 265 +---------------------------+ | | 266 | CPU/Firmware Attesting | | | 267 | Environment| |2 | 268 +---------------------+-----+ | | 269 | | 270 | | 271 | | 272 +--------------------+--+-+ 273 | TAM & Middleware Repo | 274 | M/OC | 275 +-------------------------+ 277 Figure 2: Application and Middleware Provisioning in Computing- 278 Aware Network 280 The Provisioning steps in Computing-Aware Network are illustrated 281 below. 283 (1) First, Application owner requests for confidential computing 284 resource in Computing-Aware Network. Second, based on the 285 request and confidential computing resource type, TAM will chose 286 appropriate middleware. 288 (2) TAM establishes connections with TEEP Broker to transfer 289 provisioning information. 291 (3) TEEP Broker triggers the confidential computing platform to 292 create Targeting Environment with TEEP Agent. Then TEEP Broker 293 establishes connections with TEEP agent. TEEP agent receives 294 the provisioning information and unpacks it as Middleware. 296 Need to clarify that at this stage the Middleware dosen't contain any 297 secret information. The secret information of application should be 298 provisioned after remote attestation. The specific mechanism of 299 building targeting environment is based on specific CPU and is out of 300 scope of this document. 302 5. Remote Attestation 304 In Computing-Aware Network, remote attestation is used for 305 application owner to appraise if the Targeting Environment is 306 trusted. Only after remote attestation, application owner could 307 trust the confidential computing environment and deploy secret 308 information. The general architecture of remote attestation in 309 Computing-Aware Network is shown below. 311 Targeting 312 +--> Environment 313 | +-------------+ 1/4 +----------+ 314 | | Application | +->| APP Owner|<--+ 315 | +-------------+ | +----------+ | 316 | | Middleware |<-+ | 317 | +-------------+ | 318 | | TEEP Agent | | 319 | +-------------+ | 320 |2 |3 321 | +--------------------+------+ | 322 | | Hypervisor TEEP Broker |<--+ | 323 | +---------------------------+ | | 324 | | CPU/Firmware Attesting | | | 325 | | Environment| | | 326 | +---------------------+-----+ | | 327 | | | | 328 +------------------------+ | | 329 | | 330 +--------------------+--+-+ 331 | TAM & Middleware Repo | 332 | M/OC | 333 +-------------------------+ 335 Figure 3: Remote Attestation in Computing-Aware Network 337 The remote attestation steps in Computing-Aware Network are shown 338 below. After appraising the remote attestation evidence, the 339 application owner could deploy secret data in Targeting Environment. 341 (1) Application owner establishes secure connection with middleware 342 and launches remote attestation request with certain parameters 343 like nonce. 345 (2) Targeting Environment launches evidence collection by 346 Middleware. Middleware sends request to Attesting Environment 347 for remote attestation evidence. After generating evidence by 348 Attesting Environment, the evidence will be sent back to 349 Middleware. 351 (3) The Application Owner requests for TEEP agent and middleware 352 source code to generate reference value and appraise the remote 353 attestation evidence. 355 (4) The Targeting Environment sends the evidence to Application 356 Owner. After appraising, Application Owner sends its 357 application and private data to Targeting Environment. 359 6. Use Case 361 Confidential computing provides confidentiality and integrity of data 362 and applications in the running stage. This document depicts the 363 abstract architecture of confidential computing from the perspective 364 of Computing-Aware Network. The following are some use cases of 365 confidential computing in Computing-Aware Network. 367 VR/AR Application: Users wants to use Computing-Aware Network to host 368 VR communication and interaction with other user. They don't want 369 their conversation to be awared by the network. And it is hard to 370 encrypt all the VR context because of unacceptable cost. So, the 371 users choose confidential computing to protect their privacy. After 372 the remote attestation of computing environment, the users could 373 transfer and process private information in Computing-Aware Network. 375 Medical Imaging Aalysis: A medical institute wants to use Computing- 376 Aware Network to share and process medical images in different 377 branches. One primary concern is that they don't want the patients' 378 medical images to be leaked. So they choose confidential computing 379 to process these images. 381 7. Security Considerations 383 The root of trust of confidential computing is the CPU hardware. 384 Application Owner could use the certificate or signature in remote 385 attestation information to verify the identity of CPU. The 386 connections between Application Owner and their applications are 387 protected by security protocols like TLS. 389 8. Acknowledgements 391 The author would like to thank Eric Voit, Mike Bursul and Dave Thaler 392 in CCC group who have provided valuable supports and suggestions. 394 9. IANA Considerations 396 This memo includes no request to IANA. 398 10. References 400 10.1. Normative References 402 [I-D.ietf-rats-architecture] 403 Birkholz, H., Thaler, D., Richardson, M., Smith, N., and 404 W. Pan, "Remote Attestation Procedures Architecture", Work 405 in Progress, Internet-Draft, draft-ietf-rats-architecture- 406 15, 8 February 2022, . 409 [I-D.ietf-teep-architecture] 410 Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler, 411 "Trusted Execution Environment Provisioning (TEEP) 412 Architecture", Work in Progress, Internet-Draft, draft- 413 ietf-teep-architecture-16, 28 February 2022, 414 . 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, 419 DOI 10.17487/RFC2119, March 1997, 420 . 422 10.2. Informative References 424 [CCC-White-Paper] 425 Confidential Computing Consortium, "Confidential 426 Computing: Hardware-Based Trusted Execution for 427 Applications and Data", 2021, 428 . 432 [Enarx] Profian, Inc., "Enarx", 2022, 433 . 435 [Occlum] Occlum, "Occlum", 2022, . 437 Authors' Addresses 439 Penglin Yang 440 China Mobile 441 Email: yangpenglin@chinamobile.com 443 Meiling Chen 444 China Mobile 445 Email: chenmeiling@chinamobile.com 447 Li Su 448 China Mobile 449 Email: suli@chinamobile.com