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

From: Jaime Jimenez via Datatracker <[email-masked]>
Date: Thu, 25 Nov 2021 01:34:50 -0800

Reviewer: Jaime Jimenez
Review result: On the Right Track

Dear authors,

As per the IoT Dir request I will be providing a first review of
draft-richardson-mud-qrcode-02.

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.

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
moment, for example I am not familiar enough with LLDP or with how WLAN attach
process but I think access points are supposed to know the MAC during the
authentication process. The document focuses on how the MUD could be expressed
as a SQRL code. I am not an expert on SQRL so I take it that the contents of
Section 3.2 are correct. When the MAC is not included on the MUD URL then the
assumption is that the network administrator is the one with physical access to
the devices and can create the relevant policies. This comes with the caveat of
what is then the purpose of the QR code if manual configuration is needed
anyways.

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. Section 7 lists some of the attacks but I do not
know if it is an exhaustive list, we probably should have a big disclaimer on
the use of this devices and differentiate on the use cases (home, university,
etc) as they have different deployment processes.

I could not find editorial issues but I admit I was not terribly thorough in
the review. I am missing MUD URL examples and more details on how the MUD
controller operates when a MAC matching a scanned QR code arrives, perhaps that
is part of another draft?

As per request of the ISE:

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

Ciao!
--
Jaime Jiménez

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Nov 2021 08:39:03 -0500

> draft-richardson-mud-qrcode-02.

Thank you for the review!

    > specialist that scans the code and transmits the URL from the phone device to

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.

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

    > 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 QR code, but they have been described in the Security section.

Wunderbar.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Jaime Jiménez <[email-masked]>
Date: Wed, 01 Dec 2021 08:25:42 +0200

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:
> Attachments:
> * signature.asc