Minutes Webex 16 December 2014, 6TiSCH Security Task Force

5-6pm EST

• note taker: Rene Struik
• slides discussed (and referenced in minutes): https://drive.google.com/file/d/0B2a6Ilxu1XfCOGxkbm05NlEwbms/view?usp=sharing}

Attendance

1. Michael Richardson
2. Malisa Vucinic
3. Tero Kivinen
4. Yoshi Ohba
5. Subir Das
6. Jonathan Simon
7. Rene Struik

Agenda

The suggested agenda was approved.

Agenda:

• administrativia {agenda bashing/minutes}
• join protocol details
  • (brief!) status update MAC behavior
  • continuation of routing/communication flow aspects {last week, we did not finish the only two slides on this}
• input 6tisch security to other 6tisch documents

Join process - brief status update MAC behavior (item #2a of agenda)

RS suggested he had sent out a preliminary MAC behavior write-up (that elaborated in much more detail the contents of Slides 5-8) to most 6tisch stakeholders, so as to solicit offline feedback on accuracy and completeness. He expected that the write-up would help in streamlining discussions and not repeating technical discussions. He suggested that the topic re MAC behavior had run its course in the calls, with conclusion for now, and suggested that this only be brought up again after first giving appropriate attention to other (non-MAC related) join process aspects (to which participants at the call agreed).

Routing/Communication flow aspects

RS went over Slides 9-11 of the slides, which dealt with degrees of knowledge at various stages of the join protocol flows, its consequences, and with trade-offs re keeping temporary state on, e.g., the neighbor node (join assistant) during the join process. During the presentation, RS mentioned that on Slide #10, the term "link local address" should be read as "local address" (so, as to avoid unintended connotation of terms already in use with IETF). There was a discussion after conclusion of the presentation, captured below. {Editorial note minute taker: as convenience for readers, some terms used on slides are described using alternative lingo capturing similar meaning (e.g., join assistant and JCE).}

• Slide 9:
  • no discussion
• slide 10:
  • JS elaborated on the join protocol flows with w/HART. Most salient aspects include the following:
    • a) the joining node communicates directly to the server (JCE), with the neighbor node (join assistant) acting only as relay station, without a security role.
    • b) communication between joining node and server (multi-hop) is secured end-to-end. Security uses pre-shared keying material.
    • c) communication from server to joining node is directed via neighbor node/router (join assistant), where there is an indicator in the message to the neighbor node that the message is not intended for itself, but assumed to travel "downstream", to the joining node. This indication is included in a separate header of the routing header.
    • d) initial communication uses EUI-64 address, whereas short address would be assigned by server, after successful conclusion of security handshakes.
    • e) admittance to the network requires access to the short address and is realized at the same time as the security establishment.
    • f) message relay by the neighbor node (join assistant) would be contingent upon some policy filtering, since only control data is relayed ("quarantine procedure"). No MAC state or counters are strored by the relaying node. Potential DoS attacks are "countered" via rate limiting techniques.
    • g) initial communications from joining node is secured (at MAC layer) using default key, with ASN-based nonce, with authentication-only mode of operation.
    • h) link layer (MAC) security is completely orthogonal to transport layer security, where the latter uses the CCM* mode of operation.
    • i) server configures joining nodes and neighbor nodes (join assistant) with common resources, dedicated set of links, application protocol related info (lots of other devices).
  • SD asked about next steps: he referred to Tero Kivinen's review (informal Security Directorate) review and TK's role in championing ideas in IEEE 802.15.4 and 802.15.9. He suggested that (a) one should not assume a pre-shared key; (b) one does not use a well-known key for the join process. YO suggested that one might still be able to support two types of network, join network and production network. MR was just off the call, so no opportunity to poll his opinion. TK suggested that (a) w/HART was quite different; (b) certain ports were visible to joiners; (c) beacon only relevant to joining nodes; (d) one had only one network ("production network"), with a corner that would relate to the joining node - neighbor device/join assistant ("join network"); (e) it was better to use no security during MAC layer messaging and use the exempt flag construct instead; (f) using a "well-known key" for join security was a bad idea.
• Slide 11:
  • MV came back to the join architecture discussion presented on Slides 9-11. He noted that the slides assumed a role for the router node (join assistant) that stretches further than just the role of relay station: it only forwards traffic to the server after first authenticating the joining node. Here, the idea was that while authentication does not offer fine-grained authorization control (without further filtering mechanisms on the router (join assistant)), it might help in limiting denial-of-service attacks targeting the long-haul communication channel between the router (join assistant) and the server (JCE). MV noted that more fine-grained authorization policies would still require communication with the server (for arbitrage), as would the configuration step in the join process. RS suggested that if credentials were handed out locally ("this node belongs to production facility XYZ"), then network authorization could indeed be done locally, without need for online arbitrage by server, but that credentialing details still needed more work. RS suggested that it would not be too hard to extend this mechanism to support both the relay and the authenticating role of the router (join assistant), where decision whether to support a relay-only mode as well would depend on more detailed cost/benefit analysis. He did suggest that relay-only modes had DoS issues with other IETF specs, such as DNS (hence, his emphasis on denial of service aspects).

AOB

The next conf call is scheduled for Tue January 5, 2015, 5pm EST, after a well-deserved Christmas/New Year's break.