1. doc.: IEEE 802.15-14-0184-00-0009 Submission Mar 2014 Tero Kivinen, INSIDE Secure Slide 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.

2. doc.: IEEE 802.15-14-0184-00-0009 Submission Mar 2014 Tero Kivinen, INSIDE Secure Slide 2 Open issues in MLME calls in TG9 predraft6 Tero Kivinen Beijing, China March 19, 2014

3. doc.: IEEE 802.15-14-0184-00-0009 Submission Mar 2014 Tero Kivinen, INSIDE Secure Slide 3 MLME/MCPS calls We currently have two levels of calls –Higher level calls starting KMP, rekeying etc –Lower level calls to send fragmented data packet and receive it.

4. doc.: IEEE 802.15-14-0184-00-0009 Submission Mar 2014 Tero Kivinen, INSIDE Secure Slide 4 Lower level calls MCPS-KMP-DATA.request, indication and confirm MCPS-KMP-PURGE.request, confirm Matching MCPS-DATA.* and MCPS- PURGE.* Should the name have KMP in, it as we area talking about fragmented packets.

5. doc.: IEEE 802.15-14-0184-00-0009 Submission Mar 2014 Tero Kivinen, INSIDE Secure Slide 5 Naming Perhaps talk about multipurpose packets, i.e. MCPS-MP-DATA / MCPS- MP-PURGE.* They can be used to send other things than KMP. Also change the KmpIdValue / KmpDataLength / KmpData/Payload to MPIdValue / MPDataLength / MPDataPayload or something.

6. doc.: IEEE 802.15-14-0184-00-0009 Submission Mar 2014 Tero Kivinen, INSIDE Secure Slide 6 Arguments to the calls Do we need PANId –In MCPS-DATA.request we have DstPANId and DstAddr, in our call we have only DstAddr, no PANId –Also do we need SrcPANId? What order should the arguments be –SrcPANId, SrcAddr, DstPANId, DstAddr –SrcAddr, SrcPANId, DstAddr, DstPANId –Where should the payloadHandle be? Current it is first In MCPS-DATA it is after addresses and payload

7. doc.: IEEE 802.15-14-0184-00-0009 Submission Mar 2014 Tero Kivinen, INSIDE Secure Slide 7 Higher level calls These are harder to understand, who calls them, what are they trying to do Are these calls from Higher layer to the KMP? There are also some calls from the KMP to Higher layer to indicate it has done something.

8. doc.: IEEE 802.15-14-0184-00-0009 Submission Mar 2014 Tero Kivinen, INSIDE Secure Slide 8 How to get configuration to KMP KMP needs configuration before it can start or respond to key management protocol. 1) Either push all configuration to the KMP before doing anything –Lots of data 2) Ask information from the higher layer when needed and higher layer pushes it to KMP when needed –Only data needed for current KMP is in the KMP at time I would suggest option 2.

9. doc.: IEEE 802.15-14-0184-00-0009 Submission Mar 2014 Tero Kivinen, INSIDE Secure Slide 9 Who Allocates Key Index In 802.15.4 we have Key Identifier Mode, and Key Index –Most likely higher layer needs to select Key Index, not KMP. –So we might need to add KeyIdentifierMode and KeyIndex to the KMP start calls Another option is to have KMP only to generate keying material and leave the SA filling for the higher layer –The problem is that leaves again lots of stuff unspecified –Also might require special KMP specific operations to be done to create group keys etc. –How the other end will know which key index is going to be used, how to group keys are generated etc.

10. doc.: IEEE 802.15-14-0184-00-0009 Submission Mar 2014 Tero Kivinen, INSIDE Secure Slide 10 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.

11. doc.: IEEE 802.15-14-0184-00-0009 Submission Mar 2014 Tero Kivinen, INSIDE Secure Slide 11 Other SA management Deleting SA Error notifications Group key management Purging ongoing KMP operations

12. doc.: IEEE 802.15-14-0184-00-0009 Submission Mar 2014 Tero Kivinen, INSIDE Secure Slide 12 Proposed calls *.create (From Higher Layer to KMP) –Runs KMP and creates SA. Gets KeyIndex and KeyIntifierMode as argument. –Can be used to rekey SA, i.e. create new SA, and delete old –Is given the configuration needed to run KMP *.indication (From KMP to Higher Layer) –Called when new key is being created and we are responding to it. –Asks Higher Layer to provide the configuration *.response (From Higher Layer to KMP) –Gives configuration needed to finish the KMP started by other end *.finished (From KMP to Higher Layer) –Final call from the KMP to the Higher Layer to indicate that the SA is now ready and it can be used. Gives the KeyIndex etc, and the SA PIB has already been filled in. –Called in both Initiator and Responder *.delete (From Higher Layer to KMP) –Delete existing SAs –And Matching confirmation