Subject: [6tisch] Minutes security discussion 24 March 2014

From: Thomas Watteyne <[email-masked]>
Date: Thu, 27 Mar 2014 22:19:11 -0700

All,

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

Please fix anything we might have missed directly in the e-mail and reply.

Thomas

----

Minutes Webex 24 March 2014, 6TiSCH Security Taking notes *(using Etherpad)*

   - Thomas Watteyne
   - Pascal Thubert
   - Michael Richardson

Present *(alphabetically)*

   - Giuseppe Piro
   - Jonathan Simon
   - Michael Richardson
   - Pascal Thubert
   - Paul Duffy
   - René Struik
   - Subir Das
   - Thomas Watteyne
   - Tom Phinney
   - Yoshihiro Ohba

Recording

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

Minutes

   - *[07.12]* *Michael* introduces agenda. Indicates note well, that
   meeting is recorded, minutes taken, presence logged. Makes sure all on
   Etherpad.
   - Pros and cons of EAP-TLS method (whether over PANA or 1X), vs.
   "separate" join network with object model with 6top protocol and data
   collection/actuation.
   - Comments on 1X from Paul Duffy. IEEE802.15.9 group is chartered to
   design something similar to 1X in IEEE802.15.4 space.
   - Rene comments about 15.9
   - 15.9 security WG from IEEE.
   - *[Rene Struik]* 15.9 effort started several years ago. This KMP group
   codifies methods to transfer key management messages.
   - *[Michael Richardson]* Functionally equivalent to PANA
   - *[Rene Struik]* Any technical work? Not equivalent to PANA.
   - [??] PANA can carry 1X-type messages over L3
   - *[Subir Das]* Understanding is that 15.9 is not chartered to design
   mechanism similar to PANA. Not sure we should call it as chartered to
   design something similar to PANA.
   - *[Michael Richardson]* discussion with Bob Moskowitz indicating 15.9
   will allow to transport PANA-like messages.
   - *[Michael Richardson]* does not matter, let's discuss at some other
   time. You have a client which wants to join; EAP-TLS, you get a network key
   through that process allowing the mote to join the network. Only reason to
   talk about 15.9 is because Paul Duffy indicated preferred 1X instead of
   PANA.
   - *Michael* updates list of pro/con

   This list is indicates at the end of these minutes

   - Conceivably TLS and DTLS can share a lot of code though they are
   different services
   - *[Rene Struik]* Technical argument for preferring 1X?
   - *[Michael Richardson]* pre-existence of deployments/customers.
   Preference.
   - *[Pascal Thubert]* we want to understand what properties we want to
   get and the cost for getting there, 1x vs. PANA is not the question for now
   - *[Michael Richardson]* you have to have EAP and TLS code in mote
   - *[Subir Das]* are we assuming that mote will run CoAP interface?
   - *[Michael Richardson]* yes, at least because 6top interface on top of
   CoAP
   - *[Subir Das]* if runs CoAP, will have DTLS by default?
   - *[Michael Richardson]* will assume runs CoAP for sensors/actuators.
   - *[Jonathan Simon]* sounds reasonable. If CoAP is mechanisms that
   devices use for data and management, than joining model which stays close
   to that is a good idea. Simple solutions that don't have a lot of extra
   layer or parallel technologies is better.
   - *[Michael Richardson]* have written down as PRO. Anybody has
   recommendation for 1X/PANA method?

   No answer.

   - *[Michael Richardson]* ZigBeeIP has been shipping devices with the
   PANA/1X approach
   - *[Michael Richardson]* once you get to authorization server, EAP-TLS
   is used, regardless of whether you come in through PANA or 1X. Same thing.
   - *[Subir Das]* this framework does allow for centralized/distributed
   case. ZigBeeIP has some relay functionality to reach authentication server
   if not a single hop away
   - *[Michael Richardson]* proxy uses PANA to contact authorization
   server. The adjacent node relays the information through the mesh to the
   authentication server. At that point, it's PANA. With 1X, something else?
   Probably radius or something else.
   - *[Subir Das]* normally done by radius in WiFi case
   - *[Michael Richardson]* yes, but single hop and not thousands of
   authenticators talking to radius server.
   - *[Paul Duffy]* couple of points:
      - PANA or 1X both needs to be relayed
      - PANA relaying has been RFCed, not a problem.
      - From a radius/relaying standpoint, PANA and 1X are very similar.
   - *Michael* summarizes: discussion PANA/1X (EAP-TLS) solution vs. method
   with uses CoAP/DTLS and YANG model similar to WirelessHART
   - *[Michael Richardson]* EAP-TLS over something. If someone has ZigBeeIP
   authentication infrastructure for lighting, they could use it for plant.
   Same technology. Agreed that having common infrastructure is a feature?
   - *[Paul Duffy]* not a lot of ZigBeeIP deployed. Cisco not a fan of PANA
   in ZigBeeIP, but has many devices that use 1X. Cisco tries to use things
   off the shelf. 1X is smaller footprint.
   - *[Paul Duffy]* Is the CoAP/DTLS approach brand new?
   - *[Paul Duffy]* No running code for IP but WirelessHART does it that
   way just not over IP, just over layer 2.
   - *[Paul Duffy]* People inside Cisco might not like that at all because
   all the way up to L4. Minimal amount of footprint is preference.
   - *[Paul Duffy]* Minimize attack footprints by strictly L2 approach 1x.
   - *[Jonathan Simon]* L2 from 15.4 perspective?
   - *[Paul Duffy]* yes
   - *[Paul Duffy]* if solution relies on L2, L3 and L4, than most of the
   stack needs to be functioning
   - *[Michael Richardson]* about footprint: robots requires CoAP/DTLS to
   run for application
   - *[Paul Duffy]* security compromise, cannot answer directly. you would
   be making compromise.
   - *[Jonathan Simon]* if the mechanism that all are happy with to send
   data is not the same one as the one used to join network then security
   concern for join is principally for blocking denial of service. You need to
   go through those steps to send data. That looks like what we need to
   decide: DoS vs. simplifying.
   - *[Paul Duffy]* Utility answer: L2 access control is one the last
   things we'd like to remove. Immutable device identify: related to
   IEEE802.15.1AR
   - *[Michael Richardson]* Assumes 1AR can be used in all of solutions. No
   other standard solution as mature as 1AR.
   - *[Paul Duffy]* think correct, could ask authors. Involved with
   ZigBeeIP, 802.1AR, smart grid issues.
   - *[Paul Duffy]* has been implemented most in grid
   - *[Rene Struik]* question 1AR: don't understand what is so special
   about it. Just certificate?
   - *[Paul Duffy]* set of guidelines for strong device identity
   - *[Rene Struik]* but uses SHA1, which is deprecated, right? 1AR
   provides mechanism to issue certificate and find which device belongs to
   which entity
   - *[Paul Duffy]* not just certificate method, other elements such as
   random number
   - *[Michael Richardson]* also mechanism to update and replace
   certificates to create new device IDs. Seems that are all pieces needed:
   accept mote, replace, obsolete, change ownership, etc.
   - *[Rene Struik]* we need more precision. Have no way what is being
   discussed about what matters and what is missing.
   - *[Paul Duffy]* happy to read specification different from 1AR
   - *[Michael Richardson]* question is not whether 1AR is good/bad. It
   exists. Question is: given what 1AR gives us, how can be transport the
   network claim to the mote and the authentication claim of the mote. One of
   standard protocols is PANA or 1X transport of EAP-TLS. Other mechanism is
   to use the certificates 1AR gives us directly in DTLS. In 6TiSCH, if we
   have a PCE, the PCE needs to program schedule in motes. PCE need "super
   user" access to motes, 1AR certificates provide that ownership statement.
   We need interoperability between motes and authentication servers from
   different vendors. We don't expect people to handle mote to authenticate,
   needs to be much more automated. 1AR is routinely done by companies such as
   Verizon for VoIP phones; there are products which use that.
   - *[Subir Das]* are we trying to lock down the device to a particular
   vendor?
   - *[Michael Richardson]* initially, transfer between vendor and user.
   from APIs in 1AR, once the initial owner takes ownership, possibility to
   change identity so doesn't need to talk to vendor. Allows transferring
   ownership.
   - *[Subir Das]* we could just think of it as a certificate. We should
   have different options.
   - *[Michael Richardson]* other mechanisms like transferring ownership
   can be added to talk. Crux is for mote to be able to validate certificate
   chain.
   - *[Michael Richardson]* the mote is able to validate a variety of
   certificate statements.
   - *[Paul Duffy]* about 1AR, let's not assume it's perfect. May need to
   be modified, but strong guidance to IoT space.
   - *[07.55]* *[Michael Richardson]* Let's move on. we spent lot of time
   on PANA/1AR. Round table with final comments.
      - *[Yoshihiro Ohba]* don't disagree supporting 1x but pre-shared key
      authentication should be supported as well;
      - *[Michael Richardson]* can you write as e-mail?
      - *[Tom Phinney]* nothing to add. concerned with scalability and
      replacement. But think those issues are being addressed e.g. by
René. Tend
      to agree wit the Cisco concerns about scalability.
      - *[Thomas Watteyne]* Was taking notes. Interesting discussion.
      Leaning towards side that all of our data is transported over CoAP. Data
      transported over CoAP, also CoAP might be used by the PCE. CoAP is not
      optional, has to be there and secured. Reusing it for join reduces the
      footprint in the motes.
      - *[Subir Das]* nothing to add
      - *[René Struik]* look at flexible authentication and device
      replacement
      - *[Jonathan Simon]* Scalability and not having protocols that
      require 10 passes to just get ready to send data
      - *[Paul Duffy]* That is a concern, indeed.
      - *[Pascal Thubert]* Concerned that we are looking at solutions, but
      we haven't documented requirement space. Not clear we cover all
      requirements. Happy to keep in mind Michael B. Anything else we
are missing?
   - *[Michael Richardson]* we are NOT having a call next week, we resume
   on 4/7. Please email to the 6TiSCH list and send a summary

Notes

These notes were taken by Michael Richardson during the call

   - 6TISCH SECURITY ARCHITECTURE
      - assumption: mote runs CoAP and DTLS already for 6top, and also for
      actual sensors/actuators.
      - 802.1AR, "immutable device identity" is origin of trust
      relationship (almost ubiquitous in AMI GRID)
   - 1X/PANA METHOD
      - PRO:
         - specified by ZigBee IP
         - common authorization infrastructure with ZigBee IP.
         - minimizes attack footprint
         - deals with DoS on network traffic much earlier
      - CON:
         - requires EAP, TLS
         - code is used only once to get on the network
      - WIRELESSHART/JOIN NETWORK METHOD (whether ND ARO or RPL DIO)
      - PRO:
         - reuses existing CoAP and DTLS code base.
      - CON:
         - requires layer-3/layer-4 to be operating.