Skip to main content

Terminology

We will use the term device interchangeably with the term pledge for easier reading.

  • device: The device wishing to onboard to the network.
  • registrar: The principal decision-making entity in the onboarding process.
  • proxy: A proxy to the registrar - useful if the registrar is located externally or shared between networks.
  • MASA: The Manufacturer Authority, which issues manufacturer assurances (like iDevID) and can attest to the validity of these assurances.
  • router: The physical router to which a device is connecting; the router may potentially host many networks.
  • onboarding network: A constrained network used to bootstrap the onboarding process.
  • target network: The operational network to which the device intends to attach.
  • iDevID: A unique device certificate issued by the manufacturer.
  • LDevID: A certificate used by the device to gain network access (EAP certificate).

Stages Overview

  • O - Factory Provisioning
  • A - Discover Onboarding Network
  • B - Discover Registrar
  • C - Request Voucher
  • D - Enrol the Device
  • E - Join the Network
  • F - Continuous Assurance of the Network

0 - Factory Provisioning

The demonstrated factory provisioning flow is as follows:

  • 0.1 - Device is pre-provisioned with the manufacturer's CA and URI for the manufacturer's servers.
  • 0.2 - Device generates a unique public/private key pair.
  • 0.3 - Device requests an iDevID from the manufacturer.
  • 0.4 - The returned iDevID is installed on the device.

A - Onboarding Discovery

There are two methods for discovering potential onboarding networks:

  • A.1 - Search for public Wi-Fi networks matching a particular SSID wildcard name.
  • A.2 - Search for Wi-Fi networks advertising a particular realm.

A.1 BRSKI SSID Name Wildcard Match​

The device will search for all SSIDs matching the wildcard as specified in 1.

The device will iterate round-robin across successful pattern matches in strength order.

Every time a device finds a viable match, it will connect to the onboarding network and attempt to discover the registrar.

A.2 802.11u eap.arpa​

The device will search for all networks supporting the eap.arpa realm.

The device will iterate round-robin across successful pattern matches in strength order.

Every time a device finds a viable match, it will connect to the onboarding network and attempt to discover the registrar.

Onboarding Process​

The device will prefer onboarding networks with realm support over BRSKI SSID matches.

B - Discover Registrar

When the device discovers a candidate onboarding network, it will attempt to discover the registrar.

If the registrar is non-discoverable, this onboarding network will be temporarily marked as failed, and the onboarding process will proceed to the next candidate onboarding network.

The device operates either in IPV6 or IPV4 mode. The options for Registrar discovery are slightly different in each case.

For the purposes of the NIST Build 5 demonstrator, we shall use the mDNS method of directly discovering the registrar as outlined in Appendix A 2.

Discovery of the registrar MAY also be performed with DNS-based Service Discovery by searching for the service "_brski-registrar._tcp.example.com". In this case, the domain "example.com" is discovered as described in [RFC6763], Section 11 (Appendix A.2 of this document suggests the use of DHCP parameters).

Specifically:

  • Device obtains an IP address via DHCP as per A.2 2.
  • Device listens for service announcement "_brski-registrar._tcp.example.com" as per Appendix B 2.
  • Device secures IP address of candidate Registrar.
  • Device attempts to initiate voucher request.

Discover Registrar (Full Options)​

TBD: Outline the full list of methods for discovering the registrar.

C - Request Voucher Registrar

Preconditions: Before we initiate the Request Voucher, we assume the following conditions are met:

  • device is provisioned with a valid iDevID.
  • device has connected to a candidate onboarding network.
  • device has a valid IP address on the onboarding network.
  • device has discovered the IP address of a candidate registrar (or a proxy).

Post Conditions (Success): If the voucher request is successful:

  • device is in possession of a valid voucher.

  • where the tests that need to pass are

    • voucher has not been revoked, which requires:

      • behaviour of IoT device bound by MUD descriptor

      • No requests to blacklisted domains / IP addresses

      • Manufacturer is trusted

      • Device is trusted or is owned by a user who is trusted to connect devices

      • SBOM vulnerability score lower than set threshold

C - Request Voucher Overview (Basic)​

The complete flow of the voucher request process is as follows:

  • C.0 device creates a partially authenticated TLS connection with registrar.
  • C.1 device constructs voucher request construct request and signs it with iDevID private key.
  • C.2 device sends voucher request to registrar.
  • C.3 registrar validates voucher request.
  • C.4 registrar forwards voucher request to MASA.
  • C.5 MASA validates voucher request.
  • C.6 MASA signs voucher.
  • C.7 MASA returns voucher to registrar.
  • C.8 registrar validates voucher.
  • C.9 registrar returns voucher to device.
  • C.10. device validates voucher.

3 - Request Voucher Overview (Advanced Policy)​

Validation processes exist at stages:

  • C.1 - device constructs voucher request construct request and signs it with iDevID private key.
  • C.3 - registrar validates voucher request.
  • C.5 - MASA validates voucher request.
  • C.8 - registrar validates voucher.
  • C.10 - device validates voucher.

At each of these stages, there is the option to evaluate and enforce a policy decision.

C.3 and C.8 are validation and policy enforcement points implemented at the registrar and therefore ideal for implementing the core networking policy.

D - Enrol the Device

Enrolling the device consists of the following steps:

  • D.0 - Fully authenticate the TLS connection, using iDevID (using the pinned cert in the voucher response).
  • D.1 - Generate LDevID public/private key pair.
  • D.2 - Device constructs the CSR request for enrolment, which includes the iDeviD and is signed by iDeviD.
  • D.3 - Device sends the CSR to the registrar (over the authenticated TLS session).
  • D.4 - The registrar validates the CSR request.
  • D.5 - The registrar constructs the certificate response (LDevID).
  • D.6- The registrar returns the certificate to the device.
  • D.7 - The device saves the LDevID (network credentials) locally ready to attach to the network.

E - Join the Network

Joining the network can be triggered by the device as soon as the device is in possession of a valid LDevID (or other network credential).

The router will receive the network connection request. It may confer with the registrar to check that the device is adequately permissioned to join the network. Typically, this may be performed through the RADIUS interface.

F Continuous Assurance of the Network

For the full details of the continuous assurance process, see the reference document Continuous Assurance.

Appendix: Key References

Footnotes​

  1. https://ftp.kaist.ac.kr/ietf/draft-friel-brski-over-802dot11-00.txt ↩

  2. https://datatracker.ietf.org/doc/rfc8995/ ↩ ↩2 ↩3