# A Security Framework for the Internet of Things in the Future Internet Architecture
## 6 Delegation-Based Key Provisioning Protocol
### Security Requirements  
The delegation from the Parent to the Guardian with respect to the Child can occur to address a variety of concerns. First, IoT edge devices have highly heterogeneous capabilities. The protocol for establishing mutual trust and keys described in Section 6.6 can support capable devices as well as highly resource-constrained devices. Second, establishment of the IoT device keys may be user-friendly, which conventionally requires the protocol to either leverage a trusted public key infrastructure (PKI) that is transparent to the user, or to remove dependency on trusted servers but minimize dependency on manual interaction by users. Traditional PKI or Kerberos services [41] can be challenging to establish on a global scale, and may require substantial IT professional expertise as well as computational resources for cryptographic processing. On the other hand, solutions for key provisioning without a server are often insecure, such as pre-shared key approaches, lacking resilience by working directly with fixed manufacture/device keys, or involving cumbersome and critical manual interaction such as pairing. We try to address these issues in our delegation-based key provisioning protocol.  
Particularly, when developing the key provisioning protocol, the following properties and requirements should be taken into consideration:  
* **Scalability**: As many IoT systems are large scale deployments, it would be extremely difficult to establish a secure credential for each device if human intervention is required. To enhance usability and chance of practical deployment, it is important and necessary to remove manual operations by the user on an out-of-band (OOB) channel, such as secure pairing. Instead, a trusted third party is introduced to facilitate automatic trust establishment as well as reduce human error.
* **Consistency**: All the three protocol participants should have a consistent view of the protocol session. Namely, the three participants involved know who the peers are with respect to the specific session.
* **Dynamic mutual trust and delegation**: With the success of the protocol, each pair of the involved participants can reach a mutual trust at the end of the procedure. Further, the Guardian establishes the mutual trust dynamically with the Parent and obtains delegation before executing the privilege with respect to the Child.
* **Secrecy and forward secrecy**: The principle of least privilege should be followed, implying that any resultant secret key should only be shared between the involved two parties. No third party should be able to distinguish the resultant key from a random key. Also, the _forward secrecy_ should be conserved so that the compromise of a long-term secret key will not affect the confidentiality of past communication sessions [42].
* **Lightweight**: As we focus on those resource limited devices, efficiency is a priority. When designing the protocol, the Child, which is typically, though not necessarily, a resource-constrained device, should be protected by shifting work load to the Guardian and the Parent as much as possible.
* **Average administration requirements**: The protocol should require as little professional knowledge as possible. The configurations are automatic and user-friendly so that people do not need to be IT experts to operate the protocol.