Subject: [Teep] TEEP go forward plan and charter text

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 29 Jan 2018 16:58:51 -0500

Hello,

With agreement from IETF 100 that there is sufficient effort to work
on TEEP and now a better understanding from GP, I think we are in a
position to firm up charter text and to try to charter a working group
prior to London.  With that, we'll need to look at the charter text
and be sure we have agreement, before I can kick off review within the
IESG.

I *think* the last charter text is what was entered on the TEEP page,
but am open to be corrected.  That should be our starting point for
discussion.  I think the BoF chairs will be able to assist with this
process, but I'm not positive on their schedules.  As such it may be a
mix of the chairs and AD working on this to see if we can get
agreement on charter text.

https://datatracker.ietf.org/doc/charter-ietf-teep/

Copied here for your convenience:

The Trusted Execution Environment (TEE) is a secure area of a processor.
The TEE provides security features, such as isolated execution, integrity of
Trusted Applications along with confidentiality of their assets. In general
terms, the TEE offers an execution space that provides a higher level of
security than a "rich" operating system and more functionality than a secure
element. For example, implementations of the TEE concept have been
developed by ARM, and Intel using the TrustZone and the SGX
technology, respectively.

To programmatically install, update, and delete applications running in the
TEE, this protocol runs between a service running within the TEE, a relay
application or service access point on the device's network stack and a
server-side infrastructure that interacts with and optionally maintains the
applications. Some tasks are security sensitive and the server side requires
information about the device characteristics in form of attestation and the
device-side may require information about the server.

Privacy considerations have to be taken into account with authentication
features and attestation.

This working group aims to develop an application layer protocol providing TEEs
with the following functionality, * lifecycle management of trusted
applications, and * security domain management.

A security domain allows a service provider's applications to be isolated so
that one security domain cannot be influenced by another, unless it exposes an
API to allow it.

The solution approach must take a wide range of TEE and relevant technologies
into account and will focus on the use of public key cryptography.

The group will produce the following deliverables. First, an architecture
document describing the involved entities, their relationships, assumptions,
the keying framework and relevant use cases. Second, a solution document that
describes the above-described functionality. The choice of encoding format(s)
will be decided in the working group. The group may document several
attestation technologies considering the different hardware capabilities,
performance, privacy and operational properties.

The group will maintain a close relationship with the GlobalPlatform, Trusted
Computing Group,  and other relevant standards to ensure proper use of existing
TEE-relevant application layer interfaces.

-- 

Best regards,
Kathleen

---

From: Dapeng Liu <[email-masked]>
Date: Wed, 31 Jan 2018 03:49:22 +0000

Hello Kathleen,

The charter looks good for me.

Thanks!

Regards,
Dapeng Liu

On Tue, Jan 30, 2018 at 5:59 AM Kathleen Moriarty <
[email-masked]> wrote:

> _______________________________________________
> TEEP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teep
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 31 Jan 2018 16:18:03 +0000

Hi Kathleen,

Thanks for the update. It is good to hear that there is progress.

The text below sounds good; I only have a few minor remarks:

---

s/To programmatically install, update, and delete applications running in the TEE, this protocol runs between a service running within the TEE, a relay application or service access point on the device's network stack and a server-side infrastructure that interacts with and optionally maintains the applications. Some tasks are security sensitive and the server side requires information about the device characteristics in form of attestation and the device-side may require information about the server./ To programmatically install, update, and delete applications in a TEE, this protocol runs between a service within the TEE, a relay application or service access point on the device's network stack and a server-side infrastructure that interacts with and optionally maintains the applications. Some tasks are security sensitive and the server side requires information about the device characteristics in form of attestation and the device-side may require information about the server.

Reason: Just some wording changes to avoid repeated use of "running".

---

---

s/This working group aims to develop an application layer protocol providing TEEs with the following functionality, * lifecycle management of trusted applications, and * security domain management./
This working group aims to develop an application layer protocol providing TEEs with lifecycle management of trusted applications.

Reason: I would just simplify it and not go into the details. I believe that this functionality is also covered in the  lifecycle management of trusted applications.

---

---

s/The group will maintain a close relationship with the GlobalPlatform, Trusted Computing Group,  and other relevant standards to ensure proper use of existing TEE-relevant application layer interfaces./
The group will maintain a close relationship with the IETF SUIT working group, GlobalPlatform, Trusted Computing Group, and other relevant standards to ensure proper use of existing TEE-relevant application layer interfaces.

Reason: I want to explicitly state that this group has to work closely with the SUIT WG to ensure proper alignment.

---

Ciao
Hannes

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: 29 January 2018 22:59
To: teep
Subject: [Teep] TEEP go forward plan and charter text

Hello,

With agreement from IETF 100 that there is sufficient effort to work on TEEP and now a better understanding from GP, I think we are in a position to firm up charter text and to try to charter a working group prior to London.  With that, we'll need to look at the charter text and be sure we have agreement, before I can kick off review within the IESG.

I *think* the last charter text is what was entered on the TEEP page, but am open to be corrected.  That should be our starting point for discussion.  I think the BoF chairs will be able to assist with this process, but I'm not positive on their schedules.  As such it may be a mix of the chairs and AD working on this to see if we can get agreement on charter text.

The Trusted Execution Environment (TEE) is a secure area of a processor.
The TEE provides security features, such as isolated execution, integrity of Trusted Applications along with confidentiality of their assets. In general terms, the TEE offers an execution space that provides a higher level of security than a "rich" operating system and more functionality than a secure element. For example, implementations of the TEE concept have been developed by ARM, and Intel using the TrustZone and the SGX technology, respectively.

To programmatically install, update, and delete applications running in the TEE, this protocol runs between a service running within the TEE, a relay application or service access point on the device's network stack and a server-side infrastructure that interacts with and optionally maintains the applications. Some tasks are security sensitive and the server side requires information about the device characteristics in form of attestation and the device-side may require information about the server.

Privacy considerations have to be taken into account with authentication features and attestation.

This working group aims to develop an application layer protocol providing TEEs with the following functionality, * lifecycle management of trusted applications, and * security domain management.

A security domain allows a service provider's applications to be isolated so that one security domain cannot be influenced by another, unless it exposes an API to allow it.

The solution approach must take a wide range of TEE and relevant technologies into account and will focus on the use of public key cryptography.

The group will produce the following deliverables. First, an architecture document describing the involved entities, their relationships, assumptions, the keying framework and relevant use cases. Second, a solution document that describes the above-described functionality. The choice of encoding format(s) will be decided in the working group. The group may document several attestation technologies considering the different hardware capabilities, performance, privacy and operational properties.

The group will maintain a close relationship with the GlobalPlatform, Trusted Computing Group,  and other relevant standards to ensure proper use of existing TEE-relevant application layer interfaces.

--

Best regards,
Kathleen

_______________________________________________
TEEP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teep
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: Jeremy O'Donoghue <[email-masked]>
Date: Wed, 31 Jan 2018 23:13:01 +0000

Hi Kathleen, TEEP,

I have a few remarks on the proposed Charter text.

The second of Hannes’ proposed changes (removal of “security domain management”) makes the following paragraph “A security domain allows…” seem out of place.

I suggest that we reject Hannes’ second change.

s/A security domain allows a service provider's applications to be isolated so that one security domain cannot be influenced by another, unless it exposes an API to allow it.

The solution approach must take a wide range of TEE and relevant technologies into account and will focus on the use of public key cryptography ./A security domain allows a service provider's applications to be isolated so that one security domain cannot be influenced by another, unless it exposes an API to allow it.

The solution approach must take a wide range of TEE and relevant technologies into account and will focus on the use of public key cryptography and interoperability with GlobalPlatform OTrP.

Reason: interoperability with other OTrP systems; makes sense given the co-operation with GlobalPlatform proposed below.

s/The group will maintain a close relationship with the IETF SUIT working group, GlobalPlatform, Trusted Computing Group, and other relevant standards to ensure proper use of existing TEE-relevant application layer interfaces./The group will maintain a close relationship with the IETF SUIT working group, GlobalPlatform, Trusted Computing Group, and other relevant standards to ensure proper use of existing TEE-relevant application layer interfaces and to ensure that interoperability is maintained with the standards from these groups.

Reason: interoperability is the explicit goal of relationships with other groups active in the field.

Best regards
Jeremy

On 31 Jan 2018, at 16:18, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kathleen,

---

---

---

---

---

---

Ciao
Hannes

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: 29 January 2018 22:59
To: teep
Subject: [Teep] TEEP go forward plan and charter text

Hello,

--

Best regards,
Kathleen

---

From: Mingliang Pei <[email-masked]>
Date: Thu, 1 Feb 2018 01:24:39 +0000

Hi Jeremy, Kathleen and TEEP,

>> to ensure that interoperability is maintained with the standards from these groups.

There was some prior discussion on scope and definition of “interoperability” in the thread. I think the interoperability with other group standards is desirable but I don’t think we want to strongly put it a strict requirement because of potentially unclear scope and constraints. The previous text looks fine to me in ensuring “proper” use of existing application layer interfaces.

Best regards,

Ming

From: TEEP <[email-masked]<mailto:[email-masked]>> on behalf of Jeremy O'Donoghue <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 31, 2018 at 3:13 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>, teep <[email-masked]<mailto:[email-masked]>>
Subject: [EXT] Re: [Teep] TEEP go forward plan and charter text

Hi Kathleen, TEEP,

Best regards
Jeremy

Hi Kathleen,

---

---

---

---

---

---

Ciao
Hannes

-----Original Message-----
From: TEEP [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
Sent: 29 January 2018 22:59
To: teep
Subject: [Teep] TEEP go forward plan and charter text

Hello,

https://datatracker.ietf.org/doc/charter-ietf-teep/<https://clicktime.symantec.com/a/1/EQb_IqctHFt2aRnBsLG9okbnSbsSPP2nm9dA3Un0w3E=?d=6xPRcUZrOszZDqnJFGwfEcGCmqGLQsDTov6TGrcEHTPXN_TWSZ-Bu5wCGs2rTULth4WH-47Nz7WyFPPryjBaoxmWknzDjnNj_jcYfY2UkOKG2eopxEwdaO3qu4Yr0CyyShFZ5-E2-YLtG1nOzvQxravaGKT4PjiBYqbeU1QzpyEDs-AGzwxGTmkLycI38jsTcYFSw3iOmlp0bgpni5WvuLFW2_sXOY-S1jX16txAEECpj2qGDraRBLZy5p3wh6HTvZ-Iwy6XXImGbMe2DOUfUruzYfihDhhPBi6DjhDntBOBAThtAnLOXDjPTbMWqyiGA_aKsM6BzHXDEE5BgVBSNjAqUOxVpxpX2y7Fg7ySmcnuORkT7mlfj9C2m_bm1lggso_f8UrUqPqgo-xe2jdH&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-teep%2F>

--

Best regards,
Kathleen

_______________________________________________
TEEP mailing list
[email-masked]<mailto:[email-masked]>
https://clicktime.symantec.com/a/1/70vmngcZmPTPWU_c8qcm4Hxu9BtCIo0S3JyHQQjRT_M=?d=6xPRcUZrOszZDqnJFGwfEcGCmqGLQsDTov6TGrcEHTPXN_TWSZ-Bu5wCGs2rTULth4WH-47Nz7WyFPPryjBaoxmWknzDjnNj_jcYfY2UkOKG2eopxEwdaO3qu4Yr0CyyShFZ5-E2-YLtG1nOzvQxravaGKT4PjiBYqbeU1QzpyEDs-AGzwxGTmkLycI38jsTcYFSw3iOmlp0bgpni5WvuLFW2_sXOY-S1jX16txAEECpj2qGDraRBLZy5p3wh6HTvZ-Iwy6XXImGbMe2DOUfUruzYfihDhhPBi6DjhDntBOBAThtAnLOXDjPTbMWqyiGA_aKsM6BzHXDEE5BgVBSNjAqUOxVpxpX2y7Fg7ySmcnuORkT7mlfj9C2m_bm1lggso_f8UrUqPqgo-xe2jdH&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
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/a/1/70vmngcZmPTPWU_c8qcm4Hxu9BtCIo0S3JyHQQjRT_M=?d=6xPRcUZrOszZDqnJFGwfEcGCmqGLQsDTov6TGrcEHTPXN_TWSZ-Bu5wCGs2rTULth4WH-47Nz7WyFPPryjBaoxmWknzDjnNj_jcYfY2UkOKG2eopxEwdaO3qu4Yr0CyyShFZ5-E2-YLtG1nOzvQxravaGKT4PjiBYqbeU1QzpyEDs-AGzwxGTmkLycI38jsTcYFSw3iOmlp0bgpni5WvuLFW2_sXOY-S1jX16txAEECpj2qGDraRBLZy5p3wh6HTvZ-Iwy6XXImGbMe2DOUfUruzYfihDhhPBi6DjhDntBOBAThtAnLOXDjPTbMWqyiGA_aKsM6BzHXDEE5BgVBSNjAqUOxVpxpX2y7Fg7ySmcnuORkT7mlfj9C2m_bm1lggso_f8UrUqPqgo-xe2jdH&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep