Skip to main content

TEEP Usecase for Confidential Computing in Network
draft-ietf-teep-usecase-for-cc-in-network-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Penglin Yang , Meiling Chen , Li Su , Ting Pang
Last updated 2022-08-28
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-teep-usecase-for-cc-in-network-00
TEEP Working Group                                               P. Yang
Internet-Draft                                                   M. Chen
Intended status: Informational                                     L. Su
Expires: 2 March 2023                                       China Mobile
                                                                 T. Pang
                                              Huawei Technology Co.,Ltd.
                                                          29 August 2022

           TEEP Usecase for Confidential Computing in Network
              draft-ietf-teep-usecase-for-cc-in-network-00

Abstract

   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 application and process data in that
   environment.  When confidential computing is used in network like MEC
   and CAN which provide computing resource to network users, TEEP
   protocol could be used to provision network user's data and
   application in TEE environment in confidential computing resource.
   This document focuses on using TEEP to provision network user's data
   and application in confidential computing in such network.  This
   document is a use case and extension of TEEP and could provide
   guidance for MEC, CAN and other scenarios to use confidential
   computing.

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 2 March 2023.

Yang, et al.              Expires 2 March 2023                  [Page 1]
Internet-Draft       teep usecase for CC in network          August 2022

Copyright Notice

   Copyright (c) 2022 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Notional Architecture of using confidential computing in
           network . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Usecases  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  UA, TA and PD are bundled as a package  . . . . . . . . .   5
     4.2.  PD is a separate package, TA and UA are separate or
           integrated  . . . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  TA and PD are bundled as a package, and UA is a separate
           package . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.4.  TA and PD as a package, no UA . . . . . . . . . . . . . .   8
     4.5.  TA and PD are separate packages, no UA  . . . . . . . . .   9
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Normative Reference . . . . . . . . . . . . . . . . . . .  10
     5.2.  Informative Reference . . . . . . . . . . . . . . . . . .  10
   Appendix A.  Submodules in TEEP Agent . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   The Confidential Computing Consortium defined the concept of
   confidential computing as the protection of data in use by performing
   computation in a hardware-based Trusted Execution Environment"
   [CCC-White-Paper].  In detail, CPU with confidential computing
   feature could generate an isolated hardware-protected area, in which
   data and applications will be protected from illegal access or
   tampering.

Yang, et al.              Expires 2 March 2023                  [Page 2]
Internet-Draft       teep usecase for CC in network          August 2022

   In the scenario of confidential computing in network, network users
   will attest the TEE in confidential computing and provision private
   data and applications to that TEE by network.  This network could be
   a MEC[MEC], CAN or other network that provide computing resource to
   users.

   TEEP architecture [I-D.ietf-teep-architecture] defined the design and
   standardization of a protocol for managing the lifecycle of trusted
   applications running inside a TEE.  In confidential computing, this
   TEE can also be provisioned and managed by TEEP protocol.

   This document illustrates how a network user uses the TEEP protocol
   to provision its private data in confidential computing resource.
   The intended audiences for this use case are network users and
   operators who are interested in using confidential computing in
   network.

2.  Terminology

2.1.  Terms

   TA: Trusted Application

   UA: Untrusted Application

   PD: Personalization Data

2.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Notional Architecture of using confidential computing in network

   As shown in figure 1 is the architecture of using confidential
   computing in network.  Two new components Network User and Network M/
   OC are introduced in this document.  Interactions of all components
   in this scenario are described in the following paragraphs.

Yang, et al.              Expires 2 March 2023                  [Page 3]
Internet-Draft       teep usecase for CC in network          August 2022

          +--------------------------------------+
          | Confidential Computing Resource      |
          |                       +--------+     |
          |  +-------------+      |        |     |   +------------+
          |  | TEE         |      | TEEP   |     |   | +-------+  |
          |  | +--------+  |  +---> Broker <----------->       |  |
          |  | | TEEP   |  |  |   |        |     |   | |  TAM  |  |
          |  | | Agent  |<----+   |        |     |   | |       |  |
          |  | +--------+  |      |        <--+  |   | +---^---+  |
          |  |             |      +--------+  |  |   +-----|------+
          |  | +--------+  |                  |  |         |
          |  | |   TA   |  |      +-------+   |  |         |
          |  | |        |<-------->       |<--+  |         |
          |  | +--------+  |      |  UA   |      |   +-----V------+
          |  +-------------+      |       |<---------> Data Owner |
          |                       +-------+      |   +------------+
          +--------------------------------------+

    Figure 1: notional architecture of confidential computing in network

   *  Network user possesses private data and application that need to
      be deployed in confidential computing resource.  For example in
      MEC, the autonomous vehicles could deploy private application and
      data to confidential computing resource to calculate on-vehicle
      and destination road information without knowing by MEC platform.

   *  Network Management/Orchestration Center exists in the management
      and orchestration layer of network.  Network user will use the M/
      OC to request for computing resource.  The TAM is inside the M/OC
      to provide management function to TEEP agent via TEEP broker.

   *  Confidential Computing Resource is composed by confidential
      computing devices that connected by the network and can provide
      service to network user.

   *  Package which will be mentioned in the following Usecases section
      is a unit that is signed or encrypted by Data Owner and could be
      deployed in TEE/REE or treated as application data.  TA (Trusted
      Application) in confidential computing could be an application, or
      packaged with other components like library, TEE shim or even
      Guest OS.  The specific package of confidential computing
      application could refers to the wihte paper of common terminology
      of CCC(reference needed).

   The connection between network user and M/OC depends on the
   implementation of specific network.  The connection between network
   user and UA (Untrusted Application) or TA depends on the

Yang, et al.              Expires 2 March 2023                  [Page 4]
Internet-Draft       teep usecase for CC in network          August 2022

   implementation of application.  The connection between TAM, TEEP
   Broker and TEEP Agent refers to the TEEP protocol
   [I-D.ietf-teep-protocol].

4.  Usecases

   The basic process of how a network user uses confidential computing
   is shown below.  In confidential computing, the bundle of an UA, TA,
   and PD (Personalization Data) refers to case 1,2,3,4 of TEEP
   architecture section 4.4.  Case 5 and 6 are new cases that possible
   in implementation.  At present, the main instances types exist in
   industry of confidential computing are confidential
   process,confidential container and confidential VM.

4.1.  UA, TA and PD are bundled as a package

   This use case refers to the case 1 of TEEP architecture.  If the
   network user provides this package, the process of TEEP is as follow.
   Whenever PD is involved in a package, this package must be encrypted,
   similarly hereinafter.

   1.  Network user requests for confidential computing resource to the
       network M/OC.

   2.  TAM in M/OC orchestrates confidential computing device to
       undertake the request.

   3.  TAM requests remote attestation to the TEEP Agent, TEEP Agent
       then response the evidence to TAM.  The TAM works as the relying
       party and forward the attestation result to network user.

   4.  After verification, the network user transfers the package to TAM
       and let TAM to transfer the package to TEEP Agent.

   5.  Network user establishes secure channel with TEEP agent via TAM,
       and transfers decryption key to TEEP Agent.

   6.  TEEP Agent deploys TA and personalization data, then deploy UA in
       REE via TEEP Broker.

   As for inform network users to develop their applications, the
   mapping of UA, TA and implementations are shown in figure 2.  This
   document gathers the main hardware architectures that support
   confidential computing, which include TrustZone, SGX, SEV, CCA and
   TDX.

   The brace means the operation steps to deploy packages.  The arrow
   means deploy package to a destination.

Yang, et al.              Expires 2 March 2023                  [Page 5]
Internet-Draft       teep usecase for CC in network          August 2022

    +-------------+--------------------------------------------------+
    |Package Mode |                Case 1 (UA, TA, PD)               |
    +-------------+----------------+----------------+----------------+
    |  Instance   |   Process in   |  Container in  |                |
    |    Type     |   Physical or  |  Physical or   |       VM       |
    |             | Virtual Machine| Virtual Machine|                |
    +-------------+----------------+----------------+----------------+
    |  Hardware   |    TrustZone   |    TrustZone,  |   SEV,CCA,TDX  |
    | Architecture|                |  SEV, CCA, TDX |                |
    +-------------+----------------+----------------+----------------+
    |             |{att TEEP Agent,|{att TEEP Agent,|{att TEEP Agent,|
    |    Load     |    TA->TEE,    |  TA->Trsuted   | TA->Trsuted VM |
    |  Sequence   |    PD->TA,     |   Container,   |     PD->TA,    |
    |             |    UA->REE}    |    PD->TA,     | UA->Untrusted  |
    |             |                |    UA->REE}    |       VM}      |
    +-------------+----------------+----------------+----------------+

                  Figure 2: TEEP Implementation of Case 1

4.2.  PD is a separate package, TA and UA are separate or integrated

   This usecase refers to the case 2 and case 3 of TEEP architecture.
   The PD is a separate package, the UA and TA could be separated or
   integrated as a package.  If the network user provides packages like
   this, the process of TEEP is as follow.

   1.  Network user requests for confidential computing resource to the
       network M/OC.

   2.  TAM in M/OC orchestrates confidential computing device to
       undertake the request.

   3.  Network user transfers UA and TA to confidential computing
       resource via TAM.  TAM then deploys these two applications in REE
       and TEE respectively.  (In SGX, UA must be deployed first, then
       let the UA to deploy TA in SGX.)

   4.  TAM requests remote attestation to the TEEP Agent, TEEP Agent
       then response the evidence to TAM.  The TAM works as the relying
       party and forward the attestation result to network user.

   5.  Network user establishes secure channel with TA (via UA or via
       TAM or directly), and deploys personalization data to the TA.

   The mapping of UA, TA and implementations are shown in figure 3.

Yang, et al.              Expires 2 March 2023                  [Page 6]
Internet-Draft       teep usecase for CC in network          August 2022

    +-------------+--------------------------------------------------+
    |Package Mode |   Case 2 (UA, TA) (PD), Case 3 (UA) (TA) (PD)    |
    +-------------+----------------+----------------+----------------+
    |  Instance   |   Process in   |  Container in  |                |
    |    Type     |   Physical or  |  Physical or   |       VM       |
    |             | Virtual Machine| Virtual Machine|                |
    +-------------+----------------+----------------+----------------+
    |  Hardware   |    TrustZone,  | TrustZone, SGX,|   SEV,CCA,TDX  |
    | Architecture|      SGX       |  SEV, CCA, TDX |                |
    +-------------+----------------+----------------+----------------+
    |             |   {TA->TEE,    |    {UA->REE,   |{UA->untrusted  |
    |             | att TEEP Agent,|  TA->trusted   |      VM,       |
    |    Load     |     PD->TA,    |   Container,   | TA->trusted VM,|
    |  Sequence   |    UA->REE}    | att TEEP Agent,| att TEEP Agent,|
    |             |                |    PD->TA}     |     PD->TA}    |
    +-------------+----------------+----------------+----------------+

                 Figure 3: TEEP Implementation of Case 2/3

4.3.  TA and PD are bundled as a package, and UA is a separate package

   In this case, the process of TEEP is as follow.

   1.  Network user requests for confidential computing resource to the
       network M/OC.

   2.  TAM in M/OC orchestrates confidential computing device to
       undertake the request.

   3.  Network user transfers UA to TAM.

   4.  TAM requests remote attestation to the TEEP Agent, TEEP Agent
       then response the evidence to TAM.  The TAM works as the relying
       party and forward the attestation result to network user.

   5.  Network user transfers encrypted TA and PD to TAM.  Then TAM
       transfers this package to TEEP Agent.  Network user creates
       secure channel with TEEP agent (via TAM) and transfers the
       decryption key to TEEP agent.

   6.  TEEP agent decrypts this package and deploys TA and PD.

Yang, et al.              Expires 2 March 2023                  [Page 7]
Internet-Draft       teep usecase for CC in network          August 2022

    +-------------+--------------------------------------------------+
    |Package Mode |               Case 4 (TA, PD) (UA)               |
    +-------------+----------------+----------------+----------------+
    |  Instance   |   Process in   |  Container in  |                |
    |    Type     |   Physical or  |  Physical or   |       VM       |
    |             | Virtual Machine| Virtual Machine|                |
    +-------------+----------------+----------------+----------------+
    |  Hardware   |    TrustZone,  | TrustZone, SGX,|   SEV,CCA,TDX  |
    | Architecture|      SGX       |  SEV, CCA, TDX |                |
    +-------------+----------------+----------------+----------------+
    |             |   {UA->REE,    |    {UA->REE,   | {UA->untrusted |
    |    Load     | att TEEP Agent,| att TEEP Agent,|      VM,       |
    |  Sequence   |   TA&PD->TEE}  | TA&PD->trusted | att TEEP Agent,|
    |             |                |   Container}   | TA->trusted VM}|
    +-------------+----------------+----------------+----------------+

                  Figure 4: TEEP Implementation of Case 4

4.4.  TA and PD as a package, no UA

   In this case, network user provides TA and PD as a package with no UA
   attached.  The process of TEEP in this case is as follow.

   1.  Network user requests for confidential computing resource to the
       network M/OC.

   2.  TAM in M/OC orchestrates confidential computing device to
       undertake the request.

   3.  TAM requests remote attestation to the TEEP Agent, TEEP Agent
       then response the evidence to TAM.  The TAM works as the relying
       party and forward the attestation result to network user.

   4.  Network user transfers this package to TAM, and the TAM transfers
       this package to TEEP agent.

   5.  Network user establishes secure channel with TEEP agent (via TAM)
       and transfers decryption key to TEEP agent.

   6.  TEEP Agent decrypts this package and deploys TA and PD.

Yang, et al.              Expires 2 March 2023                  [Page 8]
Internet-Draft       teep usecase for CC in network          August 2022

    +-------------+--------------------------------------------------+
    |Package Mode |                 Case 5 (TA, PD)                  |
    +-------------+----------------+----------------+----------------+
    |  Instance   |   Process in   |  Container in  |                |
    |    Type     |   Physical or  |  Physical or   |       VM       |
    |             | Virtual Machine| Virtual Machine|                |
    +-------------+----------------+----------------+----------------+
    |  Hardware   |    TrustZone,  | TrustZone, SGX,|   SEV,CCA,TDX  |
    | Architecture|      SGX       |  SEV, CCA, TDX |                |
    +-------------+----------------+----------------+----------------+
    |    Load     |{att TEEP Agent,|{att TEEP Agent,|{att TEEP Agent,|
    |  Sequence   |   TA&PD->TEE}  | TA&PD->trusted | TA->trusted VM}|
    |             |                |   Container}   |                |
    +-------------+----------------+----------------+----------------+

                  Figure 5: TEEP Implementation of Case 5

4.5.  TA and PD are separate packages, no UA

   In this case, network user provides TA and PD as separate packages
   with no UA attached.  The process of TEEP in this case is as follow.

   1.  Network user requests for confidential computing resource to the
       network M/OC.

   2.  TAM in M/OC orchestrates confidential computing device to
       undertake the request.

   3.  Network user transfer TA to TAM, and TAM deploys this TA to TEE
       through TEEP Agent.

   4.  TAM requests remote attestation to the TEEP Agent, TEEP Agent
       then response the evidence to TAM.  The TAM works as the relying
       party and forward the attestation result to network user.

   5.  Network user establishes secure channel with TA (directly or via
       TAM) and transfers PD to it.

Yang, et al.              Expires 2 March 2023                  [Page 9]
Internet-Draft       teep usecase for CC in network          August 2022

    +-------------+--------------------------------------------------+
    |Package Mode |                 Case 6 (TA), (PD)                |
    +-------------+----------------+----------------+----------------+
    |  Instance   |   Process in   |  Container in  |                |
    |    Type     |   Physical or  |  Physical or   |       VM       |
    |             | Virtual Machine| Virtual Machine|                |
    +-------------+----------------+----------------+----------------+
    |  Hardware   |    TrustZone,  | TrustZone, SGX,|   SEV,CCA,TDX  |
    | Architecture|      SGX       |  SEV, CCA, TDX |                |
    +-------------+----------------+----------------+----------------+
    |    Load     |    {TA->TEE,   | {TA->trusted   |{TA->trusted VM,|
    |  Sequence   | att TEEP Agent,|   Container,   | att TEEP Agent,|
    |             |     PD->TA}    | att TEEP Agent,|     PD->TA}    |
    |             |                |    PD->TA}     |                |
    +-------------+----------------+----------------+----------------+

                  Figure 6: TEEP Implementation of Case 6

5.  References

5.1.  Normative Reference

   [I-D.ietf-teep-architecture]
              Pei, M., Tschofenig, H., Thaler, D., and D. Wheeler,
              "Trusted Execution Environment Provisioning (TEEP)
              Architecture", Work in Progress, Internet-Draft, draft-
              ietf-teep-architecture-18, 11 July 2022,
              <https://datatracker.ietf.org/api/v1/doc/document/draft-
              ietf-teep-architecture/>.

   [I-D.ietf-teep-protocol]
              Tschofenig, H., Pei, M., Wheeler, D., Thaler, D., and A.
              Tsukamoto, "Trusted Execution Environment Provisioning
              (TEEP) Protocol", Work in Progress, Internet-Draft, draft-
              ietf-teep-protocol-10, 28 July 2022,
              <https://datatracker.ietf.org/api/v1/doc/document/draft-
              ietf-teep-protocol/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

5.2.  Informative Reference

Yang, et al.              Expires 2 March 2023                 [Page 10]
Internet-Draft       teep usecase for CC in network          August 2022

   [CCC-White-Paper]
              Confidential Computing Consortium, "Confidential
              Computing: Hardware-Based Trusted Execution for
              Applications and Data", January 2021,
              <https://confidentialcomputing.io/white-papers-reports/>.

   [MEC]      ETSI, "Multi-access Edge Computing (MEC);Framework and
              Reference Architecture", March 2022,
              <https://www.etsi.org/deliver/etsi_gs/
              MEC/001_099/003/03.01.01_60/gs_MEC003v030101p.pdf>.

   [SGX]      Intel, "Overview of Intel Software Guard Extension", June
              2016,
              <https://www.intel.com/content/www/us/en/developer/tools/
              software-guard-extensions/overview.html>.

Appendix A.  Submodules in TEEP Agent

   The original design of TEEP only includes TEEP Agent and TA inside
   TEE.  While in confidential computing implementation, other
   submodules may also be involved in the TEE.  In TEEP, these
   submodules could be covered by TEEP Agent.

   In SGX based confidential computing, submodule could provide
   convenient environment or API in which TA does not have to modify its
   source code to fit into SGX instructions.  Submodules like Gramine
   and Occlum .etc are examples that could be included in TEEP agent.
   If there is no submodule in TEEP agent, the TA and UA need to be
   customized applications which fit into the SGX architecture.

   In SEV and other architectures that support whole guest VM as a TEE,
   TEEP agent doesn't have to use extra submodule to work as a
   middleware or API.  However with some submodules like Enarx which
   works as a runtime JIT compiler, TA could be deployed in a hardware
   independent way.  In this scenario, TA could be deployed in different
   hardware architecture without re-compiling.

Authors' Addresses

   Penglin Yang
   China Mobile
   32 Xuanwumen West Street, Xicheng District
   Beijing
   100053
   China
   Email: yangpenglin@chinamobile.com

Yang, et al.              Expires 2 March 2023                 [Page 11]
Internet-Draft       teep usecase for CC in network          August 2022

   Meiling Chen
   China Mobile
   32 Xuanwumen West Street, Xicheng District
   Beijing
   100053
   China
   Email: chenmeiling@chinamobile.com

   Li Su
   China Mobile
   32 Xuanwumen West Street, Xicheng District
   Beijing
   100053
   China
   Email: suli@chinamobile.com

   Ting Pang
   Huawei Technology Co.,Ltd.
   127 Jinye Road, Yanta District
   Xi'an
   710077
   China
   Email: pangting@huawei.com

Yang, et al.              Expires 2 March 2023                 [Page 12]