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 attendees
• 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. 
#9 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

1) 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 draft.
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 bindings
Current model is requestor is requesting TEEP be installed; Anders wants binding for requestor asking for TEEP remote (such as in the cloud)
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.
HT: "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"?
MP: 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
HUM: 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
Per the humming RFC, asking if there objections to keeping the name?  
DAW: Wants to change name to avoid possible "v2" name competition/confusion
DW: 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 compromise
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 drafts?
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 drafts.
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 slides.
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.
DAW: SUIT manifest wasn't developed for attestation; I was surprised to see this.
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


---ADJOURNED---