Clone wiki

meetings / 150122_webex_security

Minutes Webex 22 January 2015, 6TiSCH Security Task Force

Dial-in information

Agenda

  1. administrativia {agenda bashing/minutes} [4 min]
  2. 6tisch security conf call schedule moving forward [1 min]
  3. input 6tisch security to architecture draft [15 min]
    • RS to present result homework assignment of last call
  4. presentation Giuseppe Piro re MAC security [30 min]
  5. prep for IETF-92 in Dallas [10 min]
  6. AOB

Notes taker

  1. Rene Struik

Attending

  1. Michael Richardson
  2. Subir Das
  3. Tero Kivinen
  4. Giuseppe Piro
  5. Pascal Thubert
  6. Rene Struik

Action item

Minutes

  • The minutes of all previous 6TiSCH security conference calls in the time window Dec 2, 2015 till Jan 14, 2015 that had not been formally approved yet were all approved.
  • 6tisch security call schedule moving forward
  • Input 6tisch security to the architecture draft (draft-ietf-6tisch-architecture-04)
    • RS reported on the outcome of the homework assignment of the 6tisch security call of the previous week (Jan 14, 2015). He had scrutinized the three text proposals that were on the table and had reviewed those with aim of establishing which elements reflected consensus of the 6tisch security group and also suggested "consensus text" the text in the document titled "join process text - suggested text for architecture document, v2 (Rene Struik, January 21, 2015)" (available via the Google Drive link). He suggested to go over the (hopefully) consensus text, identity areas where this could be improved on the call, and then post a revision reflecting this as input to the architecture document prior to the 6tisch call of the next day (Friday January 23, 2015, 11am EST). Further comments, if any, could then be made as part of the review process of the architecture doc, rather than rehashing this more now, thus allowing Pascal Thubert to move forward with the architecture document and the 6tisch security group to focus on drilling down on more detail of the join protocol itself.
    • MR suggested he was happy with this process.
    • RS briefly went over the document, identifying some feedback received from Subir Das and Yoshi Ohba by email. He also highlighted that he had incorporated the suggestion by MR on the previous call to cross-reference some actual protocols that could be considered. A brief discussion ensued.
    • PTh suggested that it would be good to add some language to the effect that the actual decision of the joining node to become part of the network may depend on authorization of the network itself. It was decided to leave out further minutiae, such as "authorization of the root of the RPL network", etc., so as to focus on the join process itself, without adding too much routing protocol baggage for now. RS suggested that this would also avoid issues that could arise in case distributed JCE's would be considered, which would not correspond to a single, fixed node. SD suggested to swap the order in which the join protocol phases and the device roles were presented in the text. He further on noted that some of the terminology re joining node, join assistant, and JCE was not entirely in with what was depicted in Fig. 1. Finally, he suggested a few small edits, such as clarifying that a "one-hop neighbor" would be one "radio hop" away and not one IP hop, etc.
    • RS agreed to try and incorporate this feedback and post a revised text document, aimed to be ready for inclusion with the architecture document. {Everybody hereby earned drink credits for reaching this mile stone and getting this topic off our chest (violins, harps, and trumpet sounds could be heard on the background)...!}
  • Presentation Giuseppe Piro re MAC security

    • GP gave a presentation on some issues with 802.15.4-2011 security in the context of the join protocol (see document "l2-sec-issues-join - v2 (Giuseppe Piro, January 22, 2015), available via Google Drive link). The context (Slide #7) was that of a joining node that tries to become part of a fully secure network (i.e., the join assistant and the path towards the JCE is secured). The main problem identified was that, in 802.15.4-2011, it is not possible to mix secured and unsecured traffic (due to some details in the incoming frame security procedure (clause 7.2.3, Step f)). GP described a potential work-around, where one would install a random key (termed "fake_l2"key" on Slide #11), which only purpose was to jump the specification hurdle (so, it would never be reallly used). He also described how one could end up in the exempt status stage (by constructing a device descriptor for the joining node on the fly and setting the exempt flag). After the presentation, a brief discussion followed.
    • TK suggested that mixing of secured and unsecured traffic was possible, since "nobody would implement Step f) if one had an incoming frame without security". RS noted that GP's presentation assumed an implementation compliant with the 802.15.4-2011 specification, not one that deviated from this. TK suggested that the work-around in the presentation would fail, since it relied on KeyIDMode 0x00, which he thought would be undefined. Since the conference call was living on borrowed time (65 minutes into the call), there was no time to verify this claim on-the-fly.
    • Upon TK mentioning that the draft 802.15.4 revision text on security should be used, RS asked whether this draft was available to the 6tisch audience. TK mentioned that he would send a request to Bob Heile (Chair of IEEE 802.15) to request drafts (normally only available to 802.15 voters) to be made available to interested 6tisch stakeholders.
  • [call concluded at 2.15pm EST]

Updated