At IETF 103 we began to catalog the onboarding mechanisms that are available today. One thing we are learning is that it is unlikely that one size will fit all. There are several dimensions to consider. First, there are different types of users of IoT devices.
Where centralised administration has not been either necessary or desirable for consumers, mechanisms such as WPA-Personal and WPS have sufficed to connect devices; or we see home devices first coming up as APs with web servers, and then being configured to join local networks. Large organisations require more centralised management, both in terms of how devices get credentials, and establishing accountability for those devices. The IETF has developed technologies such as EAP and Radius that work hand in glove with IEEE’s 802.1X, and what we commonly know as WPA-Enterprise, all of which is widely deployed, but difficult to deploy in the home.
At the same time even within large organisations there are different operating models, such as whether or not access to the Internet is available to leverage manufacturers. When hundreds of the same type of a device are connected, automation is a requirement. On the other hand, such a trusted introduction also introduces additional and potentially lasting dependencies on additional parties.
Finally, there are the capabilities and costs associated with the devices themselves. The IAB documented some of this in RFC 7452, and additional experience is documented in RFC 8387. Can a device manage the complexity of EAP? Of TLS or DTLS? Can we expect devices to support CMS-based certificates or COSE-based certificates, or are certificates of any form too much to hope for?
The IETF is not alone in addressing this matter. Organisations such as Bluetooth, Zigbee, LoRaWAN, THREAD, the Wifi Alliance, WiSUN, and BACNET are all struggling to improve onboarding across various L2 technology. Experience shows, however, that common architectural building blocks are key to scaling across different technologies. EAP and Radius, for instance, have been adopted for use in the 3G/4G/5G infrastructure, and of course TLS is used by everyone. We see some of this with onboarding as well, with mechanisms such as Bootstrapping Remote Key Infrastructure (draft-ietf-anima-bootstrapping-key-infra-21.txt) being adopted by others.
With so much work going on, it becomes difficult for implementors to decide what approach is best for them. This is where we decided to begin our work at the last IETF meeting in Bangkok. A mailing list was formed ([email protected]) and we have begun to catalog the mechanisms that are available. This catalog is, as of this writing, still not complete. What we propose to do at IETF 104 is engage in one or more side meetings to refine that work, to create a bit of a matrix that provides for some implementation guidance.