Minutes interim-2018-teep-01: Mon 10:00
minutes-interim-2018-teep-01-201810221000-00

TEEP Interim Meeting 22 October 2018

Attendees:
    Nancy Cam-Winget (chair)
    Dave Thaler (chair)
    Mingliang Pei
    Sorin Faibish
    Henk Birkholz
    Hannes Tschofenig
    David Wheeler (DavidW)

Chairs and authors met to go over open issues on September 17, Ming reviewed
notes from that meeting.

Ming started talking about the developments since the last IETF meeting in
Montreal. The most important developments have been:
     * Converted the architecture document to Markdown and moved the document
     into the public WG repository at https://github.com/ietf-teep/architecture
     * Hannes met with Ming to capture the open issues, which can be found at
     https://github.com/ietf-teep/architecture/issues * Editor meeting end of
     September. * Merged a few pull requests from DavidW.

Ming went through the notes of the last editor's meeting:

1) Trust Anchor vs. ROT (Root of Trust)

The current text in
https://github.com/ietf-teep/architecture/blob/master/draft-ietf-teep-architecture.md
captures the understanding of the relationship.

2) security domain concept was not removed, since no consensus so far to
remove.  Discussion can continue if desired.

DavidT: A single message to remove multiple trusted apps, is an example of an
"optimization" doable with security domain. In case that the trusted app will
be provided by other owner.

A provider is installing applications from 3rd party but not all the vendors is
using same domain. so, the provider is responsible for generating the key for
that 3rd party vendor?

DaveT: if TEE just tracks which TAM installed a TA, it can only accept changes
for that TA from that TAM (without needing a SD concept, it can just treat that
TAM as the owner).  If a TAM wants to keep track of SD concept inside the TAM,
without telling the TEE, it could do so internally.

Goal is to post a new I-D update before deadline later today (deadline is 5pm
Pacific)

3) Trusted Application Distribution

Distribution can happen with and without TAM. If binary is distributed by the
TAM it can be encrypted (for example when per-device specific configuration
data is needed). If the device-specific configuration data contains keys
DavidW.: in the SGX context most code is not encrypted and certain parts are
never encrypted.

DavidW.: There are potentially three pieces: 1) client app, 2) TA
loader/runtime, 3) TA application code If you use the (2) TA loader/runtime
then it is similar to TrustZone where #2 would be similiar to something like
OP-TEE.

Requirement:

Encrypted session goes between a TAM and an TEEP (OTrP) agent inside the TEE.  
That session goes over a transport channel that goes between the TAM and a
client application (not necessarily the client app that depends on the TA,
might be a system service/daemon).

If there is a desire to encrypt a specific TA, or piece of a specific TA, then
the TAM must be able to communicate some decryption key (whether device
specific or not) to the TEEP (OTrP) agent inside the TEE.  That agent might be
in the "TEE OS" (e.g., in TrustZone), or in a "loader" part of a TA (e.g., in
SGX).

4) Device administrator use case

DavidW. showed a new diagram and we discussed the notion of "Device
Administrator".

DavidT. says that he likes the device, as it shows multiple possible
configuration (single vs. multiple TEEs). The question is, however, whether the
figure should capture all configuration variants or rather just a subset of the
configurations.  Discussion of more complex variations could move into text and
keep the diagram simple(r).

During the lunch break we will update the diagram.

5) Who sends the initial message

The installer may send the first message to the TAM. There may not necessarily
be a service but rather a library. The plan is to put text in the draft about
alternative implementations for the TEEP broker.