* 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: Roman Danyliw, Benjamin Kaduk | 2018-Mar-09 —  

IETF-105 teep minutes

Session 2019-07-22 1000-1200: Sainte-Catherine - Audio stream - teep chatroom
Session 2019-07-23 1000-1200: Van Horne - teep chatroom


minutes-105-teep-00 minutes

           TEEP Working Group at IETF 105 in Montreal
             Chairs: Dave Thaler,
          Nancy Cam-Winget
             Notetakers: Ned Smith
             Jabber scribe: Ben Kaduk
          MONDAY, 22 July 2019 at 1000
          DT - Dave Thaler
          NCW - Nancy Cam-Winget
          MP -
          Ming Pei
          DW - Dave Wheeler
          HT - Hannes Tschoenig
          AT - Akira Tsukamoto
          SD -
          Sorin D?
          DAW - David Waltermire 
          SF - Sorin Fabish
          TUESDAY 23 JULY 2019
          at 1000
          RS - Rich Salz
          1) Agenda bashing, Logistics -- Chairs (5 mins)
          • [DT] - Meeting started,how many attending TEEP for the first time. Is
          there a second note taker?  Several hands raised for first time TEEP
          • Friday session was moved Tuesday. Focus will be on protocol
          and attestation interactions with RATS at 11:00 where a discussion with
          RATS participants will begin.
          2) Architecture -- David Wheeler and
          Ming Pei (90 mins)
              - draft-ietf-teep-architecture-03
          Issues: https://github.com/ietf-teep/architecture/issues
          • [MP] -
          Two areas update and issues
          Status update - 3 changes from .2 to .3
          Security domain is removed from document. 
          Added agent as part of the
          entity model
          Interm meeting in May 17th issues:
          64 Architecture issues in
          IETF 104 - a list of remaining open issues was displayed. Gray font are
          editorial, black font are major discussion items.
          Virtual interim meeting
          was held where several issues were discussed and reviewed. A summary of
          the virtual interim was covered.
          Issue #7 - Security Domain discussion
          concluded by removing security domain. However, if an implementation
          wishes it could implement security domains. 
          [DT] there was consensus
          at last IETF to remove SD, now the changes have been applied to draft
          version .03 issue can be closed
          Issue #16 and #57 - TEEP agent added to
          architecture. TEEP agent interacts with TEEP broker. TEEP Agent is an
          entity inside the TEE. TEEP Broker is inside REE and may interact with
          a TEEP Agent inside a TEE on the REE. A TAM Broker may link the TEEP
          Broker on the REE to the TAM. A TEEP Message Protocol exists between
          the TEEP Agent and TAM. [DT] Some of this conversation will be taken
          up in the context of transport protocol agenda item.
          TEEP Agent API
          (2.) exists between TEEP Agent and TEEP Broker. The architecture may
          decide to define an API.
          TEEP Broker to Client App (4.) - Do we need
          to define an API? For now no definition is anticipated.
          (3.) Transport
          Protocol between TEEP Broker  and TAM Broker., a(5.) TAM Broker to TAM
          API definition is an open question. [DT] Is the intention to define APIs
          or simply acknowledge there is an API. Whatever is the answer for 2 should
          be the answer for 5 as well. [SD] (2.) is important but  (5.) need not
          be defined. [DW] Likes symmetry between 2 and 5. The question is whether
          APIs are normative or not. Its harder to say 2 isn't normative. If we
          say 2 is normative then difficult to say 5 isn't. [DT] The purpose for
          API names is to correlate behavior in the Transport (3.) and Message
          (1.) protocols. If there was an update of any of the protocol specs,
          then normative (2.) and (5.) would benefit from having normative API
          names. [SD] It is unclear how multiple TAMs case is addressed. [NCW] As
          chair it is important for the WG to decide what is important for IETF -
          normally IETF defines protocols. (2.) and (5.) might not be in scope
          for IETF. [DW] Does it have to be normative or is informative OK? [NCW]
          The architecture defines a workflow. From an architecture perspective
          it doesn't matter if it is informative or normative, but if subsequent
          drafts are required then that may not be in scope. [DT] The APIs can be
          in scope. There are examples of IETF work that defines APIs. The strategy
          is to define API names with semantics, but doesn't define parameters and
          types. Only protocol state is described by the API text. [SD] There is a
          problem that if both (2.) and (5.) are removed then there is confusion
          around which state is controlled by which endpoint. [BK-Ben Kaduk as
          AD] +1 DT comments. What to do about the architecture document? Maybe
          it works to talk about it in more generic terms. Architecture could
          define pieces of functionality and how they interact without referring
          to them as APIs. 
          [MP] TA Binary in client app installation (Issue
          #11). In first draft assumption was TA binary from TAM. An overview of
          the TEEP message flow was reviewed. There are 10 steps in the workflow. A
          callback flow was discussed where the TEEP Agent could call back to the
          TEEP Broker to obtain additional context so the TEEP Agent can make
          a more informed decision. The "ProcessTEEPMessage" step can obtain
          context regarding whether the TAM (or another endpoint?) is a trusted
          endpoint. The "ProcessTEEPMessage(Install)" can take place given the
          context of knowing the endpoint is trusted/not-trusted. There are 3
          keys used in this protocol. The signers may need to be vetted based on
          a trust policy. Comments? [DT] If it isn’t clear some TAs need the TA
          binary in order to install the TA Binary some may not. Some may store
          the binary in protected storage. It depends on the TEE. [Randy Turner]
          - Is there a use case about connections across networks? For example,
          multicast applications to multiple agents at the same time. There
          is a section on IoT in the arch document. [MP] This seems like a new
          use case. We haven't considered multicast interactions yet. [HT] The
          transport on HTTP was assumed. But in some use cases something other than
          HTTP could be used such as at the Radio Link layer. We are only talking
          about transporting messages on top of any of the underlying layers. The
          Client App (4.) could be more complicated then currently implied. [DT]
          The charter and BOF suggest there can be multiple ways to distribute
          apps and binaries. There are several use cases that point in this
          direction. These are orthogonal to OTRP. Issue #11 is about what
          happens if the TA Binary is bundled with the client application and
          uses a multicast protocol. There could be a case where they are not
          bundled. But [DW] The distribution of the binaries could be multicast,
          but trust is between the TAA and the TAM. That may require talking
          about how to open a different type of transport, but otherwise the
          semantics are point to point. There isn't a way to do a multicast
          attestation. [DT] Speaking as a SUIT chair. The discussion of how
          to distribute binaries is heavily related to the SUIT manifest. This
          should be a great discussion in SUIT. [HT] There are many ways to do
          this but there are defined approaches already such as LORAWAN. Agrees
          with DW that we can describe in architecture for how that can be
          addressed [MP] Attestation is end-end today, not multi-cast. [DT] What
          is the current status of 11. [MP] Not in any document yet. There is a
          privacy concern that the TEEP Agent doesn't want to leak information
          until it trusts the TAM. Attestation context is required by TEEP Agent
          as a prerequisite. TAM is required to disclose context information
          first. TEEP Agent can cache TAM certificate (attestation context?) and
          subsequently no attestation exchange is required (for some duration of
          time?). [DW] Sees two issues: privacy and the need to trust the TAMs. The
          TEE can maintain a list of authenticated TAMs. This can reduce round
          trip. But if no storage available. Alternative, the TEEP Agent can be
          configured to protect privacy and protect on each exchange. Otherwise,
          the TEEP Agent can optimize for round trip. There is a trade-off between
          privacy and performance / resource use. [DT] The current protocol answer
          is you only send to someone that can decrypt. [DW] There is a question
          on whether AM has the right keys (attestation? vs. authentication?). [MP]
          Architecture for protocol needs to support various use case options. 
          describes single pass installation. (related to #11).
          Issue #64 - End-end
          security between SP (service provider) and TEE. SP isn't always a TAM
          provider. TA Binary is distributed over encrypted channel. The SP may not
          have key to decrypt. This is the problem we're trying to address. A data
          model can address the problem. This is the current proposal. [DT] This is
          the proposal by the editors. When SD is removed how do we deal with this
          use case? The architecture document should be updated to explain how this
          works (and didn't break use cases). [NCW] This is what is needed to close
          the issue. [TD] SUIT manifest can be used to express the context necessary
          to resolve using a data model solution.
          Issue #13 - TA depends on another
          TA? Defer to SUIT manifest.
          Issue #14 - Multiple TAMs per single client
          app. A client app may depend on multiple TAs. Resolution: Address the
          simple case that a single TAM is contacted by a TEEP Broker for a Client
          App. A Client App Manifest can contain multple TAMs. [DT] This is about
          a client relying on multiple TAs. What if on TA is installed and one
          isn't. One could be obtained from TAM1 and the other from TAM2. This is an
          implementation issue. There could be race conditions etc. It didn't need
          to be dealt with at architecture level. Implementers need to think about
          this however. [DW] The last discussion is a bit manufactured. In a real
          ecosystem the SP will publish the entire application to a single TAM. They
          will provide a list of TAMs they publish to. It isn't likely that parts
          of the app spans multiple TAMs. Multi-threading issues is a localized
          issue. [DT] +1 DW. If the use case does exist, then the implementation
          can resolve any inconsistencies that may emerge. [DW] Open source is
          potentially a case for this, but most often the peices are already
          installed (e.g. OpenSSL) but the SUIT manifest will address this. [NCW]
          It may be useful to explain these assumptions. [MP] There is a caveat,
          the exception is when the data and binary are installed separately. This
          could result in separate TAMs. They are treated differently (data
          vs. binary) so there may be an exception to the assumption that it will
          always be an implementation issue. [DW] We haven't talked about this
          enough. The data TAM as a SP needs to scale to all the devices they're
          going to service. This is for personalization data. If they can scale,
          they can also provide the binary as well. There could be a case for
          specialization. For example, where device is memory constrained. [MP]
          There could be cases where the data vs binary differ because of security
          reasons. [DW] Lets not make the protocol overly complicated initially. The
          protocol needs to ensure it can serve different implementations. [DT]
          Confirming we need to understand 
          the TAM use cases better. Case 1 - SP
          hosts the TAM orr 2 where the client app is bundled. In both cases there
          is only one TAM. This means that the architecture can still explain and
          wordsmith to ensure #14 and #64 can still be addressed as proposed. [MP]
          The data will be given to the TAM they trust. If they are the same then
          it is a non-issue. [DW] In the case where a TAM is specialized, they
          can front a second TAM where they pull the information through. Possibly
          they are limited by bandwidth, but seems like a corner case. [MP] There
          is a problem the fronting TAM could create a privacy problem. [DW] +1
          There could be a MITM challenge. Still need to think through this. [NCW]
          The two editors are not quite converging. Maybe the mailing list could
          help. [HT] When Brendan presented the SUIT work, the personalization
          data concept is part of the SUIT manifest. The time the data is created
          / protected, there is nothing specific to OTRP messages. Is this an
          issue? [MP] We're assuming personalization data isn't contained in
          the manifest. [DT] It has to be encrypted with only the key the device
          possesses. It can appear in the SUIT manifest, but the manifest can't
          be finalized until the device with the key is extant. [SC] Scalability
          is a concern. It isn't privacy so much as reality of scalability
          assumptions. [MP] There is an assumption the device can support multiple
          TAMS. [DW] It is similar to supporting AWS, use scalable key management
          service. [MP] Tomorrow there is a dedicated slot for this.
          Issue #17 -
          Deferred to tomorrow. 
          Issue #32 / #51 - Trust anchor update. Should arch
          document address this or should SUIT solve it? More work is needed. SUIT
          is more for firmware update not TA management. A separate draft for
          full definition of the TA lifecycle is needed. Current preference is to
          defer to a separate draft. [DT] This same problem is shared by others
          including SUIT. The same discussion would be in scope for SUIT. [MP]
          We need to decide which WG should define this. [DT] The overlap could
          be that the personalization data could contain TA data. [MP] Close to
          closing issue.
          Issue #10 ???
          Issue #52 - Alternate session based TA
          Provisioning. Suggestion is to negotiate a session key first, then
          use session key for future attestations. Responses: Dramatic change
          to protocol. Binary protocol vs. JSON/CBOR. IP is patented. Issue
          closed. [DT] Seems to be consensus to close. [Henk Birkholtz - HB] What
          is the issue? [DT] Summarized the use case for Henk's benefit. There
          will still need to be a parser and other overhead, that minimizes the
          benefit for moving to symmetric keys. [DT] There was concern on the
          list that trusting a JSON parser is appropriate. Intel has stream based
          attestations. Parties to the protocol need to be two distinct points. The
          context of the attestation can't be carried deeper without additional
          support. A token based approach makes more sense. [HT] The question is
          what information exists in the normal world vs. the secure world. I don't
          see how security functionality is maintained without putting most of the
          functionality in the secure world. What is the value of a secure world
          that doesn't have full security context? [DT] The binary vs. JSON isn't
          an arch issue it is an OTRP issue. We can talk about CBOR vs. JSON during
          the protocol session tomorrow. [MP] This proposal was raised 3 years
          ago. It doesn't seem like a good fit. There is a key provisioning WG in
          IETF. The context for TEEP is application management. 
          3) Architecture
          issue #63 (locations of keys) -- Akira Tsukamoto (10 mins)
          Issue: Issue: https://github.com/ietf-teep/architecture/issues/63 
          • Issue #65? - [AT] Where to put the keys in certificates and how are
          CAs affected? The TEEP architecture can't make assumptions about how
          the TA/SP code signing CAs are deployed. Two diagrams were displayed
          showing device manufacturer and device developer signing tasks. [MP]
          There was some confusion about which terminology to use TEEP Agent or
          TEE. [AT] There are considerations for whether functionality is on
          the REE side vs the TEE side. The TA must be signed by the CA. [DT]
          There is a question about which keys are used. There could be keys for
          attestation vs. keys used for attestation. When you load you load the
          DICE chain. [DW] There is confusion about who signs what. [DT] You end
          up with two cert chains one for attestation and another for code. [DW]
          But the code is signed by the mfg. [DT] This thread is deferred to
          tomorrow at 11. [NCW] Have issues been posted to github? [AT] Yes. [DT]
          There is editorial issue that makes the architecture unclear as it
          relates to key types (attestation vs. binary signing). [AT] Showed a
          diagram of OTrP sessions where certs and private keys are held by TAM
          and TEEP Agent. [MP] Optionally, the TEE could be installed at secure
          boot. TEE could have a certificate for secure boot. TAM should also
          have TAM CA keys. Firmware was optional in a previous release but that
          will be updated in a future release. [DW] Trusted firmware is likely
          to be an example in the document. In the implementation, there could
          be a trusted firmware, the TEE Private key will have a root back to the
          firmware trust chain. The trust chain is an implementation option Some HW
          based TEEs may appear as a single key in the TEE, but it could be derived
          from other HW keys. Nevertheless, chaining can exist. The architecture
          document didn't explain this well enough.
          4) OTrP over HTTP --
          Dave Thaler (15 mins)
              - draft-thaler-teep-otrp-over-http
          Issues: https://github.com/ietf-teep/otrp-over-http/issues 
              [NCW] Running out of time. We will move the http transport update
          to tomorrow. This concludes the meeting for today.
          TUESDAY 1000
          Agenda bashing, Logistics -- Chairs (5 mins)
          2) OTrP over HTTP -- Dave
          Thaler (15 mins) 
              - Draft: draft-thaler-teep-otrp-over-http 
              - Issues: https://github.com/ietf-teep/otrp-over-http/issues 
          DT is presenting as an individual participant as author of the
          Adopted as a WG doc. On GitHub.
          Issue #3, media types to OTrP --
          Content-Type and IANA is in spec, consider this closed.
          DW if we remove
          the name "broker" what are the second boxes on slide 4? And what are
          their responsibilities? We need to be clear.
          DT: with separated layers,
          we need a OTrP over "foo" layer that deals with the transport binding
          to OTrP.
          Ming Pei: if HTTP can be handled in the TEE, then it could be
          optional. TAM as a service, we've added more responsibility to it to also
          be a message responder. Don't have a strong opinion, but for transport
          especially for HTTP, we need to transport responder.
          Hannes: we should
          mention some of the other options
          DW: the specs discuss implementation
          and splitting] layers based on prototypes; but we should really have
          protocol layers (application layer then presentation layer and then
          the transport layer). 2nd layer is not really HTTP, but its really the
          encapsulation of TEEP. Don't agree of protocol layer of TEEP over HTTP
          DT: issue is more about terminology
          Issue not closed.
          Issue #2: http
          Current model is requestor is requesting TEEP be installed;
          Anders wants binding for requestor asking for TEEP remote (such as in the
          Options: do nothing, do in future, separate doc, work on now in
          same doc. Dave prefers "do in future"
          3) Open Trust Protocol -- Hannes
          (30 mins) 
              - Issues: https://github.com/ietf-teep/OTrP/issues 
              - Draft: draft-ietf-teep-opentrustprotocol-03 
          Draft: draft-tschofenig-teep-otrp-v2 
          HT: Why new document? WG made
          several decisions, architecture draft made changes, wider set of use
          cases, terminology alignment.
          The changes were big, which lead to a
          sinbgnificantly changed document. This is why we submitted it as an
          individual draft.
          How important is backward compatibility? It is hard
          to do with current doc and 1.0
          Possibilities: new version number, new
          name, something else?
          MP: Do we need to maintain compatibility with the
          global platform 1.0 specification? There really isn't a 1.0 since this
          work is not finished.
          DT: Previous doc, based on his hackathon work,
          wasn't interoperable with itself
          MP: There are multiple documents
          related to OTrP in global platform. Some are out for comment.
          "Of course I have more slides."  "Oh, not on this topic"
          NCW: The name
          change is more important the breaking compatibility. There might not be
          a compatibility breaking concern if global platform doesn't complete OTrP
          1.0. Are they considering a version of their document as a "standard"?
          I think so.
          NCW: Does the group want to break compatibility with global
          platform?  Separate question: should we change the name?
          DAW: Will global
          platform revise their spec?
          DT: Does global platform want to use this
          WG output? Answer seems no; that makes it hard to answer question 2
          Is the group willing to break backwards compatibility with OTrP 1.0? Yes:
          many hums; No: no hums (summary: unanimous consensus; although stronger in
          the front of the room)
          HUM: Change name from OTrP? Slightly strong no
          the humming RFC, asking if there objections to keeping the name?  
          Wants to change name to avoid possible "v2" name competition/confusion
          as someone outside the working group seeing OTrP appear in two places is
          going to be VERY confusing. Previously they did not seem interested in
          DT: Believes derivative rights were granted to IETF, including
          the name. A name change may cause branding confusion, since many parties
          expect the IETF to produce an OTrP revision.
          Adam Wiethuechter: Very
          confused by naming
          DW: Let's avoid conflicting/confusion over the name
          MP: Our intent was to bring it to the IETF for evolution
          NCW: We need
          to continue this discussion on the list.
          NCW: What do we do with the two
          HT: Is the new draft sufficient? Can a future version of this
          document replace the original?
          Using CDDL for protocol definitions,
          having issues about making it transport-agnostic, looking for help
          Details about message structure, EAT integration, etc., in slides (and
          of course the doc). TOKEN combines a few data points from the previous
          Need to investigate how to handle multiple TEEs and TAMs. This
          might require additional fields.
          No coding done yet, since there are many
          design decisions still open
          MP: Attestation can provide what TEE and TEE
          version is running. This is different than the tid/rid. a tid and a rid
          can be changed at different frequencies and independently of each other
          for various reasons. This may be a reason not to combine them.
          HT and NCW:
          We need to discuss the tid/rid/NONCE issue more.
          Q: How many have read the
          draft? A: 5 + HT
          HUM:Is the group willing to adopt this draft and replace
          the current OTrP draft with this draft? Summary: yes loudest, don't know:
          less, no: even less)
          4) IoT DDoS Attack Prevention -- Sorin Faibish
          (10 mins) 
              - Draft: draft-faibish-iot-ddos-usecases-00.txt 
          Several types of attacks in the slides. Is preventing these within
          the charter?
          Is there interest in the WG to use this draft?
          DW: The
          threat actor could be a developer of the software running or someone
          who has stolen the crediantals of the develoepr.
          NCW: 5 have read the
          draft, out of time here need to discuss on-list; suggest opening issues
          for security considerations in the docs
          5) TEEP + RATS Alignment --
          Dave Thaler (20 mins, starting >= 11:00) 
          Dave Thaler, presenting as an
          individual, about alignment to avoid duplication of attestation (Etc); see
          Presenting options for alignment. Multiple approaches can work;
          at least three.
          Freshness issue: RATS uses nonce, OTrP has a requestID
          (v1) or a NONCE (v2)  Nonce alone doesn't ensure result valid at time
          of receipt (policy change, reboot, etc)
          SF: Need to make sure there is
          no loss of functionality between OTrPv1 and v2. I'll review the drafts
          and comment.
          Henk: two types of claims (attestor mandatory/optional)
          and verifier (which might want to say something about why a given
          claim violates policy.)
          Robin Wilton: Option 3 or the advanced case
          can allow device behavior to be factored into what the device itself
          is claiming.
          Ned Smith: Need clarity on what keys are used to sign
          requests and responses.
          NCW: DW will hopefully clarify use of keys in
          his presentation. 
          NCW: Discussion (side meeting) at 8:30 on Thursday
          on attestation use cases.
          6) Architecture issue #17 (attestation) --
          David Wheeler (15 mins) 
              - Draft: draft-ietf-teep-architecture 
              - Issues: https://github.com/ietf-teep/architecture/issues 
          Desired requirements for claims: well-structured, mostly self-contained,
          extensible, support proprietary signatures and formats
          Slide on
          complexity of environments (SGX Trustzone, VM's, etc)
          Options for
          claim languages. Like SUIT manifest, but couldn't get it to work; EAT
          token has subclaim issues. Propose to merge both, use CDDL, etc.
          SUIT manifest wasn't developed for attestation; I was surprised to see
          DT speaking as SUIT chair: don't like merging, but do like carrying
          EAT in the SUIT manifest (which seems to be a restatement of what you
          really mean)
          NCW: Using CDDL is being discussed in RATS, encourage you to
          come to the WG
          NCW: As TEEP and RATS chair, we will have to think about
          how to characterize the IANA registry
          HT: Any interest in a tutorial
          such as Friday before next IETF
          NCW: Doodle poll on virtual interim

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