8 May 2018doc.: 15-18-0220-00-004y
Minutes of 802.15.4y SECNat the Marriott Warsaw, Warsaw, Polandin May 2018
IEEE 802.15.4y
SECN (Security Next Generation)Date: 5 - 8May 2018
Name / Affiliation / Address / Phone / email
Author(s):
Don Sturek / Itron, Inc. / San Jose, CA /
Abstract
Minutes of the IEEE 802.15.4y SECNInterim meeting in the Marriott Warsaw, Warsaw, Poland
These are the Minutes of the IEEE 15.4ySECNInterim meeting atthe Marriott Warsaw, Warsaw, Poland
Tuesday, 7May, 2018, PM2
[The chair, Don Sturek (Itron) called the meeting to order at 4:04 p.m.]
[Sturek called for essential patents and there was no response.]
There will be two session of the task group this week. The hope is during these two sessions that the proposals from March can be reviewed and merged. The actual decision to adopt the results will be taken during the July plenary in San Diego. The agenda (15-18/0183r01) was approved without dissent (Kunal/Chris Calvert). The minutes of the Chicago meeting (15-18/0110r01). The timeline will be finalized during the July meeting.
Sturek reviewed the gist of each of the three proprosals: Kivinen: 15-18/0109r01, Itron: 15-18/0087r00, and Blind Creek: 15-18/0095r00. He suggested that Kivinen’s proposal seemed the most promising but thought there might be use for an optional Information Element that could describe the device sending it and the encryption mode.
The key descriptor table was displayed from 15-15/0106r07. The things that need to be added to the existing secKeyDescriptor include key length and algorithm/mode, which might be specified in a single field that combines the two. The IETF IANA has alistof AEAD algorithm names and values that might be used. Some of the values can’t be used in IEEE 802.15.4 because they have tag lengths (MIC values) that are not supported in IEEE 802.15.4.
Sturek noted that he has withdrawn the Itron proposal from consideration. He asked Ben Rolfe he might withdraw the Blind Creek proposal because that way, no modifications to the packet format are required. An amendment to IEEE 802.15.9 might be needed in order to allow it to populate the PIB with all of the necessary information. (Separately, IEEE 802.15.9 needs to be amended to describe how key derivation works.) Rolfe is willing to do so if we are certain that no over-the-air conveyance of the key length, algorithm, and mode are needed. Not sending things over the air needlessly seems to be a good thing. IEEE 802.15.4 Section 7.4.2.13 (RCC Capabilities IE) might be extended if there were a need to advertise a device’s crypto capabilities rather than coming up with a whole new IE. For now, there doesn’t seem to be a pressing need to an IE and one won’t be written into the proposed text unless someone comes up with a definitive use case to justify doing the work. While IEEE 802.15.9 recommends how certain key management protocols can be used with IEEE 802.15, the informative annexes specifying the key management protocol convergences were written with only AES-128 as an expected target algorithm. So, there’s work to be done to update IEEE 802.15.9 almost certainly.
Work would be done in IEEE 802.15.4 Annex C to specify how different algorithm choices affect the frame encryption processing. This could be done in IEEE 802.15 TGmd (maintenance). Annex C has an example based on AES-128 (CCM). It would be incumbent on IEEE 802.15.4y to provide matching examples for any algorithms that we desire to support. Or it might make sense to put new examples into a living document (on Mentor?) so that it can be a more dynamic repository. Sturek suggested that Wireshark dissectors would also be a good demonstration of how a mechanism is expected to behave. It might be possible to host these things on Github or something similar. Rolfe reported that the IEEE lawyers have been looking at this topic and he hasn’t seen much resolution to date. It’s tricky to normatively reference something that’s not controlled by an SDO. Sturek will document the approach we appear to be agreeing on. That will be presented to the task group during the second time slot allocated for this meeting.
Sturek asked the task group to consider what it would take to support multicast encryption. Tero Kivinen is aware of some work being done in the IETF IPSECME working group that might be informative to that process. It seems like work would need to be done on a revised IEEE 802.15.9 to deal with multicast. This task group wouldn’t need to change anything it’s doing in order to have support for multicast in the future as long as IEEE 802.15.9 handles populating multicast keys into the key descriptor table. Sturek will look at doing a WNG proposal in San Diego that solicits support for an IEEE 802.15.9 revision to cover varying key lengths and multicast.
Specification text to implement Kivinen’s proposal could probably be ready by November. The work in IEEE 802.15.9 is orthogonal and its timing won’t affect the work on IEEE 802.15.4y.
Wednesday, May 9, 2018, AM1
Reconvened at 8:04 a.m.]
Sturek presented the closing report (15-18/0219r00), which will be presented during the Thursday night closing plenary session.The timeline includes a call for revised/new proposals prior to the San Diego meeting.Given the agreement here to converge on a single proposal, there isn’t really an expectation of any new proposals, but the option is left open in case there were unconsidered issues at this meeting.Slide 7 indicates work that will need to be done in TGmd in order to allow switching from CCM* to a broader set of AEAD algorithms.This includes needing to generate new Annexes B and C material to cover worked examples (essentially test vectors) for each new algorithm.Work will need to be done to revise IEEE 802.15.9 in order to define how keys are derived from a master secret that is generated by the key management protocol – some algorithms require separate input keys for encryption and authentication.Once that is done, IEEE 802.15.9 would likely not need to be changed again should there be new AEAD ciphers defined in IEEE 802.15.4.
[Adjourned at 8:22 a.m.]
15.4ySECN minutes May 2018page 1 of 3