Subject: Re: [Teep] Charter Text

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 20 Jul 2017 09:13:16 +0000

All,
Please provide feedback on the results of yesterday’s side meeting.  In particular, we’d like to get feedback on whether this the right scope and if we have captured it appropriately. If it is not, also please comment and if possible, provide suggestions for improvement.

We would like to continue discussion over email and get consensus around the 2nd week of September so that we can have a path forward.  In particular we would like to get answers for:

1) Do you understand what TEEP is trying to achieve?
2) Is this work that should be done in general?
3) Is this work that should be done in the IETF, or does it belong to somewhere else?
4) Should we form a WG with given charter to work on this?

Warm regards,
    Nancy & Tero (TEEP BoF Chairs)

From: TEEP <[email-masked]> on behalf of Hannes Tschofenig <[email-masked]>
Date: Wednesday, July 19, 2017 at 5:56 AM
To: "[email-masked]" <[email-masked]>
Subject: [Teep] Charter Text

Here is the charter text we came up in the side-meeting today.

------

TEEP -- A Protocol for Dynamic Trusted Execution Environment Enablement Charter

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.

Milestones

Dec 2017     Submit "TEEP Architecture" document as WG item.

Feb 2018     Submit "TEEP Protocol" document as WG item.

July 2018     Submit "TEEP Architecture" to the IESG for publication as an Informational RFC.

Feb 2019     Submit "TEEP Protocol" to the IESG for publication as a Proposed Standard.

Additional calendar items:

Nov 2017     IETF #100 Hackathon to work on TEEP protocol prototype implementations.

Mar 2018     1st interoperability event (at IETF #101).

Jul 2018       2nd interoperability event (at IETF #102).

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: Petr Peterka <[email-masked]>
Date: Thu, 20 Jul 2017 09:48:27 +0000

Hi Nancy
I think we had a very productive meeting yesterday. Here are my answers to your questions:

1) Do you understand what TEEP is trying to achieve?
ANSWER: Yes, I do. I’d like to add that the charter may re-emphasize that the proposed WG is not going to define the TEE or the TAM service themselves but just the protocol between them.

2) Is this work that should be done in general?
ANSWER: Yes, it should since there are going to be more and more trusted execution environments (lower case) especially with the proliferation of IoT devices which will need more security than what they have today.

3) Is this work that should be done in the IETF, or does it belong to somewhere else?
ANSWER: Since we are trying to define a protocol that is independent of the different TEE implementations, I believe that IETF is the right home for it.

4) Should we form a WG with given charter to work on this?
ANSWER: Yes, that is my recommendation.

Thanks
          Petr

From: TEEP [mailto:[email-masked]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Thursday, July 20, 2017 11:13 AM
To: [email-masked]
Subject: Re: [Teep] Charter Text

All,

Warm regards,

From: TEEP <[email-masked]<mailto:[email-masked]>> on behalf of Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 19, 2017 at 5:56 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Teep] Charter Text

------

Milestones

---

From: Kaarthik Sivakumar <[email-masked]>
Date: Thu, 20 Jul 2017 11:53:38 +0200

One question. I was at
the TEEP meeting yesterday and saw a (version of the) picture
that showed TEE and TAM on the same hardware. The picture was
later modified with a vertical bar between the TAM and TEE, but
are they still expected to be in the same hardware device? Is that picture available
somewhere?

I guess my answer to
your first question is "not completely".

-kaarthik-

On 20/07/17 11:13 AM, Nancy Cam-Winget
(ncamwing) wrote:

All,

Please provide feedback on the results of
yesterday’s side meeting.  In particular, we’d like to get
feedback on whether this the right scope and if we have
captured it appropriately. If it is not, also please comment
and if possible, provide suggestions for improvement.

We would like to continue discussion over
email and get consensus around the 2nd week of
September so that we can have a path forward.  In particular
we would like to get answers for:

1) Do you
understand what TEEP is trying to achieve?

2) Is this work
that should be done in general?

3) Is this work
that should be done in the IETF, or does it belong to
somewhere else?

4) Should we form
a WG with given charter to work on this?

Warm regards,

From: TEEP <[email-masked]> on
behalf of Hannes Tschofenig
<[email-masked]>

Here
is the charter text we came up in the side-meeting today.

------

TEEP
-- A Protocol for Dynamic Trusted Execution Environment
Enablement Charter

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.

Milestones

Dec
2017     Submit "TEEP Architecture" document as WG item.

Feb
2018     Submit "TEEP Protocol" document as WG item.

July
2018     Submit "TEEP Architecture" to the IESG for
publication as an Informational RFC.

Feb
2019     Submit "TEEP Protocol" to the IESG for publication
as a Proposed Standard.

Additional
calendar items:

Nov
2017     IETF #100 Hackathon to work on TEEP protocol
prototype implementations.

Mar
2018     1st interoperability event (at IETF #101).

Jul
2018       2nd interoperability event (at IETF #102).

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://www.ietf.org/mailman/listinfo/teep

---

From: Mingliang Pei <[email-masked]>
Date: Thu, 20 Jul 2017 10:30:39 +0000

Hi Kaarthik,

Thanks. I took your comment yesterday, and showed the architecture overview diagram that shows the device with TEE and remote TAM; I also recall multiple voice to say it as separate. It might get lost while the chat was fast. Let me try confirm and clarify here.

No, TEE is expected in device and TAM is expected to be remote. A TAM will generally manage many devices for one or more applications. The scope diagram intends to emphasize the TEE and TAM message exchange where the device icon is put below the TEE line. Thank you for pointing out the vague part of the picture. I took your comment and will revise the diagram to be explicit on this device and TAM host separation.

Does this help clarify the question 1? Thanks again,

Ming

Sent from iPhone

On Jul 20, 2017, at 11:54 AM, Kaarthik Sivakumar <[email-masked]<mailto:[email-masked]>> wrote:

One question. I was at the TEEP meeting yesterday and saw a (version of the) picture that showed TEE and TAM on the same hardware. The picture was later modified with a vertical bar between the TAM and TEE, but are they still expected to be in the same hardware device? Is that picture available somewhere?

I guess my answer to your first question is "not completely".

-kaarthik-

On 20/07/17 11:13 AM, Nancy Cam-Winget (ncamwing) wrote:
All,
Please provide feedback on the results of yesterday’s side meeting.  In particular, we’d like to get feedback on whether this the right scope and if we have captured it appropriately. If it is not, also please comment and if possible, provide suggestions for improvement.

Warm regards,

From: TEEP <[email-masked]><mailto:[email-masked]> on behalf of Hannes Tschofenig <[email-masked]><mailto:[email-masked]>
Date: Wednesday, July 19, 2017 at 5:56 AM
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [Teep] Charter Text

------

Milestones

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

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

---

From: Kaarthik Sivakumar <[email-masked]>
Date: Thu, 20 Jul 2017 13:05:18 +0200

Yes, it does. Thanks.

-kaarthik-

On 20/07/17 12:30 PM, Mingliang Pei
wrote:

Hi Kaarthik,

Thanks. I took your comment
yesterday, and showed the architecture overview diagram that
shows the device with TEE and remote TAM; I also recall multiple
voice to say it as separate. It might get lost while the chat
was fast. Let me try confirm and clarify here.

No, TEE is expected in device and TAM
is expected to be remote. A TAM will generally manage many
devices for one or more applications. The scope diagram intends
to emphasize the TEE and TAM message exchange where the device
icon is put below the TEE line. Thank you for pointing out the
vague part of the picture. I took your comment and will revise
the diagram to be explicit on this device and TAM host
separation.

Does this help clarify the question
1? Thanks again,

Ming

Sent from iPhone

On Jul 20, 2017, at 11:54 AM, Kaarthik Sivakumar <[email-masked]>
wrote:

One question. I
was at the TEEP meeting yesterday and saw a (version of
the) picture that showed TEE and TAM on the same hardware.
The picture was later modified with a vertical bar between
the TAM and TEE, but are they still expected to be in the
same hardware device? Is that picture available somewhere?

I guess my answer
to your first question is "not completely".

-kaarthik-

On 20/07/17 11:13 AM, Nancy
Cam-Winget (ncamwing) wrote:

All,

Please provide feedback on the
results of yesterday’s side meeting.  In particular,
we’d like to get feedback on whether this the right
scope and if we have captured it appropriately. If it is
not, also please comment and if possible, provide
suggestions for improvement.

We would like to continue discussion
over email and get consensus around the 2nd
week of September so that we can have a path forward.
In particular we would like to get answers for:

1) Do you

2) Is this
work that should be done in general?

3) Is this
work that should be done in the IETF, or does it
belong to somewhere else?

4) Should
we form a WG with given charter to work on this?

Warm regards,

Nancy & Tero (TEEP BoF
Chairs)

From:
TEEP
<[email-masked]>
on behalf of Hannes Tschofenig
<[email-masked]>

To: "[email-masked]"
<[email-masked]>

Here
is the charter text we came up in the side-meeting
today.

------

TEEP
-- A Protocol for Dynamic Trusted Execution
Environment Enablement Charter

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

This
working group aims to develop an application layer
protocol providing TEEs with the following
functionality,

*

*

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.

Milestones

Dec
2017     Submit "TEEP Architecture" document as WG
item.

Feb

July

Feb
2019     Submit "TEEP Protocol" to the IESG for
publication as a Proposed Standard.

Additional
calendar items:

Nov

Mar

Jul

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]