Trusted Execution Environment Provisioning (TEEP) WG Minutes IETF 102 Tuesday, July 17, 2018 13:50-15:50, Tuesday Afternoon Session I Room: Viger 1. Agenda bashing, Logistics 2. Review of charter milestones =============================== presenters: chairs slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-teep-chair-slides-02 The chairs discussed the status fo the WG and reviewed milestones. 3. Architecture ================ drafts: draft-ietf-teep-architecture-00 presenters: Mingliang Pei & Hannes Tschofenig slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-teep-teep-architecture-draft-02 Ming Pei and Hannes Tschofenig introduced the architecture draft and summarized the discussion of it on the mailing list. Slide 9: "How are messages routed to the correct TEE" Comment: (Dave Thaler) This diagram is implementation-agnostic. There may be different TEE types on the same system/device. Slide 11: OTrP Roles and Terminology Comment: Need to standardize the terminology in this diagram -- take it to the list Slide 12: Service Provider Teminology Comment: There are multiple use cases to consider here Comment: (Dave Thaler) I like the first definition on this slide. My question is on the two sub-bullets -- imo the second sub-bullet is a more specific case of the first. Comment: (Dave Wheeler): I see a device administrsator as different -- they decide what can be on the device. There is an ecosystem enabling the TAM. The TAM takes the role of the device administrator. Comment: (Stu Card): The issue for me is scope of the roles. The Service Provider defines the rules of engagement for the trusted app that is installed. The Device Administrator decides whether to engage in the relationship with the Service Provider. There is a notion of rules-of-engagement. The service provider sets the rules of engagement for app. The device admin can decide whether they agree with them. Slide 12: Keys Comment: (Russ Housley): You might want to reference RFC 5280 to simply describe the CA Comment: (Dave U) I'm not sure if there is a certificate in all cases. In trusted firmware, there might not be a certificate with the trusted key. A TEE may also have multiple attestation keys Comment: (Hannes) We can revise this table. There is only one attestation method defined in the architecture -- a "one key per device" model. The cardinality situation described previously isn't covered. Comment: (Russ Housley): Referencing Trust Anchor Management Protocol (TAMP) may help Comment: (Dave Thaler): Different communities use different terms. We need to provide a mapping for the terms in the draft to those used in the other communities. Comment: (Ming Pei): +1 key cardinality is an issue Comment: (Dave Thaler) Let's take key vs. CA to the list 4. Open Trust Protocol ====================== draft: draft-ietf-teep-opentrustprotocol-01 presenter: Mingliang Pei slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-teep-open-trust-protocol-otrp-02 Ming Pei provided a summary of the OTrP design and corresponding protocol. 5. TEEP Hackathon report ======================== presenter: Dave Thaler (as individual) slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-teep-teep-hackathon-report-03 Thaler explored what would be needed to implement OTrP from spec during the IETF 102 Hackathon, and presented the issues that were discovered. Comment: (Ming Pei): Comment: (Andrew Atyeo): Per the issue of the TEE encryption being optional, I believe it's mandatory in the draft. Comment: (Nancy): Need to be clear on what's meant by encryption -- confidentiality or integrity Ming Pei clarified the OTrP draft per issue #4, 5, 7, and 9 raised by Thaler. Chair: (Nancy) The WG will start tracking the issues (and resolution) in GitHub. 6. SGX Overview and Impact on TEEP ================================== presenter: David Wheeler slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-teep-recommendations-for-teep-support-of-intel-sgx-technology-02 Wheeler introduced SGX, SGX Trusted Computing Base and SGX Attestation. Slide #18 Chair: (Nancy): Are there any objections to the MUST/SHOULD statements on this slide? Comment: (Hannes): Per the 3rd bullet, in ACE, we also discussed key lengths/crypto algorithms. Comment: (Henk): The term "secure boot" is a legacy name. Also, "secure boot" has nothing to do with attestation. Comment: (Ming Pei): Per "SHOULD support Quantum", recommend "MUST support algorithm agility"