Re: [Teep] Charter strawman proposal

Does everyone agree that the following would be in scope of the charter?

Because TEE implementations (Intel SGX in particular here) can isolate the code running in the protected enclave from any type of inspection, should the protocol include an **ability** on assurance of the application to be executed?  Sending viruses to run outside of all of the other platform monitoring mechanisms from a compromised application server seems like a great infection vector to me.  (I want to state that I’m thinking that maybe implementations SHOULD offer the user an ability to approve running an isolated app - not a MUST.)  And that the protocol should support that?

I read the strawman charter as including those: (management of trusted applications & security domain management).

--
Chris Inacio
inacio@cert.org<mailto:inacio@cert.org>

From: Nick Cook <nick.cook@intercede.com><mailto:nick.cook@intercede.com>
Date: April 26, 2017 at 9:06:32 AM
To: teep@ietf.org <teep@ietf.org><mailto:teep@ietf.org>
Subject:  Re: [Teep] Charter strawman proposal

I agree that these modifications all make sense. Rather than making a lightweight definition of TEE in the first paragraph I would prefer to call out the GP definition and identify any amendments to that which we are including in our usage of the acronym TEE in the TEEP/OTrP specification. This would clearly be a footnote definition to the charter.

For the security domain part we should expand this to define what we mean by it specifically. I regard the use of security domain in OTrP as a protocol level grouping of a service provider's applications for management purposes and that there *must* be hardware isolation between security domains so that one security domain cannot be influenced by another, unless it exposes an API to allow it. The way that the trusted applications are implemented will be technology specific - again the protocol has requirements here (e.g. each TA to be manageable in its own right and to be able to be personalized) that we need to state but the protocol doesn't dictate the exact implementation.

We don't have the definitions in the draft spec and we will need to add that as we evolve it in the WG.

Nick Cook

-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@arm.com]
Sent: 28 March 2017 23:39
To: Wheeler, David M <david.m.wheeler@intel.com>; teep@ietf.org
Subject: Re: [Teep] Charter strawman proposal

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:david.m.wheeler@intel.com]
Sent: 28 March 2017 14:18
To: Hannes Tschofenig; teep@ietf.org
Subject: RE: Charter strawman proposal

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

--------

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.

[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).

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.

_______________________________________________
TEEP mailing list
TEEP@ietf.org
https://www.ietf.org/mailman/listinfo/teep
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.

_______________________________________________
TEEP mailing list
TEEP@ietf.org
https://www.ietf.org/mailman/listinfo/teep