# A Security Framework for the Internet of Things in the Future Internet Architecture
## 6 Delegation-Based Key Provisioning Protocol
### Protocol Design Choices and Considerations
#### 6.5.1 Investigation of Three Party Key Exchange Protocols  
There are several existing three party key exchange protocols. Particularly, we examine two representatives: [PERSON]'s 3 PKD [45] protocol and Needham-Schroeder protocol [46]. One of the major differences between these two protocol is that Needham-Schroeder protocol is good for establishing a one-time use shared key (e.g., session key), while [PERSON]'s 3 PKD protocol can generate a long-lived shared key. In the Needham-Schroeder protocol, the Parent, which serves as the key distribution center (KDC), generates the secret key and sends it to the one of the two peer parties (the Child and the Guardian) directly. Then the party, who receives the key from the Parent, shares the key with the other peer party with proper challenge-response verification. With the Needham-Schroeder protocol, all three protocol participants know the shared key that will be used between the two peer parties. However, the Parent does not necessarily need to know this shared key. This fact increases the risk of secret leakage and requires the generated key to be used and discarded as soon as possible because once the Parent is comprised, the shared key generated with the assistance of the Parent will be subject to leakage. In [PERSON]'s 3 PKD, the Parent provides a \"session key\" to the Child and the Guardian directly at the same time, and thus this \"session key\" may be used as a seed, with which the Child and the Guardian can compute a shared key by themselves without being known by the Parent. This strategy follows the least privilege principle and is preferred for generating a long-term key. Even if the server is comprised later, the shared key derived from the seed will not be comprised. Another problem with Needham-Schroeder protocol is its vulnerability regarding a replay attack [47], which is fixed in the Kerberos protocol [41] by the adding a timestamp. Kerberos is another widely used key distribution protocol based on the Needham-Schroeder protocol. However, Kerberos is not suitable for our purposes for the following reasons: (1) it suffers from the single point of failure; (2) the centralized KDC model is not flexible and scalable enough to support heterogeneous Parent devices on a global scale. Different edge IoT devices (Child devices) may have different Parent devices, which have pre-existing trust relationships and can provide verification and/or delegation regarding to the corresponding Child devices. Due to the vast type and quantity of the Child devices, the Parent devices are also heterogeneous and numerous. As a result, extending Kerberos to our context (e.g., a global-wised MobilityFirst-based IoT architecture) is not feasible. (3) Kerberos has a strict time requirement, which means the clocks of the involved devices must be synchronized within configured limits. However, accurate clock synchronization might be too expensive for many low end IoT devices. Hence, in this protocol, we prefer to use nonces instead of timestamps. On the other hand, [PERSON]'s 3 PKD protocol has a solid security proof and no attack against it has been identified yet. Therefore, based upon the analysis above, we chose [PERSON]'s 3 PKD protocol as the blueprint for the delegation-based key provisioning protocol. However, [PERSON]'s 3 PKD protocol alone cannot satisfy our requirements and achieve our goal. There is an assumption in [PERSON]'s 3 PKD protocol that the Parent is trusted by both the Child and the Guardian before the protocol execution. Unfortunately, this is not necessarily always true in our setting. If the Guardian and the Parent have already established a secure communication channel, then they may leverage such an advantage to facilitate the Parent to delegate the Guardian the privilege to establish a key with the Child. Alternatively, if the Guardian does not know the Parent previously and/or there is no secure communication channel between the Guardian and the Parent, these two parties need to build mutual trust on the fly during the on-going protocol session.