Minutes IETF104: teep

Meeting Minutes Trusted Execution Environment Provisioning (teep) WG
Title Minutes IETF104: teep
State Active
Other versions plain text
Last updated 2019-04-16

Meeting Minutes

   TEEP Working Group at IETF 104 in Prague, CZ
TUESDAY, 26 March 2019 at 0900

Jabber: xmpp:teep@jabber.ietf.org?join
MeetEcho: https://www.meetecho.com/ietf104/teep
Etherpad: https://etherpad.tools.ietf.org/p/notes-ietf-104-teep
Github: https://github.com/ietf-teep/

Scribe: Stephen Banghart
Notetakers: Jaime Jiménez, Ned Smith

# Agenda

### 1 Agenda bashing, Logistics -- Chairs (5 mins)
Nancy going through the agenda.

### 2 Architecture -- TBD (TBD mins) - draft-ietf-teep-architecture-02
Dave Wheeler presenting. Going through raised issues
at https://github.com/ietf-teep/architecture

- Issue #3 Trusted App Distribution
Clarification of the terminology: Client Apps, TA, Personalization Data.
Explaining the bundling variations, on how applications on the TE will be built.
Current spec will have something like an AIK (Attestation Idenity Key)

- Issue #8 Handling of multiple TEEs vs Single TEE
TEEP broker will manage the actions of the TEE, OS could combine them, but in
simplest case there is one TEE and one TEE Broker.

- Issue #14 Multiple TAMs for single Client App
TAM is associated with the TA, not Client App, but a Client App may depend on
multiple TAs Resolution - A client App manifest file can contain all TAMs it
may use to get TAs, normally just one There may be multiple TAs one for
different users/vendors/service provider etc. Any TAM can handle any TA. TEEP
Broker could use manifest to decide which TAM to use. Questions?

Dave Thaler [DT]: Regarding manifest file, where is the manifest file?
Dave Wheeler [DW]: Concept is the client app will include all the TAMs the SP
has pushed the app out to. That list of TAMs looks at its TA list to decide
which TAM it trusts. The manifest has TAM elements, where to get it and public
key. Mingjiang Pi [MP]: Client apps may use different TA from different
vendors, how do they acquire binaries from different TAs? If one client app
depends on 3 TAs still need to supply all three TAs to the TAM. Contrast to
alternative that a manifest file could have 3 TAs and can choose which TAM.
Questioning who owns selecting the TA. Jabber Henk [HB]: Trusted App and
Trusted Anchor, it is confusing. [DT]: Original question (slide 6) was that
Case 1 is the TAM the one creating the bundledle, by fetching all TAs and
sending the bundle back. [MP]: the Service Provider is the one that performs
that, it is reponsible to create the bundle. Hannes Tschofenig[HT]: the
manifest is in two places, one to describe the application, the other for the
App Developer context. [DW]: Closer alligned to Dave, SP creates application
with one or more TAs and creates a manifest with infor on TAMs and TAs. That
gets pushed out. Manifest provides all the information the TEEP B needs and is
pushed out by the service provider. We have not talked about where the manifest
is,. It is part of the Client App, which was pulled form a store and works with
the TEEP broker. We have not discussed where the installer gets the manifest
from. [DT]: The manifest doesn't have to include a separate location. [HT]:
Need to figure out the role of the manifest. [MP]: Might not have been well
specified (?). What are the requirements of the installer? Nancy
Cam-Winget[NC]: Need to go back to the issue on github. [DT]: is it a new
issue? [DW]: agrees it is a new issue especially as to format of manifest

[Issue]: File github issue on the manifest, does a client have to understand
multiple TAMs (NO) but format of manifest is open question.

- Issue #13 Is it in scope: TA depends on another TA and related installation?
This was discussed in the Interim sessions, but there are two concerns:
complexity is increased, creates a circular dependency. [DW]: Is there only 1
TA in an application? Are there circular dependancies? Are there different
versions at the same TA etc. We didn't resolve that. There were multiple
recommendations. Ming asking to defer to later. From Intel SGX, if TAs are
limited it would be limiting. Dave Waltermeier [DWal]? : What do you mean by
dependency [DWal]: If I have an application that wants to do authentication it
requires an authentication TA, that requires another TA for key storage.
[DWal]: How would we represent the nature of the dependency? [MP]: How do you
turn on video? OK I'll just speak. One app can have all TAs, but order is
important. If client app defines order then its is a simple case. TEEP
dependancies (order) need to be strictly carried out. Here we're talking about
a more complex case where client app can't figure things out. But if we can
move the responsibility to another level. It would be better.

[DT]: SUIT chair hat on. As chair of both groups I would like to have both
compatible. Brendan Moran, (who isn't in the room right now) gave feedback on
SUIT. The SUIT WG defines a manifest format, epressing order of install, etc.
It is also focused to optimise for firmware. Brendan will write on his document
a comment expressing that it could be used in other larger contexts. Teep could
use it as long as SUIT manifest can handle it it could be used by a different
WG. [NC]: Should not then TEEP express it as well? [DWal] We would need to do
that (allow other groups to define extensions to the manifest) [DT]: That is
correct. It is achievable in theory. [NC: Suggest to make draft available to
TEEP and in the next F2F or next interim have Brendan Moran there. [HT]: We
discussed two cases (i) trusted app (ii) multiple trusted apps being provided
either directly or as a reference. Need to write the correct ver. What is the
proper name etc.. so correct entries can be fetched. [DT]: Are we filing
another issue on github? [DW]: We have two different issues.

[Issue]: There is a second github issue to file. We will use Issue #13 to track
this discussion. Reference to SUIT working group and Brendan Moran Suit
Manifest format document. draft-moran-suit-manifest

[NC]: Do we need to relay that to SUIT?
[DT]: Can just be relied to them, the draft in quesiton will be presented
tomorrow morning. [MP]: I agree we should leverage SUIT manifest and send out
requirements to see if it meets our need. [DT]: Anyone having comments on the
requirements, it will be discussed tomorrow at SUIT. [NC]: Name of SUIT
manifest author? [DT]: Name is Brendan Moran: draft-moran-suit-manifest
[DW]: We need to create the manifest? Soirin Faibish [SF]: How will be the
relationship with SUIT? [DW] we'll refer to the manifest in SUIT [NC] We need
brendan to prresent to the group.

- Issue #17 Capabilities of the Attestation Mechanism
Dave presenting. Added text to the attesttation draft, presnting the draft
changes. We need to support both priprietary and standard attestation formats.
There is proposed format to put in the draft. We also need to align with RATS
and EAT attestation formats. [DW]: Attestation definition, the prester of the
claims is the attester, the entity that checks the claims is the Verifier. The
Verifier must be able to ensure the claims are correct. In our case the
Verifier is the TAM. It ensures the TEE is trustworthy. Asymmetric key pairs
are under the control of the TEE. The primary purpose is the attestation allows
device to proove to SP the properties are secure (correct). ??: It is not that
the claims are true but rather that the attester believes that the clame are
true, right? [DW]: Yes , thats correct [DW]: It will prove the identity of the
TA so that TAM or SP can authorize use of keys, identity of device or TA to
prevent masquerade attacks. It could be used to prevent aunauthorized devices
from installing attacks on the SP etc. [NC]: As chair of RATS, This is
effectively a use case of RATS currently under discussion. There will be
interdependencies. Please participate so it doesn't become too TEEP specific.
[DW]: We need to coordinate with DW. Ned agrees to coordinate with DW. Eric
Nordmark[EN]: It seems that when we are deep down in some details it would not
be surprising that we can have an unique identity on the TA (??) [DW]: Right.
so I agree with that in principle. Im struggling with how to assoicate with
TEEP which is a SP installing a TA into a device. [EN]: Service Provider could
be an ??? it is not necessarily a network provider. Seems it is closer to RATS
than TEEP. [DW] Yes correct. There are attestations that don't leak. EPID is
one of those. When talking about current standarrds RSA, ECDSA they are unique
identifiers (PII) and have privacy considerations. Difficultly understanding
where to place it. [EN]: My point for the WG don't try to solve this here but
do not prevent other to solve it by hardcoding thing with keys that are unique
per key. [DW]: OK, EPID and DAA would be part of proprietary attestation
formats that TEEP will accept. [NC]: Let's stop that now, as it is too specific
to the implementation and it might not be in scope for TEEP. (rather for RATS)
[HB]: Draft text doesn't highlight that TAM is taking the role of verifier. The
assertion presented has to spell this out specifically. Henk needs to clarifiy
(on jabber). Henk says Yes to DT response. [NC]: This belongs in the RATS WG.
[DT]: The question is the same as already made; "It is not that the claims are
true but rather that the attester believes that the clame are true, right?" And
the answer is the same, "yes" [DW]: The cryptographic properties are the
verifier needs to make assumptions about what is included in the attestation
implicitly. How as attestation key installed in the platform, what are the mfg
processes and procedures? How does a verifier know about compromises etc.
Verifier needs to be comfortable with the assumptions that are built in /
implicit. TAMs and SPs are free to say they don't trust MFG processes. It is
their security policy decision. (E.g. Implicit Attestation needs to be
understood better). Showing figure on 7.2.  TEEP Attestation Structure. [DW]:
[DT]: Questions on Use cases are perfectly fine to keep here. [DW]: We may move
this to the protocol spec.  Attestation Strructure In the end we want to align
with EAT and RATS. From TEEP attestation strtucture has  to determine if it is
a standard form or a proprietary form.  and then . I haven't gone to furthur
detail than this. Have had several discussions but more work is needed and more
input is welcome. [NC]: As chair of both WGs, form the TEEP perspective is good
to have the requirements, but this presentation would be good in RATS too.
[DW]: Unfortunately, DW will not be avilable to attend RATS (but available
online or a later time). [DW]: took the SGX attestation and identified the
elements that could be generalized. In SGX there are only two hierarchies, the
CPUSVN CPUSVN (CPU Security Version Number) telling us the version of the
microcode. There is also more information that can be used for identification,
as in the  MRENCLAVE, MRSIGNER, ... . There are cases in which you are only
checking the Security Version Number, which is the important part, not so much
the other parameters. Dave explains what an SVN is - the SVN isn't changed even
though the code veersion number changes. Only increment SVN when there is a
security relevant change to the TEE. [DW]: Still quite a bit of work to be done.

- Issue #7 Clarify meaning of Security Domain
Mingliang Pei  [MP] presenting. The problem is that there is overhead to manage

The proposal is to allow an implicit Security Domain (SD) per TA. We have
discussions in the issue tracker. Security Domain is a security boundary. It
has group or TS under the SD. It is a layer of the trust boundary. The term
"security domain" is described in the architecture document as: "A Security
Domain (SD) concept is used as the security boundary inside a TEE for trusted
applications." We added anonymous attestation key. I think discussion was what
if we don't need an AIK. When you create a SD / new key pair. The public key is
sent to TAM. SP can use key to encrypt personalization data to a Device. We
choose not to use TEE ? so each service provider can use his own key. (On slide
3 of 5).

[DW]: The discussion the authors had was trying to understand what the SD was
for. It boiled down to use: isolation mechanism for TAs, a key provisioning
mechanism, etc. Then we concluded that either we make it mandatory or we make
it implicit, Group TAs , or we make it optional or remove the concept. We have
not been able to decide. Right now the discussion is on the AIK. [HT]: At the
minimum we need to outline the feautes. You bring a new point, which is the
interaction with the service provider, which is not documented there. Currently
the protocol runs between the TEE and the broker, not all the way to the back.
[DT]:Lets go through the rest of the slides. [MP]: On slide 4 of 5. Whether
attestation is needed, encryption of ?? Which SP TAM sends is already in the
protocol. Whether a separate key (AIK) is needed is another concern. There is
an offline mode requirement. But how do you trust response from TEE? Response
can be verified by a local attestation key. Arguement from DT that alternate
DeviceID is a concern. Rich OS can hide hit. TEE certifiicate shuld be
accessable. E.g. Phone device can collect device certificates for all devices
it touches. Is this a privacy consideration? Potentially puts a burden on Rich
OS. [DW]: The fist thing to discuss is the AIK the right cryptographic item to
deal with encryption of personalization data? There are lots of things to
cosider. Symmetric keys play a role. All of the privacy issues surrounding use
of AIK for this purpose goes away. [NC]: Moving to next slide [MP]: So now this
was the separate AIK? TEE public key can be used for key wrapping (RSA?). That
is wrapped by the public key as a transport to the device. We can just use TEE
public key to transport. The Security Domain is fully needed. The only concern
is existing TEEs that doesn't support will need to support SD in their TAs.
[HT]: likes the idea of exploring simetric keys instead of AIK. Specially if SP
encrypts the metadata, there could be a reuse of the key. Having the SD
optional, would allow a roundtrip for the creation. The isolation concept will
be there anyways. [DW]: More specifically, If we make the security domain
implicit, anything installed from the same SP public key will go in the same
SD. A SP that does not owant that can use a different public key. [MP]: They
could do that as default behavior, If they want to use pub key as identifier
they could. [DT]: Hannes are you for/against the recommendation on the slide?
[HT]: in my opinion if you make the security domain implicit it gets removed
from the document. (Option n2 for issue #7) [DW]: Mandatory, Impicit, optional
or removed. #4 was DW recommendation (remove it). [HT]: For me it would be
implicit plus an extension that creates the SD. Prefer theuse of symetric key
for AIK. [MP]: If implicit then there is a separate key for that possibility.
[DT]: I have no objection for option 4. Debate is btw 2 and 4. I'd be fine with
have no normative text and instead having informative text. No objection to
Hannes option either. For the use cases that I have, the case of the TA having
its own key pair.... you have one key pair for TEE and another for TA, I see no
reason why I would need another key for the SD. I can figure out all issues
with the other two keys. [HT]: Option 4 would be fine for me as well. The SD
concept has been extremely confusing in all discussions. [DT]: I have no
problem with informative text but normative text is a challenge. [MP]: On the
symetric key part: we though about it at some point. Use of symmetric key poses
a security challenge. One per TA we have one per group of TAs. All other TAs
can decrypt the data. So only public key is given to the TA. Symmetric key is
always epheneral. This is for security reasons. [NC]: let's close this issue,
what we heard form authors and DT as individual contributor is that they are
fine with the reocmmendation on the use of symetric keys and remove security
domain from base protocol. Does the room have any objections. (No objection)
[Room]: Room is silent.

-Issue #18 Trust anchor update
[DW]: How are TAs installed. Requirements of TAs needs a separate document. We
don't need to go through manufacturing processes etc. DT forwarded requirements
changes regarding store to  SUIT.

- Issue #9 Install TA in single pass
[DW]: Defered to hackathon discussion

- Issue #10 Connection flow and model: local TEE request first to TAM rather
than TAM initiating [DW]: Defered to hackathon discussion [DW]: If you send
aigned attestation to a TAM you are revealing your identity. There are ways to
rresolve this. Install TA is the message that needs work. [HB]: There is
ongoing dsucssion on TAs in the YANG model. [DT]: NETCONF group is the one Eric
Voigh [EV]: Actually it is not Netconf, it is people from there but it will be

- Issue #12: Every Rich App Talks to TAM?
Noted that the document seems to assume that every rich app that needs a TA,
also needs to have code [DW]: there is some peice of code that talks to the
TAM. The client app integrates and talks to the TAM but it is just software
decomposition problem.

### 3 TEEP Hackathon report -- TBD (TBD mins)
Dave Thaler [DT] presenting the Hackathon report.
[DT]: Participants form ASAT, they have implementation already made.
[DT]: Formatting slides: We worked on all three drafts. As a reminder from last
hackathon. They have about 3 implementations of OtrP, Ming, Dave and the
Japanese folks, only two on each hackathon. Last IETF Dave tried to have JOSE
to run in SGX. [NC]: Its partly covered in HTTP draft and in OTRP? [DT]: Once
issue #2 is addressed it will require update of OTRP. [DT]: What I did in two
implementations (SGX/TZ). Others working on TZ and RISC-V and SGX. Since last
IETF there is Open Enclave SDK that supports SGX and Trustzone (TZ). The code
has been updated to match the latest HTTP transport spec. The summary of the
issues are in the slides. OTRP Protocol discussion: (Slide showing dsi.tee ) -
Issue #9 in dsi.tee, why are cert and cacert separate fields? So x5c requires a
JSON array where the first entry is the leaf cert, and in contrast the rest of
OTrP puts the leaf cert into a separate field and has the array only contain
the rest of the chain.

-Issue #10 What should tee "name" field contain?
The spec is silent on what the purpose of this field is, what it should
contain, and who defines the value to put in it.

-Issue 11: What should tee "ver" field contain?

-Issue 12: Relationship to existing/future attestation standards
[DT]: Is GetDeviceStateResponse an attestation message in which case should we
just reference RATS protocols?

[DT]: Quesitons?
[MP]: ??? When you send TEE name and version number, only the Name and version
are needed. We didn't require TEE name and version in the certificate.
Currently when TEE gens request all the infomation is include. [DT]: As an
implementer it would be better to leave thim in the paramaters and not in the

### 4 OTrP over HTTP -- Dave Thaler (TBD mins)
    - draft-thaler-teep-otrp-over-http-01
The OTrP specification [I-D.ietf-teep-opentrustprotocol] describes the behavior
of OTrP Agents and TAMs, but does not specify the details of the transport, an
implementation of which is referred to as a "Broker". [DT]: In arch doc the
terminology refeers to a confusing term. "TAMed Broker" should arch have this
term? (i) write a TAM using a TEE or (ii)just write the TAM service. The part
that implements the transport part vs. the full service should be
distingushable. [DW]: Should we say TEEP Agent instead of TEE? In the arch we
have a TEEP Agent and a TEEP Broker. Need to blow up the diagram for TAM. [DT]:
We need to cover the case where there is a TEE inside the TAM. [NC]: We can
have multiple diagrams with different blowups. [EN]: You could have
Microservices, QC, Load Balancer.... why do we care? No need to have another
document defining the TAM. [DT]: I think its necessary to talk about in
security considerations section. You have more risk without a TEE. [EN]: Should
we discussed security properties here? there are a lot of issues that have
nothing to do with the protocol. [DT]: If there is another implementer, then we
need to document it. [EN]: Then it could go on a separate document oriented to
implementation. [DT]: This isn't normative, what is wrong with inclucding in
the protocol spec? [EN]: having separate names creates more confusing. [DT]:
Lets look at later slides to see if the question is answered. [NC]: 4 Min.
[DT]: Last IETF slide showing. Changes from 00 to 01. HTTPBIS WG should pay
attention to draft-ietf-httpbis-bcp56bis-08
 Mark Nottingham said were doing it almost right. Need OTRP+JSON (use a
 specific media type). Instead of using a get use a 0-length post. Terminology
 invented to show symmetry.
[?]: Call it TAM Broker?
[DT]: Agent and Agent Broker for symmetry vs. other terms that aren't
symmetric. We have 2 implementations in progrress. [NC]: Does the group believe
this is needed for TEEP? Why doesn't it belong in this group? Show of hands -
has anyone reviewed the document? (4 hands + Ming). Are we ready to adopt? Any
objections? (no). Will be confirmed to the list. [NC]: Other order of business?
(No) Thank You!

### 5 Open Trust Protocol -- TBD (TBD mins) -

### 6 AOB