Re: [Rats] Dynamic Systems in IETF RATS (was Re: 3 Use cases)

"Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com> Fri, 01 November 2019 12:00 UTC

Return-Path: <ian.oliver@nokia-bell-labs.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 AE749120091 for <rats@ietfa.amsl.com>; Fri, 1 Nov 2019 05:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=nokia.onmicrosoft.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 T4719k99pSsy for <rats@ietfa.amsl.com>; Fri, 1 Nov 2019 04:59:59 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70115.outbound.protection.outlook.com [40.107.7.115]) (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 440AA12002E for <rats@ietf.org>; Fri, 1 Nov 2019 04:59:59 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SfXxep72P/szvrT9ZbAkDuobwzIVsK5Q4bj9L6wDdtbgUzezR7i32oP4/uoE3WoKEm8ll5KkbNQzY0HhfoMVu83eWMSrWK2ONpDFnGtutD2UFK+Cvsaun4MV+afBaUT4/ey+MXPV25wyVQfodop8GJ8hXeemvmDNY9yxPLF9LxiMH25i5bDaDYaFHpO/I1Xp2uvs88NLW8K+SIaGSTpPwg4H7tNpVN1GDSvXPQCaLOqVuhdvapevt4UMv5anPa5nqf5OF8zbgiOgO7Oa7snhgynY8PS9hzuO+4QjwdaxB7+f3khSgKUw76h/0kwUhx0Pi53Oy42ad4iUinHqiRNyMA==
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=dHq2BZOgrxlrzZauOiV+/ImQJJkishtJwY568MqAbfs=; b=VZhrhFgTcOswsRic2DkJp+EzTiXe0wnr53OfN7PDoS5I0tpkCeBWdO9JxorrUap8iQ9sTNKeVNZ/71BVaGq8kCBTVzHvxYR6Gqv6v/XMJWXUqiSzqvxTwrjI6OcTwugR3rRSqBuSC6lqEYIIKKya/KICQ4xQO4bWwb+IdhG0vQD6qe1DXGW0IpM41hWy8M1nPHpNBk1NWFKzud2CxpNtIQC65PoUrkpv7HdJrR++BFGJRRK9ipE26VXIgfKsW1y3TD+lCI7UeEGBu6wXCjt9wqZRx9932I28w6SAMq7kxSYMwIz5HhEi4SWVBDFwFGMNzue/PJp6w0Ll3cHq0CQ29A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia-bell-labs.com; dmarc=pass action=none header.from=nokia-bell-labs.com; dkim=pass header.d=nokia-bell-labs.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dHq2BZOgrxlrzZauOiV+/ImQJJkishtJwY568MqAbfs=; b=U5KMDclyL+J/Hmcyt0PfOGsQBToItP7OZXR7cbaaWPl5lTzycrn3txw2I725gW2qYr33vIVKM+DWumMRUdyfhTGLHL5tekBh3OwNHm9YW7KdKu9NvELyvO7LyYsCndngh3+Q0tn67iLTxsVOmUUTMYyo8aZwR5VaX5LDrxNKed8=
Received: from AM0PR0702MB3746.eurprd07.prod.outlook.com (52.133.46.159) by AM0PR0702MB3794.eurprd07.prod.outlook.com (52.133.44.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.28; Fri, 1 Nov 2019 11:59:56 +0000
Received: from AM0PR0702MB3746.eurprd07.prod.outlook.com ([fe80::40b2:509f:ad68:932a]) by AM0PR0702MB3746.eurprd07.prod.outlook.com ([fe80::40b2:509f:ad68:932a%5]) with mapi id 15.20.2387.030; Fri, 1 Nov 2019 11:59:56 +0000
From: "Oliver, Ian (Nokia - FI/Espoo)" <ian.oliver@nokia-bell-labs.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Dynamic Systems in IETF RATS (was Re: [Rats] 3 Use cases)
Thread-Index: AQHVkKtwg7t/O3MMpEyS7kOxpsh9VQ==
Date: Fri, 01 Nov 2019 11:59:56 +0000
Message-ID: <AM0PR0702MB3746BF95CB34737BD034DD1A8F620@AM0PR0702MB3746.eurprd07.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ian.oliver@nokia-bell-labs.com;
x-originating-ip: [131.228.2.10]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: da8aa4ec-b088-4194-4cbb-08d75ec30349
x-ms-traffictypediagnostic: AM0PR0702MB3794:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <AM0PR0702MB3794FAB2BBF2867CCE191B408F620@AM0PR0702MB3794.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 020877E0CB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39860400002)(376002)(366004)(136003)(189003)(199004)(66066001)(14444005)(6306002)(76116006)(316002)(236005)(9686003)(74316002)(55016002)(19627405001)(64756008)(66446008)(66556008)(66476007)(54896002)(7736002)(66946007)(8676002)(256004)(476003)(71200400001)(33656002)(4326008)(486006)(71190400001)(966005)(6116002)(606006)(14454004)(25786009)(478600001)(3846002)(81156014)(99286004)(81166006)(52536014)(229853002)(6436002)(6246003)(5660300002)(86362001)(102836004)(26005)(2906002)(105004)(53546011)(186003)(6506007)(7696005)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR0702MB3794; H:AM0PR0702MB3746.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zchj3s/RVW+/ywKp/aJgSFkEdL7FCVRhVxfy6rJ8JDbs+K3njckhUKY5bOydiooj9HMt/VvJHuk3sdSnhbyOoubN6zdl2W1y/k4PySRgEX7mvAa2bRDu8GI/jZClbm9QsjifVDddWJn0NiYDYZRX5A81MhsFhtH20M01DJhbWRG4MfIEJxX3ZRzVNoBRlrMxKlBpZ/igFwiZTlWeCK+M7bVNm7vJdpQ5l2epqMsB+zRBk+lMCZAFs0UN1Rz8ScYYqy3IUYZCP570hTZ7sWFAuve2AeZobePC7nhRDxmhpOpxj7SciEGmEARebUVBya4R3mwBPChRzOJM+EhNdnka91IRUGnIFrIST3y7t2IquNwAqTvIGvAXleLNf2Uulg6zq25QHAJcoU8hYFjSsUBngeoFIyAFBTcgVxehqogiXgtC8pfgYw29aZj9zagxV9teRNUJaiRmVc385yl68tcu1cVCpGzy8o3Cgz9kou7vn0M=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR0702MB3746BF95CB34737BD034DD1A8F620AM0PR0702MB3746_"
MIME-Version: 1.0
X-OriginatorOrg: nokia-bell-labs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: da8aa4ec-b088-4194-4cbb-08d75ec30349
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2019 11:59:56.2383 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: N0sgYNNI+/5h/sv+X4iJC/tM69rUhDt+x6G8hKXDea/8yI8BHd0BQ0a6Q60m+6GbgfBNoSzStyNqB6s4r1hAmvXSh2C0vpgGZKWMjgrK8GQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3794
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/gkafMkSZfHdJoUGxA54B7FjcYWc>
Subject: Re: [Rats] Dynamic Systems in IETF RATS (was Re: 3 Use cases)
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: Fri, 01 Nov 2019 12:00:03 -0000

Hello Michael,

If think you got both cases perfect there...actually they are the two use cases we are working on, so...


But in both cases, regardless of the network, there is a requirement for some dynamicity in the "pre known" devices. So for a rail environment the set of devices (eg: wagons) is known and combinations of those could be precalculated. For a medical system it becomes much more difficult in that the set of devices will potentially change rapidly.

Thinking about these cases suggests to me that we would need t concentrate more on the introduction protocols between attestable device and attestor - more work to be done here

And yes, the nightmare scenario is one where Scotty has to wait for the attestation server

Ian



--

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Technical Staff

Nokia Bell Labs

+358 50 483 6237

________________________________
From: Michael Richardson
Sent: Monday, 07 October 2019 15:32
To: Oliver, Ian (Nokia - FI/Espoo)
Cc: rats@ietf.org
Subject: Dynamic Systems in IETF RATS (was Re: [Rats] 3 Use cases)


Oliver, Ian (Nokia - FI/Espoo) <ian.oliver@nokia-bell-labs.com> wrote:
    > Dynamic Systems

    > All current integrity mechanism assume a certain degree of fixed
    > properties, eg: TPM's CRTM/SRTM, and known configurations. A case
    > exists where a set of, say, IoT devices each with integrity
    > measurements are attested by some Edge node. The Edge node may combine
    > the IoT device measurements into a single measurement (eg: Merkel
    > Tree). If the configuration of IoT device changes, particuarly in
    > relation to availability of device, then this combined measurement will
    > change. This changed measurement however may be a valid configuration.

    > For example, in a medical case, the set of measurement devices may be
    > rapidly changing due to necessity of network provisioning, device
    > availabiltiy etc, but the permutations of devices may still be valid.

So you are describing a system where there is an assembly of devices.
I have a few questions and want to offer a two categories:
1) the network's view of the devices is transparent.  That is, each device
   in the assembly is reachable by the network either through L2-bridging,
   L3-routing (facilited maybe by DHCPv6-PD), or because all devices are
   just connected to the same "wifi" or LLN.

2) the network's view of the devices is opaque: the network only sees some
   gateway device and perhaps all interaction is via an application layer gateway.

Case (2) seems that the layer of indirection means the assembly
gateway/controller should probably be a relying party for the devices,
and should communicate it's configuration to an attester in order to validate
it's configuration.  The network would see the resulting attestion of the
aggregate.  I don't see anything surprising or new here. Just a recursive
application of RATS.

Case (1) is therefore the more interesting case, I think.
I imagine, yes, some health care situation where the assembly is the hospital
room, and the devices are the individual monitors.  The room needs to attest
to it's ability to deal/collect the correct/complete set of information, and
one can see that the failure (or the deplection) of some device leads to the
room being "unviable", and requiring attention.

I also was thinking about an assembly that is a passenger-rail coach arranged
in a set.  Each has a series of safety sensors that the engine must
interrogate directly. But, it's not necessary for every sensor in every coach
to be functional, as there is some redundancy, not just within each vehicle,
but also because there are multiple vehicles.

===

In thinking about this, I also thought of some sf movie (Expanse, Star Trek,
Star Wars), where sensors and sub-systems get blown up/overloaded, and need
to be patched.  Chewbacca is waiting for the attestation system to agree that
all parts are installed correctly, and Han and R2D2 are effecting repairs... A
very dynamical system; but you don't get to lightspeed until is sure it won't
just kill everyone onboard.  ...
Scotty: "Captain! I canna give you warp speed until the wee attestations settle."

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [