Minutes Webex 21 October 2014, 6TiSCH Security Task Force

Note: timestamps in PDT.

Taking notes (using Etherpad)

1. Michael Richardson
2. Thomas Watteyne

Present (alphabetically)

1. Thomas Watteyne
2. Michael Richardson
3. Kris Pister
4. Mike Seewald
5. Pat Kinney
6. Subir Das

Recording

• not possible due to IETF space being full.

Minutes

1) we got started 10 minutes late, and reviewed what the purpose of the draft-richardson-6tisch-security-6top document was.

There are two places for this text. a) into the 6tisch-architecture (or possibly a new document, as per the WG) b) into the 6tisch-6top document for the actual objects to adjust. c) into some other documents that might wind up in ANIMA.

2) we worked on section 3. we added some terms to the glossary and struggled with the "network-wide" shared symmetric key that many other details cryptographic key agreement protocols assume exists in order to authenticate exchanges.

3) we discussed whether or not we could use the 6top-over-15.4 Information Elements (IE) to do security bootstrapping, and concluded that we can not, as on the JOIN mac-key which authenticate that process would be well known.

4) we discussed the question of end-to-end, JCE<->JoiningNode communication, and the relative merits of the four possibilities outlined in section 3, page 6. We agreed that option (1) [ipip] was a poor choice, and that while option (4) was a really good choice, it might not be possible. We were left with whether a new DODAG or the existing base DODAG was the right answer.

5) we concluded that for self-organizing (no PCE) 6tisch networks, that per-pair L2 keys were very important due to the use of mac-layer IE to do schedule updates. This has a code and energy impact on nodes in that they need to support one of the per-pair mechanisms listed on page 5 (section 3)[MLE,802.15.9,ohba-6tisch-security,piro-6tisch-secuirity].

Not only is there a code space requirement, but there is also the need to have enough non-volatile storage to keep all of the (unique) keys to talk to each of one's neighbours.

The upshot of this is that if you want to simplify the motes further, then having a PCE/JCE is an effective way as the motes need only maintain a single DTLS/CoAP/6top security association with the PCE, and the L2 network key could be common across the entire network.

6) we did not finish discussion of section 3, and we will come back to that next week, and also talk about what is in the packets 10-13, and if we can cache anything that would reduce join traffic.

we did dicuss intensitivity of join traffic, and how the JCE can control how many nodes (and in which order) they join.

7) I will provide an overview in the Oct. 24 group call, and I will revise the document slightly for next week.