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

Wiki

Clone wiki

meetings / 140324_webex_security

View History

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

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.

Updated