Minutes IETF102: teep
Trusted Execution Environment Provisioning
||Minutes IETF102: teep
Trusted Execution Environment Provisioning (TEEP) WG Minutes
Tuesday, July 17, 2018
13:50-15:50, Tuesday Afternoon Session I
1. Agenda bashing, Logistics
2. Review of charter milestones
The chairs discussed the status fo the WG and reviewed milestones.
presenters: Mingliang Pei & Hannes Tschofenig
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
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
presenter: Mingliang Pei
Ming Pei provided a summary of the OTrP design and corresponding protocol.
5. TEEP Hackathon report
presenter: Dave Thaler (as individual)
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
Wheeler introduced SGX, SGX Trusted Computing Base and SGX Attestation.
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"