Subject: [6tisch] Recording security webex 10 February 2014

From: Thomas Watteyne <[email-masked]>
Date: Thu, 13 Feb 2014 10:17:15 -0800

All,

You find the attendance, recording and minutes of this week's security
webex at:
https://bitbucket.org/6tisch/meetings/wiki/140210_webex_security

For your convenience, I also copy-pasted them below.

Thomas

---

 Minutes Webex 10 February 2014, 6TiSCH Security Task Force

Note: timestamps in PST.
Taking notes *(using Etherpad)*

   1. Thomas Watteyne
   2. Michael Richardson
   3. Pascal Thubert

Present *(alphabetically)*

   1. Maik Seewald
   2. Michael Behringer
   3. Michael Richardson
   4. Pascal Thubert
   5. Paul Duffy
   6. Rene Struik
   7. Subir Das
   8. Thomas Watteyne
   9. Tom Phinney

Recording

   - Webex recording (audio+slides,streaming)
   -
   https://cisco.webex.com/ciscosales/lsr.php?RCID=f126e930ee2e415eb9cb2d2ddc9f99b2
    *[56min]*

Minutes

   - *[07.02]* Meeting starts
   - *[07.02]*
      - *[Pascal]* 6TiSCH security architecture draft contains state of the
      art. Would like input from other people. Subir? Maybe put up maybe
      incorrect information, to have people react.
      - *[Pascal]* Architecture document might be different from overview
      draft.
      - *[Michael R.]* We could write one document, then cut into two
      documents when merging with 6TiSCH architecture.
      - *[Pascal]* 2 documents?
      - *[Michael R.]* Don't know what the contents would be for an
      overview draft, except for a couple of of paragraphs.
      - *[Pascal]* Jonathan is invited to contribute to document about
      state of the art of WirelessHART
      - *[Michael R.]* Would security work belong in 6TiSCH TSCH document?
      - *[Pascal]* Maybe a different document?
      - *[Michael R.]* Will continue to write up in a single document, we
      can split if needed later on.
   - *[07.10]*
      - *[Rene]* We've had several discussions but need to draw some
      conclusions. Last week: hard to re-extract what the security properties
      are. Look at what properties are provided by protocols. Useful to examine
      what can be implemented in IEEE802.15.4e TSCH. Does the security
      relationship favor centralized and/or allow separation betwen
      Authentication and Authorization?
      - *[Rene]* Question: can we implement join protocol messages in
      IEEE802.15.4e.
      - *[Rene]* One of the problems with "IETF alphabet soup" it that it
      might be unclear what the underlying technology allow; e.g. does security
      favor distributed operation, or separate authentication from
authorization?
      Ties into use case scenarios. We should get to there.
      - *[Rene]* Goes back to discussion with Michal Behringer on
      autonomous operation. We just want to identify topic areas and
see what the
      next steps should be.
      - *[Rene]* Assuming a new node wants to join, does MAC level
      facilitate that?
      - *[Rene]* Security in 15.4 and 15.4e is based on what is in
      802.15.4-2006, section 7.4.
      - *[Rene]* Walking through outgoing frame security procedure from
      15.4-2006.
      - *[Michael B.]* Question: does that assume that there is already a
      pre-shared key?
      - *[Rene]* 15.4 does not discuss key management. Reason why bring
      this up: 15.4 does not talk about key establishment.
      - *[Michael B.]* As long as no key material, security level to 0.
      - *[Rene]* Let's walk through security procedure, then we can look at
      what's on the receiving side. On the RX side, is the BBR able to process
      incoming message from joining node?
      - *[Rene]* Specs are hard to read, but let's walk to it from joining
      node perspective.
      - *[Rene]* Assuming joining node from Michael B. autonomous case.
      - *[Rene]* First packet is send unsecurily. When sending outgoing
      frame, goes through steps including CCA, then TX frame. Happens
after step
      i from section 7.2.1 in 15.4-2011.
      - *[Rene]* Now on receiving side. First step is checking whether RX
      frame passes CRC. Then checked whether satisfies security. CRC checks are
      only communication checks. No error correction at the bit level,
so if CRC
      fails, no way to correct it. Let's assume most simple case.
      - *[Rene]* RX side. First step is try and detect whether was secure.
      Header contains some admin bits, indicating how it is secured, the key
      used, etc. The basic level is the "secure bit". BBR sees that
bit set to 0.
      - *[Michael B.]* We can set the security bit to 0 or 1. So we can map
      another security protocol on that by choosing whether to set the security
      bit or not.
      - *[Rene]* MCPS-DATA.request primitive contains a parameter which
      sets the security.
      - *[Pascal]* Where are you taking us? Goal was to tell us what
      limitations is and what we can do. Is that the goal?
      - *[Rene]* I wanted to walk through steps of how 15.4 goes from
      outgoing and incoming security frame. If the network operates in a secure
      way, we need to know what the interface is with the higher
layer; on the RX
      side, involves checking with PIB attributes from tables. We have to make
      sure that the PIB attributes can allow for processing of unsecure and
      secure frames. There is a problem that we need to be aware of.
      - *[Rene]* In MCPS-DATA.request primitive, there is a SecurityLevel,
      KeyIdMode, and other Key* parameters. Once these parameters are set, the
      15.4 layer takes care of constructing the frame itself. Security
section is
      7.2.
      - *[Rene]* Assumning I'm a node on a network and receive unsecured
      frame from my interface. Can ignore many steps of 7.2.3 because unsecured
      frame. If doesn't find description of key used to secure frame, will come
      out of incoming frame procedure with error condition. Error: we cannot
      receive unsecure frame on the RX side if the RX node is in the secure
      network.
      - *[Rene]* From policy side, if you are willing to receive an
      unsecured frame, you can open up possibility for attack. Intention of the
      spec is that, if you receive an unsecure frame from a joining node, you
      might accept it with some limitations of the transmitting
device. That is,
      if I'm already in the network, I will drop all RX packets
without security,
      except for joining nodes. Will only be done if the source device has been
      flagged as having the "joining" status.
      - *[Michael B.]* Talking about normal switches/routers, concern is
      the same. If the intention is for this device to bootstrap other devices,
      we don't have a choice. We should identify proxy nodes and set the policy
      accordingly, including some level of protection such as rate limitation,
      etc.
      - *[Rene]* Possible to device behavior, but if we want to use 15.4e
      on the MAC level, we have to implement the spec. There is a missing piece
      in 15.4-2011: an unsecure frame exchanged in secure network.
      - *[Michael B.]* We need to put a policy in place.
      - *[Michael B.]* When this was written, maybe assumed keying material
      pre-provisioned.
      - *[Rene]* Or just an error in IEEE802.15.4 network?
      - *[Michael B.]* In general, I believe we agree, it is important that
      we accept unsecure frames.
      - *[Michael B.]* If a bootstrap should be running over 15.4, then it
      is imperative that certain 15.4 frames can be transmitted
without security,
      there has to be a proxy node capable of processing a number of unsecured
      frames. There will be a few bootstrap packets, which have to be accepted;
      we need to find what the restrictions are.
      - *[Rene]* Assume frame is accepted, depending on the type of frame,
      do something different. If data frame, payload sent to higher
layer. Higher
      layer could also decide whether to forward the frame.
      - *[Micheal B.]* We need a functional diagram. If unsecure frame, we
      need to check different things, and only process packet if passes those
      checks. Typical case of transition from unsecure to secure network.
      - *[Rene]* There is something in the 15.4-2011 spec which might be
      problematic. We need to take this case into account. Question: is this a
      real 15.4 problem or not? If yes, we need to give feedback to the IEEE.
      - *[Paul]* I believe that, if there is a problem with 4e, than we
      need to work with IEEE. But strongly believe we need to support
some level
      of unsecures frames, example is .1X.
      - *[Subir]* Clarifying question about security bit in 15.4 header.
      - *[Rene]* Might be something wrong in the order of the processing
      steps.
      - *[Michael B.]* What was the assumption when 15.4 was written?
      - *[Rene]* My assumption is that we cannot know.
      - *[Paul]* We shouldn't be to hung up on the letter of the law.
      - *[Subir]* Is there a case when security bit it set to 0?
      - *[Rene]* That's one of the cases Michael B. suggested, we need to
      support unsecure frames.
      - *[Subir]* If there is a secure network, device need to join that
      network, are you not assuming that that node has to set the security bit?
      If the bit is set to zero, means the node does not want to participate in
      the secure network.
      - *[Michael R.]* In WirelessHART, you can use a join key to work
      around the problem. Jonathan said it also avoids having problems with
      "random" packet from other networks being interpreted by current network.
      - *[Subir]* Don't see why not use 15.4 spec.
      - *[Michael B.]* Will send notes to ML with ideas.
      - *[Rene]* If we use a default key like WirelessHART, we could use
      15.4.
      - *[Rene]* Action steps? We need to convince ourselves on whether
      15.4 works or not? Let's discuss on the ML.
   - *[08.06]* Meeting ends