* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Teep Status Pages

Trusted Execution Environment Provisioning (Active WG)
Sec Area: Eric Rescorla, Benjamin Kaduk | 2018-Mar-09 —  

IETF-102 teep minutes

Session 2018-07-17 1330-1530: Viger - Audio stream - teep chatroom


minutes-102-teep-00 minute

          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
          The chairs discussed the status fo the WG and reviewed milestones.
          3. Architecture
          drafts: draft-ietf-teep-architecture-00
          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 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
          Ming Pei provided a summary of the OTrP design and corresponding
          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
          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.
          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"

Generated from PyHt script /wg/teep/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -