All,

You will find the minutes of the last security discussion at
https://bitbucket.org/6tisch/meetings/wiki/140407_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 7 April 2014, 6TiSCH Security Taking notes *(using Etherpad)*

   - Thomas Watteyne
   - Michael Richardson

Present *(alphabetically)*

   1. Giuseppe Piro
   2. Hank Mauldin
   3. Jonathan Simon
   4. Maik Seewald
   5. Michael Behringer
   6. Michael Richardson
   7. Nancy Cam-Winget
   8. Rene Struik
   9. Subir Das
   10. Thomas Watteyne
   11. Tom Phinney

Recording

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

Minutes

   - *[07.05]* round-table
   - *[07.09]* Michael R. introduces goal of call.
      - last call was about IEEE802.1X, EAP-TLS, including discussion on 1X
      vs PANA
      - this call, let's get away from this a little bit, and explore
      advantages about the WirelessHART-like approach
      - Jonathan posted an e-mail about the amount of traffic needed for
      EAP-TLS method
      - Let's have Jonathan comment on this, and discuss pros/cons of the
      WirelessHART approach
   - *[Rene]* before Jonathan starts, want to point out that these
   calculation have nothing to do with the WirelessHART approach
   - *[Jonathan]* sent e-mail with back-of-envelope calculation using
   today's 6TiSCH base configuration [minimal draft]. Because of its shared
   nature, has a capacity of 1-2 frames per second for a node to send/receive
   messages. Calculation of how many L2 frames need to be exchanged to
   complete EAP-TLS. Confused about term "required", not totally sure about
   follow-up e-mails.

   Jonathan's email archived at
   http://mailarchive.ietf.org/arch/msg/6tisch-security/RmQwT85xM1SlgIj4CVxU0KVVzGQ

   - *[Michael R.]* important to understand that we can set new
   requirements as profiles. We can omit/add things. People tolerant of these
   changes for IoT space, although we would have to run it by a different WGs.
   - *[Jonathan]* in the security world, usual that crypto suites are
   changed. Agreed that not a big deal, but wanted to know if a problem.
   Assuming an X.509 certificates, 15-20 L2 frames going back and forth (half
   in each direction) in order to get device to send beacons. Seems like a lot.
   - *[Michael R.]* other interesting part is the number of packets per
   second we have for new nodes to join.
   - *[Jonathan]* that's what the minimal draft specifies. Contention-based
   medium, slotted Aloha style, you will only have 1/3 of the number of cells
   available to get usable bandwidth. This restriction only when multiple
   devices are joining.
   - *[Michael R.]* just 1.5 slots per slotframe?
   - *[Jonathan]* yes, about 36% of BW, slotted Aloha.
   - *[Michael R.]* based on calculation, between 10-15s for each node to
   join?
   - *[Jonathan]* yes.
   - *[Thomas]* Minimal draft also recommends 15ms timeslot, so an extra
   50% needs to be added to calculations
   - *[Jonathan]* calculation indicates a 30min join time for 10-hop
   100-node network
   - *[Michael R.]* calculation assumes 300 bytes for certificate
   - *[Jonathan]* yes
   - *[Michael R.]* it is possible that the authenticator already has the
   6LNs certificates, and can be referred to it by hash (i.e. 16B hash instead
   of 300B certificate)
   - *[Michael R.]* additional problem is that we may not be talking about
   that a single certificate, but maybe a certificate chain. The node has only
   a vendor certificate as anchor, needs a chain of certificates to believe
   that the controller is trusted.
   - *[Jonathan]* certainly agree that if you can store certificate, you
   can send a hash. Rene in early messages made a good point that we want to
   have touch-less configuration. So pre-provisioning certificates on devices
   goes against that model. There is a system-level costs associated with
   pre-provisioning certificates in devices. Has sent e-mail with proposal to
   compact X.509 certificates: if you elide fields, you can probably get down
   to 1-2 L2 frames rather than at least 3 frames in each direction.
   - *[Michael R.]* if we devised a mechanism whereby a joining node should
   only communicate with neighbor, would this allow more parallel join?
   - *[Jonathan]* Assumed node was joining though peer. Problem with that
   is that, if high-level policy is to not let this join, peer can forward
   network-level credentials. Not clear that we can always get around DoS by
   pushing to L2.
   - *[Thomas]* Michael, please clarify last statement.
   - *[Michael R.]* two neighbors could authenticate each other without
   having to use BW further up tree; this also implies locality of joining.
   - *[Jonathan]* Exactly what calculation meant. no additional frames sent
   to central authority. If thousands of nodes, doesn't matter how much BW you
   have, it will take time.
   - *[Michael R.]* if communication needed up the tree, you need to
   provision that BW using 6TiSCH. We could reserve that BW, then remove it
   later on.
   - *[Jonathan]* assume any reasonable system would do.
   - *[Michael R.]* can we assume more BW in core of the network? Is this
   reasonable?
   - *[Jonathan]* This would be a design trade-off between many elements.
   More like individual system design trade-off.
   - *[Michael R.]* How much of the rest of the slots are available? I
   assume more than 90%?
   - *[Jonathan]* yes
   - *[Subir]* clarifying, if only 1-hop peer, how would we be running DTLS
   session?
   - *[Jonathan]* Assumption is that a node needs/gets authentication. This
   mechanism just to get node on network, you will need same mechanism to send
   data.
   - *[Jonathan]* assumption: server may be multiple hops away, we are
   separating the joining problem from steady-state problems. What are we
   trying to solve to get device onto the network> Simply able to send data to
   PCE, or trying to get it to a point where it has a DTLS session to its data
   sink. We haven't defined what we mean by joining. I have assumed: what it
   would take for a device to from knowing nothing about the network to
   sending beacons of its own, independent from being able to send data.
   - *[Subir]* in that sense, should we think about, if a node can connect
   to a peer node which is already part of the network. If new node can
   authenticate with old node, could be part of it?
   - *[Jonathan]* possibility, but would not necessarily cut down on the
   number of packets to be sent. If we assume network has been provisioned
   correctly, it's the number of frames that are generated matter more than
   whether those have to go multiple hops.
   - *[Jonathan]* in WirelessHART, all frames sent to centralized manager
   to set up a transport session. Primary different is that the number of
   frames is very small (1 frame up, 1 frame down) to get transport session
   started.
   - *[Rene]* Suppose we are able to bring down the number of join messages
   to 4 (2 up, 2 down), why would that problem be so different from
   operational use. I don't understand why security would be such a big
   factor. If we have problems at this level, maybe TSCH-based communication
   is the issue?
   - *[Jonathan]* The context is that there was a discussion about
   segregating joining traffic from data traffic, therefore limit possibility
   of DoS attacks. Agree that, if you're willing to mingle flows, joining
   packets form just another piece of traffic, and you can set up the network
   accordingly.
   - *[Michael R.]* if you set up network to support 10 queries per second,
   security operation would be 11th query? Would be very nice, but because
   these nodes haven't been authenticated, we cannot open dedicated cell, we
   need to protect that bandwidth very clearly. We have very little excess
   bandwidth.
   - *[Hank]* Endpoints will not be powered up all the time.
   - *[Michael R.]* Assumption is that we are provisioning L2 network key,
   we have been discussing protocols to provision this key.
   - *[Hank]* Join is to help nodes get this key? Confused since assumes
   motes would know the key a priori. If they don't know the universal key,
   any device would have to know the list of device certificates from that
   domain. Would need to be pre-configure; wouldn't that be more complex?
   - *[Michael R.]* we have made an assumption: we believe we will use the
   802.1AR certificate process. A device is provisioned with certificate and
   private key. A chain of certificates so network can authenticate itself to
   the device, and vice-versa.
   - *[Rene]* Maybe assumption of online certificate verification protocol
   wrong in these networks?
   - *[Michael R.]* we are not talking specifically about specific online
   certificate verification protocol. Doing 3-4 certificate verification is
   not hard for IoT device.
   - *[Rene]* Main problem has to do with communication flows and how many
   time slots we have. No problem if unlimited bandwidth. In WirelessHART, we
   require one communication up, one down. We can do authentication step,
   authorization, then manage schedule. It should be possible to keep all
   flows local, and have proxy send data once node is part of networks. Would
   that solve problem raised by Jonathan?
   - *[Michael R.]* process described is not dissimilar to EAP-TLS.
   Question: in WirelessHART messages, any asymmetric operation in which a
   node validates certificate, or based entirely on pre-provisioning.
   - *[Jonathan]* WirelessHART has pre-shared key, no validation based on
   certificates.
   - *[Michael R.]* So only symmetric encryption with a number of
   pre-shared keys.
   - *[Jonathan]* correct.
   - *[Michael R.]* Thanks, wanted to make that very clear to all.
   - *[Michael R.]* This eliminates the problem of authenticating nodes.
   This means that when you order nodes from a manufacturer, someone has to
   pre-provision those keys.
   - *[Jonathan]* Can only speak to our product. Operator (not necessarily
   manufacturer) sets security material through some API. This is something
   that could be done at factory or elsewhere. HART provides commands to
   specify keying material at run-time.
   - *[Michael R.]* Key point is that device has pre-existing relationship
   with factory.
   - *[Jonathan]* Yes, or configured on-site.
   - *[Michael R.]* So a technician needs some equipment?
   - *[Jonathan]* Can be done in-band, or through configuration using
   hand-held device.
   - *[07.50]* *[Michael R.]* Would you to spend last 10min
   self-criticizing this mechanism. What's wrong with WirelessHART model?
   - *[Jonathan]* limitation is that you cannot cleanly separate joining
   flows from steady-state flows in the netwokr. You can take a device from a
   box, which will disrupt data traffic. In a typical HART network, amount of
   bandiwdth for joining nodes is really low. Another limitation is that there
   is no external validation of the manager's ID, other than the fact that it
   possesses the right key.
   - *[Michael B.]* Quick question on thread model: are we worried about a
   device on factory floor which floods network, i.e. DoS? Is this specific to
   security?
   - *[Jonathan]* it's one thread.
   - *[Thomas]* 6TiSCH provides mechanism for flow isolation through the
   concept of track IDs.
   - *[Rene]* Would this be equivalent to "coloring" cells?
   - *[Thomas]* Yes.
   - *[Michael R.]* A controller can take over part of the network. We
   don't think that the model of symmetric key provisioning is going to work
   in touch-less networks.
   - *[Jonathan]* Agree.
   - *[Thomas]* Agree.
   - *[Michael R.]* These calls are very useful. What I'm trying to do is
   get everyone on same page. We're working on getting to understand different
   assumptions.
   - *[Michael R.]* Is capturing discussion in draft, which publish soon.

   Action item: *Michael R.* to publish security draft by Thursday April 10.

   - *[Thomas]* When is next call.
   - *[Michael R.]* next call is next Monday 04/14.
   - *[08.02]* meeting ends