Internet DRAFT - draft-ietf-teep-usecase-for-cc-in-network
draft-ietf-teep-usecase-for-cc-in-network
TEEP P. Yang
Internet-Draft M. Chen
Intended status: Informational L. Su
Expires: 19 October 2023 China Mobile
T. Pang
Huawei Technology Co.,Ltd.
17 April 2023
TEEP Usecase for Confidential Computing in Network
draft-ietf-teep-usecase-for-cc-in-network-03
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 applications and process data in that
environment. When confidential computing is used in scenarios which
need network to provision user 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 User data and applications
in confidential computing. This document is a use case and extension
of TEEP and could provide guidance for cloud computing, [MEC] and
other scenarios to use confidential computing in network.
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 19 October 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Yang, et al. Expires 19 October 2023 [Page 1]
Internet-Draft teep usecase for CC in network April 2023
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. Requirement Language . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. TA and PD as a package, no UA . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Appendix 1 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, computing unit with confidential
computing feature could generate an isolated hardware-protected area,
in which data and applications will be protected from illegal access
or tampering. When using network to provision confidential computing
environment, users need to attest and deploy their data and
applications in the TEE environment inside confidential computing
device by network. This network could be a cloud, MEC or other
network that provide confidential computing resource to users. The
TEEP WG defined the standardization of an architecture and protocol
for managing the lifecycle of trusted applications running inside a
TEE. In confidential computing, the TEE can also be provisioned and
managed by TEEP architecture and protocol. This document illustrates
how a network user uses the TEEP protocol to provision its private
Yang, et al. Expires 19 October 2023 [Page 2]
Internet-Draft teep usecase for CC in network April 2023
data and applications in confidential computing device. The intended
audiences for this use case are network users and operators who are
interested in using confidential computing in network.
2. Terminology
## Terms
* Network Management/Orchestration Center(Network M/OC): MO/C exists
in the management and orchestration layer of network. Network
User uses 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.
* Network User: Network User possesses personalization data and
applications that need to be deployed on confidential computing
device. For example in MEC, the autonomous vehicles could deploy
private applications and data on confidential computing device to
calculate on-vehicle and destination road information without
knowing by MEC platform.
* Confidential Computing Device: Confidential Computing Device is
connected by the network and can provide confidential computing
service to Network User.
* Package: Package is a unit that is owned by Network User and could
be deployed on 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 could refers to the white paper of
[CCC_Common_Terminology] by CCC.
* Personalization Data(PD): Data that holds by Network User and
needs to be protected by TEE during processing. Other terms like
TAM, TEE, REE, TA will reuse the term definition defined in
[I-D.ietf-teep-architecture].
2.1. Requirement 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 [RFC2119].
Yang, et al. Expires 19 October 2023 [Page 3]
Internet-Draft teep usecase for CC in network April 2023
3. Architecture
Figure 1 is the architecture of confidential computing in network.
Two new components Network User and Network M/OC are introduced in
this document. 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
implementation of application. The connection between TAM, TEEP
Broker and TEEP Agent refers to the TEEP protocol. Interactions of
all components in this scenario are described in the Usecase section.
+--------------------------------------+
| Confidential Computing Device |
| +--------+ | +------------+
| +-------------+ | | | |Network M/OC|
| | TEE | | TEEP | | | +-------+ |
| | +--------+ | +---> Broker <-----------> | |
| | | TEEP | | | | | | | | TAM | |
| | | Agent |<----+ | | | | | | |
| | +--------+ | | <--+ | | +---^---+ |
| | | +--------+ | | +-----|------+
| | +--------+ | | | |
| | | TA | | +-------+ | | |
| | | |<--------> |<--+ | |
| | +--------+ | | UA | | +-----V------+
| +-------------+ | |<--------->Network User|
| +-------+ | | (Package) |
+--------------------------------------+ +------------+
Figure 1: Notional Architecture of Confidential Computing in Network
4. Use Cases
The basic process of how a Network User utilizes confidential
computing is shown below. In confidential computing, the bundle of
an UA, TA, and PD 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.
Yang, et al. Expires 19 October 2023 [Page 4]
Internet-Draft teep usecase for CC in network April 2023
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.
1. Network User requests for confidential computing resource to the
network M/OC. 2. M/OC orchestrates confidential computing device to
undertake the request. 3. TAM requests remote attestation to the
TEEP Agent, TEEP Agent then sends the evidence to TAM. The TAM works
as Verifier in [RFC9334]. 4. After verification, Network User works
as Relying Party to receive the attestation result. If positive,
Network User establishes secure channel
[NIST-Special-Publication-800-133-V2] with TEEP Agent, and transfers
this package to TEEP Agent. 5. TEEP Agent deploys TA and
personalization data in TEE, then deploy UA in REE. As for informing
Network Users to develop their applications and data, 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-SNP], [CCA] and
[TDX]. The brace means the operation steps to deploy packages. The
arrow means deploy package to a destination. The "att" means
attestation challenge for the target.
+-------------+--------------------------------------------------+
|Package Mode | Case 1 (UA, TA, PD) |
+-------------+----------------+----------------+----------------+
| Instance | Process in | Container in | |
| Type | Physical or | Physical or | VM |
| | Virtual Machine| Virtual Machine| |
+-------------+----------------+----------------+----------------+
| Hardware | | TrustZone, | |
| Architecture| TrustZone | SEV-SNP, CCA, | SEV-SNP,CCA,TDX|
| | | 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
Yang, et al. Expires 19 October 2023 [Page 5]
Internet-Draft teep usecase for CC in network April 2023
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. M/OC
orchestrates confidential computing device to undertake the request.
3. Network User transfers UA and TA to confidential computing device
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
load TA in SGX.) 4. TAM requests remote attestation to the TEEP
Agent, TEEP Agent then sends the evidence to TAM. The TAM works as
Verifier in RATs architecture. 5. After verification, Network User
works as Relying Party to receive the attestation result. If
positive, Network User establishes secure channel with TA, and
deploys personalization data to the TA. The mapping of UA, TA and
implementations are shown in figure 3.
+-------------+--------------------------------------------------+
|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,| |
| Architecture| SGX | SEV-SNP, CCA, | SEV,CCA,TDX |
| | | 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 deploys UA in REE. 4. TAM requests
remote attestation to the TEEP Agent, TEEP Agent then sends the
evidence to TAM. The TAM works as Verifier in RATs architecture. 5.
After verification, Network User works as Relying Party to receive
Yang, et al. Expires 19 October 2023 [Page 6]
Internet-Draft teep usecase for CC in network April 2023
the attestation result. If positive, the Network User establishes
secure channel with TEEP Agent and transfers the TA and PD package to
TEEP Agent. 6. TEEP Agent deploys TA and PD.
+-------------+--------------------------------------------------+
|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,| |
| Architecture| SGX | SEV-SNP, CCA, | SEV,CCA,TDX |
| | | 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 sends the evidence to TAM. The
TAM works as Verifier in RATs architecture. 4. After
verification,Network User works as Relying Party to receive the
attestation result. If positive, the Network User establishes secure
channel with TEEP Agent and transfers TA and PD to TEEP Agent. 5.
TEEP Agent deploys TA and PD.
Yang, et al. Expires 19 October 2023 [Page 7]
Internet-Draft teep usecase for CC in network April 2023
+-------------+--------------------------------------------------+
|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
## 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 transfers TA to TAM, then TAM transfers TA
to TEEP Agent. 4. TAM requests remote attestation to the TEEP
Agent, TEEP Agent then sends the evidence to TAM. The TAM works as
Verifier in RATs architecture. 5. After verification, Network User
works as Relying Party to receive the attestation result. If
positive, the Network User establishes secure channel with TA and
transfers PD to it.
+-------------+--------------------------------------------------+
|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
Yang, et al. Expires 19 October 2023 [Page 8]
Internet-Draft teep usecase for CC in network April 2023
5. IANA Considerations
This document does not require actions by IANA.
6. Security Considerations
Besides the security considerations in TEEP architecture, there is no
more security and privacy issues in this document.
7. References
7.1. Normative References
[I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Thaler, D., and D. M. Wheeler,
"Trusted Execution Environment Provisioning (TEEP)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-teep-architecture-19, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-teep-
architecture-19>.
[I-D.ietf-teep-protocol]
Tschofenig, H., Pei, M., Wheeler, D. M., Thaler, D., and
A. Tsukamoto, "Trusted Execution Environment Provisioning
(TEEP) Protocol", Work in Progress, Internet-Draft, draft-
ietf-teep-protocol-12, 13 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teep-
protocol-12>.
[NIST-Special-Publication-800-133-V2]
Davis, E. B. A. R. R., "Recommendation for Cryptographic
Key Generation", June 2020,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-133r2.pdf>.
[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/rfc/rfc2119>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
7.2. Informative References
Yang, et al. Expires 19 October 2023 [Page 9]
Internet-Draft teep usecase for CC in network April 2023
[CCA] ARM, "ARM Confidential Computing Architecture", March
2022, <https://www.arm.com/architecture/security-features/
arm-confidential-compute-architecture>.
[CCC-White-Paper]
Consortium, C. C., "Confidential Computing Hardware-Based
Trusted Execution for Applications and Data", January
2021,
<https://confidentialcomputing.io/white-papers-reports/>.
[CCC_Common_Terminology]
Consortium, C. C., "Common Terminology for Confidential
Computing", October 2022,
<https://github.com/confidentialcomputing/governance/blob/
main/terminology/commonterminology.md>.
[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>.
[SEV-SNP] Devices, A. M., "AMD SEV-SNP Strengthening VM-isolation-
with-integrity-protection-and-more", January 2020,
<https://www.amd.com/system/files/TechDocs/SEV-SNP-
strengthening-vm-isolation-with-integrity-protection-and-
more.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>.
[TDX] Intel, "Intel Trust Domain Extensions", August 2021,
<https://www.intel.com/content/www/us/en/developer/
articles/technical/intel-trust-domain-extensions.html>.
[TrustZone]
Technologies, H., "Kunpeng BoostKit for Confidential
Computing TrustZone Kit", January 2022,
<https://www.hikunpeng.com/document/detail/en/
kunpengcctrustzone/overview/kunpengcctrustzone.html>.
Yang, et al. Expires 19 October 2023 [Page 10]
Internet-Draft teep usecase for CC in network April 2023
Appendix A. Appendix 1 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
No.32 Xuanwumen West Street
Beijing
China
Email: yangpenglin@chinamobile.com
Meiling Chen
China Mobile
No.32 Xuanwumen West Street
Beijing
China
Email: chenmeiling@chinamobile.com
Li Su
China Mobile
No.32 Xuanwumen West Street
Beijing
China
Email: suli@chinamobile.com
Yang, et al. Expires 19 October 2023 [Page 11]
Internet-Draft teep usecase for CC in network April 2023
Ting Pang
Huawei Technology Co.,Ltd.
127 Jinye Road, Yanta District
Xi'an
China
Email: pangting@huawei.com
Yang, et al. Expires 19 October 2023 [Page 12]
