Minutes IETF105: teep
minutes-105-teep-00


 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---