Re: [Teep] Security domain default 1-to-1 mapping to a TA proposal in TEEP

"Wheeler, David M" <david.m.wheeler@intel.com> Fri, 08 March 2019 14:49 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 B1B351279A9 for <teep@ietfa.amsl.com>; Fri, 8 Mar 2019 06:49:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 e10x1yqcdTLP for <teep@ietfa.amsl.com>; Fri, 8 Mar 2019 06:49:07 -0800 (PST)
Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (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 4591912423B for <teep@ietf.org>; Fri, 8 Mar 2019 06:49:07 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2019 06:49:06 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.58,456,1544515200"; d="scan'208,217";a="280951801"
Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga004.jf.intel.com with ESMTP; 08 Mar 2019 06:49:06 -0800
Received: from fmsmsx157.amr.corp.intel.com (10.18.116.73) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 8 Mar 2019 06:49:05 -0800
Received: from crsmsx104.amr.corp.intel.com (172.18.63.32) by FMSMSX157.amr.corp.intel.com (10.18.116.73) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 8 Mar 2019 06:49:05 -0800
Received: from crsmsx102.amr.corp.intel.com ([169.254.2.44]) by CRSMSX104.amr.corp.intel.com ([169.254.6.29]) with mapi id 14.03.0415.000; Fri, 8 Mar 2019 08:49:04 -0600
From: "Wheeler, David M" <david.m.wheeler@intel.com>
To: Andrew Atyeo <Andrew.Atyeo@intercede.com>, Mingliang Pei <Mingliang_Pei@symantec.com>
CC: "teep@ietf.org" <teep@ietf.org>
Thread-Topic: Security domain default 1-to-1 mapping to a TA proposal in TEEP
Thread-Index: AQHU1VKRZgbX2HkEAk2k301Fswqim6YBZXtwgABrq5A=
Date: Fri, 08 Mar 2019 14:49:03 +0000
Message-ID: <0627F5240443D2498FAA65332EE46C843B70D1A9@CRSMSX102.amr.corp.intel.com>
References: <F78A61D4-9B6B-4E83-8CF7-0C49E08718A9@symantec.com> <DB7PR10MB23489BA35BD7CDF8406DC6A9954D0@DB7PR10MB2348.EURPRD10.PROD.OUTLOOK.COM>
In-Reply-To: <DB7PR10MB23489BA35BD7CDF8406DC6A9954D0@DB7PR10MB2348.EURPRD10.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTU0MDZlOTktMDNiMi00N2EyLTgxODctNDUyZGQ4MDQ0NzQyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiYVl0ejFKdHgydCtEemVsU1lUVlQzd2lGbk5tem1hTFNzRkFlNjFpRms1eGdENk1hU2x6cUxpMERnekw3STloQiJ9
x-ctpclassification: CTP_NT
dlp-product: dlpe-windows
dlp-version: 11.0.400.15
dlp-reaction: no-action
x-originating-ip: [172.18.205.10]
Content-Type: multipart/alternative; boundary="_000_0627F5240443D2498FAA65332EE46C843B70D1A9CRSMSX102amrcor_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/X75EAPL6jdo95tItmXVWZ7VpzuI>
Subject: Re: [Teep] Security domain default 1-to-1 mapping to a TA proposal in TEEP
X-BeenThere: teep@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 08 Mar 2019 14:49:11 -0000

Andrew,
Thanks for your response. I have updated the comments on github with further questions.

Dave Wheeler

From: TEEP <teep-bounces@ietf.org> On Behalf Of Andrew Atyeo
Sent: Friday, March 8, 2019 2:43 AM
To: Mingliang Pei <Mingliang_Pei@symantec.com>
Cc: teep@ietf.org
Subject: Re: [Teep] Security domain default 1-to-1 mapping to a TA proposal in TEEP

Hi,
I have updated the github issue with my comments
https://github.com/ietf-teep/architecture/issues/7

basically I understand that there are some deployment types that might prefer a simpler approach, but I want to make sure that we know what would be ‘lost’ by not having a SD that is created separately. It might be that for some deployments the loss is no problem, or it might be that there could be alternative ways to give the same functionality but without need for a separate createSD that are worth exploring.
The github issue (link above) hopefully explains this better.

Regards,

Andrew Atyeo
Security Architect
Intercede
Digital trust    people ǀ devices ǀ apps
Office: +44 (0) 1455 558 111
www.intercede.com<https://www.intercede.com/>
Legal Disclaimer <https://www.intercede.com/privacy-cookies>
From: Mingliang Pei <Mingliang_Pei@symantec.com<mailto:Mingliang_Pei@symantec.com>>
Sent: 08 March 2019 02:00
To: Andrew Atyeo <Andrew.Atyeo@intercede.com<mailto:Andrew.Atyeo@intercede.com>>
Cc: teep@ietf.org<mailto:teep@ietf.org>
Subject: Security domain default 1-to-1 mapping to a TA proposal in TEEP

Hi Andy,

We are working on to close this issue #7: clarifying meaning of Security Domain (SD)

https://github.com/ietf-teep/architecture/issues/7

We want to simplify it, and propose to create a SD per TA by default, without completely removing the SD for some existing use cases. It will be good to also have your input on the implications, considering you have more involved in this with a prior OTrP TAM POC implementation. Could you review the issue, and provide comments there?

Here is a quick recap on some discussion reasonings.

Historically we consider Security Domain as a first class entity in TEEP (OTrP). There have been some desires to simplify it, or not require it in the TEEP architecture as some use cases don’t use it as much as potential IoT use cases. On the other hand, we know that existing TEE implementations and other secure element related practices uses SD to isolate and associate protection boundary. There was some resource constraints on number of SDs that can be allocated in a TEE device.

To achieve broad support of both worlds, we consider to move to an “implicit” model as follows:


  *   One SD is created per TA when a TA is going to installed. This allows creation of TA without going through explicit SD creation and so on.
  *   The prior deletion of SD will delete all TAs within the same SD. Now each TA will be required to be explicitly deleted.

Thanks,

Ming