# Lightweight CoAP-Based Bootstrapping Service for the Internet of Things
## 3 The Bootstrapping Service: CoAP-EAP
### Bootstrapping Security Associations
#### 3.4.2 CoAP Message Protection at Application Level: AUTH Option  
Once the Controller has received the MSK from the AAA server, it can derive the COAP_PSK. This key is used to generate the values for the new defined AUTH option, which contains a _Message Authentication Code_ (MAC) for integrity protection over the entire CoAP message. The reason for using this option is that it has been proved that running a DTLS handshake can be really costly in terms of time in IEEE 802.15.4 networks [74]. Thus, certain applications may prefer not to perform the DTLS handshake. In fact, other types of (non-IEEE 802.15.4) networks considered in IoT, generically referred to as LPWA (or LPWAN) for _low power wide area (network)_[75] are generally low power and low-throughput [76] and, therefore, saving bits in the link is a benefit. In Figure 5 we can see an example of message protection with the AUTH Option.The first time this option appears is during the bootstrapping phase in the message that conveys the EAP Success (step **16**'). The corresponding ACK message (step **17**') from the Smart Object, which closes the bootstrapping phase, also includes an AUTH option. By verifying the MAC, one endpoint can know whether the other endpoint owns the COAP_PSK. Since AUTH option is a new type of protection, a new port (to be assigned by IANA) and a new URI scheme identifier (e.g., \"coapa\") should be allocated. Thus, this last exchange will go through this new port. From this point, any message related with the bootstrapping service (e.g., to remove the bootstrapping state as explained in Section 3.5) will include the AUTH option. Any other service (e.g., to obtain the temperature from the smart object), implying the communication between the Smart Object and the Controller, can also use the AUTH option (steps **18**' and **19**'). Nevertheless, this does not preclude the use of DTLS, as we will see in Section 3.4.3 with the derivation of the DTLS_PSK. In fact, the use of either DTLS or AUTH will depend on the service URI, \"coaps\" or \"coapa\", respectively. The use of different URIs to indicate the protection of the exchange are exclusive. The reason is that it is not useful to provide integrity with the AUTH option and ciphering with DTLS, since DTLS already offers the possibility of using integrity and ciphering. Hence, the use of the AUTH option is used when a very simple and less taxing approach is needed. COAP_PSKK is a 16-byte length key which is computed using AES-CMAC-PRF-128 [77] as _Key Derivation Function_ (KDF), which, in turn, uses AES-CMAC-128 [78]. Both primitives use AES-128 [79] as building block since it is widely used in constrained devices. \[COAP\_PSK=KDF(MSK,\"IETF\_COAP\_PSK^{\prime\prime}||nonce-c||nonce-s,64,length) \tag{1}\]  
where  
The _AES-CMAC-PRF-128_ is defined in [77]. This function uses AES-CMAC-128 as a building block; The _MSK_ is exported by the EAP method; \"IETF_COAP_PSK\" is the ASCII code representation of the non-NULL terminated string (excluding the double quotes around it). This value is concatenated with the value of the nonces exchanged; 64 is the length of the MSK; _length_ is the length of the label \"IETF_COAP_PSK\" (13 bytes) plus the two nonces; _nonce-c_ is a random value sent from the Controller to the Smart Object; _nonce-s_ is a random value sent from the Smart Object to the Controller. To calculate the MAC value, an endpoint inserts the AUTH option and sets its value to 16 bytes with zero. Then, it applies the function AES-CMAC-128 to generate the AUTH Option value over the entire message as follows:  
\[AUTH\ Option\ value=AES-CMAC-128(COAP\_PSK,message,length) \tag{2}\]  
where  
\[COAP\_PSK\]  
is the key derived in Equation (1); _message_ is the CoAP message including the AUTH option filled with zeros; _length_ is the length of the CoAP message including the AUTH option.