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

Dave Thaler <dthaler@microsoft.com> Fri, 07 February 2020 20:59 UTC

Return-Path: <dthaler@microsoft.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 AF6CB1200B6 for <teep@ietfa.amsl.com>; Fri, 7 Feb 2020 12:59:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 sK2zMAz0SDwa for <teep@ietfa.amsl.com>; Fri, 7 Feb 2020 12:59:32 -0800 (PST)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on20703.outbound.protection.outlook.com [IPv6:2a01:111:f400:7eae::703]) (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 3415812009E for <teep@ietf.org>; Fri, 7 Feb 2020 12:59:32 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IrlNNvu+AvZSauFMbWL1eLXV4Dbyo9lpgSqRFyG2xMBaLHHOxjwN3IOY4HrXq/A5dBA0qQ+V+/OnDOrjowWD8lIdUt6ouWH+nQCGzF64vpPF7S2pA+Urh6Oam+11vTqia9Z9T2PHdf9/PPUAPCxzTT5NYBWXibizhk/NWHPy3CrOuYqqnuN1UNjYiaWjQir18AfAA2rCh73B+JpoQJt7OOIE6LshCETMAapGeKu627fYqHUlI4gT4IFVXQX/Y/JONlHKB/gSQup6oBX2HV932CKaKLxmQi07zkNms7rZTne6Z7VNjDiRhMN5iaJh3NMhcst9z2HDXGaDlSsQtJVACg==
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=IPQ6sTLBUbrBRTFDUS09mJLzglrGHwaU7dDz856M2TY=; b=HQ/bd1OGvzCHOurFKd8ZYrdgCUI/WNl6Z5yZ0I8tCvrulCo5WiDbCUew/7SoDas/n4vnbrU8aXZ89GHwHelcSwrCScMHSMSZNEuFFSZ8mdDaRGTHBp5BRYoWHJddWv1gNd/rOLFNYAobJwSAHX35ka+HwGW6Ztmb2Wtqh6SxO84EykHxVdIfepRew3/IK9x65Pv0xJd/kBCL3hLQo6AdpJ54W/NQOhCp/Ezt9iQZF9KDn8N34x0ngg6J4+o2lNpwLleL4XG9tijNFn8na+gmvTdleOrcwan25I4mIF/AjqkkEYHKYG4llpNRgf0tkD8jd5CQDnBqmaSqjhK4uzsvdA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IPQ6sTLBUbrBRTFDUS09mJLzglrGHwaU7dDz856M2TY=; b=jyFXgRaS+a3LwwS3tGASStX/zAIpQL+DQYAipS5W2kecYaQEkqKybKFyDbqdeVE/8oMgnuLRZKm0QfZXhQSVj/71cmsb6eN76uukDwfFfUdb8695BOGHoB0dwvJjXVi4G9cVSmSL6dUAFMBwovEeE+Biwd8W4LaDmndgfmuf8AU=
Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (52.132.20.161) by BL0PR2101MB1041.namprd21.prod.outlook.com (52.132.23.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.23; Fri, 7 Feb 2020 20:59:30 +0000
Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::7937:5b1f:e529:6e1e]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::7937:5b1f:e529:6e1e%5]) with mapi id 15.20.2729.010; Fri, 7 Feb 2020 20:59:30 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, Mingliang Pei <mingliang.pei@broadcom.com>
CC: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "teep@ietf.org" <teep@ietf.org>
Thread-Topic: [Teep] Working Group Last Call for draft-ietf-teep-architecture
Thread-Index: AdW5iepOELmpRRFXSAWsc0EhHQP19ALfbySAAAc0BIAABIf9gAAWBUMgACJiNvAAvsi6gAA1rNWABQN0ISA=
Date: Fri, 07 Feb 2020 20:59:30 +0000
Message-ID: <BL0PR2101MB102792D18395A9F6199D701BA31C0@BL0PR2101MB1027.namprd21.prod.outlook.com>
References: <CY4PR1601MB1254CD83B0DAADAA67A54CF3EA2E0@CY4PR1601MB1254.namprd16.prod.outlook.com> <BL0PR2101MB10278417515DEF077714D693A33F0@BL0PR2101MB1027.namprd21.prod.outlook.com> <CY4PR1601MB125400678B0DA9EE37683FBBEA3F0@CY4PR1601MB1254.namprd16.prod.outlook.com> <AM6PR08MB5285F0C0209A745F1FAABA23FA3F0@AM6PR08MB5285.eurprd08.prod.outlook.com> <BL0PR2101MB1027BB4B1FDB272B61D04468A33F0@BL0PR2101MB1027.namprd21.prod.outlook.com> <CY4PR1601MB125473BCC69227A45D62FAA7EA390@CY4PR1601MB1254.namprd16.prod.outlook.com> <CABDGos6GwjdAy89=5jY1Cb2xyB_nnphOX-bYFjYNxY2+DR3VkA@mail.gmail.com> <DM5PR1601MB1259E8FF52F3287272903036EA350@DM5PR1601MB1259.namprd16.prod.outlook.com>
In-Reply-To: <DM5PR1601MB1259E8FF52F3287272903036EA350@DM5PR1601MB1259.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-02-07T20:59:29.2238823Z; 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=25a249d6-d264-4ba5-ae72-65daac3d0ef1; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com;
x-originating-ip: [2601:600:9780:16f0:6163:193d:a7ba:f76e]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ebf3be8a-b2e5-4b0b-1142-08d7ac10a04f
x-ms-traffictypediagnostic: BL0PR2101MB1041:
x-microsoft-antispam-prvs: <BL0PR2101MB1041ACF7997D6017C417626BA31C0@BL0PR2101MB1041.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0306EE2ED4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(396003)(346002)(376002)(366004)(39860400002)(199004)(189003)(52536014)(33656002)(8990500004)(5660300002)(2906002)(71200400001)(86362001)(478600001)(7696005)(66556008)(64756008)(66946007)(10290500003)(66446008)(316002)(4326008)(54906003)(110136005)(76116006)(9686003)(55016002)(66476007)(186003)(6506007)(81166006)(8676002)(81156014)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB1041; H:BL0PR2101MB1027.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: fieVaTSEizXfvJkVn/iCSp/SMeIJlNTslU4bIB3mAb+ktiVFcLLJfOUViV9sMrbkUfE0/nfChZ85x5FrZDJCARBVXUrivS8ZjZx5VH2DklxRy1X0r9PWeQjsYtBhQEak6SXgMASoz6aZfHLEvdtIikRRx0svV+r8pxVTydDRXWwND1ycYUojz1TBQe1xdVF576dB7oWYeL6w6r8FsOnyI3115B5+zj1eybQ2ykk/0XJNeTT6XYD+7NOsnhsGUHB7AqrxfauaJdTm5uF6Fixf5xeJ0tkzDyqvFb9OBWXkuZqxr3iiIaJ/KLvytWSuxDEi9+CKd5YHO8M9XCV7VLVb0qAVCaJSKgvSI1xV2w+bfzCIh55OGSCam57moBFVcWyoLHgVTNPx0/peJRLvGIHpMM2Z+FfR8klWYiJR19Tb9xUMtkNMkXNPBj5FduYGuDPy
x-ms-exchange-antispam-messagedata: tjt2/n5rLAVMs0R44O+AoglTYD7g1xWwTu5rx4OMc+Ec6GDaV6GfvA0XNlMp9FG87/288M1oz0iCqSVLs3RgVfSyd3F6xfE4Z7O9hQye8oAEtgdbMt9ESL6zAx5odiWGhM1rt2vdxGkty7pCa1xtsx0vD4p6tkwpWDLZt1X7dnlBj/pTXyZYnZ3xIxce7uEu5kdC8UvMeaMO4v2SMB624g==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ebf3be8a-b2e5-4b0b-1142-08d7ac10a04f
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2020 20:59:30.4065 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: B7N1/kEX7H8Px9RDQLLkZfz65ivjJN+LfgK99eBOeah54/fAruGujF9VFqjfCZ9o5WXmhepHLv4Nl+l1ceNCQBDRTPgIHfiKoxi16YDAy6A=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1041
Archived-At: <https://mailarchive.ietf.org/arch/msg/teep/fEnUrsYBpGJnVOTZCvNZTYloPTE>
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: Fri, 07 Feb 2020 20:59:35 -0000

[Tiru]  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. 

[Dave] I don’t believe there is any such requirement on a TAM.   It might be “useful” but is not required in my view.

[Tiru] why do you think verification in TAM is not required?

[Ming] TA signature verification must be verified. Currently a TEE will check this code signing, and the CA certificate will be in TEE. See Figure 4 in the doc.
       "Code Signing          1 per SP       TA binary          TEE"
Note the above "TA binary encryption" discussion. If a TA is given to a TAM in an encrypted form, such a signature check isn't feasible. But we can
assume that TAM provider always vet TA binaries that it distributes for its service reputation protection.

       Note that there is also the other TA delivery mode where a TA's binary is bundled inside an Untrusted Application as binary data. In this case, the binary isn't sent to TAM for distribution.

       There is also the other case: many SPs / TA App Developers use the same extremely popular TAM service. Device manufacturers may want to limit
       to accept only a set of TA providers by using the code signing CA trust list. The architecture allows such support with the coding signing trust check in TEE.

[Tiru] Got it, Thanks. 

Also wanted to answer Tiru's question to me, which Ming also answered... If the TA developer has to authenticate with the TAM in order to upload the TA binary in the first place,
then having the TAM additionally check the signature on the TA binary is not necessary if it trusts the TA developer, or if it has contractually agreed to distribute that TA developer's binaries.
The entity that uploads the binary need not be the same entity that signs the binary.  So for example, I might get the TA binary signed by a CA that the TEE trusts, and then upload it to the
TAM using my own credentials that the TAM recognizes.

Dave