# Lightweight CoAP-Based Bootstrapping Service for the Internet of Things
## 2 State of the Art
### General Concept of Bootstrapping  
The term bootstrapping is not new. It was coined in the early 1950s to refer to a load button that was used to initiate a bootstrap program or small program to start the operating system. In computer communications, one of the first protocol to use the term bootstrap was the _Bootstrap Protocol_ (BOOTP) [39] to provide an IP address to a communicating host. This term has evolved, incorporating security aspects and more recently it is referred to in the literature as the process by which a node gathers any necessary information (not only an IP address but also security parameters) to join a network or a service after an authentication and authorization processes [40; 41]. That information can be, for example, available cipher-suites, shared keys, certificates, service parameters, _etc._ Different services can instantiate a bootstrapping solution tailored to their specific needs.  
For example, Mobile IPv6 (MIP6) considered as a service, requires dynamic parameters (cryptographic material, home address IPv6 configuration, _etc._) to be configured for its correct operation [42]. This can be done dynamically after a bootstrapping for the MIP6 service such as that defined in [43], where the _Extensible Authentication Protocol_ (EAP) [12] and _Internet Key Exchange v2_ (IKEv2) [44] have been selected to carry out this process. Another example is related to _Dynamic Host Configuration Protocol_ (DHCP) authentication extension [45] where some cryptographic material is required to protect DHCP. A bootstrapping solution proposed in [46] provides the required material by using EAP transported over an extension of DHCP. As a final example, 3 GPP also defines a _Generic Bootstrapping Architecture_ (GBA) [47] to tackle the bootstrapping problem in cellular networks.  
In general, the concept of bootstrapping can be seen as a framework to be instantiated in different scenarios. As explained in [48] there are three entities involved. A _Bootstrapping Client_ (BC), _Bootstrapping Agent_ (BA) and _Bootstrapping Target_ (BT). Figure 2 illustrates the framework. The BC is the entity asking for access to a service. The BA manages the resources and services, authorizing the access to those services. The BA can rely on an external entity called Authentication Server (AS) to complete the authentication and authorization of the BC. This is what we will do in the design of our architecture (see Section 3.2). The BT is the entity in charge of providing the service under the direction of the BA. The BA and BT can be co-located in the same entity or different entities depending on the deployment.  
There is a protocol or interface, \(A\), used between BA and BC, so they can exchange information about the access to a specific service. Another interface called \(B\) serves to communicate both the BA and the BT and to configure under what conditions BC will access the services offered by BT. The interface \(C\) is used between the BC and BT, for BC to request access to the service.  
As we will detail in Section 2.5, in the particular case of IoT, the interface \(A\) can be instantiated by using _Datagram Transport Layer Security_ (DTLS) [49], _HIP Diet EXchange_ (HIP-DEX) [50], IKEv2 [44], _IEEE 802.1X_[51], or EAP [12]. \(B\) might not be necessary if BA and BT are co-located, but if they are separated entities, the protocol to communicate that BC has permissions to access the service may be CoAP. \(C\) can be instantiated with CoAP as application protocol to request access.