Skip to main content

Early Review of draft-richardson-mud-qrcode-02
review-richardson-mud-qrcode-02-iotdir-early-jimenez-2021-11-25-00

Request Review of draft-richardson-mud-qrcode-02
Requested revision 02 (document currently at 07)
Type Early Review
Team Internet of Things Directorate (iotdir)
Deadline 2021-12-10
Requested 2021-11-24
Requested by Adrian Farrel
Authors Michael Richardson , Jacques Latour , Hassan Habibi Gharakheili
I-D last updated 2021-11-25
Completed reviews Iotdir Early review of -02 by Jaime Jimenez (diff)
Opsdir Early review of -02 by Joel Jaeggli (diff)
Comments
This document has been presented for publication in the Independent Stream.
The OPSAWG is a potential home for the document, but the WG chairs have indicated that there is no support to spend WG time on it.

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.
Assignment Reviewer Jaime Jimenez
State Completed
Request Early review on draft-richardson-mud-qrcode by Internet of Things Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/iot-directorate/jB7C-IzhLPAMD-bY-K2I8it9TeE
Reviewed revision 02 (document currently at 07)
Result On the Right Track
Completed 2021-11-25
review-richardson-mud-qrcode-02-iotdir-early-jimenez-2021-11-25-00
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