Subject: [6tisch] Minutes security discussion 16 June 2014

From: Thomas Watteyne <[email-masked]>
Date: Wed, 18 Jun 2014 12:28:14 -0700

All,

You will find the minutes of the last security discussion at
https://bitbucket.org/6tisch/meetings/wiki/140616_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 16 June 2014, 6TiSCH Security Design Team

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

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

Present *(alphabetically)*

   1. Giuseppe Piro
   2. Jonathan Simon
   3. Maik Seewald
   4. Michael Richardson
   5. Nancy Cam-Winget
   6. Pascal Thubert
   7. Pat Kinney
   8. Rene Struik
   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=94dcaeeaca494567b83960d2d7cbad62
    *[61min]*

Slides

   - No slides shared through Webex, reusing slides from last call
   -
   https://bitbucket.org/6tisch/meetings/src/master/140609_webex_sec/140609_webex_sec.pdf

Agenda

   1. Announce ANIMA/UCAN BOF.

   http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANApprovedforIETF90

   2. work on trust/cryptographic details of Joining-Node -> PCE message.
      - does it need to be signed?
   3. 6top ideas for PCE->joining node protocol. Will this work as stock
      - CoAP/DTLS, or do we need a proxy to help us?

Minutes

   - *[07.07]* Meeting starts
   - [MCR] continue Mozilla Etherpad

   reco

   - *[Michael]*
      - let's use slides from last week
      - new BoF at IETF90: ANIMA/UCAN

      http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANApprovedforIETF90

      - Core is Michael Behringer's autonomic draft, people should be aware
      of this effort
      - Autonomic Networking Integrated Model and Approach (
      https://www.ietf.org/mailman/listinfo/anima)
      - wanted to talk about messages from slide 3
   - *[Michael]* messages 4 and 5. Need to understand properties of these
   messages. Have to either encrypt or sign by PSK. If we have private key,
   why is message 4 encrypted to PCE? Is it enough to sign by joining node?
   what's the freshness criteria?
   - *[Rene]* what is fresh?
   - *[Michael]* Message 4 could be pre-calculated by joining node long
   before.
   - *[Rene]* First message by joining node, no guarantee will be fresh.
   - *[Michael]* One of the elements of that message is neighbor info. We
   could have a nonce based on ASN.
   - *[Rene]* You cannot have any assurance about first packet. The PCE
   responds.
   - *[Michael]* There could be some freshness in it.
   - *[Michael]* Model trying to see whether possible, is where there is a
   long period of time between messages 4 or 5.
   - *[Michael]* 5 could start a CoAP/DTLS session, there is no strong
   relationship between 4 and 5.
   - *[Michael]* PCE could manage order of joining.
   - *[Michael]* If message 4 does not have to be fresh, it can be
   periodically resent until the node joins the network.
   - *[Rene]* suggesting joining node is sending
   - *[Thomas]* is there any benefits in repeating> that's wasted bandwidth.
   - *[Michael]* if we have an ACK we can avoid it
   - *[Thomas]* The proxy ACKs at L2, it is responsible for the packet
   after that.
   - *[Michael]* what if lost somewhere up?
   - *[Thomas]* can happen. There can be a very long retry timeout.
   - *[Michael]* agreed. if too many nodes are turned on, the PCE can
   manage the order and may go out to vendor and get certificate or a security
   token to complete the join process. Open loops possible, e.g. manual
   authorization by a human.
   - *[Michael]* We do not want to have to hit a button or something like
   that.
   - *[Thomas]* Strictly speaking, the joining node is able to keep sync
   while waiting for reply, keeping in sync with the proxy node and waiting
   for join response.
   - *[Michael]* Question: is there a reason for message 4 to be encrypted
   to PCE?
   - *[Thomas]* In a PSK case, encrypting msg 4 shows that the node has the
   credentials.
   - *[Michael]* Address of PCE could use built into certificate. Is this
   why encrypt to PCE?
   - *[Jonathan]* came from WirelessHART case, where confidential info is
   placed there (e.g. HART-specific configuration info). These device details
   are not publicly broadcast e.g. what kind of device/capabilities.
   - *[Michael]* is there something that would need to be kept private (in
   the future?). If we do not encrypt to PCE we do not need messages 2 and 3
   - *[Thomas]* this is used for the node to know who it is talking to.
   Else it could take a long while to figure this is the wrong network. This
   is really a caching mechanism.
   - *[Michael]* The address of the PCE may well be in the certificate as
   an attribute.
   - *[Michael]* Certificate response in step 3 cannot contain
   authentication token that allows node to know which network it joins. This
   is between messages 5 and 6 when certificate chains or authorization tokens
   arrive. The certificate response could contain much of the certificate
   chain but not all. The joining node could authenticate but figure that
   there is a relationship with vendor.
   - *[Tom]* Example: many networks in a refinery with same owner, since
   the ExxonMobil owns the whole place. This granularity has to be coming from
   a tag. Out of the box the device cannot know which part of the network it
   needs to join.
   - *[Nancy]* we want to endpoint to be provisioned with right
   certificates. In utility sector service provider (SP) may be like a PG&E,
   can be provisioning the smart meters with root certificates that indicate
   which SP network to join. Consumer is very different.
   - *[Tom]* device does not know with the granularity of which block
   inside the network. Need to provision e.g. with a link back to central
   system
   - *[Thomas]* to combine the 2, if the device joins the wrong network,
   PCE can fix that.
   - *[Tom]* can see the joining device probing, trial and error and
   blacklist networks but that places the burden on the device. The right info
   is only available in some central system.
   - *[Jonathan]* in HART it is all initiated by joining device
   - *[Tom]* has to, but must come with some ID. Device provisioning may be
   done by ExxonMobil and then put in the field with a tag name that allows to
   correlate the device with its role (e.g. street address in smart meters).
   Devices have differentiable characteristics so confidentiality of the join
   process is illusional.
   - *[Michael]* concerned about device intercepted on the way to plant.
   Are we adding some defense by having the device figure the place is correct
   or not?
   - *[Tom]* would make that an option. Large system owner would tag device
   for tracking. Need also to look at home owner. No pre-provisioning, single
   step. Enable security system to add a new device, or manually add a serial
   number.
   - *[Michael]* not chartered so mush for that in 6TiSCH, expect a network
   manager. Not to go too heavily towards home.
   - *[Jonathan]* there is an installer that at least can read a do and
   feed back a central office.
   - *[Tom]* there has to be something that binds the role with the device,
   e.g. which pipe a corrosion monitor is placed on.
   - *[Michael]* that can be done out-of-band.
   - *[Tom]* yes, there is a mechanism whereby installer says I'm adding
   that device for that function.
   - *[Thomas]* Big plant case. Out of band provisioning of some data base.
   Device starts with info about this is the network device must join. See a
   number of potential proxies. During the real handshake the networks can
   reject where it is not expected.
   - *[Michael]* could PCEs from different networks communicate to answer
   to the device which proxy it should join?
   - *[Tom]* device needs positive/negative information to rejoin faster
   and not retry the wring networks. PANID can be used.
   - *[Thomas]* How does joining node identify network?
   - *[Tom]* device knows which network sent EB.
   - *[Michael]* can be forged.
   - *[Tom]* in large companies, many businesses side-by-side interfering.
   Lots of rejections in such scenarios.
   - *[Thomas]* PANID is a great filter but not security.
   - *[Michael]* step 2 must indicate what type of certificate chain is
   expected and proxy will answer I'm ExxonMobil and that root says so.
   - *[Tom]* yes, depending on timing when the device validates the chain.
   - *[Michael]* 7/11 could have purchased the same devices so serial
   numbers are needed to validate the right device in the right network.
   - *[Jonathan]* proxy can cache some certs.