TEE Distributed Provisioning Relay

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 8 January 2024.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

In big data area, different from stand-alone application, distributed application like machine learning always need to be split by Master-Worker framework like MESOS[MESOS], YARM[YARN], Spark[Spark] or kubernets[Kubernetes] . The Master node in charges of splitting distributed application to computing tasks. Then these tasks will be deployed on Workers for execution. TEE could be used to protect the application and its secret data, if only the whole process lifecycle is covered by TEE cluster. If a Verifier or Relying Party would like to attest distributed application running in TEE cluster, it has to verify the Worker nodes since the Worker nodes are the real place in where specific tasks and data are processing. The Master node conducts the splitting process and provision specific tasks or executable code to Workers after running the main part of application. Master node could relay these tasks or executable code information to Verifier or Relying party for remote attestation. As a result, Verifier or Relying Party could assess the trustworthiness of the lifecycle of distributed application in TEE cluster. This document specifies the method and protocol of this distributed TEE provision relay.¶

2. Terminology

The following terms are used:¶

• Master: The node that runs the main application and in charges of splitting and distributing tasks to Worker nodes.¶
• Worker: The node that runs the specific tasks that generated by Master.¶
• Relay: Master transfer the original provision message to Verifier/Relying party for remote attestation.¶

3. Use Cases

In privacy-preserve computing, participants want to create a unified machine learning model without leaking private data owned by each other. TEE cluster as a trusted party could make sure data inside this environment is integrated and confidential. If the federated machine learning participants trust this TEE cluster and application, they could transfer their data in that TEE cluster and generate the final machine learning model. The method and protocol described in this document could help privacy-preserve computing participants to process remote attestation of TEE cluster during runtime.¶

4. Architecture

The following figure shows the architecture of TEE distributed provisioning relay. In this architecture, Master runs the main part of distributed application, which will generate tasks or executable code and provision to Workers. Master accepts remote attestation challenge from Verifier and response Evidence of Master. Then, Master relay provisioning information of Workers to Verifier/Relying Party. In the end, Evidence of Workers will be transfered to Verifier/Relying Party by Master. The security or trust logic of this architecture is to build a trust chain between Master and Workers, in which the Verifier/Relying party could trust the Master first and let the Master to relay the provisioning information of Workers to Verifier/Relying Party.¶

                      +-------------+
                      |  Verifier/  |
                      |Relying Party|
                      +-------------+
                            ^
   1. Remote attestation    | 2. Return Evidence of Master
      of Master             | 4. Relay Worker runtime provisioning
                            v 6. Return Evidence of Workers
                +-----------------------+
                |Master/Main application|
                +-----------------------+
   3. Generate tasks &      ^ 5. Remote attestation of Workers
   distribute to Workers    |
       ---------------------+----------------------
       |                    |                     |
       v                    v                     v
   +--------+           +--------+            +--------+
   | Worker |           | Worker |            | Worker |
   +--------+           +--------+            +--------+

The steps of TEE distributed provisioning relay is described below.¶

- Verifier/Relying party sends challenge to Master and tries to assess the trustworthiness of this distributed application runs in TEE cluster.¶

- Master generates Evidence of itself and return to Verifier/Relying Party.¶

- Master generates tasks and provisions to Workers.¶

- Meanwhile, Master transfer the tasks provisioning information and Worker information back to Verifier/Relying Party to generate reference value of Workers.¶

- Master challenges Worker for Evidence.¶

- Master sends the Evidence of Workers back to Verifier/Relying Party for attestation.¶

5. Worker Runtime Provisioning Relay

Worker runtime provisioning relay message is sent from Master to Verifier/Relying Party. It's function is to provide Verifier/Relying Party information to generate reference value of Workers. This message can only be sent after remote attestation of Master.¶

tee-dpr-message = $tee-dpr-message-type .within
tee-dpr-message-framework
tee-dpr-message-framework = [
    type: $tee-dpr-type,
    optionis: { * tee-dpr-option}
]
tee-dpr-option = (uint =>any)
$tee-dpr-message-type /= tee-task-serialized
$tee-dpr-message-type /= tee-worker-hardware-manifest
$tee-dpr-message-type /= tee-worker-software-manifest

$tee-dpr-type = uint .size 1
TEE-task-serialized = 1
TEE-worker-hardware-manifest = 2
TEE-worker-software-manifest = 3

tee-task-serialized = [
    type: TEE-task-serialized
    options:{
        Recommended-serialized-type: uint .bits serialized-type
        serialized-payload = bstr
    }
]
serialized-type = &(
    json: 0
    protobuf: 1
    thrift: 2
    pre-defined: 3
)

tee-worker-hardware-manifest = [
    type: TEE-worker-hardware-manifest
    options:{
        CPU-core-number: uint .size 1
        CPU-architecture: text .size(1..128)
        CPU-version: text .size(1..128)
        CPU-frequency: unit .size 2
        ;the cpu frequency unit is MHZ
        MEMORY-size: uint .size 4
        ;the memory size unit is MB
    }
]

tee-worker-software-manifest = [
    type: TEE-worker-software-manifest
    options:{
        os-version: text .size(1..128)
        memory-allocation: text .size(1..128)
        sadr: bool
        canary: bool
        worker-executor-version: text .size(1..128)
        time-stamp: text .size(1..128)
    }
]

6. Security Considerations

This protocol is used to relay Worker TEE provisioning message between Master and Verifier, between which secure channel could be built by TLS and etc. The secure channel between Worker and Verifier could also use TLS or other secure protocol to protect provisioning message.¶

7. IANA Considerations

This document does not require actions by IANA.¶

Appendix A. Appendix 1 Full CDDL of TEE DP protocol

The full CDDL of TEE distributed provisioning protocol is shown below.¶

tee-dpr-message = $tee-dpr-message-type .within
tee-dpr-message-framework
tee-dpr-message-framework = [
    type: $tee-dpr-type,
    optionis: { * tee-dpr-option}
]
tee-dpr-option = (uint =>any)
$tee-dpr-message-type /= tee-task-serialized
$tee-dpr-message-type /= tee-worker-hardware-manifest
$tee-dpr-message-type /= tee-worker-software-manifest

$tee-dpr-type = uint .size 1
TEE-task-serialized = 1
TEE-worker-hardware-manifest = 2
TEE-worker-software-manifest = 3

tee-task-serialized = [
    type: TEE-task-serialized
    options:{
        Recommended-serialized-type: uint .bits serialized-type
        Serialized-payload = bstr
    }
]
serialized-type = &(
    json: 0
    protobuf: 1
    thrift: 2
    pre-defined: 3
)

tee-worker-hardware-manifest = [
    type: TEE-worker-hardware-manifest
    options:{
        CPU-core-number: uint .size 1
        CPU-architecture: text .size(1..128)
        CPU-version: text .size(1..128)
        CPU-frequency: unit .size 2
        ;the cpu frequency unit is MHZ
        MEMORY-size: uint .size 4
        ;the memory size unit is MB
    }
]

tee-worker-software-manifest = [
    type: TEE-worker-software-manifest
    options:{
        OS-version: text .size(1..128)
        Memory-allocation: text .size(1..128)
        Sadr: bool
        Canary: bool
        Worker-executor-version: text .size(1..128)
        Time-stamp: text .size(1..128)
    }
]
; labels of mapkey for tee dp message parameters, uint (0..15)
Recommended-serialized-type = 0
Serialized-payload = 1
CPU-core-number = 2
CPU-architecture = 3
CPU-version = 4
CPU-frequency = 5
MEMORY-size = 6
OS-version = 7
Memory-allocation = 8
Sadr = 9
Canary = 10
Worker-executor-version = 11
Time-stamp = 12

Authors' Addresses