Early Review of draft-ietf-emu-eap-noob-01

Request Review of draft-ietf-emu-eap-noob-01
Requested rev. 01 (document currently at 02)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2020-06-30
Requested 2020-06-02
Requested by Mohit Sethi
Authors Tuomas Aura, Mohit Sethi
Draft last updated 2020-06-28
Completed reviews Iotdir Early review of -01 by Dave Thaler (diff)
Secdir Early review of -01 by Steve Hanna (diff)
Assignment Reviewer Steve Hanna
State Completed
Review review-ietf-emu-eap-noob-01-secdir-early-hanna-2020-06-28
Posted at https://mailarchive.ietf.org/arch/msg/secdir/4tC9mLfHqhsVihoub9CJ1h2nH48
Reviewed rev. 01 (document currently at 02)
Review result Not Ready
Review completed: 2020-06-28


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.