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

Wiki

Clone wiki

meetings / 140616_webex_security

View History

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

Slides

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]
  • [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.

Updated