Re: [Last-Call] Opsdir last call review of draft-ietf-suit-mud-06

[Hannes Tschofenig <[e-mail]>]

Hi Eliot,


thanks for the quick response.


That's good to hear but I haven't read how any error cases are reported
to some central device management system to take some actions.

Is that functionality documented somewhere as well? For example, some
YANG modules for use with Netconf?


Ciao

Hannes


Am 21.12.2023 um 11:35 schrieb Eliot Lear:
>
> Hi Hannes and thanks Sue
>
> The MUD Manager always has the responsibility to "consider the source"
> and then to consider the context.  The information provided in MUD
> files *can *be used to automate access control to their associated
> devices.  I think this is pretty well covered in RFC 8520, but I am
> starting to think about an update to that document.
>
> Eliot
>
> On 21.12.2023 11:08, Hannes Tschofenig wrote:
>> Hi Susan,
>>
>> thanks for your detailed review.
>>
>> You are correct that this document does not address operational
>> aspects of the MUD Manager and this is certainly something the OPSAWG
>> working group should address since this document is a tiny extension
>> to the already existing MUD RFC. Along these lines you are also
>> correct that the document does not define any mechanism for the MUD
>> Manager to notify the operator about any error situations with the
>> processing of MUD files and/or SUIT manifests. I will reach out to
>> Eliot and the OPSAWG working group to think about standardization
>> work in this direction.
>>
>> I have updated the draft to better explain how the different URIs are
>> passed around. I also added a figure to illustrate it graphically.
>> Attestation Evidence, which is used to convey information about the
>> MUD URL, also allows the network to double-check the
>> firmware/software (and other properties of the device). We didn't go
>> into any details about how Evidence is processed because this is part
>> of different documents, like the RATS architecture RFC. I hope the
>> updated text clarified these aspects.
>>
>> Regarding the CDDL I had a chat with Brendan and we will make an update.
>>
>> Ciao
>> Hannes
>>
>>
>> Am 04.12.2023 um 16:19 schrieb Susan Hares via Datatracker:
>>> Reviewer: Susan Hares
>>> Review result: Has Issues
>>>
>>> Overall comment:
>>> Qualifications: I am not an expert on SUIT implementations or an
>>> operator of
>>> networks using SUIT. Therefore, my issues may be covered by some
>>> general
>>> security considerations in a document I am not aware of.
>>>
>>> General comments to authors:  This feature is clearly described in this
>>> document. Brendan and Hannes did an excellent job of writing the
>>> document.
>>>
>>> Security/Operational Issues:
>>>
>>> The security of MUD URLs may move the attacks from individual
>>> devices to the
>>> MUD Manager. (Instead of a single lemming going over the cliff, a
>>> MUD manager
>>> may send many lemmings over the cliff). This document does not seem
>>> to consider
>>> the operational issues in the MUD Manager or provide mechanisms on
>>> how to check
>>> for these attacks (e.g. Yang modules with operational state).
>>>
>>> 1. An Attack on the MUD Manager can shut down or subvert the entire
>>> network.
>>>
>>> It is not clear how the operator knows an attack on the MUD Manager
>>> is happening
>>> or occurred. If the MUD Manager pulls in broken SUIT manifests and
>>> then pulls in broken software/firmware based on the SUIT manifests
>>> how does the operator know?  In other words what device watches
>>> that the MUD Manager is not subverted via a management protocol?
>>>
>>> I do not see any operational state in the MUD Yang module [RFC8620
>>> section 2.1]
>>> It would seem natural to have some operational state in the MUD
>>> Manager reports
>>> manifest state. Yang's notif protocols could report any manifest
>>> state change
>>> (over secure TLS connections) to a centralized security server.
>>>
>>> 2. For secure URLs transmitted by 802.1X with certificates,
>>> Why are these not a "double-check" on the validity of the software?
>>>
>>> Again, it would seem natural to utilize these secure certificates as
>>> "double-checks" on the MUD Manager being "in-sync"  with the devices.
>>>
>>> 3. As a less secure double-check on being "in-sync", is the
>>> reporting of
>>>   MUD URL sent via MUD Devices via DHCP or LLDAP that is not what is
>>> in the
>>>   manifest.
>>>
>>> These reporting features are useful in transition scenarios as well as
>>> detecting attacks on the MUD manager.
>>>
>>> Editorial nits:
>>>
>>> 1. section 1, last paragraph, sentence 2
>>>
>>> Old text: /can get/
>>> New text: /has/
>>>
>>> English grammar
>>>
>>> 2. Just for my sanity, would you check the following text is correct
>>>
>>> $$SUIT_severable-members-extensions //= (
>>>    suit-manifest-mud => bstr .cbor SUIT_MUD_container
>>> )
>>> It appears you are looking to define a CBOR Type for the
>>> the SUIT_MOD_container is defined in the text.
>>>
>>> What I think I'm missing is the .cbor value for SUIT.
>>> It looks correct, but I could  not derive this from
>>> draft-ietf-suit-manifest-24:
>>>
>>> SUIT_Severable_Manifest_Members = (
>>>    ? suit-payload-fetch => bstr .cbor SUIT_Command_Sequence,
>>>    ? suit-install => bstr .cbor SUIT_Command_Sequence,
>>>    ? suit-text => bstr .cbor SUIT_Text_Map,
>>>    * $$SUIT_severable-members-extensions,
>>> )
>>>
>>> And your IANA definitions of:
>>>
>>> IANA is requested to add a new value to the SUIT envelope elements
>>> registry
>>> created with [I-D.ietf-suit-manifest]: Label: TBD2 [[Value allocated
>>> from the
>>> standards action address range]]
>>>
>>> Name: Manufacturer Usage Description (MUD)
>>> Reference: [[TBD: This document]]
>>>
>>> Again, this may be due to my incomplete understanding.
>>> This is why this is a NIT rather than an Issue.
>>>
>>>
>>>
>>