]> China Mobile

No.32 Xuanwumen West Street Beijing China yangpenglin@chinamobile.com

Huawei Technology Co.,Ltd.

127 Jinye Road, Yanta District Xi'an China pangting@huawei.com

AntGroup

World Financial Center, No.1 East 3rd Ring Middle Road, Chaoyang District Beijing China zhangxiaomeng.zxm@antgroup.com

Security TEEP distributed provisioning, big data In big data area, computing resource manager like MESOS, YARM, kubernets or computing framework like Spark, use Master-Worker structure to split computing task. In the master component, the computing task will be splited into different child tasks. Each of thess child tasks will be loaded to a executor which is managed by Worker. The Master and Worker are usually exist as cluster, cloud or other distributed framework. When the big data tasks needs to be processed in TEE in lifecycle, this document could be used for Master to provision child tasks in distributed TEEs.

Introduction In big data area, different from stand-alone applications, big data application always need to be splitted into different child tasks by Master in big data computing framework. Then these tasks will be deployed to executors in local or remote by Workers. TEE could be used to protect the application and its secret data during the process, if only the whole process lifecycle is covered by TEE. Before running big data application, it is hard to predict how many computing resources are needed. Similarly, TEE resource also needs to be provisioned during the application process lifecycle. This document specifies the architecture and protocol of how big data computing framework provision and use TEE during application process lifecycle. The Trusted Execution Environment Provisioning (TEEP) architecture document provides design guidance and introduces the necessary terminology.

Terminology The following terms are used:

• Big Data Computing Framework: An framework that is responsible for managing and spliting big data computing task, like Spark, MapReduce, etc. Usually, Big Data Computing Framework has its own Computing Resource Manage Framework. Like Spark supports standalone deploy mode.
• Computing Resource Manage Framework: An framework that is responsible for managing and scheduling computing resource in cluster, like YARN, MESOS and Kubernetes.
• Master: The entity in Computing Resource Manage Framework that is responsible for splitting computing task into different child tasks, and allocating computing resource to those child tasks.
• Executor: The executing entity that is responsible for executing child tasks in Worker. The current executor includes process, container and VM.
• Worker: The entity that is responsible for undertaking child tasks and manage Executors. Other terms like TAM, TEE, REE, TA will reuse the term definition defined in .

Use cases In federated machine learning, participants want to create a unified machine learning model without leaking private data owned by each other. TEE as a hardware based technology could make sure data inside this environment is integrated and confidential. If the federated machine learning participants trust this TEE and its TA, they could gather their data in that TEE and generate the final machine learning model. The architecture and protocol described in this document could be used in the federated machine learning scenario, and make sure the lifecycle of machine learning process is protected by TEE.

Architecture The following figure shows the architecture of TEE distributed provisioning. In this architecture, Master is the management center of big data Computing Resource Management Framework. it also plays the role of TAM in TEEP architecture. When Master starts running big data applications, it forwards TEE computing resource request to Worker by TEE-DP protocol. Worker then occupies TEE computing resource and generate Executor which is running inside TEE. Meanwhile, TEE-DP protocol also includes secure channel negotiation message. Based on the secure channel between TAM and Executor, TEEP protocol could provision child tasks generated by Master securely.

TEEP Broker Models | Master |<------------------+ | | /TAM | | | +--------+ | | ^ | | | | |TEE-DP +-------+ TEE-DP| |protocol |TEEP protocol protocol| | | | v v v +---------+ +----------+ +----------+ +--------+ | Worker |<-->| Executor | | Executor |<-->| Worker | +---------+ +----------+ +----------+ +--------+ | TEE | | TEE | +----------+ +----------+ ]]>

TEE Distributed Provisioning Protocol As described in architecture section, TEE distributed provisioning protocol has two message packages: TEE resource request/responses, TEE secure channel request/response. The message framework is shown below in CDDL format.

TEE DP Message Framework any) $tee-dp-message-type /= tee-resource-request $tee-dp-message-type /= tee-resource-response $tee-dp-message-type /= tee-secure-channel-resquest $tee-dp-message-type /= tee-secure-channel-response-direct $tee-dp-message-type /= tee-secure-channel-response-indirect $tee-dp-type = uint .size 1 TEE-resource-request = 1 TEE-resource-response = 2 TEE-secure-channel-request = 3 TEE-secure-channel-response-direct = 4 TEE-secure-channel-response-indirect = 5 ]]>

TEE Resource Request/Response TEE resource request/response message is used by Master/TAM and Worker to negotiate TEE computing resource. The resource request message is sent by Master/TAM, then the Worker response this message. The only mandantory option in request message is MEMORY-size. Other items like CPU core number, CPU frequency, CPU architecture, memory encryption method and memory isolation method are optional. Another message that is mandantory in response message is TOKEN-tee-instance, which represents the identity of selected TEE instance. This token could be public key of AIK(attestation identity key) or otehr identity information. The relevant CDDL fragment is shown below. The complete CDDL structure is shown in Appendix. {：#res-req title="TEE DP Resource Request Response " }

TEE Secure Channel Request/Response Before executing TEEP protocol between Master/TAM and Executor in TEE DP architecutre, secure channel needs to be established first. There are two kinds of secure channel in TEE DP architecture, direct and indirect. Direct means Master/TAM direct connect with Executor by network, which also means the TEE of Executor support network communication, like TLS. Indirect means the Master/TAM and Executor connect with each other by other components like TEEP broker, or Worker. Master/TAM and Executor could transfer encrypted packages like COSE, JWE, by that component. The CDDL fragment is shown below.

TEE DP Secure Channel Negotiation uint .bits protocol-name } $$ipaddr //= ( ipv4: bstr .size 4 ) $$ipaddr //= ( ipv6: bstr .size 16 ) direct-extensions = (uint => any) tee-secure-channel-response-direct = [ type: TEE-secure-channel-response-direct options:{ $$ipaddr port => uint .size 1 *direct-extensions } ] &protocol-name &= ( cose: 0, jwe: 1, others: 2, ) indirect-extentions = (uint => any) tee-secure-channel-response-indirect = [ type: TEE-channel-response-indirect options:{ Protocol-name => uint .bits protocol-name *indirect-extensions } ]]>

Security Considerations The trust domain of TEE DP architecture is Master/TAM and Executor running in TEE. The Worker component do not have to be trusted by Master/TAM since it is only used for creating Executor and monitoring runtime status. The security of secure channel based on the secure channel negotiation mechanism which is out of the scope of this document.

IANA Considerations TBD.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Broadcom Arm Limited Microsoft Amazon A Trusted Execution Environment (TEE) is an environment that enforces that any code within that environment cannot be tampered with, and that any data used by such code cannot be read or tampered with by any code outside that environment. This architecture document motivates the design and standardization of a protocol for managing the lifecycle of trusted applications running inside such a TEE. China Mobile China Mobile China Mobile Huawei Technology Co.,Ltd. Confidential computing is the protection of data in use by performing computation in a hardware-based Trusted Execution Environment. Confidential computing could provide integrity and confidentiality for users who want to run applications and process data in that environment. When confidential computing is used in scenarios which need network to provision users' data and applications in the TEE environment, TEEP architecture[I-D.ietf-teep-architecture] and protocol[I-D.ietf-teep-protocol] could be used. This document focuses on using TEEP to provision Network Users' data and applications in confidential computing. This document is a use case and extension of TEEP and could provide guidance for cloud computing, MEC[MEC] and other scenarios to use confidential computing in network. Broadcom Amazon Microsoft This document specifies a protocol that installs, updates, and deletes Trusted Components in a device with a Trusted Execution Environment (TEE). This specification defines an interoperable protocol for managing the lifecycle of Trusted Components. Informative References

Appendix 1 Full CDDL of TEE DP protocol The full CDDL of TEE distributed provisioning protocol is shown below.

Full CDDL of TEE Distributed Provisioning Protocol any) $tee-dp-message-type /= tee-resource-request $tee-dp-message-type /= tee-resource-response $tee-dp-message-type /= tee-secure-channel-resquest $tee-dp-message-type /= tee-secure-channel-response-direct $tee-dp-message-type /= tee-secure-channel-response-indirect $tee-dp-type = uint .size 1 TEE-resource-request = 1 TEE-resource-response = 2 TEE-secure-channel-request = 3 TEE-secure-channel-response-direct = 4 TEE-secure-channel-response-indirect = 5 memory-encryption-method = &( hardware-based: 0, software-based: 1, none: 2 ) memory-isolation-method = &( hardware-based: 0, software-based: 1, none: 2, ) tee-resource-request = [ type: TEE-resource-request options:{ CPU-core-number: uint .size 1 CPU-frequency: unit .size 2 ;the cpu frequency unit is MHZ MEMORY-size: uint .size 4 ;the memory size unit is MB ? Requested-memory-encryption-method: uint .bits memory-encryption-method ? Requested-memory-isolation-method: uint .bits memory-isolation-method } ] tee-resource-response = [ type: TEE-resource-response options:{ CPU-core-number: uint .size 1 CPU-frequency: unit .size 2 MEMORY-size: uint .size 4 TOKEN-tee-instance: bstr .size 4 ;this token represents the identity of TEE, it could be a public key of AIK ? Requested-memory-encryption-method: uint .bits memory-encryption-method ? Requested-memory-isolation-method: uint .bits memory-isolation-method } ] secure-channel-negotiation-type= &( direct: 0; indirect: 1; ) tee-secure-channel-resquest = [ type: TEE-secure-channel-request options:{ TOKEN-tee-instance: Secure-channel-negotiation-type: $$negotiation-type } ] $$negotiation-type //= { direct: bool ip-type: bool ;true is ipv4, false is ipv6 } $$negotiation-type //= { indirect: bool Protocol-name => uint .bits protocol-name } $$ipaddr //= ( ipv4: bstr .size 4 ) $$ipaddr //= ( ipv6: bstr .size 16 ) direct-extensions = (uint => any) tee-secure-channel-response-direct = [ type: TEE-secure-channel-response-direct options:{ $$ipaddr port => uint .size 1 *direct-extensions } ] &protocol-name &= ( cose: 0, jwe: 1, others: 2, ) indirect-extentions = (uint => any) tee-secure-channel-response-indirect = [ type: TEE-channel-response-indirect options:{ Protocol-name => uint .bits protocol-name *indirect-extensions } ] ; labels of mapkey for tee dp message parameters, uint (0..15) CPU-core-number = 0 CPU-frequency = 1 MEMORY-size = 2 Requested-memory-encryption-method = 3 Requested-memory-isolation-method = 4 TOKEN-tee-instance = 5 Secure-channel-negotiation-type = 6 direct = 7 indirect = 8 ip-type = 9 Protocol-name = 10 ipaddr = 11 port = 12 direct-extensions = 13 indirect-extensions = 14 ]]>