# Enterprise Security for the Internet of Things (IoT): Lightweight Bootstrapping with EAP-NOOB
## 7 Implementation
### Bootstrapping Sequence  
After being powered up, a more starts the bootstrapping process by joining a RPL network in its vicinity. An RPL network is formed when IoT devices exchange two kinds of messages: DODAG Information Objects (DIOs) and Destination Advertisement Objects (DAOs). DIO messages contain the configuration parameters that are necessary for the devices to construct and maintain the DODAG. Once a new device joins the DODAG, it uses DAO messages to announce its parent nodes. This information is propagated to the border router at the root of the DODAG. Neither the device nor the existing RPL network have authenticated each other at this point. Hence, they both treat this as a temporary untrusted association. Before starting an EAP conversation, the IoT device and the controller establish a CoAP level association, as required by CoAP-EAP [52]. These CoAP messages are necessary for exchanging nonces, which are later used together with the keys exported by EAP to derive cryptographic material for protecting the CoAP link between the device and the controller after bootstrapping. These initial CoAP exchanges provide the same functionality as the four-way handshake in Wi-Fi networks. The IoT device initiates the bootstrapping process by sending a Non-confirmable (NON) Client Init CoAP request to the controller on the _/boot_ interface. The controller responds with a _Confirmable (CON) Controller Init_ request. This request includes a 7-byte URI and a random nonce (nonce_c). The IoT device acknowledges the request with an _Ack init_ message, which includes the same seven-byte URI and a random nonce (nonce_s) in the response. After that, the EAP conversation begins. The CoAP messages exchanged during this conversation include EAP content as the payload. The controller initiates the conversation by sending an EAP identity request to the device, to which the device responds with its identity. In EAP-NOOB, all new devices use the same identity ([EMAIL_ADDRESS]). This informs the controller that the device will be bootstrapped with EAP-NOOB and that all EAP transactions for this device should be forwarded to the external AAA server over the RADIUS tunnel. Figure 6: Screen capture of the decoding process. The circular loading bar shows the progress of scanned data and the text on the bottom shows the already decoded URL. By receiving an unknown identity, the AAA server recognizes that a new device is requesting to join the network. It assigns the device a new identity and begins the Initial Exchange with an Elliptic Curve Diffie-Hellman (ECDH) exchange. The EAP-NOOB specification currently only supports ECDHE Curve25519. However, we decided use the NIST P-256 curve instead, since it is supported by hardware in the Firefly notes. The Initial Exchange always ends in an EAP-Failure message indicating that authentication is not yet successful. Once the Initial Exchange is completed, the device starts blinking its LED light and waits for the user to transfer an OOB message to the AAA server. The EAP-NOOB specification defines a Waiting Exchange that the device can perform to check whether the OOB message has yet been delivered. However, it also specifies that configurable timers may be used to rate-limit the frequency of these exchanges. This allows for resource-constrained devices to limit the amount of requests made to the server. Similarly to the Initial Exchange, the Waiting Exchange also ends in an EAP-Failure. After the OOB message has been delivered, the device and the AAA server finish the bootstrapping process with a Completion Exchange. This exchange verifies successful authentication and ends with the creation of a persistent association between the peer device and server. The AAA server also sends part of the MSK key to the controller. As explained earlier, the controller uses it together with the nonces from the initial CoAP packets to derive cryptographic key material. At this stage, the controller adds the new device to the list of authorized devices and finalizes it membership in the RPL network.