Subject: [Rats] retrieving reference measurements

From: Guy Fedorkow <[email-masked]>
Date: Wed, 29 Apr 2020 13:56:28 +0000

Hi Henk,

I see your proposal for identifying URIs for reference measurements in
https://tools.ietf.org/html/draft-birkholz-rats-mud-00

  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

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 29 Apr 2020 17:29:21 +0200

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:
>    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
> 
>

---

From: Guy Fedorkow <[email-masked]>
Date: Wed, 29 Apr 2020 16:19:13 +0000

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

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Wednesday, April 29, 2020 11:29 AM
To: Guy Fedorkow <[email-masked]>
Cc: [email-masked]; Jessica Fitzgerald-McKay <[email-masked]>; William
Bellingrath <[email-masked]>
Subject: Re: retrieving reference measurements

[External Email. Be cautious of content]

Hi Guy,

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:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-birkholz
> -rats-mud-00__;!!NEt6yMaO-gk!WdyQ3vQ51adw93UKoSwWvgPFs4395vPIWLjuzRBiF
> 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
>
>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 29 Apr 2020 18:29:37 +0200

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 29 Apr 2020 18:36:04 +0200

Hi Guy,

> On 29 Apr 2020, at 15:56, Guy Fedorkow <gfedorkow=[email-masked]> wrote:
> 
> Hi Henk,
> I see your proposal for identifying URIs for reference measurements in https://tools.ietf.org/html/draft-birkholz-rats-mud-00 <https://tools.ietf.org/html/draft-birkholz-rats-mud-00>
> 
>   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?

If you can get this information in, then my suggestion would be to drop it into a MUD file a’la draft-moran-suit-mud-00.txt.

Eliot

>   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
> 
> 
> _______________________________________________
> RATS mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: "Panwei (William)" <[email-masked]>
Date: Thu, 30 Apr 2020 02:59:53 +0000

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

> From: RATS [mailto:[email-masked]] On Behalf Of Henk Birkholz
> Sent: Thursday, April 30, 2020 12:30 AM
> Cc: [email-masked]; William Bellingrath <[email-masked]>; Jessica
> Fitzgerald-McKay <[email-masked]>
> 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.
> 
> 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
> 
> 
> 
> > 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...
> > Cc: [email-masked]; Jessica Fitzgerald-McKay <[email-masked]>;
> > William Bellingrath <[email-masked]>
> > 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
> > 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.
> >
> > 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
> >
> >
> -rats-mud-00__;!!NEt6yMaO-gk!WdyQ3vQ51adw93UKoSwWvgPFs4395vPI
> WLjuzRBi
> >> F
> >>     Ironic as it may sound, I'm sure you know that many operators
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 30 Apr 2020 09:31:24 +0200

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