Trusted Execution Environment Provisioning (teep)
WG | Name | Trusted Execution Environment Provisioning | |
---|---|---|---|
Acronym | teep | ||
Area | Security Area (sec) | ||
State | Active | ||
Charter | charter-ietf-teep-01 Approved | ||
Document dependencies | |||
Additional resources | Issue tracker, Wiki, Zulip Stream | ||
Personnel | Chairs | Nancy Cam-Winget, Tirumaleswar Reddy.K | |
Area Director | Paul Wouters | ||
Mailing list | Address | teep@ietf.org | |
To subscribe | https://www.ietf.org/mailman/listinfo/teep | ||
Archive | https://mailarchive.ietf.org/arch/browse/teep/ | ||
Chat | Room address | https://zulip.ietf.org/#narrow/stream/teep |
Charter for Working Group
The Trusted Execution Environment (TEE) is a secure area of a processor. The TEE provides security features such as isolated execution and integrity of Trusted Applications, along with provisions for maintaining the confidentiality of their assets. In general terms, the TEE offers an execution space that provides a higher level of security than a "rich" operating system and more functionality than a secure element. For example, implementations of the TEE concept have been developed by ARM and Intel, using the TrustZone and the SGX technology, respectively.
To programmatically install, update, and delete applications in a TEE, the Trusted Execution Environment Provisioning protocol runs between a service within the TEE on a given device, a relay application or service access point on the device's network stack and a server-side infrastructure that interacts with and optionally maintains the applications. Some tasks are security sensitive and the server side requires information about the device characteristics in the form of attestation and the device-side may require information about the server.
Privacy considerations have to be taken into account with authentication features and attestation.
This working group aims to develop an a protocol providing TEEs with lifecycle management and security domain management for trusted applications.
A security domain allows a service provider's applications to be isolated so that one security domain cannot be influenced by another domain, unless the domain exposes an API to allow inter-domain interactions.
The solution approach must take a wide range of TEE and relevant technologies into account and will focus on the use of public key cryptography.
The group will produce the following deliverables. The first document is on architecture, describing the involved entities, their relationships, assumptions, the keying framework, and relevant use cases. Second, a solution document that includes the above-described functionality in a protocol will be developed. The choice of encoding format(s) will be decided in the working group. The group may document several attestation technologies considering the different hardware capabilities, performance, privacy, and operational properties.
The group will maintain a close relationship with the IETF SUIT working group, GlobalPlatform, Trusted Computing Group, and other relevant standards groups to ensure interoperability, compatibility, and proper use of existing TEE-relevant application layer interfaces.
Milestones
Date | Milestone | Associated documents |
---|---|---|
Mar 2021 | Progress Solution document to the IESG for publication |
draft-ietf-teep-protocol
|
Nov 2020 | Begin WGLC for Solution document |
draft-ietf-teep-protocol
|
Sep 2020 | Progress HTTP transport for TEEP document to the IESG for publication |
draft-ietf-teep-otrp-over-http
|
Sep 2020 | Progress Architecture document to the IESG for publication |
rfc9397 (was draft-ietf-teep-architecture)
|
Done milestones
Date | Milestone | Associated documents |
---|---|---|
Done | Begin WGLC for Architecture document |
rfc9397 (was draft-ietf-teep-architecture)
|
Done | Adopt a solution document |
draft-ietf-teep-opentrustprotocol
|
Done | Adopt an Architecture document |
rfc9397 (was draft-ietf-teep-architecture)
|