Re: [Iot-directorate] Iotdir early review of draft-richardson-mud-qrcode-02

[Jaime Jiménez <[e-mail]>]

Thanks for the prompt reply Michael! 
I have no additional comments on this.

Ciao!
-- 
Jaime Jiménez

On Thu, Nov 25, 2021, at 3:39 PM, Michael Richardson wrote:
> Jaime Jimenez via Datatracker <[e-mail]> wrote:
>     > As per the IoT Dir request I will be providing a first review of
>     > draft-richardson-mud-qrcode-02.
>
> Thank you for the review!
>
>     > To my understanding the aim of the document is to provide the MUD 
> URL as a QR
>     > code for devices that do not have MUD support. From the 
> deployment point of
>     > view I suppose the process would be done for example via a 
> deployment
>     > specialist that scans the code and transmits the URL from the 
> phone device to
>     > the MUD Controller.
>
> yes, it might also occur in the asset management group, which for instance,
> receives devices in boxes, adds them to their asset management database, and
> then prints some "This device owned by Example Corp, asset tag 234589234"
> stickers and affixes them.  This is one of the purposes of the RLA QR codes.
>
>     > As per 3.2.5 in some cases the MUD URL contains also the MAC of 
> the device so
>     > that when the device connects, the network will recognise it (for 
> example when
>     > using ARP or DHCP). That latter part by the way is a bit 
> undefined at
>
> The detail here is difficult as it depends upon how the asset database is
> integrated with the DHCP, and ultimately, with the MUD controller.
> In the worse case, there would be copy and pasting from one system to
> another, but that would get better as this this goes on.
> No integration with ARP, DHCP or LLDP is required, as the device probably
> does not put it's MUD URL into DHCP or LLDP if it has the URL on the outside.
> (but that might change over time)
>
>     > A naive attacker could read the QR code that contains the MAC, 
> change its own
>     > MAC to that of the QR code and then impersonate the device 
> effectively
>     > blacklisting that MAC address and preventing the actual device 
> from attaching
>     > to the network in the future.
>
> Yes, I suppose that this is an attack.
> To do it, the attacker must have credentials that let it onto the network in
> the first place.   Maybe that involves just plugging a cable in to an empty
> port.
> At which point, they could do all sorts things too.
> If the network has 802.1x controls (such as EAP-Enterprise), then the network
> would really have already defended itself against that.
>
>     > "The ISE would appreciate reviews from IoT and Operations experts 
> to gather
>     > opinions on the document. In particular, the ISE would like to 
> know whether
>     > publicaiton would be a bad idea or could be harmful to the 
> Internet."
>
>     > I personally do not see any specific items on this draft that 
> could be harmful
>     > to the general Internet. Some security issues are evident and 
> affect the use of
>     > the QR code, but they have been described in the Security section.
>
> Wunderbar.
>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>
> Attachments:
> * signature.asc