Multi-Roundtrip TA Installation

[hannestschofenig]

If a TA installation that contains a SUIT manifest requires further interactions to perform a complete installation of dependencies then the TEEP Agent has to be given the ability to tell the TAM that further interactions are needed.

Hence, I should suggest to add the possibility to continue the TA installation after the TrustedAppInstall message.

Here is an example of what I have in mind:

+------------+           +-------------+
| TAM        |           |TEEP Agent   |
+------------+           +-------------+

  TrustedAppInstall ---->

                   <----   Continue

  TrustedAppInstall ---->

                           Success

                   <----    or

                           Error

[dthaler]

What is the use case for this? I can't think of one right now where this would be needed.

[hannestschofenig]

Manifests can be bundled with and without binaries. Additionally, a binary may have a dependency on another binary.

In those cases where the provided manifest came without a binary or when there is another binary needed (as a dependency) then we need to have a way for the TEEP Agent to get back to the TAM and inform the TAM that more binaries are needed.

(The same may be true for personalization data or configuration data that is referenced as a dependency.)

The mechanism above is what I am proposing to address this use case.

[dthaler]

In those cases where the provided manifest came without a binary or when there is another binary needed (as a dependency) then we need to have a way for the TEEP Agent to get back to the TAM and inform the TAM that more binaries are needed.

Since the TAM gets the list of TAs installed, then the TAM should be able to install the dependencies before pushing down the dependent manifest. Thus, success of a dependency install means the TAM can now do a TrustedAppInstall that depends on it.

(The same may be true for personalization data or configuration data that is referenced as a dependency.)

The mechanism above is what I am proposing to address this use case.

The only case I can think of where you have to pend things is if the personalization data comes via a different TAM.
E.g., an encrypted TA binary that one needs to get the key from another TAM (the case we discussed at the f2f editors meeting that ming hosted). We said then that the personalization data would be configured just like any TA would be (hence the "trusted component" language in the other PR). In such a case, I would propose just delaying the Success/Error response until it's done... the TEEP agent would initiate a new connection to the other TAM (as identified in the dependencies in the SUIT manifest), since it cannot complete the SUIT manifest install steps until that is done.

The "continue" proposal would not work in this case with different TAMs, whereas the approach I describe above does not need any "Continue" response and works with multiple TAMs.

[hannestschofenig]

You are making the TAM do all the dependency resolution upfront while I am trying to add a solution to the case where the client also does some degree of dependency resolution.

[dthaler]

You are making the TAM do all the dependency resolution upfront

No I am not. See my statement above which shows a client driven mechanism:

I would propose just delaying the Success/Error response until it's done... the TEEP agent would initiate a new connection to the other TAM (as identified in the dependencies in the SUIT manifest)

[dthaler]

Slide 7 of the TEEP protocol presentation covered this issue at IETF 109

The proposed resolution is:

Agent’s SUIT processor resolves dependencies, and doesn’t respond to initial Install until all dependencies are resolved and SUIT processing completes

The thing to note is that we still need to provide freshness (replay protection) of SUIT reports, so if we use a token or nonce, then the TAM has to store it while the install is outstanding.

[dthaler]

Issue #141 tracks the freshness discussion.

[dthaler]

Fixed in draft-06