Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Tue, 07 January 2020 09:28 UTC

Return-Path: <Hannes.Tschofenig@arm.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 9FD8912006E for <teep@ietfa.amsl.com>; Tue, 7 Jan 2020 01:28:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=fziXMPUf; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=xdnC+Lh9
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 FzJomtDU7nH2 for <teep@ietfa.amsl.com>; Tue, 7 Jan 2020 01:28:19 -0800 (PST)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2075.outbound.protection.outlook.com [40.107.20.75]) (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 C1726120019 for <teep@ietf.org>; Tue, 7 Jan 2020 01:28:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SDvwuLNGcsFblQkEMnUXJzeApxhqyBnjctXoN1vwS7Q=; b=fziXMPUf5bjBK4yfsCUNNdrgT8rF5OfNczYc3OARayAgQRuA3EPqKDHReKGS6hgWg507buaPjXCqgDD5XEXATnay89CgIq9oMsga5qOehdkOJy3Su0P2lVFKSO8MEXZktjJe74VkkWpSMSSt4Rz2m0nSd6xQJ7YD5/xc1eF8ujI=
Received: from VI1PR08CA0144.eurprd08.prod.outlook.com (2603:10a6:800:d5::22) by AM6PR08MB3607.eurprd08.prod.outlook.com (2603:10a6:20b:4c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.15; Tue, 7 Jan 2020 09:28:14 +0000
Received: from AM5EUR03FT060.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::205) by VI1PR08CA0144.outlook.office365.com (2603:10a6:800:d5::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.10 via Frontend Transport; Tue, 7 Jan 2020 09:28:14 +0000
Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT060.mail.protection.outlook.com (10.152.16.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Tue, 7 Jan 2020 09:28:14 +0000
Received: ("Tessian outbound 28955e0c1ca8:v40"); Tue, 07 Jan 2020 09:28:13 +0000
X-CR-MTA-TID: 64aa7808
Received: from a77fa2eb52eb.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id FE0D492E-9FD1-4F52-B08E-48FA19AC5C7A.1; Tue, 07 Jan 2020 09:28:08 +0000
Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a77fa2eb52eb.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 07 Jan 2020 09:28:08 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hAxI8S/df2j7QieamncMV8HOokxeqhLhbF0nGbHZpiNjiqVpt+EGFWaq+R83CH8rlsPGtPA6KB6XU7dALtJ2thHWmxoG8xhnFmonD0ag93yMD96v3VTBCLgaDdFrjf3EHZnA3nHfzmOQGLSb8Xw4TEOoqbtDHwfWI+A8dAW9woewifKx/qGY/EnqfO5J6VPnsB9yr88AfxmddimiX//f1zqdG6nQt7ynn48zG0t6YKkMAFI4VprkoL3XUvvKLV9jxXvR2mHHcbK2PIsfOY9KBixEDonbzxujpgyH3+y6/cXI/XUnHMN0MB0FlNe5mwctbktFx4zGHe48mHl41zuN8g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YfAGUb5R7d0u9keUWVo0xLu009hWW5aL78ssslUODaw=; b=C1CQO9tSGq2LKkrx/F4DKM6S8v+iKLdvKTKzR6Ru8/BvPkUPIJGjGDbacLeuutLZrnUsw77DaQQzzqiRrtKNBMsKkCBaVHILqq+RjBZ2td2/zObZ5YLAECL5gTkVdyRZs4IRY2ptV9/jd2reiL3JczUe2FeSHasU/6pZ5IRA0lZ7NdRxlxCunMrOPrnfUBvJSQv1WA56X/XN38plEFrfvtJaQnWQ6Xm8Aop8dcWgi4nAwV6egnJoE6LxiX4Vdej3mFVDsBFveRq1sQv80IRMA8CtJHqGeLpWH78jj8ENuOwo6vE6/rGNmQpU4bNeEotozM9QAMQNqv7W6AIyr5iETA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YfAGUb5R7d0u9keUWVo0xLu009hWW5aL78ssslUODaw=; b=xdnC+Lh97FZ0otf7mjfCjPMbfBmLO/Rj4jyd7leWu5/9RqzT7dd9wHxoXAkAdXyRFumAx3vPoImlye3TWov0KERD0OL95ENlN1gmO4cEUxTdY16s+tRf4q5/qE6KDYbF2Pslg1yHyHeYcCIZ81kmr8zBmznLnwfxx7MYAbjy3O0=
Received: from AM6PR08MB5285.eurprd08.prod.outlook.com (20.179.0.161) by AM6PR08MB5190.eurprd08.prod.outlook.com (10.255.121.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Tue, 7 Jan 2020 09:28:07 +0000
Received: from AM6PR08MB5285.eurprd08.prod.outlook.com ([fe80::1581:c3da:22ee:41b9]) by AM6PR08MB5285.eurprd08.prod.outlook.com ([fe80::1581:c3da:22ee:41b9%7]) with mapi id 15.20.2602.016; Tue, 7 Jan 2020 09:28:07 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, Dave Thaler <dthaler@microsoft.com>, "teep@ietf.org" <teep@ietf.org>
Thread-Topic: Working Group Last Call for draft-ietf-teep-architecture
Thread-Index: AdW5iepOELmpRRFXSAWsc0EhHQP19ALfbySAAAc0BIAABIf9gA==
Date: Tue, 07 Jan 2020 09:28:07 +0000
Message-ID: <AM6PR08MB5285F0C0209A745F1FAABA23FA3F0@AM6PR08MB5285.eurprd08.prod.outlook.com>
References: <CY4PR1601MB1254CD83B0DAADAA67A54CF3EA2E0@CY4PR1601MB1254.namprd16.prod.outlook.com> <BL0PR2101MB10278417515DEF077714D693A33F0@BL0PR2101MB1027.namprd21.prod.outlook.com> <CY4PR1601MB125400678B0DA9EE37683FBBEA3F0@CY4PR1601MB1254.namprd16.prod.outlook.com>
In-Reply-To: <CY4PR1601MB125400678B0DA9EE37683FBBEA3F0@CY4PR1601MB1254.namprd16.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-07T03:14:02.9467153Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=113fc599-cef6-4df9-bb00-5e0a626ea5d7; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
x-ts-tracking-id: f82990ee-e9c5-4072-ba90-dd8c85adf679.0
x-checkrecipientchecked: true
Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [195.149.223.43]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 112fe00f-cbe7-4fe2-abfc-08d79353ebad
X-MS-TrafficTypeDiagnostic: AM6PR08MB5190:|AM6PR08MB3607:
X-Microsoft-Antispam-PRVS: <AM6PR08MB360717DA41BD7150037B187BFA3F0@AM6PR08MB3607.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508;
x-forefront-prvs: 027578BB13
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(39860400002)(396003)(376002)(366004)(51914003)(53754006)(189003)(199004)(55016002)(52536014)(71200400001)(9686003)(81156014)(81166006)(8676002)(8936002)(478600001)(21615005)(45080400002)(966005)(76116006)(6506007)(26005)(53546011)(7696005)(64756008)(66946007)(66446008)(33656002)(66476007)(66556008)(110136005)(2906002)(9326002)(30864003)(86362001)(5660300002)(186003)(316002)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB5190; H:AM6PR08MB5285.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: WT+w9WhKbtCPnsIPYTPPUKyuavS0WgWJ6tiFw2ueB5Zv6B5vpOaxxJw+BPLOjvQ2PNcAowSwzs6ptTVrz4WIoXofFBuVT3FUx8YKHXXiq4nU0mx2AKi/lAqOzb6F/x/SOxsEPtZL1B5kjEjhBaWMTY2+Vrh3mbgPoyeRc76IkrWrhs4vlYBu+M5F+pVghMxd9aovmt/ppfENQeLqeqOjBRcCxRQ1kQFrmpxyP4yn6v3d+vIBcKODByiqYekc4brZuwbifap4nCLJHcIYlZMTBGhqHER8JZSMXpug73Za6xGzJetk9x5CYaNdcPsvb7nyjImNxhurbG3Nie6eMlKHw7ELU2TVi/10yokryQRPbIcBtG7qVIMRDJHzbKsMs+GRVZysy6S0YnKGGPFkLzO5WNBEXn1tak3Yow5hfPWBSxVckajXrqHd4w3/1E6dZ7MZ+XBp19PMEBTPFP6LPPLXjS23OlM8PHpsaP5j/xk1U7jCijojuR84duYEVf0147QPwl+t7Jrw41q76/HU3DHk5BMFwSK3MQYUofSvG2mrSsb9mbGZDPiWGn3AnQtjZQiTInNur9TuBr2OfXi6b+/JLA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM6PR08MB5285F0C0209A745F1FAABA23FA3F0AM6PR08MB5285eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5190
Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT060.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(376002)(346002)(136003)(51914003)(53754006)(199004)(189003)(40434004)(8676002)(356004)(26826003)(8936002)(186003)(336012)(478600001)(45080400002)(26005)(9326002)(966005)(81166006)(81156014)(70586007)(9686003)(21615005)(86362001)(70206006)(36906005)(110136005)(5660300002)(53546011)(7696005)(55016002)(52536014)(2906002)(33656002)(30864003)(66574012)(6506007)(316002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3607; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1;
X-MS-Office365-Filtering-Correlation-Id-Prvs: a64b7d00-9ffe-435d-0c7f-08d79353e7aa
X-Forefront-PRVS: 027578BB13
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: x6R83FS4I/SWb1gHU8TcFFLeL/U2407spAKuuuOTep5L2DroY8VuVMec2YCnC1XwXIVvY8ORKGFQ1ccaSjYROy3FZu2nmKN5EgK8Tbww12OkXzN//0yzdqmPpQlUmtNAgyU63hHgTab4v0ewDwvbg9rVs3ib7+JMN0hpgHo0xeRh3O9y9X88TnG0dn2Mq61foD5XZFVkWgwqlbCnHtEpuTmyx6dlcdpZzFXM0ntMagoAwgpP9gqorTBqsc+09a/xZqGyNyFBBEZFvQFMoHjhosjRztv8vmeGQyiT1cjyMeL/uGB29Hj6ptzuL0UOd3FYdf8KshCUC7c9QjPeFRWUB0GvzsrYoF36eInvLeiwy8ujBbs0uRCDZHDj22Or+H8YEw6arfPcrIQ555hNcMNCANaQVWIZXn1DQGIuU8wfgiwCj/wXl1bThY8+bB4IYWzdtU8LBO4I++4NdWC+QoC4xNeZmkdQS9WDdx1OYIRUo6ZG0cuFYN/xxI8uOrnkv4MWNKtfWtfYrsZUqv0vAf5zIpA7NeDVMuopXwsqPDVYiNfkdkAQsHBgsDsiuF/g8U3tJqn97HZ19zTfh8PxTA2Eqa5Z9dJYUgLIpYobVSottUQ=
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2020 09:28:14.1020 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 112fe00f-cbe7-4fe2-abfc-08d79353ebad
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3607
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/6fsVE-OYwmp0oQpZQB5tTKVbLL0>
Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture
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: Tue, 07 Jan 2020 09:28:26 -0000

Hi Tiru,

Thanks for the review. There is clearly room for improving the write-up.

A few remarks below.

From: TEEP <teep-bounces@ietf.org> On Behalf Of Konda, Tirumaleswar Reddy
Sent: Tuesday, January 7, 2020 7:39 AM
To: Dave Thaler <dthaler@microsoft.com>; teep@ietf.org
Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture


[As an individual]

Hi Dave,



I have reviewed the draft and have comments and nits listed below:



a) It is not clear from the Introduction how TEE is different from a Closed OS like Google Chromebook or Windows 10S ?

     The benefit of Payment application running in Closed OS verses in TEE is not evident from the description. What part of the Payment application runs in the REE and TEE respectively ?

     If biometric identification information is securely stored in TEE for identification, how does the TEE identify the biometric identification information is not retrieved by an malicious agent in the REE.

     Section 3.3 (Internet of things), How does the architecture ensure the sensitive data is retrieved by a legitimate application in the REE and not by an malicious application ?



[Hannes] The TEE adds another layer of software isolation. To protect one TA to steal data from another TA the two TAs need to be isolated against each other. Depending on the TEE technology you are using this is accomplished via different means.



It is up to the application developer to decide how they best want to separate the REE and the TEE part, which in part depends a bit on what type of payment protocol they are using. In some other cases (probably more realistic) they may be using an already existing payment system, which is provided as a TA, and they are just using it. In general, it does not strike me as a great idea to have random smart phone app developers writing their own payment software.



b) Why should the list of trust anchors on the device be managed by the Device's network carrier ?

     (you may want to define the term "network carrier").



[Hannes] The text says the following:



"
The list of Trust Anchors is normally modifiable
      by the Device's owner or Device Administrator.  However the Device
      manufacturer and network carrier may restrict some modifications,
      for example, by not allowing the manufacturer or carrier's Trust
      Anchor to be removed or disabled.

"



This describes current practice in the mobile phone industry and may not necessarily be applicable to other deployment scenarios. Hence, there is no required behavior here.





c) If the REE is compromised (for example by malware), it could terminate the TEEP broker in REE. How is this attack mitigated ?



[Hannes] If the REE is compromised then that's typically not a good thing but the REE side still cannot access anything on the secure world, if implemented correctly. It could, however, indeed terminate the TEEP broker and avoid any calls to the secure world. This would be a DoS attack. It would be possible to periodically schedule an interrupt that is processed by the secure world to let the secure world double-check the state of the normal world.



d) What happens if the malicious agent acting as TEEP broker launches attacks (e.g. garbage data, replay attack, DoS of messages etc.,) on the TEEP agent, and how will the TEEP agent defend itself ?



[Hannes] The TEEP agent dispatches calls to the trusted applications. It is typically a shim layer that just checks parameters of the requests and then relays them to the TAs. Having a rock solid implementation of the TEEP agent is important and of course the TAs need to be implemented properly as well.



The GP TEE Client API is meant to provide a reference design for an API that allows data passing back and forth. So, implementing that API properly will be important. This is why there is this open source project to implement that API so that other developers can just use it.





e) The below line is not clear to me:

Enumeration and access to the appropriate TEEP Broker is up to the Rich Execution Environment and the Untrusted Applications..



[Hannes] There may be multiple TEEP Brokers on the system and the interaction between untrusted apps and the TEEP broker is up to a policy implemented by the developer.



h) A use case explaining the use of multiple TAM, multiple TEEP brokers on a device, and multiple TEE would be useful to the reader of the specification.



[Hannes] Definitely a good idea to add text with use cases.

Here is my quick response:



  *   Multiple TAMs: you could think about this as having multiple code repositories. Different SPs may prefer to use certain TAMs for their software distribution.
  *   Multiple TEEP brokers: this can occur when you have a broker offered by the OS and one bundled with the untrusted app.
  *   Multiple TEEs: This depends on the TEE technology. In the TrustZone case you may have a multi-processor system and each processor comes with TrustZone support.



i) When a TEEP Broker receives a request from an Untrusted Application

   to install a TA, a list of TAM URIs may be provided for that TA, and

   the request is passed to the TEEP Agent.  If the TEEP Agent decides

   that the TA needs to be installed, the TEEP Agent selects a single

   TAM URI that is consistent with the list of trusted TAMs provisioned

   on the device invokes the HTTP transport for TEEP to connect to the

   TAM URI and begins a TEEP protocol exchange.



Comment> I am not sure why the architecture draft is discussing the protocol aspects like HTTP for TEEP ?



[Hannes] I believe it does not need to mention HTTP but it could list it as an example.



j) What if the malware in REE instructs the TEEP agent via TEEP broker to keep installing/uninstalling TA (over-whelm the TEEP agent and TEE or installing un-necessary TA to have no memory for the required TA) ?



[Hannes] Having a compromised REE environment that causes all sorts of apps to be installed is possible (assuming the TEE is authorizing the installation of those apps). An implementation of the secure world, most likely the TEE OS, will have to make sure that the device does not install TAs and overwrite the memory space they have been configured to use.



i) What is the use case for "Personalization data" ?



[Hannes] Personalization data is meant to make each instance of the TA unique and potentially tie it to a specific user. Imagine a TA that implements biometric functionality: there has to be something in TA that relates this instance of the TA to a specific human, for example by storing a fingerprint alongside the TA as configuration data.



j) Why is Section 4.5 discussing Case 1 when it not in use ?



[Hannes] We just describe the possible approach and illustrates how things are done today. There is, however, a lot of development going on in the area of TEEs and I suspect that we will see all sorts of different use cases showing up in the future as the technology gets used in different environments.





k) The below line is not clear to me (please elaborate):

Consequently, a TAM generally communicates with an Untrusted Application about how it gets messages that originate from a TEE inside a device.



[Hannes] The key point of that paragraph is that today TEEs do not communicate with the outside world but require the cooperation with something on the REE side.



l) What is the use case for one TA and multiple SP ?



[Hannes] I am not sure. I let Ming, DaveW, or DaveT respond.



m) what is the use case for keeping the TA binary secret from the TAM ?



[Hannes] it is more and more common today to protect binaries from inspection because this gives attackers a lot of information. If you don't want to use it and only sign the binaries that's fine too. But the option is there for you to protect the confidentiality of the binary.



n) We allow a way for an Untrusted Application to check the trustworthiness of a TA.



Comment> You may want to re-phrase the above line, and remove "we".



[Hannes] I think we should delete this paragraph:

"

   We allow a way for an Untrusted Application to check the

   trustworthiness of a TA.  A TEEP Broker has a function to allow an

   application to query the information about a TA.

"





o) A notification that an incoming TEEP session is being requested by a TEEP Agent.



Comment> What you meant by "incoming TEEP session" ?



[Hannes] Dave should respond to this one because it relates to the HTTP transport, I believe.



p) How does the TEEP broker communicate with the TEEP agent ?



[Hannes] Via an API, for example the GP TEEP Client API.



q) Section 5.3 says the architecture uses PKI but Section 9.1 discusses self-signed certificates. Please fix.



[Hannes] We need to clarify the statement about the self-signed TA binaries.



r) In Figure 4, for the purpose of "Code signing" my understanding is the location of corresponding CA certs is both TEE and TAM.



[Hannes] I believe it would be useful to also store the CA cert that is used for code signing at the TAM because then it can verify the signed TAs.

If we indeed believe the text in Section 9.1 is correct then that code signing CA cert also needs to be made available to the TEEP Broker and potentially even to the untrusted app.



s)I have seen several malicious apps in App store in both Android and iOS, it is possible for an malicious App developer to publish both malicious untrusted applications

   and malicious trusted applications.  I don't think the TEEP architecture prevents this attack and it is the responsibility of TAM and App store to remove such apps

    (see https://android-developers.googleblog.com/2018/01/how-we-fought-bad-apps-and-malicious.html)



[Hannes] Yes, it would be the responsibility of the TAM, the device manufacturer and the SP / developer to ensure that they do not distribute malicious TAs.



Ciao

Hannes



Cheers,

-Tiru


From: Dave Thaler <dthaler@microsoft.com<mailto:dthaler@microsoft.com>>
Sent: Tuesday, January 7, 2020 8:44 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com<mailto:TirumaleswarReddy_Konda@McAfee.com>>; teep@ietf.org<mailto:teep@ietf.org>
Subject: RE: Working Group Last Call for draft-ietf-teep-architecture


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
I opened one pull request for editorial issues (https://github.com/ietf-teep/architecture/pull/109),
and filed seven other issues listed at https://github..com/ietf-teep/architecture/issues<https://github.com/ietf-teep/architecture/issues>

110) Service Provider discussion is confusing<https://github.com/ietf-teep/architecture/issues/110>
111) Terminology section is not consistently ordered<https://github.com/ietf-teep/architecture/issues/111>
112) Text about carriers is confusing<https://github.com/ietf-teep/architecture/issues/112>
113) Section 6.2.3 contradicts section 4.2<https://github.com/ietf-teep/architecture/issues/113>
114) Figure 3 is too hard to understand<https://github.com/ietf-teep/architecture/issues/114>
115) Reference to IANA number<https://github.com/ietf-teep/architecture/issues/115>
116) Incorrect/obsolete statements about TEEP Broker<https://github.com/ietf-teep/architecture/issues/116>

I have ideas about how to address all of them, but if others have comments, please speak up.

The possibly(?) contentious one might be that in #110 I am proposing to use the term
"App Developer" throughout, instead of using "Service Provider" in some places and "App Developer" in others
and then saying they're synonymous like it does now.   (I'd be ok with mentioning that in some contexts an App Developer
might be known as a "Service Provider" if that is important to GlobalPlatform folks.)

Dave

From: TEEP <teep-bounces@ietf.org<mailto:teep-bounces@ietf.org>> On Behalf Of Konda, Tirumaleswar Reddy
Sent: Monday, December 23, 2019 4:17 AM
To: teep@ietf.org<mailto:teep@ietf.org>
Subject: [Teep] Working Group Last Call for draft-ietf-teep-architecture

Hi all,

This message starts a Work Group Last Call (WGLC) for TEEP architecture.  The version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-architecture-05<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teep-architecture-05&data=02%7C01%7Cdthaler%40microsoft.com%7C88bfc467b880468e461e08d787a2196d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637127002642640827&sdata=aallqAzJH3MqV2bbzMzwvD3OXhpRFyPJVHeaWye4x40%3D&reserved=0>

The WGLC will last for 4 weeks and will end on 20 January 2020.

Please send your comments to the list before this date and your assessment of whether or not it is ready to proceed to publication.

Regards,
Tiru & Nancy
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.