Minutes IETF104: teep
minutes-104-teep-00

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]:
<dave asks a question> [DT]: Questions on Use cases are perfectly fine to keep
here. [DW]: We may move this to the protocol spec. <next slide> Attestation
Strructure In the end we want to align with EAT and RATS. From TEEP attestation
strtucture has <header> to determine if it is a standard form or a proprietary
form. <claims> and then <signature>. 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
SPs. <Etherpad down for a while> 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). <note: all of this is very
clearly discussed in the issue tracker for #7> [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
on RATS

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

### 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. <looking at
 slide OTRP Transport @ 104> 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) -
draft-ietf-teep-opentrustprotocol-02

### 6 AOB