Subject: [6tisch] Minutes security discussion 14 April 2014

From: Thomas Watteyne <[email-masked]>
Date: Tue, 15 Apr 2014 10:01:47 -0700

All,

You will find the minutes of the last security discussion at
https://bitbucket.org/6tisch/meetings/wiki/140414_webex_security, also
copy-pasted below.

Please fix anything we might have missed directly in the e-mail and reply
to both 6tisch and 6tisch-security MLs.

Thomas

---

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

Recording

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

Agenda

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

Minutes

   - *[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
         - 04/07/2014:
         http://www.ietf.org/mail-archive/web/6tisch/current/msg02117.html
         - 03/24/2014:
         http://www.ietf.org/mail-archive/web/6tisch/current/msg02062.html
         - full list at
         https://bitbucket.org/6tisch/meetings/wiki/list_meetings
      - *[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