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.