# Lightweight CoAP-Based Bootstrapping Service for the Internet of Things
## 3 The Bootstrapping Service: CoAP-EAP
### General Operation Flow  
In order to run the bootstrapping service, it is necessary to define a _Uniform Resource Identifier_ (URI) so that any endpoint can refer to the service using that value. In particular we defined the URI as _/boot_ for our bootstrapping service. In this manner, when the Smart Object, acting as CoAP client, wants to start the bootstrapping service, it sends a Confirmable _POST /boot_ request to the Controller, which acts as CoAP server in this first exchange (step **1**). Typically, the Controller will answer back with a response message (step **1'**) saying the service is available (CoAP Response Code _2.04_). However, it may omit it and proceed with the following exchange to save this message in the link. Then, the Controller, as CoAP client for the rest of the exchange, immediately sends a Confirmable _POST /boot_ request to the Smart Object as CoAP server from this point on (step **2**). The Smart Object indicates the creation of a resource for the bootstrapping service to the Controller. The message carries a nonce (_nonce-c_), which will be used for the generation of fresh cryptographic material after the bootstrapping execution; and a Token with a value chosen randomly. This value is used as the session identifier and kept during the whole authentication. The smart object assigns an identifier to a resource (value 5 in the example) and answers with an ACK that carries a piggybacked response with a new nonce (_nonce-s_), also used for the same purpose than _nonce-c_, and the Token (step **3**). The _Message-ID_ (MID) values in the requests sent by the Controller are generated _randomly_, as suggested in the CoAP standard. The Controller selects a new Message-ID value each time a new request is sent to the Smart Object, until the bootstrapping service finishes. Moreover, the Controller stores the last Message-ID sent until correctly receiving the corresponding ACK. The Smart Object keeps track of the last received Message-ID to identify retransmissions, and the previous Message-IDs during the current bootstrapping to identify old messages. In general, a request is considered valid in terms of the Message-ID if either this value matches the last value received, which means a retransmission of the last response is required, or the arrival of a new Message-ID, which therefore represents a new message. If these rules do not apply (_i.e._, an old Message-ID has been received), the Smart Object silently discards the request. This is possible because the bootstrapping service is designed as lockstep: the Controller will not send a new request until receiving the corresponding response. When the current bootstrapping exchange finishes successfully, the smart object can free the tracked Message-IDs, except for the last received Message-ID at the end of the bootstrapping, just in case a retransmission is required. After this initial handshake, the EAP authentication starts. Figure 4 shows an example of exchange using the EAP-PSK method and pass-through mode (IdP's AAA server intervenes in the EAP authentication). Nevertheless, the number of messages will depend on the EAP method used. The Controller will use the POST method to send EAP requests to the resource created in the Smart Object. Then, the Smart Object sends an ACK with a piggybacked response to carry the EAP responses to the Controller (steps **4-16**). This corresponds with _phases 1a and 1b_ in the EAP KMF (RFC 5247 [14]). Specifically, the Controller first requests the Smart Object's identity (_EAP Req/Id_) (e.g., _smartobject@domain.net_) (step **4**). Then it sends its identity (_EAP Res/Id_) in an ACK message (step **5**). The Controller uses the information in the identity to route the EAP Response/Id message to the IdP's AAA. Without loss of generality, our example is based on RADIUS as AAA protocol. In Figure 4 we can observe the RADIUS _Access-Request_ message containing the EAP Res/Id (step **6**).