Minutes Webex 02 November 2014, 6TiSCH Security Task Force

Two security meetings were held that day. These minutes refer to the first one.

Agenda

9-10am EST

0) Agenda bashing

1) Join protocol details
    a) desired properties
    b) realizable properties
2) Next steps:
    a) consensus on 1#a and 1#b
    b) form tiger team to work out details
        - project phases
        - communication of sub-results
    c) what to squeeze into architecture draft, etc.

Material

• slides discussed (and referenced in minutes):
  • https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing
  • (SAME) https://bitbucket.org/6tisch/meetings/src/master/141202_webex_security/141202_webex_security.pptx
• Recording: https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing

Attendance

• MR: Michael Richardson
• YO: Yoshi Ohba
• SD: Subir Das
• GP: Giuseppe Piro
• RS: Rene Struik

Minutes

Agenda

The suggested agenda was approved.

Join process - desirable vs. realizable properties

• RS went over the desirable properties of the join process (Slide 6).
• MR raised point that privacy of the device identity of the joining node might not be required.
• SD suggested that it is fine to include privacy in list of "desiderata"; evaluation metrics might consider these in "grey tones" vs. as "black and white" requirement.
• RS suggested that merit of privacy might depend on deployment scenario, but is on the radar in lots of IETF groups (in terms of traceability/tracking); if privacy can be easily offered as additional feature, this would be a plus. After asking, there was no further discussion on properties listed.

Join process - MAC behavior

• RS went over some MAC security aspects of the 802.15.4-2011 and 802.15.4e-2012 specifications (Slides 19-22). The main premise here was that a recipient device that expects secured traffic, will reject all incoming unsecured traffic, unless this originates from a device with so-called "exempt status". This "exempt status" construct allows receipt of incoming unsecured data frames from a joining node that does not have network-specific keying material yet.
• How to switch on/off this "exempt status" parameter was also discussed (see Slide 20).
• Furthermore, there was some discussion on how this compares to the use of so-called "default keys" (aka "fake" keys) (see also Slide 22).
• RS also discussed incoming processing of secured beacon frames (Slide 20), where a device without proper keying material can still extract visible portions of a secured beacon frame, even though it cannot rely on this. This feature is already supported in the 802.15.4-2006 spec as part of the "active scan" specification. {NOTE added (after the call): still to be checked whether this feature was not modified in the 802.15.4-2011 spec or with 802.15.4e-2012}.
• GP mentioned that 802.15.4 does not allow the use of the default key.
• SD suggested that an important point in not using default keys is that all incoming processing with keys will be treated transparently, irrespective of exceptions.
• RS explained that even if default keys were to be used, this would mess up local security state (e.g., frame counters), which is not the case if one would send unsecured traffic and use the "exempt status" construct instead.
• SD summarized that using unsecured frames, rather than "fake" security with "default keys", should be adopted, which was consensus on the call.
• GP came back to the "exempt flag" topic and suggested that details hereof are in the "device descriptor lookup table".
• RS suggested that we all have a closer look at specification details, so that switching this feature on/off could be easily codified for 6TiSCH use.

Join process - non-MAC behavior

• Given remaining time on the call would not allow full discussion of non-MAC aspects (Slides 23-25) and given that MR had to drop off the call, it was decided to revisit those topics at the next conf call.

AOB Conf call scheduling

• SD suggested he was confused about having two call times in email traffic (one at 9am EST and one at 11am EST) and suggested that other groups, such as, e.g., IEEE, often use cyclic schedule, so as to accommodate participants from around the world and who may be at widely different time zones.
• RS volunteered to look into this topic and obtain feedback on such a schedule.