Subject: [Teep] clarification questions on draft-ietf-teep-architecture-14

From: Daniel Migault <[email-masked]>
Date: Sun, 21 Mar 2021 23:04:35 -0400

Hi,

I have been through the latest version of the teep architecture document
(draft-ietf-teep-architecture-14) and have a few clarifying questions. I
must say that most of these clarification questions are related to SGX.

Yours,
Daniel

     Trusted Execution Environment Provisioning (TEEP) Architecture
                    draft-ietf-teep-architecture-14

1.  Introduction

[...]

<mglt>

   TEEs use hardware enforcement combined with software protection to
   secure TAs and its data.  TEEs typically offer a more limited set of
   services to TAs than is normally available to Untrusted Applications.

Reading these sentences with SGX in
mind, I am reading that "software
protection" is the actual SGX software
implementation. Is that the correct
interpretation of "software protection"
?

>From the sentence above, "TEE offers a
limited set of services", I am reading
that some code running in REE will not
be able to run in a TEE. It is unclear
in term of services what these
limitations are at least in a SGX
context.  Of course in context switch
may be different in TEE as it is in REE,
and these limitations (may) impact the
performances of the TA.  I am wondering
if I am missing something or if the text
has been written with some TEE that are
not SGX ?

</mglt>

[...]

<mglt>
   To simplify the life of TA developers interacting with TAs in a TEE,

I am tempted to say that TA always run
in TEE, in which case "in a TEE" may be
redundant or may suppose that some TA
are not running in a TEE.  Note that it
appears at several different places in
the text.

</mglt>

   an interoperable protocol for managing TAs running in different TEEs
   of various devices is needed.
<mglt>
   This software update protocol needs to
   make sure that compatible trusted and untrusted components (if any)
   of an application are installed on the correct device.  In this TEE
   ecosystem, there often arises a need for an external trusted party to
   verify the identity, claims, and rights of TA developers, devices,
   and their TEEs.  This trusted third party is the Trusted Application
   Manager (TAM).

I am reading "this software update
protocol" as limiting the ability to
upgrade an already installed
application.  I have the impression that
installation of a software is in scope
and that in this case, installation will
only be permitted depending on the TEE
version.  If this is included in the
term "software upgrade" I have the
impression these tasks are beyond a
software upgrade.

</mglt>

   The Trusted Execution Environment Provisioning (TEEP) protocol
   addresses the following problems:

   -  An installer of an Untrusted Application that depends on a given
      TA wants to request installation of that TA in the device's TEE so
      that the Untrusted Application can complete, but the TEE needs to
      verify whether such a TA is actually authorized to run in the TEE
      and consume potentially scarce TEE resources.

<mglt>
   -  A TA developer providing a TA whose code itself is considered
      confidential wants to determine security-relevant information of a
      device before allowing their TA to be provisioned to the TEE
      within the device.  An example is the verification of the type of
      TEE included in a device and that it is capable of providing the
      security protections required.

My first question reading this paragraph
concerns the TA developer versus the TA
manager or device manager.  I am tempted
to see these as two different roles, but
I would say the responsibility to
install a TA with a certain level of
version of the TEE is more likely to be
the responsibility of the TAM or a
Device Manager than the TA developer.
This may not exclude that TAM and TA
developer have a specific agreement and
some conditions are provided by the TA
developer.

I am reading this text as a TA developer
or manager evaluates the trustworthiness
of the REE, but I would tempted to
consider such information as unlikely to
be reliable, so I am wondering if there
is anything I am missing.

I understand that the TEE version and
associated level of security are defined
in SGX by the CPUSVN.  If that is the
case and unless I am missing something,
I only see CPUSVN as being mentioned in
the REPORT, which includes an
attestation process, in which case, a TA
or TA installer may already have been
instantiated. So I am wondering if I am
not missing anything.  To sum up, I am
wondering if - in an SGX environment -
CPUSVN is in scope to be checked before
installing a TA, and if so if that are
any other way to get the value than by
proceeding to an attestation.

While not related to the code itself,
but some sort of secret credentials
associated to the TA, I believe that a
TA Manager may check the level of trust
of the TEE before provisioning the TA
with secrets.  I am wondering if that is
part of TEEP with Personalization Data
or if such instantiation is always
delegated to the TA. More specifically,
the TA sets a trusted communication with
the TAM that pushes the secret
credentials.
Now that I have read the full spec, it
seems that the bundle description
somehow addresses this, but I think that
mentioning the configuration of a TA in
the introduction or overview section
would ease the reading.

</mglt>

<mglt>

   -  A TEE in a device wants to determine whether an entity that wants
      to manage a TA in the device is authorized to manage TAs in the
      TEE, and what TAs the entity is permitted to manage.

With SGX in mind, the "TEE wants to
determine looks strange" as I see TEE as
a platform that manages TAs.  I
understand the text willing to ensure
that only authorized TAM access
authorized TAs. Unless I am missing
something, the wording seems a bit
complex.

</mglt>

   -  A Device Administrator wants to determine if a TA exists (is
      installed) on a device (in the TEE), and if not, install the TA in
      the TEE.

   -  A Device Administrator wants to check whether a TA in a device's
      TEE is the most up-to-date version, and if not, update the TA in
      the TEE.

   -  A Device Administrator wants to remove a TA from a device's TEE if
      the TA developer is no longer maintaining that TA, when the TA has
      been revoked or is not used for other reasons anymore (e.g., due
      to an expired subscription).

   For TEEs that simply verify and load signed TA's from an untrusted
   filesystem, classic application distribution protocols can be used
   without modification.  The problems in the bullets above, on the
   other hand, require a new protocol, i.e., the TEEP protocol, for TEEs
   that can install and enumerate TAs in a TEE-secured location and
   where another domain-specific protocol standard (e.g., [GSMA],
   [OTRP]) that meets the needs is not already in use.

<mglt>
I think it would be better to move this
text above to say in specific TEE's
environment we do have the following
restrictions as opposed to list some
issues and then say that this issues
only concerns some specific environment.

>From this text, I also understand that
the architecture and TEEP is not needed
for SGX.  It is however unclear to me
whether all problems can be addressed by
these classic application distribution
can be used.  As mentioned above, it is
unclear to me how the CPUSVN can be
returned.

I think that additional clarifications
might be needed to mention whether the
TEE that do not have the problems
mentioned in the bullets - in I assume
SGX is one of these - could use TEEP.
In this case TEEP could be used as a
standard protocol for any TEE platforms.
To sum up I would like to understand:
Whether there is a need or an advantage
in implementing TEEP for SGX or whether
TEEP and SGX are somehow orthogonal.

</mglt>

[...]

4.  Architecture

4.1.  System Components

[...]

<mglt>
      A Trusted Component Signer or Device Administrator chooses a
      particular TAM based on whether the TAM is trusted by a device or
      set of devices.  The TAM is trusted by a device if the TAM's
      public key is, or chains up to, an authorized Trust Anchor in the
      device.  A Trusted Component Signer or Device Administrator may
      run their own TAM, but the devices they wish to manage must
      include this TAM's public key or certificate, or a certificate it
      chains up to, in the Trust Anchor Store.

The definition of Trust Anchor Store
implicitly seems to say the TAS is in
the TEE.  If that is the case, it might
worth being mentioned explicitly.

</mglt>

[...]

<mglt>
   -  TEEP Broker: A TEEP Broker is an application component running in
      a Rich Execution Environment (REE) that enables the message
      protocol exchange between a TAM and a TEE in a device.  A TEEP
      Broker does not process messages on behalf of a TEE, but merely is
      responsible for relaying messages from the TAM to the TEE, and for
      returning the TEE's responses to the TAM.  In devices with no REE
      (e.g., a microcontroller where all code runs in an environment
      that meets the definition of a Trusted Execution Environment in
      Section 2), the TEEP Broker would be absent and instead the TEEP
      protocol transport would be implemented inside the TEE itself.

I am wondering if in the case of SGX the
TEEP Broker is the untrusted application
itself.  If so this might worth being
specified explicitly.

</mglt>

[...]

4.2.  Multiple TEEs in a Device

<mglt>
   Some devices might implement multiple TEEs.  In these cases, there
   might be one shared TEEP Broker that interacts with all the TEEs in
   the device.  However, some TEEs (for example, SGX [SGX]) present
   themselves as separate containers within memory without a controlling
   manager within the TEE.  As such, there might be multiple TEEP
   Brokers in the REE, where each TEEP Broker communicates with one or
   more TEEs associated with it.

I do not see the controlling manager
being defined in the architecture, so
unless that is a component we need to
introduce I am wondering if mentioning
that "some TEEs (for example, SGX [SGX])
present themselves as separate
independent containers or enclaves"
might not be clearer.

>From the text I also understand that for
SGX, each enclave is thought as a TEE.
In my perspective I would have seen the
enclave as a TA and TEE being the SGX
platform, in which case I would have
been tempted to say that SGX only have
one TEE.

There is one Agent per TEE, but it seems
to me that having one per enclave or one
for the platform would be implemented as
a service provided by the platform, that
is a specific enclave. I am wondering if
this is how the TEEP agent is enjoined
to be implemented in SGX ?

If that is the case, and multiple TEEP
agent could be instantiated with TA's
selecting one of these  Agent, we could
lean to have one agent per enclave and
so having a TEE being an enclave could
be appropriated. However, an enclave
could also have more than one Agent
which does not seem to be considered.
Though I am not sure this really
matters. but it seems to me clearer to
have the Agent as part of the SGX
platform. The Agent be whatever the TA
has selected to complete the Agent
function.

If the TEE designates the enclave I
would like to understand where SGX is
represented as well as what am I
missing.

</mglt>

<mglt>
   It is up to the REE and the Untrusted Applicat ions how they select
   the correct TEEP Broker.  Verification that the correct TA has been
   reached then becomes a matter of properly verifying TA attestations,
   which are unforgeable.

Untrusted Applications is misspelt.

I think I see the Broker as being the
untrusted application in SGX. I am
wondering if that makes sense and if
there are other ways.

I would also be happy to understand how
the broker can ensure the correct TA is
being reached.
If "correct" has anything related to
authentication. I would think of local
attestation between two enclaves, but
that seems to defy the purpose of the
broker being a REE.

</mglt>

[...]

4.4.  Untrusted Apps, Trusted Apps, and Personalization Data

[...]

<mglt>
   There are three possible cases for bundling of an Untrusted
   Application, TA(s), and Personalization Data:

   1.  The Untrusted Application, TA(s), and Personalization Data are
       all bundled together in a single package by a Trusted Component
       Signer and either provided to the TEEP Broker through the TAM, or
       provided separately (with encrypted Personalization Data), with
       key material needed to decrypt and install the Personalization
       Data and TA provided by a TAM.

I suppose that in this case the
termination point of the TAM
communication is the broker, and the
broker is then responsible to dispatch
the TA and Personalization data to the
TEE and the Untrusted Application to the
REE.  I believe the reason for
encrypting the Personalization Data is
to perform end to end communication
between the TAM and the Agent.  I
believe the clarification would help the
reading. I also assume that the TAM will
use the public key of the Agent.
Overall I believe that this scenario
multiplexes two sort of end to end
communications. Some communications
between the TAM and Broker are related
to untrusted world while TAM or
developer - Agent are related to the
trusted worlds.
I would like to clarify between
Untrusted App, TA, and Personalization
Data what is the final destination, what
is encrypted and what key material is
used.
</mglt>

4.4.1.  Example: Application Delivery Mechanisms in Intel SGX

[...]

<mglt>
This
   installation is complex because the Untrusted Application decrypted
   inside the TEE must be passed out of the TEE to an installer in the
   REE which would install the Untrusted Application; this assumes that
   the Untrusted Application package includes the TA code also, since
   otherwise there is a significant problem in getting the SGX enclave
   code (the TA) from the TEE, through the installer, and into the
   Untrusted Application in a trusted fashion.

At this point it seems the TAM
terminates the session to the Agent to
which the full bundle is provided.  As
exposed in the section above the bundle
may be composed of different pieces some
of them are forwarded to the Agent
others are left to the REE. In that
sense the bundle could be seen as
multiplexing different communications.

I am wondering why such scenario could
not be considered in SGX.

</mglt>

Finally, the
   Personalization Data would need to be sent out of the TEE (encrypted
   in an SGX enclave-to-enclave manner) to the REE's installation app,
   which would pass this data to the installed Untrusted Application,
   which would in turn send this data to the SGX enclave (TA).  This
   complexity is due to the fact that each SGX enclave is separate and
   does not have direct communication to other SGX enclaves.

   As long as signed files (TAs and/or Personalization Data) are
   installed into an untrusted filesystem and trust is verified by the
   TEE at load time, classic distribution mechanisms can be used.

<mglt>
Some
   uses of SGX, however, allow a model where a TA can be dynamically
   installed into an SGX enclave that provides a runtime platform.  The
   TEEP protocol can be used in such cases, where the runtime platform
   could include a TEEP Agent.

I am not familiar with the term runtime
platform, but I suppose that the Agent
would be an Intel specific enclave.
If that is correct, I suppose this
enclave would be shared by all TAs. I am
wondering if that is what is meant by
the text ?

</mglt>

[...]

4.5.  Entity Relations

[...]

<mglt>
   At step 3, a user will go to an Application Store to download the
   Untrusted Application (where the arrow indicates the direction of
   data transfer).

The arrow direction might be indicated
in the figure or with the first arrow
being represented.  In that case this
may correspond to the certificate
provisioning.  It seems to me - unless I
have missed it
- that certificates provisioning is
missing. If so this is clearly a nits.

</mglt>

   At step 4, since the Untrusted Application depends on the TA,
   installing the Untrusted Application will trigger TA installation by
   initiating communication with a TAM.

<mglt>
The TEEP Agent will interact
   with TAM via a TEEP Broker that faciliates communications between a
   TAM and the TEEP Agent in TEE.

facilite maybe that is facilitate. This
is a nits.

</mglt>

[...]

5.  Keys and Certificate Types

[...]

<mglt>
   Figure 4 summarizes the relationships between various keys and where
   they are stored.  Each public/private key identifies a Trusted
   Component Signer, TAM, or TEE, and gets a certificate that chains up
   to some trust anchor.  A list of trusted certificates is then used to
   check a presented certificate against.

I have the impression so far that TEE
has not been involved into any
authentication.  I suspect that TEE and
TEEP Agent represent the same entity. If
that is correct I think that would worth
some clarification why we can use one
for the other and why we need to have
two distinct entities that share the
same identity.

</mglt>

[...]

<mglt>

5.2.  Trust Anchors in a TEE

   A TEE determines whether TA binaries are allowed to execute by
   verifying whether their signature can be verified using
   certificate(s) or raw public key(s) in the TEE's Trust Anchor Store.
   The list is typically preloaded at manufacturing time, and can be
   updated using the TEEP protocol if the TEE has some form of "Trust
   Anchor Manager TA" that has Trust Anchors in its configuration data.
   Thus, Trust Anchors can be updated similar to updating the
   Personalization Data for any other TA, as discussed in Section 5.1.

I am wondering if the current SGX does
not have ANY key in its Trust Anchor
Store as it simply validates the
signature of the code at the
instantiating (EINIT).

It is a bit confusing - at least to me -
at that point what are the roles of the
Agent versus the TEE. It might be a
consequence of the previous questions I
asked myself that confused me.

</mglt>

[...]

6.2.  TEEP Broker Implementation Consideration

[...]

<mglt>
                           Model:    A      B      C     ...

                                    TEE    TEE    TEE
        +----------------+           |      |      |
        |      TEEP      |     Agent |      |      | Agent
        | implementation |           |      |      |
        +----------------+           v      |      |
                 |                          |      |
        +----------------+           ^      |      |
        |    TEEP/HTTP   |    Broker |      |      |
        | implementation |           |      |      |
        +----------------+           |      v      |
                 |                   |             |
        +----------------+           |      ^      |
        |      HTTP      |           |      |      |
        | implementation |           |      |      |
        +----------------+           |      |      v
                 |                   |      |
        +----------------+           |      |      ^
        |   TCP or QUIC  |           |      |      | Broker
        | implementation |           |      |      |
        +----------------+           |      |      |
                                    REE    REE    REE

                       Figure 5: TEEP Broker Models

I am wondering if TLS could be included
into the TEE.  It is correct that I do
not envision TCP being in the TEE.

</mglt>

[...]

6.2.1.  TEEP Broker APIs

   The following conceptual APIs exist from a TEEP Broker to a TEEP
   Agent:

   1.  RequestTA: A notification from an REE application (e.g., an
       installer, or an Untrusted Application) that it depends on a
       given Trusted Component, which may or may not already be
       installed in the TEE.

<mglt>
   2.  UnrequestTA: A notification from an REE application (e.g., an
       installer, or an Untrusted Application) that it no longer depends
       on a given Trusted Component, which may or may not already be
       installed in the TEE.  For example, if the Untrusted Application
       is uninstalled, the uninstaller might invoke this conceptual API.

I understand Unrequest as being
equivalent to undo, or remove or
uninstall. If that is correct, I am
wondering if there are any reasons for
non calling it remove or uninstall ?

</mglt>

[...]

7.  Attestation

   Attestation is the process through which one entity (an Attester)
   presents "evidence", in the form of a series of claims, to another
   entity (a Verifier), and provides sufficient proof that the claims
   are true.

<mglt>
Different Verifiers may require different degrees of
   confidence in attestation proofs and not all attestations are
   acceptable to every verifier.

the last verifier should be Verifier in
my opinion. If that is correct the nits
appears at multiple locations. This is a
nit.

</mglt>

[...]

9.  Security Considerations

9.2.  Data Protection

[...]

<mglt>

   The protocol between TEEP Agents and TAMs similarly is responsible
   for securely providing integrity and confidentiality protection
   against adversaries between them.  Since the transport protocol under
   the TEEP protocol might be implemented outside a TEE, as discussed in
   Section 6, it cannot be relied upon for sufficient protection.  The
   TEEP protocol provides integrity protection, but confidentiality must
   be provided by payload encryption, i.e., using encrypted TA binaries
   and encrypted attestation information.  See [I-D.ietf-teep-protocol]
   for more discussion.

There is also the case where a session
is established between the TAM and the
Agent.  If used this would require HTTP
to be in the TEE.

</mglt>

-- 
Daniel Migault
Ericsson

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Mar 2021 09:10:00 +0000

Hi Daniel,

Thanks for reading carefully through the draft.

Many of your questions relate to the use of TEEP for Intel SGX. I cannot answer those questions and the architecture was written to be independent of a particular TEE instantiation. I will skip the SGX related questions and someone else (maybe from Intel) can answer those.

Let me answer your questions that are unrelated to SGX.

~ snip ~

<mglt>

[Hannes] The issue is that there is the TA in the secure world but then you also need code elsewhere to interact with it. In fact, there will have to be code pretty much everywhere (at least in TrustZone) to allow the transition from the app running in the normal world to the TA running in the secure world. It may sound like an easy thing to do but it isn’t in practice and the TF-M and OP-TEE code show this, see https://www.trustedfirmware.org/

</mglt>

[Hannes] We also cover installation and deletion of software. Maybe we should expand the sentence to make this clearer.

</mglt>

<mglt>

[Hannes] I think both entities need to work together. The TA developer writes the TA code and understands for what application it is meant to be used (at least typically). It might also have requirements on the type of TEE. An operator of  a TAM needs to decide what it wants to send to devices.

[Hannes] They may have an agreement or in other cases the relationship may be pretty loose.

[Hannes] Imagine that a TEE developer writes an app that does some machine learning and he only wants to release the code to devices that implement certain security features in the TEE. He would work together with the TAM operator to ensure that those requirements are met and the attestation functionality offered by the TEEP protocol gives him or her that assurance.

~snip~

with secrets.
[Hannes] Yes.

I am wondering if that is
part of TEEP with Personalization Data
or if such instantiation is always
delegated to the TA.

[Hannes] This is part of the TEEP protocol. The ability to protect (encrypt) personalization data is offered by SUIT.

More specifically,
the TA sets a trusted communication with
the TAM that pushes the secret
credentials.
[Hannes] Sort-of. Details about the SUIT part will be added in a SUIT document on how the encryption looks like.

[Hannes] This is maybe the wrong document; the TEEP protocol document could give an example or should go into the details of this. My take-away from the last meeting was that we will cover this in a separate document in SUIT.

</mglt>

~snip~

[...]

4.  Architecture

4.1.  System Components

[...]

<mglt>

[Hannes] The trust anchor may not necessarily be in the same TEE that is running the TA. It could also be in an attached crypto processor / secure element.

</mglt>

~snip~

[...]

[...]

<mglt>

[Hannes] There are different layers of communiation, as shown in Figure 1. Section 4.4 only talks about how the different software components & personalization data may get to the device. Section 4.4 really has to be read in combination with the text related to Figure 1.

~snip~

[...]

4.5.  Entity Relations

[...]

<mglt>

</mglt>

[Hannes] Here is the figure:

    (App Developers)   (App Store)   (TAM)      (Device with TEE)  (CAs)
           |                   |       |                |            |
           |                   |       |      (Embedded TEE cert) <--|
           |                   |       |                |            |
           | <--- Get an app cert -----------------------------------|
           |                   |       |                |            |
           |                   |       | <-- Get a TAM cert ---------|
           |                   |       |                |            |
   1. Build two apps:          |       |                |            |
                               |       |                |            |
      (a) Untrusted            |       |                |            |
          App - 2a. Supply --> | --- 3. Install ------> |            |
                               |       |                |            |
      (b) TA -- 2b. Supply ----------> | 4. Messaging-->|            |
                               |       |                |            |

What certificate provisioning is missing?

[...]

<mglt>

</mglt>

[Hannes] A TEE is a system concept, which includes a combination of hardware and software.
Hence, you cannot really state something like "the TEE authenticates X". The TEE and the TEEP Agent are also not the same thing.

Figure 4 really only focuses on the security keys and tries to avoid going too much into details of how an implementation on a specific TEE works.
[...]

[...]

[...]

<mglt>
                           Model:    A      B      C     ...

                                    TEE    TEE    TEE
        +----------------+           |      |      |

[Hannes] This can be done and is done regularly. I think we should update the figure to include this option since it is very common.
I added this issue: https://github.com/ietf-teep/architecture/issues/222

</mglt>

[...]

6.2.1.  TEEP Broker APIs

<mglt>

</mglt>

[Hannes] The reason is that a TA may be needed by another TA and hence you cannot just delete it. You can only say that you do not need it anymore.
Once nobody needs it anymore it can be removed by the system, if necessary.

[...]

7.  Attestation

<mglt>

</mglt>

[Hannes] We just used the terms from the RATS group.

[...]

9.2.  Data Protection

[...]

<mglt>

[Hannes] Yes, you could run HTTP into the TEE and this is done as well.
For the TEEP protocol you do, however, need to make some decisions about how you want to design the system and the current design assumes that there are cases where HTTP is terminated outside the TEEP.
Is this a good design? We will see.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Daniel Migault <[email-masked]>
Date: Tue, 23 Mar 2021 09:24:24 -0400

Hi Hannes,

Thanks for the clarifications. Please find my responses inline.

Yours,
Daniel

On Tue, Mar 23, 2021 at 5:10 AM Hannes Tschofenig <[email-masked]>
wrote:

> Many of your questions relate to the use of TEEP for Intel SGX. I cannot
> answer those questions and the architecture was written to be independent
> of a particular TEE instantiation. I will skip the SGX related questions
> and someone else (maybe from Intel) can answer those.
>
>
>
<mglt>
just to clarify, I agree that the description is TEE technologie
independent, but I just willing to align the text with my understanding of
SGX. Overall I believe that the text in section 4.4 that positioned the
abstract architecture toward TrustZone and SGX was very clarifying and
believe that more example sections or appendices sections related to
existing implementation might be clarifying.
</mglt>

> [Hannes] The issue is that there is the TA in the secure world but then
> you also need code elsewhere to interact with it. In fact, there will have
> to be code pretty much everywhere (at least in TrustZone) to allow the
> transition from the app running in the normal world to the TA running in
> the secure world. It may sound like an easy thing to do but it isn’t in
> practice and the TF-M and OP-TEE code show this, see
> https://www.trustedfirmware.org/
>
>
>
<mglt>
Thanks for the link. This is obviously not a huge issue - at least to me -
but it sounds to me that TA may designate different things depending on the
TEE technology and it might be clarifying to illustrate what it means in
SGX and TrustZone. There are potentially multiple ways to do that and maybe
an illustrative example in the appendix would be in my opinion enough so to
avoid major changes in the text.
</mglt>

> [Hannes] We also cover installation and deletion of software. Maybe we
> should expand the sentence to make this clearer.
>
>
>
<mglt>
I think that would good. This would have at least prevent me wondering this
question. .
</mglt>

> [Hannes] I think both entities need to work together. The TA developer
> writes the TA code and understands for what application it is meant to be
> used (at least typically). It might also have requirements on the type of
> TEE. An operator of  a TAM needs to decide what it wants to send to
> devices.
>
>
>
<mglt>
So I understand the developer specifies a code for a specific type of TEE.
I think I misread "type of TEE", reading your response, it seems that type
of TEE designates SGX or TrustZone as opposed to the different version
proposed by SGX or TrustZone. If that the case, it sounds relatively
obvious to me that app.trustzone and app.sgx are different app and the
developper chose where the app is expected to run. In my inital comment, I
read type of TEE as a TEE version with some microcodes enables. This means
that app.sgx is likely to run on every declination of it and the actual
configuration or instantiation of the TEE cannot - as I understand be
decided but the application developer. As I understand it, the
configuration of the TEE is revealed during the attestation.
If that is correct, I would say that mentioning (TrustZone or SGX) after
type of TEE would have been clearer to me.

</mglt>

> [Hannes] They may have an agreement or in other cases the relationship may
<mglt>
ok
</mglt>

> [Hannes] Imagine that a TEE developer writes an app that does some machine
> learning and he only wants to release the code to devices that implement
> certain security features in the TEE. He would work together with the TAM
> operator to ensure that those requirements are met and the attestation
> functionality offered by the TEEP protocol gives him or her that assurance.
>
>
>
<mglt>
I understand the use case. I think what my concern was that with SGX, my
understanding is that enclaves are built from the REE and code is loaded
from the REE.  In this case, that seems to me difficult to ensure
confidentiality with a level equivalent to the one associated to the one
provided by a TEE. It seems to me that TrustZone would enable to provision
the code directly to the TEE via the agent without passing through the REE.
I think that would be good to specify that the problem is only related to
one TEE technology.
</mglt>

> [Hannes] This is part of the TEEP protocol. The ability to protect
> (encrypt) personalization data is offered by SUIT.
>
>
>
<mglt>
ok
</mglt>

> [Hannes] Sort-of. Details about the SUIT part will be added in a SUIT
> document on how the encryption looks like.
>
> <mglt>
ok, thanks.
</mglt>

> [Hannes] This is maybe the wrong document; the TEEP protocol document
> could give an example or should go into the details of this. My take-away
> from the last meeting was that we will cover this in a separate document in
> SUIT.
>
>
>
<mglt>
What I meant was that the bundle section provided a sufficient high level
view of how it works. To me a simple referenc eto that section would be
sufficient. Of course additional details and a reference to a suit document
may be better, but I do not think that is necessary in that document.
</mglt>

> [Hannes] The trust anchor may not necessarily be in the same TEE that is
> running the TA. It could also be in an attached crypto processor / secure
> element.
>
<mglt>
ok.thanks.
</mglt>

> [Hannes] There are different layers of communiation, as shown in Figure 1.
> Section 4.4 only talks about how the different software components &
> personalization data may get to the device. Section 4.4 really has to be
> read in combination with the text related to Figure 1.
>
>
>
<mglt>
ok thanks for the clarification. I am tempted to say that maybe the text
could be a bit more explicit to ease connecting the dots.
</mglt>

> What certificate provisioning is missing?
<mglt>
I have not found the description of the 3 first arrows - unless I am
missing it.
</mglt>

> Hence, you cannot really state something like "the TEE authenticates X".
> The TEE and the TEEP Agent are also not the same thing.
>
>
>
<mglt>
I agree that I had issue with "the TEE authenticates X" and similarly to "X
authenticates TEE" but this is how I am reading the section 5 "Keys and
certificates Types. I have the impression that TEE should be replaced by
TEEP Agent.
</mglt>

> Figure 4 really only focuses on the security keys and tries to avoid going
> too much into details of how an implementation on a specific TEE works.
>
> [...]
>
>
>
>
>
> [...]
>
>
>
> [Hannes] This can be done and is done regularly. I think we should update
> the figure to include this option since it is very common.
>
<mglt>
thanks.
</mglt>

> [Hannes] The reason is that a TA may be needed by another TA and hence you
> cannot just delete it. You can only say that you do not need it anymore.
>
<mglt>
thanks for the clarification. I think that would worth having it mentioned.
</mglt>

> [Hannes] We just used the terms from the RATS group.
<mglt>
I just mentioned there were a mix of verifier and Verifier and I suppose
that is not intentional.
</mglt>

> For the TEEP protocol you do, however, need to make some decisions about
> how you want to design the system and the current design assumes that there
> are cases where HTTP is terminated outside the TEEP.
>
<mglt>
I see your point. [I-D.ietf-teep-protocol] made a choice the text is based
upon. I think that might be clarified up front that this results from a
choice and it is not an architecture design.
</mglt>

>
>
> Ciao
>
> Hannes
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>

-- 
Daniel Migault
Ericsson

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 25 Mar 2021 15:44:09 +0000

Hi Daniel,

It came to my mind that the workshop talk by Akira, where he speaks about TEEP on RISC-V: https://www.youtube.com/watch?v=-nSpxRr1sYo, could be of interesting to you. It talks about another TEE in detail.
You might also want to join our hackathons. That could give you even more insight into the software architecture (since some of your questions are related to it).

Anyway, a few remarks below...

<mglt>

<mglt>
Thanks for the link. This is obviously not a huge issue - at least to me - but it sounds to me that TA may designate different things depending on the TEE technology and it might be clarifying to illustrate what it means in SGX and TrustZone. There are potentially multiple ways to do that and maybe an illustrative example in the appendix would be in my opinion enough so to avoid major changes in the text.
</mglt>

[Hannes] The issues is that this requires a lot of explanation. TrustZone has different variants – for A and for M class. TrustZone for A class exists with and without secure world hypervisor. Then, there are also different software stacks running on the A- and M-class devices, which would impact a description. Then, TrustZone is a system level concept, which includes peripherals. Hence, it depends on the entire SoC system design. I understand that it would be useful to have such a description but it also takes a lot of time.

</mglt>

<mglt>
I think that would good. This would have at least prevent me wondering this question. .
</mglt>

[Hannes] I created a PR here: https://github.com/ietf-teep/architecture/pull/223

</mglt>

<mglt>

<mglt>
So I understand the developer specifies a code for a specific type of TEE. I think I misread "type of TEE", reading your response, it seems that type of TEE designates SGX or TrustZone as opposed to the different version proposed by SGX or TrustZone. If that the case, it sounds relatively obvious to me that app.trustzone and app.sgx are different app and the developper chose where the app is expected to run. In my inital comment, I read type of TEE as a TEE version with some microcodes enables. This means that app.sgx is likely to run on every declination of it and the actual configuration or instantiation of the TEE cannot - as I understand be decided but the application developer. As I understand it, the configuration of the TEE is revealed during the attestation.
If that is correct, I would say that mentioning (TrustZone or SGX) after type of TEE would have been clearer to me.

</mglt>

<mglt>
ok
</mglt>

<mglt>
I understand the use case. I think what my concern was that with SGX, my understanding is that enclaves are built from the REE and code is loaded from the REE.  In this case, that seems to me difficult to ensure confidentiality with a level equivalent to the one associated to the one provided by a TEE. It seems to me that TrustZone would enable to provision the code directly to the TEE via the agent without passing through the REE.
I think that would be good to specify that the problem is only related to one TEE technology.
</mglt>

[Hannes] Normally, communication happens through the REE and not directly to the TEE. It is, however, possible to have peripherals connected directly to the TEE. This is rather the exception. Dave Thaler has worked on such a prototype, if I recall correctly.

 Confidentiality of communication to the TA is ensured by having the security terminate in the TEE rather than in the REE.
~snip~

<mglt>
ok
</mglt>
More specifically,

<mglt>
What I meant was that the bundle section provided a sufficient high level view of how it works. To me a simple referenc eto that section would be sufficient. Of course additional details and a reference to a suit document may be better, but I do not think that is necessary in that document.
</mglt>

[Hannes] In the TEEP protocol draft we have references to SUIT and RATS, of course. For the architecture document, which should ideally be agnostic to the solution details, we thought it would better not to go into those details.

</mglt>

~snip~

[...]

4.  Architecture

4.1.  System Components

[...]

<mglt>

</mglt>

~snip~

[...]

[...]

<mglt>

<mglt>
ok thanks for the clarification. I am tempted to say that maybe the text could be a bit more explicit to ease connecting the dots.
</mglt>

[Hannes] If you have ideas on how to better phrase it, feel free to make a suggestion.

~snip~

[...]

4.5.  Entity Relations

[...]

<mglt>

</mglt>

<mglt>
I have not found the description of the 3 first arrows - unless I am missing it.
</mglt>

Here is a picture:

[...]

<mglt>

</mglt>

<mglt>
I agree that I had issue with "the TEE authenticates X" and similarly to "X authenticates TEE" but this is how I am reading the section 5 "Keys and certificates Types. I have the impression that TEE should be replaced by TEEP Agent.
</mglt>

[Hannes] I created an issue regarding Figure 4: https://github.com/ietf-teep/architecture/issues/224

[...]

[...]

<mglt>
                           Model:    A      B      C     ...

                                    TEE    TEE    TEE
        +----------------+           |      |      |

</mglt>

<mglt>
thanks.
</mglt>
[...]

6.2.1.  TEEP Broker APIs

<mglt>

</mglt>

<mglt>

7.  Attestation

<mglt>

</mglt>

<mglt>
I just mentioned there were a mix of verifier and Verifier and I suppose that is not intentional.
</mglt>

[Hannes] Is your confusion the mix between “verifier” and “Verifier”?

[...]

9.2.  Data Protection

[...]

<mglt>

<mglt>
I see your point. [I-D.ietf-teep-protocol] made a choice the text is based upon. I think that might be clarified up front that this results from a choice and it is not an architecture design.
</mglt>

[Hannes] I added an issue about this:
https://github.com/ietf-teep/architecture/issues/225

Ciao
Hannes

Thanks again for your review.

Ciao
Hannes

---

From: Akira Tsukamoto <[email-masked]>
Date: Fri, 26 Mar 2021 10:05:09 +0900

Hi Daniel and Hannes,

> It came to my mind that the workshop talk by Akira, where he speaks about TEEP on RISC-V: https://www.youtube.com/watch?v=-nSpxRr1sYo, could be of interesting to you. It talks about another TEE in…

This is the improved details of the above video link.
https://www.youtube.com/watch?v=gFcAgS8Q8TU&list=PLbzoR-pLrL6qfNemegyJ19ajZ_6f11qit&index=66

Best,
Akira

On 3/26/2021 12:44 AM, Hannes Tschofenig wrote:
> Hi Daniel,
> 
> It came to my mind that the workshop talk by Akira, where he speaks about TEEP on RISC-V: https://www.youtube.com/watch?v=-nSpxRr1sYo <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D-nSpxRr1sYo&data=04%7C01%7Cakira.tsukamoto%40aist.go.jp%7C02535f8c68004a9f397108d8efa4e6b4%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637522839516209990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2Bj8ROgsKFggl3NVLNPfSNbasG%2FCST5%2BWaiClra0JKOI%3D&reserved=0>, could be of interesting to you. It talks about another TEE in detail.
> 
>     [Hannes] The issue is that there is the TA in the secure world but then you also need code elsewhere to interact with it. In fact, there will have to be code pretty much everywhere (at least in TrustZone) to allow the transition from the app running in the normal world to the TA running in the secure world. It may sound like an easy thing to do but it isn’t in practice and the TF-M and OP-TEE code show this, see https://www.trustedfirmware.org/ <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.trustedfirmware.org%2F&data=04%7C01%7Cakira.tsukamoto%40aist.go.jp%7C02535f8c68004a9f397108d8efa4e6b4%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637522839516219982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=yuHWEafAE9X%2Bi1WYXU%2Fb2JuMPXUeI3k8OfHeAa397aQ%3D&reserved=0>
> 
> <mglt>
> 
> [Hannes] I created a PR here: https://github.com/ietf-teep/architecture/pull/223 <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F223&data=04%7C01%7Cakira.tsukamoto%40aist.go.jp%7C02535f8c68004a9f397108d8efa4e6b4%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637522839516219982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=fUTxWzFkUdKchEV8XadtpChKb6RkIqNMcidxiey54uU%3D&reserved=0>
> 
>     </mglt>
> 
> [Hannes] I created an issue regarding Figure 4: https://github.com/ietf-teep/architecture/issues/224 <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F224&data=04%7C01%7Cakira.tsukamoto%40aist.go.jp%7C02535f8c68004a9f397108d8efa4e6b4%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637522839516229976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=I2eCAunN89gnh9I5ejXJEd2fwf3%2B7%2FFKkktjV9R5kPs%3D&reserved=0>
> 
>     I added this issue: https://github.com/ietf-teep/architecture/issues/222 <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F222&data=04%7C01%7Cakira.tsukamoto%40aist.go.jp%7C02535f8c68004a9f397108d8efa4e6b4%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637522839516229976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=IOPcBPjBFqHlPG7KhdfdPRtk4qXi5BbSbicMp5TU3vU%3D&reserved=0>
> 
>     </mglt>
> 
> <mglt>
> 
> thanks.
> 
> </mglt>
> 
>     [...]
> 
>     6.2.1.  TEEP Broker APIs
> 
> https://github.com/ietf-teep/architecture/issues/225 <https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F225&data=04%7C01%7Cakira.tsukamoto%40aist.go.jp%7C02535f8c68004a9f397108d8efa4e6b4%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637522839516239968%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=QlkLZLQCDvgb2fm0wjLe%2BmmcZg906oOqQAEdutMx%2FsM%3D&reserved=0>
> 
>     Ciao
> 
>     Hannes
> 
> _______________________________________________
> TEEP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teep
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 26 Mar 2021 14:17:58 +0000

Thanks, Akira, for doing these talks. They are extremely valuable for educating the OS security community about what we are doing in this group.

Ciao
Hannes

-----Original Message-----
From: Akira Tsukamoto <[email-masked]>
Sent: Friday, March 26, 2021 2:05 AM
To: Hannes Tschofenig <[email-masked]>; Daniel Migault <[email-masked]>
Cc: [email-masked]
Subject: Re: [Teep] clarification questions on draft-ietf-teep-architecture-14

Hi Daniel and Hannes,

Best,
Akira

---

From: Daniel Migault <[email-masked]>
Date: Fri, 26 Mar 2021 11:16:10 -0400

Hi Akira and Hannes,

I will definitely have a look at it.  Thanks for sharing!

Yours,
Daniel

On Thu, Mar 25, 2021 at 9:05 PM Akira Tsukamoto <[email-masked]>
wrote:

> Hi Daniel and Hannes,
>
> > It came to my mind that the workshop talk by Akira, where he speaks
> about TEEP on RISC-V: https://www.youtube.com/watch?v=-nSpxRr1sYo, could
> be of interesting to you. It talks about another TEE in detail.
>
> > It came to my mind that the workshop talk by Akira, where he speaks
> about TEEP on RISC-V: https://www.youtube.com/watch?v=-nSpxRr1sYo <
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D-nSpxRr1sYo&data=04%7C01%7Cakira.tsukamoto%40aist.go.jp%7C02535f8c68004a9f397108d8efa4e6b4%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637522839516209990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2Bj8ROgsKFggl3NVLNPfSNbasG%2FCST5%2BWaiClra0JKOI%3D&reserved=0>,
> could be of interesting to you. It talks about another TEE in detail.
> >
> > You might also want to join our hackathons. That could give you even
> more insight into the software architecture (since some of your questions
> are related to it).
> >
> >     [Hannes] The issue is that there is the TA in the secure world but
> then you also need code elsewhere to interact with it. In fact, there will
> have to be code pretty much everywhere (at least in TrustZone) to allow the
> https://www.trustedfirmware.org/ <
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.trustedfirmware.org%2F&data=04%7C01%7Cakira.tsukamoto%40aist.go.jp%7C02535f8c68004a9f397108d8efa4e6b4%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637522839516219982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=yuHWEafAE9X%2Bi1WYXU%2Fb2JuMPXUeI3k8OfHeAa397aQ%3D&reserved=0
> >
> >
> > <mglt>
> >
> > Thanks for the link. This is obviously not a huge issue - at least to me
> - but it sounds to me that TA may designate different things depending on
> the TEE technology and it might be clarifying to illustrate what it means
> in SGX and TrustZone. There are potentially multiple ways to do that and
> maybe an illustrative example in the appendix would be in my opinion enough
> so to avoid major changes in the text.
> >
> > </mglt>
> >
> > [Hannes] The issues is that this requires a lot of explanation.
> TrustZone has different variants – for A and for M class. TrustZone for A
> class exists with and without secure world hypervisor. Then, there are also
> different software stacks running on the A- and M-class devices, which
> would impact a description. Then, TrustZone is a system level concept,
> which includes peripherals. Hence, it depends on the entire SoC system
> design. I understand that it would be useful to have such a description but
> it also takes a lot of time.
> >
> >     </mglt>
> >
> >     [Hannes] We also cover installation and deletion of software. Maybe
> we should expand the sentence to make this clearer.
> >
> > <mglt>
> >
> > [Hannes] I created a PR here:
> https://github.com/ietf-teep/architecture/pull/223 <
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F223&data=04%7C01%7Cakira.tsukamoto%40aist.go.jp%7C02535f8c68004a9f397108d8efa4e6b4%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637522839516219982%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=fUTxWzFkUdKchEV8XadtpChKb6RkIqNMcidxiey54uU%3D&reserved=0
> >
> >
> >     </mglt>
> >
> >     [Hannes] I think both entities need to work together. The TA
> developer writes the TA code and understands for what application it is
> meant to be used (at least typically). It might also have requirements on
> the type of TEE. An operator of  a TAM needs to decide what it wants to
> send to devices.
> >
> > <mglt>
> >
> > So I understand the developer specifies a code for a specific type of
> TEE. I think I misread "type of TEE", reading your response, it seems that
> type of TEE designates SGX or TrustZone as opposed to the different version
> >     [Hannes] Imagine that a TEE developer writes an app that does some
> machine learning and he only wants to release the code to devices that
> implement certain security features in the TEE. He would work together with
> the TAM operator to ensure that those requirements are met and the
> attestation functionality offered by the TEEP protocol gives him or her
> that assurance.
> >
> > <mglt>
> >
> > [Hannes] Normally, communication happens through the REE and not
> directly to the TEE. It is, however, possible to have peripherals connected
> directly to the TEE. This is rather the exception. Dave Thaler has worked
> on such a prototype, if I recall correctly.
> >
> >   Confidentiality of communication to the TA is ensured by having the
> security terminate in the TEE rather than in the REE.
> >
> >     ~snip~
> >
> >     [Hannes] Sort-of. Details about the SUIT part will be added in a
> SUIT document on how the encryption looks like.
> >
> > <mglt>
> >
> > ok, thanks.
> >
> > </mglt>
> >
> >     [Hannes] This is maybe the wrong document; the TEEP protocol
> document could give an example or should go into the details of this. My
> take-away from the last meeting was that we will cover this in a separate
> document in SUIT.
> >
> > <mglt>
> >
> > What I meant was that the bundle section provided a sufficient high
> level view of how it works. To me a simple referenc eto that section would
> be sufficient. Of course additional details and a reference to a suit
> document may be better, but I do not think that is necessary in that
> document.
> >
> > </mglt>
> >
> > [Hannes] In the TEEP protocol draft we have references to SUIT and RATS,
> of course. For the architecture document, which should ideally be agnostic
> to the solution details, we thought it would better not to go into those
> details.
> >
> >     </mglt>
> >
> >     ~snip~
> >
> >     [...]
> >
> >     4.  Architecture
> >
> >     4.1.  System Components
> >
> >     [...]
> >
> >     <mglt>
> >
> >     [Hannes] The trust anchor may not necessarily be in the same TEE
> that is running the TA. It could also be in an attached crypto processor /
> secure element.
> >
> > <mglt>
> >
> > ok.thanks.
> >
> > </mglt>
> >
> >     </mglt>
> >
> >     ~snip~
> >
> >     [...]
> >
> >     [Hannes] There are different layers of communiation, as shown in
> Figure 1. Section 4.4 only talks about how the different software
> components & personalization data may get to the device. Section 4.4 really
> has to be read in combination with the text related to Figure 1.
> >
> > <mglt>
> >
> |            |
> |            |
> |            |
> |            |
> >                                     |       |
> |            |
> >            (a) Untrusted            |       |
> |            |
> >                                     |       |
> |            |
> >                                     |       |
> |            |
> >     Hence, you cannot really state something like "the TEE authenticates
> X". The TEE and the TEEP Agent are also not the same thing.
> >
> > <mglt>
> >
> > I agree that I had issue with "the TEE authenticates X" and similarly to
> "X authenticates TEE" but this is how I am reading the section 5 "Keys and
> > [Hannes] I created an issue regarding Figure 4:
> https://github.com/ietf-teep/architecture/issues/224 <
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F224&data=04%7C01%7Cakira.tsukamoto%40aist.go.jp%7C02535f8c68004a9f397108d8efa4e6b4%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637522839516229976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=I2eCAunN89gnh9I5ejXJEd2fwf3%2B7%2FFKkktjV9R5kPs%3D&reserved=0
> >
> >
> >     Figure 4 really only focuses on the security keys and tries to avoid
> going too much into details of how an implementation on a specific TEE
> works.
> >
> >     [...]
> >
> >     [...]
> >
> >     [Hannes] This can be done and is done regularly. I think we should
> update the figure to include this option since it is very common.
> >
> >     I added this issue:
> https://github.com/ietf-teep/architecture/issues/222 <
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F222&data=04%7C01%7Cakira.tsukamoto%40aist.go.jp%7C02535f8c68004a9f397108d8efa4e6b4%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637522839516229976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=IOPcBPjBFqHlPG7KhdfdPRtk4qXi5BbSbicMp5TU3vU%3D&reserved=0
> >
> >
> >     </mglt>
> >
> > <mglt>
> >
> > thanks.
> >
> > </mglt>
> >
> >     [...]
> >
> >     6.2.1.  TEEP Broker APIs
> >
> >     [Hannes] The reason is that a TA may be needed by another TA and
> hence you cannot just delete it. You can only say that you do not need it
> anymore.
> >
> >     For the TEEP protocol you do, however, need to make some decisions
> about how you want to design the system and the current design assumes that
> there are cases where HTTP is terminated outside the TEEP.
> >
> > I see your point. [I-D.ietf-teep-protocol] made a choice the text is
> based upon. I think that might be clarified up front that this results from
> a choice and it is not an architecture design.
> >
> > </mglt>
> >
> > https://github.com/ietf-teep/architecture/issues/225 <
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F225&data=04%7C01%7Cakira.tsukamoto%40aist.go.jp%7C02535f8c68004a9f397108d8efa4e6b4%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637522839516239968%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=QlkLZLQCDvgb2fm0wjLe%2BmmcZg906oOqQAEdutMx%2FsM%3D&reserved=0
> >
> >
> >     Ciao
> >
> >     Hannes
> >

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Fri, 26 Mar 2021 16:33:40 -0400

Hi Hannes,

Thanks for the response. Please, my responses inline.

Yours,
Daniel

On Thu, Mar 25, 2021 at 11:44 AM Hannes Tschofenig <
[email-masked]> wrote:

> Hi Daniel,
>
>
>
> It came to my mind that the workshop talk by Akira, where he speaks about
> TEEP on RISC-V: https://www.youtube.com/watch?v=-nSpxRr1sYo, could be of
> interesting to you. It talks about another TEE in detail.
>
> You might also want to join our hackathons. That could give you even more
> insight into the software architecture (since some of your questions are
> related to it).
>
>
>
> [Hannes] The issues is that this requires a lot of explanation. TrustZone
> has different variants – for A and for M class. TrustZone for A class
> exists with and without secure world hypervisor. Then, there are also
<mglt>
I agree.
</mglt>

> https://github.com/ietf-teep/architecture/pull/223
>
>
>
<mglt>
thanks.
</mglt>

> [Hannes] Normally, communication happens through the REE and not directly
> to the TEE. It is, however, possible to have peripherals connected directly
> to the TEE. This is rather the exception. Dave Thaler has worked on such a
> prototype, if I recall correctly.
>
>
>
<mglt>
agree, when I mentioned the communication terminating the TEE I was
referring to TLS only, not TCP/IP. I think we are saying the same thing.
</mglt>

> to the solution details, we thought it would better not to go into those
<mglt>
ok this sounds reasonable. the reader will have to look at the procol to
find out the details.
</mglt>

<mglt>

Here is the text I propose. If the UA, TA and PD are bundled altogether, I
think that they cannot be provided separately, but I might be missing
something. Here is the text I would maybe propose to clarify that many
communications may be multiplexed.

OLD:

       Data and TA provided by a TAM. The Personalization Data MUST be
encrypted

NEW:

       Signer and either provided to the TEEP Broker through the TAM. The
TEEP broker in the REE may forward some of the elements or the full bundle
to the TA Agent as described in section 6.2. When confidentiality is
required, the elements provided to the TAM MUST be encrypted and a secure
channel between the TAM and the TA Agent is required. In most cases
Personalization Data needs to be encrypted.

I am using channels as it is not necessarily a session, but other terms may
be more appropriate.

</mglt>

> I have not found the description of the 3 first arrows - unless I am
ok the 3 first arrows I designated were:   (Embedded TEE cert),  Get an app
cert, Get a TAM cert. To be clear I think this is just a nit.
</mglt>

> https://github.com/ietf-teep/architecture/issues/224
>
>
>
<mglt>
ok thanks
</mglt>

> 6.2.  TEEP Broker Implementation Consideration
<mglt>
yes. I have the impression in some places the text puts verifier instead of
Verifier. That will not prevent me from sleeping I agree.
</mglt>

<mglt>
thanks.
</mglt>

-- 
Daniel Migault
Ericsson