TEEP Working Group at IETF 104 in Prague, CZ TUESDAY, 26 March 2019 at 0900 Jabber: xmpp:teep@jabber.ietf.org?join MeetEcho: https://www.meetecho.com/ietf104/teep Etherpad: https://etherpad.tools.ietf.org/p/notes-ietf-104-teep Github: https://github.com/ietf-teep/ Scribe: Stephen Banghart Notetakers: Jaime Jiménez, Ned Smith # Agenda ### 1 Agenda bashing, Logistics -- Chairs (5 mins) Nancy going through the agenda. ### 2 Architecture -- TBD (TBD mins) - draft-ietf-teep-architecture-02 Dave Wheeler presenting. Going through raised issues at https://github.com/ietf-teep/architecture - Issue #3 Trusted App Distribution Clarification of the terminology: Client Apps, TA, Personalization Data.  Explaining the bundling variations, on how applications on the TE will be built. Current spec will have something like an AIK (Attestation Idenity Key) - Issue #8 Handling of multiple TEEs vs Single TEE TEEP broker will manage the actions of the TEE, OS could combine them, but in simplest case there is one TEE and one TEE Broker. - Issue #14 Multiple TAMs for single Client App TAM is associated with the TA, not Client App, but a Client App may depend on multiple TAs Resolution - A client App manifest file can contain all TAMs it may use to get TAs, normally just one There may be multiple TAs one for different users/vendors/service provider etc. Any TAM can handle any TA. TEEP Broker could use manifest to decide which TAM to use. Questions? Dave Thaler [DT]: Regarding manifest file, where is the manifest file? Dave Wheeler [DW]: Concept is the client app will include all the TAMs the SP has pushed the app out to. That list of TAMs looks at its TA list to decide which TAM it trusts. The manifest has TAM elements, where to get it and public key. Mingjiang Pi [MP]: Client apps may use different TA from different vendors, how do they acquire binaries from different TAs? If one client app depends on 3 TAs still need to supply all three TAs to the TAM. Contrast to alternative that a manifest file could have 3 TAs and can choose which TAM. Questioning who owns selecting the TA.  Jabber Henk [HB]: Trusted App and Trusted Anchor, it is confusing.  [DT]: Original question (slide 6) was that Case 1 is the TAM the one creating the bundledle, by fetching all TAs and sending the bundle back. [MP]: the Service Provider is the one that performs that, it is reponsible to create the bundle.  Hannes Tschofenig[HT]: the manifest is in two places, one to describe the application, the other for the App Developer context.  [DW]: Closer alligned to Dave, SP creates application with one or more TAs and creates a manifest with infor on TAMs and TAs. That gets pushed out. Manifest provides all the information the TEEP B needs and is pushed out by the service provider. We have not talked about where the manifest is,. It is part of the Client App, which was pulled form a store and works with the TEEP broker. We have not discussed where the installer gets the manifest from.  [DT]: The manifest doesn't have to include a separate location. [HT]: Need to figure out the role of the manifest. [MP]: Might not have been well specified (?). What are the requirements of the installer? Nancy Cam-Winget[NC]: Need to go back to the issue on github. [DT]: is it a new issue?  [DW]: agrees it is a new issue especially as to format of manifest [Issue]: File github issue on the manifest, does a client have to understand multiple TAMs (NO) but format of manifest is open question. - Issue #13 Is it in scope: TA depends on another TA and related installation? This was discussed in the Interim sessions, but there are two concerns: complexity is increased, creates a circular dependency. [DW]: Is there only 1 TA in an application? Are there circular dependancies? Are there different versions at the same TA etc. We didn't resolve that. There were multiple recommendations. Ming asking to defer to later. From Intel SGX, if TAs are limited it would be limiting. Dave Waltermeier [DWal]? : What do you mean by dependency [DWal]: If I have an application that wants to do authentication it requires an authentication TA, that requires another TA for key storage. [DWal]: How would we represent the nature of the dependency? [MP]: How do you turn on video? OK I'll just speak. One app can have all TAs, but order is important. If client app defines order then its is a simple case. TEEP dependancies (order) need to be strictly carried out. Here we're talking about a more complex case where client app can't figure things out. But if we can move the responsibility to another level. It would be better. [DT]: SUIT chair hat on. As chair of both groups I would like to have both compatible. Brendan Moran, (who isn't in the room right now) gave feedback on SUIT. The SUIT WG defines a manifest format, epressing order of install, etc. It is also focused to optimise for firmware. Brendan will write on his document a comment expressing that it could be used in other larger contexts. Teep could use it as long as SUIT manifest can handle it it could be used by a different WG.  [NC]: Should not then TEEP express it as well?  [DWal] We would need to do that (allow other groups to define extensions to the manifest) [DT]: That is correct. It is achievable in theory. [NC: Suggest to make draft available to TEEP and in the next F2F or next interim have Brendan Moran there.  [HT]: We discussed two cases (i) trusted app (ii) multiple trusted apps being provided either directly or as a reference. Need to write the correct ver. What is the proper name etc.. so correct entries can be fetched. [DT]: Are we filing another issue on github? [DW]: We have two different issues. [Issue]: There is a second github issue to file. We will use Issue #13 to track this discussion. Reference to SUIT working group and Brendan Moran Suit Manifest format document. draft-moran-suit-manifest [NC]: Do we need to relay that to SUIT? [DT]: Can just be relied to them, the draft in quesiton will be presented tomorrow morning. [MP]: I agree we should leverage SUIT manifest and send out requirements to see if it meets our need.  [DT]: Anyone having comments on the requirements, it will be discussed tomorrow at SUIT. [NC]: Name of SUIT manifest author? [DT]: Name is Brendan Moran: draft-moran-suit-manifest [DW]: We need to create the manifest? Soirin Faibish [SF]: How will be the relationship with SUIT?  [DW] we'll refer to the manifest in SUIT [NC] We need brendan to prresent to the group. - Issue #17 Capabilities of the Attestation Mechanism Dave presenting. Added text to the attesttation draft, presnting the draft changes. We need to support both priprietary and standard attestation formats. There is proposed format to put in the draft. We also need to align with RATS and EAT attestation formats. [DW]: Attestation definition, the prester of the claims is the attester, the entity that checks the claims is the Verifier. The Verifier must be able to ensure the claims are correct. In our case the Verifier is the TAM. It ensures the TEE is trustworthy. Asymmetric key pairs are under the control of the TEE. The primary purpose is the attestation allows device to proove to SP the properties are secure (correct). ??: It is not that the claims are true but rather that the attester believes that the clame are true, right? [DW]: Yes , thats correct [DW]: It will prove the identity of the TA so that TAM or SP can authorize use of keys, identity of device or TA to prevent masquerade attacks. It could be used to prevent aunauthorized devices from installing attacks on the SP etc. [NC]: As chair of RATS, This is effectively a use case of RATS currently under discussion. There will be interdependencies. Please participate so it doesn't become too TEEP specific.  [DW]: We need to coordinate with DW. Ned agrees to coordinate with DW. Eric Nordmark[EN]: It seems that when we are deep down in some details it would not be surprising that we can have an unique identity on the TA (??) [DW]: Right. so I agree with that in principle. Im struggling with how to assoicate with TEEP which is a SP installing a TA into a device.  [EN]: Service Provider could be an ??? it is not necessarily a network provider. Seems it is closer to RATS than TEEP. [DW] Yes correct. There are attestations that don't leak. EPID is one of those. When talking about current standarrds RSA, ECDSA they are unique identifiers (PII) and have privacy considerations. Difficultly understanding where to place it. [EN]: My point for the WG don't try to solve this here but do not prevent other to solve it by hardcoding thing with keys that are unique per key. [DW]: OK, EPID and DAA would be part of proprietary attestation formats that TEEP will accept.  [NC]: Let's stop that now, as it is too specific to the implementation and it might not be in scope for TEEP. (rather for RATS) [HB]: Draft text doesn't highlight that TAM is taking the role of verifier. The assertion presented has to spell this out specifically. Henk needs to clarifiy (on jabber). Henk says Yes to DT response.  [NC]: This belongs in the RATS WG. [DT]: The question is the same as already made; "It is not that the claims are true but rather that the attester believes that the clame are true, right?" And the answer is the same, "yes" [DW]: The cryptographic properties are the verifier needs to make assumptions about what is included in the attestation implicitly. How as attestation key installed in the platform, what are the mfg processes and procedures? How does a verifier know about compromises etc. Verifier needs to be comfortable with the assumptions that are built in / implicit. TAMs and SPs are free to say they don't trust MFG processes. It is their security policy decision. (E.g. Implicit Attestation needs to be understood better). Showing figure on 7.2.  TEEP Attestation Structure. [DW]: [DT]: Questions on Use cases are perfectly fine to keep here.  [DW]: We may move this to the protocol spec. Attestation Strructure In the end we want to align with EAT and RATS. From TEEP attestation strtucture has
to determine if it is a standard form or a proprietary form. and then . I haven't gone to furthur detail than this. Have had several discussions but more work is needed and more input is welcome. [NC]: As chair of both WGs, form the TEEP perspective is good to have the requirements, but this presentation would be good in RATS too.  [DW]: Unfortunately, DW will not be avilable to attend RATS (but available online or a later time). [DW]: took the SGX attestation and identified the elements that could be generalized. In SGX there are only two hierarchies, the CPUSVN CPUSVN (CPU Security Version Number) telling us the version of the microcode. There is also more information that can be used for identification, as in the  MRENCLAVE, MRSIGNER, ... . There are cases in which you are only checking the Security Version Number, which is the important part, not so much the other parameters. Dave explains what an SVN is - the SVN isn't changed even though the code veersion number changes. Only increment SVN when there is a security relevant change to the TEE. [DW]: Still quite a bit of work to be done.  - Issue #7 Clarify meaning of Security Domain Mingliang Pei  [MP] presenting. The problem is that there is overhead to manage SPs. The proposal is to allow an implicit Security Domain (SD) per TA. We have discussions in the issue tracker. Security Domain is a security boundary. It has group or TS under the SD. It is a layer of the trust boundary. The term "security domain" is described in the architecture document as: "A Security Domain (SD) concept is used as the security boundary inside a TEE for trusted applications." We added anonymous attestation key. I think discussion was what if we don't need an AIK. When you create a SD / new key pair. The public key is sent to TAM. SP can use key to encrypt personalization data to a Device. We choose not to use TEE ? so each service provider can use his own key. (On slide 3 of 5). [DW]: The discussion the authors had was trying to understand what the SD was for. It boiled down to use: isolation mechanism for TAs, a key provisioning mechanism, etc. Then we concluded that either we make it mandatory or we make it implicit, Group TAs , or we make it optional or remove the concept. We have not been able to decide. Right now the discussion is on the AIK. [HT]: At the minimum we need to outline the feautes. You bring a new point, which is the interaction with the service provider, which is not documented there. Currently the protocol runs between the TEE and the broker, not all the way to the back.  [DT]:Lets go through the rest of the slides.  [MP]: On slide 4 of 5. Whether attestation is needed, encryption of ?? Which SP TAM sends is already in the protocol. Whether a separate key (AIK) is needed is another concern. There is an offline mode requirement. But how do you trust response from TEE? Response can be verified by a local attestation key. Arguement from DT that alternate DeviceID is a concern. Rich OS can hide hit. TEE certifiicate shuld be accessable. E.g. Phone device can collect device certificates for all devices it touches. Is this a privacy consideration? Potentially puts a burden on Rich OS. [DW]: The fist thing to discuss is the AIK the right cryptographic item to deal with encryption of personalization data? There are lots of things to cosider. Symmetric keys play a role. All of the privacy issues surrounding use of AIK for this purpose goes away. [NC]: Moving to next slide [MP]: So now this was the separate AIK? TEE public key can be used for key wrapping (RSA?). That is wrapped by the public key as a transport to the device. We can just use TEE public key to transport. The Security Domain is fully needed. The only concern is existing TEEs that doesn't support will need to support SD in their TAs.  [HT]: likes the idea of exploring simetric keys instead of AIK. Specially if SP encrypts the metadata, there could be a reuse of the key. Having the SD optional, would allow a roundtrip for the creation. The isolation concept will be there anyways.  [DW]: More specifically, If we make the security domain implicit, anything installed from the same SP public key will go in the same SD. A SP that does not owant that can use a different public key. [MP]: They could do that as default behavior, If they want to use pub key as identifier they could.  [DT]: Hannes are you for/against the recommendation on the slide? [HT]: in my opinion if you make the security domain implicit it gets removed from the document. (Option n2 for issue #7) [DW]: Mandatory, Impicit, optional or removed. #4 was DW recommendation (remove it). [HT]: For me it would be implicit plus an extension that creates the SD. Prefer theuse of symetric key for AIK. [MP]: If implicit then there is a separate key for that possibility.  [DT]: I have no objection for option 4. Debate is btw 2 and 4. I'd be fine with have no normative text and instead having informative text. No objection to Hannes option either. For the use cases that I have, the case of the TA having its own key pair.... you have one key pair for TEE and another for TA, I see no reason why I would need another key for the SD. I can figure out all issues with the other two keys.  [HT]: Option 4 would be fine for me as well. The SD concept has been extremely confusing in all discussions. [DT]: I have no problem with informative text but normative text is a challenge. [MP]: On the symetric key part: we though about it at some point. Use of symmetric key poses a security challenge. One per TA we have one per group of TAs. All other TAs can decrypt the data. So only public key is given to the TA. Symmetric key is always epheneral. This is for security reasons.  [NC]: let's close this issue, what we heard form authors and DT as individual contributor is that they are fine with the reocmmendation on the use of symetric keys and remove security domain from base protocol. Does the room have any objections. (No objection) [Room]: Room is silent. -Issue #18 Trust anchor update [DW]: How are TAs installed. Requirements of TAs needs a separate document. We don't need to go through manufacturing processes etc. DT forwarded requirements changes regarding store to  SUIT. - Issue #9 Install TA in single pass  [DW]: Defered to hackathon discussion - Issue #10 Connection flow and model: local TEE request first to TAM rather than TAM initiating [DW]: Defered to hackathon discussion [DW]: If you send aigned attestation to a TAM you are revealing your identity. There are ways to rresolve this. Install TA is the message that needs work. [HB]: There is ongoing dsucssion on TAs in the YANG model. [DT]: NETCONF group is the one Eric Voigh [EV]: Actually it is not Netconf, it is people from there but it will be on RATS - Issue #12: Every Rich App Talks to TAM? Noted that the document seems to assume that every rich app that needs a TA, also needs to have code [DW]: there is some peice of code that talks to the TAM. The client app integrates and talks to the TAM but it is just software decomposition problem. ### 3 TEEP Hackathon report -- TBD (TBD mins) Dave Thaler [DT] presenting the Hackathon report.  [DT]: Participants form ASAT, they have implementation already made.  [DT]: Formatting slides: We worked on all three drafts. As a reminder from last hackathon. They have about 3 implementations of OtrP, Ming, Dave and the Japanese folks, only two on each hackathon.  Last IETF Dave tried to have JOSE to run in SGX.  [NC]: Its partly covered in HTTP draft and in OTRP? [DT]: Once issue #2 is addressed it will require update of OTRP. [DT]: What I did in two implementations (SGX/TZ). Others working on TZ and RISC-V and SGX. Since last IETF there is Open Enclave SDK that supports SGX and Trustzone (TZ). The code has been updated to match the latest HTTP transport spec. The summary of the issues are in the slides. OTRP Protocol discussion: (Slide showing dsi.tee ) - Issue #9 in dsi.tee, why are cert and cacert separate fields? So x5c requires a JSON array where the first entry is the leaf cert, and in contrast the rest of OTrP puts the leaf cert into a separate field and has the array only contain the rest of the chain. -Issue #10 What should tee "name" field contain? The spec is silent on what the purpose of this field is, what it should contain, and who defines the value to put in it. -Issue 11: What should tee "ver" field contain? -Issue 12: Relationship to existing/future attestation standards [DT]: Is GetDeviceStateResponse an attestation message in which case should we just reference RATS protocols? [DT]: Quesitons? [MP]: ??? When you send TEE name and version number, only the Name and version are needed. We didn't require TEE name and version in the certificate. Currently when TEE gens request all the infomation is include. [DT]: As an implementer it would be better to leave thim in the paramaters and not in the certificate?? ### 4 OTrP over HTTP -- Dave Thaler (TBD mins)     - draft-thaler-teep-otrp-over-http-01 The OTrP specification [I-D.ietf-teep-opentrustprotocol] describes the behavior of OTrP Agents and TAMs, but does not specify the details of the transport, an implementation of which is referred to as a "Broker". [DT]: In arch doc the terminology refeers to a confusing term. "TAMed Broker" should arch have this term? (i) write a TAM using a TEE or (ii)just write the TAM service. The part that implements the transport part vs. the full service should be distingushable. [DW]: Should we say TEEP Agent instead of TEE? In the arch we have a TEEP Agent and a TEEP Broker. Need to blow up the diagram for TAM.  [DT]: We need to cover the case where there is a TEE inside the TAM. [NC]: We can have multiple diagrams with different blowups. [EN]: You could have Microservices, QC, Load Balancer.... why do we care? No need to have another document defining the TAM.  [DT]: I think its necessary to talk about in security considerations section. You have more risk without a TEE. [EN]: Should we discussed security properties here? there are a lot of issues that have nothing to do with the protocol.  [DT]: If there is another implementer, then we need to document it.  [EN]: Then it could go on a separate document oriented to implementation.  [DT]: This isn't normative, what is wrong with inclucding in the protocol spec? [EN]: having separate names creates more confusing.  [DT]: Lets look at later slides to see if the question is answered. [NC]: 4 Min. [DT]: Last IETF slide showing. Changes from 00 to 01. HTTPBIS WG should pay attention to draft-ietf-httpbis-bcp56bis-08   Mark Nottingham said were doing it almost right. Need OTRP+JSON (use a specific media type). Instead of using a get use a 0-length post.  Terminology invented to show symmetry.  [?]: Call it TAM Broker? [DT]: Agent and Agent Broker for symmetry vs. other terms that aren't symmetric. We have 2 implementations in progrress. [NC]: Does the group believe this is needed for TEEP? Why doesn't it belong in this group? Show of hands - has anyone reviewed the document? (4 hands + Ming). Are we ready to adopt? Any objections? (no). Will be confirmed to the list. [NC]: Other order of business? (No) Thank You! ### 5 Open Trust Protocol -- TBD (TBD mins) - draft-ietf-teep-opentrustprotocol-02 ### 6 AOB