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

Daniel Migault <mglt.ietf@gmail.com> Fri, 26 March 2021 15:16 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E96E3A20E9 for <teep@ietfa.amsl.com>; Fri, 26 Mar 2021 08:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yi1pYgroJGCW for <teep@ietfa.amsl.com>; Fri, 26 Mar 2021 08:16:24 -0700 (PDT)
Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34DC63A20E8 for <teep@ietf.org>; Fri, 26 Mar 2021 08:16:24 -0700 (PDT)
Received: by mail-vk1-xa2c.google.com with SMTP id k76so1256228vkk.10 for <teep@ietf.org>; Fri, 26 Mar 2021 08:16:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cHKM6HsA+HCcMvgPOMwdbh3Pp8ZViMECTJEyvtYd6B8=; b=jh8U8wmK8TvtA91QvkiDqJg4tvHdPQnE1DHyQCl9MQizB3oJJ/gm/0TSClV4IKTI3l QgIZbiUq3HFUZaRec7FzMstbTIxqfjENvvJIBowpYUwcduVYlLBuAtnRUmx9eps5NmGS nD+33f8OrUr9/5qQcuCUtCH/t3PI7a/8BkLLA9ZOwH3KAbcFbhXMFo/F5/1AOiplT44D tOY4gBACnjtlrzhy3ssVpFQh9bR7c1mM7o+PHkopKL6dccnin/91ElfHP8pf62Q52VGO 8exH0p5De9N3ztYPODEmeV1B0Jptdtde96H93sGYbtnPFcOTef+s6mFiDKPqrkAeqJCB QSRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cHKM6HsA+HCcMvgPOMwdbh3Pp8ZViMECTJEyvtYd6B8=; b=QTxUcgo/z9iSFcyerercWFBaSFemqiGZCZ2X9SSQua1pk73yAlE/fLtm3G7iaoZbEl ZSiW3Kzwu8hObgks2qzrHJWbxTN2R81atxDhsRJ2fmJSWuYk7BA78ZDNo6blZaUONYws zSCGYSmF7/0jcSwkAkCBq/LRAA6K0wOKHYWYwoNn9eSPGyUlmgPW5aJSr4qACuMvKOph POfEdtcemMZBSlpo2RLPKw33jzus3y9jdzYSYt3ftVedrbiOGLKY4PqM5WDWn/aOp0eo aNZ0+a4KUWUp7HsPTYboI/qOnORhybjkV61/qKEa4dp5ZOer5gyTJW+VVELBVUw2gLt6 GBwA==
X-Gm-Message-State: AOAM531EAaHN4mX6/+RAKS1IAkzFKE06EiMJQCxSDuasPbFK7XLqp2Im E4dIwv4/trBz8Yrs7BTEarVMW9x+gxr0ssz8LoU=
X-Google-Smtp-Source: ABdhPJzt1CiK+DJxcp+2JqVIPNfroYRTmpUt+o1h9UXB8S+XI9KMjoHN4I0fFsFT6XnyQEZQ6IV0r7whrGvGeFKdQ00=
X-Received: by 2002:a1f:1f4f:: with SMTP id f76mr8987956vkf.19.1616771781708; Fri, 26 Mar 2021 08:16:21 -0700 (PDT)
MIME-Version: 1.0
References: <CADZyTkkomUxgPzFs1e6xUShPfFC7sfAt2-ROOTQYj+5vjjPduw@mail.gmail.com> <VI1PR08MB26392008798A0F8972B034D5FA649@VI1PR08MB2639.eurprd08.prod.outlook.com> <CADZyTkn9wcqkD3oURJnCfzLi9tMONC6hHPeSF2KOELqzduYvZQ@mail.gmail.com> <VI1PR08MB26393A409821FE15C992A522FA629@VI1PR08MB2639.eurprd08.prod.outlook.com> <26b22434-bd9f-30b9-950b-9240252945da@aist.go.jp>
In-Reply-To: <26b22434-bd9f-30b9-950b-9240252945da@aist.go.jp>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Fri, 26 Mar 2021 11:16:10 -0400
Message-ID: <CADZyTkkSC3OEhyu9=0ggPuP-d24305wSHoQZ_A0q8G8H9B+ytQ@mail.gmail.com>
To: Akira Tsukamoto <akira.tsukamoto@aist.go.jp>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "teep@ietf.org" <teep@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bb4e5a05be72035f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/5Y0Y8_ywVVgcoYDziRSu4iDgA60>
Subject: Re: [Teep] clarification questions on draft-ietf-teep-architecture-14
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Mar 2021 15:16:30 -0000

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 <akira.tsukamoto@aist.go.jp>
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.
>
> 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>;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).
> >
> > Anyway, a few remarks below...
> >
> >     <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.
> >
> >     [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>
> >
> > 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>
> >
> >         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.
> >
> >     [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 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>
> >
> >         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.
> >
> >     [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>
> >
> >     This may not exclude that TAM and TA
> >
> >     developer have a specific agreement and
> >
> >     some conditions are provided by the TA
> >
> >     developer.
> >
> >     [Hannes] They may have an agreement or in other cases the
> relationship may be pretty loose.
> >
> > <mglt>
> >
> > ok
> >
> > </mglt>
> >
> >     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.
> >
> >     [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] 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~
> >
> >     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.
> >
> >     [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.
> >
> > <mglt>
> >
> > ok
> >
> > </mglt>
> >
> >     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.
> >
> > <mglt>
> >
> > ok, thanks.
> >
> > </mglt>
> >
> >     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.
> >
> >     [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>
> >
> >            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.
> >
> >     [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~
> >
> >     [...]
> >
> >     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>
> >
> >     [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>
> >
> > [Hannes] If you have ideas on how to better phrase it, feel free to make
> a suggestion.
> >
> >     ~snip~
> >
> >     [...]
> >
> >     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>
> >
> >     [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>
> >
> > I have not found the description of the 3 first arrows - unless I am
> missing it.
> >
> > </mglt>
> >
> > Here is a picture:
> >
> >     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>
> >
> >     [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.
> >
> > <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 <
> 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.
> >
> >     [...]
> >
> >     [...]
> >
> >     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.
> >
> >     [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
> >
> >         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>
> >
> >     [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.
> >
> > <mglt>
> >
> > thanks for the clarification. I think that would worth having it
> mentioned.
> >
> > </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>
> >
> >     [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>
> >
> > [Hannes] Is your confusion the mix between “verifier” and “Verifier”?
> >
> >     [...]
> >
> >     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.
> >
> >     [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.
> >
> > <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 <
> 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
> >
> >     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.
> >
> >
> > Thanks again for your review.
> >
> > 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.
> >
> > _______________________________________________
> > TEEP mailing list
> > TEEP@ietf.org
> > https://www.ietf.org/mailman/listinfo/teep
> >
>


-- 
Daniel Migault
Ericsson