Subject: [Teep] Charter strawman proposal

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 28 Mar 2017 18:44:02 +0000

Hi all,

I thought I should put a first draft for the agenda together.

In a nutshell I described the scope of the work without going too far into the details. Then, I particularly point out the desire to support different flavours of TEEs and to focus on a public key-based solution only. Then, I go on describing the two main milestones, namely an architecture document and the actual protocol document. Finally, I believe it is important to mention that we will maintain a close relationship with GlobalPlatform.

The milestones list the expected adoption dates, the dates for submission of publication of these documents to the IESG, and also the plan to participate in Hackathons and to do an interop event.

What do others think?

Ciao
Hannes

--------

TEEP -- A Protocol for Dynamic Trusted Execution Environment Enablement Charter

The Trusted Execution Environment (TEE) is a secure area of the main processor. The TEE, as an isolated execution environment, provides security features, such as isolated execution, integrity of Trusted Applications along with 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. 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 running in the TEE requires a protocol that runs between a client implementation running inside the TEE, a relay application on the rich operating system and a server-side infrastructure maintaining the applications. Since such management tasks are security sensitive where the server side requires information about the device capabilities (in form of attestation), the client-side demands server-side authentication, and privacy considerations have to be taken into account.

This working group aims to develop an application layer protocol providing TEEs with the following functionality,
 * management of trusted applications,
 * attestation, and
 * security domain management (which provides a logical space that contains the service provider's applications).

The solution approach must take a wide range of TEE technologies into account and will focus on the use of public key cryptography.

The group will produce the following deliverables. First, an architecture document describing the involved entities, their relationships, assumptions, the keying framework and relevant use cases. Second, a solution document that describes the above-described functionality. The use of the best possible encoding format 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 GlobalPlatform to ensure proper use of existing TEE-relevant application layer interfaces and other abstractions used by GlobalPlatform-compliant TEE devices.

Milestones

Aug 2017     Submit "TEEP Architecture" document as WG item.

Oct 2017     Submit "TEEP Protocol" document as WG item.

Nov 2017     Participation in the IETF #100 Hackathon to work on the TEEP Protocol.

Dec 2017     Submit "TEEP Architecture" to the IESG for publication as an Informational RFC.

Mar 2017     Organization of an interoperability event at IETF #101.

Apr 2017     Submit "TEEP Protocol" to the IESG for publication as a Proposed Standard.

[1] Wikipedia, 'Trusted execution environment', URL: https://en.wikipedia.org/wiki/Trusted_execution_environment (March 2017).
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Wheeler, David M" <[email-masked]>
Date: Tue, 28 Mar 2017 19:18:06 +0000

Hannes,
Thanks for drafting this. I look forward to great discussions around this topic. I have made some modifications below.

I have made the following types of modifications:
* a protocol is not required in every case, therefore, a protocol may be advantageous to the marketplace (but not a requirement)
	a standard protocol will ease portability, create a level playing field/access for different TEEs, and 
	increase adoption for more secure devices
* a relay application on the rich OS side is not required - what is required is some service access onto the network stack for communications
	It is possible for some TEEs to provide trusted stacks - a service access point must be accessible to protocol entities outside the device
* the server side architecture interacts with the application, but maintenance of the app is optional
* discovery of actual TEE capabilities is important as well

I think security domains is an area for discussion, so I leave that alone. But hope to have more discussions and a better understanding of the requirements around SDs in the future.

It might be useful to discuss other potential standards groups that we should be aligned with, especially in the IoT space.

Thanks,
Dave Wheeler

--------

[It may be advantageous to build the marketplace to have a protocol that supports] programmatically install, update, and delete applications running in the TEE. [ This ] protocol runs between a [trusted service] running [within] the TEE, 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. Since [ some tasks ( such as management tasks) ] are security sensitive where the server side requires information about the device capabilities (in form of attestation), the client-side demands server-side authentication, and privacy considerations have to be taken into account.

This working group aims to develop an application layer protocol providing TEEs with the following functionality,
 * discovery of TEE capabilities
 * management of trusted applications,
 * attestation, and
 * security domain management (which provides a logical space that contains the service provider's applications).

Milestones

_______________________________________________
TEEP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teep

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 28 Mar 2017 22:39:26 +0000

Thanks, David. Those are indeed useful suggestions. Your presentation today at the BOF also clarified some of these points and now make much more sense to me.

Let me try to incorporate your suggestions to see how well the text reads and whether it makes sense to others.

Ciao
Hannes

-----Original Message-----
From: Wheeler, David M [mailto:[email-masked]]
Sent: 28 March 2017 14:18
To: Hannes Tschofenig; [email-masked]
Subject: RE: Charter strawman proposal

Hannes,

Thanks,
Dave Wheeler

--------

Milestones

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 31 Mar 2017 09:35:22 -0500

>  * security domain management (which provides a logical space that contains the service provider's applications).

Hannes and Dave,

The above list of proposed work items is useful. I wish we could have 
discussed it a bit at the BoF.

Questions that come to mind is which of the above would be protocols and 
which would be data models, and then a feel for the gaps in these areas 
relative to currently existing mechanisms and standards.

For example, I assume there are protocols and data models to manage 
applications on the devices. Do we need something brand new for the 
trusted applications? Or just some minor extensions?

Is there some gap analysis which can be shared with the list?

Thanks,
    Erik