Re: [Teep] clarification questions on draft-ietf-teep-architecture-14
Hannes Tschofenig <Hannes.Tschofenig@arm.com> Tue, 23 March 2021 09:10 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 B385A3A241C for <teep@ietfa.amsl.com>; Tue, 23 Mar 2021 02:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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=Wq2mNlsj; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=Wq2mNlsj
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 o46_G8nGbmz0 for <teep@ietfa.amsl.com>; Tue, 23 Mar 2021 02:10:17 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2080.outbound.protection.outlook.com [40.107.20.80]) (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 17DD73A241B for <teep@ietf.org>; Tue, 23 Mar 2021 02:10:16 -0700 (PDT)
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=4kLSWYGO0zGNfPM4rvihHJIgTbvBz+Szl7avZyELitc=; b=Wq2mNlsjcUHne3fv339crbBMYQ/+6rPX1rJE9lrgb6fpMAcjLqHl34hM2fMfeD3UTih7S8nPA64DNCcLds2DSkbUkjzTk/Z+qPtbfrzS+IaMde4c3deHurOD9GBOSO3TdQ6t9NOS6hgPD2bVx/yKc+AOUCg++Rfo3tXp/HxjXAQ=
Received: from DBBPR09CA0047.eurprd09.prod.outlook.com (2603:10a6:10:d4::35) by VE1PR08MB5038.eurprd08.prod.outlook.com (2603:10a6:803:116::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Tue, 23 Mar 2021 09:10:08 +0000
Received: from DB5EUR03FT040.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:d4:cafe::7c) by DBBPR09CA0047.outlook.office365.com (2603:10a6:10:d4::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18 via Frontend Transport; Tue, 23 Mar 2021 09:10:08 +0000
X-MS-Exchange-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=pass 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 DB5EUR03FT040.mail.protection.outlook.com (10.152.20.243) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18 via Frontend Transport; Tue, 23 Mar 2021 09:10:08 +0000
Received: ("Tessian outbound 1b6dfb84c254:v89"); Tue, 23 Mar 2021 09:10:08 +0000
X-CR-MTA-TID: 64aa7808
Received: from c91de2aff041.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 0C91F804-3786-4019-BC5B-A4AB82F9BF18.1; Tue, 23 Mar 2021 09:10:02 +0000
Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c91de2aff041.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 23 Mar 2021 09:10:02 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ql2Kj0uzDljdrIwDFZm6JshxqvGK2y4dNzx53UCr82IRrLs6vZhACZGpz2NB5Zhs+k5X994FZjK6UCQEsc9hg9kW3zoon7080XeT9pwsrjxK/IyGtdw1tbldJ3Cq5YO70qOMw6xxLXJ74abFKmls/Tty4z/F2ybVojU93f4/FdTfZ3ZdX3XNJxWNbGffPF70cuZAmD/rQITJ5ynas/xG8PuMjcW2o6WhIjMWaNpP5lXlg5nrnJfo2LZMMbZLxOQuwnbi6S99bzDLD7GzwGU2CHP/dkHmlvnbutY9umztEcHle0w9esc8rmxRYxystuRW80fJFp8hObXJo7UXgj7XHQ==
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=4kLSWYGO0zGNfPM4rvihHJIgTbvBz+Szl7avZyELitc=; b=aiaMKeIS5fUxKAvZNpmpLYWFeaT5MDpxPy72tdmPcZwkqa7QpFEf6m2Y7N9OBm78damdTG76rEYkaSvY2C/XKmfSLKKkKSvhu7lc8CHiPXXtYMkyy15Yk18ESLuLha8ve0d00YBhRRp+yld/Y2z2gbcAghQc6vNECBo4C5ilAUUfGB0HXH64NBbNVePGhAt8g0Q8IWFsPju465lKK6ZQNk9Apn+ZriwYEUVx+GbBvKlfi/WqvRu1XOE+TileBEC4o1itnHHbMZL+7MwJbQIuaLlaXuxKsx3ICSkUhXrztXCxJKMwayJBOSB8J6r5vJ4Du01JtAkcBpzBqhcY6zPSNA==
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=4kLSWYGO0zGNfPM4rvihHJIgTbvBz+Szl7avZyELitc=; b=Wq2mNlsjcUHne3fv339crbBMYQ/+6rPX1rJE9lrgb6fpMAcjLqHl34hM2fMfeD3UTih7S8nPA64DNCcLds2DSkbUkjzTk/Z+qPtbfrzS+IaMde4c3deHurOD9GBOSO3TdQ6t9NOS6hgPD2bVx/yKc+AOUCg++Rfo3tXp/HxjXAQ=
Received: from VI1PR08MB2639.eurprd08.prod.outlook.com (2603:10a6:802:25::13) by VI1PR0802MB2270.eurprd08.prod.outlook.com (2603:10a6:800:a1::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Tue, 23 Mar 2021 09:10:01 +0000
Received: from VI1PR08MB2639.eurprd08.prod.outlook.com ([fe80::f004:92db:341e:9d6b]) by VI1PR08MB2639.eurprd08.prod.outlook.com ([fe80::f004:92db:341e:9d6b%7]) with mapi id 15.20.3955.027; Tue, 23 Mar 2021 09:10:01 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Daniel Migault <mglt.ietf@gmail.com>, "teep@ietf.org" <teep@ietf.org>
Thread-Topic: [Teep] clarification questions on draft-ietf-teep-architecture-14
Thread-Index: AQHXHsgzU4jouAJcUEa/f9TZISL4naqQRh/w
Date: Tue, 23 Mar 2021 09:10:00 +0000
Message-ID: <VI1PR08MB26392008798A0F8972B034D5FA649@VI1PR08MB2639.eurprd08.prod.outlook.com>
References: <CADZyTkkomUxgPzFs1e6xUShPfFC7sfAt2-ROOTQYj+5vjjPduw@mail.gmail.com>
In-Reply-To: <CADZyTkkomUxgPzFs1e6xUShPfFC7sfAt2-ROOTQYj+5vjjPduw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ts-tracking-id: 7C74D87CDD092443B75F3BBA8AA99C8B.0
x-checkrecipientchecked: true
Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com;
x-originating-ip: [195.149.223.198]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 10f9cfd2-01e5-49d2-2c92-08d8eddb74b0
x-ms-traffictypediagnostic: VI1PR0802MB2270:|VE1PR08MB5038:
X-Microsoft-Antispam-PRVS: <VE1PR08MB5038EA98B2F52D174C21129EFA649@VE1PR08MB5038.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:5236;OLM:6790;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: PQ12EdOEU2piWtPnktMfWdLgkKl7K1Mzu/Q6gx5bULs51iL/u3Ib3tHsED08Z0OIqxUCdyUbJPMdbkS+tvOmeekMd9HDbGIClZmprleOXaAPGjE7AvrkEAFeg0uHrCoVPHXjSd8MFZ56meIG+XzGmX9AdmOs90EGvGubsszqt+0PmwZh0fpMoepfSMvUGDO+FR4D/CKylkTqNN7uS4DNJbAhEetd5oDf6njmc/b53J6zp8aIVYGvxdVVuZgecEB/dB4/tDhrqE6w6uoJ4oq8bYFeO0VUgG1hlV8qNMXUmbjD6R3XDvaaJITlbIvKqyR8VGqfZQBTDtrwdRpdv4rg30b/1Z1LcCEV0B6qxpbSdNppMy/QbU9jrPxcrq9s4nClfZs0W/lyoeK5xG9ylwPz6aMYpstb7beEZevQe/ISSyOqjgY4Udbm24UhL2BXicBB+dc9lqUzszVGLy3vye4rReDw15siyUmQrjnhymz73dP536QT9eeyenUKVE1xrTVVhDlbWfoSUNftI45B99yHsPhwBB/tXX2GA+e43vB/Bh3AufwAdQDMzgOvr2RQZjvP43Ps8rOiJn0xLfEmY9e2fpMUfGI9M09VKQeh1nzZrUpJxvM+bTmlXPqnmMn/x9EEjOskjAjI27FVZKvCWmDxIfgJLbCLIIgn4StTxG4Msq93CFu1kY3jCQ9RVWPhbYy5JWTpi6IEjsG+eFcVb9gKIepzDNyKUca9gNOQNqiWmECqerpcASEdzikSpDcKlRHU
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR08MB2639.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(346002)(396003)(136003)(376002)(366004)(33656002)(5660300002)(55016002)(166002)(30864003)(26005)(38100700001)(52536014)(71200400001)(186003)(83380400001)(9686003)(66446008)(66476007)(316002)(9326002)(8676002)(64756008)(2906002)(7696005)(966005)(66556008)(110136005)(66946007)(76116006)(86362001)(6506007)(8936002)(478600001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: +0VPI/ADF2MjcTKFQxCpNuZJWeeXa68kxJcDvzePbqP8UF33lYD6F7l4iB3ermNuE0cBaY74xPRbfcrGHiNwmBRA3Cb28yTmQb26cfW84c2pjON4vXWovNKyR3OuI8Rc7uCqwiJlpYDph7ViCPg0b+1qsBd7PczllKxaxXer3mbVdk8y/mNNDiD69vfr+N+BS1k2ykUIgPrmjlF0i3CPv3hsKsU+fBawv0TiHMoyivZG9ZL6zDceKJjwtQFatYpffst4NfD/2H5WXgJkH5vvE51w20xAu9DzOtOWDQaVuKricnTcRM411ocNCUTJduVurU4wgsewerqdybCwDsvKq8t1YX4DAhENRIsL1HRQTEXoldz7/nNaHW+PfZXqLzm/bfzNbS5RBYwIADQEduR9/iLWqfhc0B9a1usENNxil4zYK4lpthb1T6C0iXAPwbWmR4A1x7+ybTc7+5RdELmJgpsL9qm3rSsC7+mFne0cjPR1uPRp+vgX6tUv9XAUSKqhTusaA73JYmL7H+joT8fQXVjmZJEOnYqW3GrZeSd1CrN1gBBj2wh0fEZY//mf9v5AI5uDFYEXIJP9GD3Dq3tnKr0xwCnBtYv/k6VczB7p6Qkf6eshNF0aWlZ8oz28sVFxY+8r4mLEmmDQciMMBoZ1+tVPJN2ud+y+6Sl8z76s8mOXF/LqlqAd56iSjFXN5fxvJaVTG9lh0I5AwEZoYySsB+m3bu/aMbmp8N/PMYOOIS/rfBQ6Do5gBkCwTsX09I4hyL92z/8bvqETBppWbcwcsXOmNU6oCwXWc8WaQ8NyHycPEsrNz61GHbjK+MKN9imWTwF+9gqFoClPRNIAkzQNkLbgL/0YLVEaMptpuASZBMoMaGTOqRygwBWBE1M/RWN59T8ND0FcXYJYVOlcRZ7X/58qhaq6pPZDyqUeRHbTb3+ZVUREKv+TJaTooGl6vV82EWwBfifFc4YLECj5ILB7d+zsRmc6n4u92uZWGZHxxXhBqEYyTpcl6sp0j6K1vvthu5hwOMr4RVCEby9XLgXu0geURZjbvtJENG2batehrLfFwX7o3MhSQlHWmUs7yV2805XDDct1cqKcbBR2sMiLDGoXweRZpIIfY6S3tXmeJU3Z49iHsSE9BLdTnDzoxBPGjVV7bls5ShvKEGtSdRTF39ODEkRSxdAdUi0olkqioQcKpsY+hMzSqfbBr9hTcecmV6SWeMQ822VR8rlKg27D1izr9sCr1PDqbW3wWmZuBr6ymA5ae7beREJWShXd00qy70k4BNC0WuAKEe17y7ao2tW7knVO7EVk2XVcb1I3Cx6lqzURmBtP13jvdWMhgKMc
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_VI1PR08MB26392008798A0F8972B034D5FA649VI1PR08MB2639eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2270
Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT040.eop-EUR03.prod.protection.outlook.com
X-MS-Office365-Filtering-Correlation-Id-Prvs: 1fe75bbe-c334-416b-432a-08d8eddb7047
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: szc15uQI3b3d75aQRWbrbQSEQNB0Ahdbea5mTi8TuwWp1Tyi0iPr5x8nTjzUaUJBYb8J7PC3HdvZSYb/MnQAtQsKIQG0j0Dja/m4qFb+WOd4+cRgoOaHgXR2E7r6e49rcdgTiw7ojO9ijBVmHDBCPN9NA5wPbkmwz3GGHnW2ZNbGi/Ipz1ICKe8+GcZmu9MiN2o7LAzN7WZ6O0sc0iqw1BY53BOCbh64RnmWW2SSbFLuJo0h1zR03hvobQvilLb5odAQhtf7rrRo7nXOTg/kfoMQCQBt97Ite+CJKbOPzFr0G4+0LFCvmqRJQkryu4b3ka4Qj66w6IZFfHr2hd2G/Eo7oGp18+BV6ccIwOfEF1Opj+hIDo/jYshknMbVPkjg6O2uCWs0jlg44yhT+14o13czUHESBO1+YIfDtoLIVh6rJ4myuYMfV499TVdYGQ1HjO5/fzGDsV3NBWJyeMxN+vn5WExbGi8nRQmXTNE3UVJ4Y7zmNdx14ajTxdc4Wbt/XiVi47k3uiZ3od9wm45OijcwB96Bp5mdH3rfj1Qb/dmWLSXXA+TmUEpvHOMUNeEZzGNHIHgJVbq3i8g7mGhEg5vSGfJXzjoDaJ0sbJfcI8lDzdSE3TAG2dS8BQbBmdGX9l8ORzFGrOurXScT4UKWjYktyNLwpfoDjzoRy7+hLzxBzyZlrUc6GM3gN/0W/VeMxO6pIjxCtxK+zAW9325ejjtcSaa8ID7o169k40KFp8A=
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(376002)(39860400002)(346002)(396003)(136003)(36840700001)(46966006)(70206006)(82310400003)(47076005)(166002)(70586007)(52536014)(26005)(8936002)(8676002)(82740400003)(86362001)(9326002)(36860700001)(81166007)(356005)(83380400001)(478600001)(966005)(7696005)(33964004)(2906002)(5660300002)(110136005)(9686003)(316002)(336012)(55016002)(186003)(30864003)(33656002)(6506007)(579004)(559001); DIR:OUT; SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2021 09:10:08.4178 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 10f9cfd2-01e5-49d2-2c92-08d8eddb74b0
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-AuthSource: DB5EUR03FT040.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5038
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/MX67HHrxE5kXTw76XqD5IhaOL0I>
Subject: Re: [Teep] clarification questions on draft-ietf-teep-architecture-14
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, 23 Mar 2021 09:10:23 -0000
Hi Daniel, Thanks for reading carefully through the draft. Many of your questions relate to the use of TEEP for Intel SGX. I cannot answer those questions and the architecture was written to be independent of a particular TEE instantiation. I will skip the SGX related questions and someone else (maybe from Intel) can answer those. Let me answer your questions that are unrelated to SGX. ~ snip ~ <mglt> To simplify the life of TA developers interacting with TAs in a TEE, I am tempted to say that TA always run in TEE, in which case "in a TEE" may be redundant or may suppose that some TA are not running in a TEE. Note that it appears at several different places in the text. [Hannes] The issue is that there is the TA in the secure world but then you also need code elsewhere to interact with it. In fact, there will have to be code pretty much everywhere (at least in TrustZone) to allow the transition from the app running in the normal world to the TA running in the secure world. It may sound like an easy thing to do but it isn’t in practice and the TF-M and OP-TEE code show this, see https://www.trustedfirmware.org/ </mglt> an interoperable protocol for managing TAs running in different TEEs of various devices is needed. <mglt> This software update protocol needs to make sure that compatible trusted and untrusted components (if any) of an application are installed on the correct device. In this TEE ecosystem, there often arises a need for an external trusted party to verify the identity, claims, and rights of TA developers, devices, and their TEEs. This trusted third party is the Trusted Application Manager (TAM). I am reading "this software update protocol" as limiting the ability to upgrade an already installed application. I have the impression that installation of a software is in scope and that in this case, installation will only be permitted depending on the TEE version. If this is included in the term "software upgrade" I have the impression these tasks are beyond a software upgrade. [Hannes] We also cover installation and deletion of software. Maybe we should expand the sentence to make this clearer. </mglt> The Trusted Execution Environment Provisioning (TEEP) protocol addresses the following problems: - An installer of an Untrusted Application that depends on a given TA wants to request installation of that TA in the device's TEE so that the Untrusted Application can complete, but the TEE needs to verify whether such a TA is actually authorized to run in the TEE and consume potentially scarce TEE resources. <mglt> - A TA developer providing a TA whose code itself is considered confidential wants to determine security-relevant information of a device before allowing their TA to be provisioned to the TEE within the device. An example is the verification of the type of TEE included in a device and that it is capable of providing the security protections required. My first question reading this paragraph concerns the TA developer versus the TA manager or device manager. I am tempted to see these as two different roles, but I would say the responsibility to install a TA with a certain level of version of the TEE is more likely to be the responsibility of the TAM or a Device Manager than the TA developer. [Hannes] I think both entities need to work together. The TA developer writes the TA code and understands for what application it is meant to be used (at least typically). It might also have requirements on the type of TEE. An operator of a TAM needs to decide what it wants to send to devices. This may not exclude that TAM and TA developer have a specific agreement and some conditions are provided by the TA developer. [Hannes] They may have an agreement or in other cases the relationship may be pretty loose. I am reading this text as a TA developer or manager evaluates the trustworthiness of the REE, but I would tempted to consider such information as unlikely to be reliable, so I am wondering if there is anything I am missing. [Hannes] Imagine that a TEE developer writes an app that does some machine learning and he only wants to release the code to devices that implement certain security features in the TEE. He would work together with the TAM operator to ensure that those requirements are met and the attestation functionality offered by the TEEP protocol gives him or her that assurance. ~snip~ While not related to the code itself, but some sort of secret credentials associated to the TA, I believe that a TA Manager may check the level of trust of the TEE before provisioning the TA with secrets. [Hannes] Yes. I am wondering if that is part of TEEP with Personalization Data or if such instantiation is always delegated to the TA. [Hannes] This is part of the TEEP protocol. The ability to protect (encrypt) personalization data is offered by SUIT. More specifically, the TA sets a trusted communication with the TAM that pushes the secret credentials. [Hannes] Sort-of. Details about the SUIT part will be added in a SUIT document on how the encryption looks like. Now that I have read the full spec, it seems that the bundle description somehow addresses this, but I think that mentioning the configuration of a TA in the introduction or overview section would ease the reading. [Hannes] This is maybe the wrong document; the TEEP protocol document could give an example or should go into the details of this. My take-away from the last meeting was that we will cover this in a separate document in SUIT. </mglt> ~snip~ [...] 4. Architecture 4.1. System Components [...] <mglt> A Trusted Component Signer or Device Administrator chooses a particular TAM based on whether the TAM is trusted by a device or set of devices. The TAM is trusted by a device if the TAM's public key is, or chains up to, an authorized Trust Anchor in the device. A Trusted Component Signer or Device Administrator may run their own TAM, but the devices they wish to manage must include this TAM's public key or certificate, or a certificate it chains up to, in the Trust Anchor Store. The definition of Trust Anchor Store implicitly seems to say the TAS is in the TEE. If that is the case, it might worth being mentioned explicitly. [Hannes] The trust anchor may not necessarily be in the same TEE that is running the TA. It could also be in an attached crypto processor / secure element. </mglt> ~snip~ [...] 4.4. Untrusted Apps, Trusted Apps, and Personalization Data [...] <mglt> There are three possible cases for bundling of an Untrusted Application, TA(s), and Personalization Data: 1. The Untrusted Application, TA(s), and Personalization Data are all bundled together in a single package by a Trusted Component Signer and either provided to the TEEP Broker through the TAM, or provided separately (with encrypted Personalization Data), with key material needed to decrypt and install the Personalization Data and TA provided by a TAM. I suppose that in this case the termination point of the TAM communication is the broker, and the broker is then responsible to dispatch the TA and Personalization data to the TEE and the Untrusted Application to the REE. I believe the reason for encrypting the Personalization Data is to perform end to end communication between the TAM and the Agent. I believe the clarification would help the reading. I also assume that the TAM will use the public key of the Agent. Overall I believe that this scenario multiplexes two sort of end to end communications. Some communications between the TAM and Broker are related to untrusted world while TAM or developer - Agent are related to the trusted worlds. I would like to clarify between Untrusted App, TA, and Personalization Data what is the final destination, what is encrypted and what key material is used. </mglt> [Hannes] There are different layers of communiation, as shown in Figure 1. Section 4.4 only talks about how the different software components & personalization data may get to the device. Section 4.4 really has to be read in combination with the text related to Figure 1. ~snip~ [...] 4.5. Entity Relations [...] <mglt> At step 3, a user will go to an Application Store to download the Untrusted Application (where the arrow indicates the direction of data transfer). The arrow direction might be indicated in the figure or with the first arrow being represented. In that case this may correspond to the certificate provisioning. It seems to me - unless I have missed it - that certificates provisioning is missing. If so this is clearly a nits. </mglt> [Hannes] Here is the figure: (App Developers) (App Store) (TAM) (Device with TEE) (CAs) | | | | | | | | (Embedded TEE cert) <--| | | | | | | <--- Get an app cert -----------------------------------| | | | | | | | | <-- Get a TAM cert ---------| | | | | | 1. Build two apps: | | | | | | | | (a) Untrusted | | | | App - 2a. Supply --> | --- 3. Install ------> | | | | | | (b) TA -- 2b. Supply ----------> | 4. Messaging-->| | | | | | What certificate provisioning is missing? 5. Keys and Certificate Types [...] <mglt> Figure 4 summarizes the relationships between various keys and where they are stored. Each public/private key identifies a Trusted Component Signer, TAM, or TEE, and gets a certificate that chains up to some trust anchor. A list of trusted certificates is then used to check a presented certificate against. I have the impression so far that TEE has not been involved into any authentication. I suspect that TEE and TEEP Agent represent the same entity. If that is correct I think that would worth some clarification why we can use one for the other and why we need to have two distinct entities that share the same identity. </mglt> [Hannes] A TEE is a system concept, which includes a combination of hardware and software. Hence, you cannot really state something like "the TEE authenticates X". The TEE and the TEEP Agent are also not the same thing. Figure 4 really only focuses on the security keys and tries to avoid going too much into details of how an implementation on a specific TEE works. [...] [...] 6.2. TEEP Broker Implementation Consideration [...] <mglt> Model: A B C ... TEE TEE TEE +----------------+ | | | | TEEP | Agent | | | Agent | implementation | | | | +----------------+ v | | | | | +----------------+ ^ | | | TEEP/HTTP | Broker | | | | implementation | | | | +----------------+ | v | | | | +----------------+ | ^ | | HTTP | | | | | implementation | | | | +----------------+ | | v | | | +----------------+ | | ^ | TCP or QUIC | | | | Broker | implementation | | | | +----------------+ | | | REE REE REE Figure 5: TEEP Broker Models I am wondering if TLS could be included into the TEE. It is correct that I do not envision TCP being in the TEE. [Hannes] This can be done and is done regularly. I think we should update the figure to include this option since it is very common. I added this issue: https://github.com/ietf-teep/architecture/issues/222 </mglt> [...] 6.2.1. TEEP Broker APIs The following conceptual APIs exist from a TEEP Broker to a TEEP Agent: 1. RequestTA: A notification from an REE application (e.g., an installer, or an Untrusted Application) that it depends on a given Trusted Component, which may or may not already be installed in the TEE. <mglt> 2. UnrequestTA: A notification from an REE application (e.g., an installer, or an Untrusted Application) that it no longer depends on a given Trusted Component, which may or may not already be installed in the TEE. For example, if the Untrusted Application is uninstalled, the uninstaller might invoke this conceptual API. I understand Unrequest as being equivalent to undo, or remove or uninstall. If that is correct, I am wondering if there are any reasons for non calling it remove or uninstall ? </mglt> [Hannes] The reason is that a TA may be needed by another TA and hence you cannot just delete it. You can only say that you do not need it anymore. Once nobody needs it anymore it can be removed by the system, if necessary. [...] 7. Attestation Attestation is the process through which one entity (an Attester) presents "evidence", in the form of a series of claims, to another entity (a Verifier), and provides sufficient proof that the claims are true. <mglt> Different Verifiers may require different degrees of confidence in attestation proofs and not all attestations are acceptable to every verifier. the last verifier should be Verifier in my opinion. If that is correct the nits appears at multiple locations. This is a nit. </mglt> [Hannes] We just used the terms from the RATS group. [...] 9. Security Considerations 9.2. Data Protection [...] <mglt> The protocol between TEEP Agents and TAMs similarly is responsible for securely providing integrity and confidentiality protection against adversaries between them. Since the transport protocol under the TEEP protocol might be implemented outside a TEE, as discussed in Section 6, it cannot be relied upon for sufficient protection. The TEEP protocol provides integrity protection, but confidentiality must be provided by payload encryption, i.e., using encrypted TA binaries and encrypted attestation information. See [I-D.ietf-teep-protocol] for more discussion. There is also the case where a session is established between the TAM and the Agent. If used this would require HTTP to be in the TEE. [Hannes] Yes, you could run HTTP into the TEE and this is done as well. For the TEEP protocol you do, however, need to make some decisions about how you want to design the system and the current design assumes that there are cases where HTTP is terminated outside the TEEP. Is this a good design? We will see. Ciao Hannes 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] clarification questions on draft-ietf-teep… Daniel Migault
- Re: [Teep] clarification questions on draft-ietf-… Hannes Tschofenig
- Re: [Teep] clarification questions on draft-ietf-… Daniel Migault
- Re: [Teep] clarification questions on draft-ietf-… Hannes Tschofenig
- Re: [Teep] clarification questions on draft-ietf-… Akira Tsukamoto
- Re: [Teep] clarification questions on draft-ietf-… Hannes Tschofenig
- Re: [Teep] clarification questions on draft-ietf-… Daniel Migault
- Re: [Teep] clarification questions on draft-ietf-… Daniel Migault
- Re: [Teep] clarification questions on draft-ietf-… Daniel Migault