Subject: [Teep] TEEP update

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Wed, 6 Dec 2017 22:42:06 +0000

Hello TEEP members,

We had strong consensus @IETF100 Singapore that IETF should work on TEE provisioning.  But, it was unclear as to how to better distinguish scope and charter.  We discussed the potential overlap but also complementary work that SUIT and TEEP can pursue as well as the work happening in the Global Platform group.  The notes can be found in the etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-teep

Before we can form the WG, we need to establish our charter so we need to continue discussion over the list.  Based on the f2f meeting, we need to clarify:

-          How should TEEP define its scope so it complements (and coordinates) with SUIT? Proposed split discussed included:

o   TEEP focuses on more on trusted “apps” after boot, whereas SUIT focuses more on “firmware” for boot

o   TEEP focuses on installation of code into a Trusted Execution Environment (whether for IoT or not), whereas SUIT focuses on installation of code on an IoT device (whether in a TEE or not)

o   TEEP focuses more on initial provisioning of code the first time, whereas SUIT focuses more on subsequent updates to already-provisioned code

-          How should TEEP define its scope/charter relative to Global Platform? Discussion included:

o   TEEP focusing only on protocols not API (or only abstract APIs)

Thanks, Dave and Nancy

---

From: Dapeng Liu <[email-masked]>
Date: Thu, 07 Dec 2017 04:59:36 +0000

Hi Nancy,

Thanks for the update.

Please see my comments inline:

On Thu, Dec 7, 2017 at 6:42 AM Nancy Cam-Winget (ncamwing) <
[email-masked]> wrote:

>  Hello TEEP members,
>
>
>
> We had strong consensus @IETF100 Singapore that IETF should work on TEE
> provisioning.  But, it was unclear as to how to better distinguish scope
> and charter.  We discussed the potential overlap but also complementary
> work that SUIT and TEEP can pursue as well as the work happening in the
> Global Platform group.  The notes can be found in the etherpad:
> http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-teep
>
>
>
> Before we can form the WG, we need to establish our charter so we need to
> continue discussion over the list.  Based on the f2f meeting, we need to
> clarify:
>
> -          How should TEEP define its scope so it complements (and
> coordinates) with SUIT? Proposed split discussed included:
>
> o   TEEP focuses on installation of code into a Trusted Execution
> Environment (whether for IoT or not), whereas SUIT focuses on installation
> of code on an IoT device (whether in a TEE or not)
>
> o   TEEP focuses more on initial provisioning of code the first time,
> whereas SUIT focuses more on subsequent updates to already-provisioned code
>
>
>
 [Dapeng] TEEP is not limited to 'provisioning of code the first time', it
can also used to update the TA (trusted application). we may need to revise
the wording here.

Thanks,
Regards,
Dapeng(Max) LIU

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

---

From: "faibish, sorin" <[email-masked]>
Date: Fri, 8 Dec 2017 21:12:01 +0000

This is Sorin. See within [sf].

From: TEEP [mailto:[email-masked]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Wednesday, December 6, 2017 5:42 PM
To: [email-masked]
Subject: [Teep] TEEP update

 Hello TEEP members,

o   TEEP focuses more on initial provisioning of code the first time, whereas SUIT focuses more on subsequent updates to already-provisioned code
[sf] In my opinion we should stick to the initial provisioning such that cheap IoT devices (class I) will support this. It is doubtful if they will support any upgrades/updates that will require higher level OS.

o   TEEP focusing only on protocols not API (or only abstract APIs)
[sf] I will be pretty much unhappy if we will propose an API that is specific to a certain class as GP defined it. The abstract API is more suitable for IETF and allows support for different classes of IoT devices. So, no question in my mind that we need an abstract API.

./Sorin

Thanks, Dave and Nancy

---

From: Mingliang Pei <[email-masked]>
Date: Thu, 21 Dec 2017 19:27:44 +0000

On IETF’s right to continue OTrP spec, after confirming with the original Open Trust Protocol Alliance members who jointly created the original draft, I can share that there is no issue of copyright or continuing the work in IETF.

We created OTrP draft and posted the specification to IETF web site very long before we gave it to Global Platform. OTPA has a joint alliance agreement amendment to keep it live till 12/2018 so that the organization can continue to own and promote OTrP to other SDO. The IETF can work with the RFC drafts that we posted. In the case of Global Platform, OTrP is being restructured from a document point of view to map to TMF. We already have two frameworks.

So at the end of the game, we have two architecture models: Global Platform with TMF/OTrP and IETF with OTrP. Over the time, the IETF version of OTrP will be the closest one to the original OTrP document.

So we can continue to evolve OTrP it in its own for what TEEP considers the necessary and best. IETF can move OTrP in a broader way to address use cases, where some of them are new, that were discussed in the last IETF and potentially additional ones as part of the WG work.

Hope this help.

Happy holidays to all!

Ming

From: TEEP <[email-masked]<mailto:[email-masked]>> on behalf of Dapeng Liu <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, December 6, 2017 at 8:59 PM
To: "Nancy Cam-Winget (ncamwing)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [EXT] Re: [Teep] TEEP update

Hi Nancy,

Thanks for the update.

On Thu, Dec 7, 2017 at 6:42 AM Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>> wrote:
 Hello TEEP members,

We had strong consensus @IETF100 Singapore that IETF should work on TEE provisioning.  But, it was unclear as to how to better distinguish scope and charter.  We discussed the potential overlap but also complementary work that SUIT and TEEP can pursue as well as the work happening in the Global Platform group.  The notes can be found in the etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-100-teep<https://clicktime.symantec.com/a/1/RgzDlCOdTSL0pPNW9H_myvEvfkLBfBTcBqzaDEm2xRw=?d=kIJluwK3h8ZLVt4md8S1Ei9orXBCxs0xJV8blWgZdLggdUEuDPXm9WcDyho6s2Vxswi4sjtOXaJ1YkLIkGo59kM0_kI7P96HM7qzzIRrWZobzlWFwcaqiDZymA-EL7qEIdEPlUzz0pWGzBkoc0VrYeoH_f0XDWVkYeajk1DZb05otgQOB5skSxw8DlmH6f0AnY602wQ4tcNfMiXZNwKVluujJdUqZwzlfSfMQVjXMgQvzusKAdquT0cHEz1euwXWtEyEqtBPvmJ3b8t9fQFb4xU13mWnqGIdSke5Z6qsI9o-Y4WrXHYufIvaAe__yrYsHdqwE0MbS9-v2r0uBGTvldXeb0p5_M4-Ogsdoph33lBHbfBeEr0hLIH0qN32fiomMw%3D%3D&u=http%3A%2F%2Fetherpad.tools.ietf.org%3A9000%2Fp%2Fnotes-ietf-100-teep>

 [Dapeng] TEEP is not limited to 'provisioning of code the first time', it can also used to update the TA (trusted application). we may need to revise the wording here.

Thanks,
Regards,
Dapeng(Max) LIU

Thanks, Dave and Nancy

_______________________________________________
TEEP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teep<https://clicktime.symantec.com/a/1/2KpxylTruarFLdyaOUSK1s2DbBx6nyi1XyGL2RAwsBI=?d=kIJluwK3h8ZLVt4md8S1Ei9orXBCxs0xJV8blWgZdLggdUEuDPXm9WcDyho6s2Vxswi4sjtOXaJ1YkLIkGo59kM0_kI7P96HM7qzzIRrWZobzlWFwcaqiDZymA-EL7qEIdEPlUzz0pWGzBkoc0VrYeoH_f0XDWVkYeajk1DZb05otgQOB5skSxw8DlmH6f0AnY602wQ4tcNfMiXZNwKVluujJdUqZwzlfSfMQVjXMgQvzusKAdquT0cHEz1euwXWtEyEqtBPvmJ3b8t9fQFb4xU13mWnqGIdSke5Z6qsI9o-Y4WrXHYufIvaAe__yrYsHdqwE0MbS9-v2r0uBGTvldXeb0p5_M4-Ogsdoph33lBHbfBeEr0hLIH0qN32fiomMw%3D%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep>

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Fri, 22 Dec 2017 12:23:54 +0000

Hi Mingliang,

On 21 Dec 2017, at 19:27, Mingliang Pei <[email-masked]<mailto:[email-masked]>> wrote:

In the case of Global Platform, OTrP is being restructured from a document point of view to map to TMF. We already have two frameworks.

GlobalPlatform is maintaining strict backward compatibility and interoperability with the OTrP document that was contributed to it (very similar to Draft 4) while constructing the mapping with TMF. In other words, from the perspective of an OWE the behaviour should be unchanged.

There are several areas where GP is contributing “something new” to OTrP:
- Where the semantics of Security Domain behaviour are not fully defined in OTrP, the semantics of TMF Security Domains (which are much more completely defined than anything in current OTrP drafts) are used.
- OTrP behaviour is mapped to TMF commands and configuration so that a system can support both TMF and OTrP.
- Factory reset, which is fully defined in TMF, will be supported for OTrP Security Domains. This will be optional as it may not be needed for some device types.

How will interoperability between “GlobalPlatform” and “IETF" OTrP be assured in such a model? As noted above, GP has a strict goal of backward compatibility and interoperability with the contribution we have received from Open Trust Protocol Alliance.

I have the same understanding as Mingliang on the Copyright around the OTPA contributions to both GlobalPlatform and IETF: OTPA owns the copyright in the original contributions (but it does not own copyright in any subsequent contributions and changes in the respective standards organizations)

Best regards
Jeremy

Hi Nancy,

Thanks for the update.

Thanks,
Regards,
Dapeng(Max) LIU

Thanks, Dave and Nancy

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Dec 2017 12:32:12 +0000

Hi Jeremy,

picking one topic from your email below:

Ø  How will interoperability between “GlobalPlatform” and “IETF" OTrP be assured in such a model? As noted above, GP has a strict goal of backward compatibility and interoperability with the contribution we have received from Open Trust Protocol Alliance.

GP already has three different solutions on the plate today, namely the symmetric TMF, the public key based TMF version and now also OTrP.

There is no interoperability between even these three so why worry about the interoperability between GP and IETF OTrP when there is no interop even within GP itself?

Ciao
Hannes

From: TEEP [mailto:[email-masked]] On Behalf Of Jeremy O'Donoghue
Sent: 22 December 2017 13:24
To: Mingliang Pei
Cc: Nancy Cam-Winget (ncamwing); [email-masked]; Dapeng Liu
Subject: Re: [Teep] [EXT] Re: TEEP update

Hi Mingliang,

Best regards
Jeremy

Hi Nancy,

Thanks for the update.

Thanks,
Regards,
Dapeng(Max) LIU

Thanks, Dave and Nancy

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: Jeremy O'Donoghue <[email-masked]>
Date: Fri, 22 Dec 2017 13:25:23 +0000

Hi Hannes,

Short answer: different protocols, same (or, at least, compatible) behaviour because the semantics of Security Domain behaviour are fully defined in all cases.

As noted below, a strong goal for the work at GP is to ensure that an OTrP OWE is seamlessly interoperable with a device, whether it supports OTrP natively or as a layer over TMF.

As an example, it is a goal that a single TEE could contain multiple SD hierarchies managed, respectively, by Service Providers using any of Symmetric TMF, Asymmetric TMF and OTrP. More realistically, this would allow for a single TEE to support any of the three management options, depending on the environment in which it is deployed.

GP made a deliberate design choice in TMF to separate management functionality and protocol layer, which makes this approach feasible, albeit fairly complex.

Any future interoperability risk between “GP” and “IETF” OTrP does not, in my opinion, arise from the protocol (which GP is not changing) but because GP has made decisions on SD semantics in areas which OTrP draft does not currently cover and which IETF may choose to approach differently.

Best regards
Jeremy

On 22 Dec 2017, at 12:32, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeremy,

Ciao
Hannes

From: TEEP [mailto:[email-masked]] On Behalf Of Jeremy O'Donoghue
Sent: 22 December 2017 13:24
To: Mingliang Pei
Cc: Nancy Cam-Winget (ncamwing); [email-masked]<mailto:[email-masked]>; Dapeng Liu
Subject: Re: [Teep] [EXT] Re: TEEP update

Hi Mingliang,

Best regards
Jeremy

Hi Nancy,

Thanks for the update.

Thanks,
Regards,
Dapeng(Max) LIU

Thanks, Dave and Nancy

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teep

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Dec 2017 13:34:50 +0000

Hi Jeremy,

You have an interesting concept of interoperability. From me interoperability means that I can take a vendor A providing a TAM, a service provider B, and a TEE vendor C (where A,B, and C are different parties using different implementations) and then the result still works. I fail to see how this is possible when the encoding, the credential types, and even the message semantic is different.

Let us also talk about the security domain concept since you bring this up.

I make the bold claim that it is an artefact of over-engineering. The OTrP spec says that it is the TEE representation of a service provider. For simplicity reasons I argue that we just assume that there is one-to-one relationship between a trusted app and a service provider. Convince me that a hierarchy of security domains is actually needed. In none of the documents I have read such a justification has been provided.

Ciao
Hannes

From: Jeremy O'Donoghue [mailto:[email-masked]]
Sent: 22 December 2017 14:25
To: Hannes Tschofenig
Cc: Mingliang Pei; Nancy Cam-Winget (ncamwing); [email-masked]; Dapeng Liu
Subject: Re: [Teep] [EXT] Re: TEEP update

Hi Hannes,

Best regards
Jeremy

Hi Jeremy,

Ciao
Hannes

Hi Mingliang,

Best regards
Jeremy

Hi Nancy,

Thanks for the update.

Thanks,
Regards,
Dapeng(Max) LIU

Thanks, Dave and Nancy

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Fri, 22 Dec 2017 14:33:37 +0000

Hi Hannes,

I think you are misunderstanding me on interoperability.

I claim that Vendor C TEE using OTrP natively and Vendor D TEE which uses OTrP on TMF can both work with Vendor A TAM and Vendor B Service Provider. I further claim that Vendor D TEE may also support Vendor E TAM and Vendor F Service Provider who have chosen to use TMF with e.g. Asymmetric Security Layer.

The way in which GP defines security domains is certainly very flexible. There is no doubt that implementing all SD options in TMF to their fullest extent would be much more complex than required for many (probably most) use cases. It is equally possible to choose a set of options in TMF which is of low complexity (e.g. a hierarchy “depth” of 1 and non-support of many options - this can actually be simpler than OTrP, although such a deployment is probably too limited for most use cases).

From my perspective, OTrP brings one major benefit to the ecosystem, which is that it standardises the PKI and protocol making wide scale deployment relatively straightforward - a weakness of TMF is that the large number of options can make it it difficult for TAMs, SPs and TEE vendors to agree on what makes sense for an open ecosystem.

In most other respects, while TMF can be much more complex than OTrP, it certainly doesn’t need to be.

I’d like to be quite clear on my goal here: I want to make devices that are fully interoperable in any OTrP system, which means that there should be no behavioural difference between an “IETF” OTrP system and a “GP” OTrP system. What the implementations look like under the surface should be irrelevant. I hope that it will be a goal of both organisations to ensure that this is the case.

Jeremy

On 22 Dec 2017, at 13:34, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeremy,

Ciao
Hannes

From: Jeremy O'Donoghue [mailto:[email-masked]]
Sent: 22 December 2017 14:25
To: Hannes Tschofenig
Cc: Mingliang Pei; Nancy Cam-Winget (ncamwing); [email-masked]<mailto:[email-masked]>; Dapeng Liu
Subject: Re: [Teep] [EXT] Re: TEEP update

Hi Hannes,

Best regards
Jeremy

Hi Jeremy,

Ciao
Hannes

Hi Mingliang,

Best regards
Jeremy

Hi Nancy,

Thanks for the update.

Thanks,
Regards,
Dapeng(Max) LIU

Thanks, Dave and Nancy

---

From: "Wheeler, David M" <[email-masked]>
Date: Fri, 22 Dec 2017 18:02:52 +0000

Hannes, Jeremy,
I like this conversation, and think it is very fruitful. I am not familiar with Global Platform TEE Management Framework (TMF), but interoperability goals are interesting.

I want to make devices that are fully interoperable in any OTrP system, which means that there should be no behavioral difference between an “IETF” OTrP system and a “GP” OTrP system.

Behavior is a funny thing, and as we begin evaluating OTrP operations against different types of TEE’s, I expect to have some stimulating conversations. Indeed the implementation of a TEE will have many implications. For example, what does it mean for OTrP to “delete” or “uninstall” an application in a TEE system ROM? It clearly cannot “remove” it. In an SGX TEE there is no “installation” of applications that survive beyond the runtime of an application – the TEE is instantiated on-demand, and then torn down when the application exits. What does “installation” really mean in that case?

From a protocol perspective, IMHO, behavior can only be measured from the outside, regarding the system as a black box that implements a particular state machine. Interoperability is measured by the faithful expression of the state machine to external observers. The system may perform few steps or many steps in order to present a valid behavior. What I mean by state machine and external behavior, for example:

-          When the system receives an “install” message, is the related application available for use, or is an appropriate error message returned?

-          When a crypto key or application is provisioned into a security domain (SD) is there appropriate separations guaranteed in accordance with the TEE definition (different TEE’s will have different separation characteristics), limitations on usage, protection from leakage, and availability for appropriate usage.

I expect (hope) that part of our work will involve refining the OTrP specification to more clearly define these external behaviors, and provide a mechanism(s) for communicating separation characteristics (possibly/hopefully through attestations) to TAMs and Service Providers allowing security policy decisions to be effectively made by those entities.

Jeremy, as you mention, there is not full interoperability even within GP, if a TEE does not implement all aspects of the TMF (symmetric and asymmetric), and this should fall into the business decision category (a device should implement the characteristics it deems necessary for the target market). The protocol should allow a rich expression of these characteristics, and for unification perhaps, a reasonable default.

I don’t see the separation of OTrP into GP (for a concrete implementation according to a specific TEE interface) and IETF (for interoperable protocol definitions and extensions) to be problematic.

Hope you all have a wonderful Christmas holiday (if you observe that as I do) and a Happy New Year.

Dave Wheeler

From: TEEP [mailto:[email-masked]] On Behalf Of Jeremy O'Donoghue
Sent: Friday, December 22, 2017 7:34 AM
To: Hannes Tschofenig <[email-masked]>
Cc: Mingliang Pei <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; [email-masked]; Dapeng Liu <[email-masked]>
Subject: Re: [Teep] [EXT] Re: TEEP update

Hi Hannes,

Jeremy

Hi Jeremy,

Ciao
Hannes

Hi Hannes,

Best regards
Jeremy

Hi Jeremy,

Ciao
Hannes

Hi Mingliang,

Best regards
Jeremy

Hi Nancy,

Thanks for the update.

Thanks,
Regards,
Dapeng(Max) LIU

Thanks, Dave and Nancy