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
