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

[Mingliang Pei <[e-mail]>]

I meant that any amendment too if needed. Thanks, Ming

On 4/26/17, 2:39 PM, "TEEP on behalf of Mingliang Pei"
<[e-mail] on behalf of [e-mail]> wrote:

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