Re: [Rats] retrieving reference measurements

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Thu, 30 April 2020 07:32 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 AB7E63A0A53 for <rats@ietfa.amsl.com>; Thu, 30 Apr 2020 00:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 K8HI9fXfzbvn for <rats@ietfa.amsl.com>; Thu, 30 Apr 2020 00:32:06 -0700 (PDT)
Received: from mail-edgeDD24.fraunhofer.de (mail-edgeDD24.fraunhofer.de [192.102.167.24]) (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 D80EA3A0A8C for <rats@ietf.org>; Thu, 30 Apr 2020 00:32:04 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2GJAQBkpYde/xmnZsBmGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF7gilsA1UvKgqEEY55gWQtiW6PcoFfCAoBAQEBAQEBAQEGAQEYCwoCBAEBAoFOgnQCgkckOBMCEAEBBgEBAQEBBQQCAmmFVgyDU34BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ8CDTYeNxIBAR0BAQEBAwEBIQ8BBTYLDAQJAhEEAQEBAgIjAwICIQYfAQgIBgEMAQUCAQEXgwsBgksDLgQLkz+bBHWBMoRJQUGCeA1igTgGgQ4qjDEPgUw/gREnD4JaPoIeSQEBAwGBLAESAQmDKoJeBI12RIJFhieYTldHB4FJd3wEhm+FXIUfhDUjgkyMaQWMRo8ygVKHUYI8kD4CBAIJAhWBaSNncE0kT4JpUBgNjikXg1CFFIVDcgKBJ40ZAYEKBQEB
X-IPAS-Result: A2GJAQBkpYde/xmnZsBmGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF7gilsA1UvKgqEEY55gWQtiW6PcoFfCAoBAQEBAQEBAQEGAQEYCwoCBAEBAoFOgnQCgkckOBMCEAEBBgEBAQEBBQQCAmmFVgyDU34BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ8CDTYeNxIBAR0BAQEBAwEBIQ8BBTYLDAQJAhEEAQEBAgIjAwICIQYfAQgIBgEMAQUCAQEXgwsBgksDLgQLkz+bBHWBMoRJQUGCeA1igTgGgQ4qjDEPgUw/gREnD4JaPoIeSQEBAwGBLAESAQmDKoJeBI12RIJFhieYTldHB4FJd3wEhm+FXIUfhDUjgkyMaQWMRo8ygVKHUYI8kD4CBAIJAhWBaSNncE0kT4JpUBgNjikXg1CFFIVDcgKBJ40ZAYEKBQEB
X-IronPort-AV: E=Sophos;i="5.72,341,1580770800"; d="scan'208";a="31509795"
Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeDD24.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Apr 2020 09:32:01 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B7DQCxfqpe/1lIDI1mHAEBAQEBAQcBARIBAQQEAQFAgUeCKm4DVDAqCoQXjnqBZC2Jdo99gWcLAQMBAQEBAQYBARgLCgIEAQGBUIJ0AoItJDgTAhABAQUBAQECAQUEbYUqASsMhXEBAQEBAwEBIQ8BBTYLDAQJAhEEAQEBAgIjAwICIQYfAQgIBgEMAQUCAQEXgwsBgksDMguXIZsDdoEyhE1BQoJyDWKBOgaBDiqMQQ+BTD+BEScPglo+gh5JAQEDAYEsARIBCYMqgmAEjiVEglKGOZkdWkoHgUt9fwSHEIV2hTaEQiOCW40nBY0AkAWBV4d0gkWQfQIEAgkCFYFpImZwTSRPgmlQGA2PEB+DGBeDT4UUhURBMQI0AgYBBwEBAwl8kF4BgQoFAQE
X-IronPort-AV: E=Sophos;i="5.73,334,1583190000"; d="scan'208";a="81353464"
Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Apr 2020 09:31:34 +0200
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 03U7VV3q013149 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Thu, 30 Apr 2020 09:31:31 +0200
Received: from [192.168.16.50] (79.234.123.239) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 30 Apr 2020 09:31:25 +0200
To: "Panwei (William)" <william.panwei@huawei.com>, Guy Fedorkow <gfedorkow@juniper.net>
CC: "rats@ietf.org" <rats@ietf.org>, William Bellingrath <wbellingrath@juniper.net>, Jessica Fitzgerald-McKay <jmfmckay@gmail.com>
References: <DM6PR05MB68895483D6F508C46748147FBAAD0@DM6PR05MB6889.namprd05.prod.outlook.com> <96c6bf0f-024d-972e-333f-edd288f3920f@sit.fraunhofer.de> <DM6PR05MB6889C3D6B8C636C2AD30D51FBAAD0@DM6PR05MB6889.namprd05.prod.outlook.com> <7a3b2b24-3dca-202b-fb83-3af52be25ee5@sit.fraunhofer.de> <a36018ab556c47aba8f14e36ce5fcdad@huawei.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <318fe49a-40f9-d822-6ce8-015f0728f84b@sit.fraunhofer.de>
Date: Thu, 30 Apr 2020 09:31:24 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <a36018ab556c47aba8f14e36ce5fcdad@huawei.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.123.239]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/qmVu5y6OqzjbuTEkGBY7uBlRr_E>
Subject: Re: [Rats] retrieving reference measurements
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, 30 Apr 2020 07:32:11 -0000

Hi Wei,
hi Guy,

it is relatively easy to include RIM (or as Dave highlighted we should 
fall back to Reference Values (Manifests) RVM) in software updates. I 
think there is wild agreement there. I think that is not the question, 
the question is how to retrieve them from the Attester and one option 
discussed are YANG management interfaces:

As a test, I tried to model (Co)SWID as YANG once 
(https://datatracker.ietf.org/doc/draft-birkholz-yang-swid/):

RIM/RVM can become quite big. Every reference value wrt to file 
integrity requires a file identifier that is applicable to file 
integrity measurements conducted by the Attester. Typically, a path and 
a file name are used (which apparently implies the existence of a 
file-system). Due to the volume of measurements, absolute path names 
create high redundancy in a RIM/RVM. (Co)SIWD address this issue by 
recreating a directory tree structure in the representation itself and 
therefore eliminating redundant segments in path notations.

But - this requires the named type "directory" to be nested in the named 
type "directory" in order to construct that tree. That is possible in 
XML and CBOR, but not in YANG modeled data. In YANG, a circular use of 
statements (via groupings) is not allowed. Hence, it is not possible to 
use this "optimization" applied in (Co)SWID. The alternative is to 
fall-back to absolute paths and create an even larger volume of YANG 
model data.

This would also break simple interoperability between YANG-SWID and 
(Co)SWID. It is not impossible - but at the moment I have doubts that it 
is feasible, though (and I arrived at the conclusion by trying to create 
a corresponding YANG module).

If the module in draft-birkholz-yang-swid is acceptable (in general, 
details might still to be fixed) including the absolute path notation it 
uses, then we can revive that I-D.

It's not that I did not thought about your proposal here already, I just 
thought it was not viable enough.

Viele Grüße,

Henk

On 30.04.20 04:59, Panwei (William) wrote:
> Hi Henk, Guy,
> 
> I think the key point is that the YANG-modeled reference measurements or the YANG-modeled RIM should be defined. I also suggested this in my comments on draft-birkholz-rats-mud. I think there are two main reasons:
> 
> 1) draft-birkholz-rats-coswid-rim defined the CoSWID-styled reference measurements. Meanwhile, draft-birkholz-rats-mud defines a YANG-modeled URI pointing at the reference measurements. So, by combining the two ideas together, the YANG-modeled reference measurements or YANG-modeled RIM can be defined directly in the MUD File. This way has an advantage that the Verifiers that only support YANG don't need to support CoSWID and do more implementation.
> 
> 2) There is a use case that the reference measurements (signed by the vendor) can be stored at the network devices. In this case, the reference measurements can be retrieved by the Verifier via the YANG / NETCONF interface. Henk's concern is how to update the reference measurements when the network devices update, and Guy's suggestion is that the new reference measurements (also signed by the vendor) can be part of the vendor's software update package.
> I agree with Guy that this is a reasonable use case, and there is a doable solution. (Besides, I also think this path for delivering reference measurements can be used by other devices as well.) Therefore, for the network devices that use the YANG / NETCONF interface, the YANG-modeled reference measurements or YANG-modeled RIM should be defined. And Guy proposed to define the YANG-modeled reference measurements in DraftC.
> 
> So I think the YANG-modeled reference measurements are worthy to be defined, in draft-rats-mud or draft-charra or an independent draft.
> 
> Regards & Thanks!
> Wei Pan
> 
>> -----Original Message-----
>> From: RATS [mailto:rats-bounces@ietf.org] On Behalf Of Henk Birkholz
>> Sent: Thursday, April 30, 2020 12:30 AM
>> To: Guy Fedorkow <gfedorkow@juniper.net>
>> Cc: rats@ietf.org; William Bellingrath <wbellingrath@juniper.net>; Jessica
>> Fitzgerald-McKay <jmfmckay@gmail.com>
>> Subject: Re: [Rats] retrieving reference measurements
>>
>> Hi Guy,
>>
>> I think I misunderstood the intend of your initial question. I thought it was a
>> "network isolation" question, but it is a "conveyance method"
>> question, I think.
>>
>> CoSWID RIM tags use (and extend, actually), the payload-entry and
>> therefore can be bundled in corresponding software/firmware packages
>> that are updates. This is the reason why they are used in SUIT Manifests, too.
>>
>> If they are not included in a software package, they can be referred to via a
>> MUD ULL / MUD File. MUD is simply a straight forward option to...
>> point at device specific things. It is certainly not meant to be constraining
>> options, it adds a increasingly popular one.
>>
>> Viele Grüße,
>>
>> Henk
>>
>>
>>
>> On 29.04.20 18:19, Guy Fedorkow wrote:
>>> Hi Henk,
>>>     I understand that third-party RIMs could be used, but for embedded
>>> equipment, it seems like the easiest path is to deliver the RIMs as
>>> part of the vendor's software update package for the device.
>>> Operators have well-worn procedures for getting software updates to
>>> devices; if the RIM is just part of the package, they don't have to
>>> think about a new procedure at all...
>>>     Maybe not for everyone, but it seems like it would be a common
>> use-case...
>>> Thanks
>>> /guy
>>>
>>>
>>>
>>> Juniper Business Use Only
>>>
>>> -----Original Message-----
>>> From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
>>> Sent: Wednesday, April 29, 2020 11:29 AM
>>> To: Guy Fedorkow <gfedorkow@juniper.net>
>>> Cc: rats@ietf.org; Jessica Fitzgerald-McKay <jmfmckay@gmail.com>;
>>> William Bellingrath <wbellingrath@juniper.net>
>>> Subject: Re: retrieving reference measurements
>>>
>>> [External Email. Be cautious of content]
>>>
>>>
>>> Hi Guy,
>>>
>>> I think it would be strange for a network equipment device to expose a
>>> potentially vulnerable management to the open internet, too :)
>>>
>>> Luckily, there will probably be a "higher level" constituent in the
>>> network that an Attester's DevID can be presented to (typically this
>>> is or is close to a device that is also a Verifier). And these systems
>>> generally have a way to "reach out" to the internet.
>>>
>>> The typically already existing "path" to follow here is the way
>>> updates find their way to a "network equipment device". If you are
>>> air-gap'ed or completely isolated wrt every layer 2 topology, it may
>>> start to become a bit tricky, but your are running around with usb
>>> sticks in hand to do updates then, too.
>>>
>>> YANG is a big solution for big problems. But you can use a YANG server
>>> to retrieve RIM that are stored on the Attester itself, of course.
>>> These probably are outdated at some point and then leave you with the
>>> same illustrated above, again.
>>>
>>> Viele Grüße,
>>>
>>> Henk
>>>
>>>
>>> On 29.04.20 15:56, Guy Fedorkow wrote:
>>>> Hi Henk,
>>>>
>>>> I see your proposal for identifying URIs for reference measurements
>>>> in
>>>> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-birkhol
>>>> z
>>>>
>> -rats-mud-00__;!!NEt6yMaO-gk!WdyQ3vQ51adw93UKoSwWvgPFs4395vPI
>> WLjuzRBi
>>>> F
>>>> gldobaQ_dLIeFbhOWan0kBLDLY$
>>>>
>>>>      I realize that some constrained devices may not want to do this,
>>>> but do you think draft-charra could be extended to allow retrieval of
>>>> the signed reference measurements directly from the device being
>>>> attested, via the YANG / Netconf interface?
>>>>
>>>>      Ironic as it may sound, I'm sure you know that many operators
>>>> ensure that their internet routers cannot access the public internet.
>>>>
>>>>      Thanks,
>>>>
>>>> /guy
>>>>
>>>>
>>>> Juniper Business Use Only
>>>>
>>
>> _______________________________________________
>> RATS mailing list
>> RATS@ietf.org
>> https://www.ietf.org/mailman/listinfo/rats