Trusted Execution Environment Provisioning Tuesday 13:30-15:30 Tuesday Session I March 20, 2018 - London Note takers: Chris Inacio Jabber: Pete Resnick Agenda bashed ------------- Milestone review: updating website to reflect realistic dates ask: date for WGLC for architecutre Dec? Target April 2018 for WG acceptance of arch document Dec 2018 nominally accepted as a strawman (primary authors nodding acceptance) Mar - July 2019 to progress to IESG ---- WG Overview Presentation (chairs): https://datatracker.ietf.org/meeting/101/materials/slides-101-teep-problem-statement-recap-00 ---- TEEP Use Cases: https://datatracker.ietf.org/meeting/101/materials/slides-101-teep-potential-use-cases-00 Wheeler Are we missing TAM for APP validation? David/Chair: No, those are different functions of roles Wheeler: Thought TAM was independent David/Char: No, but they could be (function of 2 of the current roles) Any uses cases to rule out / or all these valid? Subir Das: which TA should be out of scope, but does that mean that 2a is out of scope hannes: good idea to recast use cases into those different roles we don't want to constrain on who runs the TA, thinks that is the right approach Mingliang: role, chip vendor, doesn't need to be in scope Subir Das: good to be add TAM to the entities list chair: can you think of a case where it isn't one of the already existing 5 subir: yes, when it's a 3rd party chair: please write up a use case for that subir: yes, I have see it that way, will write it up wheeler: +1 / YES Gene Golovinsky: (missed comment) :( hannes: Subir has a point, the secure OS vendor also provides TAM, but it could also be a 3rd party chair: do you have a term (managed security provider) but a better term would be accepted mingliang: enterprise may have a 3rd party TAM provider; outsource their TAM functions to their security provider entity ========== Arch: Hannes https://datatracker.ietf.org/meeting/101/materials/slides-101-teep-architecture-00 chair: security session follows red lines in the arch diagram - focus of the group subir: I do support that 1 TEE requirement subir: Is there another way to reach a TEE without using an app and/or agent? subir: Does device OEM have another way to talk to TEE mingliang: for normal app, you need shim to make the TEE to create the API hannes: need soemthing like a kernel module that talks to the network & talks to the TEE hannes: those two could be merged together (agent & app); not excluding that, but 2 different roles (talking outside the box & talking to TEE) wheeler: mic isn't working (waaaa, waaaa, waaa) dave thaler: doesn't know why we need to have a concept of "device", just need the concept of a TEE wheeler: there must be multiple TEE's though wheeler: device is the relationship between OEM and TEE sven schrencker: must allow to have multiple TEE's; already have those mingliang pei: we started with 1 TEE, looking at phones for example, you can have multiple TEE's as long as it doesn't matter which TEE you talk to max pritkin: relathionship between TEE doesn't matter, but then how do you install the agent / app; at a minimum you need to say the device exists to state that the device doesn't necessarily know what is installed in the TEE chair: no support for not having device and support for having multiple TEE's chair: define what you mean by security domain / provision data area, app, etc.? hannes: struggling with this, comes from the smartcard world, but that has changed hannes: its a data container / multiple apps can access data in TEE mingliang: I agree. conceptually its isolation thaler: refinement of the use case statements. this defines the isolation view arashmid akhavain: each slice in the security domain can present a different set of andrew atyeo: security domain - just a relationship with the service provider outside the TEE; not clear there is any data sharing mechanism in place in which multiple trusted apps can share data eric nordmark: many to many relationship between apps and the isolation domains seems like it would be hard to get correct and who would manage that? hannes: discussion on mailing list about 1:1 vs n:m; eric you say 1:1 eric: (nod yes) mingliang: ???? thaler: even if the thing is 1:1, you can still have multiple things talk to that; but do you want that complexity eric: if I have someone who manages those policies, who's going to manage that, refering to app B vs. B', especially complicated when its many:many need to understand that use case before you design that mingliang: the intel can run a big app, including an OS eric: an app is 10K vs 10M, what is the scale of an app sven schrencker: the enclave is defined, so it can be arbitrary, so it can be very large wheeler: not an ability to run an OS inside SGX Protocol / Solution Document (mingliang) : https://datatracker.ietf.org/meeting/101/materials/slides-101-teep-open-trust-protocol-01 ======================================== chair: currently presenting just what's being done today. Not necessarily what's the goal of the WG max pritkin: confused about use of TASM & TAM chair/mingliang: TSM and TAM are synonyms. TSM is the older term changed to TAM. Arch Questions (chairs) ================================= 1/n message formats?? should cbor be supported: hannes: json was selected originally because envisioned for mobile phone app developers, original use case environment hannes: then people brought up IoT use cases, but that's more tricky, should CBOR then be supported, not sure hannes: CBOR generally would include COSE, which might include some more significant changes chair: not a right answer now, need to define this now, and then do the right work from that hannes: also stated want to have alignment with SUIT WG, they selected CBOR/COSE SUIT chair: assumption in SUIT that you will have a CBOR parser but not necessarily a JSON parser jeremey: as currently defined JSON may not be transformable to CBOR chairs: believe it is convertible, but will check dave crocker: multiple formats breeds complexity and errors, what's the reason? chairs: reasons are stated, might need support for SUIT wheeler: CBOR to support IoT crocker: might be good to express that there is 1 format, with multiple serializations brett jordan: generally against multiple forms of serialization, pick 1, it increases implementation cost chair: from the list: both protocols mandatory to implement at the TAM, but agent only has to speak 1 chair: continue conversation on the list crocker: thales interpretation of his statement is different; single common format, but separate effort for a gateway henk b. : tcg starts using cbor chair: should TEEP consider multiple transports? HTTPS / CoAP / ??? andrew atyeo: need to specify more than just which protocol, what's inside chunshan xiong : which version of the various protocols. mingliang: currently uses 1.1 in the global platform hannes: COAP can't use on its own, or COAP over TCP. differences in performance in the various versions max pritkin: why just talking about HTTP when we should look at a whole stack, e.g. COAP & JSON doesn't make sense hannes: haven't seen newer version of http used in IoT environment chair: heard multiple or COAP, but haven't heard HTTPS only mingliang: IoT use is different then richer device; on device pick 1, but at TAM can support more Sorin Faibish: be sure that you can represent the interest in IoT; other devices can support the IoT case henk b: +1 to max for COAP & CBOR; COAP over reliable should be discussed more chairs: how many have read the draft? chairs: should the WG adopt the draft as the WG draft david kemp: question phrase: about supporting creating an info model and sharing with SUIT chair: draft contains an entire flow for the protocol chair: should we start from this draft waldermire: should defer on the data model for now anyway bret jordan: second what dave w. said : consensus to adopt wheeler: okay with this as a starting point, but larger issues need to be addressed jeremy o'donoghue: starting with draft 6 will ease compatibility with global whatever Meeting dismissed.