# Lightweight CoAP-Based Bootstrapping Service for the Internet of Things
## 3 The Bootstrapping Service: CoAP-EAP
### Bootstrapping State Definition and Management  
The _bootstrapping state_ is a set of parameters resulting from the bootstrapping process described in Section 3.3. This state is maintained by the Smart Object and the Controller. The bootstrapping state comprises the following values: both entities' IPv6 addresses; authorization information related with the bootstrapping service that came form the AAA infrastructure, in particular, the supported cryptosuite, capabilities (e.g., AUTH-based or DTLS-based protection) of the Smart Object and the lifetime associated to the state; list of keys exported and derived from the bootstrapping procedure (COAP_PSK, DTLS_PSK and ASRK) and a resource identifier generated in the Smart Object after receiving a Confirmable POST /boot request.  
In general, if the lifetime of the bootstrapping state expires at both endpoints it will be automatically removed, along with the associated resource. Nevertheless, the Smart Object or the Controller can explicitly signal a desire to remove the bootstrapping state.  
Figure 6: Protecting post-bootstrapping with datagram transport layer security (DTLS).  
On the one hand, the Smart Object may also request the Controller to abandon the security domain and, thus, to delete bootstrapping state. This is useful because the Smart Object may desire to notify the Controller that it should stop sending accounting information to the AAA infrastructure since, for example, it is leaving the security domain. In a similar way as the Smart Object signals that it wants to start a bootstrapping by sending a Confirmable POST message to the URI of the bootstrapping service (_POST /boot_), the Smart Object can signal the Controller its desire to leave the security domain by the following URI-Path: _/boot?del=X_. The part _/boot_ indicates that the Smart Object requires the Controller to perform some action related to the bootstrapping. This action is defined by the part _?del=X_, which signals to the Controller that the Smart Object desires to leave the security domain, where \(X\) is the resource identifier to be erased. For example, Figure 7 shows the Smart Object sends a protected _Confirmable POST /boot?del=5_ (step **20**) to trigger the Controller to remove resource identifier 5. When the Controller receives this request, it looks for an existing bootstrapping state that matches the identifier. If the Controller has the bootstrapping state, it sends a Confirmable DELETE request (step **21**) to the Smart Object to erase the resource with the assigned identifier (e.g., _\"boot/5\"_). Typically, the Controller can also send the response associated to the POST but the Smart Object considers that receiving the DELETE directly is sufficient. In fact, upon receiving the Confirmable DELETE request, the Smart Object sends a protected ACK with piggy-backed response (step **22**) with a response code to confirm the bootstrapping state is going to be removed (_2.02_). If the Controller already removed the state (e.g., it already expired), it sends an unprotected (there is no bootstrapping state) ACK message with code _4.04 (Not Found_). The Smart Object may not trust this unprotected message and insist on sending POST (e.g., 3 times) to see if it receives a protected Confirmable DELETE request. If the Smart Object does not finally receive this request, it may consider that the Controller has already removed the state. On the other hand, if the Controller wants to delete the bootstrapping state, it only has to start the Confirmable DELETE request/ACK exchange.  
Finally, the Smart Object may want to renew the bootstrapping state (refreshing cryptographic material, lifetime, _etc._) before it expires. This means a new EAP authentication, as we have described in Section 3.3. This new bootstrapping exchange needs to finish before the current bootstrapping state expires. If the new bootstrapping process finishes successfully, the current bootstrapping state is replaced with the new one.  
Figure 7: Example of deleting bootstrapping state (with AUTH-based protection).