The term regular operating system is ambiguous and even misleading.

Suggestion: replace with "commodity operating system" or "Rich Execution Environment".

Dave Thaler suggested to offer an optimization that allows the installation of a TA in single pass in
slide #7 of https://datatracker.ietf.org/meeting/102/materials/slides-102-teep-teep-hackathon-report-03

In Section 5.6 Keys and Certificate Types, §2 TEE Key pair and certificate (p. 17):

The cardinality of TEE key pair and certificate is currently 'one per device'.
However, according to the 'Scope and Assumptions', "This specification assumes that an applicable device is equipped with one or more TEEs"

Therefore, for devices with multiple TEEs, it could make sense to change the cardinality of TEE key pair and certificate to "one per TEE".

Otherwise, in an example where two installed TEEs are produced by different manufacturers (unlikely, but potentially possible?), the two manufacturers would have to agree on how to produce a shared keypair/certificate.

Both the architecture document as well as the OTrP specification use the term "Agent" to refer to an entity that relays the messages between the TAM and the TEE. It was proposed to use an alternative term instead and now we are searching for a suitable name.

Here is the discussion: https://www.ietf.org/mail-archive/web/teep/current/msg00355.html

Section 7.4 has some API reference on SD APIs that should be removed in the next update.

"When a new key pair is generated for a TA-to-TAM or TA-to-SP
communication, the keypair must be covered by an attestation,
including "CreateSecurityDomain" response, "UpdateSecurityDomain"
response, etc."

Slide 8 and 9 in https://datatracker.ietf.org/meeting/102/materials/slides-102-teep-teep-architecture-draft-02 raise the issue that the Agent needs to route the messages to the correct TEE. This adds extra functionality for the Agent implementation.

Dave Thaler noted that the document seems to assume that every rich app that needs a TA, also needs to have code to talk to a TAM.

He states:

• I agree that's one possible implementation but the architecture should not require that.

• An alternative implementation would be where the REE OS (e.g., the app store installer) contains code for communicating with TAM(s) using data in (for example) the rich app's manifest, and the rich app has no need to run until the TA is already installed. The installer/communicator is a rich app of a sort, but it's a different one from the client app that depends on the TA.

In his opinion, the arch doc should not require that it's the same app, but should certainly allow it to be.

The architectural diagram appropriate shows the TEEP Broker being the initiator to communicate with the TAM; however, is it the case that the TEEP Broker is the initiator to communicate with the TEE?

The question asked by our notetaker RW: in the diagram, Dave W said any comms between the device and a TAM is initiated by the device (not the TAM). Is that implicit, in the diagram, in the unidirectional arrow from the device (specifically, the TEEP Broker) to the TAM? If so, do the unidirectional arrows between other components in the diagram represent the same implicit rule (i.e. that the origin of the arrow denotes the element that always initiates communication)?

A SP may need support that a TA is only installed to devices that have assurance the confidential algorithms in a TA not get disclosed. This needs some architecture support.

TA binary itself is supported as being encrypted when it is delivered from a TAM to TEE, encrypting using a TEE's key. The question is how a SP allows a TAM to deliver its TA without disclosing it.

The confidential piece may thus becomes a "personalization data" to a TA. The TA binary can be shared with a TAM, but the confidential data remains at SP, and it should be delivered with end-to-end security to a device TEE.

In most discussions the TEEP messaging interaction has been described as a protocol that runs between the TAM and the TEE with a relay (Agent) that passed messages back and forth.

However, the OTrP specification also gives a role to the Client Application not only in the sense of triggering the interaction (since the TEE itself cannot communicate to the outside world on its own) but via the GetTAInformation call. The GetTAInformation call described in Section 6.4.2 of https://tools.ietf.org/html/draft-ietf-teep-opentrustprotocol-01 allows a Client Application to query a TEE about a previously installed TA without requiring the interaction with a TAM.

In order for this to work the Client Application has to known the TA's identifier and also the AIK public key.

The Client App has to obtain this information somehow.

The important implication of allowing the Client App to participate in the TEEP message exchange is that the protocol interaction becomes a three party interaction rather than a two party protocol. There is also the need to consider the encoding of the protocol messages so that they are friendly for app developers since the Client App needs to deal with the TEEP messaging exchanges.

As this functionality appears to be an optimization it would be good to know how much is actually gained by this optimization.

In the translation from XML to Markdown the text describing the example in Section 5.12. A Sample Device Setup Flow got messed up. Text may have gotten lost as well.

Terminology should either be in alphabetical order, or in a natural order where terms are defined without forward references. Currently it seems to be an odd mix of the two.

Currently the TEEP architecture draft supports TAM to distribute a TA binary and device specific information. It calls for further work to support the case where a TA binary is supplied by a Client Application. This is the case how GSX distributes a TA today.

The case support is considered in scope in IETF 101 TEEP WG discussion. See more TEEP mailing discussion with David Wheeler.

One of the original motivation to require a TAM is that both TA binary and any device specific configuration for the TA will be encrypted when it is sent to a device, ensuring better protection of TA binary. It has some challenge to still meet this security property if a TA binary is included in a Client Application in an Application Store. We could lower the security requirement that TA binary is just signed and make encryption optional. We need to work out the related verification protocol specification in the TEE side.

Page 4 talks about "Service Providers (SP)", that intend to provide "services" through a TA, but never explains what this means, or what such 'services' refer to. It's also confusingly similar to the term ISP so is unclear whether it's similar or different.

Section 4.6 then talks about the "App Developer" and even says "For the purpose of this document there is no difference between the SP and the app developer".

Since they are apparently synonymous, my reading is that the document would be far easier to read if the draft just use the term "App Developer" instead of "SP".

Dave Thaler raised the issue and recommended that the first request from a Client Application should start from requesting TEE to sign and then to TAM, not TAM to TEE.

"As I noted in my arch doc comments, I disagree that there needs to be any communication between the rich app being installed, and the TAM. A valid implementation model should be that the app store installer reads the metadata (including TA dependencies) about the rich app, and as part of installing the rich app (without ever needing to run it), the installer can communicate with the TEE to express those dependencies, which then triggers the TEE to generate a signed message to the TAM, which can be related by the installer."

See also slide 3 and4: https://datatracker.ietf.org/doc/slides-102-teep-teep-hackathon-report/

Can a single Client Application be configured to talk to various TAMs? For example, if it requires multiple TAs could those be provided by different TAMs? For a single TA case is it possible that the Client App is able to select from which TAM it is provided, particularly when the TA is personalized (and potentially personalized differently by different TAMs). Should we make simplifications here?

Nancy wrote in https://mailarchive.ietf.org/arch/msg/teep/yuRULH2HhCsh2Tsu5NJlgC5HcJM

I would now like to announce a reorganization of the TEEP Architecture editors list to include:
Ming Pei, David Wheeler, David Thaler, and Hannes Tschofenig.  I would like to thank A. Atyeo
and L. Dapeng for their valuable Contributions to the originating draft and expect them to be
noted as contributors in that section.

This still needs to be done in the document

Related to issue #16 : the architecture document uses both the terms "Agent" and "TEEP Broker". According to issue #16, the decision is only to use the term "broker".

Suggestion: replace the terms "agent" and "TEEP broker" with "broker".

draft-faibish-iot-ddos-usecases-00 issues; questions
Should this draft be part of TEEP WG?
Does TEEP WG need more detailed protocol implementation before accepting as a WG document?
Is TEEP Ready to adopt as TEEP WG document?
Perhaps if it is accepted can these usecases added to the architecture document? How?

draft-faibish-iot-ddos-usecases-00 issues
Is TEEP the right security protocol to prevent DDoS attacks from ioT devices. Types of attacks could be random network traffic generated, reflection of network packets or amplification of legitimate network packets.

• Requested Components: A list of zero or more components (TAs or
  other dependencies needed by a TEE) that are requested by some
  depending app, but which are not currently installed in the TEE.

How does this information carried inside the attestation payload relate to the info conveyed in the TEEP protocol?

In slide #9-11 of https://datatracker.ietf.org/meeting/102/materials/slides-102-teep-recommendations-for-teep-support-of-intel-sgx-technology-02 David Wheeler argued that the TEEP architecture (and consequently OTrP) need to be flexible with regards to the use of different attestation mechanisms.

At the IETF Montreal meeting it was suggested that there is a possible link to the proposed EAT work. For EAT see https://www.ietf.org/mailman/listinfo/eat

We use the following term:

"

• Trusted Execution Environment (TEE): An execution environment that
  runs alongside of, but is isolated from, an REE.
  "

Cristofaro Mune suggested to use the following definition instead:

"

• Trusted Execution Environment (TEE): An execution environment that
  runs alongside of, but is separated from, an REE.
  "

Argument: Isolated means that the TEE and the REE do not communicate

Trust Anchors are typically a list of Certification Authority (CA) certificate. It can be also public key of a trusted authority and identifier. Trust Anchors are assumed to be implemented by TEEs. The format of list or public key are assumed to be the well known format such as X.509 certificate.

A specific format to define such a list for Trust Anchor update is considered also out of scope for TEEP architecture. This may be worthy some consideration for a later separate draft as an advanced feature.

[DT: Some of the below are already tracked by other GitHub issues, but copying entirety here to make sure I don't miss something]

Schönwälder, Jürgen [email protected] wrote:

• RFC 2119 language

  This seems mainly used in the section about attestations. Do we
  really need RFC 2119 terms in this architecture document? Some of
  the SHALLs do not seem to be really needed.

[DT: above is tracked by issue #69]

• UA == CA ?

  The introduction introduces UA but then this is only used again once
  in 5.2. Given that section 2 starts with defining CA, is CA the same
  as UA (and hence UA should be replaced with CA)?

[DT: above is tracked by issue #55]

• root of trust

  This definition remains a bit unclear and it ends with an ad-hoc
  reference to a NIS draft. I searched for RoT in the document but it
  is not widely used. Perhaps this term can even be replaced by simply
  expanding the definitions of TFW a bit?

• acronyms and terms

  I notice that not all terms for which acronyms are defined at the
  end of section 2 are actually defined terms. Perhaps they should all
  be defined? Missing are TAM (Trusted Application Manager) and SD
  (Security Domain). The later one (SD) in particular would benefit
  from a definition.

[DT: SD is tracked by issue #62]

• assumptions

  Does it make sense to have a top-level section consisting of just two
  sentences? Perhaps move this into a subsection of the architecture
  section?

• #notionalarch

  What is #notionalarch? A broken reference to Figure 1?

• typo caption figure 2

  s/wtih/with/

• typo 5.5

  s/would required/would require/
  s/recieve/receive/

• typo 5.7

  s/may different/may be different/

• trust anchors

  It seems that managing trust anchors will be crucial in order to
  deal with 'crypto gone wrong' scenarios. Is it really smart to leave
  management and updates to proprietary mechanisms? Why can't trust
  anchors not be managed like other TEE data? What is the reason to
  declare this out of scope - too complex? too hard to find agreement?
  Will trust anchor changes cause installed TAs to be removed if they
  lost their trust?

[DT: above is tracked by issue #32]

• message security

  It may help to clarify what the 'ends' are in the statement
  "messages are signed end-to-end". In particular, is the end the TEEP
  Agent and the TAM?

• teep broker

  I am not sure what "A shared module in REE comes to meet this need."
  tells me. What is a "shared module"? Perhaps the sentence can simply
  be removed.

  I am not sure the text is really clear. There are two kinds of
  interactions, a CA needing a TA to be made available and CA using a
  TA. I assume the first goes with the TEEP broker but the later via
  REE OS mechanisms. Or does the TEEP broker provide the single
  interface via which CAs request TA services?

• attestation

  "but the OTrP protocol SHALL allow" - this is the first time OTrP
  shows up and RFC 2119 language is used; did you mean to say a TEEP
  protocol? or something like that?

[DT: above is tracked by issue #17]

• crypto properties

  Does it really make sense to fix digital signature formats in an
  architecture document? The list of formats will likely change over
  time; so it is good to define MUST for today's blessed list?

[DT: above is tracked by issue #17]

• figure teep attestation layout

  Perhaps change the layout such that the claims are listed one below
  the other instead of next to each other (this way things may fit
  into the space - yes, I am still using 80 column terminals).

[DT: above is tracked by issue #17]

• typo attestation flow

  s/Attesations/Attestations/

• security

  Why does that text say "should be validated" instead of "must be
  validated"?

[DT: above is covered by issue #69]

What is the GetTAInformation function discussed in the security
considerations? It seems to fall out of the air.

Several places in the doc use the term "carrier" without explaining why that's even relevant. The roles defined were TAMs, device administrators, SPs (or app developers), etc., but not carriers so why are they relevant?

Also the "Multiple TAMs and Relationship to TAs" has text about "mobile devices" which also shouldn't appear except as an example, since many TEEs to which TEEP would apply are not in mobile devices.

There needs a way to update Trust Anchor in a device, being a list of root CA certificates or public keys.

In a discussion between Dave and Ming, we consider to introduce a specific TA, namely, Manager TA, which is responsible to manage Trust Anchor update policies and where to get updated trust anchors.

This Manager TA is usually pre-installed inside a TEE.

David Wheeler raised this issue in slide 8 of https://datatracker.ietf.org/meeting/102/materials/slides-102-teep-recommendations-for-teep-support-of-intel-sgx-technology-02 since SGX does not depend on secure boot.

Section 7.1 Attestation Hierarchy mentions that "seed required for TAM protocol operation must be built into the device at manufacture".

This is technically correct, but considering that the architecture assumes the presence of multiple TEEs on the device, it could be rephrased as "seed required for TAM protocol operation must be built into the TEE at manufacture".

In discussion with Ming we were wondering whether there are restrictions regarding the attestation mechanism on what it can sign. Currently, the OTrP design assumes that the secure OS running in the TEE has access to the device certificate, which was provisioned during manufacturing, and that it signs whatever data is given to it. There may, however, be restrictions in what an attestation mechanism signs, for example when it offers only a restricted API. If that's indeed the case then a message from the TEE to the TAM would have to contain two signatures, namely one for the signed attestation data and another one for the signed message.

To get an answer to this question we thought it would be useful to survey existing attestation technologies.

This issue was raised by David Wheeler on slide #12 of https://datatracker.ietf.org/meeting/102/materials/slides-102-teep-recommendations-for-teep-support-of-intel-sgx-technology-02

The definition of "Device Administrator" (p.6) mentions that "A device owner can manage the list of allowed TAMs by modifying the list of Trust Anchors on the Device.".

The device owner is neither defined nor mentioned elsewhere in the document; therefore, it should either be turned into 'device administrator' or defined.

The Device User is explicitly defined as a human being (...). This excludes the cases when a device with a TEE may be a component of larger chain of devices interoperating by exposing services (some sort of a pub-sub system) and is never actually directly used by a human user.

Suggestion: extend the definition of "Device user" to include also network services running on other devices.

Section 5.5 has:
[NOTE: Need to add an equivalent discussion for an ARM/TZ
implementation]

Section 5.6 has:
[Note: discussion of format of this single binary, and who/what is
responsible for splitting these things apart, and installing the
client app into the REE, the TA into the TEE, and the personalization
data into the TEE or TA. Obviously the decryption must be done by
the TEE but this may not be supported by all TAs.]

The sentence "It is important to ensure a legitimate agent is installed and used. If an agent is compromised it may drop messages and thereby introduce a denial of service." is not necessary here, since:

1. It is discussed under "Security considerations"
2. The Agent (i.e. broker) is one of the many ways of running a DOS attack on the TEE and does not need any extra highlighting; the Rich Execution Environment, considered explicitly untrustworthy, may simply block the TEEP I/O and equally perform a DOS attack.

Suggestion: remove the sentence "It is important to ensure a legitimate agent is installed and used. If an agent is compromised it may drop messages and thereby introduce a denial of service."

The term "security domain" is described in the architecture document as:

A Security Domain (SD) concept is used as the security boundary
inside a TEE for trusted applications.

There seems to be an implicit assumptions that trusted applications do not share resources with other trusted applications. The security domain concept then seems to allow to enable this sharing. Global Platform has been referenced as the source of this concept but unfortunately I wasn't able to find a definition in the Global Platform documents. The question is also what resources would be shared between TAs.

The introduction of the Security Domain concept has also other side effects on the protocol specification:

First, it requires separate messaging for creating and deleting security domains.

Second, it requires added protocol elements to reference security domains.

Third, the Anonymous Attestation Key (AAK) is established and maintained for use with security domains.

Made a slide to have a example of keys, certs and CA certs described in the draft for start prototyping the flow of TA insert and delete.

TEEP-OTrP-key-locations-IETF-105.pdf

As the architecture seems to still be under consideration I take the liberty suggesting an alternative to the current static TEE attestation scheme. This is based on experiences gathered at the Office of the CTO of RSA Security and in TCG. The idea is simply that an attestation challenge-response sequence in addition to transferring trust information, also creates a "session" and an associated shared session key. This enables a bunch of potentially useful features:

• High-level human-readable MAC-protected API talking binary to primitive (resource constrained) TEEs
• Offloading JSON and BASE64 encoding/decoding, Networking and UI to the REE level
• Makes the TEE part independent of protocol language (XML/JSON/CBOR)
• Encryption using derived session key
• API and response aggregation/pipe-lining
• User interaction inside of the protocol
• Provisioning of complex structures in a step-wise fashion
• Virtual namespace eliminates need for explicit key IDs
• Atomic multi-phase provisioning
• Credential management with issuer isolation

This has been successfully applied to a Secure Key Store/Provisioning Protocol powering a universal "Wallet" coined Saturn.

"TEE": https://cyberphone.github.io/doc/security/sks-api-arch.pdf
Protocol: https://cyberphone.github.io/doc/security/keygen2.html#Sample_Run
IPR declaration: https://priorart.ip.com/IPCOM/000215433

All features above may not be meaningful in a TEEP scenario.

Disclaimer: the scheme above has not been subjected to a peer review

At IETF#103 Erik Nordmark suggested to talk about the case where the TAM updates the TA to a new version but then also has to consider the compatiblity between the normal world app and the TA

From IETF#103:

Robin W asks (in the notes so as to not interrupt note taking) : in the diagram, Dave W
said any comms between the device and a TAM is initiated by the device (not the
TAM). Is that implicit, in the diagram, in the unidirectional arrow from the device
(specifically, the TEEP Broker) to the TAM? If so, do the unidirectional arrows between
other components in the diagram represent the same implicit rule (i.e. that the origin of
the arrow denotes the element that always initiates communication)?
Nancy CW: Yes, that is the intent. Although, we should confirm this with the authors,
so we can open an issue to track this.

Terms "untrusted application and "client application" are used interchangeably:
Compare:

"An application component running inside a TEE is referred to as a Trusted Application (TA), while a normal application running in the regular operating system is referred to as an Untrusted Application (UA).
"
AND
"
Client Application: An application running in a Rich Execution Environment, such as an Android, Windows, or iOS application. We sometimes refer to this as the 'Client App'.
"

Suggestion: adopt same terminology throughout the document

There was discussion of case where a TA may depend on another TA, in theory, possibly from a different provider.

• who initiates the installation of the dependent TA?
• should a Client App specifies those dependency in its metadata so that those can be installed?

See slide #10 in https://datatracker.ietf.org/doc/slides-102-teep-teep-hackathon-report/

TPMs have been mentioned in the past in discussions as a TEE technology that could make use of the TEEP functionality. It appears that their functionality today is too limited to have them in scope for TEEP.

A discussion can be found here: https://www.ietf.org/mail-archive/web/teep/current/msg00357.html

Similar to issue #53, the use term for the (de-facto) Rich Execution Environment is used inconsistently - either "regular", or "normal", or "typical" (p.6) operating system.

Suggestion: adopt same terminology throughout the document.

The TEE key pair and certificate are used for authenticating the TEE
to a remote TAM. Often, the key pair is burned into the TEE by the
TEE manufacturer and the key pair and its certificate are valid for
the expected lifetime of the TEE.

The term "burned into" gives me the impression that these keys are never changed. The security consideration section says something different. So, what are we trying to say?

Column "Location" in Figure 6: Key and Certificate Types contains both "Device secure storage" and "Device TEE". I suspect they are intended to mean the same thing and this must be reflected in the text.

Suggestion: use the term "Device TEE"

Issue was brought up in the WG meeting in Bangkok.

If the TAM updates a TA in a device, the update might break compatibility withe the UA (untrusted app)
In some cases (many cases) the change to the TA will require a commensurate change in the UA.
The text needs to be changed so that there is cooperation between the update in the TA and UA.

Since all things are triggered from the client device (not the TAM), the update of the TA should be trigger when the UA is updated and get the appropriate most updated TA that complies with the needs of the application.

The other concern has to do with a TA that is bound to multiple different UAs, and one requires a certain (newer) version, and another UA still requires the older version. This needs to be handled as well.

Currently the document shows an intended status of Informational.
But terminology section defines RFC 2119 terms, which are then used in a number of sections (7, 7.1, 9.5, 9.6, etc.) in statements like:

The Attestation Header SHALL identify the "Attestation Type" and the "Attestation Signature Type" along with an "Attestation Format Version Number."

The claims themselves SHALL be defined in an attestation claims dictionary.

That registry SHALL be defined in the OTrP protocol …

Any intermediate CA for TEE device certificates SHOULD be validated by TAM with a Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) method.

The TEE SHOULD use validation of the supplied TAM certificates and OCSP stapled data to validate that the TAM is trustworthy.

So this begs two questions:

1. Do we expect things to claim 'conformance' to this document? If so, should it be standards track instead of informational? Or if we don't, then should we remove normative language?
2. Who can claim conformance to this document, document writers or implementers? Currently the requirements language seems to be an odd mix of both, with some like "That registry SHALL be defined in the OTrP protocol" being requirements for document writers, while others are requirements for implementers. Trying to mix both in the same document is at best confusing. It would be better to have only one or the other, or else to put them into separate sections that are clearly distinguished as requirements for implementers vs requirements for document authors.

Consider a test lab wanting to write a test suite. Should they look at this doc? (yes if standards track, no if informational?) If they do, which SHALLs do they need to write test cases for? If they haven't been in all the TEEP discussions, it's really hard to tell.

From IETF#103:

v01 now includes text to define and distinguish between

• Trust Anchor
• Root of Trust
  Eric Norrmark: over the course of the device lifecycle, there are times when more than
  one trust anchor will be present (for example, when transitioning from one trust anchor
  to its replacement). Follow-up question: does the architecture define any mechanism
  other than an expiry date in a certificate, to indicate when a trust anchor should be
  replaced.
  Russ H: suggests adding text to define 'trust anchor fingerprint' and its role as part of
  the validation/replacement process for trust anchors.
  Nancy C-W where would this term be used in the documentation as a whole?
  Dave T: rather than add as a discrete term definition, append this text to the definition
  of 'trust anchor'.
  General “nod’ from the participants in the room

draft-faibish-iot-ddos-usecases-00 issues

Should TEEP WG address the use cases for DDoS prevention in the architecture draft?
Use case 1: Upgradable OS less IoT devices
Use case 2: IoT devices connected to gateway
Use case 3: Smart IoT devices with rich OS