Re: [Teep] Charter Text

Lubna Dajani <lubnadajani@gmail.com> Tue, 12 September 2017 11:40 UTC

Return-Path: <lubnadajani@gmail.com>
X-Original-To: teep@ietfa.amsl.com
Delivered-To: teep@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236C5133030 for <teep@ietfa.amsl.com>; Tue, 12 Sep 2017 04:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.018
X-Spam-Level:
X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuBuyZhZ5MAn for <teep@ietfa.amsl.com>; Tue, 12 Sep 2017 04:40:48 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827E11333E0 for <teep@ietf.org>; Tue, 12 Sep 2017 04:40:48 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id m35so24857026qte.1 for <teep@ietf.org>; Tue, 12 Sep 2017 04:40:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:message-id:date:in-reply-to:references :mime-version; bh=qjJS3UNSALDJBzkASHtG+76o+CzUz/zo/l40C9X//fc=; b=XZcUU0V3F+th3mZBSTdKvK/cAGDLt90NwwBynBA2AHAk+0CgHOX0rn4x5UC9LoVOSu uTyr5Ey6nPps5ZOia0UXuSgo70BUlXiyDy47dt5NKM+h6lESoIrcvPCZP8LjYDrQrzkf fE0pPWjPyt00LkKhdMQo65QPBtwp8JuaiFR6PM5DFWiTZYWJUPdcy1blhhXk7MX9xw+T bE5UZseevZjCHSNlE1x1kp6kMQavUjyUzLTd7HZgKhm7IIpRTyTX2B95iFBQmJ6SC9H9 H4EVwf6muvIQ4g5pntNEFGNpIYwT20dL7+VeXedG7LtiAemIEQ8iYhMSeiFpH/8R9jbi aZVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:message-id:date:in-reply-to :references:mime-version; bh=qjJS3UNSALDJBzkASHtG+76o+CzUz/zo/l40C9X//fc=; b=lw2sN/BVxYuiYyFfLLoqaQW5Dh8NkSOHYF8i+ThYEvYPZPRJ8twx+azrvCbfOLEqCX FqVVj/kd6g5VAAiDhaAgn09dFIe7+s5kImHqwfG5BlYuw+YMs5UrI+yhlvexz/vLv7R7 nUDh6jkJa7slHZjMN0FEqGcQEkMZiqxfGFloCyoFKFAVwSguOPoQ19K+AnftXMvLxYrY eUjKVky7RMGlPQX36DlJaONuLDFK/Gj2TgUh2UgoGsn9jPzdNzWr1Qrj6g1rXt/oLJoi 1A51+SswZ60sSe0WS3f0YZWJ6er8Z9E5OklhSpjdpUWOOAdaGWu3mbcpKVltjyQA4z1X No5Q==
X-Gm-Message-State: AHPjjUgx969hYLNXsdOQYX98+14u5IKZ18DlpL++YSGZfqUAghGTh+3T qWovr7CUTEvgwA==
X-Google-Smtp-Source: AOwi7QDYBvsT9wILMQjLi093a/+4UYMo9v/XTdyYBXTzXJxBX+nYErsmvjriexevJUPCparLviV9wg==
X-Received: by 10.200.26.176 with SMTP id x45mr22484443qtj.181.1505216447492; Tue, 12 Sep 2017 04:40:47 -0700 (PDT)
Received: from [127.0.0.1] (send-12.prod.mixmax-mailer.com. [52.200.39.124]) by smtp.gmail.com with ESMTPSA id a13sm7625665qkj.35.2017.09.12.04.40.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Sep 2017 04:40:46 -0700 (PDT)
Content-Type: multipart/alternative; boundary="----sinikael-?=_1-15052164461380.6101050749881511"
From: Lubna Dajani <lubnadajani@gmail.com>
To: Petr Peterka <ppeterka@verimatrix.com>
Cc: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, teep@ietf.org
Message-Id: <d6015c71-04de-3323-bb08-5ac66a5c21d0@mixmax.com>
Date: Tue, 12 Sep 2017 11:40:45 +0000
In-Reply-To: <DM5PR20MB1228DEC9757FCBDCA4254052AAA70@DM5PR20MB1228.namprd20.prod.outlook.com>
References: <6EFD27BC-CE56-4112-AD20-C787520BEE87@cisco.com> <DM5PR20MB1228DEC9757FCBDCA4254052AAA70@DM5PR20MB1228.namprd20.prod.outlook.com>
X-Mixmax-Message-Id: M0MGFELaXs0YfTml3
X-Mailer: Mixmax (mixmax.com)
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/ZwlpRwkOZ2Ihyk7-kS8a0DXkTfk>
Subject: Re: [Teep] Charter Text
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement <teep.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teep>, <mailto:teep-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teep/>
List-Post: <mailto:teep@ietf.org>
List-Help: <mailto:teep-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teep>, <mailto:teep-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Sep 2017 11:40:51 -0000

please allow me to echo Petr's responses.1. Yes2. Yes3. Yes4. Yes I am
personally very excited to see this WG form and I look forward to actively
contributing to the evolution of this protocol as I have since the ideation
stages of this protocol …
Thank you Nancy, Petr and everyone here…
Lubna__________________________________________________Lubna Dajani  I
 Allternet Ltd.@lubnadajani

@futuristasORG

+ 1 201 982 0934





Confidentiality Notice:The information contained in this email and any
attachments is intended only for the recipient[s] listed above and may be
privileged and confidential. Any dissemination, copying, or use of or reliance
upon such information by or to anyone other than the recipient[s] listed above
is prohibited. If you have received this message in error, please notify the
sender immediately at the email address above and destroy any and all copies of
this message.

Sent with Mixmax  





On Thu, Jul 20, 2017 2:48 AM, Petr Peterka ppeterka@verimatrix.com  wrote:
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:teep-bounces@ietf.org] On Behalf Of Nancy Cam-Winget
(ncamwing)
Sent:  Thursday, July 20, 2017 11:13 AM
To:  teep@ietf.org
Subject:  Re: [Teep] Charter Text



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 <teep-bounces@ietf.org> on behalf of Hannes Tschofenig <
Hannes.Tschofenig@arm.com>
Date: Wednesday, July 19, 2017 at 5:56 AM
To: "teep@ietf.org" <teep@ietf.org>
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.