Re: [Teep] [EXT] Re: [EXT] Re: Charter strawman proposal

[Mingliang Pei <[e-mail]>]

Agreed too. We implicitly assume it is TEE definition by GP in the spec,
and it is good to call this out explicitly, and also Security Domain
definitions. Thanks, Ming

On 4/26/17, 6:15 AM, "TEEP on behalf of Brian Witten"
<[e-mail] on behalf of [e-mail]> wrote:

>+1
>
>> On Apr 26, 2017, at 6:06 AM, Nick Cook <[e-mail]> wrote:
>> 
>> 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:[e-mail]]
>> Sent: 28 March 2017 23:39
>> To: Wheeler, David M <[e-mail]>; [e-mail]
>> 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:[e-mail]]
>> Sent: 28 March 2017 14:18
>> To: Hannes Tschofenig; [e-mail]
>> 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
>> [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teep
>
>_______________________________________________
>TEEP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/teep