NIST SPECIAL PUBLICATION 1800-36C

Trusted Internet of Things (IoT) Device
Network-Layer Onboarding and
Lifecycle Management:
Enhancing Internet Protocol-Based IoT Device and Network
Security
Volume C:
How-To Guides

Murugiah Souppaya
Paul Watrobski

Dan Harkins
Danny Jump

National Institute of Standards and Technology
Gaithersburg, Maryland

Aruba, a Hewlett Packard
Enterprise company
San Jose, California

Chelsea Deane
Joshua Klosterman
Blaine Mulugeta
Charlie Rearick
Susan Symington

Andy Dolan
Kyle Haefner
Craig Pratt
Darshak Thakore

The MITRE Corporation
McLean, Virginia

CableLabsLouisville, Colorado

October 2023
SECOND PRELIMINARY DRAFT
This publication is available free of charge fromhttps://www.nccoe.nist.gov/projects/trusted-iot-device-network-layer-onboarding-and-lifecycle-management

SECOND PRELIMINARY DRAFT

1

DISCLAIMER

2
3
4
5
6
7

Certain commercial entities, equipment, products, or materials may be identified by name or company
logo or other insignia in order to acknowledge their participation in this collaboration or to describe an
experimental procedure or concept adequately. Such identification is not intended to imply special
status or relationship with NIST or recommendation or endorsement by NIST or NCCoE; neither is it
intended to imply that the entities, equipment, products, or materials are necessarily the best available
for the purpose.

8
9
10
11
12

While NIST and the NCCoE address goals of improving management of cybersecurity and privacy risk
through outreach and application of standards and best practices, it is the stakeholder’s responsibility to
fully perform a risk assessment to include the current threat, vulnerabilities, likelihood of a compromise,and the impact should the threat be realized before adopting cybersecurity measures such as thisrecommendation.

13
14

National Institute of Standards and Technology Special Publication 1800-36C, Natl. Inst. Stand. Technol.
Spec. Publ. 1800-36C, 33 pages, October 2023, CODEN: NSPUE2

15

FEEDBACK

16
17

You can improve this guide by contributing feedback. As you review and adopt this solution for yourown organization, we ask you and your colleagues to share your experience and advice with us.

18

Comments on this publication may be submitted to: iot-onboarding@nist.gov.

19

Public comment period: October 31, 2023 through December 15, 2023

20

All comments are subject to release under the Freedom of Information Act.

21
22
23
24
25
26

National Cybersecurity Center of Excellence
National Institute of Standards and Technology
100 Bureau Drive
Mailstop 2002
Gaithersburg, MD 20899
Email: nccoe@nist.gov

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementii

SECOND PRELIMINARY DRAFT

27

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE

28
29
30
31
32
33
34
35
36
37
38
39
40

The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards
and Technology (NIST), is a collaborative hub where industry organizations, government agencies, andacademic institutions work together to address businesses’ most pressing cybersecurity issues. Thispublic-private partnership enables the creation of practical cybersecurity solutions for specificindustries, as well as for broad, cross-sector technology challenges. Through consortia under
Cooperative Research and Development Agreements (CRADAs), including technology partners—from
Fortune 50 market leaders to smaller companies specializing in information technology security—the
NCCoE applies standards and best practices to develop modular, adaptable example cybersecurity
solutions using commercially available technology. The NCCoE documents these example solutions in
the NIST Special Publication 1800 series, which maps capabilities to the NIST Cybersecurity Frameworkand details the steps needed for another entity to re-create the example solution. The NCCoE wasestablished in 2012 by NIST in partnership with the State of Maryland and Montgomery County,
Maryland.

41
42

To learn more about the NCCoE, visit https://www.nccoe.nist.gov/. To learn more about NIST, visit
https://www.nist.gov.

43

NIST CYBERSECURITY PRACTICE GUIDES

44
45
46
47
48
49

NIST Cybersecurity Practice Guides (Special Publication 1800 series) target specific cybersecurity
challenges in the public and private sectors. They are practical, user-friendly guides that facilitate theadoption of standards-based approaches to cybersecurity. They show members of the information
security community how to implement example solutions that help them align with relevant standards
and best practices, and provide users with the materials lists, configuration files, and other information
they need to implement a similar approach.

50
51
52

The documents in this series describe example implementations of cybersecurity practices thatbusinesses and other organizations may voluntarily adopt. These documents do not describe regulations
or mandatory practices, nor do they carry statutory authority.

53

KEYWORDS

54
55

application-layer onboarding; bootstrapping; Internet of Things (IoT); Manufacturer Usage Description(MUD); network-layer onboarding; onboarding; Wi-Fi Easy Connect.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementiii

SECOND PRELIMINARY DRAFT56

ACKNOWLEDGMENTS

57

We are grateful to the following individuals for their generous contributions of expertise and time.
Name

Organization

Amogh Guruprasad Deshmukh

Aruba, a Hewlett Packard Enterprise company

Bart Brinkman

Cisco

Eliot Lear

Cisco

Peter Romness

Cisco

Tyler Baker

Foundries.io

George Grey

Foundries.io

David Griego

Foundries.io

Fabien Gremaud

Kudelski IoT

Brecht Wyseur

Kudelski IoT

Faith Ryan

The MITRE Corporation

Nicholas Allot

NquiringMinds

Toby Ealden

NquiringMinds

Alois Klink

NquiringMinds

John Manslow

NquiringMinds

Antony McCaigue

NquiringMinds

Alexandru Mereacre

NquiringMinds

Craig Rafter

NquiringMinds

Loic Cavaille

NXP Semiconductors

Mihai Chelalau

NXP Semiconductors

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementiv

SECOND PRELIMINARY DRAFT

58
59
60
61

Name

Organization

Julien Delplancke

NXP Semiconductors

Anda-Alexandra Dorneanu

NXP Semiconductors

Todd Nuzum

NXP Semiconductors

Nicusor Penisoara

NXP Semiconductors

Laurentiu Tudor

NXP Semiconductors

Michael Richardson

Sandelman Software Works

Karen Scarfone

Scarfone Cybersecurity

Steve Clark

SEALSQ, a subsidiary of WISeKey

Pedro Fuentes

SEALSQ, a subsidiary of WISeKey

Gweltas Radenac

SEALSQ, a subsidiary of WISeKey

Kalvin YangSEALSQ, a subsidiary of WISeKey

Mike Dow

Silicon Labs

Steve Egerter

Silicon LabsThe Technology Partners/Collaborators who participated in this build submitted their capabilities in
response to a notice in the Federal Register. Respondents with relevant capabilities or productcomponents were invited to sign a Cooperative Research and Development Agreement (CRADA) with
NIST, allowing them to participate in a consortium to build this example solution. We worked with:

62
63
64
65
66

Technology Collaborators
Aruba, a Hewlett Packard
Enterprise company
CableLabs
Cisco

Foundries.io
Kudelski IoT
NquiringMinds
NXP Semiconductors

Open Connectivity Foundation (OCF)
Sandelman Software WorksSEALSQ, a subsidiary of WISeKey
Silicon LabsNIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementv

SECOND PRELIMINARY DRAFT

67

DOCUMENT CONVENTIONS

68
69
70
71
72
73
74

The terms “shall” and “shall not” indicate requirements to be followed strictly to conform to the
publication and from which no deviation is permitted. The terms “should” and “should not” indicate thatamong several possibilities, one is recommended as particularly suitable without mentioning or
excluding others, or that a certain course of action is preferred but not necessarily required, or that (inthe negative form) a certain possibility or course of action is discouraged but not prohibited. The terms“may” and “need not” indicate a course of action permissible within the limits of the publication. The
terms “can” and “cannot” indicate a possibility and capability, whether material, physical, or causal.

75

CALL FOR PATENT CLAIMS

76
77
78
79
80
81

This public review includes a call for information on essential patent claims (claims whose use would be
required for compliance with the guidance or requirements in this Information Technology Laboratory(ITL) draft publication). Such guidance and/or requirements may be directly stated in this ITL Publication
or by reference to another publication. This call also includes disclosure, where known, of the existenceof pending U.S. or foreign patent applications relating to this ITL draft publication and of any relevant
unexpired U.S. or foreign patents.

82
83

ITL may require from the patent holder, or a party authorized to make assurances on its behalf, inwritten or electronic form, either:8485a) assurance in the form of a general disclaimer to the effect that such party does not hold and does not
currently intend holding any essential patent claim(s); or

86
87
88

b) assurance that a license to such essential patent claim(s) will be made available to applicants desiring
to utilize the license for the purpose of complying with the guidance or requirements in this ITL draft
publication either:

89
90
91
92

1. under reasonable terms and conditions that are demonstrably free of any unfair discrimination;or
2. without compensation and under reasonable terms and conditions that are demonstrably freeof any unfair discrimination.

93
94
95
96
97

Such assurance shall indicate that the patent holder (or third party authorized to make assurances on its
behalf) will include in any documents transferring ownership of patents subject to the assurance,
provisions sufficient to ensure that the commitments in the assurance are binding on the transferee,and that the transferee will similarly include appropriate provisions in the event of future transfers withthe goal of binding each successor-in-interest.

98
99

The assurance shall also indicate that it is intended to be binding on successors-in-interest regardless ofwhether such provisions are included in the relevant transfer documents.

100

Such statements should be addressed to: iot-onboarding@nist.gov.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementvi

SECOND PRELIMINARY DRAFT

101

Contents

102

1 Introduction ........................................................................................1

103

1.1

How to Use This Guide .................................................................................................. 1

104

1.2

Build Overview .............................................................................................................. 3

105

1.2.1

Reference Architecture Summary ................................................................................ 3

106

1.2.2

Physical Architecture Summary .................................................................................... 3

107
108

1.3

Typographic Conventions .............................................................................................. 6

2 Build 1 (Wi-Fi Easy Connect, Aruba/HPE) .............................................7

109

2.1

Aruba Central/Hewlett Packard Enterprise (HPE) Cloud .............................................. 7

110

2.2

Aruba Wireless Access Point ......................................................................................... 7

111

2.2.1

Wi-Fi Network Setup/Configuration ............................................................................. 8

112

2.2.2

Wi-Fi Easy Connect Configuration ................................................................................ 9

113

2.3

114
115

2.3.1

2.4

116
117

Cisco Catalyst 3850-S Switch ......................................................................................... 9
Aruba User Experience Insight (UXI) Sensor ............................................................... 10
2.4.1

2.5

Configuration .............................................................................................................. 10
Configuration .............................................................................................................. 10

Raspberry Pi................................................................................................................. 10

118

2.5.1

Configuration .............................................................................................................. 11

119

2.5.2

DPP Onboarding ......................................................................................................... 11

120

2.6

Certificate Authority .................................................................................................... 13

121

2.6.1

Private Certificate Authority ....................................................................................... 13

122

2.6.2

SEALSQ INeS................................................................................................................ 17

123
124
125

2.7

3 Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) ..................................... 18
3.1

126
127

UXI Cloud ..................................................................................................................... 18

CableLabs Platform Controller .................................................................................... 18
3.1.1

3.2

Operation/Demonstration.......................................................................................... 18

CableLabs Custom Connectivity Gateway ................................................................... 19

128

3.2.1

Installation/Configuration .......................................................................................... 19

129

3.2.2

Integration with CableLabs Platform Controller ........................................................ 19

130

3.2.3

Operation/Demonstration.......................................................................................... 19

131
132

3.3

Reference Clients/IoT Devices..................................................................................... 19
3.3.1

Installation/Configuration .......................................................................................... 19

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementvii

SECOND PRELIMINARY DRAFT
133
134
135

3.3.2

4 Build 3 (BRSKI, Sandelman Software Works) ...................................... 20
4.1

136
137

Onboarding Router/Join Proxy .................................................................................... 20
4.1.1

4.2

138
139

Operation/Demonstration.......................................................................................... 19

Minerva Join Registrar Coordinator ............................................................................ 20
4.2.1

4.3

140

Setup and Configuration ............................................................................................. 20
Setup and Configuration ............................................................................................. 20

Reach Pledge Simulator ............................................................................................... 21
4.3.1

Setup and Configuration ............................................................................................. 21

141

4.4

Serial Console Server ................................................................................................... 22

142

4.5

Minerva Highway MASA Server .................................................................................. 22

143
144

4.5.1

4.6

145
146

IoT Devices................................................................................................................... 23
4.6.1

4.7

Setup and Configuration ............................................................................................. 23
Setup/Installation ....................................................................................................... 23

SEALSQ Certificate Authority....................................................................................... 23147

5 Build 4 (Thread, Silicon Labs, Kudelski IoT) ......................................... 23148

6 Build 5 (BRSKI, NquiringMinds) .......................................................... 23149

7 Factory Provisioning Builds ................................................................ 23

150

Appendix A List of Acronyms ................................................................. 24

151

Appendix B References .......................................................................... 25

152

List of Figures

153

Figure 1-1 NCCoE IoT Onboarding Laboratory Physical Architecture .....................................................5

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementviii

SECOND PRELIMINARY DRAFT

154

1 Introduction

155
156
157
158
159

The following volumes of this guide show information technology (IT) professionals and security
engineers how we implemented these example solutions. We cover all of the products employed in thisreference design. We do not re-create the product manufacturers’ documentation, which is presumed
to be widely available. Rather, these volumes show how we incorporated the products together in ourenvironment.

160
161

Note: These are not comprehensive tutorials. There are many possible service and security configurations
for these products that are out of scope for this reference design.

162

1.1 How to Use This Guide

163
164
165
166
167
168
169
170
171

This NIST Cybersecurity Practice Guide demonstrates a standards-based reference design for
implementing trusted IoT device network-layer onboarding and lifecycle management and describes
various example implementations of this reference design. Each of these implementations, which are
known as builds, is standards-based and is designed to help provide assurance that networks are not put
at risk as new IoT devices are added to them and to help safeguard IoT devices from connecting tounauthorized networks. The reference design described in this practice guide is modular and can be
deployed in whole or in part, enabling organizations to incorporate trusted IoT device network-layer
onboarding and lifecycle management into their legacy environments according to goals that they haveprioritized based on risk, cost, and resources.

172
173
174
175

NIST is adopting an agile process to publish this content. Each volume is being made available as soon as
possible rather than delaying release until all volumes are completed. Work continues on implementing
the example solutions and developing other parts of the content. As a preliminary draft, we will publish
at least one additional draft for public comment before it is finalized.

176

This guide contains five volumes:

177
178
179

▪

NIST Special Publication (SP) 1800-36A: Executive Summary – why we wrote this guide, thechallenge we address, why it could be important to your organization, and our approach tosolving this challenge

180▪

NIST SP 1800-36B: Approach, Architecture, and Security Characteristics – what we built and why

181
182
183

▪

NIST SP 1800-36C: How-To Guides – instructions for building the example implementations,
including all the security-relevant details that would allow you to replicate all or parts of thisproject (you are here)

184
185
186

▪

NIST SP 1800-36D: Functional Demonstrations – use cases that have been defined to showcase
trusted IoT device network-layer onboarding and lifecycle management security capabilities andthe results of demonstrating these use cases with each of the example implementations

187
188
189

▪

NIST SP 1800-36E: Risk and Compliance Management – risk analysis and mapping of trusted IoT
device network-layer onboarding and lifecycle management security characteristics tocybersecurity standards and recommended practices

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

1

SECOND PRELIMINARY DRAFT
190

Depending on your role in your organization, you might use this guide in different ways:

191
192

Business decision makers, including chief security and technology officers, will be interested in the
Executive Summary, NIST SP 1800-36A, which describes the following topics:

193
194

▪

challenges that enterprises face in migrating to the use of trusted IoT device network-layer
onboarding

195▪

example solutions built at the NCCoE

196▪

benefits of adopting the example solution

197
198

Technology or security program managers who are concerned with how to identify, understand, assess,and mitigate risk will be interested in NIST SP 1800-36B, which describes what we did and why.

199
200
201
202
203
204

Also, Section 4 of NIST SP 1800-36E will be of particular interest. Section 4, Mappings, maps logicalcomponents of the general trusted IoT device network-layer onboarding and lifecycle management
reference design to security characteristics listed in various cybersecurity standards and recommended
practices documents, including Framework for Improving Critical Infrastructure Cybersecurity (NIST
Cybersecurity Framework) and Security and Privacy Controls for Information Systems and Organizations(NIST SP 800-53).

205
206
207

You might share the Executive Summary, NIST SP 1800-36A, with your leadership team members to help
them understand the importance of using standards-based trusted IoT device network-layer onboarding
and lifecycle management implementations.

208
209
210
211
212
213
214
215
216
217
218

IT professionals who want to implement similar solutions will find the whole practice guide useful. You
can use the how-to portion of the guide, NIST SP 1800-36C, to replicate all or parts of the builds createdin our lab. The how-to portion of the guide provides specific product installation, configuration, andintegration instructions for implementing the example solution. We do not re-create the productmanufacturers’ documentation, which is generally widely available. Rather, we show how weincorporated the products together in our environment to create an example solution. Also, you can use
Functional Demonstrations, NIST SP 1800-36D, which provides the use cases that have been defined toshowcase trusted IoT device network-layer onboarding and lifecycle management security capabilities
and the results of demonstrating these use cases with each of the example implementations. Finally,
NIST SP 1800-36E will be helpful in explaining the security functionality that the components of eachbuild provide.

219
220
221
222
223
224
225
226

This guide assumes that IT professionals have experience implementing security products within theenterprise. While we have used a suite of commercial products to address this challenge, this guide does
not endorse these particular products. Your organization can adopt this solution or one that adheres tothese guidelines in whole, or you can use this guide as a starting point for tailoring and implementing
parts of a trusted IoT device network-layer onboarding and lifecycle management solution. Your
organization’s security experts should identify the products that will best integrate with your existing
tools and IT system infrastructure. We hope that you will seek products that are congruent withapplicable standards and recommended practices.

227
228

A NIST Cybersecurity Practice Guide does not describe “the” solution, but example solutions. This is apreliminary draft guide. As the project progresses, this preliminary draft will be updated. We seek

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

2

SECOND PRELIMINARY DRAFT
229
230
231

feedback on the publication’s contents and welcome your input. Comments, suggestions, and successstories will improve subsequent versions of this guide. Please contribute your thoughts to iotonboarding@nist.gov.

232

1.2 Build Overview

233
234
235

This NIST Cybersecurity Practice Guide addresses the challenge of network-layer onboarding using
standards-based protocols to perform trusted network-layer onboarding of an IoT device. Each build
demonstrates one or more of these capabilities:

236
237

▪

Trusted Network-Layer Onboarding: providing the device with its unique network credentials
over an encrypted channel

238
239

▪

Network Re-Onboarding: performing trusted network-layer onboarding of the device again,
after device reset

240▪

Network Segmentation: assigning a device to a segment of the network

241
242

▪

Trusted Application-Layer Onboarding: providing the device with application-layer credentials
over an encrypted channel after completing network-layer onboarding

243
244

▪

Ongoing Device Authorization: continuously monitoring the device on an ongoing basis,
providing policy-based assurance and authorization checks on the device throughout its lifecycle

245
246
247
248
249
250
251

Currently, five builds that will serve as examples of how to onboard IoT devices using the protocols
described in NIST SP 1800-36B, as well as the factory provisioning builds, are being implemented andwill be demonstrated as part of this project. The remainder of this practice guide provides step-by-step
instructions on how to reproduce the three builds that have been completed so far: Builds 1 (Wi-Fi Easy
Connect, Aruba/HPE), 2 (Wi-Fi Easy Connect, CableLabs, OCF), and 3 (BRSKI, Sandelman Software
Works). Step-by-step instructions for Builds 4 (Thread, Silicon Labs, Kudelski IoT), 5 (BRSKI,
NquiringMinds), and the factory provisioning builds will be included in future updates to this document.

252

1.2.1 Reference Architecture Summary

253
254
255
256
257
258

The builds described in this document are instantiations of the trusted network-layer onboarding andlifecycle management logical reference architecture that is described in NIST SP 1800-36B. Thisarchitecture is organized according to five high-level processes: Device Manufacture and Factory
Provisioning, Device Ownership and Bootstrapping Information Transfer, Trusted Network-Layer
Onboarding, Trusted Application-Layer Onboarding, and Continuous Assurance. For a full explanation of
the architecture, please see NIST SP 1800-36B: Approach, Architecture, and Security Characteristics.

259

1.2.2 Physical Architecture Summary

260
261
262
263
264
265

Figure 1-1 depicts the high-level physical architecture of the NCCoE IoT Onboarding laboratoryenvironment in which the five trusted IoT device network-layer onboarding project builds and the two
factory provisioning builds are being implemented. The NCCoE provides virtual machine (VM) resources
and physical infrastructure for the IoT Onboarding lab. As depicted, the NCCoE IoT Onboarding
laboratory hosts collaborator hardware and software for the builds. The NCCoE also provides
connectivity from the IoT Onboarding lab to the NIST Data Center, which provides connectivity to the

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

3

SECOND PRELIMINARY DRAFT
266
267

internet and public IP spaces (both IPv4 and IPv6). Access to and from the NCCoE network is protectedby a firewall.

268
269
270
271
272
273

Access to and from the IoT Onboarding lab is protected by a pfSense firewall, represented by the brickbox icon in Figure 1-1. This firewall has both IPv4 and IPv6 (dual stack) configured. The IoT Onboarding
lab network infrastructure includes a shared virtual environment that houses a domain controller and avendor jumpbox. These components are used across builds where applicable. It also contains fiveindependent virtual local area networks (VLANs), each of which houses a different trusted network-layer
onboarding build.

274
275
276
277
278
279

The IoT Onboarding laboratory network has access to cloud components and services provided by thecollaborators, all of which are available via the internet. These components and services include Aruba
Central and the User Experience Insight (UXI) Cloud (Build 1), Platform Controller (Build 2), a
Manufacturer Authorized Signing Authority (MASA) server (Builds 3, 5), Kudelski IoT keySTREAM
application-layer onboarding service and Amazon Web Services (AWS) IoT (Build 4), andFoundriesFactory and SEALSQ INeS, which we anticipate will be used across numerous builds.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

4

SECOND PRELIMINARY DRAFT
280

Figure 1-1 NCCoE IoT Onboarding Laboratory Physical Architecture
NIST Virtual Environment

Collaborator
Cloud
Components

INTERNET

Aruba Foundries UXI Platform MASA SEALSQ Kudelski IoT AWS IoT
INeS keySTREAM (Build 4)Central Factory Cloud Controller Servers(Build 1) (Build 1, 2) (Build 1) (Build 2) (Build 3, (Build 1,5, (Build 4)
Factory) Factory)

Firewall
Domain Vendor Registrar
Controller Jumpbox Server(Build 3)
Shared Environment

Build 1

Aruba
Access Point

IoT
Devices

Build 2

Cisco
SwitchUXI
SensorBuild 4

Build 3Gateway
Access Point

IoT
Devices

DMZ
Switch802.15.4
Gateway
TITUS Serial
ConsoleBuild 5

Onboarding
RouterThread BorderRouterIoT
Devices

IoT
Devices

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

MASA++ Gateway
Registrar Access Point
ServerIoT
Devices

Factory
Provisioning
Build
Onboarding
RouterIoT
Devices

5

SECOND PRELIMINARY DRAFT
281
282

All six network-layer onboarding laboratory environments, as depicted in the diagram, have been
installed:

283
284
285
286
287

▪

The Build 1 network infrastructure within the NCCoE lab consists of two components: the Aruba
Access Point and the Cisco Switch. Build 1 also requires support from Aruba Central for networklayer onboarding and the UXI Cloud for application-layer onboarding. These components are in
the cloud and accessed via the internet. The IoT devices that are onboarded using Build 1
include the UXI Sensor and the Raspberry Pi.

288
289
290
291

▪

The Build 2 network infrastructure within the NCCoE lab consists of a single component: theGateway Access Point. Build 2 also requires support from the Platform Controller, which also
hosts the IoTivity Cloud Service. The IoT devices that are onboarded using Build 2 include three
Raspberry Pis.

292
293
294
295
296
297
298

▪

The Build 3 network infrastructure components within the NCCoE lab include a Wi-Fi capable
home router (including Join Proxy), a DMZ switch (for management), and an ESP32A Xtensaboard acting as a Wi-Fi IoT device, as well as an nRF52840 board acting as an IEEE 802.15.4
device. A management system on a BeagleBone Green acts as a serial console. A registrar server
has been deployed as a virtual appliance on the NCCoE private cloud system. Build 3 also
requires support from a MASA server which is accessed via the internet. In addition, a Raspberry
Pi provides an ethernet/802.15.4 gateway, as well as a test platform.

299
300
301
302
303
304

▪

The Build 4 network infrastructure components within the NCCoE lab include an Open Thread
Border Router, which is implemented using a Raspberry Pi, and a Silicon Labs Gecko WirelessStarter Kit, which acts as an 802.15.4 antenna. Build 4 also requires support from the Kudelski
IoT keySTREAM service, which is in the cloud and accessed via the internet. The IoT device thatis onboarded in Build 4 is the Silicon Labs Thunderboard (BRD2601A) with an EFR32MG24
System-on-Chip. The application service to which it onboards is AWS IoT.

305
306
307
308
309
310

▪

The Build 5 network infrastructure components within the NCCoE lab include an OpenWRT
router, a Turris Omnia Wi-Fi access point, the MASA++ Registration Server, and a USB hub. Thisbuild leverages the NquiringMinds’ cloud service called tdx Volt in conjunction with the RADIUS
service that resides on the router to provide authentication capabilities for network-layer
onboarding to take place. The IoT device that is onboarded using Build 5 is a Feather HUZAH
ESP8266.

311
312
313
314
315

▪

The factory provisioning build network infrastructure partially shares the Wi-Fi capable homerouter with Build 3 for network-layer onboarding. The IoT devices in this build are Raspberry Pis
equipped with a SEALSQ VaultIC Secure Element, which is provisioned credentials incoordination with the cloud-based SEALSQ INES Certificate Authority. The factory provisioning
build also includes a cloud-based MASA server to support BRSKI capabilities.

316
317

The remainder of this guide will focus on the setup and configuration of Builds 1, 2, and 3. Informationfor Builds 4, 5, and the factory provisioning builds are planned for future updates to this document.

318

1.3 Typographic Conventions

319

The following table presents typographic conventions used in this volume.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

6

SECOND PRELIMINARY DRAFT

Typeface/Symbol

Meaning

ExampleItalics

file names and path names;
references to documents that are not
hyperlinks; new terms; andplaceholders
names of menus, options, command
buttons, and fields
command-line input, onscreen
computer output, sample code
examples, and status codes
command-line user input contrasted
with computer output
link to other parts of the document, a
web URL, or an email address

For language use and style guidance, see
the NCCoE Style Guide.

Bold
Monospace

Monospace Bold

blue text

Choose File > Edit.
mkdir

service sshd start

All publications from NIST’s NCCoE areavailable at https://www.nccoe.nist.gov.

320

2 Build 1 (Wi-Fi Easy Connect, Aruba/HPE)

321
322
323

This section of the practice guide contains detailed instructions for installing and configuring all the
products used to build an instance of the example solution. For additional details on Build 1’s logical andphysical architectures, see NIST SP 1800-36B: Approach, Architecture, and Security Characteristics.

324
325
326
327

The network-layer onboarding component of Build 1 utilizes Wi-Fi Easy Connect, also known as theDevice Provisioning Protocol (DPP). The Wi-Fi Easy Connect standard is maintained by the Wi-Fi Alliance[1]. The term “DPP” is used when referring to the network-layer onboarding protocol, and “Wi-Fi Easy
Connect” is used when referring to the overall implementation of the network onboarding process.

328

2.1 Aruba Central/Hewlett Packard Enterprise (HPE) Cloud

329
330
331
332
333
334
335

This build utilized Aruba Central as a cloud management service that provided management and support
for the Aruba Wireless Access Point (AP) and provided authorization and DPP onboarding capabilities forthe wireless network. A cloud-based application programming interface (API) endpoint provided theability to import the DPP Uniform Resource Identifiers (URIs) in the manner of a Supply Chain
Integration Service. Due to this capability and Build 1’s support for Wi-Fi Easy Connect, Build 1’s
infrastructure fully supported interoperable network-layer onboarding with Build 2’s Reference Clients(“IoT devices”) provided by CableLabs.

336

2.2 Aruba Wireless Access Point

337
338
339

Use of DPP is implicitly dependent on the Aruba Central cloud service. Aruba Central provides a cloud
Infrastructure as a Service (IaaS) enabled architecture that includes initial support for DPP in Central
2.5.6/ArubaOS (AOS) 10.4.0. Central and AOS support multiple deployment formats:

340

1. As AP only, referred to as an underlay deployment, where traffic is bridged locally from the APs.

341
342
343

2. An overlay deployment, where all data is securely tunneled to an on-prem gateway where
advanced services can route, inspect, and analyze the data before it’s either bridged locally orrouted to its next hop.
NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

7

SECOND PRELIMINARY DRAFT
344
345

3. A mixed-mode deployment, which is a combination of the two where a returned ‘role/label’ isused to determine how the data is processed and forwarded.

346
347
348
349

At the time of this publication, a user can leverage any 3xx, 5xx, or 6xx APs to support a DPP
deployment, with a view that all future series APs will implicitly include support. For an existing or newuser there is a prerequisite of the creation of a Service Set Identifier (SSID). Note that DPP today is notsupported under Wi-Fi Protected Access 3 (WPA3); this is a roadmap item with no published timeline.

350
351
352
353

Assuming there is an existing SSID or a new one is created based upon the above security restrictions,the next step is to enable DPP (as detailed below in Section 2.2.1) such that the SSID can support
multiple authentication and key managements (AKMs) on a Basic Service Set (BSS). If the chosen security
type is DPP, only a single AKM will exist for that BSS.

354
355

A standards-compliant 802.3at port is the easiest method for providing the AP with power. An external
power supply can also be used.

356
357
358
359
360

Within this document, we do not cover the specifics of radio frequency (RF) design and placement ofAPs. Guidance and assistance is available within the Aruba community site,
https://community.arubanetworks.com or the Aruba Support Portal, https://asp.arubanetworks.com.
Additionally, we do not cover onboarding and licensing of Aruba Central hardware. Documentation canbe found here: https://www.arubanetworks.com/techdocs/ArubaDocPortal/content/docportal.htm.

361

2.2.1 Wi-Fi Network Setup/Configuration

362
363

The following instructions detail the initial setup and configuration of the Wi-Fi network upon powering
on and connecting the AP to an existing network.

364

1. Navigate to the Aruba Central cloud management interface.

365
366

2. On the sidebar, navigate under Global and choose the AP-Group you want to configure/modify.
(This assumes you have already grouped your APs by location/functions.)367

3. Under Devices, click on Config in the top right side.

368

4. You will now be in the Access Points tab and WLANs tab. Do one of the following:

369
370
371
372

a. If creating a new SSID, click on + Add SSID. After entering the Name (SSID) in Step 1 andconfiguring options as necessary in Step 2, when you get to Step 3 (Security), it will
default on the slide-bar to the Personal Security Level; the alternative is the Enterprise
Security Level.

373
374
375
376
377

i. If you choose the Personal Security Level, under Key-Management ensure you
select either DPP or WPA2-Personal. If you choose WPA2-Personal, expand theAdvanced Settings section and enable the toggle button for DPP so that the SSID
can broadcast the AKM. Note that this option is not available if choosing DPP for
Key-Management.

378
379
380

ii. If you choose the Enterprise Security Level, only WPA2-Enterprise KeyManagement currently supports DPP. Expand the Advanced Settings section andenable the toggle button for DPP so that the SSID can broadcast the AKM.
NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

8

SECOND PRELIMINARY DRAFT
381

b. If you plan to enable DPP on a previously created SSID:

382
383

i. Ensure you are running version 10.4+ on your devices. You also need an SSID thatis configured for WPA2-Personal or WPA2-Enterprise.

384
385

ii. When ready, float your cursor over the previously created SSID name you wish toconfigure and click on the edit icon.

386
387

iii. Edit the SSID, click on Security, and expand the Advanced Settings section andenable the toggle button for DPP.

388

iv. Click Save Settings.

389
390

For SSIDs that have been modified to add DPP AKM, it’s also necessary to enable DPP within the radio
profile.

391

1. Under the Access Point Tab, click on Radios.

392
393

2. It’s expected you’ll see a default radio-profile. If a custom one has been created, you’ll need toreview your configuration before proceeding.

394
395
396

3. Assuming a default radio-profile, click on the Edit icon, expand Show advanced settings, andscroll down to DPP Provisioning. You can selectively enable this for 2.4 GHz or 5.0 GHz. Support
for DPP on 6.0 GHz is a roadmap item at this time and is not yet available.

397

2.2.2 Wi-Fi Easy Connect Configuration

398
399
400

Configuration of the Access Point occurred through the Aruba Central cloud management interface.
Standard configurations were used to stand up the Build 1 wireless network. The instructions forenabling DPP capabilities for the overall wireless network are listed below:

401

1. Navigate to the Aruba Central cloud management interface.

402

2. On the sidebar, navigate to Security > Authentication and Policy > Config.

403

3. In the Client Access Policy section, click Edit.

404
405

4. Under the Wi-Fi Easy Connect™ Service heading, ensure that the name of your wireless network
is selected.

406

5. Click Save.

407

2.3 Cisco Catalyst 3850-S Switch

408
409
410

This build utilized a Cisco Catalyst 3850-S switch. This switch utilized a minimal configuration with two
separate VLANs to allow for IoT device network segmentation and access control. The switch also
provided Power-over-Ethernet support for the Aruba Wireless AP.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

9

SECOND PRELIMINARY DRAFT

411

2.3.1 Configuration

412
413

The switch was configured with two VLANs, and a trunk port dedicated to the Aruba Wireless AP. You
can find the relevant portions of the Cisco iOS configuration below:

414

interface Vlan1415

no ip address

416

interface Vlan2417

no ip address

418

interface GigabitEthernet1/0/1

419

switchport mode trunk

420

interface GigabitEthernet1/0/2

421

switchport mode access422

switchport access vlan 1

423

interface GigabitEthernet1/0/3

424switchport mode access425

switchport access vlan 2426

2.4 Aruba User Experience Insight (UXI) Sensor

427
428
429
430
431

This build utilized an Aruba UXI Sensor as a Wi-Fi Easy Connect-capable IoT device. Models G6 and G6C
support Wi-Fi Easy Connect, and all available G6 and G6C models support Wi-Fi Easy Connect within
their software image. This sensor successfully utilized the network-layer onboarding mechanism
provided by the wireless network and completed onboarding to the application-layer UXI cloud service.
The network-layer onboarding process is automatically initiated by the device on boot.

432

2.4.1 Configuration

433
434
435
436
437
438
439
440
441
442

All of Aruba’s available G6 and G6C UXI sensors support the ability to complete network-layer andapplication-layer onboarding. No specific configuration of the physical sensor is required. As part of the
supply-chain process, the cryptographic public key for your sensor(s) will be available within the cloud
tenant. This public/private keypair for each device is created as part of the manufacturing process. The
public key effectively identifiers the sensor to the network and as part of the Wi-Fi Easy Connect/DPP
onboarding process. This allows unprovisioned devices straight from the factory to be onboarded andsubsequently connect to the UXI sensor cloud to obtain their network-layer configuration. An
administrator will have to define the ‘tasks’ the UXI sensor is going to perform such as monitoring SSIDs,
performing reachability tests to on-prem or cloud services, and making the results of these tests
available within the UXI user/administrator portal.

443

2.5 Raspberry Pi

444
445
446

In this build, the Raspberry Pi 3B+ acts as a DPP enrollee. In setting up the device for this build, a DPPcapable wireless adapter, the Alfa AWUS036NHA network dongle, was connected to enable the Pi tosend and receive DPP frames. Once fully configured, the Pi can onboard with the Aruba AP.
NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

10

SECOND PRELIMINARY DRAFT

447

2.5.1 Configuration

448

The following steps were completed for the Raspberry Pi to complete DPP onboarding:

449
450
451

1. Set the management IP for the Raspberry Pi to an IP address in the Build 1 network. To do this,add the following lines to the file dhcpcd.conf located at /etc/dhcpcd.conf. For this build, the IP
address was set to 192.168.10.3.

452

2. Install Linux Libraries using the apt package manager. The following packages were installed:453

a. autotools-dev

454

b. automake

455

c. libcurl4-openssl-dev

456

d. libnl-genl-3-dev

457

e. libavahi-client-dev

458

f.

459

g. aircrack-ng

460

h. openssl-1.1.1q

461
462
463

libavahi-core-dev

3. Install the DPP utilities. These utilities were installed from the GitHub repository
https://github.com/HewlettPackard/dpp using the following command:
git clone https://github.com/HewlettPackard/dpp

464

2.5.2 DPP Onboarding

465
466
467
468
469

This section describes the steps for using the Raspberry Pi as a DPP enrollee. The Pi uses a DPP utility tosend out chirps to make its presence known to available DPP configurators. Once the Pi is discovered,the DPP configurator (Aruba Wireless AP) initiates the DPP authentication protocol. During this phase,
DPP connectors are created to onboard the device to the network. As soon as the Pi is fullyauthenticated, it is fully enrolled and can begin normal network communication.

470
471

1. Navigate to the DPP utilities directory which was installed during setup:
cd dpp/linux

472

2. From the DPP utilities directory, run the following command to initiate a DPP connection:

473

sudo ./sss -I wlan1 -r -e sta -k respp256.pem -B respbkeys.txt -a -t -d 255

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

11

SECOND PRELIMINARY DRAFT

474

3. Once the enrollee has found a DPP configurator, the DPP authentication protocol is initiated.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

12

SECOND PRELIMINARY DRAFT

475

2.6 Certificate Authority

476
477

The function of the certificate authority (CA) in this build is to issue network credentials for use in the
network-layer onboarding process.

478

2.6.1 Private Certificate Authority

479
480

A private CA was provided as a part of the DPP demonstration utilities in the HPE GitHub repository. For
demonstration purposes, the Raspberry Pi is used as the configurator and the enrollee.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

13

SECOND PRELIMINARY DRAFT
481

2.6.1.1 Installation/Configuration

482
483

The following instructions detail the initial setup and configuration of the private CA using the DPP
demonstration utilities and certificates located at https://github.com/HewlettPackard/dpp.

484
485

1. Navigate to the DPP utilities directory on the Raspberry Pi: ~dpp/linux
cd dpp/linux/

486
487
488
489
490
491

2. The README in the GitHub repository(https://github.com/HewlettPackard/dpp/blob/master/README) references a text file called
configakm which contains information about the network policies for a configurator to provision
on an enrollee. The format is: <akm> <EAP server> <ssid> . Current AKMs that are supported
are DPP, dot1x, sae, and psk. For this build, DPP is used. For DPP, an Extensible Authentication
Protocol (EAP) server is not used.

492
493
494
495

3. Configure the file configakm located in ~/dpp/linux/. This file instructs the configurator on how
to deploy a DPP connector (network credential) from the configurator to the enrollee. As shown
below, the configakm file is filled with the following fields:
dpp unused Build1-IoTOnboarding.

496
497
498

4. The file csrattrs.conf contains attributes to construct an Abstract Syntax Notation One (ASN.1)
string. This string allows the configurator to tell the enrollee how to generate a certificate
signing request (CSR). The following fields were used for this demonstration:499

asn1 = SEQUENCE: seq_section

500[seq_section]

501

field1 = OID:challengePassword

502

field2 = SEQUENCE:ecattrs

503

field3 = SEQUENCE:extnd

504

field4 = OID:ecdsa-with-SHA256

505[ecattrs]

506

field1 = OID:id-ecPublicKey

507

field2 = SET:curve

508[curve]509

field1 = OID:prime256v1

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

14

SECOND PRELIMINARY DRAFT
510[extnd]511

field1 – OID:extReq

512field2 = SET:extattrs

513[extattrs]

514

field1 = OID:serialNumber

515

field2 = OID:favouriteDrink

516

2.6.1.2 Operation/Demonstration

517
518

Once setup and configuration have been completed, the following steps can be used to demonstrateutilizing the private CA to issue credentials to a requesting device.

519
520

1. Open three terminals on the Raspberry Pi: one to start the certificate program, one to show theconfigurator’s point of view, and one to show the enrollee’s point of view.

521
522

2. The demonstration uses an OpenSSL certificate. To run the program from the first terminal,
navigate to the following directory: ~/dpp/ecca/, and run the command: ./ecca.

523

3. On the second terminal, start the configurator using the following command:524

sudo ./sss -I lo -r -c signp256.pem -k respp256.pem -B resppbkeys.txt -d 255

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

15

SECOND PRELIMINARY DRAFT

525
526

527

As shown in the terminal where the ecca program is running, the configurator contacts the CA
and asks for the certificate.

4. On the third terminal, start the enrollee using the following command:528

sudo ./sss -I lo -r -e sta -k initp256.pem -B initbkeys.txt -t -a -q -d 255

529
530
531

From the enrollee’s perspective, it will send chirps on different channels until it finds theconfigurator. Once found, it sends its certificate to the CA for signing. The snippet below is of
the enrollee generating the CSR.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

16

SECOND PRELIMINARY DRAFT

532

5. In the ecca terminal, the certificate from the enrollee is shown533

2.6.2 SEALSQ INeS

534
535
536

The SEALSQ INeS Certificate Management System provides CA and certificate management capabilities
for Build 1. Implementation of this system provides Build 1 with a trusted, public CA to support issuing
network credentials.

537

2.6.2.1 Setup and Configuration

538
539
540
541

To support this build, a custom software agent was deployed on a Raspberry Pi in the Build 1 network.
This agent interacted with the cloud-based CA in SEALSQ INeS via API to sign network credentials.
Network-level onboarding of IoT devices was completed via DPP, with network credentials being
successfully requested from and issued by SEALSQ INeS.
NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

17

SECOND PRELIMINARY DRAFT
542
543
544

Additional information on interacting with the SEALSQ INeS API can be found athttps://inesdev.certifyiddemo.com/. Access can be requested directly from SEALSQ via their contact
form: https://www.sealsq.com/contact.

545

2.7 UXI Cloud

546
547
548
549
550
551

The UXI Cloud is a web-based application that serves as a monitoring hub for the UXI sensor. It provides
visibility into the data captured by the performance monitoring that the UXI sensor conducts. For the
purposes of this build, the dashboard was used to demonstrate application-layer onboarding, which
occurs once the UXI sensor has completed network-layer onboarding. Once application-layer
onboarding was completed and the application configuration had been applied to the device, ourdemonstration concluded.

552

3 Build 2 (Wi-Fi Easy Connect, CableLabs, OCF)

553
554
555

This section of the practice guide contains detailed instructions for installing and configuring all of the
products used to build an instance of the example solution. For additional details on Build 2’s logical andphysical architectures, see NIST SP 1800-36B: Approach, Architecture, and Security Characteristics.

556
557
558
559

The network-layer onboarding component of Build 2 utilizes Wi-Fi Easy Connect, also known as theDevice Provisioning Protocol (DPP). The Wi-Fi Easy Connect standard is maintained by the Wi-Fi Alliance[1]. The term “DPP” is used when referring to the network-layer onboarding protocol, and “Wi-Fi Easy
Connect” is used when referring to the overall implementation of the network onboarding process.

560

3.1 CableLabs Platform Controller

561
562
563
564
565
566

The CableLabs Platform Controller provides an architecture and reference implementation of a cloudbased service that provides management capability for service deployment groups, access points withthe deployment groups, registration and lifecycle of user services, and the secure onboarding andlifecycle management of users’ Wi-Fi devices. The controller also exposes APIs for integration with thirdparty systems for the purpose of integrating various business flows (e.g., integration with manufacturing
process for device management).

567
568
569
570
571

The Platform Controller would typically be hosted by the network operator or a third-party service
provider. It can be accessed via web interface. Additional information for this deployment can beaccessed at the official CableLabs repository:
https://github.com/cablelabs/Streamlined_Onboarding_Demo/blob/nccoe-release/docs/Ref-AP-Setupfor-NCCoE/nccoe-ap-setup.md.

572

3.1.1 Operation/Demonstration

573
574
575
576

Once configuration of the Platform Controller, Gateway, and Reference Client has been completed, fulloperation can commence. Instructions for this are located at the official CableLabs repository:
https://github.com/cablelabs/Streamlined_Onboarding_Demo/blob/nccoerelease/docs/Raspberry_Pi_Deployment.md.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

18

SECOND PRELIMINARY DRAFT

577

3.2 CableLabs Custom Connectivity Gateway

578
579
580
581
582

In this deployment, the gateway software is running on a Raspberry Pi 3B+, which acts as a router,firewall, wireless access point, Open Connectivity Foundation (OCF) Diplomat, and OCF Onboarding Tool.
The gateway is also connected to the CableLabs Platform Controller, which manages much of theconfiguration and functions of the gateway. Due to Build 2’s infrastructure and support of Wi-Fi Easy
Connect, Build 2 fully supported interoperable network-layer onboarding with Build 1’s IoT devices.

583

3.2.1 Installation/Configuration

584
585
586
587

Hardware requirements, pre-installation steps, installation steps, and configuration instructions for the
gateway can be found at the official CableLabs repository:
https://github.com/cablelabs/Streamlined_Onboarding_Demo/blob/nccoe-release/docs/Ref-AP-Setupfor-NCCoE/nccoe-ap-setup.md.

588

3.2.2 Integration with CableLabs Platform Controller

589
590
591
592

Once initial configuration has occurred, the gateway can be integrated with the CableLabs Platform
Controller. Instructions can be found at the official CableLabs repository:
https://github.com/cablelabs/Streamlined_Onboarding_Demo/blob/nccoe-release/docs/Ref-AP-Setupfor-NCCoE/nccoe-ap-setup.md

593

3.2.3 Operation/Demonstration

594
595
596
597

Once configuration of the Platform Controller, Gateway, and Reference Client has been completed, fulloperation can commence. Instructions for this are located at the official CableLabs repository:
https://github.com/cablelabs/Streamlined_Onboarding_Demo/blob/nccoerelease/docs/Raspberry_Pi_Deployment.md.

598

3.3 Reference Clients/IoT Devices

599
600
601
602
603

Three reference clients were deployed in this build, each on a Raspberry Pi 3B+. They were eachconfigured to emulate either a smart light switch or a smart lamp. The software deployed also included
the capability to perform network-layer onboarding via Wi-Fi Easy Connect/DPP and application-layer
onboarding using the OCF onboarding method. These reference clients were fully interoperable with
network-layer onboarding to Build 1.

604

3.3.1 Installation/Configuration

605
606
607
608

Hardware requirements, pre-installation, installation, and configuration steps for the reference clientsare detailed in the official CableLabs repository:
https://github.com/cablelabs/Streamlined_Onboarding_Demo/blob/nccoerelease/docs/Raspberry_Pi_Deployment.md.

609

3.3.2 Operation/Demonstration

610
611

Once configuration of the Platform Controller, Gateway, and Reference Client has been completed, fulloperation can commence. Instructions for this are located at the official CableLabs repository:
NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

19

SECOND PRELIMINARY DRAFT
612
613

https://github.com/cablelabs/Streamlined_Onboarding_Demo/blob/nccoerelease/docs/Raspberry_Pi_Deployment.md.

614
615

For interoperability with Build 1, the IoT device’s DPP URI was provided to Aruba Central, which allowed
Build 1 to successfully complete network-layer onboarding with the Build 2 IoT devices.

616

4 Build 3 (BRSKI, Sandelman Software Works)

617
618
619

This section of the practice guide contains detailed instructions for installing and configuring all of the
products used to build an instance of the example solution. For additional details on Build 3’s logical andphysical architectures, see NIST SP 1800-36B: Approach, Architecture, and Security Characteristics.

620
621

The network-layer onboarding component of Build 3 utilizes the Bootstrapping Remote Secure
Infrastructure (BRSKI) protocol. Build 3 is representative of a typical home or small office network.

622

4.1 Onboarding Router/Join Proxy

623
624
625
626
627

The onboarding router quarantines the IoT device attempting to join the network until the BRSKI
onboarding process is complete. The router in this build is a Turris MOX device, which is based on theLinux OpenWrt version 4 operating system (OS). The Raspberry Pi 3 contains software to function as the
Join Proxy for the pledges to the network. If another brand of device is used, a different source ofcompiled Join Proxy might be required.

628

4.1.1 Setup and Configuration

629
630

The router needs to be IPv6 enabled. In the current implementation, the join package operates on an
unencrypted network, but this will be updated in a future version of the build.

631

4.2 Minerva Join Registrar Coordinator

632
633

The purpose of the Join Registrar is to determine whether a new device is allowed to join the network.
The Join Registrar is located on a virtual machine running Devuan Linux 4 within the network.

634

4.2.1 Setup and Configuration

635
636
637

The Minerva Fountain Join Registrar/Coordinator is available as a Docker container and as a VM in OVA
format at: https://minerva.sandelman.ca/fountain/. Further setup and configuration instructions areavailable on the Sandelman website: https://minerva.sandelman.ca/fountain/configuration/.

638

For the Build 3 demonstration, the VM deployment was installed onto a VMware vSphere system.

639

A freshly booted VM image will do the following on its own:

640▪

Configure a database

641▪

Configure a local certificate authority (fountain:s0\_setup\_jrc)

642▪

Configure certificates for the database connection

643▪

Configure certificates for the Registrar https interface

644▪

Configure certificates for use with the Bucardo database replication system

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

20

SECOND PRELIMINARY DRAFT
645▪

Configure certificates for LDevID certification authority (fountain:s2\_create\_registrar)

646▪

Start the JRC

647
648

The root user is permitted to log in on the console ("tty0") using the password “root” but is immediately
forced to set a new password.

649

The new registrar will announce itself with the name minerva-fountain.local in mDNS.

650
651

The logs for this are put into /var/log/configure-fountain-12345.log (where 12345 is a new number
based upon the PID of the script).

652

4.3 Reach Pledge Simulator

653
654
655

The Reach Pledge Simulator acts as an IoT device in Build 3. The pledge is acting as an IoT device joining
the network and is hosted on a Raspberry Pi 3. More information is available on the Sandelman website:
https://minerva.sandelman.ca/reach/.

656

4.3.1 Setup and Configuration

657
658
659

While the functionality of this device is to act as an IoT device, it runs on the same software as the Join
Registrar Coordinator. This software is available in both VM and Docker container format. Please see
Section 4.2.1 for installation instructions.

660
661

When setting up the Reach Pledge Simulator, the address of the Join Registrar Coordinator is
automatically determined by the pledge.

662

Currently, the Reach Pledge Simulator obtains its IDevID using the following steps:

663

1. View the available packages by visiting https://honeydukes.sandelman.ca.

664

2. Open a terminal on the Raspberry Pi device and navigate to the Reach directory by entering:

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

21

SECOND PRELIMINARY DRAFT
665

666
667
668

669
670
671

cd reach

3. Enter the following command while substituting the URL for one of the available zip files
containing the IDevID of choice on https://honeydukes.sandelman.ca.
wget https://honeydukes.sandelman.ca/product_00-D0-E5-02-00-42.zip

4. Unzip the file by entering the following command, substituting the name of your zip file (theIDevID is the device.crt file):
unzip product_00-D0-E5-02-00-42.zip

672
673

In a future implementation of the build, the IDevID will be obtained using the SEALSQ INeS Certificate
Management Service.

674

4.4 Serial Console Server

675
676
677
678
679
680

The serial console server does not participate in the onboarding process but provides direct console
access to the IoT devices. The serial console server has been attached to a multi-port USB hub and USB
connectors and/or USB2TTL adapters connected to each device. The ESP32 and the nRF52840 are bothconnected to the serial console and receive power from the USB hub. Power to the console and IoT
devices is also provided via the USB hub. A BeagleBone Green device was used as the serial console,using the "screen" program as the telecom device.

681

4.5 Minerva Highway MASA Server

682
683
684

In the current implementation of the build, the MASA server provides the Reach Pledge Simulator withan IDevID Certificate and a public/private keypair. In a future version of this build, the public/private
keypair will be generated by the SEALSQ INeS Certificate Management Service.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

22

SECOND PRELIMINARY DRAFT

685

4.5.1 Setup and Configuration

686
687
688

Installation of the Minerva Highway MASA is described athttps://minerva.sandelman.ca/highway/configuration/. Additional configuration details are available athttps://minerva.sandelman.ca/openssl/2022/06/10/configuring-highway-development.html.

689
690

Availability of VMs and containers is described athttps://minerva.sandelman.ca/containers/2018/11/14/minerva-lxd-update.html.

691

4.6 IoT Devices

692
693
694

In the current implementation of the build, onboarding of the IoT devices has not yet been
implemented. Currently, the Reach Pledge Simulator is being utilized to simulate an IoT device joining
the network.

695

4.6.1 Setup/Installation

696
697

The IoT devices need to be provisioned with an IDevID. In a future version of this build, the IDevID will
be provisioned using the SEALSQ INeS Certificate Management System.

698

4.7 SEALSQ Certificate Authority

699
700
701
702

The SEALSQ INeS Certificate Management System provides CA and certificate management capabilities
for Build 3. Implementation of this system will provide Build 3 with a trusted, public CA to support
issuing network credentials. This collaboration is in progress and will be described in a future version ofthis document.

703

5 Build 4 (Thread, Silicon Labs, Kudelski IoT)

704
705

In future releases of this practice guide, this section will contain detailed instructions for installing andconfiguring all of the products used to build an instance of the example solution.

706

6 Build 5 (BRSKI, NquiringMinds)

707
708

In future releases of this practice guide, this section will contain detailed instructions for installing andconfiguring all of the products used to build an instance of the example solution.

709

7 Factory Provisioning Builds

710
711

In future releases of this practice guide, this section will contain detailed instructions for installing andconfiguring all of the products used to build an instance of the example solution.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

23

SECOND PRELIMINARY DRAFT

712

Appendix A

List of Acronyms

AKM

Authentication and Key Management

AOS

ArubaOSAP

Access PointAPI

Application Programming Interface

ASN.1

Abstract Syntax Notation One

AWS

Amazon Web Services

BSS

Basic Service Set

CACertificate Authority

CRADA

Cooperative Research and Development Agreement

CSR

Certificate Signing Request

DMZ

Demilitarized Zone

DPP

Device Provisioning Protocol (Wi-Fi Easy Connect)

EAP

Extensible Authentication Protocol

HPE

Hewlett Packard Enterprise

IaaS

Infrastructure as a Service

IEEE

Institute of Electrical and Electronics Engineers

IoT

Internet of Things

IPv4

Internet Protocol Version 4

IPv6Internet Protocol Version 6

MASA

Manufacturer Authorized Signing Authority

MUD

Manufacturer Usage Description

NCCoE

National Cybersecurity Center of Excellence

NIST

National Institute of Standards and Technology

OCF

Open Connectivity Foundation

OS

Operating System

RFRadio Frequency

SP

Special Publication

SSID

Service Set Identifier

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

24

SECOND PRELIMINARY DRAFT
URI

Uniform Resource Identifier

USB

Universal Serial Bus

UXIUser Experience Insight

VLAN

Virtual Local Area Network

VM

Virtual Machine

WLAN

Wireless Local Area Network

WPA2

Wi-Fi Protected Access 2

WPA3

Wi-Fi Protected Access 3

713

Appendix B

714
715

[1]

References

Wi-Fi Alliance. Wi-Fi Easy Connect. Available: https://www.wi-fi.org/discover-wi-fi/wi-fi-easyconnect.

NIST SP 1800-36C: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management25