Subject: [secdir] Secdir early review of draft-ietf-emu-eap-noob-01

From: Steve Hanna via Datatracker <[email-masked]>
Date: Sun, 28 Jun 2020 16:54:43 -0700

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.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 28 Jun 2020 21:43:34 -0400

> Review result: Not Ready

Steve thanks for the great review!
I wanted to respond as an IoT onboarding expert and EMU WG member.

    > can/should employ within its new context (including how to reach and

Hi, so your comments are well taken, but it's really an unreasonably high
standard.  While it is really important to get the configuration mechanisms
in place, they are even more diverse than onboarding.
That's an entire ocean of disagreement here.
I would certainly love to get a handle on this.
When it comes to standardization, really have to be very selective on how big
a thing to bite off.  I think that we can incrementally get to this, but
first we need some success with getting even one onboarding spec working.

So I don't think it's reasonable to evaluate EAP-NOOB (or BRSKI-TEEP) by this critiera.

    > etc. Why ignore these? Why not reach out and try to help them?

Well, of those groups, many of them are completely pay-to-play fora, and do
all of their work behind closed doors. In many cases, they look to the IETF
for components, such as EAP-NOOB, BRSKI, etc. that they can incorporate into
their designs.  Some are actively hostile towards an an actual written
standard, preferring that everyone license a particular software stack instead.
I think that EAP-NOOB has benefited greatly from academic and industrial review.

    > screen, etc.). What about those that don’t?

Yup. Some don't, and you need to do something else.
But, a lot of devices *do* have displays.
Think about any industrial or hospital instrument.
They all go "ping", and have a cool display to put a graph on :-)

    > IoT devices will need to connect to? Few IoT networks run EAP.

EAP is very popular in industrial and enterprise situations.
EAP can be easily introduced into home network, with the Authentication
Server running locally.  Many have done this, and it is supported in Openwrt today.

    > * How will the device know which network to connect to, in the first
    > place?

This is a good question, and I can offer no answer for the EAP-NOOB case, and
I leave it to the authors to respond to your other comments.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-