# A Security Framework for the Internet of Things in the Future Internet Architecture
## 6 Delegation-Based Key Provisioning Protocol
### Discussions and Security Analysis
#### Protocol Security Analysis  
The key provisioning protocol provides strong security on provisioned keys by leveraging two different protocols, namely a three-party key distribution protocol (3 PKD) and a two-party SIGMA protocol, for parent-guardian authentication. These two protocols are overlaid with _enhanced protocol session context (all identifiers and nonces)_ so that all protocol participants have consistent and a correct view of the protocol session. Upon the successful completion of the key provisioning protocol, each party needs to confirm its commitment to the fact that they agree on, and contribute (e.g., contribute a nonce) to the shared secret(e.g., a shared key or a seed used to generate a shared key). Introducing enhanced protocol session context into the protocol design excludes the possibility of an identity misbinding attack, where an attacker successfully convinces the peers that the key exchange succeeded, yet the key agreement is bound by each of the participants to a wrong \"peer\" [44]. One of the measures adopted in the key provisioning protocol to prevent identity-related attacks, e.g., a misbinding attack, is adding identifiers in the corresponding messages when necessary We assume the identifiers of Child \(C\), Guardian \(G\) and Parent \(P\) are \(ID_{C}\), \(ID_{G}\) and \(ID_{P}\) respectively. In the context of the MobilityFirst-IoT, there are two types of identifiers : the globally-used GUID and the locally-used membership credential. Thus, \(ID_{G}\) and \(ID_{P}\) should be the GUIDs of \(G\) and \(P\) respectively. However, as \(C\) is typically a low-end IoT edge device, it does not necessarily have a GUID. Further, before the completion of the key provisioning protocol, as \(C\) has not successfully finished the device registration yet, \(C\) does not hold a local membership credential of \(G\)'s network. In fact, \(ID_{C}\) should be a \"local\" identifier recognizable by \(P\) and used to facilitate the establishment of a long-term membership key shared with \(G\). To summarize, \(ID_{C}\) is neither a GUID nor a local membership key. Instead, \(ID_{C}\) is only a local identifier that uniquely identifies \(C\) at \(P\). For example, assuming \(P\) is a device manufacturer and \(C\) is a product device from \(P\), then \(ID_{C}\) could be the model and serial number that is stored in \(P\)'s database. In other application scenarios of the key provisioning protocol, \(ID_{G}\) and \(ID_{P}\) are not necessarily GUIDs, which is specific to the design of the MobilityFirst network. Alternatively, \(ID_{G}\) and \(ID_{P}\) could be any other forms of identifier that allow \(G\) and \(P\) to identify and further authenticate each other. The first stage of our protocol contains the first three messages and corresponds to the first stage of [PERSON]'s 3 PKD protocol, in which each of the two peer parties contributes a nonce to the new protocol session. Also, as the \"server\" \(P\) is unknown to \(G\) at this point, \(C\) explicitly specifies its Parent \(P\) by providing \(ID_{P}\). This design provides flexibility, which many other existing server-based key distribution protocols, such as Kerberos, lack. In Message 2, the identity of the Parent is specified by the Child, and hence the Guardian knows who to contact for delegation from the Child. In practice, as a Child may have several pre-existing trust relationships that can be leveraged, the Child has the freedom to direct the Guardian to any of the Parents sharing an established trust. In case one Parent is unreachable by the Guardian or the mutual trust establishment between the Guardian and the Parent fails, the Guardian may inform the Child of the delegation failure. Then the Child can in turn provide another Parent as the new referee. In the second stage (Message 4-6), which corresponds to the SIGMA protocol, a Parent-Guardian authentication is completed using the Diffie-Hellman exchange. This authentication process, facilitated by a PKI, is essential to exclude the possible collusion of the Child and the Parent.