Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: TG9 MLME questions Date Submitted: 19 March, 2014 Source: Tero Kivinen, Company: INSIDE Secure Address: Eerikinkatu 28, FI-00180 Helsinki, Finland Voice:+358 20 500 7800, FAX: +358 20 500 7801, E-Mail: kivinen@iki.fi Re: TG9 MLMN question Abstract: Open issues in the MLME calls Purpose: Try to get the MLME calls fixed Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15. Tero Kivinen, INSIDE Secure

2. Tero Kivinen Beijing, China March 19, 2014 Open issues in MLME calls in TG9 predraft6 Tero Kivinen, INSIDE Secure

3. Tero Kivinen, INSIDE Secure We need to define SAP • We have two SAPs • One for the Multipurpose fragmentation layer (MP-SAP) • Another for the KMP (KMP-SAP)

4. Tero Kivinen, INSIDE Secure We need to define data model • I.e what is stored and where. • Where is all KMP configuration data • Who keeps track of Key Index/Key Source • Etc • Not really an issue for the Multipurpose layer, as it does not store data

5. Tero Kivinen, INSIDE Secure Multipurpose SAP • This is the lower layer calls between KMP (or any other multipurpose layer) and the MAC, i.e. the shim layer doing the fragmentation and sending data. • Naming: MP-SAP

6. Tero Kivinen, INSIDE Secure MP-SAP calls • MP-DATA.request, indication and confirm • MP-PURGE.request, confirm • Matching MCPS-DATA.* and MCPS-PURGE.* • Change the KmpIdValue / KmpDataLength / KmpDataPayload to MultipurposeId / MPDataLength / MPData

7. Tero Kivinen, INSIDE Secure Arguments to the calls • We need to match the MCPS-DATA calls • In KMP we do not need SrcAddrMode etc, but for sending other multipurpose messages, it will be needed, so we need to have it in MP-SAP. • Also need the PANId • What about the other arguments • MCPS-DATA has lots of other arguments, and not all of them are applicable. • Anything that affects how we send data is something we should include. • For receiving parameters there is problems, as what shall we do if the things are different in different fragments we receive.

8. Tero Kivinen, INSIDE Secure SecurityLevel KeyIdMode KeySource KeyIndex <all other in MCPS-DATA.request which are applicable> MP-DATA.request • SrcAddrMode • DstAddrMode • DstPANId • DstAddr • MultipurposeId • MPDataLength • MPData • MPHandle

9. Tero Kivinen, INSIDE Secure MP-DATA.confirm • MPHandle • status

10. Tero Kivinen, INSIDE Secure SecurityLevel KeyIdMode KeySource KeyIndex <all other in MCPS-DATA.indication which are applicable> MP-DATA.indication • SrcAddrMode • SrcPANId • SrcAddr • DstAddrMode • DstPANId • DstAddr • MultipurposeId • MPDataLength • MPData

11. Tero Kivinen, INSIDE Secure MP-DATA.indication • What happens if some of the fragments received has different values for SecurityLevel or so? • Should we leave them out too?

12. Tero Kivinen, INSIDE Secure MP-PURGE.request/confirm • MP-PURGE.request • MPHandle • MP-PURGE.confirm • MPHandle • status

13. Tero Kivinen, INSIDE Secure KMP-SAP • Data model questions: • Where is KMP configuration data • Who updates the MAC security PIB • Who owns the KeyIndex and KeySource • Who drives the starting of the KMP • Who drives the rekeying

14. Tero Kivinen, INSIDE Secure KMP Configuration data • KMP needs configuration before it can start or respond to key management protocol. • 1) Either push all configuration to the KMP using KMP-SAP before doing anything • Lots of data • 2) Ask information from the higher layer with KMP-SAP when needed • Only data needed for current KMP is in the KMP at time • 3) Leave it unspecified • higher layer will provide configuration data to the KMP in whatever way is suitable for the given setup and given KMP • Perhaps it is best to use the option 3, i.e. KMP assumes it has all the data it needs

15. Tero Kivinen, INSIDE Secure MAC Security PIB • Who will push the keying material to the MAC security PIB • 1) KMP does that directly • 2) Goes through the higher layer • I think option 1 is the only reasonable • We do not want to expose keying material to the higher layer • Makes FIPS etc certification hard • Unnecessary burden to upper layer • To allow KMP to do it, the KMP needs to know everything that is needed to fill in the security PIB • This means KMP owns the keying data

16. Tero Kivinen, INSIDE Secure Who owns the KeyIndex and KeySource • I.e who allocates and decides which KeyIndex and KeySource is used. • 1) Higher layer keeps track of them and allocates and owns them • 2) KMP does the same, and gives that information to the higher layer • Option 1 is better, as higher layer is only one who knows what it wants • That means the KMP-SAP calls do require KeyIndtifierMode, KeyIndex and KeySource arguments

17. Tero Kivinen, INSIDE Secure Rekeying • How to do rekeying • 1) Just do KMP rekeying, i.e. KMP regenerate keying material, and then higher layer will generate new keys and push them. • How does it coordinate it with other end • 2) Do KMP rekeying for each SA separately • 3) Use KMP calls to just create new SA, and higher layer will start using it when it wants, and deletes the old one, i.e. no explicit rekey. • I would suggest option 3.

18. Tero Kivinen, INSIDE Secure Other SA management • Deleting SA • Error notifications • Group key management • If the higher layer owns the KeyIdentifierMode, KeyIndex and KeySource then it can use them to create keys, but it needs a way to transmit those keys to other end. • Purging ongoing KMP operations

19. Tero Kivinen, INSIDE Secure KMP-CREATE.request • Used to create new SA between peers • Called from higher layer to KMP • Will result call to KMP-CREATE.confirm if KMP operation was started / failed • Will result call to KMP-FINISHED.indication when the KMP operation is finished. • Results KMP-CREATE.indication call in the other end • Need special understanding for group key generation, i.e. if creating SA with KeyIdentifierMode >= 2, with same KeySource that already has keys in KMP with other peer, then just transmit keys.

20. Tero Kivinen, INSIDE Secure KMP-CREATE.request • KmpHandle • SrcExtAddr • DstPANId • DstExtAddr • KmpId • KeyIdentifierMode • KeyIndex • KeySource

21. Tero Kivinen, INSIDE Secure KMP-CREATE.confirm • Called when KMP operation has been started, i.e. when the KMP has checked that parameters are ok. • This does not mean that operation can be successfully finished, there is KMP-FINISHED.indication for that.

22. Tero Kivinen, INSIDE Secure KMP-CREATE.confirm • KmpHandle • status

23. Tero Kivinen, INSIDE Secure KMP-CREATE.indication • Indicates that other end has started key creation with us. The higher layer will call the KMP-CREATE.response to indicate whether the other end is authorized to create security association. • How does the indication/response pairing go. Does it use Handle in same way as request/confirm?

24. Tero Kivinen, INSIDE Secure KMP-CREATE.indication • KmpHandle • SrcPANId • SrcExtAddr • DstPANId • DstExtAddr • KmpId

25. Tero Kivinen, INSIDE Secure KMP-CREATE.response • Called by the higher layer in response to the KMP-CREATE.indication to specify whether the other end is authorized to create security associations

26. Tero Kivinen, INSIDE Secure KMP-CREATE.response • KmpHandle • AllowOperation

27. Tero Kivinen, INSIDE Secure KMP-FINISHED.indication • Called in both initiator and responder to indicate the higher layer that KMP has finished the creation of the security association. • This means that KMP has updated the security PIB values, and higher layer can use the keys • Higher layer might also fill in rest of the security PIB values at this point, if it wants to use this key for only some specific use cases, like only for certain command frames or similar. • Do we need status to indicate whether operation succeeded, or do we call this only if things succeeded?

28. Tero Kivinen, INSIDE Secure KMP-FINISHED.indication • SrcPANId • SrcExtAddr • DstPANId • DstExtAddr • KmpId • KeyIdentifierMode • KeyIndex • KeySource

29. Tero Kivinen, INSIDE Secure KMP-DELETE.* • Deletes the security association. • Request starts operation, indication will tell the responder that security association has been deleted, confirm will tell initiator that other end has acknowledged that security association has been deleted.

30. Tero Kivinen, INSIDE Secure KMP-DELETE.request • KmpHandle • SrcExtAddr • DstPANId • DstExtAddr • KmpId • KeyIdentifierMode • KeyIndex • KeySource

31. Tero Kivinen, INSIDE Secure KMP-DELETE.indication • SrcPANId • SrcExtAddr • DstPANId • DstExtAddr • KmpId • KeyIdentifierMode • KeyIndex • KeySource

32. Tero Kivinen, INSIDE Secure KMP-DELETE.confirm • KmpHandle • status

33. Tero Kivinen, INSIDE Secure Rekey with different Key Index • Rekey is done by calling KMP-CREATE.request to create new security association • After KMP-FINISHED.indication and suitable timeout, the traffic can be moved to new security association • Then old security association can be deleted by calling KMP-DELETE.request

34. Tero Kivinen, INSIDE Secure Inplace Rekey • KMP-CREATE.request can also be used to do inplace rekey to replace existing key with new key. • This might cause packets to be lost, because different ends has different keys

35. Tero Kivinen, INSIDE Secure KMP-PURGE.request / KMP-PURGE.confirm • Operations to cancel existing CREATE operations. • Can we use the same call to cancel other operations like KMP-DELETE?