Clone wiki

meetings / 140414_webex_security

Minutes Webex 14 April 2014, 6TiSCH Security

Taking notes (using Etherpad)

  1. Pascal Thubert
  2. Thomas Watteyne

Present (alphabetically)

  1. Giuseppe Piro
  2. Hank Mauldin
  3. Jonathan Simon
  4. Michael Behringer
  5. Michael Richardson
  6. Nancy Cam-Winget
  7. Pascal Thubert
  8. Pat Kinney
  9. Subir Das
  10. Thomas Watteyne
  11. Tom Phinney
  12. Yoshihiro Ohba



  1. review of current discussion.
  2. re-state assumptions / conclusions
  3. consider non-PCE case
  4. re-state what we want, rank these.


  • [07.03] Meeting starts
  • [07.04] Michael R. introduces agenda.
    • Michael has asked Pascal to gave details on non-PCE use case. Assumptions? What are we looking for? Compromises?
    • Michael calls for approval of the agenda.

      No issues raised on the call. Agenda approved.

  • [07.06] review of current discussion.
    • 2 proposals on the table:
      • ZigBee IP-link (EAP-TLS)
      • WirelessHART-like.
    • In both cases, we have to deal with join.
    • How can we make the process touch-less? Plugged in from the factory without having to configure; certificates in place.
    • We are far from agreement about the right way
    • [Pascal] Even if we decided something as a group, we need to bring it to the WG. Suggests not to have too many discussions between 2 options in DT, but rather take proposals WG.
    • [Michael R.] strongly agree, we need everyone to really understand to come to consensus.
    • [Thomas] previous contents of Etherpad was cleaned up and published to ML
    • [Michael R.] ACK, thank you.
    • [Michael R.] Let's agree on assumptions
    • We want to have touch-less configuration. Any disagreement from call?

      No disagreement from the call.

    • Do it with certificates? and some asymmetric cryptography, is that too much for hardware?
    • [Subir] Does not mean touchless is not the only way of deploying, right? How is information input at manufacturer?
    • [Michael R.] What manufacturer does is out of scope. If can leverage touch-less nature, great, but out of scope
    • [M. Behringer] We do not assume the factory to do device-level configuration
    • [Michael R.] Do you mean different loads for each device?
    • [M. Behringer] Yes
    • [Michael R.] IEEE802.1AR assumption, private key need to be install. IEEE802.1AR has a private key that is securely installed or generated on a per-device basis.
    • [Subir] Device and customer-specific (domain) is not expected from manufacturer.
    • [M. Behringer] means device and customer specific pre-config. Assume not done in factory. 1AR assumed.
    • [Nancy] 802.1AR is more device, understanding what we want to achieve. Presumption that service provider that would provision certificates (e.g. service providers for phones), i.e. trust anchor, potentially local certificates, something to allow certificates on-board, i.e. "zero touch"
    • [Michael R.] Michael's B autonomic doc and IEEE802.1AR indicate the vendor is going to issue the service provider with a certificate that says device belongs to you. service provider takes the mote and enrolls in a touch-less way. They may have a process to replace the trust anchor, but that is out of scope.
    • [Nancy] Does that have to be over the air?
    • [Michael R.] Assumption is that mechanisms can be used over the air. If more reliable over JTAG, that's fine.
    • [Nancy] OK
    • [Michael R.] we will not standardize how to do that. Intention is that manufacturer could ship devices directly to customer and that service provider may have to receive a set of certificates. The end customer may have contracted to an service provider that is continuously involved in the service.
    • [Jonathan] I do recall people's desire for allowing for pre-shared key.
    • [Jonathan] We need to be careful we are defining mechanism for high end and stay away if we can from system-level policy on how they are used. We should avoid discussion on 'the right way' of using certificates.
    • [Michael R.] we had one e-mail suggesting that pre-shared keys should be available. We cannot make a chain of pre-shared keys. It is not possible to have a multi-party trust 3-way trust based on pre-sharded key. Re-keying is an issue e.g. if device further resold, or factory is resold. or customer switches service provider. Cannot go back to the initial key that was already leaked to another party.
    • [Jonathan] Slightly disagree, though overall point is valid. Access Control Lists (ACLs) can prevent devices from joining, though does not prevent join starvation.
    • [M. Behringer] Do we have a clear understanding of how pre-shared keys would work?

      No answer on the call

    • [Michael R.] Suggest that pre-shared keys are out of scope for release 1. If someone has a use-case and a proposal on how that would work, that person should come to us and explain.
    • [M. Behringer] for the certificate-based approach, at least we have a proposal. Let us see how low we can go with that.
    • [Michael R.] Support of pre-shared key should not be a MUST, but if it is supported, that's fine.
    • [Michael R.] Does this amount to "pre-shared key is a MAY", and "certificates are SHOULD or MUST"? We are not going to rule out protocol which supports pre-shared keys.
    • [Jonathan] Agreed for prerequisite for someone to talk about pre-shared key.
    • [Michael R.] Some Kerberos versions might work with pre-shared key, but needs high availability of vendor. We might indicate that vendor is not per-se online.
    • [Pascal] we need to have an explicit sentence
    • [Michael R.] I propose:
      • "The solution does not need to support pre-shared keys, but a solution that does support pre-shared keys will not be dis-regarded"
      • that is, pre-shared keys is a "MAY", Asymmetric methods are a MUST / SHOULD.
    • [Michael R.] let's draft sentence 2 to identify who is who in the process.
      • Vendor: builds the motes. Having vendor in the join flow adds value.
      • Service Provider: operates the motes
      • Customer: owns the motes.
    • [Michael R.] what we said is that during the provisioning, vendor is not required to be online. OK?

      1-2 OKs from call.

    • [Michael R.] Assumption is that we have equipment in the field for 20-30 year, and different set of vendors might be different.
    • [Michael R.] proposed summary:
      • "The vendor should not be required to be online during provisioning (i.e. join time)"
    • SD: what does "online" mean?
    • [Michael R.] For example, able to respond to OCSP (Online Certificate Status Protocol), a protocol to verify a certificate is valid. Other way is a certificate revocation list. There might be a mechanism to go back to the vendor to get token. we don't want "vendor online" to be a requirement.
    • [Michael R.] other statements: "a 1AR certificates should be present in the device". Does 1AR support SIM-type mechanisms?
    • [M. Behringer] We don't want to prevent a vendor from participating in the join process. If vendor can be online, might be better.
    • [Michael R.] Vendor not forbidden to be online, just forbidden to be required.
    • [Michael R.] Vendor being online as might add value to technical solution
    • [Michael R.] Thinking about situation about provisioning new power station, until power comes on, no notion of "online".
    • [M. Behringer] In autonomics, both business models exist and we have them in autonomic networks but without the vendor it is weaker.
    • [Michael R.] Any other assumptions?
    • [Pascal] let's make sure people are on Etherpad
    • [Michael R.] that's why insisted on people being on Etherpad
  • [07.42] consider non-PCE case
    • [Michael R.] Pascal, can you give a summary of non-PCE case?
    • [Pascal] Need for 6top to communicate with parent/children.
    • [Pascal] Exchange between RPL parent and child from which rest of network depends, e.g. allocation of timeslots.
    • [Pascal] Other example is time sync, i.e. attacker introduces time drift. Affects time in the device. Can read information inside timeslot database. We are looking at CoAP exchanges between parent and child.
    • [Michael R.] just look, or also modify schedule?>
    • [Pascal] both r/w
    • [Michael R.] Concern not about "read", since typically not a security concern.
    • [Pascal] Just to validate that you are in sync, you need to read.
    • [Pascal] write capability is there: parent is in charge of slots in both directions.
    • [Michael R.] What other support for authorization
    • [Michael R.] If PCE, can assume security manager. How much other infrastructure can a mote get to?
    • [Pascal] You have a root. If non-storing, root of PCE is more powerful (e.g. does source routing, and injecting time). You could push more to that box.
    • [Michael R.] Do we agree that what we have there is a 6LBR which is the RPL root, which has more power.

      Thomas agrees

    • [Michael R.] Is 6top interaction between parent/child restricted to the strict RPL children?
    • [Pascal] If we look at flow, we have not yet the way we will do track setup (GMPLS like suite of timeslots). If might be decided by the PCE, offloaded to devices to manage bundle. If offloaded to devices, exact cells could be negotiated between parent and children.
    • [Michael R.] So even in PCE, there can be neighbor to neighbor negotiation?
    • [Pascal] Not agreed yet in WG. We would have to have same relationship with parent as we have with PCE
    • [Michael R.] For example, child node A hears two parents B and C. Picks B to join. Would it have communicate at any point that it can also hear parent C. Allows you to go through C in case.
    • [Pascal] Would not preclude use of that model.
    • [Michael R.] Seems that we have a problem where it is very hard to prove 2 nodes are radio-adjacent. Very easy for attacker to break this. How strong can assumption be some node is parent. Is the set of nodes can are allowed a child's timeslots. We could secure something in RPL to secure parent-child relationship.
    • [Pascal] Don't see why non-parent neighbor will have to write into node.
    • [Pascal] Multicast DAO. We need to verify that we cam live without it.
    • [Michael R.] If we can restrict it to RPL parent, we can make security easier. We could have security with parents.
    • [Pascal] Let's keep in mind multi-cast DAO.
    • [Pascal] We have an item in charter to validate root of network. Recursively, can related to parent.
    • [Michael R.] If you connect L2 and L3 security, you can have a better solution.
    • [Thomas] What I propose is to go to the 6top group and ask for statement on whether a neighor (not parent) will ever have to access the node's 6top interface.
    • [Michael R.] PCE could make tracks the way it wants.
    • [Pascal] We are providing security for parent/child relationship, some other entity has to create trust relationship if not parent/child.
    • [Pascal] e.g. PCE which would set up track
    • [Michael R.] why?
    • [Thomas] Multiple example, including OTF.
  • [08.04] re-state what we want, rank these.
    > [Michael R.] Out of time, moved to next call.
  • [08.05] AOB
    • [Michael R.] Any other business

      No other business raised.

    • Next call will be in 2 weeks

      04/28/2014, 7-8am PDT

  • [08.06] meeting ends