Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Jan 2020 03:14:03 +0000

I opened one pull request for editorial issues (https://github.com/ietf-teep/architecture/pull/109),
and filed seven other issues listed at https://github.com/ietf-teep/architecture/issues

110) Service Provider discussion is confusing<https://github.com/ietf-teep/architecture/issues/110>
111) Terminology section is not consistently ordered<https://github.com/ietf-teep/architecture/issues/111>
112) Text about carriers is confusing<https://github.com/ietf-teep/architecture/issues/112>
113) Section 6.2.3 contradicts section 4.2<https://github.com/ietf-teep/architecture/issues/113>
114) Figure 3 is too hard to understand<https://github.com/ietf-teep/architecture/issues/114>
115) Reference to IANA number<https://github.com/ietf-teep/architecture/issues/115>
116) Incorrect/obsolete statements about TEEP Broker<https://github.com/ietf-teep/architecture/issues/116>

I have ideas about how to address all of them, but if others have comments, please speak up.

The possibly(?) contentious one might be that in #110 I am proposing to use the term
"App Developer" throughout, instead of using "Service Provider" in some places and "App Developer" in others
and then saying they're synonymous like it does now.   (I'd be ok with mentioning that in some contexts an App Developer
might be known as a "Service Provider" if that is important to GlobalPlatform folks.)

Dave

From: TEEP <[email-masked]> On Behalf Of Konda, Tirumaleswar Reddy
Sent: Monday, December 23, 2019 4:17 AM
To: [email-masked]
Subject: [Teep] Working Group Last Call for draft-ietf-teep-architecture

Hi all,

This message starts a Work Group Last Call (WGLC) for TEEP architecture.  The version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-architecture-05<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teep-architecture-05&data=02%7C01%7Cdthaler%40microsoft.com%7C88bfc467b880468e461e08d787a2196d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637127002642640827&sdata=aallqAzJH3MqV2bbzMzwvD3OXhpRFyPJVHeaWye4x40%3D&reserved=0>

The WGLC will last for 4 weeks and will end on 20 January 2020.

Please send your comments to the list before this date and your assessment of whether or not it is ready to proceed to publication.

Regards,
Tiru & Nancy

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 7 Jan 2020 06:38:44 +0000

[As an individual]

Hi Dave,

I have reviewed the draft and have comments and nits listed below:

a) It is not clear from the Introduction how TEE is different from a Closed OS like Google Chromebook or Windows 10S ?

     The benefit of Payment application running in Closed OS verses in TEE is not evident from the description. What part of the Payment application runs in the REE and TEE respectively ?

     If biometric identification information is securely stored in TEE for identification, how does the TEE identify the biometric identification information is not retrieved by an malicious agent in the REE.

     Section 3.3 (Internet of things), How does the architecture ensure the sensitive data is retrieved by a legitimate application in the REE and not by an malicious application ?

b) Why should the list of trust anchors on the device be managed by the Device's network carrier ?

     (you may want to define the term "network carrier").

c) If the REE is compromised (for example by malware), it could terminate the TEEP broker in REE. How is this attack mitigated ?

d) What happens if the malicious agent acting as TEEP broker launches attacks (e.g. garbage data, replay attack, DoS of messages etc.,) on the TEEP agent, and how will the TEEP agent defend itself ?

e) The below line is not clear to me:

Enumeration and access to the appropriate TEEP Broker is up to the Rich Execution Environment and the Untrusted Applications.

h) A use case explaining the use of multiple TAM, multiple TEEP brokers on a device, and multiple TEE would be useful to the reader of the specification.

i) When a TEEP Broker receives a request from an Untrusted Application

   to install a TA, a list of TAM URIs may be provided for that TA, and

   the request is passed to the TEEP Agent.  If the TEEP Agent decides

   that the TA needs to be installed, the TEEP Agent selects a single

   TAM URI that is consistent with the list of trusted TAMs provisioned

   on the device invokes the HTTP transport for TEEP to connect to the

   TAM URI and begins a TEEP protocol exchange.

Comment> I am not sure why the architecture draft is discussing the protocol aspects like HTTP for TEEP ?

j) What if the malware in REE instructs the TEEP agent via TEEP broker to keep installing/uninstalling TA (over-whelm the TEEP agent and TEE or installing un-necessary TA to have no memory for the required TA) ?

i) What is the use case for "Personalization data" ?

j) Why is Section 4.5 discussing Case 1 when it not in use ?

k) The below line is not clear to me (please elaborate):

Consequently, a TAM generally communicates with an Untrusted Application about how it gets messages that originate from a TEE inside a device.

l) What is the use case for one TA and multiple SP ?

m) what is the use case for keeping the TA binary secret from the TAM ?

n) We allow a way for an Untrusted Application to check the trustworthiness of a TA.

Comment> You may want to re-phrase the above line, and remove "we".

o) A notification that an incoming TEEP session is being requested by a TEEP Agent.

Comment> What you meant by "incoming TEEP session" ?

p) How does the TEEP broker communicate with the TEEP agent ?

q) Section 5.3 says the architecture uses PKI but Section 9.1 discusses self-signed certificates. Please fix.

r) In Figure 4, for the purpose of "Code signing" my understanding is the location of corresponding CA certs is both TEE and TAM.

s)I have seen several malicious apps in App store in both Android and iOS, it is possible for an malicious App developer to publish both malicious untrusted applications

   and malicious trusted applications.  I don't think the TEEP architecture prevents this attack and it is the responsibility of TAM and App store to remove such apps

    (see https://android-developers.googleblog.com/2018/01/how-we-fought-bad-apps-and-malicious.html)

Cheers,

-Tiru

From: Dave Thaler <[email-masked]>
Sent: Tuesday, January 7, 2020 8:44 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: Working Group Last Call for draft-ietf-teep-architecture

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
I opened one pull request for editorial issues (https://github.com/ietf-teep/architecture/pull/109),
and filed seven other issues listed at https://github.com/ietf-teep/architecture/issues

Dave

From: TEEP <[email-masked]<mailto:[email-masked]>> On Behalf Of Konda, Tirumaleswar Reddy
Sent: Monday, December 23, 2019 4:17 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Teep] Working Group Last Call for draft-ietf-teep-architecture

Hi all,

Regards,
Tiru & Nancy

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 7 Jan 2020 09:28:07 +0000

Hi Tiru,

Thanks for the review. There is clearly room for improving the write-up.

A few remarks below.

From: TEEP <[email-masked]> On Behalf Of Konda, Tirumaleswar Reddy
Sent: Tuesday, January 7, 2020 7:39 AM
To: Dave Thaler <[email-masked]>; [email-masked]
Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture

[As an individual]

Hi Dave,

[Hannes] The TEE adds another layer of software isolation. To protect one TA to steal data from another TA the two TAs need to be isolated against each other. Depending on the TEE technology you are using this is accomplished via different means.

It is up to the application developer to decide how they best want to separate the REE and the TEE part, which in part depends a bit on what type of payment protocol they are using. In some other cases (probably more realistic) they may be using an already existing payment system, which is provided as a TA, and they are just using it. In general, it does not strike me as a great idea to have random smart phone app developers writing their own payment software.

[Hannes] The text says the following:

"
The list of Trust Anchors is normally modifiable
      by the Device's owner or Device Administrator.  However the Device
      manufacturer and network carrier may restrict some modifications,
      for example, by not allowing the manufacturer or carrier's Trust
      Anchor to be removed or disabled.

"

This describes current practice in the mobile phone industry and may not necessarily be applicable to other deployment scenarios. Hence, there is no required behavior here.

[Hannes] If the REE is compromised then that's typically not a good thing but the REE side still cannot access anything on the secure world, if implemented correctly. It could, however, indeed terminate the TEEP broker and avoid any calls to the secure world. This would be a DoS attack. It would be possible to periodically schedule an interrupt that is processed by the secure world to let the secure world double-check the state of the normal world.

[Hannes] The TEEP agent dispatches calls to the trusted applications. It is typically a shim layer that just checks parameters of the requests and then relays them to the TAs. Having a rock solid implementation of the TEEP agent is important and of course the TAs need to be implemented properly as well.

The GP TEE Client API is meant to provide a reference design for an API that allows data passing back and forth. So, implementing that API properly will be important. This is why there is this open source project to implement that API so that other developers can just use it.

Enumeration and access to the appropriate TEEP Broker is up to the Rich Execution Environment and the Untrusted Applications..

[Hannes] There may be multiple TEEP Brokers on the system and the interaction between untrusted apps and the TEEP broker is up to a policy implemented by the developer.

[Hannes] Definitely a good idea to add text with use cases.

Here is my quick response:

  *   Multiple TAMs: you could think about this as having multiple code repositories. Different SPs may prefer to use certain TAMs for their software distribution.
  *   Multiple TEEP brokers: this can occur when you have a broker offered by the OS and one bundled with the untrusted app.
  *   Multiple TEEs: This depends on the TEE technology. In the TrustZone case you may have a multi-processor system and each processor comes with TrustZone support.

[Hannes] I believe it does not need to mention HTTP but it could list it as an example.

[Hannes] Having a compromised REE environment that causes all sorts of apps to be installed is possible (assuming the TEE is authorizing the installation of those apps). An implementation of the secure world, most likely the TEE OS, will have to make sure that the device does not install TAs and overwrite the memory space they have been configured to use.

[Hannes] Personalization data is meant to make each instance of the TA unique and potentially tie it to a specific user. Imagine a TA that implements biometric functionality: there has to be something in TA that relates this instance of the TA to a specific human, for example by storing a fingerprint alongside the TA as configuration data.

[Hannes] We just describe the possible approach and illustrates how things are done today. There is, however, a lot of development going on in the area of TEEs and I suspect that we will see all sorts of different use cases showing up in the future as the technology gets used in different environments.

[Hannes] The key point of that paragraph is that today TEEs do not communicate with the outside world but require the cooperation with something on the REE side.

[Hannes] I am not sure. I let Ming, DaveW, or DaveT respond.

[Hannes] it is more and more common today to protect binaries from inspection because this gives attackers a lot of information. If you don't want to use it and only sign the binaries that's fine too. But the option is there for you to protect the confidentiality of the binary.

[Hannes] I think we should delete this paragraph:

"

   We allow a way for an Untrusted Application to check the

   trustworthiness of a TA.  A TEEP Broker has a function to allow an

   application to query the information about a TA.

"

[Hannes] Dave should respond to this one because it relates to the HTTP transport, I believe.

[Hannes] Via an API, for example the GP TEEP Client API.

[Hannes] We need to clarify the statement about the self-signed TA binaries.

[Hannes] I believe it would be useful to also store the CA cert that is used for code signing at the TAM because then it can verify the signed TAs.

If we indeed believe the text in Section 9.1 is correct then that code signing CA cert also needs to be made available to the TEEP Broker and potentially even to the untrusted app.

[Hannes] Yes, it would be the responsibility of the TAM, the device manufacturer and the SP / developer to ensure that they do not distribute malicious TAs.

Ciao

Hannes

Cheers,

-Tiru

From: Dave Thaler <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 7, 2020 8:44 AM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Working Group Last Call for draft-ietf-teep-architecture

________________________________
I opened one pull request for editorial issues (https://github.com/ietf-teep/architecture/pull/109),
and filed seven other issues listed at https://github..com/ietf-teep/architecture/issues<https://github.com/ietf-teep/architecture/issues>

Dave

Hi all,

Regards,
Tiru & Nancy
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: Dave Thaler <[email-masked]>
Date: Tue, 7 Jan 2020 19:44:19 +0000

Below

From: Hannes Tschofenig <[email-masked]>
Sent: Tuesday, January 7, 2020 1:28 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Dave Thaler <[email-masked]>; [email-masked]
Subject: RE: Working Group Last Call for draft-ietf-teep-architecture

Hi Tiru,

A few remarks below.

From: TEEP <[email-masked]<mailto:[email-masked]>> On Behalf Of Konda, Tirumaleswar Reddy
Sent: Tuesday, January 7, 2020 7:39 AM
To: Dave Thaler <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture

[As an individual]

Hi Dave,

The document (intentionally) makes no statement about whether a "close OS" as you put it, is or is not a TEE.   The question is really about whether such an OS prevents code injection attacks (e.g., due to buffer overruns or whatever else), prevents data modification attacks, etc.

This is issue #112 that I filed.   Personally I think the term "carrier" should be removed from the doc.

"

"

Right.  DoS attacks by the REE are, in general, not prevented (some TEEs may prevent them but most won't).

The TEEP architecture doesn't change this.

The TEEP Agent implements a secure protocol (the TEEP protocol) between it and a TAM.
That protocol must be secure against attacks by untrusted intermediaries, including routers, HTTP proxies, and TEEP brokers.

I agree the line is confusingly worded.

Isn't that what Figure 2 already provides?  Can you elaborate on what you're looking for?

-        Multiple TAMs: you could think about this as having multiple code repositories. Different SPs may prefer to use certain TAMs for their software distribution.
-        Multiple TEEP brokers: this can occur when you have a broker offered by the OS and one bundled with the untrusted app.
-        Multiple TEEs: This depends on the TEE technology. In the TrustZone case you may have a multi-processor system and each processor comes with TrustZone support.

Sure.

On the other hand, we have a WG document, and the architecture document can mention it as explaining how that doc fits into the architecture and relates to the other docs.

An REE can always conduct DoS attacks against a TEEP agent as discussed in your question (c) above.

However the word "instructs" is incorrect since the TEEP Agent is authoritative, your question should say "requests" instead, since the TEEP agent is free to ignore/reject the request.  (This is why section 6.2.1 has "RequestTA", as does the transport spec.)

There is an example in section 4.4:

Ø  an example of

Ø  personalization data might be a secret symmetric key used by the TA

Ø  to communicate with the SP

Agree with Hannes.

That whole paragraph is confusingly worded, and I currently plan to rewrite it based on my marked up hard copy :)

No idea, I'd propose deleting that section.   I was confused by it as well.

I believe the use case is where the app developer considers the TA binary itself to be secret (e.g., intellectual property worth protecting), but wants to allow it to be distributed through a TAM that is run by another organization, one with more hosting capacity.   Thus the developer puts an encrypted binary in that TAM, and then runs their own lighter weight TAM that just hands out decryption keys which doesn't need nearly as much much capacity/bandwidth.

"

"

Agreed it should be deleted.  This was the second point of issue #116 that I filed.

The TEEP protocol requires the agent to connect to the TAM.   This is a notification about the initial connection.

See the transport spec for more details.

Right, implementation-specific detail.

Sure.  Figure 4 talks about multiple certificates.   5.3 is a general statement about multiple types.

9.1 is about one specific type of cert that may or may not have a PKI.

So they are not in contradiction but yes clarification would be good.

I don't believe there is any such requirement on a TAM.   It might be "useful" but is not required in my view.

I don't believe the text in 9.1 is correct.

    (see https://android-developers.googleblog.com/2018/01/how-we-fought-bad-apps-and-malicious.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fandroid-developers.googleblog.com%2F2018%2F01%2Fhow-we-fought-bad-apps-and-malicious.html&data=02%7C01%7Cdthaler%40microsoft.com%7Cbcf3b2c5f95b4c4c31fa08d79353ece5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139861908969481&sdata=gNv0t73IFUqZmdnXjWmpb9bAyoYGfczM6oRe66Qlaog%3D&reserved=0>)

It's the responsibility of the TAM to not install malicious trusted apps, only authorized ones.

I don't think it's correct to say it's the responsibility of the TAM to "remove" malicious trusted apps, since it shouldn't have installed it in the first place.

The only case where "removal" might make sense is if the TAM previously authorized a trusted app, and later changed its policy that such TA is no longer authorized (e.g., because it was determined to be buggy or malicious or whatever else).

Ciao

Hannes

Cheers,

-Tiru

________________________________
I opened one pull request for editorial issues (https://github.com/ietf-teep/architecture/pull/109<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F109&data=02%7C01%7Cdthaler%40microsoft.com%7Cbcf3b2c5f95b4c4c31fa08d79353ece5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139861908969481&sdata=S36SLw%2F2T7yK210awwzbpWTE0LAN9r1WFtkE5qG%2Bfl0%3D&reserved=0>),
and filed seven other issues listed at https://github..com/ietf-teep/architecture/issues<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues&data=02%7C01%7Cdthaler%40microsoft.com%7Cbcf3b2c5f95b4c4c31fa08d79353ece5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139861908979441&sdata=5aqxPRt0miAe5DsoenjkTn2qbJlVWTeciLtw9SBVn1E%3D&reserved=0>

110) Service Provider discussion is confusing<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F110&data=02%7C01%7Cdthaler%40microsoft.com%7Cbcf3b2c5f95b4c4c31fa08d79353ece5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139861908979441&sdata=KPNhnXV43eP8ZmdSqv3Vkbcj%2FPUlt5G3qYUgWPOBT%2F0%3D&reserved=0>
111) Terminology section is not consistently ordered<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F111&data=02%7C01%7Cdthaler%40microsoft.com%7Cbcf3b2c5f95b4c4c31fa08d79353ece5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139861908979441&sdata=Y%2FwhR2qzEc86xYboYueIlwI7jGUlIUnUp03qQ%2FclAMs%3D&reserved=0>
112) Text about carriers is confusing<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F112&data=02%7C01%7Cdthaler%40microsoft.com%7Cbcf3b2c5f95b4c4c31fa08d79353ece5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139861908989393&sdata=R1xs7Zt7GAt%2Bj0cv8rE273CmG4Y%2FPSQ5bB1SXVVjUS0%3D&reserved=0>
113) Section 6.2.3 contradicts section 4.2<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F113&data=02%7C01%7Cdthaler%40microsoft.com%7Cbcf3b2c5f95b4c4c31fa08d79353ece5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139861908989393&sdata=fYt0nEoCNSxthFVKq%2FmxutxQgpThx8L1Vn3h%2BxLhKxE%3D&reserved=0>
114) Figure 3 is too hard to understand<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F114&data=02%7C01%7Cdthaler%40microsoft.com%7Cbcf3b2c5f95b4c4c31fa08d79353ece5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139861908989393&sdata=o%2F6RQy0IdDZQ1Z5wDYg5WVamJ31SS6JUzU8nCLB8ksk%3D&reserved=0>
115) Reference to IANA number<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F115&data=02%7C01%7Cdthaler%40microsoft.com%7Cbcf3b2c5f95b4c4c31fa08d79353ece5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139861908999352&sdata=xPDRcUGvaicejeAxxLOt5Cc%2BaFAEpe1X1XBnW8TOrY8%3D&reserved=0>
116) Incorrect/obsolete statements about TEEP Broker<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fissues%2F116&data=02%7C01%7Cdthaler%40microsoft.com%7Cbcf3b2c5f95b4c4c31fa08d79353ece5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139861908999352&sdata=O8lfJd0TAW1aEU50xAO7U09PPsCtcrCCPBFNHlPC2pA%3D&reserved=0>

Dave

Hi all,

This message starts a Work Group Last Call (WGLC) for TEEP architecture.  The version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-architecture-05<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teep-architecture-05&data=02%7C01%7Cdthaler%40microsoft.com%7Cbcf3b2c5f95b4c4c31fa08d79353ece5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637139861909009306&sdata=jkSiFYpG8FFVJUPk7nzK4VCH2j3im3RyFYtQj7ieHCw%3D&reserved=0>

Regards,
Tiru & Nancy

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 9 Jan 2020 07:52:58 +0000

Hi Hannes and Dave,

Thanks for the responses. Please see inline [TR]

From: Dave Thaler <[email-masked]>
Sent: Wednesday, January 8, 2020 1:14 AM
To: Hannes Tschofenig <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]
Subject: RE: Working Group Last Call for draft-ietf-teep-architecture

From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 7, 2020 1:28 AM
To: Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; Dave Thaler <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Working Group Last Call for draft-ietf-teep-architecture

Hi Tiru,

A few remarks below.

[As an individual]

Hi Dave,

[TR] Got it, Thanks.

[TR] Closed OS prevent the above attacks, a malicious app cannot read/modify the data of the other apps (e.g., ransomware attack is not possible, see https://support.google.com/chromebook/answer/3438631?hl=en).

[TR] Works for me.

"

"

[TR] You may want to explain the above threat vector in the document.

[TR] Okay. I think it will be useful to discuss possible attacks by untrusted intermediaries on the TEEP agent and how the TEEP agent can protect itself (either in this document or in the TEEP protocol specification) ?

[TR] Please fix in the next update.

[TR] I am looking for use cases, the text proposed by Hannes below looks like a good starting point.

Sure.

[TR] Fair point.

[TR] My suggestion is to discuss the above attack in the document.

  *   an example of

  *   personalization data might be a secret symmetric key used by the TA
  *   to communicate with the SP

[TR] Thanks, I missed the example.

Agree with Hannes.

[TR] Okay.

[TR] Okay.

[TR] Works for me.

[TR] Got it but it also allows the possibility of publishing malicious apps the TAM/SP may not be able to validate (For instance Apple has a strict review process of apps before publishing on the iOS app store). Encrypting the binaries from inspection by attacker is required but TAM/SP are not necessarily the attackers.

"

"

[TR] Okay.

[TR] Thanks for the clarification.

[TR] Okay.

[TR] What is need for self-signed certificates when code signing certificates by CA are used today ?

[TR] why do you think verification in TAM is not required ?

[TR] You may want to raise an issue in github to correct the text.

[TR] You may want to discuss the above case in the document.  If the trusted app is removed by TAM because it is malicious, some notification to the user would be helpful to remove the associated untrusted application in the REE.

-Tiru

Ciao

Hannes

Cheers,

-Tiru

Dave

Hi all,

Regards,
Tiru & Nancy

---

From: Mingliang Pei <[email-masked]>
Date: Sat, 11 Jan 2020 22:41:39 -0800

Hi Tiru, thank you very much for your comments and suggestions. Thanks Dave
and Hannes for prompt response for us.

Please see my comments inlines, mostly on top of your last replies, and for
several questions that need additional clarification.

Thanks,

Ming

On Wed, Jan 8, 2020 at 11:53 PM Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

> *From:* Dave Thaler <[email-masked]>
> *Sent:* Wednesday, January 8, 2020 1:14 AM
> *To:* Hannes Tschofenig <[email-masked]>; Konda, Tirumaleswar
> Reddy <[email-masked]>; [email-masked]
> *Subject:* RE: Working Group Last Call for draft-ietf-teep-architecture
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
>
>
> ------------------------------
>
> Below
>
>
>
> *From:* Hannes Tschofenig <[email-masked]>
> *Sent:* Tuesday, January 7, 2020 1:28 AM
> *To:* Konda, Tirumaleswar Reddy <[email-masked]>;
> Dave Thaler <[email-masked]>; [email-masked]
> *Subject:* RE: Working Group Last Call for draft-ietf-teep-architecture
>
>
>
> Hi Tiru,
>
>
>
> *From:* TEEP <[email-masked]> *On Behalf Of *Konda, Tirumaleswar
> Reddy
> *Sent:* Tuesday, January 7, 2020 7:39 AM
> *To:* Dave Thaler <[email-masked]>; [email-masked]
> *Subject:* Re: [Teep] Working Group Last Call for
> draft-ietf-teep-architecture
>
>
>
> [As an individual]
>
>
>
> Hi Dave,
>
>
>
> a) It is not clear from the Introduction how TEE is different from a
> Closed OS like Google Chromebook or Windows 10S ?
>
>      The benefit of Payment application running in Closed OS verses in TEE
> is not evident from the description. What part of the Payment application
> runs in the REE and TEE respectively ?
>
>      If biometric identification information is securely stored in TEE for
> identification, how does the TEE identify the biometric identification
> information is not retrieved by an malicious agent in the REE.
>
>      Section 3.3 (Internet of things), How does the architecture ensure
> the sensitive data is retrieved by a legitimate application in the REE and
> not by an malicious application ?
>
>
>
> [Hannes] The TEE adds another layer of software isolation. To protect one
> TA to steal data from another TA the two TAs need to be isolated against
> each other. Depending on the TEE technology you are using this is
> accomplished via different means.
>
>
>
> It is up to the application developer to decide how they best want to
> separate the REE and the TEE part, which in part depends a bit on what type
> of payment protocol they are using. In some other cases (probably more
> realistic) they may be using an already existing payment system, which is
> provided as a TA, and they are just using it. In general, it does not
> strike me as a great idea to have random smart phone app developers writing
> their own payment software.
>
>
>
> [TR] Got it, Thanks.
>
>
>
> The document (intentionally) makes no statement about whether a “close OS”
> as you put it, is or is not a TEE.   The question is really about whether
> such an OS prevents code injection attacks (e.g., due to buffer overruns or
> whatever else), prevents data modification attacks, etc..
>
>
>
> [TR] Closed OS prevent the above attacks, a malicious app cannot
> read/modify the data of the other apps (e.g., ransomware attack is not
> possible, see https://support.google.com/chromebook/answer/3438631?hl=en
> <https://clicktime.symantec.com/3JPSEBNruBmUKctmhaBoGpT7Vc?u=https%3A%2F%2Fsupport.google.com%2Fchromebook%2Fanswer%2F3438631%3Fhl%3Den>).
>
>
>
>
> This is issue #112 that I filed.   Personally I think the term “carrier”
> should be removed from the doc.
>
>
>

Dave has this issue tracked, and I added comment there. For one, "a network
carrier" applies to mobile device only, and we have other TEE device types.
On the other hand, the "network carrier" text does have some relevance
here. For mobile devices, Trust Anchors are expected to be set by device
manufacturers. What to put by a device manufacturer into devices, however,
is often governed or instructed by the network carrier that a particular
mobile device is produced for. That is the history of this context. I think
we can make this as an example of set for such a case.

[TR] Works for me.
> “
> “
> This describes current practice in the mobile phone industry and may not
> necessarily be applicable to other deployment scenarios. Hence, there is no
> required behavior here.
>
>
>
>
>
> c) If the REE is compromised (for example by malware), it could terminate
> the TEEP broker in REE. How is this attack mitigated ?
>
>
>
> [Hannes] If the REE is compromised then that’s typically not a good thing
> but the REE side still cannot access anything on the secure world, if
> implemented correctly. It could, however, indeed terminate the TEEP broker
> and avoid any calls to the secure world. This would be a DoS attack.. It
> would be possible to periodically schedule an interrupt that is processed
> by the secure world to let the secure world double-check the state of the
> normal world.
>
>
>
> Right.  DoS attacks by the REE are, in general, not prevented (some TEEs
> may prevent them but most won’t).
>
> The TEEP architecture doesn’t change this.
>
>
>
[MP] Agreed. Will add some text on this.

>
> d) What happens if the malicious agent acting as TEEP broker launches
> attacks (e.g. garbage data, replay attack, DoS of messages etc.,) on the
> TEEP agent, and how will the TEEP agent defend itself ?
>
>
>
> [Hannes] The TEEP agent dispatches calls to the trusted applications. It
> is typically a shim layer that just checks parameters of the requests and
> then relays them to the TAs. Having a rock solid implementation of the TEEP
> agent is important and of course the TAs need to be implemented properly as
> well.
>
>
>
> The GP TEE Client API is meant to provide a reference design for an API
> that allows data passing back and forth. So, implementing that API properly
> will be important. This is why there is this open source project to
> implement that API so that other developers can just use it.
>
>
>
> That protocol must be secure against attacks by untrusted intermediaries,
> including routers, HTTP proxies, and TEEP brokers.
>
>
>
> [TR] Okay. I think it will be useful to discuss possible attacks by
> untrusted intermediaries on the TEEP agent and how the TEEP agent can
> protect itself (either in this document or in the TEEP protocol
> specification) ?
>
>
>

[MP] We may add this and the above one in "Security Consideration".

> Enumeration and access to the appropriate TEEP Broker is up to the Rich
> Execution Environment and the Untrusted Applications..
>
>
>
> [Hannes] There may be multiple TEEP Brokers on the system and the
> interaction between untrusted apps and the TEEP broker is up to a policy
> implemented by the developer.
>
>
>

[MP] Agreed. Will fix. (Dave has had some on Multiple TEEP Broker).

>
> h) A use case explaining the use of multiple TAM, multiple TEEP brokers on
> a device, and multiple TEE would be useful to the reader of the
> specification.
>
>
>
> Isn’t that what Figure 2 already provides?  Can you elaborate on what
> you’re looking for?
>
>
>
> -          Multiple TAMs: you could think about this as having multiple
> code repositories. Different SPs may prefer to use certain TAMs for their
> software distribution.
>
> -          Multiple TEEP brokers: this can occur when you have a broker
> offered by the OS and one bundled with the untrusted app.
>
> -          Multiple TEEs: This depends on the TEE technology. In the
> TrustZone case you may have a multi-processor system and each processor
> comes with TrustZone support.
>
>
>
> On the other hand, we have a WG document, and the architecture document
> can mention it as explaining how that doc fits into the architecture and
> relates to the other docs.
>
>
>
> [TR] Fair point.
>
>
>
> j) What if the malware in REE instructs the TEEP agent via TEEP broker to
> keep installing/uninstalling TA (over-whelm the TEEP agent and TEE or
> installing un-necessary TA to have no memory for the required TA) ?
>
>
>
> However the word “instructs” is incorrect since the TEEP Agent is
> authoritative, your question should say “requests” instead, since the TEEP
> agent is free to ignore/reject the request.  (This is why section 6.2.1 has
> “RequestTA”, as does the transport spec.)
>
>
>
> [Hannes] Having a compromised REE environment that causes all sorts of
> apps to be installed is possible (assuming the TEE is authorizing the
> installation of those apps). An implementation of the secure world, most
> likely the TEE OS, will have to make sure that the device does not install
> TAs and overwrite the memory space they have been configured to use.
>
>
>

[MP] Good point. We can add this threat discussion in Security
Consideration.

>    - an example of
>    - personalization data might be a secret symmetric key used by the TA
>    - to communicate with the SP
>
>
>
> [Hannes] Personalization data is meant to make each instance of the TA
> unique and potentially tie it to a specific user. Imagine a TA that
> implements biometric functionality: there has to be something in TA that
> relates this instance of the TA to a specific human, for example by storing
> a fingerprint alongside the TA as configuration data.
>
>
>
> [Hannes] We just describe the possible approach and illustrates how things
> are done today. There is, however, a lot of development going on in the
> area of TEEs and I suspect that we will see all sorts of different use
> cases showing up in the future as the technology gets used in different
> environments.
>
>
>
> Agree with Hannes.
>
>
>
> [TR] Okay.
>
>
>
> Consequently, a TAM generally communicates with an Untrusted Application
> about how it gets messages that originate from a TEE inside a device.
>
>
>
> [Hannes] The key point of that paragraph is that today TEEs do not
> communicate with the outside world but require the cooperation with
> something on the REE side.
>
>
>
> That whole paragraph is confusingly worded, and I currently plan to
> rewrite it based on my marked up hard copy J
>
>
>
> [TR] Okay.
>
>
>
> [Hannes] I am not sure.. I let Ming, DaveW, or DaveT respond.
>
>
>
> No idea, I’d propose deleting that section.   I was confused by it as well.
>
>
>

[MP] A TA software author can license the TA to multiple "buyers" who
installs to their own user devices via their own TAM providers. The buyers
are SPs in the original use case context. A TA developer doesn't
necessarily distribute the TA. We have changed the meaning of SP to be
interchangeable with an "App Developer" along with WG discussion, which
treats the TA authorizer (SP) to devices as the owner of the TA.

A SP may provide its own "TA personalization data". Different SPs may
provide different data. There needs a way to address the case when the same
TA is installed to a device by multiple providers. To this end, the
proposal was to have different "identifiers" for the TA to multiple SPs so
that they don't have to be overwritten. A Device Administrator may decide
which TAM and TA it allows to install to devices.

This is certainly a complex case, and not expected to be common in
practice. Do you feel that we can disallow such a case where a TA author
always directly works with a TAM service to distribute the TA? I feel that
this licensed TA case may still have a place here.

[TR] Works for me.
> [Hannes] it is more and more common today to protect binaries from
> inspection because this gives attackers a lot of information. If you don’t
> want to use it and only sign the binaries that’s fine too. But the option
> is there for you to protect the confidentiality of the binary.
>
>
>
> I believe the use case is where the app developer considers the TA binary
> itself to be secret (e.g., intellectual property worth protecting), but
> wants to allow it to be distributed through a TAM that is run by another
> organization, one with more hosting capacity.   Thus the developer puts an
> encrypted binary in that TAM, and then runs their own lighter weight TAM
> that just hands out decryption keys which doesn’t need nearly as much much
> capacity/bandwidth.
>
>
>
> [TR] Got it but it also allows the possibility of publishing malicious
> apps the TAM/SP may not be able to validate (For instance Apple has a
> strict review process of apps before publishing on the iOS app store).
> Encrypting the binaries from inspection by attacker is required but TAM/SP
> are not necessarily the attackers.
>
>
[MP] I think this risk can be some contract between the TAM and the TA
provider to manage. When a TAM doesn't want to risk its reputation to
distribute malware, it may demand to inspect binary that a TA provider
gives. Agree with you that a TAM most probably have the original TA binary
access, who are not treated as an attacker by the TA developer.

Note that the more common case of TA binary encryption common is for the
TAM to encrypt the TA binary to prevent any man-in-the-middle from
inspecting the binary. App Developer encrypted TA binary has a decryption
key distribution challenge to a device. The separate TAM was devised for
this purpose, but that was largely used for "personalization data" support
case.

> “
> “

[MP] Agreed too. It was originally set there for local query without
contacting a remote TAM to check a TA.

o) A notification that an incoming TEEP session is being requested by a
> TEEP Agent.
> The TEEP protocol requires the agent to connect to the TAM.   This is a
> notification about the initial connection.
>
> r) In Figure 4, for the purpose of "Code signing" my understanding is the
> location of corresponding CA certs is both TEE and TAM.
>
>
>
> [Hannes] I believe it would be useful to also store the CA cert that is
> used for code signing at the TAM because then it can verify the signed TAs.
>
>
>
> I don’t believe there is any such requirement on a TAM.   It might be
> “useful” but is not required in my view.
>
>
>

[MP]  TA signature verification must be verified. Currently a TEE will
check this code signing, and the CA certificate will be in TEE. See Figure
4 in the doc.

"Code Signing          1 per SP       TA binary          TEE"

Note the above "TA binary encryption" discussion. If a TA is given to a TAM
in an encrypted form, such a signature check isn't feasible. But we can
assume that TAM provider always vet TA binaries that it distributes for its
service reputation protection.

Note that there is also the other TA delivery mode where a TA's binary is
bundled inside an Untrusted Application as binary data. In this case, the
binary isn't sent to TAM for distribution.

There is also the other case: many SPs / TA App Developers use the same
extremely popular TAM service. Device manufacturers may want to limit to
accept only a set of TA providers by using the code signing CA trust list.
The architecture allows such support with the coding signing trust check in
TEE.

If we indeed believe the text in Section 9.1 is correct then that code
> signing CA cert also needs to be made available to the TEEP Broker and
> potentially even to the untrusted app.
>
>
>
> I don’t believe the text in 9.1 is correct.
>
>
>
[MP] See above comment.

> s)I have seen several malicious apps in App store in both Android and iOS,
> it is possible for an malicious App developer to publish both malicious
> untrusted applications
>
>    and malicious trusted applications.  I don't think the TEEP
> architecture prevents this attack and it is the responsibility of TAM and
> App store to remove such apps
>
>     (see
> https://android-developers.googleblog.com/2018/01/how-we-fought-bad-apps-and-malicious.html
> <https://clicktime.symantec.com/3WoTUQiqn8S8EL5UYFU7jhw7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fandroid-developers.googleblog.com%252F2018%252F01%252Fhow-we-fought-bad-apps-and-malicious.html%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908969481%26sdata%3DgNv0t73IFUqZmdnXjWmpb9bAyoYGfczM6oRe66Qlaog%253D%26reserved%3D0>)
>
>
>
>
> [Hannes] Yes, it would be the responsibility of the TAM, the device
> manufacturer and the SP / developer to ensure that they do not distribute
> malicious TAs.
>
>
>
> It’s the responsibility of the TAM to not install malicious trusted apps,
> only authorized ones.
>
>
>
> I don’t think it’s correct to say it’s the responsibility of the TAM to
> “remove” malicious trusted apps, since it shouldn’t have installed it in
> the first place.
>
> The only case where “removal” might make sense is if the TAM previously
> authorized a trusted app, and later changed its policy that such TA is no
> longer authorized (e.g., because it was determined to be buggy or malicious
> or whatever else).
>
>
>
> [TR] You may want to discuss the above case in the document.  If the
> trusted app is removed by TAM because it is malicious, some notification to
> the user would be helpful to remove the associated untrusted application in
> the REE.
>
>
>
[MP] Good suggestion. We may touch on this point in Security Consideration
section too.

> -Tiru
>
>
>
>
>
> Ciao
>
> Hannes
>
>
>
> Cheers,
>
> -Tiru
>
>
>
> *From:* Dave Thaler <[email-masked]>
> *Sent:* Tuesday, January 7, 2020 8:44 AM
> *To:* Konda, Tirumaleswar Reddy <[email-masked]>;
> [email-masked]
> *Subject:* RE: Working Group Last Call for draft-ietf-teep-architecture
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
>
>
> ------------------------------
>
> I opened one pull request for editorial issues (
> https://github.com/ietf-teep/architecture/pull/109
> <https://clicktime.symantec.com/351u59QLtaPT81TMTAvunqB7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fpull%252F109%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908969481%26sdata%3DS36SLw%252F2T7yK210awwzbpWTE0LAN9r1WFtkE5qG%252Bfl0%253D%26reserved%3D0>),
>
>
> and filed seven other issues listed at
> https://github..com/ietf-teep/architecture/issues
> <https://clicktime.symantec.com/3TrjBmWdEfiS7oUVpmi3Wif7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908979441%26sdata%3D5aqxPRt0miAe5DsoenjkTn2qbJlVWTeciLtw9SBVn1E%253D%26reserved%3D0>
>
>
>
> 110) Service Provider discussion is confusing
> <https://clicktime.symantec.com/39cMDUsNGvSvaSRJP2CQiA57Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F110%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908979441%26sdata%3DKPNhnXV43eP8ZmdSqv3Vkbcj%252FPUlt5G3qYUgWPOBT%252F0%253D%26reserved%3D0>
>
> 111) Terminology section is not consistently ordered
> <https://clicktime.symantec.com/3VAiubTPBm8Nu7K6jeyK6yC7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F111%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908979441%26sdata%3DY%252FwhR2qzEc86xYboYueIlwI7jGUlIUnUp03qQ%252FclAMs%253D%26reserved%3D0>
>
> 112) Text about carriers is confusing
> <https://clicktime.symantec.com/35JbtAkeyAguJKDDbAswm587Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F112%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908989393%26sdata%3DR1xs7Zt7GAt%252Bj0cv8rE273CmG4Y%252FPSQ5bB1SXVVjUS0%253D%26reserved%3D0>
>
> 113) Section 6.2.3 contradicts section 4.2
> <https://clicktime.symantec.com/3EXPNKjMEAd6Hx9XSx5RnEP7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F113%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908989393%26sdata%3DfYt0nEoCNSxthFVKq%252FmxutxQgpThx8L1Vn3h%252BxLhKxE%253D%26reserved%3D0>
>
> 114) Figure 3 is too hard to understand
> <https://clicktime.symantec.com/3Pv5ZDeQraj9Kioz4xbxtPN7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F114%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908989393%26sdata%3Do%252F6RQy0IdDZQ1Z5wDYg5WVamJ31SS6JUzU8nCLB8ksk%253D%26reserved%3D0>
>
> 115) Reference to IANA number
> <https://clicktime.symantec.com/35d9oVECvbeBe1SvSPJ2Aix7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F115%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908999352%26sdata%3DxPDRcUGvaicejeAxxLOt5Cc%252BaFAEpe1X1XBnW8TOrY8%253D%26reserved%3D0>
>
> 116) Incorrect/obsolete statements about TEEP Broker
> <https://clicktime.symantec.com/39puLGz66Tz8pqU7Trrs6Lk7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F116%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908999352%26sdata%3DO8lfJd0TAW1aEU50xAO7U09PPsCtcrCCPBFNHlPC2pA%253D%26reserved%3D0>
>
>
>
> “App Developer” throughout, instead of using “Service Provider” in some
> places and “App Developer” in others
>
> and then saying they’re synonymous like it does now.   (I’d be ok with
> mentioning that in some contexts an App Developer
>
> might be known as a “Service Provider” if that is important to
> GlobalPlatform folks.)
>
>
>
> Dave
>
>
>
> *From:* TEEP <[email-masked]> *On Behalf Of *Konda, Tirumaleswar
> Reddy
> *Sent:* Monday, December 23, 2019 4:17 AM
> *To:* [email-masked]
> *Subject:* [Teep] Working Group Last Call for draft-ietf-teep-architecture
>
>
>
> Hi all,
>
>
>
> This message starts a Work Group Last Call (WGLC) for TEEP architecture.
> The version to be reviewed is
> https://tools.ietf.org/html/draft-ietf-teep-architecture-05
> <https://clicktime.symantec.com/3J8myVCnpenkHpNeAegdSaG7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Ftools.ietf.org%252Fhtml%252Fdraft-ietf-teep-architecture-05%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861909009306%26sdata%3DjkSiFYpG8FFVJUPk7nzK4VCH2j3im3RyFYtQj7ieHCw%253D%26reserved%3D0>
>
>
>
> Please send your comments to the list before this date and your assessment
> of whether or not it is ready to proceed to publication.
>
>
>
> Regards,
>
> Tiru & Nancy
>
> 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
> [email-masked]
>
> https://clicktime.symantec.com/3E4xJQVFydcmnjgspEbLjV47Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 13 Jan 2020 09:46:25 +0000

Hi Ming,

Please see inline [TR2]

From: Mingliang Pei <[email-masked]>
Sent: Sunday, January 12, 2020 12:12 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: Dave Thaler <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture

________________________________
Hi Tiru, thank you very much for your comments and suggestions. Thanks Dave and Hannes for prompt response for us.

Please see my comments inlines, mostly on top of your last replies, and for several questions that need additional clarification.

Thanks,

Ming

On Wed, Jan 8, 2020 at 11:53 PM Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Hannes and Dave,

From: Dave Thaler <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 8, 2020 1:14 AM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Working Group Last Call for draft-ietf-teep-architecture

Hi Tiru,

A few remarks below.

[As an individual]

Hi Dave,

[TR] Got it, Thanks.

The document (intentionally) makes no statement about whether a “close OS” as you put it, is or is not a TEE.   The question is really about whether such an OS prevents code injection attacks (e.g., due to buffer overruns or whatever else), prevents data modification attacks, etc..

[TR] Closed OS prevent the above attacks, a malicious app cannot read/modify the data of the other apps (e.g., ransomware attack is not possible, see https://support.google.com/chromebook/answer/3438631?hl=en<https://clicktime.symantec.com/3JPSEBNruBmUKctmhaBoGpT7Vc?u=https%3A%2F%2Fsupport.google.com%2Fchromebook%2Fanswer%2F3438631%3Fhl%3Den>).

This is issue #112 that I filed.   Personally I think the term “carrier” should be removed from the doc.

Dave has this issue tracked, and I added comment there. For one, "a network carrier" applies to mobile device only, and we have other TEE device types. On the other hand, the "network carrier" text does have some relevance here. For mobile devices, Trust Anchors are expected to be set by device manufacturers. What to put by a device manufacturer into devices, however, is often governed or instructed by the network carrier that a particular mobile device is produced for. That is the history of this context. I think we can make this as an example of set for such a case.

[TR2] Thanks for the clarification. You may want to add the mobile device example in the document.

[TR] Works for me.

“

“

[Hannes] If the REE is compromised then that’s typically not a good thing but the REE side still cannot access anything on the secure world, if implemented correctly. It could, however, indeed terminate the TEEP broker and avoid any calls to the secure world. This would be a DoS attack.. It would be possible to periodically schedule an interrupt that is processed by the secure world to let the secure world double-check the state of the normal world.

Right.  DoS attacks by the REE are, in general, not prevented (some TEEs may prevent them but most won’t).

Isn’t that what Figure 2 already provides?  Can you elaborate on what you’re looking for?

Sure.

[TR] Fair point.

However the word “instructs” is incorrect since the TEEP Agent is authoritative, your question should say “requests” instead, since the TEEP agent is free to ignore/reject the request.  (This is why section 6.2.1 has “RequestTA”, as does the transport spec.)

[MP] Good point. We can add this threat discussion in Security Consideration.

  *   an example of

Agree with Hannes.

[TR] Okay.

That whole paragraph is confusingly worded, and I currently plan to rewrite it based on my marked up hard copy ☺

[TR] Okay.

[MP] A TA software author can license the TA to multiple "buyers" who installs to their own user devices via their own TAM providers. The buyers are SPs in the original use case context. A TA developer doesn't necessarily distribute the TA. We have changed the meaning of SP to be interchangeable with an "App Developer" along with WG discussion, which treats the TA authorizer (SP) to devices as the owner of the TA.

A SP may provide its own "TA personalization data". Different SPs may provide different data. There needs a way to address the case when the same TA is installed to a device by multiple providers.  To this end, the proposal was to have different "identifiers" for the TA to multiple SPs so that they don't have to be overwritten. A Device Administrator may decide which TAM and TA it allows to install to devices.

This is certainly a complex case, and not expected to be common in practice.

[TR2] If it not a common practice today, suggest to remove it or if you think it will be useful in future, please add the above explanation of TA with different ‘identifiers’ from multiple SPs on the device.

Do you feel that we can disallow such a case where a TA author always directly works with a TAM service to distribute the TA? I feel that this licensed TA case may still have a place here.

[TR2] Yes, it deviates from the role of TAM to manage TAs on behalf of SP (as per the definition in Section 4.1).

[TR] Works for me.

[Hannes] it is more and more common today to protect binaries from inspection because this gives attackers a lot of information. If you don’t want to use it and only sign the binaries that’s fine too. But the option is there for you to protect the confidentiality of the binary.

I believe the use case is where the app developer considers the TA binary itself to be secret (e.g., intellectual property worth protecting), but wants to allow it to be distributed through a TAM that is run by another organization, one with more hosting capacity.   Thus the developer puts an encrypted binary in that TAM, and then runs their own lighter weight TAM that just hands out decryption keys which doesn’t need nearly as much much capacity/bandwidth.

[MP] I think this risk can be some contract between the TAM and the TA provider to manage. When a TAM doesn't want to risk its reputation to distribute malware, it may demand to inspect binary that a TA provider gives. Agree with you that a TAM most probably have the original TA binary access, who are not treated as an attacker by the TA developer.

[TR2] You should discuss the above point in the document. Please see https://thenextweb.com/apps/2020/01/10/google-joker-malware-play-store/ to understand how malicious apps are making their way into Google play store. These apps start with clean versions, grow user base and later introduce malicious code through updates.

Note that the more common case of TA binary encryption common is for the TAM to encrypt the TA binary to prevent any man-in-the-middle from inspecting the binary. App Developer encrypted TA binary has a decryption key distribution challenge to a device. The separate TAM was devised for this purpose, but that was largely used for "personalization data" support case.

“

“

[TR] Okay.

[MP] Agreed too. It was originally set there for local query without contacting a remote TAM to check a TA.

[TR] Okay.

I don’t believe there is any such requirement on a TAM.   It might be “useful” but is not required in my view.

[MP]  TA signature verification must be verified. Currently a TEE will check this code signing, and the CA certificate will be in TEE. See Figure 4 in the doc.

"Code Signing          1 per SP       TA binary          TEE"
Note the above "TA binary encryption" discussion. If a TA is given to a TAM in an encrypted form, such a signature check isn't feasible. But we can assume that TAM provider always vet TA binaries that it distributes for its service reputation protection.

Note that there is also the other TA delivery mode where a TA's binary is bundled inside an Untrusted Application as binary data. In this case, the binary isn't sent to TAM for distribution.

There is also the other case: many SPs / TA App Developers use the same extremely popular TAM service. Device manufacturers may want to limit to accept only a set of TA providers by using the code signing CA trust list. The architecture allows such support with the coding signing trust check in TEE.

[TR2] Got it, Thanks.

Cheers,
-Tiru

[MP] See above comment.

    (see https://android-developers.googleblog.com/2018/01/how-we-fought-bad-apps-and-malicious.html<https://clicktime.symantec.com/3WoTUQiqn8S8EL5UYFU7jhw7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fandroid-developers.googleblog.com%252F2018%252F01%252Fhow-we-fought-bad-apps-and-malicious.html%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908969481%26sdata%3DgNv0t73IFUqZmdnXjWmpb9bAyoYGfczM6oRe66Qlaog%253D%26reserved%3D0>)

It’s the responsibility of the TAM to not install malicious trusted apps, only authorized ones.

I don’t think it’s correct to say it’s the responsibility of the TAM to “remove” malicious trusted apps, since it shouldn’t have installed it in the first place.

The only case where “removal” might make sense is if the TAM previously authorized a trusted app, and later changed its policy that such TA is no longer authorized (e.g., because it was determined to be buggy or malicious or whatever else).

[MP] Good suggestion. We may touch on this point in Security Consideration section too.

-Tiru

Ciao

Hannes

Cheers,

-Tiru

________________________________
I opened one pull request for editorial issues (https://github.com/ietf-teep/architecture/pull/109<https://clicktime.symantec.com/351u59QLtaPT81TMTAvunqB7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fpull%252F109%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908969481%26sdata%3DS36SLw%252F2T7yK210awwzbpWTE0LAN9r1WFtkE5qG%252Bfl0%253D%26reserved%3D0>),
and filed seven other issues listed at https://github..com/ietf-teep/architecture/issues<https://clicktime.symantec.com/3TrjBmWdEfiS7oUVpmi3Wif7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908979441%26sdata%3D5aqxPRt0miAe5DsoenjkTn2qbJlVWTeciLtw9SBVn1E%253D%26reserved%3D0>

110) Service Provider discussion is confusing<https://clicktime.symantec.com/39cMDUsNGvSvaSRJP2CQiA57Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F110%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908979441%26sdata%3DKPNhnXV43eP8ZmdSqv3Vkbcj%252FPUlt5G3qYUgWPOBT%252F0%253D%26reserved%3D0>
111) Terminology section is not consistently ordered<https://clicktime.symantec.com/3VAiubTPBm8Nu7K6jeyK6yC7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F111%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908979441%26sdata%3DY%252FwhR2qzEc86xYboYueIlwI7jGUlIUnUp03qQ%252FclAMs%253D%26reserved%3D0>
112) Text about carriers is confusing<https://clicktime.symantec.com/35JbtAkeyAguJKDDbAswm587Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F112%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908989393%26sdata%3DR1xs7Zt7GAt%252Bj0cv8rE273CmG4Y%252FPSQ5bB1SXVVjUS0%253D%26reserved%3D0>
113) Section 6.2.3 contradicts section 4.2<https://clicktime.symantec.com/3EXPNKjMEAd6Hx9XSx5RnEP7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F113%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908989393%26sdata%3DfYt0nEoCNSxthFVKq%252FmxutxQgpThx8L1Vn3h%252BxLhKxE%253D%26reserved%3D0>
114) Figure 3 is too hard to understand<https://clicktime.symantec.com/3Pv5ZDeQraj9Kioz4xbxtPN7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F114%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908989393%26sdata%3Do%252F6RQy0IdDZQ1Z5wDYg5WVamJ31SS6JUzU8nCLB8ksk%253D%26reserved%3D0>
115) Reference to IANA number<https://clicktime.symantec.com/35d9oVECvbeBe1SvSPJ2Aix7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F115%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908999352%26sdata%3DxPDRcUGvaicejeAxxLOt5Cc%252BaFAEpe1X1XBnW8TOrY8%253D%26reserved%3D0>
116) Incorrect/obsolete statements about TEEP Broker<https://clicktime.symantec.com/39puLGz66Tz8pqU7Trrs6Lk7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fietf-teep%252Farchitecture%252Fissues%252F116%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861908999352%26sdata%3DO8lfJd0TAW1aEU50xAO7U09PPsCtcrCCPBFNHlPC2pA%253D%26reserved%3D0>

The possibly(?) contentious one might be that in #110 I am proposing to use the term
“App Developer” throughout, instead of using “Service Provider” in some places and “App Developer” in others
and then saying they’re synonymous like it does now.   (I’d be ok with mentioning that in some contexts an App Developer
might be known as a “Service Provider” if that is important to GlobalPlatform folks.)

Dave

Hi all,

This message starts a Work Group Last Call (WGLC) for TEEP architecture.  The version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-architecture-05<https://clicktime.symantec.com/3J8myVCnpenkHpNeAegdSaG7Vc?u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Ftools.ietf.org%252Fhtml%252Fdraft-ietf-teep-architecture-05%26data%3D02%257C01%257Cdthaler%2540microsoft.com%257Cbcf3b2c5f95b4c4c31fa08d79353ece5%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637139861909009306%26sdata%3DjkSiFYpG8FFVJUPk7nzK4VCH2j3im3RyFYtQj7ieHCw%253D%26reserved%3D0>

Regards,
Tiru & Nancy
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
[email-masked]<mailto:[email-masked]>
https://clicktime.symantec.com/3E4xJQVFydcmnjgspEbLjV47Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep

---

From: Dave Thaler <[email-masked]>
Date: Tue, 14 Jan 2020 00:21:30 +0000

[...]

[...]

[DT] The document (intentionally) makes no statement about whether a "close OS" as you put it, is or is not a TEE.   The question is really about whether such an OS prevents code injection attacks (e.g., due to buffer overruns or whatever else), prevents data modification attacks, etc.

[TR] Closed OS prevent the above attacks, a malicious app cannot read/modify the data of the other apps (e.g., ransomware attack is not possible, see https://support.google.com/chromebook/answer/3438631?hl=en<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.google.com%2Fchromebook%2Fanswer%2F3438631%3Fhl%3Den&data=02%7C01%7Cdthaler%40microsoft.com%7C4a1e761bc5b7412883c508d794d8f70d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637141531903517840&sdata=AqPSd3PJDgbfJRXfJMRIg7EiK8GYWqGY3XNaFQJj5tQ%3D&reserved=0>).

That link contains insufficient information to say whether a ransomware attack is possible, or whether the environment meets the other criteria of a TEE.  For example, the page mentions verified boot, which checks at boot time, but contains no statements about whether code modifications or additions are prevented post-boot.   The Sandboxing section implies (especially the part about "app" in there) that code can be added after boot, without requiring a security protocol equivalent to the TEEP protocol.  As such, I suspect it is inherently weaker than a TEE, and it would be an REE with classic security techniques.

It is not, however, the intent of this document to state whether such an OS is, or is not, a TEE.   The intent is to state the criteria for what is a TEE, and then provide an architecture for provisioning one, in a way that is sufficient for a reader to draw their own conclusions.

Dave

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 14 Jan 2020 08:04:00 +0000

Hi Dave,

Please see inline [TR2]

From: Dave Thaler <[email-masked]>
Sent: Tuesday, January 14, 2020 5:52 AM
To: Konda, Tirumaleswar Reddy <[email-masked]>; Hannes Tschofenig <[email-masked]>; [email-masked]
Subject: RE: Working Group Last Call for draft-ietf-teep-architecture

[...]

[...]

[TR2] Got it, Thanks for the clarification. My other comment is regarding the attacks discussed in first paragraph of Section 1. These attacks seem not possible in closed OS. For example, sideloading of apps is not possible (unless developer mode is enabled), so installing apps from untrustworthy sources is not applicable and data on which the applications are operating will not be revealed to other apps because of sandboxing.

-Tiru

Dave

---

From: Nicolae Paladi <[email-masked]>
Date: Thu, 16 Jan 2020 14:15:03 +0100

Hi,

Opened issue #127 - The definition of "Untrusted Application" under Terminology does not read well.
Suggesting a minor edit (removing one word).

Currently:

Untrusted Application: An application running in a Rich Execution Environment, such as an Android, Windows, or iOS application.

As it reads now, the statement defines an untrusted application as an application that is running in a Rich Execution Environment (REE). The statement next provides examples of REEs - "Android", "Windows"; and continues with an example of an application "iOS application". This set of examples is inconsistent and hence confusing.

Suggested
Untrusted Application: An application running in a Rich Execution Environment, such as an Android, Windows, or iOS.

Best regards,

Nicolae

> On 23 Dec 2019, at 13:17, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> Hi all,
>  
> This message starts a Work Group Last Call (WGLC) for TEEP architecture.  The version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-architecture-05 <https://tools.ietf.org/html/draft-ietf-teep-architecture-05>
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/teep <https://www.ietf.org/mailman/listinfo/teep>

---

From: Mingliang Pei <[email-masked]>
Date: Sat, 18 Jan 2020 23:11:38 -0800

Thanks Nicolae, agreed your suggestion, Ming

On Thu, Jan 16, 2020 at 5:15 AM Nicolae Paladi <[email-masked]> wrote:

> *Untrusted Application: An application running in a Rich Execution
> Environment, such as an Android, Windows, or iOS application.*
>
> As it reads now, the statement defines an untrusted application as an
> application that is running in a Rich Execution Environment (REE). The
> statement next provides examples of REEs - "Android", "Windows"; and
> continues with an example of an application "iOS application". This set
> of examples is inconsistent and hence confusing.
> Suggested
> *Untrusted Application: An application running in a Rich Execution
> Environment, such as an Android, Windows, or iOS.*
>
>
> Best regards,
> Nicolae
>
>
> On 23 Dec 2019, at 13:17, Konda, Tirumaleswar Reddy <
> [email-masked]> wrote:
>
> Hi all,
>
> <https://clicktime.symantec.com/3TQLbkkQueCxwGkB4jo52dg7Vc?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teep-architecture-05>
>
> https://www.ietf.org/mailman/listinfo/teep
> <https://clicktime.symantec.com/3PMGCxha6jdmFEKy9YpKbdM7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep>
>
>
> https://clicktime.symantec.com/3PMGCxha6jdmFEKy9YpKbdM7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>