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.