NIST Use cases
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, mass-produced 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 the device 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, a process known as network-layer onboarding.
Establishing trust between a network and an IoT device (as defined in NIST Internal Report 8425) prior to providing the device with the credentials it needs to join the network is crucial for mitigating the risk of potential 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.
In this practice guide, the National Cybersecurity Center of Excellence (NCCoE) applies standards, best practices, 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.
1.1 Challenge[BM1]
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 for devices to be securely provided with their local network credentials at the time of manufacture, this requires 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 from building identical devices for all its customers.
The industry lacks scalable, automatic mechanisms to safely manage IoT devices throughout their lifecycles, and lacks a trusted mechanism for providing IoT devices with their network credentials and policy at the time of deployment on the network. It is easy for a network to falsely identify itself, yet many IoT devices onboard to networks without verifying the network’s identity and ensuring that it is their intended target network. Also, many IoT devices lack user interfaces, making it cumbersome to manually 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 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.
Once a device is connected to the network, if it becomes compromised, it can pose a security risk to both 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 other devices on the network.
1.2 Solution
We need scalable, automated, trusted mechanisms to safely manage IoT devices throughout their lifecycles 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 the device 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.
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 their lifecycles 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 network-layer onboarding solutions. We define a trusted network-layer onboarding solution to be a mechanism for provisioning network credentials to a device that:
§ 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 and replaced as needed, and
o the device to be securely onboarded to other networks after being repurposed or resold.
The use cases designed to be demonstrated by this project’s implementations include:
§ trusted network-layer onboarding of IoT devices
§ repeated trusted network-layer onboarding of devices to the same or a different network
§ 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 network
§ policy-based ongoing device authorization
§ software-based methods to provision device birth credentials in the factory
§ mechanisms for IoT device manufacturers to provide IoT device purchasers with information needed to onboard the IoT devices to their networks (i.e., device bootstrapping information)
1.3 Benefits
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:
§ Ensure that their network is not put at risk as IoT devices are added to it
§ Safeguard their IoT devices from being taken over by unauthorized networks
§ Provide IoT devices with unique credentials for network access
§ Provide, renew, and replace device network credentials in a secure manner
§ Ensure that IoT devices can automatically and securely perform application-layer onboarding after performing trusted network-layer onboarding and connecting to a network
§ Support ongoing protection of IoT devices throughout their lifecycles
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:
§ Placing unique credentials into secure storage on IoT devices at time of manufacture (i.e., device birth credentials)
§ Installing onboarding software onto IoT devices
§ Providing IoT device purchasers with information needed to onboard the IoT devices to their networks (i.e., device bootstrapping information)
§ Integrating support for network-layer onboarding with additional security capabilities to provide ongoing protection throughout the device lifecycle
[BM1]NIST Leadership Review: Slight modifications to this section.
1.1 Audience
The intended audience for this practice guide includes:
§ IoT device manufacturers, integrators, and vendors
§ Semiconductor manufacturers and vendors
§ Secure storage manufacturers
§ Network equipment manufacturers
§ IoT device owners and users
§ Owners and administrators of networks (both home and enterprise) to which IoT devices connect
§ Service providers (internet service providers/cable operators and application platform providers)
1.2 Scope
This project focuses on the trusted network-layer onboarding of IoT devices in both home and enterprise environments. Enterprise, consumer, and industrial use cases for trusted IoT device network-layer 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 the onboarding of IP-based devices in the initial phase and will consider using technologies such as Zigbee or Bluetooth in future phases of this project.
The project’s scope also includes security technologies that can be integrated with and enhanced by the trusted network-layer onboarding mechanism to protect the device and its network throughout the device’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.
1.1 Assumptions and Definitions
This project is guided by a variety of assumptions, which are categorized by subsection below.
1.1.1 Credential Types
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. Birth credentials are installed onto the device before it is released into the supply chain; trusted network-layer 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 onboarding and connects to the network, during the application-layer onboarding process. These different types of IoT device credentials are defined as follows:
§ 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) [12] and/or a public/private key pair.
Birth credentials:
o are permanent, and their value is independent of context;
o enable the trusted network-layer onboarding process while keeping the device manufacturing process efficient; and
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.
§ 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:
§ 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 application-layer 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.
§ User Credential: An IoT device that permits authorized users to access it and restricts access only to authorized users will have one or more user credentials associated with it. These credentials 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.
In order to perform network- and application-layer onboarding, the device being onboarded must already have been provisioned with birth credentials. A pre-provisioned, unique, authoritative birth credential is essential for enabling the IoT device to be identified and authenticated as part of the trusted 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 with respect to the network to which the IoT device will connect. Each application-layer credential that is provisioned 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 the course of its lifetime, and the value of this birth credential remains unchanged. However, that IoT device may have any number of network, application-layer, and user credentials at any given point in time, and these credentials may be replaced repeatedly over the course of the device’s lifetime.
1.1.2 Integrating Security Enhancements[BM1]
Integrating trusted network-layer IoT device onboarding with additional security mechanisms and technologies 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:
§ Trusted application-layer onboarding: When supported, application-layer onboarding can be performed automatically after a device has connected to its local network. Trusted application-layer 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 many cases, a network’s IoT devices will be so numerous that manually onboarding devices at the application 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 the overall security posture of each IoT device.
As part of the application-layer onboarding process, devices and the application services with which they interact perform mutual authentication and establish an encrypted channel over which the application service can download application-layer credentials and software to the device 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 up-to-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.
Network-layer onboarding cannot be performed until after network-layer bootstrapping information has been introduced to the device and the network. This network-layer bootstrapping information enables the device and the network to mutually authenticate and establish a secure channel. Analogously, application-layer onboarding cannot be performed until after application-layer bootstrapping information has been introduced to the device and the application servers with which they will onboard. This application-layer bootstrapping information enables the device and the application server to mutually authenticate and establish a secure channel.
o Streamlined Application-Layer Onboarding—One potential mechanism for introducing this application-layer bootstrapping information to the device and the application server is to use the network-layer onboarding process. The secure channel that is established during 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-layer bootstrapping 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 is truly secret and known only to them, thereby establishing a firm foundation for their secure association. In this way, trusted network-layer onboarding can provide a secure foundation for trusted application-layer onboarding. We call an application-layer onboarding process that uses network-layer onboarding to exchange application-layer bootstrapping information streamlined application-layer onboarding.
o 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 that enables the device to mutually authenticate with an application-layer service after it has connected to the network. This mechanism for performing application-layer onboarding does not rely on the network-layer onboarding process to provide application-layer bootstrapping information to the device. All that is required is that the device have connectivity 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.
§ 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 the device that can be used to determine to which network segment it should be assigned upon connection. By conveying this information in a manner that protects its integrity and confidentiality, 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 a known vulnerability or misconfiguration, or because it is behaving in a suspicious manner, the device may be dynamically assigned to a different network segment as a means of quarantining it, or it’s network-layer credential can be revoked or deleted.
§ 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 from being corrupted and for protecting the network from a potentially harmful device. Even though a device is authenticated and authorized prior to being onboarded, it is recommended that the device be subject to ongoing, policy-based authentication and authorization as it continues to operate 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 to be authorized throughout the device’s tenure on the network.
§ Device Communications intent enforcement: Network-layer onboarding protocols can be used to securely transmit device intent information from the device to the network (i.e., to transmit this information in encrypted form with integrity protections). After the device has securely connected to the network, the network can use this device intent information to ensure that the device sends and receives traffic only from authorized locations. Secure conveyance of device intent information, combined with enforcement of it, ensures that IoT devices are constrained to sending and receiving only those communications that are explicitly required for each device to fulfill its purpose.
§ Additional Security Mechanisms: Although not demonstrated in the implementations that have been 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 through all phases of the device lifecycle. Examples of such mechanisms include integration with supply chain management tools, device attestation, automated lifecycle management, mutual attestation, and centralized asset management. Overall, application of these and other security protections can create a dependency chain of 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 network-layer onboarding process in turn may enable additional capabilities and provide a foundation that makes them more secure, thereby helping to ensure the ongoing security of the device and, by extension, the network.
1.1.3 Device Limitations
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, human interface (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 it should be able to support and the more robustly it should be able to support them. Depending on both device and onboarding solution capabilities, different levels of assurance may be provided.
[BM1]NIST Leadership Review: Modifications to this section.
1 Functional Demonstration Playbook
Six scenarios have been defined that demonstrate capabilities related to various aspects of trusted IoT device network-layer onboarding, application-layer onboarding, and device lifecycle management. These scenarios are as follows:
§ Scenario 0: Factory Provisioning
§ Scenario 1: Trusted Network-Layer Onboarding
§ Scenario 2: Trusted Application-Layer Onboarding
§ Scenario 3: Re-Onboarding a Device
§ Scenario 4: Ongoing Device Validation
§ Scenario 5: Establishment and Maintenance of Credential and Device Security Posture Throughout the Lifecycle
We executed the factory provisioning scenario (Scenario 0) using both a Bootstrapping Remote Secure Key Infrastructure (BRSKI) Factory Provisioning Build and a Wi-Fi Easy Connect Factory Provisioning Build that have been implemented as part of this project. We executed the trusted network-layer onboarding and lifecycle management scenarios using each of the onboarding builds that have been implemented as part of this project. The capabilities that were demonstrated depend both on the features of the network-layer onboarding protocol (i.e., Wi-Fi Easy Connect) that the build supports and on any additional mechanisms the build may have integrated (e.g., application-layer onboarding).
Section 2.1 defines the factory provisioning scenario (Scenario 0). Sections 2.2 through 2.6 define each of the five onboarding scenarios.
1.1 Scenario 0: Factory Provisioning
This scenario, which simulates the IoT device factory provisioning process, is designed to represent some steps that must be performed in the factory before the device is put into the supply chain. These steps are performed by the device manufacturer or integrator to provision a device with the information it requires to be able to participate in trusted network-layer onboarding and lifecycle management. The device is assumed to have been equipped with secure storage and with the software or firmware needed to support a specific network-layer onboarding protocol (e.g., Wi-Fi Easy Connect or BRSKI). Scenario 0 includes initial provisioning of the IoT device with its birth credential (e.g., its private key and initial device identifier (IDevID) [1]), where it is stored in secure storage to prevent tampering or disclosure. This process includes generation of the credential (e.g., a private key and other information), signing of this credential (if applicable, depending on what onboarding protocol the device is designed to support), and transfer of the device bootstrapping information (e.g., a DPP URI or the device’s IDevID ) to the appropriate destination to ensure that it will be available for use during the network layer onboarding process. Following provisioning, the birth credential may be used for network-layer or application-layer onboarding. Table 2‑1 lists the capabilities that may be demonstrated in this factory provisioning scenario.
Table 2‑1 Scenario 0 Factory Provisioning Capabilities That May Be Demonstrated
| Demo ID | Capability | Description |
|---|---|---|
| S0.C1 | Birth Credential Generation and Storage | The device’s birth credentials are generated within or generated and provisioned into secure storage on the IoT device. The content and format of the credential are appropriate to the onboarding protocol (e.g., Wi-Fi Easy Connect [2] or BRSKI [3]) that the device is designed to support: · For BRSKI, the credential is a private key, a signed certificate (IDevID), a trust anchor for the manufacturer’s certificate authority (CA), and the location of a trusted manufacturer authorized signing authority (MASA). · For Wi-Fi Easy Connect, the credential is a private key and a public bootstrapping key . |
| S0.C2 | Birth Credential Signing | The credential is signed by a trusted CA. |
| S0.C3 | Bootstrapping Information Availability | The bootstrapping information required for onboarding the device is made available as needed. The format and content of the bootstrapping information depends on the onboarding protocol that the device is designed to support: · For BRSKI, the bootstrapping information is the certificate and ownership information that is sent to the MASA. · For Wi-Fi Easy Connect, the bootstrapping information is the Device Provisioning Protocol (DPP) uniform resource identifier (URI) (which contains the public key, and optionally other information such as device serial number). |
1.2 Scenario 1: Trusted Network-Layer Onboarding
This scenario involves trusted network-layer onboarding of an authorized IoT device to a local network that is operated by the owner of the IoT device. The device is assumed to have been manufactured to support the type of network-layer onboarding protocol (e.g., Wi-Fi Easy Connect or BRSKI) that is being used by the local network. The device is also assumed to have been provisioned with its birth credential in a manner similar to that described in Scenario 0: Factory Provisioning, including transfer of the device’s bootstrapping information (e.g., its public key) to the operator of the local network to ensure that this information will be available to support authentication of the device during the initial phase of the trusted network-layer onboarding process. Onboarding is performed after the device has booted up and is placed in onboarding mode. Because the organization that is operating the local network is the owner of the IoT device, the device is authorized to onboard to the network and the network is authorized to onboard the device. In this scenario, after the identities of the device and the network are authenticated, a network onboarding component—a logical component authorized to onboard devices on behalf of the network—authenticates the device and provisions unique network credentials to the device over a secure channel. These network credentials are not just specific to the device; they are also specific to the local network. The device then uses these credentials to connect to the network. Table 22 lists the capabilities that may be demonstrated in this scenario.
Table 2‑2 Scenario 1 Trusted Network-Layer Onboarding Capabilities That May Be Demonstrated
| Demo ID | Capability | Description |
|---|---|---|
| S1.C1 | Device Authentication | The onboarding mechanism authenticates the device’s identity. |
| S1.C2 | Device Authorization | The onboarding mechanism verifies that the device is authorized to onboard to the network. |
| S1.C3 | Network Authentication | The device can verify the network’s identity. |
| S1.C4 | Network Authorization | The device can verify that the network is authorized to take control of it. |
| S1.C5 | Secure Local Credentialing | The onboarding mechanism securely provisions local network credentials to the device. |
| S1.C6 | Secure Storage | The credentials are provisioned to secure hardware-backed storage on the device. |
| S1.C7 | Network Selection | The onboarding mechanism provides the IoT device with the identifier of the network to which the device should onboard. |
| S1.C8 | Interoperability | The network-layer onboarding mechanism can onboard a minimum of two types of IoT devices (e.g., different device vendors and models). |
1.3 Scenario 2: Trusted Application-Layer Onboarding
This scenario involves trusted application-layer onboarding that is performed automatically on an IoT device after the device connects to a network. As a result, this scenario can be thought of as a series of steps that would be performed as an extension of Scenario 1, assuming the device has been designed and provisioned to support application-layer onboarding. As part of these steps, the device automatically mutually authenticates with a trusted application-layer onboarding service and establishes an encrypted connection to that service so the service can provision the device with application-layer credentials. The application-layer credentials could, for example, enable the device to securely connect to a trusted lifecycle management service to check for available updates or patches. For the application-layer onboarding mechanism to be trusted, it must establish an encrypted connection to the device without exposing any information that must be protected to ensure the confidentiality of that connection. Two types of application-layer onboarding are defined in NIST SP 1800-36B: streamlined and independent. Table 2‑3 lists the capabilities that may be demonstrated in this scenario, including both types of application-layer onboarding.
Table 2‑3 Scenario 2 Trusted Application-Layer Onboarding Capabilities That May Be Demonstrated
| Demo ID | Capability | Description |
|---|---|---|
| S2.C1 | Automatic Initiation of Streamlined Application-Layer Onboarding | The device can automatically (i.e., with no manual intervention required) initiate trusted application-layer onboarding after performing network-layer onboarding and connecting to the network. In this case, the application-layer onboarding bootstrapping information has been securely conveyed to the device during the network-layer onboarding process. |
| S2.C2 | Automatic Initiation of Independent Application-Layer Onboarding | The device can automatically (i.e., with no manual intervention required) initiate trusted application-layer onboarding after performing network-layer onboarding and connecting to the network. In this case, the application-layer onboarding bootstrapping information has been pre-provisioned to the device by the device manufacturer or integrator (e.g., as part of an application that was installed on the device during the manufacturing process). |
| S2.C3 | Trusted Application-Layer Onboarding | The device and a trusted application service can establish an encrypted connection without exposing any information that must be protected to ensure the confidentiality of the connection. They can then use that secure association to exchange application-layer information. |
1.4 Scenario 3: Re-Onboarding a Device
This scenario involves re-onboarding an IoT device to a network after deleting its network credentials so that the device can be re-credentialed and reconnected. If the device also supports application-layer onboarding, application-layer onboarding should also be performed again after the device reconnects to the network. This scenario assumes that the device has been able to successfully demonstrate trusted network-layer onboarding as defined in Scenario 1: Trusted Network-Layer Onboarding. If application-layer re-onboarding is to be demonstrated as well, the scenario assumes that the device has also been able to successfully demonstrate at least one method of application-layer onboarding as defined in Scenario 2: Trusted Application-Layer Onboarding. Table 2‑4 lists the capabilities that may be demonstrated in this scenario.
Table 2‑4 Scenario 3 Re-Onboarding Capabilities That May Be Demonstrated
| Demo ID | Capability | Description |
|---|---|---|
| S3.C1 | Credential Deletion | The device’s network credential can be deleted. |
| S3.C2 | De-Credentialed Device Cannot Connect | After the device’s network credential has been deleted, the device is not able to connect to or communicate on the network securely. |
| S3.C3 | Re-Onboarding (network layer) | After the device’s network credential has been deleted, the network-layer onboarding mechanism can securely re-provision a network credential to the device, which the device can then use to connect to the network securely. |
| S3.C4 | Re-Onboarding (application layer) | After the device’s network and application-layer credentials have been deleted and the device has been re-onboarded at the network layer and reconnected to the network, the device can again perform trusted application-layer onboarding. |
1.5 Scenario 4: Ongoing Device Validation
This scenario involves ongoing validation of a device, not only as part of a trusted boot or attestation process prior to permitting the device to undergo network-layer onboarding, but also after the device has connected to the network. It may involve one or more security mechanisms that are designed to evaluate, validate, or respond to device trustworthiness using methods such as examining device behavior, ensuring device authenticity and integrity, and assigning the device to a specific network segment based on its conformance to policy criteria. Table 2‑5 lists the capabilities that may be demonstrated in this scenario. None of these capabilities are integral to trusted network-layer onboarding; however, they may be used in conjunction with or subsequent to trusted network-layer onboarding to enhance device and network security.
Table 2‑5 Scenario 4 Ongoing Device Validation Capabilities That May Be Demonstrated
| Demo ID | Capability | Description |
|---|---|---|
| S4.C1 | Device Attestation (initial) | The network-layer onboarding mechanism requires successful device attestation prior to permitting the device to be onboarded. |
| S4.C2 | Device Attestation (application layer) | The application-layer onboarding mechanism requires successful device attestation prior to permitting the device to be onboarded. |
| S4.C3 | Device Attestation (ongoing) | Successful device attestation is required prior to permitting the device to perform some operation (e.g., accessing a high-value resource). |
| S4.C4 | Local Network Segmentation (initial) | Upon connection, the IoT device is assigned to some local network segment in accordance with policy, which may include an assessment of its security posture. |
| S4.C5 | Behavioral Analysis | Device behavior is observed to determine whether the device meets the policy criteria required to be permitted to perform a given operation (e.g., to access a high-value resource or be placed on a given network segment). |
| S4.C6 | Local Network Segmentation (ongoing) | The IoT device can be reassigned to a different network segment based on ongoing assessments of its conformance to policy criteria. |
| S4.C7 | Periodic Device Reauthentication | After connection, the IoT device’s identity is periodically reauthenticated in order to maintain network access. |
| S4.C8 | Periodic Device Reauthorization | After connection, the IoT device’s authorization to access the network is periodically reconfirmed in order to maintain network access. |
1.6 Scenario 5: Establishment and Maintenance of Credential and Device Security Posture Throughout the Lifecycle
This scenario involves steps used to help establish and maintain the security posture of both the device’s network credentials and the device itself. It includes the capability to download and validate the device’s most recent firmware updates, securely integrate with a device intent enforcement mechanism (e.g., Manufacturer Usage Description (MUD) [4]), keep the device updated and patched, and establish and maintain the device’s network credentials by provisioning X.509 certificates or DPP Connectors to the device and updating expired network credentials. Table 26 lists the capabilities that may be demonstrated in this scenario. None of these capabilities are integral to trusted network-layer onboarding; however, they may be used in conjunction with or subsequent to trusted network-layer onboarding to enhance device and network security.
Table 2‑6 Scenario 5 Credential and Device Posture Establishment and Maintenance Capabilities That May Be Demonstrated
| Demo ID | Capability | Description |
|---|---|---|
| S5.C1 | Trusted Firmware Updates | The device can download the most recent firmware update and verify its signature before it is installed. |
| S5.C2 | Credential Certificate Provisioning | The onboarding mechanism can interact with a certificate authority to sign a device’s X.509 certificate and provision it onto the device. |
| S5.C3 | Credential Update | The device’s network credential can be updated after it expires. |
| S5.C4 | Server Attestation | Successful server attestation is required prior to permitting the server to perform some operation on the device (e.g., prior to downloading and installing updates onto the device). |
| S5.C5 | Secure Integration with MUD | The network-layer onboarding mechanism can convey necessary device intent information (e.g., the IoT device’s MUD URL) to the network in encrypted form, thereby securely binding this information to the device and ensuring its confidentiality and integrity. |
| S5.C6 | Lifecycle Management Establishment | The device has a lifecycle management service and can automatically establish a secure association with it after performing network-layer onboarding and connecting to the network. |