1. 6tisch Avatar 6tisch
  2. admin
  3. meetings

Wiki

Clone wiki

meetings / 140210_webex_security

View History

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

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

Updated