|
This discussion keeps circling back to a need for some type of
private initial binding process between a device that is to be newly
introduced to a network and some agent of the network. In ISA100.11a
and other industrial protocols, we tend to call that process
"provisioning" to keep the terminology distinct from the later
"commissioning" process when the device is actually installed in a
physical plant and brought actively into the network. In the industrial space the provisioning process often can be performed months in advance, when a device is placed in inventory at a plant site as a usable spare, although when the physical device is itself large -- e.g., a 3 m diameter valve -- initial provisioning is likely to occur as the first phase of installation and commissioning. Consideration of the above scenario makes it clear that the provisioning process needs to communicate one or more site-specific credentials (of some type), in a local temporal and spatially secure manner, that later forms the basis for establishing mutual authentication, even though the identity of the eventual target network for the device may not be determinable at the time that the provisioning process occurs (e.g., when the device is placed in inventory). Rather than go on and on about alternative A) below, perhaps our time would be better spent in focusing on the above-summarized process to find acceptable secure alternatives to alternative A) that can provide the needed basis for subsequent mutual authentication. In other words, I am suggesting a change in focus for this discussion based on the presumption that alternative A) will be seen in the future as always unacceptable. If that is the case, what can we propose as a relatively painless, virtually product-cost-free alternative that all 6TiSCH devices can be required to support. It was in that spirit that I proposed using an LED as a low-sensitivity photodiode (which admittedly is a 2-terminal device, not what I had sleepily misstated as a 3-terminal device), together with a smartphone. The smartphone need not be connected to the target network if it merely serves as an optical relay proxy to convey credentials between a device currently in the network and the new device. Conveying a device credential to a network agent or proxy might be performed simply by having the smartphone scan a QR code on the device or its packaging, then conveying that optically or by RF to the proxy or agent, or by normal WiFi or cell connection to a site JCE. Clearly the above is an inadequate solution as stated, which would require further extension; it is placed on the table only to stimulate thought about how a human agent and a contemporary ubiquitous device such as a smartphone might be used as a short-duration relatively-secure channel between the device and a network proxy. The key element is that, for many IoT devices, it is the human installer or human agent for the site where the device will be installed that is acting as an authenticating intermediary in tying the device-to-be-installed to the site's network(s). -Tom ===== On 2015.05.07 07:20, Thomas Watteyne
wrote:
|
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
