[Emu] Secdir early review of draft-ietf-emu-eap-noob-01

[Steve Hanna via Datatracker <[e-mail]>]

Reviewer: Steve Hanna
Review result: Not Ready

Reviewer: Steve Hanna
Review result: Not Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document defines a new EAP method for bootstrapping IoT devices.

After reading the document, I have many questions:

* Bootstrapping an IoT device involves many tasks that extend far beyond what
is accomplished by EAP-NOOB: configuring the services that the device
can/should employ within its new context (including how to reach and
authenticate them), the networks and protocols that it should use and how it
should obtain access to those networks, the access control policies that it
should use (who is permitted to access the device and what operations can they
perform), as well as many other configuration elements such as which lights a
switch should control. The current document does not specify how such things
are provisioned or even hint at this as an important problem. Without
specifying such things, only a tiny part of the IoT device configuration
problem has been solved. Perhaps another provisioning protocol could be used
after EAP-NOOB but that protocol would need to be specified. With this extra
step would come more complexity and user effort. Why not do this all with one
protocol?

* IoT device provisioning is not a new problem. In fact, it has been solved
hundreds of times. Most of those solutions are proprietary but some standards
efforts are ongoing now: IoTopia, FIDO IoT, Connected Home over IP, IP-BLiS,
etc. Why ignore these? Why not reach out and try to help them?

* This proposal assumes that the IoT device has a user interface (camera,
screen, etc.). What about those that don’t? Many small IoT devices do not have
a user interface of any sort or they only have a very primitive UI: a
temperature sensor, motion detector, wall switch, light bulb, circuit breaker,
etc.

* Won’t this protocol apply to a relatively small subset of the networks that
IoT devices will need to connect to? Few IoT networks run EAP. Mainly, EAP
seems to be used in cellular networks and enterprise Ethernet and Wi-Fi
networks. How will EAP-NOOB work in the Smart Home, where Wi-Fi is the most
common network type and EAP is not used?

* How will the device know which network to connect to, in the first place? At
most locations, there are many wireless networks. Do you envision the user
selecting from a list of Wi-Fi SSIDs and entering the network password with a
touchscreen and keypad? What about the small IoT devices that don’t have a
touchscreen and keypad? The server can’t help because the device is not yet
connected to the network.

* How will the user get OOB Output from the OOB sender to the OOB receiver? The
specification doesn’t seem to  As an IoT device maker, what am I supposed to
put into the instructions? Ask your local network administrator what to do?

* If the server indicates that it can handle peer-to-server OOB, what does that
mean? Must the server have a camera? If so, what is it expected to scan and
process? And if the peer prints out a page with a QR code, what should go into
the code? The same questions apply to OOB implemented with audio, flashing
LEDs, NFC, etc. In order to achieve interoperability, all of the details of
these OOB methods would need to be specified exactly. The current specification
includes no information like this. Without this information, multi-vendor
interoperability is highly unlikely. Even if each OOB method was fully
specified, consumers would still be frustrated if their server only supports QR
codes and their device only supports NFC or audio.

In my view, this protocol as currently specified is mainly of theoretical
interest. I could not recommend that the IETF adopt it as an RFC as it would
have almost no practical value.