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

[Eliot Lear <[e-mail]>]

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