NIST SPECIAL PUBLICATION 1800-36B

Trusted Internet of Things (IoT) Device
Network-Layer Onboarding and
Lifecycle Management:
Enhancing Internet Protocol-Based IoT Device and Network
Security
Volume B:
Approach, Architecture, and Security Characteristics
Michael Fagan
Jeffrey Marron
Paul Watrobski
Murugiah Souppaya

Andy Dolan
Kyle Haefner
Craig Pratt
Darshak Thakore

National Cybersecurity Center of Excellence
Information Technology Laboratory

CableLabsLouisville, Colorado

William Barker

Peter Romness

NXP Semiconductors
Mougins, France

Dakota Consulting
Silver Spring, Maryland

Cisco
San Jose, California

Michael Richardson

Chelsea Deane
Joshua Klosterman
Charlie Rearick
Blaine Mulugeta
Susan Symington

Tyler Baker
David Griego

The MITRE Corporation
McLean, Virginia

Dan Harkins
Danny Jump

Foundries.io
London, United Kingdom

Brecht Wyseur
Kudelski IoT
Cheseaux-sur-Lausanne,
Switzerland

Alexandru Mereacre
Nick Allott
NquiringMinds
South Hampton, United Kingdom

Julien Delplancke

Sandelman Software Works
Ontario, Canada

Steve Clark
SEALSQ, a subsidiary of WISeKey
Geneva, Switzerland

Mike Dow
Steve Egerter
Silicon LabsAustin, Texas

Aruba, a Hewlett Packard Enterprise Company
San Jose, California

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.

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

10

FEEDBACK

11
12
13
14
15
16
17
18
19
20
21

You can improve this guide by contributing feedback regarding which aspects of it you find helpful aswell as suggestions on how it might be improved. Should we provide guidance summaries that target
specific audiences? What trusted IoT device onboarding protocols and related features are mostimportant to you? Is there some content that is not included in this document that we should cover? Are
we missing anything in terms of technologies or use cases? In what areas would it be most helpful for us
to focus our future related efforts? For example, should we consider implementing builds that onboard
devices supporting Matter and/or the Fast Identity Online (FIDO) Alliance application onboarding
protocol? Should we implement builds that integrate security mechanisms such as device intent,
lifecycle management, supply chain management, attestation, or behavioral analysis? As you review andadopt this solution for your own organization, we ask you and your colleagues to share your experienceand advice with us.

22

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

23

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

24

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

25
26
27
28
29
30

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-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementii

SECOND PRELIMINARY DRAFT

31

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE

32
33
34
35
36
37
38
39
40
41
42
43
44

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.

45
46

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

47

NIST CYBERSECURITY PRACTICE GUIDES

48
49
50
51
52
53

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.

54
55
56

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.

57

KEYWORDS

58
59

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

60

ACKNOWLEDGMENTS

61

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

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

SECOND PRELIMINARY DRAFT

Name

Organization

Eliot Lear

Cisco

George Grey

Foundries.io

David Griego

Foundries.io

Fabien Gremaud

Kudelski IoT

Faith Ryan

The MITRE Corporation

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

Julien Delplancke

NXP Semiconductors

Anda-Alexandra Dorneanu

NXP Semiconductors

Todd Nuzum

NXP Semiconductors

Nicusor Penisoara

NXP Semiconductors

Laurentiu Tudor

NXP Semiconductors

Karen Scarfone

Scarfone Cybersecurity

Pedro Fuentes

SEALSQ, a subsidiary of WISeKeyNIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementiv

SECOND PRELIMINARY DRAFT

62
63
64
65

Name

Organization

Gweltas Radenac

SEALSQ, a subsidiary of WISeKey

Kalvin YangSEALSQ, a subsidiary of WISeKey

The 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:

66

Technology Collaborators

67
68
69
70

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 Labs

71

DOCUMENT CONVENTIONS

72
73
74
75
76
77
78

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.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementv

SECOND PRELIMINARY DRAFT79

CALL FOR PATENT CLAIMS

80
81
82
83
84
85

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.

86
87

ITL may require from the patent holder, or a party authorized to make assurances on its behalf, inwritten or electronic form, either:8889a) 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

90
91
92

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:

93
94

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

95
96

2. without compensation and under reasonable terms and conditions that are demonstrably freeof any unfair discrimination.

97
98
99
100
101

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.

102
103

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.

104

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

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

SECOND PRELIMINARY DRAFT

105

Contents

106

1 Summary .............................................................................................1

107

1.1

Challenge ....................................................................................................................... 1

108

1.2

Solution.......................................................................................................................... 2

109

1.3

Benefits.......................................................................................................................... 3

110
111
112

2 How to Use This Guide .........................................................................3
2.1

Typographic Conventions .............................................................................................. 5

3 Approach .............................................................................................5

113

3.1

Audience ........................................................................................................................ 7

114

3.2

Scope ............................................................................................................................. 8

115

3.3

Assumptions and Definitions......................................................................................... 8

116

3.3.1

Credential Types ........................................................................................................... 8

117

3.3.2

Integrating Security Enhancements ........................................................................... 10

118

3.3.3

Device Limitations ...................................................................................................... 12

119

3.3.4

Specifications Are Still Improving ............................................................................... 12

120

3.4

Collaborators and Their Contributions ........................................................................ 12

121

3.4.1

Aruba, a Hewlett Packard Enterprise Company ......................................................... 14

122

3.4.2

CableLabs .................................................................................................................... 16

123

3.4.3

Cisco ............................................................................................................................ 17

124

3.4.4

Foundries.io ................................................................................................................ 17

125

3.4.5

Kudelski IoT ................................................................................................................. 18

126

3.4.6

NquiringMinds ............................................................................................................ 18

127

3.4.7

NXP Semiconductors .................................................................................................. 19

128

3.4.8

Open Connectivity Foundation (OCF) ......................................................................... 20

129

3.4.9

Sandelman Software Works ....................................................................................... 20130

3.4.10 SEALSQ, a subsidiary of WISeKey ............................................................................... 21

131

3.4.11 VaultIC405 .................................................................................................................. 22132

3.4.12 Silicon Labs.................................................................................................................. 22

133

4 Reference Architecture ...................................................................... 23

134

4.1

Device Manufacture and Factory Provisioning Process .............................................. 25

135

4.2

Device Ownership and Bootstrapping Information Transfer Process ........................ 27

136

4.3

Trusted Network-Layer Onboarding Process .............................................................. 29

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

SECOND PRELIMINARY DRAFT
137

4.4

Trusted Application-Layer Onboarding Process .......................................................... 31

138

4.5

Continuous Verification ............................................................................................... 33

139
140

5 Laboratory Physical Architecture ....................................................... 35
5.1

Shared Environment .................................................................................................... 38

141

5.1.1

Domain Controller ...................................................................................................... 38

142

5.1.2

Jumpbox...................................................................................................................... 38

143

5.2

Build 1 (Wi-Fi Easy Connect, Aruba/HPE) Physical Architecture ................................. 38

144

5.3

Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) Physical Architecture .......................... 39

145

5.4

Build 3 (BRSKI, Sandelman Software Works) Physical Architecture ........................... 40

146

5.5

Build 4 (Thread, Silicon Labs, Kudelski IoT) Physical Architecture .............................. 42

147

5.6

Build 5 (BRSKI, NquiringMinds) Physical Architecture ................................................ 42

148

5.7

BRSKI Factory Provisioning Build Physical Architecture .............................................. 42

149

5.8

Wi-Fi Easy Connect Factory Provisioning Build Physical Architecture ........................ 42

150
151

6 General Findings ................................................................................ 42
6.1

Wi-Fi Easy Connect ...................................................................................................... 42

152

6.1.1

Mutual Authentication ............................................................................................... 42

153

6.1.2

Mutual Authorization ................................................................................................. 42

154

6.1.3

Secure Storage ............................................................................................................ 43

155

6.2

BRSKI ............................................................................................................................ 43

156

6.2.1

Reliance on the Device Manufacturer ........................................................................ 43

157

6.2.2

Mutual Authentication ............................................................................................... 44

158

6.2.3

Mutual Authorization ................................................................................................. 44

159

7 Future Build Considerations ............................................................... 44

160

7.1

Network Authentication .............................................................................................. 44

161

7.2

Device Intent ............................................................................................................... 44

162

7.3

Integration with a Lifecycle Management Service ...................................................... 44

163

7.4

Network Credential Renewal ...................................................................................... 45

164

7.5

Integration with Supply Chain Management Tools..................................................... 45

165

7.6

Attestation ................................................................................................................... 45

166

7.7

Mutual Attestation ...................................................................................................... 45

167

7.8

Behavioral Analysis ...................................................................................................... 45

168

7.9

Device Trustworthiness Scale ...................................................................................... 45

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

SECOND PRELIMINARY DRAFT
169

7.10 Resource Constrained Systems ................................................................................... 46

170

Appendix A List of Acronyms ................................................................. 47

171

Appendix B Glossary .............................................................................. 50

172

Appendix C Build 1 (Wi-Fi Easy Connect, Aruba/HPE) ............................. 51

173

C.1 Technologies ................................................................................................................ 51

174

C.2 Build 1 Architecture ..................................................................................................... 53

175

C.2.1

Build 1 Logical Architecture ........................................................................................ 53

176

C.2.2

Build 1 Physical Architecture ...................................................................................... 55

177

Appendix D Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) ...................... 56

178

D.1 Technologies ................................................................................................................ 56179

D.2 Build 2 Architecture ..................................................................................................... 58

180

D.2.1

Build 2 Logical Architecture ........................................................................................ 58

181

D.2.2

Build 2 Physical Architecture ...................................................................................... 61

182

Appendix E Build 3 (BRSKI, Sandelman Software Works) ....................... 62

183

E.1

Technologies ................................................................................................................ 62

184

E.2

Build 3 Architecture ..................................................................................................... 64

185

E.2.1

Build 3 Logical Architecture ........................................................................................ 64

186

E.2.2

Build 3 Physical Architecture ...................................................................................... 66

187

Appendix F References .......................................................................... 67

188

List of Figures

189

Figure 3-1 Aruba/HPE DPP Onboarding Components......................................................................... 16

190

Figure 3-2 Components for Onboarding an IoT Device that Communicates Using Thread to AWS IoT ..23

191
192

Figure 4-1 Trusted IoT Device Network-Layer Onboarding and Lifecycle Management Logical
Reference Architecture ....................................................................................................24

193

Figure 4-2 IoT Device Manufacture and Factory Provisioning Process................................................. 25

194

Figure 4-3 Device Ownership and Bootstrapping Information Transfer Process ..................................28

195

Figure 4-4 Trusted Network-Layer Onboarding Process .....................................................................30

196

Figure 4-5 Trusted Streamlined Application-Layer Onboarding Process .............................................. 31

197

Figure 4-6 Continuous Verification....................................................................................................34

198

Figure 5-1 NCCoE IoT Onboarding Laboratory Physical Architecture ................................................... 36
NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementix

SECOND PRELIMINARY DRAFT
199

Figure 5-2 Physical Architecture of Build 1 ........................................................................................ 39

200

Figure 5-3 Physical Architecture of Build 2 ........................................................................................ 40

201

Figure 5-4 Physical Architecture of Build 3 ........................................................................................ 41

202

Figure C-1 Logical Architecture of Build 1 .......................................................................................... 54

203

Figure D-1 Logical Architecture of Build 2 .......................................................................................... 59

204

Figure E-1 Logical Architecture of Build 3 .......................................................................................... 65

205

List of Tables

206

Table 3-1 Capabilities and Components Provided by Each Technology Partner/Collaborator .............. 13207

Table C-1 Build 1 Products and Technologies..................................................................................... 51

208

Table D-1 Build 2 Products and Technologies .................................................................................... 56

209

Table E-1 Build 3 Products and Technologies ..................................................................................... 62

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementx

SECOND PRELIMINARY DRAFT

210

1 Summary

211
212
213
214
215
216
217
218

IoT devices are typically connected to a network. As with any other device needing to communicate on a
network securely, an IoT device needs credentials that are specific to that network to help ensure that
only authorized devices can connect to and use the network. A typical commercially available, massproduced IoT device cannot be pre-provisioned with local network credentials by the manufacturer
during the manufacturing process. Instead, the local network credentials will be provisioned to thedevice at the time of its deployment. This practice guide is focused on trusted methods of providing IoT
devices with the network-layer credentials and policy they need to join a network upon deployment, aprocess known as network-layer onboarding.

219
220
221
222
223
224
225
226
227

Establishing trust between a network and an IoT device (as defined in NIST Internal Report 8425) prior toproviding the device with the credentials it needs to join the network is crucial for mitigating the risk ofpotential attacks. There are two possibilities for attack. One is where a device is convinced to join an
unauthorized network, which would take control of the device. The other is where a network is
infiltrated by a malicious device. Trust is achieved by attesting and verifying the identity and posture of
the device and the network before providing the device with its network credentials—a process known
as network-layer onboarding. In addition, scalable, automated mechanisms are needed to safely manage
IoT devices throughout their lifecycles, such as safeguards that verify the security posture of a device
before the device is permitted to execute certain operations.

228
229
230
231

In this practice guide, the National Cybersecurity Center of Excellence (NCCoE) applies standards, bestpractices, and commercially available technology to demonstrate various mechanisms for trusted
network-layer onboarding of IoT devices. This guide shows how to provide network credentials to IoT
devices in a trusted manner and maintain a secure device posture throughout the device lifecycle.

232

1.1

233
234
235
236
237
238

With 40 billion IoT devices expected to be connected worldwide by 2025 [1], it is unrealistic to onboard
or manage these devices by visiting each device and performing a manual action. While it is possible fordevices to be securely provided with their local network credentials at the time of manufacture, thisrequires the manufacturer to customize network-layer onboarding on a build-to-order basis, which
prevents the manufacturer from taking full advantage of the economies of scale that could result frombuilding identical devices for all its customers.

239
240
241
242
243
244
245
246
247
248

The industry lacks scalable, automatic mechanisms to safely manage IoT devices throughout theirlifecycles, and lacks a trusted mechanism for providing IoT devices with their network credentials andpolicy at the time of deployment on the network. It is easy for a network to falsely identify itself, yetmany IoT devices onboard to networks without verifying the network’s identity and ensuring that it istheir intended target network. Also, many IoT devices lack user interfaces, making it cumbersome tomanually input network credentials. Wi-Fi is sometimes used to provide credentials over an open (i.e.,
unencrypted) network, but this onboarding method risks credential disclosure. Most home networks use
a single password shared among all devices, so access is controlled only by the device’s possession of
the password and does not consider a unique device identity or whether the device belongs on the
network. This method also increases the risk of exposing credentials to unauthorized parties. Providing

Challenge

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

1

SECOND PRELIMINARY DRAFT
249
250

unique credentials to each device is more secure, but doing so manually would be resource-intensive
and error-prone, would risk credential disclosure, and cannot be performed at scale.

251
252
253
254
255

Once a device is connected to the network, if it becomes compromised, it can pose a security risk toboth the network and other connected devices. Not keeping such a device current with the most recent
software and firmware updates may make it more susceptible to compromise. The device could also be
attacked through the receipt of malicious payloads. Once compromised, it may be used to attack otherdevices on the network.

256

1.2

257
258
259
260
261
262
263

We need scalable, automated, trusted mechanisms to safely manage IoT devices throughout theirlifecycles to ensure that they remain secure, starting with secure ways to provision devices with their
network credentials, i.e., beginning with network-layer onboarding. Onboarding is a particularly
vulnerable point in the device lifecycle because if it is not performed in a secure manner, then both thedevice and the network are at risk. Networks are at risk of having unauthorized devices connect to them,and devices are at risk of being taken over by networks that are not authorized to onboard or control
them.

264
265
266
267
268
269

The NCCoE has adopted the trusted network-layer onboarding approach to promote automated, trusted
ways to provide IoT devices with unique network credentials and manage devices throughout theirlifecycles to ensure that they remain secure. The NCCoE is collaborating with CRADA consortium
technology providers in a phased approach to develop example implementations of trusted networklayer onboarding solutions. We define a trusted network-layer onboarding solution to be a mechanism
for provisioning network credentials to a device that:

Solution

270▪

provides each device with unique network credentials,

271▪

enables the device and the network to mutually authenticate,272▪

sends devices their network credentials over an encrypted channel,273▪

does not provide any person with access to the network credentials, and274▪

can be performed repeatedly throughout the device lifecycle to enable:275othe device’s network credentials to be securely managed and replaced as needed, and

276
277

o

the device to be securely onboarded to other networks after being repurposed or
resold.

278

The use cases designed to be demonstrated by this project’s implementations include:279▪

trusted network-layer onboarding of IoT devices

280▪

repeated trusted network-layer onboarding of devices to the same or a different network

281
282
283

▪

automatic establishment of an encrypted connection between an IoT device and a trusted
application service (i.e., trusted application-layer onboarding) after the IoT device has
performed trusted network-layer onboarding and used its credentials to connect to the network284▪

policy-based ongoing device authorization

285▪

software-based methods to provision device birth credentials in the factory

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

2

SECOND PRELIMINARY DRAFT
286
287

▪

288

1.3

289
290

This practice guide can benefit both IoT device users and IoT device manufacturers. The guide can help
IoT device users understand how to onboard IoT devices to their networks in a trusted manner to:mechanisms for IoT device manufacturers to provide IoT device purchasers with informationneeded to onboard the IoT devices to their networks (i.e., device bootstrapping information)

Benefits

291▪

Ensure that their network is not put at risk as IoT devices are added to it

292▪

Safeguard their IoT devices from being taken over by unauthorized networks

293▪

Provide IoT devices with unique credentials for network access

294▪

Provide, renew, and replace device network credentials in a secure manner

295
296

▪

Ensure that IoT devices can automatically and securely perform application-layer onboarding
after performing trusted network-layer onboarding and connecting to a network

297▪

Support ongoing protection of IoT devices throughout their lifecycles

298
299
300

This guide can help IoT device manufacturers, as well as manufacturers and vendors of semiconductors,
secure storage components, and network onboarding equipment, understand the desired security
properties for supporting trusted network-layer onboarding and demonstrate mechanisms for:

301
302

▪

Placing unique credentials into secure storage on IoT devices at time of manufacture (i.e., device
birth credentials)

303▪

Installing onboarding software onto IoT devices

304
305

▪

Providing IoT device purchasers with information needed to onboard the IoT devices to their
networks (i.e., device bootstrapping information)

306
307

▪

Integrating support for network-layer onboarding with additional security capabilities to provide
ongoing protection throughout the device lifecycle

308

2 How to Use This Guide

309
310
311
312
313
314
315
316
317

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 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.

318
319
320
321

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.

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

3

SECOND PRELIMINARY DRAFT
322

This guide contains five volumes:

323
324
325

▪

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

326
327

▪

NIST SP 1800-36B: Approach, Architecture, and Security Characteristics – what we built and why(you are here)

328
329
330

▪

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

331
332
333

▪

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,
and the results of demonstrating these use cases with each of the example implementations

334
335
336

▪

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

337

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

338
339

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:

340
341

▪

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

342▪

example solutions built at the NCCoE

343▪

benefits of adopting the example solution

344
345

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.

346
347
348
349
350
351

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).

352
353
354

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 implementations for trusted IoT device
network-layer onboarding and lifecycle management.

355
356
357
358
359
360

IT professionals who want to implement similar solutions will find all volumes of the practice guideuseful. You can use the how-to portion of the guide, NIST SP 1800-36C, to replicate all or parts of thebuilds created in our lab. The how-to portion of the guide provides specific product installation,
configuration, and integration instructions for implementing the example solution. We do not re-create
the product manufacturers’ documentation, which is generally widely available. Rather, we show how
we incorporated the products together in our environment to create an example solution. Also, you canNIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

4

SECOND PRELIMINARY DRAFT
361
362
363
364
365

use Functional Demonstrations, NIST SP 1800-36D, which provides the use cases that have been defined
to showcase 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 thatthe components of each build provide.

366
367
368
369
370
371
372
373

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.

374
375
376
377
378

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
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
iot-onboarding@nist.gov.

379

2.1

380

The following table presents typographic conventions used in this volume.

Typographic Conventions

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.

381

3 Approach

382
383
384
385

This project builds on the document-based research presented in the NIST Draft Cybersecurity White
Paper, Trusted Internet of Things (IoT) Device Network-Layer Onboarding and Lifecycle Management [2].
That paper describes key security and other characteristics of a trusted network-layer onboarding
solution as well as the integration of onboarding with related technologies such as device attestation,

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

5

SECOND PRELIMINARY DRAFT
386
387
388
389

device intent [3][4], and application-layer onboarding. The security and other attributes of theonboarding process that are catalogued and defined in that paper can provide assurance that the
network is not put at risk as new IoT devices are added to it and also that IoT devices are safeguarded
from being taken over by unauthorized networks.

390
391
392
393
394
395
396
397
398
399
400
401

To kick off this project, the NCCoE published a Federal Register Notice [5] inviting technology providers
to participate in demonstrating approaches to deploying trusted IoT device network-layer onboarding
and lifecycle management in home and enterprise networks, with the objective of showing how trusted
IoT device network-layer onboarding can practically and effectively enhance the overall security of IoT
devices and, by extension, the security of the networks to which they connect. The Federal Register
Notice invited technology providers to provide products and/or expertise to compose prototypes.
Components sought included network onboarding components and IoT devices that support trusted
network-layer onboarding protocols; authorization services; supply chain integration services; accesspoints, routers, or switches; components that support device intent management; attestation services;
controllers or application services; IoT device lifecycle management services; and asset management
services. Cooperative Research and Development Agreements (CRADAs) were established with qualified
respondents, and teams of collaborators were assembled to build a variety of implementations.

402
403
404
405
406
407

NIST is following an agile methodology of building implementations iteratively and incrementally,
starting with network-layer onboarding and gradually integrating additional capabilities that improvedevice and network security throughout a managed device lifecycle. The project team began bydesigning a general, protocol-agnostic reference architecture for trusted network-layer onboarding (seeSection 4) and establishing a laboratory infrastructure at the NCCoE to host implementations (seeSection 5).

408
409
410
411
412
413

Five build teams were established to implement trusted network-layer onboarding prototypes, and asixth build team was established to demonstrate multiple builds for factory provisioning activities
performed by an IoT device manufacturer to enable devices to support trusted network-layer
onboarding. Each of the build teams fleshed out the initial architectures of their example
implementations. They then used technologies, capabilities, and components from project collaborators
to begin creating the builds:

414
415
416
417

▪

Build 1 (Wi-Fi Easy Connect, Aruba/HPE) uses components from Aruba, a Hewlett Packard
Enterprise company, to support trusted network-layer onboarding using the Wi-Fi Alliance’s WiFi Easy Connect Specification, Version 2.0 [6] and independent (see Section 3.3.2) applicationlayer onboarding to the Aruba User Experience Insight (UXI) cloud.

418
419
420
421
422

▪

Build 2 (Wi-Fi Easy Connect, CableLabs, OCF) uses components from CableLabs to support
trusted network-layer onboarding using the Wi-Fi Easy Connect protocol that allows
provisioning of per-device credentials and policy management for each device. Build 2 also uses
components from the Open Connectivity Foundation (OCF) to support streamlined (see Section
3.3.2) trusted application-layer onboarding to the OCF security domain.

423
424
425
426

▪

Build 3 (BRSKI, Sandelman Software Works) uses components from Sandelman Software Works
to support trusted network-layer onboarding using the Bootstrapping Remote Secure KeyInfrastructure (BRSKI) [7] protocol and an independent, third-party Manufacturer Authorized
Signing Authority (MASA).

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

6

SECOND PRELIMINARY DRAFT
427
428
429
430

▪

Build 4 (Thread, Silicon Labs, Kudelski IoT) (still in progress) will use components from SiliconLabs to support trusted network-layer onboarding using the Thread Mesh Commissioning
Protocol (MeshCoP) [8] and components from Kudelski IoT to support trusted application-layer
onboarding to the Amazon Web Services (AWS) IoT core.

431
432
433
434
435

▪

Build 5 (BRSKI over Wi-Fi, NquiringMinds) (still in progress) will use components from
Sandelman Software Works to support trusted network-layer onboarding using the BRSKI
protocol over 802.11 [9], and OpenWrt-based open-source components to support trusted
network-layer onboarding using Wi-Fi Easy Connect. Additional components from
NquiringMinds will support ongoing, policy-based, continuous assurance and authorization.

436
437
438
439
440

▪

The BRSKI Factory Provisioning Build (still in progress) will use Raspberry Pi devices and codefrom Sandelman Software Works and secure storage elements, code, and a certificate authority(CA) from SEALSQ, a subsidiary of WISeKey. This build will demonstrate activities forprovisioning IoT devices with their initial (i.e., birth—see Section 3.3) credentials for use with the
BRSKI protocol and for making device bootstrapping information available to device owners.

441
442
443
444
445

▪

The Wi-Fi Easy Connect Factory Provisioning Build (still in progress) will use Raspberry Pi devices
and code from Aruba and secure storage elements, code, and a CA from SEALSQ, a subsidiary of
WISeKey. This build will demonstrate activities for provisioning IoT devices with their birthcredentials for use with the Wi-Fi Easy Connect protocol and for making device bootstrapping
information available to device owners.

446
447
448

At this time, only builds 1, 2, and 3 of the trusted network-layer onboarding implementations have been
completed and are documented in this draft practice guide. The remaining builds are planned forinclusion as they are completed in future versions of the guide.

449
450
451

Each build team documented the architecture and design of its build (see Appendix C, Appendix D, andAppendix E). As each build progressed, its team also documented the steps taken to install and configure
each component of the build (see NIST SP 1800-36C).

452
453
454

The project team then designed a set of use case scenarios designed to showcase the builds’ security
capabilities. Each build team conducted a functional demonstration of its build by running the build
through the defined scenarios and documenting the results (see NIST SP 1800-36D).

455
456
457
458

The project team also conducted a risk assessment and a security characteristic analysis anddocumented the results, including a mapping of the security capabilities of the reference solution to the
Framework for Improving Critical Infrastructure Cybersecurity (NIST Cybersecurity Framework) [10] andother relevant guidelines and recommended practices (see NIST SP 1800-36E).

459
460
461

Finally, the NCCoE worked with industry and standards developing organization collaborators to distill
their findings and consider potential enhancements to future support for trusted IoT device networklayer onboarding (see Section 6 and Section 7).

462

3.1

463

The intended audience for this practice guide includes:

Audience464▪

IoT device manufacturers, integrators, and vendors

465▪

Semiconductor manufacturers and vendors

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

7

SECOND PRELIMINARY DRAFT
466▪

Secure storage manufacturers

467▪

Network equipment manufacturers

468▪

IoT device owners and users

469
470

▪

Owners and administrators of networks (both home and enterprise) to which IoT devices
connect

471
472

▪

Service providers (internet service providers/cable operators and application platform
providers)

473

3.2

474
475
476
477
478
479
480

This project focuses on the trusted network-layer onboarding of IoT devices in both home andenterprise environments. Enterprise, consumer, and industrial use cases for trusted IoT device networklayer onboarding are all considered to be in scope at this time. The project encompasses trusted
network-layer onboarding of IoT devices deployed across different Internet Protocol (IP) based
environments using wired, Wi-Fi, and broadband networking technologies. The project addresses
onboarding of IP-based devices in the initial phase and will consider using technologies such as Zigbee orBluetooth in future phases of this project.

481
482
483
484
485
486
487
488
489
490
491

The project’s scope also includes security technologies that can be integrated with and enhanced by thetrusted network-layer onboarding mechanism to protect the device and its network throughout thedevice’s lifecycle. Examples of these technologies include supply chain management, device attestation,
trusted application-layer onboarding, device intent enforcement, device lifecycle management, asset
management, the dynamic assignment of devices to various network segments, and ongoing device
authorization. Aspects of these technologies that are relevant to their integration with network-layer
onboarding are within scope. Demonstration of the general capabilities of these technologies
independent of onboarding is not within the project’s scope. For example, demonstrating a policy that
requires device attestation to be performed before the device will be permitted to be onboarded would
be within scope. However, the details and general operation of the device attestation mechanism would
be out of scope.

492

3.3

493

This project is guided by a variety of assumptions, which are categorized by subsection below.

494

3.3.1

495
496
497
498
499
500
501

There are several different credentials that may be related to any given IoT device, which makes it
important to be clear about which credential is being referred to. Two types of IoT device credentials are
involved in the network-layer onboarding process: birth credentials and network credentials. Birthcredentials are installed onto the device before it is released into the supply chain; trusted networklayer onboarding solutions leverage birth credentials to authenticate devices and securely provision
them with their network credentials. If supported by the device and the application service provider,application-layer credentials may be provisioned to the device after the device performs network-layer

Scope

Assumptions and Definitions
Credential Types

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

8

SECOND PRELIMINARY DRAFT
502
503
504
505
506
507
508
509
510

onboarding and connects to the network, during the application-layer onboarding process. These
different types of IoT device credentials are defined as follows:▪

511

Birth Credential: In order to participate in trusted network-layer onboarding, devices must be
equipped with a birth credential, which is sometimes also referred to as a device birth identity
or birth certificate. A birth credential is a unique, authoritative credential that is generated or
installed into secure storage on the IoT device during the pre-market phase of the device’s
lifecycle, i.e., before the device is released for sale. A manufacturer, integrator, or vendor
typically generates or installs the birth credential onto an IoT device in the form of an Initial
Device Identifier (IDevID) [11] and/or a public/private keypair.
Birth credentials:

512oare permanent, and their value is independent of context;

513
514

o

enable the trusted network-layer onboarding process while keeping the device
manufacturing process efficient; and

515
516

o

include a unique identity and a secret and can range from simple raw public and private
keys to X.509 certificates that are signed by a trusted authority.

517
518
519
520
521

▪

Network Credential: A network credential is the credential that is provisioned to an IoT device
during network-layer onboarding. The network credential enables the device to connect to the
local network securely. A device’s network credential may be changed repeatedly, as needed, by
subsequent invocation of the trusted network-layer onboarding process.

Additional types of credentials that may also be associated with an IoT device are:

522
523
524
525
526
527

▪

Application-Layer Credential: An application-layer credential is a credential that is provisioned
to an IoT device during application-layer onboarding. After an IoT device has performed
network-layer onboarding and connected to a network, it may be provisioned with one or more
application-layer credentials during the application-layer onboarding process. Each applicationlayer credential is specific to a given application and is typically unique to the device, and it may
be replaced repeatedly over the course of the device’s lifetime.

528
529
530
531
532
533

▪

User Credential: An IoT device that permits authorized users to access it and restricts accessonly to authorized users will have one or more user credentials associated with it. Thesecredentials are what the users present to the IoT device in order to gain access to it. The user
credential is not relevant during network-layer onboarding and is generally not of interest within
the scope of this project. We include it in this list only for completeness. Many IoT devices may
not even have user credentials associated with them.

534
535
536
537
538
539
540
541
542
543

In order to perform network- and application-layer onboarding, the device being onboarded mustalready have been provisioned with birth credentials. A pre-provisioned, unique, authoritative birthcredential is essential for enabling the IoT device to be identified and authenticated as part of thetrusted network-layer onboarding process, no matter what network the device is being onboarded to or
how many times it is onboarded. The value of the birth credential is independent of context, whereas
the network credential that is provisioned during network-layer onboarding is significant only withrespect to the network to which the IoT device will connect. Each application-layer credential that isprovisioned during application-layer onboarding is specific to a given application, and each user
credential is specific to a given user. A given IoT device only ever has one birth credential over thecourse of its lifetime, and the value of this birth credential remains unchanged. However, that IoT device
NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

9

SECOND PRELIMINARY DRAFT
544
545

may have any number of network, application-layer, and user credentials at any given point in time, andthese credentials may be replaced repeatedly over the course of the device’s lifetime.

546

3.3.2

547
548
549

Integrating trusted network-layer IoT device onboarding with additional security mechanisms andtechnologies can help increase trust in both the IoT device and the network to which it connects.
Examples of such security mechanism integrations demonstrated in this project include:

550
551
552
553
554
555
556
557
558

▪

Integrating Security Enhancements

Trusted application-layer onboarding: When supported, application-layer onboarding can be
performed automatically after a device has connected to its local network. Trusted applicationlayer onboarding enables a device to be securely provisioned with the application-layer
credentials it needs to establish a secure association with a trusted application service. In manycases, a network’s IoT devices will be so numerous that manually onboarding devices at theapplication-layer would not be practical; in addition, dependence on manual application-layer
onboarding would leave the devices vulnerable to accidental or malicious misconfiguration. So
application-layer onboarding, like network-layer onboarding, is fundamental to ensuring theoverall security posture of each IoT device.

559
560
561
562
563
564
565
566
567

As part of the application-layer onboarding process, devices and the application services withwhich they interact perform mutual authentication and establish an encrypted channel overwhich the application service can download application-layer credentials and software to thedevice and the device can provide information to the application service, as appropriate.
Application-layer onboarding is useful for ensuring that IoT devices are executing the most upto-date versions of their intended applications. It can also be used to establish a secure
association between a device and a trusted lifecycle management service, which will ensure that
the IoT device continues to be patched and updated with the latest firmware and software,
thereby enabling the device to remain trusted throughout its lifecycle.

568
569
570
571
572
573
574
575

Network-layer onboarding cannot be performed until after network-layer bootstrapping
information has been introduced to the device and the network. This network-layerbootstrapping information enables the device and the network to mutually authenticate andestablish a secure channel. Analogously, application-layer onboarding cannot be performed until
after application-layer bootstrapping information has been introduced to the device and theapplication servers with which they will onboard. This application-layer bootstrapping
information enables the device and the application server to mutually authenticate andestablish a secure channel.

576
577
578
579
580
581
582
583
584
585
586
587

o

Streamlined Application-Layer Onboarding—One potential mechanism for introducing
this application-layer bootstrapping information to the device and the application serveris to use the network-layer onboarding process. The secure channel that is establishedduring network-layer onboarding can serve as the mechanism for exchanging
application-layer bootstrapping information between the device and the application
server. By safeguarding the integrity and confidentiality of the application-layerbootstrapping information as it is conveyed between the device and the application
server, the trusted network-layer onboarding mechanism helps to ensure that
information that the device and the application server use to authenticate each other istruly secret and known only to them, thereby establishing a firm foundation for theirsecure association. In this way, trusted network-layer onboarding can provide a securefoundation for trusted application-layer onboarding. We call an application-layer

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

10

SECOND PRELIMINARY DRAFT
588
589

onboarding process that uses network-layer onboarding to exchange application-layerbootstrapping information streamlined application-layer onboarding.
o

590
591
592
593
594
595
596
597
598
599
600
601

Independent Application-Layer Onboarding—An alternative mechanism for introducing
application-layer bootstrapping information to the device is to provide this information
to the device during the manufacturing process. During manufacturing, the IoT device
can be provisioned with software and associated bootstrapping information thatenables the device to mutually authenticate with an application-layer service after it hasconnected to the network. This mechanism for performing application-layer onboarding
does not rely on the network-layer onboarding process to provide application-layerbootstrapping information to the device. All that is required is that the device haveconnectivity to the application-layer onboarding service after it has connected to the
network. We call an application-layer onboarding process that does not rely on
network-layer onboarding to exchange application-layer bootstrapping information
independent application-layer onboarding.

602
603
604
605
606
607
608
609
610
611
612
613
614
615

▪

Segmentation: Upon connection to the network, a device may be assigned to a particular local
network segment to prevent it from communicating with other network components, as
determined by enterprise policy. The device can be protected from other local network
components that meet or do not meet certain policy criteria. Similarly, other local network
components may be protected from the device if it meets or fails to meet certain policy criteria.
A trusted network-layer onboarding mechanism may be used to convey information about thedevice that can be used to determine to which network segment it should be assigned uponconnection. By conveying this information in a manner that protects its integrity andconfidentiality, the trusted network-layer onboarding mechanism helps to increase assurance
that the device will be assigned to the appropriate network segment. Post-onboarding, if a
device becomes untrustworthy, for example because it is found to have software that has aknown vulnerability or misconfiguration, or because it is behaving in a suspicious manner, thedevice may be dynamically assigned to a different network segment as a means of quarantining
it.

616
617
618
619
620
621
622
623
624
625
626

▪

Ongoing Device Authorization: Once a device has been network-layer onboarded in a trusted
manner and has possibly performed application-layer onboarding as well, it is important that as
the device continues to operate on the network, it maintains a secure posture throughout its
lifecycle. Ensuring the ongoing security of the device is important for keeping the device frombeing corrupted and for protecting the network from a potentially harmful device. Even thougha device is authenticated and authorized prior to being onboarded, it is recommended that thedevice be subject to ongoing, policy-based authentication and authorization as it continues tooperate on the network. This may include monitoring device behavior and constraining
communications to and from the device as needed in accordance with policy. In this manner, an
ongoing device authorization service can ensure that the device and its operations continue tobe authorized throughout the device’s tenure on the network.

627
628
629
630
631
632
633

▪

Additional Security Mechanisms: Although not demonstrated in the implementations that havebeen built in this project so far, numerous additional security mechanisms can potentially be
integrated with network-layer onboarding, beginning at device boot-up and extending throughall phases of the device lifecycle. Examples of such mechanisms include integration with supply
chain management tools, device attestation, device communications intent enforcement,
automated lifecycle management, mutual attestation, and centralized asset management.
Overall, application of these and other security protections can create a dependency chain of

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

11

SECOND PRELIMINARY DRAFT
634
635
636
637
638

protections. This chain is based on a hardware root of trust as its foundation and extends up to
support the security of the trusted network-layer onboarding process. The trusted networklayer onboarding process in turn may enable additional capabilities and provide a foundationthat makes them more secure, thereby helping to ensure the ongoing security of the device and,by extension, the network.

639

3.3.3

640
641
642
643
644
645
646
647

The security capabilities that any onboarding solution will be able to support will depend in part on the
hardware, processing power, cryptographic modules, secure storage capacity, battery life, humaninterface (if any), and other capabilities of the IoT devices themselves, such as whether they support
verification of firmware at boot time, attestation, application-layer onboarding, and device
communications intent enforcement; what onboarding and other protocols they support; and whether
they are supported by supply-chain tools. The more capable the device, the more security capabilities itshould be able to support and the more robustly it should be able to support them. Depending on bothdevice and onboarding solution capabilities, different levels of assurance may be provided.

648

3.3.4

649
650
651
652
653

Ideally, trusted network-layer onboarding solutions selected for widespread implementation and use
will be openly available and standards-based. Some potential solution specifications are still being
improved. In the meantime, their instability may be a limiting factor in deploying operational
implementations of the proposed capabilities. For example, the details of running BRSKI over Wi-Fi arenot fully specified at this time.

654

3.4

655
656
657
658
659

Organizations participating in this project submitted their capabilities in response to an open call in theFederal Register for all sources of relevant security capabilities from academia and industry (vendors
and integrators). Listed below are the respondents with relevant capabilities or product components(identified as “Technology Partners/Collaborators” herein) who signed a CRADA to collaborate with NIST
in a consortium to build example trusted IoT device network-layer onboarding solutions.

660

Technology Collaborators

661
662
663
664

Device Limitations

Specifications Are Still Improving

Collaborators and Their Contributions

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-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

12

SECOND PRELIMINARY DRAFT
665
666

Table 3-1 summarizes the capabilities and components provided, or planned to be provided, by eachpartner/collaborator.

667

Table 3-1 Capabilities and Components Provided by Each Technology Partner/Collaborator
Collaborator

Security Capability or Component Provided

Aruba

Infrastructure for trusted network-layer onboarding using the Wi-Fi Easy
Connect protocol and application-layer onboarding to the UXI cloud. IoT devices
for use with both Wi-Fi Easy Connect network-layer onboarding and applicationlayer onboarding. The UXI Dashboard provides for an “always-on” remotetechnician with near real-time data insights into network and application
performance.

CableLabs

Infrastructure for trusted network-layer onboarding using the Wi-Fi Easy
Connect protocol. IoT devices for use with both Wi-Fi Easy Connect networklayer onboarding and application-layer onboarding to the OCF security domain.

Cisco

Networking components to support various builds.

Foundries.io

Factory software for providing birth credentials into secure storage on IoT
devices and for transferring device bootstrapping information from device
manufacturer to device purchaser.

Kudelski IoT

Infrastructure for trusted application-layer onboarding of a device to the AWS
IoT core. The service comes with a cloud platform and a software agent thatenables secure provisioning of AWS credentials into secure storage of IoT
devices.

NquiringMinds

Service that performs ongoing monitoring of connected devices to ensure theircontinued authorization (i.e., continuous authorization service).

NXP
Semiconductors

IoT devices with secure storage for use with both Wi-Fi Easy Connect and BRSKI
network-layer onboarding. Service for provisioning credentials into securestorage of IoT devices.

Open Connectivity
Foundation (OCF)

Infrastructure for trusted application-layer onboarding to the OCF security
domain using IoTivity, an open-source software framework that implements the
OCF specification.

Sandelman
Software Works

Infrastructure for trusted network-layer onboarding using BRSKI. Factory
provisioning code that sends device ownership information and the device
certificate to the MASA.

SEALSQ, a
subsidiary of
WISeKey

Secure storage elements, code, and software that simulates factory provisioningof birth credentials to those secure elements on IoT devices in support of both
Wi-Fi Easy Connect and BRSKI network-layer onboarding; certificate authority
for signing device certificates.

Silicon Labs

Infrastructure for connection to a Thread network that has access to othernetworks for application-layer onboarding. IoT device with secure storage foruse with Thread network connection and application-layer onboarding using
Kudelski IoT.

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

13

SECOND PRELIMINARY DRAFT
668
669
670
671

Each of these technology partners and collaborators has described the relevant products andcapabilities it brings to this trusted onboarding effort in the following subsections. The NCCoE does notcertify or validate products or services. We demonstrate the capabilities that can be achieved by using
participants’ contributed technology.

672

3.4.1

673
674
675
676
677
678
679
680
681
682

Aruba, a Hewlett Packard Enterprise (HPE) company, provides secure, intelligent edge-to-cloud
networking solutions that use artificial intelligence (AI) to automate the network, while harnessing data
to drive powerful business outcomes. With Aruba ESP (Edge Services Platform) and as-a-service options
as part of the HPE GreenLake family, Aruba takes a cloud-native approach to helping customers meettheir connectivity, security, and financial requirements across campus, branch, data center, and remoteworker environments, covering all aspects of wired, wireless local area networking (LAN), and wide area
networking (WAN). Aruba ESP provides unified solutions for connectivity, visibility, and control
throughout the IT-IoT workflow, with the objective of helping organizations accelerate IoT-driven digitaltransformation with greater ease, efficiency, and security. To learn more, visit Aruba at
https://www.arubanetworks.com/.

683

3.4.1.1

684
685
686
687
688
689

Device Provisioning Protocol (DPP), certified under the Wi-Fi Alliance as “Easy Connect,” is a standard
developed by Aruba that allows IoT devices to be easily provisioned onto a secure network. DPP
improves security by leveraging Wi-Fi Protected Access 3 (WPA3) to provide device-specific credentials,
enhance certificate handling, and support robust, secure, and scalable provisioning of IoT devices in any
commercial, industrial, government, or consumer application. Aruba implements DPP through a
combination of on-premises hardware and cloud-based services as shown in Figure 3-1.

690

3.4.1.2

691
692
693
694
695

From their unique vantage as ceiling furniture, Aruba Wi-Fi 6 APs have an unobstructed overhead viewof all nearby devices. Built-in Bluetooth Low Energy (BLE) and Zigbee 802.15.4 IoT radios, as well as aflexible USB port, provide IoT device connectivity that allows organizations to address a broad range of
IoT applications with infrastructure already in place, eliminating the cost of gateways and IoT overlay
networks while enhancing IoT security.

696
697
698
699
700

Aruba’s APs enable a DPP network through an existing Service Set Identifier (SSID) enforcing DPP access
control and advertising the Configurator Connectivity Information Element (IE) to attract unprovisioned
clients (i.e., clients that have not yet been onboarded). Paired with Aruba’s cloud management service“Central”, the APs implement the DPP protocol. The AP performs the DPP network introduction protocol(Connector exchange) with provisioned clients and assigns network roles.

701

3.4.1.3

702
703
704
705
706

Aruba Central is a cloud-based networking solution with AI-powered insights, workflow automation, andedge-to-cloud security that empowers IT teams to manage and optimize campus, branch, remote, data
center, and IoT networks from a single point of visibility and control. Built on a cloud-native,
microservices architecture, Aruba Central is designed to simplify IT and IoT operations, improve agility,
and reduce costs by unifying management of all network infrastructure.

Aruba, a Hewlett Packard Enterprise Company

Device Provisioning Protocol

Aruba Access Point (AP)Aruba Central

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

14

SECOND PRELIMINARY DRAFT
707
708
709
710
711

Aruba’s “Central” Cloud DPP service exposes and controls many centralized functions to enable aseamless integrated end-to-end solution and act as a DPP service orchestrator. The cloud-based DPP
service selects an AP to authenticate unprovisioned enrollees (in the event that multiple APs receive theclient chirps). The DPP cloud service holds the Configurator signing key and generates Connectors forenrollees authenticated through an AP.

712

3.4.1.4

713
714
715
716

Available within Aruba Central, the IoT Operations service extends network administrators’ view into IoT
devices and applications connected to the network. Organizations can gain critical visibility into
previously invisible IoT devices, as well as reduce costs and complexity associated with deploying IoTapplications. IoT Operations comprises three core elements:

IoT Operations

717
718

▪

IoT Dashboard, which provides a granular view of devices connected to Aruba APs, as well as IoT
connectors and applications in use.

719
720

▪

IoT App Store, a repository of click-and-go IoT applications that interface with IoT devices andtheir data.

721
722

▪

IoT Connector, which provisions multiple applications to be computed at the edge for agile IoT
application support.

723

3.4.1.5

724
725
726
727
728

Part of Aruba Central, AI-powered Client Insights automatically identifies each endpoint connecting to
the network with up to 99% accuracy. Client Insights discovers and classifies all connected endpoints—
including IoT devices—using built-in machine learning and dynamic profiling techniques, helping
organizations better understand what’s on their networks, automate access privileges, and monitor the
behavior of each endpoint’s traffic flows to more rapidly spot attacks and act.

729

3.4.1.6

730
731
732
733
734

Cloud-native network access control (NAC) solution Cloud Auth delivers time-saving workflows to
configure and manage onboarding, authorization, and authentication policies for wired and wirelessnetworks. Cloud Auth integrates with an organization’s existing cloud identity store, such as Google
Workspace or Azure Active Directory, to authenticate IoT device information and assign the right level of
network access.

735
736
737
738
739
740

Cloud Auth operates as the DPP Authorization server and is the repository for trusted DPP Uniform
Resource Identifiers (URIs) of unprovisioned enrollees. It maintains role information for each
unprovisioned DPP URI and for provisioned devices based on unique per-device credential (public key
extracted from Connector). Representational State Transfer (RESTful) application programming
interfaces (APIs) provide extensible capabilities to support third parties, making an easy path for
integration and collaborative deployments.

741

3.4.1.7

742
743
744

User Experience Insight (UXI) sensors continuously monitor end-user experience on customer networks
and provide a simple-to-use cloud-based dashboard to assess networks and applications. The UXI sensor
is onboarded in a zero-touch experience using DPP. Once network-layer onboarding is complete, the UXIClient Insights

Cloud AuthUXI Sensor: DPP Enrollee

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

15

SECOND PRELIMINARY DRAFT
745
746
747

sensor performs application-layer onboarding to the Aruba cloud to download a customer-specificprofile. This profile enables the UXI sensor to perform continuous network testing and monitoring, andto troubleshoot network issues that it finds.

748

Figure 3-1 Aruba/HPE DPP Onboarding Components

749

3.4.2

750
751
752
753
754

CableLabs is an innovation lab for future-forward research and development (R&D)—a global meeting ofminds dedicated to building and orchestrating emergent technologies. By convening peers and experts
to share knowledge, CableLabs’s objective is to energize the industry ecosystem for speed and scale. Its
research facilitates solutions with the goal of making connectivity faster, easier, and more secure, andits conferences and events offer neutral meeting points to gain consensus.

755
756
757

As part of this project, CableLabs has provided the reference platform for its Custom Connectivity
architecture for the purpose of demonstrating trusted network-layer onboarding of Wi-Fi devices using
a variety of credentials. The following components are part of the reference platform.

758

3.4.2.1

759
760
761
762
763

The controller provides interfaces and messaging for managing service deployment groups, accesspoints with the deployment groups, registration and lifecycle of user services, and the secure
onboarding and lifecycle management of users’ Wi-Fi devices. The controller also exposes APIs for
integration with third-party systems for the purpose of integrating various business flows (e.g.,
integration with manufacturing process for device management).

CableLabs

Platform Controller

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

16

SECOND PRELIMINARY DRAFT
764

3.4.2.2

Custom Connectivity Gateway Agent

765
766
767
768
769
770
771
772
773

The Gateway Agent is a software component that resides on the Wi-Fi AP and gateway. It connects withthe controller to coordinate the Wi-Fi and routing capabilities on the gateway. Specifically, it enforces
the policies and configuration from the controller by managing the lifecycle of the Wi-Fi Extended
Service Set/Basic Service Set (ESS/BSS) on the AP, authentication and credentials of the client devices
that connect to the AP, and service management and routing rules for various devices. It also manages
secure onboarding capabilities like Easy Connect, simple onboarding using a per-device pre-shared key(PSK), etc. The Gateway agent is provided in the form of an operational Raspberry Pi-based Gatewaythat also includes hostapd for Wi-Fi/DPP and open-vswitch for the creation of trust-domains androuting.

774

3.4.2.3

775
776
777
778

Three Raspberry Pi-based reference clients are provided. The reference clients have support for Wi-Fi
Alliance (WFA) Easy Connect-based onboarding as well as support for different Wi-Fi credentials,
including per-device PSK and 802.1x certificates. One of the reference clients also has support for OCFbased streamlined application-layer onboarding.

779

3.4.3

780
781
782
783
784
785
786
787
788

Cisco Systems, or Cisco, delivers collaboration, enterprise, and industrial networking and security
solutions. The company’s cybersecurity team, Cisco Secure, is one of the largest cloud and network
security providers in the world. Cisco’s Talos Intelligence Group, the largest commercial threat
intelligence team in the world, is comprised of world-class threat researchers, analysts, and engineers,and supported by unrivaled telemetry and sophisticated systems. The group feeds rapid and actionable
threat intelligence to Cisco customers, products, and services to help identify new threats quickly anddefend against them. Cisco solutions are built to work together and integrate into your environment,using the “network as a sensor” and “network as an enforcer” approach to both make your team more
efficient and keep your enterprise secure. Learn more about Cisco at https://www.cisco.com/go/secure.

789

3.4.3.1

790
791

A Cisco Catalyst switch is provided to support network connectivity and network segmentation
capabilities.

792

3.4.4

793
794
795
796
797
798
799
800

Foundries.io helps organizations bring secure IoT and edge devices to market faster. The
FoundriesFactory cloud platform offers DevOps teams a secure Linux-based firmware/operating system(OS) platform with device and fleet management services for connected devices, based on a fixed noroyalty subscription model. Product development teams gain enhanced security from boot to cloud
while reducing the cost of developing, deploying, and updating devices across their installed lifetime.
The open-source platform interfaces to any cloud and offers Foundries.io customers maximum flexibility
for hardware configuration, so organizations can focus on their intellectual property, applications, andvalue add. For more information, please visit https://foundries.io/.

Reference Clients

Cisco

Cisco Catalyst Switch

Foundries.io

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

17

SECOND PRELIMINARY DRAFT
801

3.4.4.1

FoundriesFactory

802
803
804
805

FoundriesFactory is a cloud-based software platform provided by Foundries.io that offers a complete
development and deployment environment for creating secure IoT devices. It provides a set of tools andservices that enable developers to create, test, and deploy custom firmware images, as well as manage
the lifecycle of their IoT devices.

806
807
808
809
810

Customizable components include open-source secure boot software, the open-source LinuxmicroPlatform (LmP) distribution built with Yocto and designed for secure managed IoT and edge
products, secure Over the Air (OTA) update facilities, and a Docker runtime for managing containerized
applications and services. The platform is cross architecture (x86, Arm, and RISC-V) and enables secureconnections to public and private cloud services.

811
812
813

Leveraging open standards and open software, FoundriesFactory is designed to simplify and accelerate
the process of developing, deploying, and managing IoT and edge devices at scale, while also ensuringthat they are secure and up-to-date over the product lifetime.

814

3.4.5

815
816
817
818
819
820

Kudelski IoT is the Internet of Things division of Kudelski Group and provides end-to-end IoT solutions,IoT product design, and full-lifecycle services to IoT semiconductor and device manufacturers,
ecosystem creators, and end-user companies. These solutions and services leverage the group’s 30+
years of innovation in digital business model creation; hardware, software, and ecosystem design andtesting; state-of-the-art security lifecycle management technologies and services; and managed
operation of complex systems.

821

3.4.5.1

822
823
824
825
826
827

Kudelski IoT keySTREAM is a device-to-cloud, end-to-end solution for securing all the key assets of an IoT
ecosystem during its entire lifecycle. The system provides each device with a unique, immutable,
unclonable identity that forms the foundation for critical IoT security functions like in-factory or in-fieldprovisioning, data encryption, authentication, and secure firmware updates, as well as allowing
companies to revoke network access for vulnerable devices if necessary. This ensures that the entire
lifecycle of the device and its data can be managed.

828
829

In this project, keySTREAM is used to enable application-layer onboarding. It manages the attestation ofdevices, ownership, and provisioning of application credentials.

830

3.4.6

831
832
833
834
835
836

NquiringMinds provides intelligent trusted systems, combining AI-powered analytics with strong cybersecurity fundamentals. tdx Volt is the NquiringMinds general-purpose zero-trust services infrastructure
platform, upon which it has built Cyber tdx, a cognitively enhanced cyber defense service designed for
IoT. Both products are the latest iteration of the TDX product family. NquiringMinds is a UK company.
Since 2010, it has been deploying its solutions into smart cities, health care, industrial, agricultural,
financial technology, defense, and security sectors.

837
838

NquiringMinds collaborates extensively within the open standards and open-source community. It
focuses on the principle of continuous assurance: the ability to continually reassess security risk by

Kudelski IoT

Kudelski IoT keySTREAM™

NquiringMinds

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

18

SECOND PRELIMINARY DRAFT
839
840
841

intelligently reasoning across the hard and soft information sources available. NquiringMinds’ primarycontributions to this project, described in the subsections below, are being made available as open
source.

842

3.4.6.1

843
844
845
846
847
848
849
850
851
852

edgeSEC is an open-source, OpenWrt-based implementation of an intelligent secure router. It
implements, on an open stack, the key components needed to implement both trusted onboarding andcontinuous assurance of devices. It contains an implementation of the Internet Engineering Task Force(IETF) BRSKI protocols, with the necessary adaptations for wireless onboarding, fully integrated into an
open operational router. It additionally implements intent constraints (IETF Manufacturer Usage
Description [MUD]) and behavior monitoring (IoTSF ManySecured) that support some of the moreenhanced trusted onboarding use cases. edgeSEC additionally provides the platform for an
asynchronous control plane for the continuous management of multiple routers and a general-purpose
policy evaluation point, which can be used to demonstrate the breadth of onboarding and monitoringuse cases that can be supported.

853

3.4.6.2

854
855
856
857
858

tdx Volt is NquiringMinds’s zero-trust infrastructure platform. It encapsulates identity management,
credential management, service discovery, and smart policy evaluation. This platform is designed tosimplify the end-to-end demonstration of the trusted onboarding process and provides tools for use on
the IoT device, the router, applications, and clouds. tdx Volt integrates with the open source edgeSEC
router.

859

3.4.7

860
861
862
863
864

NXP Semiconductors strives to enable a smarter, safer, and more sustainable world through innovation.
With its focus on secure connectivity solutions for embedded applications, NXP is impacting theautomotive, industrial, and IoT, mobile, and communication infrastructure markets. Built on more than
60 years of combined experience and expertise, the company has approximately 31,000 employees inmore than 30 countries. Find out more at https://www.nxp.com/.

865

3.4.7.1

866
867
868
869
870

The EdgeLock SE050 secure element (SE) product family offers strong protection against the latest
attack scenarios and an extended feature set for a broad range of IoT use cases. This ready-to-use
secure element for IoT devices provides a root of trust at the silicon level and delivers real end-to-end
security – from edge to cloud – with a comprehensive software package for integration into any type ofdevice.

871

3.4.7.2

872
873
874
875
876

EdgeLock 2GO is the NXP service platform designed for easy and secure deployment and managementof IoT devices. This flexible IoT service platform lets the device manufacturers and service providers
choose the appropriate options to optimize costs while benefiting from an advanced level of device
security. The EdgeLock 2GO service provisions the cryptographic keys and certificates into the hardware
root of trust of the IoT devices and simplifies the onboarding of the devices to the cloud.

edgeSEC

tdx Volt

NXP Semiconductors

EdgeLock SE050 secure element

EdgeLock 2GO

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

19

SECOND PRELIMINARY DRAFT
877

3.4.7.3

i.MX 8M family

878
879
880
881
882
883

The i.MX 8M family of applications processors based on Arm® Cortex®-A53 and Cortex-M4 cores provide
advanced audio, voice, and video processing for applications that scale from consumer home audio toindustrial building automation and mobile computers. It includes support for secure boot, secure debug,
and lifecycle management, as well as integrated cryptographic accelerators. The development boards
and Linux Board Support Package enablement provide out-of-the-box integration with an external SE050
secure element.

884

3.4.8

885
886
887
888
889
890
891

OCF is a standards developing organization that has had contributions and participation from over 450+
member organizations representing the full spectrum of the IoT ecosystem, from chip makers to
consumer electronics manufacturers, silicon enablement software platform and service providers, andnetwork operators. The OCF specification is an International Organization forStandardization/International Electrotechnical Commission (ISO/IEC) internationally recognized standard
that was built in tandem with an open-source reference implementation called IoTivity. Additionally,
OCF provides an in-depth testing and certification program.

892

3.4.8.1

893
894
895
896

OCF has contributed open-source code from IoTivity that demonstrates the advantage of secure
network-layer onboarding and implements the Wi-Fi Alliance’s Easy Connect to power a seamlessbootstrapping of secure and trusted application-layer onboarding of IoT devices with minimal userinteraction.

897
898
899
900
901

This code includes the interaction layer, called the OCF Diplomat, which handles secure communication
between the DPP-enabled access point and the OCF application layer. The OCF onboarding tool (OBT) is
used to configure and provision devices with operational credentials. The OCF reference
implementation of a basic lamp is used to demonstrate both network- and application-layer onboarding
and to show that once onboarded and provisioned, the OBT can securely interact with the lamp.

902

3.4.9

903
904
905
906
907
908

Sandelman Software Works (SSW) provides consulting and software design services in the areas ofsystems and network security. A complete stack company, SSW provides consulting and design services
from the hardware driver level up to Internet Protocol Security (IPsec), Transport Layer Security (TLS),
and cloud database optimization. SSW has been involved with the IETF since the 1990s, now dealing
with the difficult problem of providing security for IoT systems. SSW leads standardization efforts
through a combination of running code and rough consensus.

909
910

3.4.9.1

911
912
913

The Highway component is a cloud-native component operated by the device manufacturer (or its
authorized designate). It provides the Request for Comments (RFC) 8995 [7] specified Manufacturer
Authorized Signing Authority (MASA) for the BRSKI onboarding mechanism.

Open Connectivity Foundation (OCF)

IoTivity

Sandelman Software Works

Minerva Highway IoT Network-Layer Onboarding and Lifecycle Management
SystemNIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

20

SECOND PRELIMINARY DRAFT
914
915
916
917
918
919
920

Highway is an asset manager for IoT devices. In its asset database it maintains an inventory of devices
that have been manufactured, what type they are, and who the current owner of the device is (if it has
been sold). Highway does this by taking control of the complete identity lifecycle of the device. It can aid
in provisioning new device identity certificates (IDevIDs) by collecting Certificate Signing Requests andreturning certificates, or by generating the new identities itself. This is consistent with Section 4.1.2.1(On-device private key generation) and Section 4.1.2.2 (Off-device private key generation) of
https://www.ietf.org/archive/id/draft-irtf-t2trg-taxonomy-manufacturer-anchors-00.html.

921
922
923
924
925
926

Highway can act as a standalone three-level private public key infrastructure (PKI). Integrations with
Automatic Certificate Management Environment (RFC 8555) allow it to provision certificates from anexternal PKI using the DNS-01 challenge in Section 8.4 of https://www.rfceditor.org/rfc/rfc8555.html#section-8.4. Hardware integrations allow for the private key operations to
be moved out of the main CPU. However, the needs of a busy production line in a factory would requirecontinuous access to the hardware offload.

927
928

In practice, customers put the subordinate CA into Highway, which it needs to sign new IDevIDs, and put
the trust anchor private CA into a hardware security module (HSM).

929
930
931
932
933
934

Highway provides a BRSKI-MASA interface running on a public TCP/HTTPS port (usually 443 or 9443).
This service requires access to the private key associated to the anchor that has been “baked into” thePledge device during manufacturing. The Highway instance that speaks to the world in this way does nothave to be the same instance that signs IDevID certificates, and there are significant security advantages
to separating them. Both instances do need access to the same database servers, and there are a variety
of database replication techniques that can be used to improve resilience and security.

935
936
937

As IDevIDs do not expire, Highway does not presently include any mechanism to revoke IDevIDs, nordoes it provide Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP). It is
unclear how those mechanisms can work in practice.

938
939
940
941

Highway supports two models. In the Sales Integration model, the intended owner is known in advance.
This model requires customer-specific integrations, which often occur at the database level throughviews or other SQL tools. In the trust on first use (TOFU) model, the first customer to claim a productbecomes its owner.

942

3.4.10 SEALSQ, a subsidiary of WISeKey

943
944
945

WISeKey International Holding Ltd. (WISeKey) is a cybersecurity company that deploys digital identity
ecosystems and secures IoT solution platforms. It operates as a Swiss-based holding company throughseveral operational subsidiaries, each dedicated to specific aspects of its technology portfolio.

946
947
948
949
950

SEALSQ is the subsidiary of the group that focuses on designing and selling secure microcontrollers, PKI,
and identity provisioning services while developing post-quantum technology hardware and software
products. SEALSQ products and solutions are used across a variety of applications today, from multifactor authentication devices, home automation systems, and network infrastructure, to automotive,
industrial automation, and control systems.

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

21

SECOND PRELIMINARY DRAFT

951

3.4.11 VaultIC405

952
953
954
955

The VaultIC405 secure element combines hardware-based key storage with cryptographic accelerators
to provide a wide array of cryptographic features including identity, authentication, encryption, key
agreement, and data integrity. It protects against hardware attacks such as micro-probing and sidechannels.

956
957
958
959

The fundamental cryptography of the VaultIC family includes NIST-recommended algorithms and key
lengths. Each of these algorithms, Elliptic Curve Cryptography (ECC), Rivest-Shamir-Adleman (RSA), andAdvanced Encryption Standard (AES), is implemented on-chip and uses on-chip storage of the secret key
material so the secrets are always protected in the secure hardware.

960
961
962

The secure storage and cryptographic acceleration support use cases like network/IoT end node
security, platform security, secure boot, secure firmware download, secure communication/TLS, data
confidentiality, encryption key storage, and data integrity.

963

3.4.11.1 INeS Certificate Management System (CMS)

964
965
966
967
968

SEALSQ’s portfolio includes INeS, a managed PKI-as-a-service solution. INeS leverages the WISeKey
Webtrust-accredited trust services platform, a Matter approved Product Attestation Authority (PAA),
and custom CAs. These PKI technologies support large-scale IoT deployments, where IoT endpoints will
require certificates to establish their identities. The INeS CMS platform provides a secure, scalable, andmanageable trust model.

969
970

INeS CMS provides certificate management, CA management, public cloud integration and automation,role-based access control (RBAC), and APIs for custom implementations.

971

3.4.12 Silicon Labs

972
973
974
975
976
977
978
979
980

Silicon Labs provides products in the area of secure, intelligent wireless technology for a moreconnected world. Securing IoT is challenging. It’s also mission-critical. The challenge of protecting
connected devices against frequently surfacing IoT security vulnerabilities follows device makers
throughout the entire product lifecycle. Protecting products in a connected world is a necessity as
customer data and modern online business models are increasingly targets for costly hacks andcorporate brand damage. To stay secure, device makers need an underlying security platform in the
hardware, software, network, and cloud. Silicon Labs offers security products with features that address
escalating IoT threats, with the goal of reducing the risk of IoT ecosystem security breaches and thecompromise of intellectual property and revenue loss from counterfeiting.

981
982
983

For this project, Silicon Labs has provided a host platform for the OpenThread border router (OTBR), a
Thread radio transceiver, and an IoT device to be onboarded to the AWS cloud service and that
communicates using the Thread wireless protocol.

984

3.4.12.1 OpenThread Border Router Platform

985
986
987

A Raspberry Pi serves as host platform for the OTBR. The OTBR forms a Thread network and acts as abridge between the Thread network and the public internet, allowing the IoT device that communicatesusing the Thread wireless protocol and that is to be onboarded communicate with cloud services. The

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

22

SECOND PRELIMINARY DRAFT
988
989

OTBR’s connection to the internet can be made through either Wi-Fi or ethernet. Connection to the
SLWSTK6023A (see Section 3.4.12.2) is made through a USB serial port.

990

3.4.12.2 SLWSTK6023A Thread Radio Transceiver

991
992

The SLWSTK6023A (Wireless starter kit) acts as a Thread radio transceiver or radio coprocessor (RCP).
This allows the OTBR host platform to form and communicate with a Thread network.

993

3.4.12.3 xG24-DK2601B Thread “End” Device

994
995
996

The xG24-DK2601B is the IoT device that is to be onboarded to the cloud service (AWS). It
communicates using the Thread wireless protocol. Communication is bridged between the Thread
network and the internet by the OTBR.

997

3.4.12.4 Kudelski IoT keySTREAM™

998
999
1000
1001
1002

The Kudelski IoT keySTREAM solution is described more fully in Section 3.4.5.1. It is a cloud service
capable of verifying the hardware-based secure identity certificate chain associated with the xG24DK2601B component described in Section 3.4.12.3 and delivering a new certificate chain that can berefreshed or revoked as needed to assist with lifecycle management. The certificate chain is used toauthenticate the xG24-DK2601B device to the cloud service (AWS).

1003
1004
1005

Figure 3-2 shows the relationships among the components provided by Silicon Labs and Kudelski that
support the trusted application-layer onboarding of an IoT device that communicates via the Thread
protocol to AWS IoT.

1006

Figure 3-2 Components for Onboarding an IoT Device that Communicates Using Thread to AWS IoT

1007

4 Reference Architecture

1008
1009

Figure 4-1 depicts the reference architecture to demonstrate trusted IoT device network-layer
onboarding and lifecycle management used throughout this Practice Guide. This architecture shows a
NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

23

SECOND PRELIMINARY DRAFT
1010
1011
1012

high-level, protocol-agnostic, and generic approach to trusted network-layer onboarding. It represents
the basic components and processes, regardless of the network-layer onboarding protocol used and theparticular device lifecycle management activities supported.

1013
1014
1015
1016
1017
1018
1019

When implementing this architecture, an organization can follow different steps and use different
components. The exact steps that are performed may not be in the same order as the steps in the
logical reference architecture, and they may use components that do not have a one-to-one
correspondence with the logical components in the logical reference architecture. In Appendices C, D,
and E we present the architectures for builds 1, 2, and 3, each of which is an instantiation of this logicalreference architecture. Those build-specific architectures are more detailed and are described in termsof specific collaborator components and trusted network-layer onboarding protocols.

1020
1021

Figure 4-1 Trusted IoT Device Network-Layer Onboarding and Lifecycle Management Logical Reference
Architecture
Device Manufacturer Premises
2. Device ownership and bootstrapping information transfer
1. Device manufacture andfactory provisioning
Deviceownership
informationtransfer

Device Owner’s Network
3. Trusted network-layer onboarding

IoT Devices

5. Continuousverification

1022
1023

CA

Devicebootstrapping
informationtransfer

SecurestorageAccess Point, Router, or Switch

Network
Onboarding
Component

Supply Chain
Integration Service

4. Trusted
applicationlayer
onboarding
NetworkLayer
Onboarding
Authorization
ServiceContinuous
Authorization
Service
Application
ServerThere are five high-level processes to carry out this architecture, as labeled in Figure 4-1. These fiveprocesses are as follows:

1024
1025
1026

1. Device manufacture and factory provisioning – the activities that the IoT device manufacturer
performs to prepare the IoT device so that it is capable of network- and application-layer
onboarding (Figure 4-2, Section 4.1).

1027
1028
1029

2. Device ownership and bootstrapping information transfer – the transfer of IoT device
ownership and bootstrapping information from the manufacturer to the device and/or thedevice’s owner that enables the owner to onboard the device securely. The component in Figure
NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

24

SECOND PRELIMINARY DRAFT
1030
1031

4-1 labeled “Supply Chain Integration Service” represents the mechanism used to accomplish
this information transfer (Figure 4-3, Section 4.2).

1032
1033
1034
1035

3. Trusted network-layer onboarding – the interactions that occur between the network-layer
onboarding component and the IoT device to mutually authenticate, confirm authorization,
establish a secure channel, and provision the device with its network credentials (Figure 4-4,
Section 4.3).

1036
1037
1038

4. Trusted application-layer onboarding – the interactions that occur between a trusted
application server and the IoT device to mutually authenticate, establish a secure channel, andprovision the device with application-layer credentials (Figure 4-5, Section 4.4).

1039
1040

5. Continuous verification – ongoing, policy-based verification and authorization checks on the IoT
device to support device lifecycle monitoring and control (Figure 4-6, Section 4.5).

1041
1042
1043

Figure 4-1 uses two colors. The dark-blue components are central to supporting trusted network-layer
onboarding itself. The light-blue components support the other aspects of the architecture. Each of thefive processes is explained in more detail in the subsections below.

1044

4.1

1045
1046
1047
1048
1049
1050
1051
1052
1053
1054

Figure 4-2 depicts the device manufacture and factory provisioning process in more detail. As shown in
Figure 4-2, the manufacturer is responsible for creating the IoT device and provisioning it with thenecessary hardware, software, and birth credentials so that it is capable of network-layer onboarding.
The IoT device should be manufactured with a secure root of trust as a best practice, possibly as part ofa secure manufacturing process, particularly when outsourced. Visibility and control over theprovisioning process and manufacturing supply chain, particularly for outsourced manufacturing, iscritical in order to mitigate the risk of compromise in the supply chain, which could lead to theintroduction of compromised devices. The CA component is shown in light blue in Figure 4-2 because its
use is optional and depends on the type of credential that is being provisioned to the device (i.e.,
whether or not it is an 802.1AR certificate).

1055

Figure 4-2 IoT Device Manufacture and Factory Provisioning Process

Device Manufacture and Factory Provisioning Process

Provide device’s public key to the CA and receive back a signed certificate for the device, if necessaryCA

Device manufacture and factory provisioning:
IoT Device

Record thedevice ID andbootstrapping
information

Securestorage(1) Create the IoT device and give it a unique identifier(2) Equip the device to run the onboarding protocol(3) Install a unique birth credential (public/private key pair) into the device’s
secure storage. (If the credential is a certificate, it will need to be signed.)(4) Install any additional information that may be required to support related
operations, such as application-layer onboarding or device intent enforcement(5) Maintain a record of the device’s serial number and bootstrapping information

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

25

SECOND PRELIMINARY DRAFT
1056
1057

At a high level, the steps that the manufacturer or an integrator performs as part of this preparation
process, as shown in Figure 4-2, are as follows:

1058
1059

1. Create the IoT device and assign it a unique identifier (e.g., a serial number). Equip the device
with secure storage.

1060
1061
1062
1063

2. Equip the device to run a specific network-layer onboarding protocol (e.g., Wi-Fi Easy Connect,
BRSKI, Thread MeshCoP). This step includes ensuring that the device has the software/firmware
needed to run the onboarding protocol as well as any additional information that may berequired.

1064
1065
1066
1067
1068
1069
1070

3. Generate or install the device’s unique birth credential into the device’s secure storage. [Note:using a secure element that has the ability to autonomously generate private/public root key
pairs is inherently more secure than performing credential injection, which has the potential toexpose the private key.] The birth credential includes information that must be kept secret (i.e.,the device’s private key) because it is what enables the device’s identity to be authenticated.
The contents of the birth credential will depend on what network-layer onboarding protocol thedevice supports. For example:

1071
1072
1073
1074

a. If the device runs the Wi-Fi Easy Connect protocol, its birth credential will take the formof a unique private key, which has an associated DPP URI that includes thecorresponding public key and possibly additional information such as Wi-Fi channel andserial number.

1075
1076
1077
1078
1079

b. If the device runs the BRSKI protocol, its birth credential takes the form of an 802.1AR
certificate that gets installed as the device’s IDevID and corresponding private key. The
IDevID includes the device’s public key, the location of the MASA, and trust anchors thatcan be used to verify vouchers signed by the MASA. The 802.1AR certificate needs to besigned by a trusted signing authority prior to installation, as shown in Figure 4-2.

1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095

4. Install any additional information that may be required to support related capabilities that are
enabled by network-layer onboarding. The specific contents of the information that gets
installed on the device will vary according to what capabilities it is intended to support. For
example, if the device supports:
a. streamlined application-layer onboarding (see Section 3.3.2), then the bootstrapping
information that is required to enable the device and a trusted application server to findand mutually authenticate each other and establish a secure association will be stored
on the device. This is so it can be sent to the network during network-layer onboarding
and used to automatically perform application-layer onboarding after the device has
securely connected to the network. The Wi-Fi Easy Connect protocol, for example, caninclude such application-layer bootstrapping information as third-party information inits protocol exchange with the network, and Build 2 (i.e., the Wi-Fi Easy Connect,
CableLabs, OCF build) demonstrates use of this mechanism to support streamlined
application-layer onboarding.
Note, however, that a device may still be capable of performing independent [seeSection 3.3.2] application-layer onboarding even if the application-layer onboarding
NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

26

SECOND PRELIMINARY DRAFT
1096
1097
1098
1099
1100
1101

information is not exchanged as part of the network-layer onboarding protocol. The
application that is installed on the device, i.e., the application that the device executes
to fulfill its purpose, may include application-layer bootstrapping information thatenables it to perform application-layer onboarding when it begins executing. Build 1(i.e., the Wi-Fi Easy Connect, Aruba/HPE build) demonstrates independent applicationlayer onboarding.

1102
1103
1104
1105
1106

b. device intent, then the URI required to enable the network to locate the device’s intent
information will be stored on the device so that it can be sent to the network during
network-layer onboarding. After the device has securely connected to the network, thenetwork can use this device intent information to ensure that the device sends andreceives traffic only from authorized locations.

1107
1108
1109
1110
1111
1112

5. Maintain a record of the device’s serial number (or other uniquely identifying information) andthe device’s bootstrapping information. The manufacturer will take note of the device’s ID and
its bootstrapping information and store these. Eventually, when the device is sold, themanufacturer will need to provide the device’s owner with its bootstrapping information. The
contents of the device’s bootstrapping information will depend on what network-layer
onboarding protocol the device supports. For example:

1113
1114

a. If the device runs the Wi-Fi Easy Connect protocol, its bootstrapping information is the
DPP URI that is associated with its private key.

1115
1116

b. If the device runs the BRSKI protocol, its bootstrapping information is its 802.1AR
certificate.

1117

4.2

Device Ownership and Bootstrapping Information Transfer Process

1118
1119
1120

Figure 4-3 depicts the activities that are performed to transfer device bootstrapping information fromthe device manufacturer to the device owner, as well as to transfer device ownership information to thedevice itself. A high-level summary of these activities is described in the steps labeled A, B, and C.

1121
1122
1123
1124
1125

The figure uses two colors. The dark-blue components are those used in the network-layer onboarding
process. They are the same components as those depicted in the trusted network-layer onboarding
process diagram provided in Figure 4-4. The light-blue components and their accompanying steps depict
the portion of the diagram that is specific to device ownership and bootstrapping information transfer
activities.

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

27

SECOND PRELIMINARY DRAFT
1126

Figure 4-3 Device Ownership and Bootstrapping Information Transfer Process
Device Manufacturer Premises

DeviceManufacturer

Supply Chain
Integration
Service(1) Provide the serial number and bootstrapping informationof the device that the organization has purchased(3) Provide

Device Owner’s Network

IoT Devices

Securestoragethe device
withinformation
about its
owner

CA

(2) Make theserial number
andbootstrapping
information of
the purchased
device available
to theauthorization
service used by
the device owner.

Access Point, Router, or Switch

Network
Onboarding
Component

1127

NetworkLayer
Onboarding
Authorization
Service

These steps are as follows:

1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145

1. The device manufacturer makes the device serial number, bootstrapping information, andownership information available so that the organization or individual who has purchased thedevice will have the device’s serial number and bootstrapping information, and the device itself
will be informed of who its owner is. In Figure 4-3, the manufacturer is shown sending thisinformation to the supply chain integration service, which ensures that the necessary
information ultimately reaches the device owner’s authorization service as well as the device
itself. In reality, the mechanism for forwarding this bootstrapping information from the
manufacturer to the owner may take many forms. For example, when BRSKI is used, themanufacturer sends the device serial number and bootstrapping information to a MASA thatboth the device and its owner trust. When other network-layer onboarding protocols are used,the device manufacturer may provide the device owner with this bootstrapping information
directly by uploading this information to the owner’s portion of a trusted cloud. Such amechanism is useful for the case in which the owner is a large enterprise that has made a bulk
purchase of many IoT devices. In this case, the manufacturer can upload the information for
hundreds or thousands of IoT devices to the supply chain integration service at once. We callthis the enterprise use case. Alternatively, the device manufacturer may provide thisinformation to the device owner indirectly by including it on or in the packaging of an IoT device
that is sold at retail. We call this the consumer use case.

1146
1147
1148

The contents of the device bootstrapping information will vary according to the onboarding
protocol that the device supports. For example, if the device supports the Wi-Fi Easy Connect
network-layer onboarding protocol, the bootstrapping information will consist of the device’s

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

28

SECOND PRELIMINARY DRAFT
1149
1150

DPP URI. If the device supports the BRSKI network-layer onboarding protocol, bootstrapping
information will consist of the device’s IDevID (i.e., its 802.1AR certificate).

1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161

2. The supply chain integration service forwards the device serial number and bootstrapping
information to an authorization service that has connectivity to the device owner’s networklayer onboarding component so that the device owner can use this information to authenticate
the device and verify that it is expected and authorized to be onboarded to the device owner’s
network. Again, this forwarding may take many forms—e.g., enterprise case or consumer case—and use a variety of different mechanisms within each use case type—e.g., information moved
from one location to another in the device owner’s portion of a trusted cloud, informationtransferred via a standardized protocol operating between the MASA and the device owner’s
domain registrar, or information scanned from a QR code on device packaging using a mobile
app. In the case in which BRSKI is used, a certificate authority is consulted to help validate thesignature of the 802.1AR certificate that comprises the device bootstrapping information.

1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173

3. The supply chain integration service may also provide the device with information about who its
owner is. Knowing who its owner is enables the device to ensure that the network that is trying
to onboard it is authorized to do so, because it is assumed that if a network owns a device, it isauthorized to onboard it. The mechanisms for providing the device with assurance that the
network that is trying to onboard it is authorized to do so can take a variety of forms, dependingon the network-layer onboarding protocol being used. For example, if the Wi-Fi Easy Connect
protocol is being used, then if an entity is in possession of the device’s public key, that entity is
assumed to be authorized to onboard the device. If BRSKI is being used, the device will be
provided with a signed voucher verifying that the network that is trying to onboard the device isauthorized to do so. The voucher is signed by the MASA. Because the manufacturer has installed
trust anchors for the MASA onto the device, the device trusts the MASA. It is also able to verify
the MASA’s signature.

1174
1175
1176

Authentication of the network by the device may also take a variety of forms. These may range
from simply trusting the person who is onboarding the device to onboard it to the correct
network, to providing the IoT device with the network’s public key.

1177

4.3

Trusted Network-Layer Onboarding Process

1178
1179
1180
1181
1182

Figure 4-4 depicts the trusted network-layer onboarding process in more detail. It shows theinteractions that occur between the network-layer onboarding component and the IoT device tomutually authenticate, confirm that the device is authorized to be onboarded to the network, confirm
that the network is authorized to onboard the device, establish a secure channel, and provision thedevice with its network credentials.

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

29

SECOND PRELIMINARY DRAFT
1183

Figure 4-4 Trusted Network-Layer Onboarding Process

IoT Devices

Securestorage(1)Device enters onboarding mode
(8) Use network credentials toconnect to the network securely(2)Trusted introduction of device
and network bootstrapping
information(3) Device and network
authentication(4) Verify that the network is
authorized to onboard the device

Access Point, Router, or Switch(7) Provision network credentials to the device(6) Establish a secure channel(denoted by )Network
Onboarding
Component(5) Verify that device is authorized
to be onboarded to the network

NetworkLayer
Onboarding
Authorization
Service

1184
1185
1186
1187

The numbered arrows in the diagram are intended to provide a high-level summary of the network-layer
onboarding steps. These steps are assumed to occur after any device bootstrapping information andownership transfer activities (as described in the previous section) that may need to be performed. The
steps of the trusted network-layer onboarding process are as follows:

1188
1189

1. The IoT device to be onboarded is placed in onboarding mode, i.e., it is put into a state such that
it is actively listening for and/or sending initial onboarding protocol messages.

1190
1191
1192

2. Any required device bootstrapping information that has not already been provided to the
network and any required network bootstrapping information that has not already been
provided to the device are introduced in a trusted manner.

1193
1194
1195
1196
1197
1198
1199

3. Using the device and network bootstrapping information that has been provided, the network
authenticates the identity of the IoT device (e.g., by ensuring that the IoT device is in possessionof the private key that corresponds with the public key for the device that was provided as partof the device’s bootstrapping information), and the IoT device authenticates the identity of the
network (e.g., by ensuring that the network is in possession of the private key that correspondswith the public key for the network that was provided as part of the network’s bootstrapping
information).

1200
1201
1202

4. The device verifies that the network is authorized to onboard it. For example, the device may
verify that it and the network are owned by the same entity, and therefore assume that the
network is authorized to onboard it.

1203
1204

5. The network onboarding component consults the network-layer onboarding authorization
service to verify that the device is authorized to be onboarded to the network. For example, the
NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management30

SECOND PRELIMINARY DRAFT
1205
1206

network-layer authorization service can confirm that the device is owned by the network and ison the list of devices authorized to be onboarded.

1207
1208

6. A secure (i.e., encrypted) channel is established between the network onboarding component
and the device.

1209
1210

7. The network onboarding component uses the secure channel that it has established with thedevice to confidentially send the device its unique network credentials.

1211
1212

8. The device uses its newly provisioned network credentials to establish secure connectivity to the
network.

1213

4.4

Trusted Application-Layer Onboarding Process

1214
1215
1216
1217
1218
1219
1220
1221

Figure 4-5 depicts the trusted application-layer onboarding process as enabled by the streamlined
application-layer onboarding mechanism. As defined in Section 3.3.2, streamlined application-layer
onboarding occurs after network-layer onboarding and depends upon and is enabled by it. The figure
uses two colors. The dark-blue components are those used in the network-layer onboarding process.
They and their accompanying steps (written in black font) are identical to those found in the trusted
network-layer onboarding process diagram provided in Figure 4-4. The light-blue component and its
accompanying steps (written in light-blue font) depict the portion of the diagram that is specific tostreamlined application-layer onboarding.

1222

Figure 4-5 Trusted Streamlined Application-Layer Onboarding Process

IoT Devices

Securestorage(1)Device enters onboarding mode(10) Use network credentials toconnect to the network securely(2)Trusted introduction of device
and network bootstrapping
information(11) Device and application
server mutually authenticate
and establish a secure channel(12) Application server may,for example, perform updates
and ongoing lifecycle
management of device(3) Device and network
authentication
Access Point, Router, or Switch(4) Verify that network is authorized
to onboard the device(6) Establish a secure channel(denoted by )(9) Provision network credentials to thedevice, including the application server’s
application-layer bootstrapping
information(7) Device sends its applicationlayer bootstrapping information
Network
Onboarding
Component(5) Verify that device is authorized
to be onboarded to the network(8) Exchange device’s andapplication server’s applicationlayer bootstrapping information

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

NetworkLayer
Onboarding
Authorization
Service
Application
Server31

SECOND PRELIMINARY DRAFT
1223
1224
1225
1226
1227
1228
1229

As is the case with Figure 4-4, the steps in this diagram are assumed to occur after any device ownershipand bootstrapping information transfer activities that may need to be performed. Steps 1-6 in this figure
are identical to Steps 1-6 in the trusted network-layer onboarding diagram of Figure 4-4, but steps 7 and
8 are different. With the completion of steps 1-6 in Figure 4-5, a secure channel has been establishedbetween the IoT device and the network-layer onboarding component. However, the device does not
get provisioned with its network-layer credentials until step 9. To support streamlined application-layer
onboarding, additional steps are required. Steps 1-12 are as follows:

1230
1231

1. The IoT device to be onboarded is placed in onboarding mode, i.e., it is put into a state such that
it is actively listening for and/or sending initial onboarding protocol messages.

1232
1233
1234

2. Any required device bootstrapping information that has not already been provided to the
network and any required network bootstrapping information that has not already been
provided to the device are introduced in a trusted manner.

1235
1236
1237
1238
1239
1240
1241

3. Using the device and network bootstrapping information that has been provided, the network
authenticates the identity of the IoT device (e.g., by ensuring that the IoT device is in possessionof the private key that corresponds with the public key for the device that was provided as partof the device’s bootstrapping information), and the IoT device authenticates the identity of the
network (e.g., by ensuring that the network is in possession of the private key that correspondswith the public key for the network that was provided as part of the network’s bootstrapping
information).

1242
1243
1244

4. The device verifies that the network is authorized to onboard it. For example, the device may
verify that it and the network are owned by the same entity, and therefore assume that the
network is authorized to onboard it.

1245
1246
1247
1248

5. The network onboarding component consults the network-layer onboarding authorization
service to verify that the device is authorized to be onboarded to the network. For example, thenetwork-layer authorization service can confirm that the device is owned by the network and ison the list of devices authorized to be onboarded.

1249
1250

6. A secure (i.e., encrypted) channel is established between the network onboarding component
and the device.

1251
1252
1253
1254
1255
1256
1257
1258

7. The device sends its application-layer bootstrapping information to the network onboarding
component. Just as the network required the trusted introduction of device network-layerbootstrapping information in order to enable the network to authenticate the device and ensurethat the device was authorized to be network-layer onboarded, the application server requires
the trusted introduction of device application-layer bootstrapping information to enable theapplication server to authenticate the device at the application layer and ensure that the device
is authorized to be application-layer onboarded. Because this application-layer bootstrapping
information is being sent over a secure channel, its integrity and confidentiality are ensured.

1259
1260
1261
1262

8. The network onboarding component forwards the device’s application-layer bootstrapping
information to the application server. In response, the application server provides its
application-layer bootstrapping information to the network-layer onboarding component foreventual forwarding to the IoT device. The IoT device needs the application server’s
NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

32

SECOND PRELIMINARY DRAFT
1263
1264

bootstrapping information to enable the device to authenticate the application server andensure that it is authorized to application-layer onboard the device.

1265
1266
1267
1268
1269

9. The network onboarding component uses the secure channel that it has established with the IoT
device to confidentially send the device its unique network credentials. Along with these
network credentials, the network onboarding component also sends the IoT device theapplication server’s bootstrapping information. Because the application server’s bootstrapping
information is being sent over a secure channel, its integrity and confidentiality are ensured.

1270
1271

10. The device uses its newly provisioned network credentials to establish secure connectivity to the
network.

1272
1273
1274
1275

11. Using the device and application server application-layer bootstrapping information that has
already been exchanged in a trusted manner, the application server authenticates the identityof the IoT device and the IoT device authenticates the identity of the application server. Thenthey establish a secure (i.e., encrypted) channel.

1276
1277
1278
1279
1280

12. The application server application layer onboards the IoT device. This application-layer
onboarding process may take a variety of forms. For example, the application server may
download an application to the device for the device to execute. It may associate the device
with a trusted lifecycle management service that performs ongoing updates of the IoT device topatch it as needed to ensure that the device remains compliant with policy.

1281

4.5

Continuous Verification

1282
1283
1284
1285
1286
1287

Figure 4-6 depicts the steps that are performed to support continuous verification. The figure uses twocolors. The light-blue component and its accompanying steps (written in light-blue font) depict the
portion of the diagram that is specific to continuous authorization. The dark-blue components are thoseused in the network-layer onboarding process. They and their accompanying steps (written in blackfont) are identical to those found in the trusted network-layer onboarding process diagram provided in
Figure 4-4, except for step 5, Verify that device is authorized to be onboarded to the network.

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

33

SECOND PRELIMINARY DRAFT
1288

Figure 4-6 Continuous Verification

IoT Devices(1)Device enters onboarding mode

(8) Use network credentials toconnect to the network securely(2)Trusted introduction of device
and network bootstrapping
information(3) Device and network
authentication(4) Verify that network is authorized
to onboard the device(6) Establish a secure channel(denoted by )SecurestorageAccess Point, Router, or Switch(7) Provision network
credentials to thedeviceNetwork
Onboarding
Component(5a) Verify thatdevice is authorized
to be onboarded to
the network(9) Monitor and control the routeraccording to policy on an ongoing basis
to verify that the device and its
operations continue to be authorizedContinuous
Authorization
Service(5b) Verify thatdevice is authorized
to be onboarded to
the network

NetworkLayer
Onboarding
Authorization
Service

1289
1290
1291
1292
1293
1294
1295
1296

When continuous verification is being supported, step 5 is broken into two separate steps, as shown in
Figure 4-6. Instead of the network onboarding component directly contacting the network-layer
onboarding authorization service to see if the device is owned by the network and on the list of devices
authorized to be onboarded (as shown in the trusted network-layer onboarding architecture depicted in
Figure 4-4), a set of other enterprise policies may also be applied to determine if the device isauthorized to be onboarded. The application of these policies is represented by the insertion of theContinuous Authorization Service (CAS) component in the middle of the exchange between the network
onboarding component and the network-layer onboarding authorization service.

1297
1298
1299
1300
1301
1302
1303
1304

For example, the CAS may have received external threat information indicating that certain device types
have a vulnerability. If so, when the CAS receives a request from the network-layer onboarding
component to verify that a device of this type is authorized to be onboarded to the network (Step 5a), it
would immediately respond to the network-layer onboarding component that the device is not
authorized to be onboarded to the network. If the CAS has not received any such threat information
about the device and it checks all its policies and determines that the device should be permitted to beonboarded, it will forward the request to the network-layer onboarding authorization service (Step 5b)
and receive a response (Step 5b) that it will forward to the network onboarding component (Step 5a).

1305
1306
1307
1308

As depicted by Step 9, the CAS also continues to operate after the device connects to the network andexecutes its application. The CAS performs asynchronous calls to the network router to monitor thedevice on an ongoing basis, providing policy-based verification and authorization checks on the device
throughout its lifecycle.

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

34

SECOND PRELIMINARY DRAFT

1309

5 Laboratory Physical Architecture

1310
1311
1312
1313
1314
1315
1316
1317

Figure 5-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 thefactory 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 theinternet and public IP spaces (both IPv4 and IPv6). Access to and from the NCCoE network is protectedby a firewall.

1318
1319
1320
1321
1322

Access to and from the IoT Onboarding lab is protected by a pfSense firewall, represented by the brickbox icon in Figure 5-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 LANs, each of which houses a different trusted network-layer onboarding build.

1323
1324
1325
1326
1327

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 UXI Cloud (Build 1), Platform Controller (Build 2), a MASA server (Build 3), Kudelski IoT
keySTREAM application-layer onboarding service and AWS IoT (Build 4), and FoundriesFactory and
SEALSQ INeS, which we anticipate will be used across numerous builds.

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

35

SECOND PRELIMINARY DRAFT
1328

Figure 5-1 NCCoE IoT Onboarding Laboratory Physical Architecture

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

36

SECOND PRELIMINARY DRAFT
1329
1330

All five network-layer onboarding laboratory environments, as depicted in the diagram, have been
installed, as well as the laboratory environment for the BRSKI factory provisioning build:

1331
1332
1333
1334
1335

▪

The Build 1 (i.e., the Wi-Fi Easy Connect, Aruba/HPE build) 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 network-layer 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.

1336
1337
1338
1339

▪

The Build 2 (i.e., the Wi-Fi Easy Connect, CableLabs, OCF build) network infrastructure within the
NCCoE lab consists of a single component: the Gateway Access Point. Build 2 requires support
from the Platform Controller, which also hosts the IoTivity Cloud Service. The IoT devices thatare onboarded using Build 2 include three Raspberry Pis.

1340
1341
1342
1343
1344
1345
1346
1347

▪

The Build 3 (i.e., the BRSKI, Sandelman Software Works build) network infrastructurecomponents within the NCCoE lab include a Wi-Fi capable home router (including Join Proxy), a
DMZ switch (for management), and an ESP32A Xtensa board acting as a Wi-Fi IoT device, as wellas 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 serverwhich is accessed via the internet. In addition, an RPI3 provides an ethernet/802.15.4 gateway,
as well as a test platform.

1348
1349
1350
1351
1352
1353
1354

▪

The Build 4 (i.e., the Thread, Silicon Labs, Kudelski IoT build) 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 Wireless Starter 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 andaccessed via the internet. The IoT device that is onboarded in Build 4 is the Silicon LabsThunderboard (BRD2601A) with an EFR32MG24 System-on-Chip. The application service towhich it onboards is AWS IoT.

1355
1356
1357
1358
1359
1360

▪

The Build 5 (i.e., the BRSKI, NquiringMinds build) 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. This build leverages the NquiringMinds’ component 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.

1361
1362
1363
1364
1365

▪

The BRSKI factory provisioning build components include an onboarding router shared with
Build 3 for network-layer onboarding. The IoT devices in this build are Raspberry Pis equippedwith a SEALSQ VaultIC Secure Element, which is provisioned credentials in coordination with thecloud-based SEALSQ INeS certification authority. The BRSKI factory provisioning build also
includes a cloud-based MASA server to support BRSKI capabilities.

1366
1367

The physical architecture for the Wi-Fi Easy Connect factory provisioning build has not yet been
deployed.

1368
1369
1370
1371

The details of the physical architecture of Builds 1, 2, and 3, their related collaborators’ cloudcomponents, and the shared environment, as well as the baseline software running on these physicalarchitectures, are described in the subsections below. The physical architectures of Builds 4 and 5, the
BRSKI factory provisioning build, and the Wi-Fi Easy Connect factory provisioning build will be described
NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

37

SECOND PRELIMINARY DRAFT
1372
1373

in future versions of this document when those builds are complete. The details of Builds 1, 2, and 3 areprovided in Appendix C (Build 1), Appendix D (Build 2), and Appendix E (Build 3).

1374

5.1

1375
1376
1377
1378
1379
1380

The NCCoE IoT Onboarding laboratory contains a shared environment to host several baseline services
in support of the builds. These baseline services supported configuration and integration work in each of
the builds and allowed collaborators to work together throughout the build process. This sharedenvironment is contained in its own network segment, with access to/from the rest of the labenvironment closely controlled. In addition, each of the systems in the shared environment is hardenedwith baseline configurations.

1381

5.1.1

1382
1383

The Domain Controller provides Active Directory and Domain Name System (DNS) services supporting
network access and access control in the lab. It runs on Windows Server 2019.

1384

5.1.2

1385
1386

The jumpbox provides secure remote access and management to authorized collaborators on each of
the builds. It runs on Windows Server 2019.

1387

5.2

1388
1389
1390
1391

Figure 5-2 is a view of the high-level physical architecture of Build 1 in the NCCoE IoT Onboarding
laboratory. The build components include an Aruba Wireless Access Point, Aruba Central, UXI Cloud, aCisco Catalyst switch, and the IoT devices to be onboarded, which include both a Raspberry Pi and a UXI
sensor. Most of these components are described in Section 3.4.1 and Section 3.4.3.

Shared Environment

Domain Controller

Jumpbox

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

1392
1393

▪

The Aruba Access Point acts as the DPP Configurator and relies on the Aruba Central cloudservice for authentication and management purposes.

1394
1395
1396

▪

Aruba Central ties together the IoT Operations, Client Insights, and Cloud Auth services tosupport the network-layer onboarding operations of the build. It also provides an API to support
the device ownership and bootstrapping information transfer process.

1397
1398

▪

The Cisco Catalyst Switch provides Power-over-Ethernet and network connectivity to the Aruba
Access Point. It also supports network segmentation.

1399
1400
1401
1402
1403

▪

The UXI Sensor acts as an IoT device and onboards to the network via Wi-Fi Easy Connect. After
network-layer onboarding, it performs independent (see Section 3.3.2) application-layer
onboarding. Once it has application-layer onboarded and is operational on the network, it does
passive and active monitoring of applications and services and will report outages, disruptions,and quality of service issues.

1404
1405
1406
1407

▪

UXI Cloud is an HPE cloud service that the UXI sensor contacts as part of the application-layer
onboarding process. The UXI sensor downloads a customer-specific configuration from the UXI
Cloud so that the UXI sensor can learn about the customer networks and services it needs tomonitor.

1408▪

The Raspberry Pi acts as an IoT device and onboards to the network via Wi-Fi Easy Connect.

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

38

SECOND PRELIMINARY DRAFT
1409
1410

▪

SEALSQ Certificate Authority has been integrated with Build 1 to sign network credentials thatare issued to IoT devices.

1411

▪

FoundriesFactory is not currently implemented in Build 1.

1412

Figure 5-2 Physical Architecture of Build 1

1413

5.3

1414
1415
1416

Figure 5-3 is a view of the high-level physical architecture of Build 2 in the NCCoE IoT Onboarding
laboratory. The Build 2 components include the Gateway Access Point, three IoT devices, and the
Platform Controller, which hosts the application-layer IoTivity service.

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

1417
1418
1419

▪

The Gateway Access Point acts as the Custom Connectivity Gateway Agent described in Section
3.4.2.2 and controls all network-layer onboarding activity within the network. It also hosts OCF
IoTivity functions, such as the OCF OBT and the OCF Diplomat.

1420
1421
1422

▪

The Platform Controller described in Section 3.4.2.1 provides management capabilities for the
Custom Connectivity Gateway Agent. It also hosts the application-layer IoTivity service for the
IoT devices as described in Section 3.4.8.1.

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

39

SECOND PRELIMINARY DRAFT
1423
1424
1425

▪

The IoT devices serve as reference clients, as described in Section 3.4.2.3. They run OCF
reference implementations. The IoT devices are onboarded to the network and complete both
application-layer and network-layer onboarding.

1426

▪

FoundriesFactory and SEALSQ INeS are not currently implemented in Build 2.

1427

Figure 5-3 Physical Architecture of Build 2

1428

5.4

1429
1430
1431

Figure 5-4 is a view of the high-level physical architecture of Build 3 in the NCCoE IoT Onboarding
laboratory. The Build 3 components include the onboarding router, a DMZ switch, IoT devices, a serial
console, and an 802.15.4 gateway.

Build 3 (BRSKI, Sandelman Software Works) Physical Architecture

1432
1433

▪

The onboarding router is a Turris MOX router running OpenWRT. The onboarding routerquarantines the IoT devices until they complete the BRSKI onboarding process.

1434
1435
1436

▪

The owner’s Registrar Server hosts the Minerva Fountain Join Registrar Coordinator application
running in a virtual machine. The Registrar Server determines whether or not a device meets thecriteria to join the network.

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

40

SECOND PRELIMINARY DRAFT
1437
1438
1439

▪

The MASA server for this build is a Minerva Highway MASA server as outlined in Section 3.4.9.1.
The role of the MASA server is to receive the voucher-request from the Registrar Server andconfirm that the Registrar Server has the right to own the device.

1440

▪

The DMZ switch is a basic Netgear switch that segments the build from the rest of the lab.

1441
1442
1443
1444

▪

The IoT devices include an ESP32 Xtensa device with Wi-Fi that will be tested with FreeRTOS and
RIOT-OS, a Raspberry Pi 3 running Raspbian 11, and an nRF52840 with an 802.15.4 radio that is
running RIOT-OS. The IoT devices are currently not used in the build but will serve as clients to
be onboarded onto the network in a future implementation of the build.

1445
1446

▪

The Sandelman Software Works Reach Pledge Simulator is the device that is onboarded to the
network in the current build.

1447
1448
1449

▪

The serial console is a BeagleBone Green with an attached USB hub. The serial console is used toaccess the IoT devices for diagnostic purposes. It also provides power and power control for USB
powered devices.

1450
1451

▪

The 802.15.4 gateway is integrated into the Raspberry Pi3 via an OpenMote daughter card. This
gateway will serve to onboard one of the IoT devices in a future implementation of this build.

1452

▪

SEALSQ INeS is not currently implemented in Build 3.

1453

Figure 5-4 Physical Architecture of Build 3

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

41

SECOND PRELIMINARY DRAFT

1454

5.5

Build 4 (Thread, Silicon Labs, Kudelski IoT) Physical Architecture

1455

The Build 4 physical architecture will be described in a future version of this document.

1456

5.6

1457

The Build 5 physical architecture will be described in a future version of this document.

1458

5.7

1459
1460

The BRSKI factory provisioning build physical architecture will be described in a future version of thisdocument.

1461

5.8

1462
1463

The Wi-Fi Easy Connect factory provisioning build physical architecture will be described in a futureversion of this document after it has been deployed.

1464

6 General Findings

1465

6.1

1466
1467
1468
1469
1470
1471
1472
1473

The Wi-Fi Easy Connect solution that was demonstrated in Build 1 and Build 2 supports trusted networklayer onboarding in a manner that is secure, efficient, and flexible enough to meet the needs of various
use cases. It is simple enough to be used by consumers, who typically do not have specialized technicalknowledge. In addition, to meet the needs of enterprises, it may be used to onboard a large number ofdevices quickly. Builds 1 and 2 are implementations of this protocol, and they are interoperable: IoT
devices that were provisioned for use with Build 1 were able to be onboarded onto the network using
Build 2, and IoT devices that were provisioned for use with Build 2 were able to be onboarded onto the
network using Build 1.

1474

6.1.1

1475
1476
1477
1478
1479
1480
1481
1482

Although DPP is designed to support authentication of the network by the IoT device as well as
authentication of the device by the network, the Wi-Fi Easy Connect solutions that were demonstrated
in builds 1 and 2 do not demonstrate mutual authentication at the network layer. They only support
authentication of the device. In order to authenticate the network, the device needs to be provided with
the DPP URI for the network configurator, which means that the device has to have a functional userinterface so that the DPP URI can be input into it. The devices being used in builds 1 and 2 do not haveuser interfaces. In the future, if devices with user interfaces are available for use with builds 1 and 2,
perhaps this capability could be demonstrated.

1483

6.1.2

1484
1485
1486

When using DPP, device authorization is based on possession of the device’s DPP URI. When the device
is acquired, its DPP URI is provided to the device owner. A trusted administrator of the owner’s network
is assumed to approve addition of the device’s DPP URI to the database or cloud service where the DPP

Build 5 (BRSKI, NquiringMinds) Physical Architecture
BRSKI Factory Provisioning Build Physical Architecture

Wi-Fi Easy Connect Factory Provisioning Build Physical Architecture

Wi-Fi Easy Connect

Mutual Authentication

Mutual Authorization

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

42

SECOND PRELIMINARY DRAFT
1487
1488

URIs of authorized devices are stored. During the onboarding process, the fact that the owning network
is in possession of the device’s DPP URI indicates to the network that the device is authorized to join it.

1489
1490
1491
1492
1493
1494
1495

DPP supports network authorization using the Resurrecting Duckling security model [12]. Although thedevice cannot cryptographically verify that the network is authorized to onboard it, the fact that the
network possesses the device’s public key is understood by the device to implicitly authorize the
network to onboard the device. The assumption is that an unauthorized network would not havepossession of the device and so would not be able to obtain the device’s public key. While this assuranceof authorization is not cryptographic, it does provide some level of assurance that the “wrong” network
won’t onboard it.

1496

6.1.3

1497
1498
1499
1500
1501
1502
1503

The UXI sensor used in Build 1 has a TPM where the device’s birth credential and private key are stored,
providing a secure root of trust. However, the lack of secure storage on some of the other IoT devices(e.g., the Raspberry Pis) used to demonstrate onboarding in builds 1 and 2 is a current weakness.
Ensuring that the confidentiality of a device’s birth, network, and other credentials is protected while
stored on the device is an essential aspect of ensuring the security of the network-layer onboarding
process, the device, and the network itself. To fully demonstrate trusted network-layer onboarding,devices with secure storage should be used in the future whenever possible.

1504

6.2

1505
1506
1507
1508
1509

The BRSKI solution that is demonstrated in Build 3 supports trusted network-layer onboarding in amanner that is secure, efficient, and able to meet the needs of enterprises. It may be used to onboard alarge number of devices quickly. This BRSKI build is based on IETF RFC 8995 [7]. The build has a relianceon the manufacturer to provision keys for the onboarding device and has a reliance on a cloud-based
service for the MASA server.

1510

6.2.1

1511
1512
1513
1514
1515
1516
1517

Organizations implementing BRSKI should be aware of the reliance that they will have on the IoT device
manufacturer in properly and securely provisioning their devices. If keys become compromised,attackers may be able to onboard their own devices to the network, revoke certificates to prevent
legitimate devices from being onboarded, or onboard devices belonging to others onto the attacker’s
network using the attacker’s MASA. These concerns are addressed in depth in RFC 8995 section 11.6. If adevice manufacturer goes out of business or otherwise shuts down their MASA servers, the onboarding
services for their devices will no longer function.

1518
1519
1520
1521

During operation, onboarding services may become temporarily unavailable for a number of reasons. In
the case of a DoS attack on the MASA, server maintenance, or other outage on the part of the
manufacturer, an organization will not be able to access the MASA. These concerns are addressed in
depth in RFC 8995 section 11.1.

Secure Storage

BRSKI

Reliance on the Device Manufacturer

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

43

SECOND PRELIMINARY DRAFT

1522

6.2.2

Mutual Authentication

1523
1524
1525
1526
1527

BRSKI supports authentication of the IoT device by the network as well as authentication of the networkby the IoT device. The Registrar authenticates the device when it receives the IDevID from the device.
The MASA confirms that the Registrar is the legitimate owner of the device and issues a voucher. The
device is able to authenticate the network using the voucher that it receives back from the MASA. This
process is explained in depth in RFC 8995 section 11.5.

1528

6.2.3

1529
1530
1531

BRSKI authorization for the IoT device is done via the voucher that is returned to the Registrar from the
MASA. The voucher states which network the IoT device is authorized to join. The Registrar determines
the level of access the IoT device has to the network.

1532

7 Future Build Considerations

1533
1534
1535
1536
1537
1538
1539
1540

In addition to the builds that have been completed and those that are in progress, future work could
potentially involve integrating additional security mechanisms with network-layer onboarding,
beginning at device boot-up and extending through all phases of the device lifecycle, to further protect
the device and, by extension, the network. For example, future builds could include the capability todemonstrate the integration of trusted network-layer onboarding with zero trust-inspired capabilities. In
addition, the scope of the project could potentially be expanded beyond its current focus on IP-based
networks. While our goal so far has been to tackle what is currently implementable, the subsections that
follow briefly discuss areas that could potentially be addressed as part of the project’s future roadmap.

1541

7.1

1542
1543
1544
1545

Future builds could be designed to demonstrate network authentication in addition to device
authentication as part of the network-layer onboarding process. Network authentication enables thedevice to verify the identity of the network that will be taking control of it prior to permitting itself to beonboarded.

1546

7.2

1547
1548
1549
1550
1551
1552

Future builds could be designed to demonstrate the use of network-layer onboarding protocols tosecurely transmit device intent information from the device to the network (i.e., to transmit thisinformation in encrypted form with integrity protections). Secure conveyance of device intent
information, combined with enforcement of it, would enable the build to ensure that IoT devices areconstrained to sending and receiving only those communications that are explicitly required for eachdevice to fulfill its purpose.

1553

7.3

1554
1555
1556

Future builds could demonstrate trusted network-layer onboarding of a device, followed by streamlined
trusted application-layer onboarding of that device to a lifecycle management application service. Sucha capability would ensure that, once connected to the local network, the IoT device will automatically

Mutual Authorization

Network Authentication

Device Intent

Integration with a Lifecycle Management Service

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

44

SECOND PRELIMINARY DRAFT
1557
1558

and securely establish an association with a trusted lifecycle management service that is designed tokeep the device updated and patched on an ongoing basis.

1559

7.4

1560
1561
1562

Some devices may be provisioned network credentials that are X.509 certificates and that will therefore
eventually expire. Future build efforts could explore and demonstrate potential ways of renewing such
credentials without having to reprovision the credentials to the devices.

1563

7.5

1564
1565
1566
1567
1568

Future work could include definition of an open, scalable supply chain integration service that can
provide additional assurance of device provenance and trustworthiness automatically as part of theonboarding process. The supply chain integration service could be integrated with the authorization
service to ensure that only devices whose provenance meets specific criteria and that reach a thresholdlevel of trustworthiness will be onboarded or authorized.

1569

7.6

1570
1571
1572
1573
1574

Future builds could integrate device attestation capabilities with network-layer onboarding to ensurethat only IoT devices that meet specific attestation criteria are permitted to be onboarded. In addition
to considering the attestation of each device as a whole, future attestation work could also focus on
attestation of individual device components, so that detailed attestation could be performed for eachboard, integrated circuit, and software program that comprises a device.

1575

7.7

1576
1577
1578
1579
1580

Future builds could implement mutual attestation of the device and its application services. In one
direction, device attestation could be used to enable a high-value application service to determine
whether a device should be given permission to access it. In the other direction, attestation of theapplication service could be used to enable the device to determine whether it should give theapplication service permission to access and update the device.

1581

7.8

1582
1583
1584
1585
1586

Future builds could integrate artificial intelligence (AI) and machine learning (ML) based tools that aredesigned to analyze device behavior to spot anomalies or other potential signs of compromise. Any
device that is flagged as a potential threat by these tools could have its network credentials invalidated
to effectively evict it from the network, be quarantined, or have its interaction with other devices
restricted in some way.

1587

7.9

1588
1589
1590
1591

Perhaps in the future the project’s scope could be broadened to include the additional concept of adevice trustworthiness scale in which information regarding device capabilities, secure firmware
updates, the existence (or not) of a secure element for private key protection, type and version of eachof the software components that comprise the device, etc. would be used as input parameters to

Network Credential Renewal

Integration with Supply Chain Management Tools

Attestation

Mutual Attestation

Behavioral Analysis

Device Trustworthiness Scale

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

45

SECOND PRELIMINARY DRAFT
1592
1593
1594
1595
1596
1597

calculate each device’s trustworthiness value. Calculating such a value would essentially provide theequivalent of a background check. A history for the device could be maintained, including information
about whether it has ever been compromised, if it has a known vulnerability, etc. Such a trustworthinessvalue could be provided as an onboarding token or integrated into the authorization service sopermission to onboard to the network, or to access certain resources once joined, could be granted ordenied based on historical data and trustworthiness measures.

1598

7.10 Resource Constrained Systems

1599
1600
1601
1602
1603
1604

At present, onboarding solutions for technologies such as Zigbee, Z-Wave, and BLE use their own
proprietary mechanisms or depend on gateways. In the future, the project could potentially be
expanded to include onboarding in highly resource-constrained systems and non-IP systems without
using gateways. Future work could include trying to perform trusted onboarding in these smaller
microcontroller-constrained spaces in a standardized way with the goal of bringing more commonality
across various solutions without having to rely on IP gateways.

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

46

SECOND PRELIMINARY DRAFT

1605

Appendix A

List of Acronyms

AAA

Authentication, Authorization, and Accounting

ACL

Access Control List

AES

Advanced Encryption Standard

AI

Artificial Intelligence

AP

Access PointAPI

Application Programming Interface

AWS

Amazon Web Services

BLE

Bluetooth Low Energy

BRSKI

Bootstrapping Remote Secure Key Infrastructure

BSS

Basic Service Set

CACertificate Authority

CAS

Continuous Authorization Service

CMS

Certificate Management System

CPU

Central Processing Unit

CRADA

Cooperative Research and Development Agreement

CRL

Certificate Revocation List

DHCP

Dynamic Host Configuration Protocol

DMZ

Demilitarized Zone

DNS

Domain Name System

DPP

Device Provisioning Protocol

DTLS

Datagram Transport Layer Security

ECC

Elliptic Curve Cryptography

ESP(Aruba) Edge Services Platform

ESS

Extended Service Set

ESTEnrollment over Secure Transport

HPE

Hewlett Packard Enterprise

HSM

Hardware Security Module

HTTPS

Hypertext Transfer Protocol Secure

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

47

SECOND PRELIMINARY DRAFT
IDevID

Initial Device Identifier

IE

Information Element

IEC

International Electrotechnical Commission

IETF

Internet Engineering Task Force

IoT

Internet of Things

IP

Internet Protocol

IPsec

Internet Protocol Security

ISOInternational Organization for Standardization

LAN

Local Area Network, Local Area Networking

LmP

Linux microPlatform

MASA

Manufacturer Authorized Signing Authority

MeshCoP

Thread Mesh Commissioning Protocol

ML

Machine Learning

mPKI

Managed Public Key Infrastructure

MUD

Manufacturer Usage Description

NAC

Network Access Control

NCCoE

National Cybersecurity Center of Excellence

NIST

National Institute of Standards and Technology

OBT

Onboarding Tool

OCF

Open Connectivity Foundation

OCSP

Online Certificate Status Protocol

OS

Operating System

OTA

Over the AirOTBROpenThread Border Router

PKI

Public Key Infrastructure

PSK

Pre-Shared Key

R&D

Research & Development

RBAC

Role-Based Access Control

RCP

Radio Coprocessor

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

48

SECOND PRELIMINARY DRAFT
RESTfulRepresentational State Transfer

RFC

Request for Comments

RoT

Root of Trust

RSA

Rivest-Shamir-Adleman (public-key cryptosystem)

SaaS

Software as a Service

SE

Secure Element

SP

Special Publication

SSID

Service Set Identifier

SSW

Sandelman Software Works

TCP

Transmission Control Protocol

TLS

Transport Layer Security

TOFU

Trust On First Use

TPM

Trusted Platform Module

URI

Uniform Resource Identifier

UXI(Aruba) User Experience Insight

VM

Virtual Machine

WAN

Wide Area Network, Wide Area Networking

WFA

Wi-Fi Alliance

WPA2

Wi-Fi Protected Access 2

WPA3

Wi-Fi Protected Access 3

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

49

SECOND PRELIMINARY DRAFT

1606

Appendix B

Glossary

Application-Layer Information that the device and an application-layer service must have in order
Bootstrapping
for them to mutually authenticate and use a trusted application-layer
Information
onboarding protocol to onboard a device at the application layer. There isapplication-layer bootstrapping information about the device that the network
must be in possession of, and application-layer bootstrapping information about
the application service that the device must be in possession of. A typicalexample of application-layer bootstrapping information that the device musthave is the public key that corresponds to the trusted application service’s
private key.
Application-Layer The process of providing IoT devices with the application-layer credentials they
Onboarding
need to establish a secure (i.e., encrypted) association with a trusted application
service. This document defines two types of application-layer onboarding:
independent and streamlined.
Independent
An application-layer onboarding process that does not rely on use of the
Application-Layer network-layer onboarding process to transfer application-layer bootstrapping
Onboarding
information between the device and the application service.
Network-Layer
Bootstrapping
Information

Information that the device and the network must have in order for them to use
a trusted network-layer onboarding protocol to onboard a device. There is
network-layer bootstrapping information about the device that the network
must be in possession of, and network-layer bootstrapping information about
the network that the device must be in possession of. A typical example ofdevice bootstrapping information that the network must have is the public key
that corresponds with the device’s private key.

Network-Layer
Onboarding

The process of providing IoT devices with the network-layer credentials andpolicy they need to join a network upon deployment.

Streamlined
An application-layer onboarding process that uses the network-layer onboarding
Application-Layer protocol to securely transfer application-layer bootstrapping information
Onboarding
between the device and the application service.
Trusted Network- A network-layer onboarding process that meets the following criteria:
Layer Onboarding • provides each device with unique network credentials,• enables the device and the network to mutually authenticate,• sends devices their network credentials over an encrypted channel,• does not provide any person with access to the network credentials, and• can be performed repeatedly throughout the device lifecycle to enable:o the device’s network credentials to be securely managed andreplaced as needed, ando the device to be securely onboarded to other networks after being
repurposed or resold.

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

50

SECOND PRELIMINARY DRAFT

1607

Appendix C

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

1608

C.1 Technologies

1609
1610
1611
1612
1613
1614

Build 1 is an implementation of network-layer onboarding that uses the Wi-Fi Easy Connect protocol.
The onboarding infrastructure and related technology components for Build 1 have been provided by
Aruba/HPE. IoT devices that were onboarded using Build 1 were provided by Aruba/HPE and CableLabs.
The CA used for signing credentials issued to IoT devices was provided by SEALSQ, a subsidiary of
WISeKey. For more information on these collaborators and the products and technologies that they
contributed to this project overall, see Section 3.4.

1615
1616
1617
1618
1619
1620
1621
1622

Build 1 network onboarding infrastructure components within the NCCoE lab consist of the Aruba
Access Point. Build 1 also requires support from Aruba Central and the UXI Cloud, which are accessed via
the internet. IoT devices that can be network-layer onboarded using Build 1 include the Aruba/HPE UXI
sensor and CableLabs Raspberry Pi. The UXI sensor also includes the Aruba UXI Application, whichenables it to use independent (see Section 3.3.2) application-layer onboarding to be onboarded at theapplication layer as well, providing that the network to which the UXI sensor is onboarded has
connectivity to the UXI Cloud via the internet. The Build 1 implementation supports the provisioning of
all three types of network credentials defined in DPP:

1623

▪

Connector for DPP-based network access

1624

▪

Password/passphrase/PSK for WPA3/WPA2 network access

1625

▪

X.509 certificates for 802.1X network access

1626
1627
1628
1629

Build 1 has been integrated with the SEALSQ CA on SEALSQ INeS CMS to enable Build 1 to obtain signed
certificates from this CA when Build 1 is onboarding devices and issuing credentials for 802.1X network
access. When issuing credentials for DPP and WPA3/WPA2-based network access, the configurator does
not need to use a CA.

1630
1631
1632
1633

Table C-1 lists the technologies used in Build 1. It lists the products used to instantiate each componentof the reference architecture and describes the security function that the component provides. The
components listed are logical. They may be combined in physical form, e.g., a single piece of hardware
may house a network onboarding component, a router, and a wireless access point.

1634

Table C-1 Build 1 Products and Technologies
Component

Product

Function

Network-Layer
Onboarding
Component (Wi-Fi
Easy Connect
Configurator)

Aruba Access Point
with support from
Aruba Central

Runs the Wi-Fi Easy Connect network-layer onboarding
protocol to interact with the IoT device to perform oneway or mutual authentication, establish a securechannel, and securely provide local network credentials
to the device. If the network credential that is being
provided to the device is a certificate, the onboarding
component will interact with a certificate authority tosign the certificate. The configurator deployed in Build 1
supports DPP 2.0, but it is also backward compatible with
DPP 1.0.

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

51

SECOND PRELIMINARY DRAFT
Component

Product

Function

Access Point,
Router, or Switch

Aruba Access Point

Wireless access point that also serves as a router. It may
get configured with per-device access control lists (ACLs)
and policy when devices are onboarded.

Supply Chain
Integration Service

Aruba Central

The device manufacturer provides device bootstrapping
information to the HPE Cloud via the REST API that is
documented in the DPP specification. Once the device istransferred to an owner, the HPE Cloud provides thedevice bootstrapping information (i.e., the device’s DPP
URI) to the device owner’s private tenancy within the
HPE Cloud.

Authorization
Service

Cloud Auth (onAruba Central)

The authorization service provides the configurator androuter with the information needed to determine if thedevice is authorized to be onboarded to the network
and, if so, whether it should be assigned any special roles
or be subject to any specific access controls. It provides
device authorization, role-based access control, andpolicy enforcement.

Build-Specific IoT
DeviceAruba UXI Sensor

The IoT device that is used to demonstrate both trusted
network-layer onboarding and trusted application-layer
onboarding. It runs the Wi-Fi Easy Connect network-layer
onboarding protocol supported by the build to securely
receive its network credentials. It also has an applicationthat enables it to perform independent (see Section
3.3.2) application-layer onboarding.

Generic IoT Device

Raspberry Pi

The IoT device that is used to demonstrate only trusted
network-layer onboarding.

Secure Storage

Aruba UXI Sensor
Trusted Platform
Module (TPM)

Storage on the IoT device that is designed to beprotected from unauthorized access and capable ofdetecting attempts to hack or modify its contents. Usedto store and process private keys, credentials, and otherinformation that must be kept confidential.

Certificate
Authority (CA)SEALSQ INeS CMS
CAIssues and signs certificates as needed. These certificates
can be used by the device to connect to any 802.1abased network.

Application-Layer
Onboarding
ServiceUXI Application and
UXI CloudAfter connecting to the network, the device downloads
its application-layer credentials from the UXI cloud anduses them to authenticate to the UXI application, withwhich it interacts.

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

52

SECOND PRELIMINARY DRAFT
Component

Product

Function

Ongoing Device
Authorization

N/A – Not intended
for inclusion in thisbuild

Performs activities designed to provide an ongoingassessment of the device’s trustworthiness andauthorization to access network resources. For example,
it may perform behavioral analysis or device attestation
and use the results to determine whether the device
should be granted access to certain high-value resources,
assigned to a particular network segment, or other action
taken.

Manufacturer
Factory
Provisioning
Process

N/A (Not yet
implemented)

Manufactures the IoT device. Creates, signs, and installs
the device’s unique identity and other birth credentials
into secure storage. Installs information the device
requires for application-layer onboarding (if applicable).
May populate a manufacturer database with information
regarding devices that are created and, when the devices
are sold, may record what entity owns them.

1635

C.2 Build 1 Architecture1636

C.2.1 Build 1 Logical Architecture

1637
1638
1639
1640

The network-layer onboarding steps that are performed in Build 1 are depicted in Figure C-1. These
steps are broken into two main parts: those required to transfer device bootstrapping information fromthe device manufacturer to the device owner’s authorization service (labeled with letters) and thoserequired to perform network-layer onboarding of the device (labeled with numbers).

1641

The device manufacturer:

1642
1643
1644
1645

A) Creates the device and installs a unique birth credential into secure storage on the device.
Then the manufacturer sends the device’s bootstrapping information, which takes the formof a DPP URI, to Aruba Central in the HPE cloud. The device manufacturer interfaces with
the HPE cloud via a REST API.

1646
1647
1648

B) When the device is purchased, the device’s DPP URI is sent to the HPE cloud account of thedevice’s owner. The device owner’s cloud account contains the DPP URIs for all devices thatit owns.

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

53

SECOND PRELIMINARY DRAFT
1649

Figure C-1 Logical Architecture of Build 1
IoT Device Manufacturing and Ownership Transfer Activities

Device Manufacturer(A) Create the IoT Device
Install the device’s unique birth credential into the device’s secure storage
Send the device’s DPP URI to the HPE Cloud (via the REST API)(B) Provide thedevice’s DPP
URI to thedevice owner’s
account in the
cloud

Network-Layer Onboarding StepsIoT Devices(1) Device enters onboarding
mode and waits for DPP
exchange to begin(3) Configurator and device
perform the authentication
phase of DPP—a 3-way
handshake that authenticatesthe device and establishes asecure channel with it(6) Acquire an IP address via DHCP and use the network
credentials to connect to the network securely

Access Point, Router, or Switch(5) Assign any special roles or
ACLs pertaining to the device(4) Configurator and device perform the configuration phaseof DPP—a 3-way handshake that provisions network
credentials to the device (e.g., SSID, unique PSK)

Configurator

1650
1651

HPE Cloud(2) Configurator verifies that the device is authorized
to be onboarded to the network by obtaining its public
key from the list of owned device DPP URIs

Authorization
Service

After obtaining the device, the device owner provisions the device with its network credentials byperforming the following network-layer onboarding steps:

1652
1653
1654
1655

1. The owner puts the device into onboarding mode. The device waits for the DPP exchange tobegin. This exchange includes the device issuing a discovery message, which the owner’s
configurator hears. The discovery message is secured such that it can only be decoded by anentity that possesses the device’s DPP URI.

1656
1657
1658

2. The configurator consults the list of DPP URIs of all owned devices to decode the discovery
message and verify that the device is owned by the network owner and is therefore assumed to
be authorized to be onboarded to the network.

1659
1660
1661

3. Assuming the configurator finds the device’s DPP URI, the configurator and the device performthe authentication phase of DPP, which is a three-way handshake that authenticates the device
and establishes a secure (encrypted) channel with it.

1662
1663
1664

4. The configurator and the device use this secure channel to perform the configuration phase of
DPP, which is a three-way handshake that provisions network credentials to the device, alongwith any other information that may be needed, such as the network SSID.

1665
1666
1667

5. The router or switch consults the owner’s authentication, authorization, and accounting (AAA)service to determine if the device should be assigned any special roles or if any special ACL
entries should be made for the device. If so, these are configured on the router or switch.
NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

54

SECOND PRELIMINARY DRAFT
1668
1669

6. The device uses Dynamic Host Configuration Protocol (DHCP) to acquire an IP address and thenuses its newly provisioned network credentials to connect to the network securely.

1670

This completes the network-layer onboarding process.

1671
1672
1673
1674
1675
1676
1677
1678
1679

After the device is network-layer onboarded and connects to the network, it automatically performs
independent (see Section 3.3.2) application-layer onboarding. The application-layer onboarding steps
are not depicted in Figure C-1. During the application-layer onboarding process, the IoT device, which
is a UXI sensor, authenticates itself to the UXI cloud using its manufacturing certificate and pulls its
application-layer credentials from the UXI cloud. In addition, if a firmware update is relevant, this also
happens. The UXI sensor contacts the UXI cloud service to download a customer-specific configurationthat tells it what to monitor on the customer’s network. The UXI sensor then conducts the network
performance monitoring functions it is designed to perform and uploads the data it collects to the UXIapplication dashboard.

1680

C.2.2 Build 1 Physical Architecture

1681

Section 5.2 describes the physical architecture of Build 1.

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

55

SECOND PRELIMINARY DRAFT

1682

Appendix D

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

1683

D.1 Technologies

1684
1685
1686
1687
1688
1689
1690
1691

Build 2 is an implementation of network-layer onboarding that uses the Wi-Fi Easy Connect protocol.
Build 2 also supports streamlined (see Section 3.3.2) application-layer onboarding to the OCF security
domain. The network-layer onboarding infrastructure for Build 2 is provided by CableLabs and theapplication-layer onboarding infrastructure is provided by OCF. IoT devices that were network-layer
onboarded using Build 2 were provided by Aruba/HPE and OCF. Only the IoT devices provided by OCF
were capable of being both network-layer onboarded and streamlined application-layer onboarded. For
more information on these collaborators and the products and technologies that they contributed tothis project overall, see Section 3.4.

1692
1693
1694

Build 2 onboarding infrastructure components consist of the CableLabs Custom Connectivity Gateway
Agent, which runs on the Gateway Access Point, and the Platform Controller. IoT devices onboarded by
Build 2 include the Aruba UXI Sensor and CableLabs Raspberry Pi.

1695
1696
1697
1698

Table D-1 lists the technologies used in Build 2. It lists the products used to instantiate each logical build
component and the security function that the component provides. The components listed are logical.
They may be combined in physical form, e.g., a single piece of hardware may house a network
onboarding component, router, and wireless access point.

1699

Table D-1 Build 2 Products and Technologies
Component

Product

Function

Network-Layer
Onboarding
Component(Configurator)

CableLabs Custom
Connectivity
Gateway Agent
with support from
CableLabs
Platform
Controller

Runs the Wi-Fi Easy Connect network-layer onboarding
protocol to interact with the IoT device to perform oneway or mutual authentication, establish a secure channel,
and securely provide local network credentials to thedevice. It also securely conveys application-layerbootstrapping information to the device as part of the WiFi Easy Connect protocol to support application-layer
onboarding. The network-layer onboarding component
deployed in Build 2 supports DPP 2.0, but it is also
backward compatible with DPP 1.0.

Access Point,
Router, or Switch

Raspberry Pi(running Custom
Connectivity
Gateway Agent)

The access point includes a configurator that runs the WiFi Easy Connect Protocol. It also serves as a router that: 1)
routes all traffic exchanged between IoT devices and therest of the network, and 2) assigns each IoT device to a
local network segment appropriate to the device’s trustlevel (optional).

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

56

SECOND PRELIMINARY DRAFT
Component

Product

Function

Supply Chain
Integration Service

CableLabs
Platform
Controller/IoTivity
Cloud Service

The device manufacturer provides device bootstrapping
information (i.e., the DPP URI) to the CableLabs Web
Server. There are several potential mechanisms forsending the DPP URI to the CableLabs Web Server. The
manufacturer can send the device’s DPP URI to the Web
Server directly, via an API. The API used is not the REST API
that is documented in the DPP specification. However, theAPI is published and was made available to manufacturers
wanting to onboard their IoT devices using Build 2. Oncethe device is transferred to an owner, the CableLabs Web
Server provides the device’s DPP URI to the device owner’s
authorization service, which is part of the owner’s
configurator.

Authorization
Service

CableLabs
Platform
Controller

The authorization service provides the configurator androuter with the information needed to determine if thedevice is authorized to be onboarded to the network and,if so, whether it should be assigned any special roles,
assigned to any specific network segments, or be subject
to any specific access controls.

Build-Specific IoT
DeviceRaspberry Pi(Bulb)
Raspberry Pi(switch)The IoT devices that are used to demonstrate both trusted
network-layer onboarding and trusted application-layer
onboarding. They run the Wi-Fi Easy Connect networklayer onboarding protocol to securely receive their
network credentials. They also support application-layer
onboarding of the device to the OCF environment by
conveying the device’s application-layer bootstrapping
information as part of the network-layer onboarding
protocol.

Generic IoT Device

Aruba UXI Sensor

The IoT device that is used to demonstrate only trusted
network-layer onboarding.

Secure Storage

N/A (IoT device is
not equippedwith securestorage)

Storage designed to be protected from unauthorizedaccess and capable of detecting attempts to hack or
modify its contents. Used to store and process private keys
and other information that must be kept confidential.

Certificate
Authority

N/A (Not yet
implemented)

Issues and signs certificates as needed.

Application-Layer
Onboarding Service

OCF Diplomat and
OCF OBT within
IoTivity

After connecting to the network, the OCF Diplomat
authenticates the devices, establishes secure channels
with them, and sends them access control lists that control
which bulbs each switch is authorized to turn on and off.

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

57

SECOND PRELIMINARY DRAFT
Component

Product

Function

Ongoing Device
Authorization

N/A – Not
intended forinclusion in thisbuild

Performs activities designed to provide ongoingassessment of the device’s trustworthiness andauthorization to access network resources. For example, it
may perform behavioral analysis or device attestation anduse the results to determine whether the device should be
granted access to certain high-value resources, assigned toa particular network segment, or other action taken.

Manufacturer
Factory
Provisioning
Process

N/A (Not yet
implemented)

Manufactures the IoT device. Creates, signs, and installs
the device’s unique identity and other birth credentials
into secure storage. Installs information the device
requires for application-layer onboarding (if applicable).
May populate a manufacturer database with information
regarding devices that are created and, when the devices
are sold, may record what entity owns them.

1700

D.2 Build 2 Architecture1701

D.2.1 Build 2 Logical Architecture

1702
1703
1704
1705

The network-layer onboarding steps that are performed in Build 2 are depicted in Figure D-1. These
steps are broken into two main parts: those required to transfer device bootstrapping information fromthe device manufacturer to the device owner’s authorization service (labeled with letters) and thoserequired to perform network-layer onboarding of the device (labeled with numbers).

1706

The device manufacturer:

1707
1708
1709
1710
1711
1712
1713

A) Creates the device and installs a unique birth credential into secure storage on the device.
Because the device created for use in build 2 will also perform application-layer onboarding into
the OCF security domain, as part of the manufacturing process the manufacturer also either
installs application-layer bootstrapping information onto the device or ensures that the device
has the capability to generate one-time application-layer bootstrapping information at runtime.
Then the manufacturer makes the device’s network-layer bootstrapping information, whichtakes the form of a DPP URI, available to the device’s owner.

1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724

Build 2 supports several mechanisms whereby the manufacturer can make the device’s
network-layer bootstrapping information (i.e., its DPP URI) available to the device owner. The
device’s DPP URI can be uploaded directly to a device owner’s cloud account or web server via
API (as might come in handy when onboarding many enterprise devices at one time).
Alternatively, the DPP URI can be manually entered into a local web portal that runs aconfiguration webpage that a device on the same Wi-Fi network can connect to for purposes ofscanning a QR code or typing in the DPP URI. A DPP URI that is to be entered manually could, forexample, be emailed to the owner or encoded into a QR code and printed on the device chassis,
in device documentation, or on device packaging. Figure D-1 depicts the case in which the
manufacturer provides the device’s DPP URI to the owner for manual entry. When the ownerreceives the device’s DPP URI, the owner may optionally add the device’s DPP URI to a list of
NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

58

SECOND PRELIMINARY DRAFT
1725
1726
1727

DPP URIs for devices that it owns that is maintained as part of the owner’s authorization service.
Such a list would enable the owner’s network to determine if a device is authorized to beonboarded to it.

1728
1729
1730
1731
1732
1733

B) The person onboarding the device opens a web application and enters the device’s DPP URI. The
web application then sends the DPP URI to the Wi-Fi Easy Connect configurator, e.g., through a
web request. (Note that although the laboratory implementation of Build 2 requires the user toenter the DPP URI via a web page, an implementation designed for operational use would
typically require the user to provide the DPP URI by scanning a QR code into a network
operator-provided app that is logged into the user’s account.)

1734

Figure D-1 Logical Architecture of Build 2
IoT Device Manufacturing and Ownership Transfer Activities

Device Manufacturer(A) Create the IoT Device, install the device’s unique birth credential, and either install its application-layerbootstrapping information or ensure that it can generate one-time application-layer bootstrapping
information at runtime.
Provide the device’s DPP URI to the device’s owner either via the CableLabs web server or via QR code

Network- and Application-Layer Onboarding(B) Person opens a web app
and inputs the device’s DPP URI,
which is sent to the configurator,
thereby performing the trusted
introduction of the device’sbootstrapping information

IoT Devices(6) The device uses its newly-provisioned
network credentials to connect to the
network securely and then acquires an IP
address via DHCP

(1) The device enters onboarding
mode and waits for the DPP
exchange to begin(3) The configurator and the device
perform the authentication phaseof DPP—a three-way handshakethat authenticates the device andestablishes a secure channel with it(4) The configurator and the device
perform the configuration phase of
DPP. During this three-way
handshake, the device sends its
application-layer bootstrapping
information as part of the DPP
configuration crequest object andthe configurator provisions
network credentials to the device

Securestorage(7) The OCF OBT
discovers the device andprompts the user for
confirmation. Assuming
user confirmation isreceived, the OBT
authenticates the device
and establishes a securechannel with it

Access Point and Router

Wi-Fi Easy
Connect
Configurator
OCF Diplomat(2) The configurator verifies thatthe device is authorized to beonboarded to the network(5) The configurator sends thedevice’s application-layerbootstrapping information to the
OCF OBT via the OCF Diplomat

NetworkLayer
Onboarding
Authorization
Service

OCF OBT(8) The OBT installs
operational trust
anchors on the device
and sends it an access
control list that dictates
which bulbs each lightswitch is authorized toturn on and off.

1735
1736
1737
1738
1739
1740

After ensuring that the device’s network-layer bootstrapping information (i.e., its DPP URI) has been
uploaded to the configurator, the device owner performs both trusted network-layer onboarding andstreamlined application-layer onboarding to the OCF security domain by performing the steps depicted
in Figure D-1. In this diagram, the components that relate to network-layer onboarding are depicted indark blue and their associated steps are written in black font. The components and steps that are
related to application-layer onboarding are depicted in light blue. The steps are as follows:

1741
1742
1743
1744

1. The owner puts the device into onboarding mode. The device waits for the DPP exchange tobegin. This exchange includes the device issuing a discovery message, which the owner’s
configurator hears. The discovery message is secured such that it can only be decoded by anentity that possesses the device’s DPP URI.

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

59

SECOND PRELIMINARY DRAFT
1745
1746
1747
1748
1749

2. Optionally, if such a list is being maintained, the configurator consults the list of DPP URIs of all
owned devices to verify that the device is owned by the network owner and is therefore
assumed to be authorized to be onboarded to the network. (If the device is being onboarded byan enterprise, the enterprise would likely maintain such a list; however, if the device is being
onboarded to a home network, this step might be omitted.)

1750
1751
1752

3. Assuming the configurator finds the device’s DPP URI, the configurator and the device performthe authentication phase of DPP, which is a three-way handshake that authenticates the device
and establishes a secure (encrypted) channel with it.

1753
1754
1755
1756
1757

4. The configurator and the device use this secure channel to perform the configuration phase of
DPP, which is a three-way handshake that provisions network credentials to the device, alongwith any other information that may be needed, such as the network SSID. In particular, as partof the three-way handshake in the Build 2 demonstration, the device sends its application-layerbootstrapping information to the configurator as part of the DPP configuration request object.

1758
1759
1760
1761
1762
1763
1764
1765

5. The configurator receives the device’s application-layer bootstrapping information and forwards
it to the OCF Diplomat. The purpose of the OCF Diplomat is to provide a bridge between the
network and application layers. It accomplishes this by parsing the org.openconnectivity fields ofthe DPP request object, which contains the UUID of the device and the application-layerbootstrapping credentials, and sending these to the OCF OBT as part of a notification that the
OBT has a new device to onboard. The Diplomat and the OBT use a subscribe and notify
mechanism to ensure that the OBT will receive the onboarding request even if the OBT isunreachable for a period of time (e.g., the OBT is out of the home).

1766
1767
1768

6. The device uses its newly provisioned network credentials to connect to the network securely
and then uses DHCP to acquire an IP address. This completes the network-layer onboarding
process.

1769
1770
1771
1772
1773
1774
1775
1776

7. The OBT implements a filtered discovery mechanism using the UUID provided from the OCF
Diplomat to discover the new device on the network. Once it discovers the device, before
proceeding, the OBT may optionally prompt the user for confirmation that they want to perform
application-layer onboarding to the OCF security domain. This prompting may be accomplished,for example, by sending a confirmation request to an OCF app on the user’s mobile device.
Assuming the user responds affirmatively, the OBT uses the application-layer bootstrapping
information to authenticate the device and take ownership of it by setting up a Datagram
Transport Layer Security (DTLS) connection with the device.

1777
1778
1779
1780

8. The OBT then installs operational trust anchors and access control lists onto the device. For
example, in the access control list, each light bulb may have an access control entry dictating
which light switches are authorized to turn it on and off. This completes the application-layer
onboarding process.

1781
1782
1783
1784

Note that, at this time, the application-layer bootstrapping information is provided unilaterally in the
Build 2 application-layer onboarding demonstration. The application-layer bootstrapping information of
the device is provided to the OCF Diplomat, enabling the OBT to authenticate the device. In a futureversion of this process, the application-layer bootstrapping information could be provided bi-

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

60

SECOND PRELIMINARY DRAFT
1785
1786
1787
1788
1789

directionally, meaning that the OCF Diplomat could also send the OCF operational root of trust to the
IoT device as part of the DPP configuration response frame. Exchanging application-layer bootstrapping
information bilaterally in this way would enable the secure channel set up as part of the network-layer
onboarding process to support establishment of a mutually authenticated session between the device
and the OBT.

1790
1791
1792
1793
1794
1795
1796
1797

In the Build 2 demonstration, two IoT devices, a switch and a light bulb, are onboarded at both the
network and application layers. Each of these devices sends the OCF Diplomat its application-layerbootstrapping information over the secure network-layer onboarding channel during the network-layer
onboarding process. Immediately after they complete the network-layer onboarding process andconnect to the network, the OCF Diplomat provides their application-layer bootstrapping information to
the OBT. The OBT then uses the provided application-layer bootstrapping information to discover,authenticate, and onboard each device. Because the devices have no way to authenticate the identity of
the OBT in the current implementation, the devices are configured to trust the OBT upon first use.

1798
1799
1800
1801

After the OBT authenticates the devices, it establishes secure channels with them and provisions themaccess control lists that control which bulbs each switch is authorized to turn on and off. To demonstratethat the application onboarding was successful, Build 2 demonstrates that the switch is able to control
only those bulbs that the OCF OBT has authorized it to.

1802

D.2.2 Build 2 Physical Architecture

1803

Section 5.3 describes the physical architecture of Build 2.

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

61

SECOND PRELIMINARY DRAFT

1804

Appendix E

Build 3 (BRSKI, Sandelman Software Works)

1805

E.1 Technologies

1806

Build 3 is an implementation of network-layer onboarding that uses the BRSKI protocol.

1807
1808
1809
1810
1811
1812
1813
1814
1815
1816

Build 3 does not support application-layer onboarding. The network-layer onboarding infrastructure andrelated technology components for Build 3 were provided by Sandelman Software Works. The Raspberry
Pi, ESP32, and Nordic NRF IoT devices that will be onboarded in a future implementation of Build 3 werealso provided by Sandelman Software Works, as was the Sandelman Software Works Reach Pledge
Simulator, which is the device that is onboarded in the current build. The IoT devices do not have securestorage, but future plans are to integrate them with secure storage elements. Build 3 issues private PKI
certificates as network credentials at this time, but future plans are to integrate Build 3 with a thirdparty private CA from which it can obtain signed certificates. For more information on Sandelman
Software Works and the products and technologies that it contributed to this project overall, see Section
3.4.

1817
1818
1819
1820

Onboarding Build 3 infrastructure components consist of Raspberry Pi, Nordic NRF, ESP32, Sandelman
Software Works Minerva Fountain Join Registrar Coordinator, Sandelman Software Works
Minerva.Highway, Sandelman Software Works Reach Pledge Simulator, and a Minerva Fountain internal
CA.

1821
1822
1823
1824

Table E-1 lists the technologies used in Build 3. It lists the products used to instantiate each logical build
component and the security function that the component provides. The components are logical. They
may be combined in physical form, e.g., a single piece of hardware may house both a network
onboarding component and a router and/or wireless access point.

1825

Table E-1 Build 3 Products and Technologies
Component

Product

Function

Network-Layer
Onboarding
Component (BRSKI
Domain Registrar)

Sandelman Software
Works Minerva
Fountain Registrar

Runs the BRSKI protocol. It authenticates the IoT
device, receives a voucher-request from the IoT
device, and passes the request to the MASA. It also
receives a voucher from the MASA, verifies it, andpasses it to the IoT device. Assuming the IoT device
finds the voucher to be valid and determines that the
network is authorized to onboard it, the Domain
Registrar provisions network credentials to the IoT
device using EST.

Access Point,
Router, or Switch

Turris MOX routerrunning OpenWRTThe Onboarding Router segments the onboarding
device from the rest of the network until the BRSKI
onboarding is complete

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

62

SECOND PRELIMINARY DRAFT
Component

Product

Function

Supply Chain
Integration
Service(Manufacturer
Authorized Signing
Authority—MASA)

Minerva Highway,
which is a MASA
provided by
Sandelman SoftwareWorks

The device manufacturer provides device
bootstrapping information (e.g., the device’s X.509
certificate) and device ownership information to the
MASA. The MASA creates and signs a voucher saying
who the owner of the device is and provides thisvoucher to the IoT device via the Domain Registrar sothat the device can verify that the network that istrying to onboard it is authorized to do so.

Authorization
Service

Minerva Highway,
which is a MASA
provided by
Sandelman SoftwareWorks

The device manufacturer provides device
bootstrapping information (e.g., the device’s X.509
certificate) and device ownership information to the
MASA. The MASA creates and signs a voucher saying
who the owner of the device is and provides thisvoucher to the IoT device via the Domain Registrar sothat the device can verify that the network that istrying to onboard it is authorized to do so.

IoT Device(Pledge)

Sandelman Software
Works Reach Pledge
Simulator

The device that is used to demonstrate trusted
network-layer onboarding by joining the network. Thisrole is currently performed by the Sandelman
Software Works Reach Pledge Simulator, but will be
fulfilled by IoT devices in a future implementation of
the build.

Secure Storage

N/A (The IoT devices
and the Sandelman
Software Works Reach
Pledge Simulator do
not include securestorage)

Storage on the IoT device that is designed to beprotected from unauthorized access and capable ofdetecting attempts to hack or modify its contents.
Used to store and process private keys, credentials,
and other information that must be kept confidential.

Certificate
Authority

N/A (self-signed
certificates were used)

Issues and signs certificates as needed.

Application-Layer
Onboarding
ServiceNone. Not supported
in this build.

After connecting to the network, the device mutuallyauthenticates with a trusted application service andinteracts with it at the application layer.

Ongoing Device
Authorization

N/A – Not intended forinclusion in this build

Performs activities designed to provide an ongoingassessment of the device’s trustworthiness andauthorization to access network resources. For
example, it may perform behavioral analysis or device
attestation and use the results to determine whether
the device should be granted access to certain highvalue resources, assigned to a particular network
segment, or other action taken.

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

63

SECOND PRELIMINARY DRAFT
Component

Product

Function

Manufacturer
Factory
Provisioning
Process

N/A (Not yet
implemented)

Manufactures the IoT device. Creates, signs, andinstalls the device’s unique identity and other birthcredentials into secure storage. Installs information
the device requires for application-layer onboarding (ifapplicable). May populate a manufacturer databasewith information regarding devices that are created
and, when the devices are sold, may record what
entity owns them.

1826

E.2 Build 3 Architecture1827

E.2.1 Build 3 Logical Architecture

1828
1829
1830
1831
1832

The network-layer onboarding steps that are performed in Build 3 are depicted in Figure E-1. These
steps are broken into two main parts: those required to transfer device bootstrapping information fromthe device manufacturer to the device owner’s authorization service (labeled with letters) and thoserequired to perform network-layer onboarding of the device (labeled with numbers). These steps aredescribed in greater detail in IETF RFC 8995.

1833

The device manufacturer:

1834
1835
1836
1837
1838

(A) Creates the device and installs a unique serial number and birth credential into secure storage
on the device. This unique birth credential takes the form of a private key and its associated802.1AR certificate, e.g., the device’s IDevID. As part of this factory-installed certificate process,the location of the device’s MASA is provided in an extension to the IDevID. The device is also
provided with trust anchors for the MASA entity that will sign the returned vouchers.

1839
1840

(B) Stores information about the device, such as its serial number and its IDevID, in the MASA’s
database.

1841
1842

(C) Eventually, when the device is sold, the MASA may also record the device ownership
information in its database.

NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management64

SECOND PRELIMINARY DRAFT
1843

Figure E-1 Logical Architecture of Build 3
IoT Device Manufacturing and Ownership Transfer Activities

Device Manufacturer(A) Create the IoT Device and give it a serial number
Install the device’s unique birth credential into the device’s secure storage (IDevID)
Provide the location of the device's MASA and a trust anchor for the MASA

Supply Chain
Integration
Service

Network-Layer Onboarding(1) Device establishes/discovers an httpsconnection to the local Domain Registrar

IoT Devices (Pledges)(5) Registrar examines the new voucher andother info. Based on this info, the Registrar
makes the decision to continuebootstrapping and passes the voucher tothe device(6) Device verifies the voucher signature byusing pre-provisioned trust anchorsassociated with the MASA
(7) Device uses EST to requests newcredentials

C) Eventually,
when the device
is purchased, themanufacturer
may also
record thedevice owner
information in
the MASA(9) Device uses network credentials
to connect to the network securely(2) Device creates a pledge voucher request,
signs it using its IDevID certificate, andsends the request to the Registrar

Access Point, Router, or Switch(8) Registrar provisions network credentials
to the device using EST (e.g. LDevID)

DomainRegistrar(3) Registrar determines if the device was
expected. If so, it creates, signs, and sends tothe device’s MASA a registrar voucher-request
containing the info from the pledge voucherrequest and info about the registrar/owner.

B) Store thedevice serial #and IDevID in the
MASA database.

Manufacturer
Authorized
Signing Authority(MASA)

4) MASA verifies that the Registrar owns the device (ortrusts on first use), creates a new voucher indicating
this, and passes the new voucher back to the Registrar.

1844
1845

After obtaining the device, the device owner provisions the device with its network credentials byperforming the following network-layer onboarding steps:

1846
1847
1848
1849
1850
1851

1. The owner puts the device into onboarding mode. The device establishes an https connection to
the local Domain Registrar. (In a standard implementation, the device would use link-local
network connectivity to locate a join proxy, and the join proxy would provide the device withhttps connectivity to the local Domain Registrar. The Build 3 implementation, however, does notsupport discovery at this time. To overcome this code limitation, the IoT device has been preprovided with the address of the local Domain Registrar, to which it connects directly.)

1852
1853
1854

2. The device creates a pledge voucher-request that includes the device serial number, signs thisrequest with its IDevID certificate (i.e., its birth credential), and sends this signed request to theRegistrar.

1855
1856
1857
1858
1859
1860

3. The Registrar receives the pledge voucher-request and considers whether the manufacturer isknown to it and whether devices of that type are welcome. If so, the Registrar forms a registrar
voucher-request that includes all the information from the pledge voucher-request along withinformation about the registrar/owner. The Registrar signs this registrar voucher-request. It
locates the MASA that the IoT device is known to trust (e.g., the MASA that is identified in thedevice’s IDevID extension) and sends the registrar voucher-request to the MASA.

1861
1862
1863
1864

4. The MASA consults the information that it has stored and applies policy to determine whether
or not to approve the Registrar’s claim that it owns the device. (For example, the MASA may
consult sales records for the device to verify device ownership, or it may be configured to trustthat the first registrar that contacts it on behalf of a given device is in fact the device owner.)
NIST SP 1800-36B: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

65

SECOND PRELIMINARY DRAFT
1865
1866
1867

Assuming the MASA decides to approve the Registrar’s claim to own the device, the MASA
creates a voucher that directs the device to accept its new owner, signs this voucher, and sends
it back to the Registrar.

1868
1869
1870
1871

5. The Registrar receives this voucher, examines it along with other related information (such as
security posture, remote attestation results, and/or expected device serial numbers), anddetermines whether it trusts the voucher. Assuming it trusts the voucher, the Registrar passes
the voucher to the device.

1872
1873

6. The device uses its factory-provisioned MASA trust anchors to verify the voucher signature,
thereby ensuring that the voucher can be trusted.

1874

7. The device uses Enrollment over Secure Transport (EST) to request new credentials.

1875
1876

8. The Registrar provisions network credentials to the device using EST. These network credentials
get stored into secure storage on the device, e.g., as an LDevID.

1877

9. The device uses its newly provisioned network credentials to connect to the network securely.

1878

This completes the network-layer onboarding process for Build 3.

1879

E.2.2 Build 3 Physical Architecture

1880

Section 5.4 describes the physical architecture of Build 3.

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

66

SECOND PRELIMINARY DRAFT

1881

Appendix F

References

1882
1883
1884

[1]

L. S. Vailshery, “Number of Internet of Things (IoT) connected devices worldwide from 2019 to2023, with forecasts from 2022 to 2030,” Statista, July 2023. Available:
https://www.statista.com/statistics/1183457/iot-connected-devices-worldwide/

1885
1886
1887
1888

[2]

S. Symington, W. Polk, and M. Souppaya, Trusted Internet of Things (IoT) Device NetworkLayer Onboarding and Lifecycle Management (Draft), National Institute of Standards andTechnology (NIST) Draft Cybersecurity White Paper, Gaithersburg, MD, Sept. 2020, 88 pp.
https://doi.org/10.6028/NIST.CSWP.09082020-draft

1889
1890

[3]

E. Lear, R. Droms, and D. Romascanu, Manufacturer Usage Description Specification, IETF
Request for Comments (RFC) 8520, March 2019. Available: https://tools.ietf.org/html/rfc8520

1891
1892
1893
1894
1895

[4]

M. Souppaya et al, Securing Small-Business and Home Internet of Things (IoT) Devices:
Mitigating Network-Based Attacks Using Manufacturer Usage Description (MUD), National
Institute of Standards and Technology (NIST) Special Publication (SP) 1800-15, Gaithersburg,Md., May 2021, 438 pp. Available:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-15.pdf

1896
1897
1898
1899
1900

[5]

“National Cybersecurity Center of Excellence (NCCoE) Trusted Internet of Things (IoT) Device
Network-Layer Onboarding and Lifecycle Management,” Federal Register Vol. 86, No. 204,
October 26, 2021, pp. 59149-59152. Available:
https://www.federalregister.gov/documents/2021/10/26/2021-23293/national-cybersecuritycenter-of-excellence-nccoe-trusted-internet-of-things-iot-device

1901
1902

[6]

Wi-Fi Alliance, Wi-Fi Easy Connect™ Specification Version 3.0, 2022. Available:
https://www.wi-fi.org/system/files/Wi-Fi_Easy_Connect_Specification_v3.0.pdf

1903
1904
1905

[7]

M. Pritikin, M. Richardson, T.T.E. Eckert, M.H. Behringer, and K.W. Watsen, Bootstrapping
Remote Secure Key Infrastructure (BRSKI), IETF Request for Comments (RFC) 8995, October
2021. Available: https://datatracker.ietf.org/doc/rfc8995/

1906

[8]

Thread 1.1.1 Specification, February 13, 2017.

1907
1908
1909

[9]

O. Friel, E. Lear, M. Pritikin, and M. Richardson, BRSKI over IEEE 802.11, IETF Internet-Draft(Individual), July 2018. Available: https://datatracker.ietf.org/doc/draft-friel-brski-over802dot11/01/

1910[10] NIST. Cybersecurity Framework. Available: http://www.nist.gov/cyberframework/.

1911
1912
1913

[11] IEEE Standard for Local and Metropolitan Area Networks - Secure Device Identity, IEEE Std
802.1AR-2018 (Revision of IEEE Std 802.1AR-2009), 2 Aug. 2018, 73 pp. Available:
https://ieeexplore.ieee.org/document/8423794

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

67

SECOND PRELIMINARY DRAFT
1914
1915
1916
1917
1918

[12] F. Stajano and R. Anderson, The Resurrecting Duckling: Security Issues for Ad-hoc Wireless
Networks, B. Christianson, B. Crispo and M. Roe (Eds.). Security Protocols, 7th International
Workshop Proceedings, Lecture Notes in Computer Science, 1999. Springer-Verlag Berlin
Heidelberg 1999. Available: https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAndduckling.pdf

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

68