Re: [Teep] Charter strawman proposal

"Wheeler, David M" <david.m.wheeler@intel.com> Tue, 28 March 2017 19:18 UTC

Return-Path: <david.m.wheeler@intel.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 E689F129648 for <teep@ietfa.amsl.com>; Tue, 28 Mar 2017 12:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.812
X-Spam-Level:
X-Spam-Status: No, score=-6.812 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=intel.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 nDZU3Mx846eS for <teep@ietfa.amsl.com>; Tue, 28 Mar 2017 12:18:11 -0700 (PDT)
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEBC6129A0B for <teep@ietf.org>; Tue, 28 Mar 2017 12:18:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intel.com; i=@intel.com; q=dns/txt; s=intel; t=1490728691; x=1522264691; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mn4eQdVVpgGCEvktneuxXYl+2FSLWD5Wsl1hz0FWyWo=; b=NNO1kxoqst1xA3ggk8hEPFWuLxOFrfKgdi61W3vS+eYcSSoOhRkB7AsL GJalRBsTlqZNq5jyWyt2QYX6eiwsjQ==;
Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 12:18:08 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.36,237,1486454400"; d="scan'208";a="80314247"
Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga005.jf.intel.com with ESMTP; 28 Mar 2017 12:18:08 -0700
Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 28 Mar 2017 12:18:08 -0700
Received: from crsmsx104.amr.corp.intel.com (172.18.63.32) by FMSMSX112.amr.corp.intel.com (10.18.116.6) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 28 Mar 2017 12:18:08 -0700
Received: from crsmsx102.amr.corp.intel.com ([169.254.2.201]) by CRSMSX104.amr.corp.intel.com ([172.18.63.32]) with mapi id 14.03.0319.002; Tue, 28 Mar 2017 13:18:06 -0600
From: "Wheeler, David M" <david.m.wheeler@intel.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "teep@ietf.org" <teep@ietf.org>
Thread-Topic: Charter strawman proposal
Thread-Index: AdKn8psj9vu4dTTCT0CCPMegyCEPAAAAyoaA
Date: Tue, 28 Mar 2017 19:18:06 +0000
Message-ID: <0627F5240443D2498FAA65332EE46C84366EA50D@CRSMSX102.amr.corp.intel.com>
References: <HE1PR0802MB2475D750A62DFFAB28F1768CFA320@HE1PR0802MB2475.eurprd08.prod.outlook.com>
In-Reply-To: <HE1PR0802MB2475D750A62DFFAB28F1768CFA320@HE1PR0802MB2475.eurprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmI0ZTZkMTItYTlmZS00OTEwLTk1OGUtZjEyNDBkYzg3OWZkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjIuMTEuMCIsIlRydXN0ZWRMYWJlbEhhc2giOiJFMDNIMWZoanZjcUpSdm5OWHhQamxGRmNiUndkbmZDK0xuWUVWanVObVFzPSJ9
x-ctpclassification: CTP_IC
x-originating-ip: [172.18.205.10]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/t4yWTb4F64TAVfkEul0Kz5VzkxA>
Subject: Re: [Teep] Charter strawman proposal
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, 28 Mar 2017 19:18:14 -0000

Hannes,
Thanks for drafting this. I look forward to great discussions around this topic. I have made some modifications below.

I have made the following types of modifications:
* a protocol is not required in every case, therefore, a protocol may be advantageous to the marketplace (but not a requirement)
	a standard protocol will ease portability, create a level playing field/access for different TEEs, and 
	increase adoption for more secure devices
* a relay application on the rich OS side is not required - what is required is some service access onto the network stack for communications
	It is possible for some TEEs to provide trusted stacks - a service access point must be accessible to protocol entities outside the device
* the server side architecture interacts with the application, but maintenance of the app is optional
* discovery of actual TEE capabilities is important as well

I think security domains is an area for discussion, so I leave that alone. But hope to have more discussions and a better understanding of the requirements around SDs in the future.

It might be useful to discuss other potential standards groups that we should be aligned with, especially in the IoT space.

Thanks,
Dave Wheeler

--------

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

The Trusted Execution Environment (TEE) is a secure area of the main processor. The TEE, as an isolated execution environment, 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. Implementations of the TEE concept have been developed by ARM, and Intel using the TrustZone and the SGX technology, respectively.

[It may be advantageous to build the marketplace to have a protocol that supports] programmatically install, update, and delete applications running in the TEE. [ This ] protocol runs between a [trusted 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. Since [ some tasks ( such as management tasks) ] are security sensitive where the server side requires information about the device capabilities (in form of attestation), the client-side demands server-side authentication, and privacy considerations have to be taken into account.

This working group aims to develop an application layer protocol providing TEEs with the following functionality,
 * discovery of TEE capabilities
 * management of trusted applications,
 * attestation, and
 * security domain management (which provides a logical space that contains the service provider's applications).

The solution approach must take a wide range of TEE 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 use of the best possible encoding format 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 to ensure proper use of existing TEE-relevant application layer interfaces and other abstractions used by GlobalPlatform-compliant TEE devices.

Milestones

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

Oct 2017     Submit "TEEP Protocol" document as WG item.

Nov 2017     Participation in the IETF #100 Hackathon to work on the TEEP Protocol.

Dec 2017     Submit "TEEP Architecture" to the IESG for publication as an Informational RFC.

Mar 2017     Organization of an interoperability event at IETF #101.

Apr 2017     Submit "TEEP Protocol" to the IESG for publication as a Proposed Standard.

[1] Wikipedia, 'Trusted execution environment', URL: https://en.wikipedia.org/wiki/Trusted_execution_environment (March 2017).
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
TEEP@ietf.org
https://www.ietf.org/mailman/listinfo/teep