[Iot-directorate] Iotdir telechat review of draft-ietf-opsawg-sdi-10

[Nancy Cam-Winget via Datatracker <[e-mail]>]

Reviewer: Nancy Cam-Winget
Review result: Ready with Issues

IOTDIR review of draft-ietf-opsawg-sdi-10

Reviewer: Nancy Cam-Winget

I have reviewed this document as part of the IoT directorate review team as
anÊongoing effort to review key IETF documents.

This document describes a method to improve the security of
Auto-install or zero-touch provisioning mechanisms for network devices.
The goals include providing layers of security onto existing solutions
While retaining deployment simplicity for both implementor and operator.

The basic proposed mechanism to "improve" the security is by encrypting the
configuration file with the device's public key prior to the device arriving
to its destination.  As the document states in the introductions, it is only
suitable for some use cases; and requires an infrastructure not readily
available or suitable in many industrial IoT deployments.

Assumptions I draw from the document that are barriers to industrial IoT:
- The Operator (or buyer) knows the actual manufacturer or the device.  In
industrial IoT (IIoT), the supply chain can be deeper and often times there is
at least one integrator for these devices. - "Configuration file" in the
document is a single file, where in some IoT devices they need more "tailoring"
vis-a-vis firmware and software as part of their "config" that is more
involved.  Perhaps the "file" that is encrypted is a "tool" but then I'm not
sure encryption solves this for IoT.

- Certificate Publication Server has security and privacy considerations....the
Operator now needs another tool to be able to do this and know where to go and
get the key securely, e.g. it has to trust the publication server and know it
is also authorized.

As this solution doesn't address the considerations for a malicious vendor, and
incurs the assumptions, I am not sure it has strong applicability to IoT.

Introduction
------------
I think more clarification on the use case is needed:
"....nor is it intended to solve all use-cases - rather it is a simple
Targeted solution to solve a common operational issue...".

A "network device" can be one that is intended to be part of the network
infrastructure vs. a device that wants to communicate thru the network
infrastructure.  I do think the considerations for these 2 types of devices are
different and warrant clarification.  From this sentence I am presuming it is
the latter but it is not clear.

Section 4
---------
- 4.1: I can't see the practicality of having "the accounting department get
the unique identifier" and much worse, communicate it to the operations group. 
This seems to break the "zero touch" aspects of the flow, not to mention the
potential security risks as you now need to both trust the people or the tool
in the accounting department....that is, this adds a level of complexity to the
securing of the bootstrapping process.

- 4.2: by "operator", it is implied that there is a "tool" that the operator
must run to contact the server. This should be more clear...and how builds the
"tool"? And How does this improve the simplicity of the process?

- 4.3: there are still quite a lot of industrial IoT deployments that do not
use DHCP. Network equipment, maybe, but controllers and sensors, no.

Section 5
---------
- 5.2: This paragraph is hard to digest.  I think there are 2 separable
concepts trying to be conveyed but they are meshed?  (1) The operator may
choose to to install its own "device key" (e.g. LDEVID in 802.1AR terms) (2)
The vendor may choose to implement identity key storage in one of 2 ways (a)
allow for write once only device identity key storage (once overwritten, will
present challenges if the device changes owner) or (b) allow for the device to
have a re-write device identity key store.

- 5.3: is the intent of this document to only cover "minimal configuration" for
first. Bootstraps only?

Section 7
---------
There should be a discussion on the security requirements of the Certificate
Publication Server. I seems that a malicious requester could phish for these
keys ahead of time as well to defeat the encrypted configs.