Re: [Rats] looking for better terms -- request for bike shed discussion

Dave Thaler <dthaler@microsoft.com> Thu, 09 January 2020 01:36 UTC

Return-Path: <dthaler@microsoft.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D41120142 for <rats@ietfa.amsl.com>; Wed, 8 Jan 2020 17:36:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 OoFPtGElakKq for <rats@ietfa.amsl.com>; Wed, 8 Jan 2020 17:36:35 -0800 (PST)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2111.outbound.protection.outlook.com [40.107.223.111]) (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 B664A12004F for <rats@ietf.org>; Wed, 8 Jan 2020 17:36:34 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CeuCLoPMw3GSMzPe99SWLPiGLDPkybLXohjKM6blSra2zosJvj4V4Hacfu67B5iDAXlOTcnuvuu01rclOefHWIZa2f4/r9yi1zAicua8ONGFbUbYPgBPoF/8NXAW3P6zAipqzihArDOn/BLvDktd4Ztxl9zgtHXy8byKm5g55qUeJD18437a+jSOmrx5f9zyfRqUxNsUHVB99OfwyyI7oMYybcoojpnSWw5ZpUMoHNm4ciiCe94PTOZnX5uolCMWYfLFwu6C3etQPPB+mbiNmK2iHUlWZoNfZkjAnMncxe9zU6zSQCn/mpfzX9sA4aOrEuZeRauyCiGl3lR+Z0Cgiw==
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=e+IGw/E9TXqsEFVA1vnTlx9+3KkI8IDsqFkVhtUrFKU=; b=eJwFYAGqHY+8FZYlh5Im2Epaq2qU+7I6BfOKJfYsL2+5GCuJDXPTCIwOqRL+mkMbrr3gpgknaK3gsHZsEiMQcQkKP6+7S1jScuMHkA8F/noE3U85QXOSYdyLW2QfjGlBhKQ475oALWOQfA/cA+uxsk5vfLQOZVCgjSc3fbX3zDZ4TLfhPdimXjHvqjjPKZCuWjRYyi8mwleQ2zR4FlMwEMQmPgRpoV39JLJ/aFPgLaivEvXu2UgWrplx67f8Zw2qPTEmKt9f8se3i4ba6BmxRLv9+Eaj6FX2x+Mn0cVEs1+OLRFSpxOp/Q0CVEYP4egq3wBQKVEVhmEaR4/IDxpBLA==
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=e+IGw/E9TXqsEFVA1vnTlx9+3KkI8IDsqFkVhtUrFKU=; b=h64Sk3DmX2DBHKTXmmy/cZxWR9j0o4/DIUXekaXKYRHTZUw0J6OT8pm5nR7NRlgG5yBlKK1RsBzm0eIU1Xz5bObwlwNFVhcoq0Frp+s5XY87yRvQTeJZSdSpghL/UO2sPYr6ibNNiuW6Cq+q9h1Bl9574MQDOMY4VKhKg2KLGMo=
Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (52.132.20.161) by BL0PR2101MB1108.namprd21.prod.outlook.com (52.132.24.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.3; Thu, 9 Jan 2020 01:36:33 +0000
Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::c50e:86ef:6bf3:d535]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::c50e:86ef:6bf3:d535%9]) with mapi id 15.20.2644.002; Thu, 9 Jan 2020 01:36:33 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: "Smith, Ned" <ned.smith@intel.com>, Michael Richardson <mcr@sandelman.ca>, Laurence Lundblade <lgl@island-resort.com>
CC: "\"Schönwälder, Jürgen\"" <J.Schoenwaelder@jacobs-university.de>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] looking for better terms -- request for bike shed discussion
Thread-Index: AQHVxXRNHlBPWqb3kESfZ0AtIRfNEqffZpYAgAAExoCAAFDHAIAATH2AgAEh3gCAAElhEIAAGxMAgAAAbRA=
Date: Thu, 09 Jan 2020 01:36:32 +0000
Message-ID: <BL0PR2101MB1027EA0EFF9CC536603D18CFA3390@BL0PR2101MB1027.namprd21.prod.outlook.com>
References: <26979.1578413051@localhost> <6291CF16-BBDC-4A12-A0C0-FDFBAB494A31@island-resort.com> <20200107165432.zmpm6yilgr6fogrh@anna.jacobs.jacobs-university.de> <C7744481-277D-477A-8B0A-F7DC9F4CC273@intel.com> <0FB69139-54DE-4F1B-906F-12B83D1EDEED@island-resort.com> <31998.1578512094@localhost> <BL0PR2101MB10278A4C6B18B806320B82EEA3390@BL0PR2101MB1027.namprd21.prod.outlook.com> <DAD704E4-CB1A-47A4-A951-763363689716@intel.com>
In-Reply-To: <DAD704E4-CB1A-47A4-A951-763363689716@intel.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-09T00:02:40.8002482Z; 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=59f11f50-6651-43a1-b587-9a7347e6d731; 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: [167.220.61.0]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 805dd788-b92e-4f3e-7515-08d794a45bb5
x-ms-traffictypediagnostic: BL0PR2101MB1108:
x-microsoft-antispam-prvs: <BL0PR2101MB11086374112C25B6FA2EECADA3390@BL0PR2101MB1108.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 02778BF158
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(366004)(376002)(396003)(136003)(13464003)(189003)(199004)(71200400001)(66574012)(9686003)(55016002)(478600001)(7696005)(8990500004)(33656002)(5660300002)(52536014)(54906003)(186003)(316002)(81156014)(8676002)(6506007)(8936002)(86362001)(53546011)(81166006)(966005)(66946007)(76116006)(66556008)(64756008)(66476007)(66446008)(2906002)(10290500003)(110136005)(4326008)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB1108; H:BL0PR2101MB1027.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: ubnRtKYOQ4R5iasoXiKv/MOdWHsDZhQjF3ojrFGSDdFCB7Kqym31BXvlXE6Gv8oMBhhenlpGRVleVFLuTKSOJUTcroDTugyLuw1gdXUtF9Md61AUWEr5xPx4LJXBgphhLg4RAPp9wjdGkvAgba+j7yirXLZTrfvvCoFyKfxXGQvk+xFvAw2+zErz86l8Aa8wBtd6updi0lt7GzftlxlYF7GR1gDH+H3+FXSrbeUdxzjBdA9PU/fPWXyY2moGBXCKaVuLPHi2udh9qOl8uUm3lOhI19nA198HaPS3evYe5DQN0ED+y1YLUItAZkA3PmEdUfzuL+iwIC9pfV+UjwFGH4FX6ra9RxmGO/hWJd/Vpi0VUPMDXnGjA0LKds7f4y0GOM4GxgvRK6a1j8zykrFfMcN+ZhLLTGgc1273ZgDCrRuuLDODjR21Md9dnyRN5F49LfJnGJwVT3tb/BkPyjIohYtPjVP/rSyDr8lAgwfUkRY0DZ9C9S55U8qBwC2t8uY77OEogG/HNPEaO5k1Ip4bUWHEe3XuecmtHhr2mqKaIUHokx5ITDjAB0A45RghQ8to
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: 805dd788-b92e-4f3e-7515-08d794a45bb5
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 01:36:32.8531 (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: r4ip8QgEX5kVdEs0A59z51/h/xQpYzggezweIaCHkv3S7a9B4W81jBwPpYvOsQOgz5g8L39P5/Pi598AUN09pehjxefXu7kjD0GQ8Q162LU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1108
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/4BuT0_9mAGU_5I7V57dlmzLdcgk>
Subject: Re: [Rats] looking for better terms -- request for bike shed discussion
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2020 01:36:38 -0000

I think I agree with everything Ned said below. :)

Dave

-----Original Message-----
From: Smith, Ned <ned.smith@intel.com> 
Sent: Wednesday, January 8, 2020 5:34 PM
To: Dave Thaler <dthaler@microsoft.com>; Michael Richardson <mcr@sandelman.ca>; Laurence Lundblade <lgl@island-resort.com>
Cc: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>; rats@ietf.org
Subject: Re: [Rats] looking for better terms -- request for bike shed discussion

Equating the "attester" with an "attesting environment" may be fallacious. For example, the TA might be the thing that signs the conveyance protocol frames and delivers the cert chain to the Verifier. However, it (the TA) isn't an "attesting environment" it only ever is a "target environment". 

The Verifier MUST(?) detect the DICE layering convention and walk the graph back to the original (root) "attesting environment". Even with DICE layering, there is still only a single "device" (endpoint) that the RATS Role will call "Attester" and it consists of multiple "attesting environments" and multiple "target environments" where some of these are both an "attesting" and a "target" environment during its lifetime. 

It may be incorrect to say that the TA is the RATS "Attester" because the Attester is supposed to be a pledge that can prove it is a trustworthy endpoint to the Verifer. The endpoint isn't just the TA, it is the chain of things that anchors it to the first "attesting environment". 

The root/anchor "attesting" environment relies on its mfg to establish trust using a mfg issued certificate that vouches for the process that manufactured it and likely issues an identity credential (IDevID). The IDevID allows the Verifier to disambiguate which of possibly multiple instances of Attesters it is talking to currently. 

It seems reasonable that an EAT submod structure can be used to represent DICE layering (so could an X.509 certificate chain). However, a submod could also describe other relationships / decompositions of a multi-component endpoint. For example, if the OP-TEE consisted of multiple chips then there could be multiple vendors, part numbers etc.. and therefore multiple submods where all of them (likely) are "target environments".  

DICE layering comprehends hierarchies too. If one of the OPTEE sub components had DICE capabilities it could become an "attesting environment" to one of the OPTEE chips (branches). But this more complex thing is still dependent on its path to the anchor/root "attesting environment" so it can't (in isolation) claim to be the "attester". 

If the TEE was an SGX instead of an OPTEE, then the anchor "attesting environment" is SGX uCode rather than HW --> Trusted FW. The SGX "attesting" and "target" environments are orthogonal to the non-SGX "attesting" and "target" environments, but nevertheless part of an IA "device". It is possible therefore to have multiple "Attesters" in the same SGX-capable "device".

-Ned

On 1/8/20, 4:02 PM, "Dave Thaler" <dthaler@microsoft.com> wrote:

    I don't think I have any problems with Laurence's terminology but just to test it...
    
    We have devices running Trusted Apps on OP-TEE over trusted firmware on an ARM TrustZone processor.
    The full evidence is a DICE cert chain that has a set of claims for each cert in the chain, where each layer is an attesting environment for the subsequent layer (attested environment):
    	Hardware -> Trusted Firmware -> OP-TEE -> TA
    Thus there are four claim sets in a chain.
    
    Using Laurence's terminology, I believe the suggestion is that attesting environment is an "attester" and an attested environment is a "target".   Thus the example above has 3 attesters (Hardware, TFW, and OP-TEE), and 4 targets (HW where target == attester, TFW, OP-TEE, and TA).
    
    Are you ok with saying that every claimset in a chain is from a separate "attester"?   I believe this is different from our current definition of Attester (which is the thing that sends the whole chain to a verifier), so want to confirm.
    
    Dave
    
    -----Original Message-----
    From: RATS <rats-bounces@ietf.org> On Behalf Of Michael Richardson
    Sent: Wednesday, January 8, 2020 11:35 AM
    To: Laurence Lundblade <lgl@island-resort.com>
    Cc: =?utf-8?B?IlNjaMO2bnfDpGxkZXIsIErDvHJnZW4i?= <J.Schoenwaelder@jacobs-university.de>; Smith, Ned <ned.smith@intel.com>; rats@ietf.org
    Subject: Re: [Rats] looking for better terms -- request for bike shed discussion
    
    
    Thank you for this very nice text. I rather like it.
    
    Laurence Lundblade <lgl@island-resort.com> wrote:
        > Here’s some rough text:
    
        > Conceptually, the “attester” produces a set of “claims” about a “target”.
        > The claims are known as “attestation evidence” and are sent to the
        > “verifier”. The verifier additionally takes in “endorsements”, processes
        > the attestation evidence and produces the “attestation result” for the
        > final consumer, the “relying party”.
    
    
        > This description left conceptual for easy understanding and discussion.
        > Actual implementations are usually more complex in at least one or more
        > of these ways:
    
    
    
        > * The attester is also the target
    
    
        > * One attester produces claims about several targets (submodules)
    
    
        > * The verifier and the relying party are the same
        > * Claims may be simple or complex, many or few
        > * Some claims are measurements and some are not
        > * Some claims in in the attestation evidence may be simply passed
        > through the verifier, others may be heavily processed.
        > * Daisy chaining -- the evidence from one attester goes through a
        > verifier producing results which are taken as claims that are input
        > to another attester that outputs a different set of evidence that
        > goes on through a different verifier.
        > * Daisy chaining may happen on the device producing the attestations
        > or in the infrastructure evaluating the device or both.
    
    
        > (Next I’d write a plethoras of simple examples for attester, target,
        > claims… assuming only the simplest implementation that maps to the
        > conceptual description )
    
    
    
    
    
    
        > I am starting to prefer the basic conceptual / abstract description over one
        > that is inherently mappable to every possible.
    
        > LL
    
    _______________________________________________
    RATS mailing list
    RATS@ietf.org
    https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C3ca5bb5fc5d84a6f6f6208d794a4120a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637141304715148942&amp;sdata=2LW6xIN2AAm7bkYQIlpqGQRTwT76Bp0GYqxQbIbN3UM%3D&amp;reserved=0