Minutes Webex 02 November 2014, 6TiSCH Security Task Force
Two security meetings were held that day. These minutes refer to the second one.
Minutes compiled by Michael Richardson:
Attending: - Thomas Watteyne (TW) - Michael Richarson (MR) - Tero Kivinen (TK) - Malisa Vucinic (MV) - Rene Struik (joined :30) (RS) - Pascal Thubert (joined :50) (PT) Tero composed a summary of his views, which he sent to secdir and to me privately. is it at: https://mailarchive.ietf.org/arch/msg/secdir/xqPZrSNhkXyD8n4Y5yerG2BmSVc and I will likely reply to that message into this list. The discussion started from a need to understand if we had one or two beacons coming from the join assistant. I assumed that there would be two, and that one would be secured with the production network key, and the other with the well known beacon key. There was various amount of discussion as whether or not this was even possible to do with available MAC implementations. I took an action to research how much of the MAC implementation is in software in the "main" CPU, and how much is logic in the MAC (whether it's hard logic, or immutable firmware doesn't matter). I hope to post that summary on Monday. Associated with this discussion was some details about the current 802.15.4 receiver state machine, and changes that TK is making in the -2015 revision. A suggestion was made to have one beacon, just the production beacon. This made a number of us unhappy, as if you can trick someone to use lower ASN, you cause them to send more data with a previous key, and due to the replay issue with stream ciphers, you may be able to guess what sent the previous time. We transitioned to the idea of having one beacon, authenticating it only. Nodes which have the production network key will be able to authenticate the beacon and pull the correct ASN. Joining nodes won't be able to authenticate the traffic, but will be able to use the beacon to synchronize to the network and find the Aloha slot. We talked about the use of a virtual extended address for sending beacons, as the L2-keys are per-extended (source) address, and since multiple nodes will need to send the beacon (for radio coverage in the mesh), it needs to be done right. We discussed whether or not the join traffic itself should be encrypted with some well known key (different from the production network key, which the joining node does not yet know). Opinions were expressed that it wasn't necessary, and the situation from the Zigbee interop were recounted again. TK suggested that older receiver state machine implementation would have difficulty with encrypted traffic that was differently trusted. - TK: points to "In the P802.15.4-REVc-DF2 section 220.127.116.11 Active and passive channel scan we say: The information from the frame to be unsecured shall be recorded in the PAN descriptor even if the Status from the unsecuring process indicated an error" We discussed what to do with the architecture document, and some text was promised prior to Friday's 6tisch meeting.