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

[Mohit Sethi M <[e-mail]>]

Hi Steve,

I have answered each question in-line.

On 6/29/20 2:54 AM, Steve Hanna via Datatracker wrote:
> 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?

That's not how the Internet or standardization works.

Why stop here with the requirements. Maybe EAP-NOOB should also address 
how the software on these devices is updated since that is a necessary 
precursor to updating the elliptic curves used by the protocol. Maybe 
EAP-NOOB should also ensure quantum resistance since quantum computers 
will be available any day. Maybe EAP-NOOB should also periodically 
provide verifiable device health reports after the initial configuration 
is complete.

The point I am trying to make here is that there needs to be a careful 
balance between salami style protocol knick knacks that don't fit 
together and a gargantuan all encompassing protocol that is never 
completed (or deployed).

There are over 52 EAP authentication methods. Can you name one which 
also provisions access control policies for resources on the peer 
device. The answer would be a clear no. There is a reason for that. We 
have other protocols to deal with access control policies. For IoT 
devices, we have ACE (Authentication and Authorization for Constrained 
Environments: https://datatracker.ietf.org/wg/ace/charter/) doing that 
work.

You talk about configuring what protocols the IoT device should use 
after obtaining initial network connectivity? I wonder what kind of 
imaginary IoT devices have multiple protocols implemented (for doing the 
same job) that would require some sort of selection.

EAP-NOOB does export a AMSK after successful authentication. Whether 
this AMSK is used for configuring access control policies or for 
protecting higher-layer protocols is up to other protocol specifications 
and device developers. EAP-NOOB also includes exchange of protected 
ServerInfo and PeerInfo JSON objects that can supply deployment specific 
configuration information. Appendix C 
(https://tools.ietf.org/html/draft-ietf-emu-eap-noob-01#appendix-C) even 
suggests that servers can provide a list of SSIDs to the peer that it 
can successfully connect to later on.

>
> * 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?

You missed Device Provisioning Protocol (DPP), Amazon Frustration Free 
Setup (https://developer.amazon.com/frustration-free-setup). I sincerely 
hope you have posed the same question of outreach to all them. I 
obviously cannot control (or participate) in all those other standards 
bodies. The fact that there are many people working in this area only 
proves that this is relevant problem and that there is no definite 
solution (not that I expect a single protocol to rule the entire world). 
The EMU working group was chartered to 
(https://datatracker.ietf.org/group/emu/about/) "Define a standard EAP 
method for mutual authentication between a peer and a server that is 
based on an out-of-band channel. The method itself should be independent 
of the underlying OOB channel and shall support a variety of OOB 
channels such as NFC, dynamically generated QR codes, audio, and visible 
light.". The fact that EAP-NOOB can also be used for bootstrapping IoT 
devices is a fringe benefit.

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

Others protocols assume manufacturer provided servers, smartphone 
applications, Certification Authorities (CA), cryptographic hardware 
modules, blockchains, sales channel integration, secure supply chains, 
secure printed stickers etc. What about those devices and users that 
cannot (or do not want to) rely on such dependencies. Ultimately you 
have to pick your poison. EMU chose to explicitly work with dynamic OOB 
messages given the fewer dependencies and added security benefits.

>
> * 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?

As a conscientious engineer/technologist and the chair of EMU, I refuse 
to invest my career in bad, broken, and insecure technologies that 
should have died a long time ago. If someone in this day and age still 
feels that they should work on a protocol where all devices in the 
network share the same secret (Wi-Fi shared passphrase), they are free 
to do so. I would rather spend my time on how to make EAP more usable 
(and easy to deploy) in all networks (including home networks). EAP was 
originally intended for all networks (and not the small subset you refer 
to) with original RFCs dating back to mid 1990s. Unfortunately, the 
community at that time decided that network-wide shared secrets is an 
acceptable short-term fix.

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

This is a valid problem (but irrelevant for any EAP method). 
Nonetheless, I understand it is important to know how the protocol would 
work in real deployments.

If EAP-NOOB is implemented on a UI rich device (such as a laptop) users 
can naturally select their network.

When EAP-NOOB is used on device with no obvious UI to select the 
network, an EAP-NOOB implementation can run a discovery script 
(https://github.com/tuomaura/eap-noob/blob/dev_0.1/wpa_supplicant-2.6/wpa_supplicant/wpa_auto_run.py) 
that allows the peer device to perform initial exchange with all 
potential networks and generate several OOB messages. The user will then 
choose one and deliver it to his server (this would be akin to user 
selecting his network from a list). Obviously, the number of OOB 
messages would grow to an unreasonable amount if there are many networks 
in the vicinity.

This by no means is the only (or ideal) solution but it should give you 
a good idea of what to expect. There have been discussions on how the 
network could provide hints to un-configured devices.  Eliot Lear has 
some ideas on solving this problem with bloom filters so we might see 
improvements in the near future. Thankfully, network selection can be 
improved independently of the EAP method.

Let us also compare this with how other standards deal with the problem 
of network selection. Many simply assume that there is only network in 
the vicinity of the device when it is turned on. Such an assumption 
isn't reasonable in many scenarios. Zigbee IP specification section 6.4 
"Network Selection" discusses several alternatives including a) “Allow 
Join" flag is added to network beacons. New un-configured devices 
examine this flag before initiating a connection attempt; b) user 
selection of network from a list; and c) joining node is pre-configured 
with information about the network which it should join.

>
> * 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?

The OOB channel used by the device doesn't depend on the network where 
it is deployed. The OOB channel only depends on the device UI that the 
vendor adopts. So the instruction could be:  scan a QR code when one is 
shown on the peer device, point the camera to the LED light on the peer 
device when it starts blinking, or show the QR code to the camera of the 
peer device.

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

This would definitely be the wrong way to do standardization. Firstly, 
because there are many different OOB channels. Many of them have no 
standards (sending data over audio example or a small blinking LED). 
Some of them have competing standards (communication over visible light: 
IEEE 802.15.7, OpenVLC, JEITA CP-1221).

EAP-NOOB only standardizes what data needs to be communicated over the 
OOB channel. How the OOB channel is implemented is up to the device 
vendor and the channel they adopt. You are also misinterpreting that the 
server needs to support OOB channels like NFC. Let me explain how this 
is done in a real implementation (https://github.com/tuomaura/eap-noob):

- The EAP peer and server is implemented inside standard wpa_supplicant 
(https://github.com/tuomaura/eap-noob/tree/dev_0.1/wpa_supplicant-2.6) 
and hostapd 
(https://github.com/tuomaura/eap-noob/tree/dev_0.1/hostapd-2.6) software 
packages. The initial exchange, waiting exchange, and completion 
exchange is implemented as defined in the specification.

- A separate piece of software on the peer (python script: 
https://github.com/tuomaura/eap-noob/blob/master/wpa_supplicant-2.6/wpa_supplicant/wpa_auto_run.py) 
generates a QR code and shows it in on the device's display. The QR code 
contains a URL with the OOB message as a query string. A separate piece 
of software on the server (nodejs: 
https://github.com/tuomaura/eap-noob/tree/dev_0.1/nodejs) receives the 
OOB message when the QR code is opened. These pieces of software 
interact with the wpa_supplicant and hostapd via sqlite tables (although 
a nice API would have been better).

Thus, the parts of the implementation responsible for transferring the 
OOB message can be simply be drop-shipped (substituted) without 
interfering with the EAP-NOOB peer and server. As an example, instead of 
showing a QR code, the peer outputs a NFC message (see function 
'send_via_NFC' 
https://github.com/tuomaura/eap-noob/blob/dev_0.1/wpa_supplicant-2.6/wpa_supplicant/wpa_auto_run.py), 
which is read by Android application 
(https://github.com/tuomaura/eap-noob/tree/dev_0.1/EAPNOOBWebView) and 
sent to the same nodejs web server (and eventually to the EAP server).

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

Thank you for sharing your view but it isn't based on facts and doesn't 
provide any supporting evidence. On the contrary: there 3 known 
implementations of EAP-NOOB (1. https://github.com/tuomaura/eap-noob, 
2.https://github.com/eduingles/coap-eap-noob, and 3. 
https://github.com/Vogeltak/hostap), there is a public demo on a small 
device (https://www.youtube.com/watch?v=rPuFKoihl5E), and we have a 
small deployment. I take massive pride in this. Compare this with other 
EAP methods such as EAP-TEAP (https://tools.ietf.org/html/rfc7170) which 
were standardized and went on to become an RFCs with no known 
implementations and were later found to contain a bunch of errata 
(https://www.rfc-editor.org/errata/rfc7170). Thanks to Eliot, Oleg, 
Jorge, Joe, and others who are now fixing them.

I see no actionable points in this review and consider it addressed.

--Mohit

>
>
>