Re: [Rats] retrieving reference measurements

["Shwetha Bhandari (shwethab)" <[e-mail]>]

Henk's questions on viability of yang modelling of the RIM so that a verifier can query it using existing Netconf/RESTconf interfaces seem very valid.

In addition, Data model for RIM (Yang/CDDL) seem to be orthogonal to how the actual RIM is represented (XML/JSON/CBOR) and signed by the endorser. 
Are we suggesting that an endorser create multiple representation of RIM and sign it and make it available in the Software image/patch on the attester along with publishing it elsewhere?

Thanks,
Shwetha

On 4/30/20, 1:02 PM, "RATS on behalf of Henk Birkholz" <[e-mail] on behalf of [e-mail]> wrote:

    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:[e-mail]] On Behalf Of Henk Birkholz
    >> Sent: Thursday, April 30, 2020 12:30 AM
    >> To: Guy Fedorkow <[e-mail]>
    >> Cc: [e-mail]; William Bellingrath <[e-mail]>; Jessica
    >> Fitzgerald-McKay <[e-mail]>
    >> 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 <[e-mail]>
    >>> Sent: Wednesday, April 29, 2020 11:29 AM
    >>> To: Guy Fedorkow <[e-mail]>
    >>> Cc: [e-mail]; Jessica Fitzgerald-McKay <[e-mail]>;
    >>> William Bellingrath <[e-mail]>
    >>> 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
    >> [e-mail]
    >> https://www.ietf.org/mailman/listinfo/rats
    
    _______________________________________________
    RATS mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/rats