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

Wiki

Clone wiki

meetings / 140602_webex_security

View History

Minutes Webex 02 June May 2014, 6TiSCH Security Design Team

Note: timestamps in PDT.

Taking notes (using Etherpad)

  1. Thomas Watteyne
  2. Pascal Thubert

Present (alphabetically)

  1. Jonathan Simon
  2. Hank Mauldin
  3. Michael Richardson
  4. Pascal Thubert
  5. Pat Kinney
  6. Rene Struik
  7. Subir Das
  8. Thomas Watteyne
  9. Max Pritikin

Recordings

Slides

Agenda

  1. table of contents for protocol documents
  2. WirelessHART-like flow.

TOC outline

'''As outlined during the call'''

  • security requirements
    • threat model
    • implementation cost, etc. (storage of security material, computational cost)
    • denial of service and other communication impacts of security protocol mechanisms
  • protocol requirements/constraints/assumptions
    • dependencies on centralized or external functionality, inline and offline
  • time sequence diagram
  • explanation of each step
  • size of each "packet", and number of frames needed to contain it.
  • resulting security properties obtained from this process
  • deployment scenarios underlying protocol requirements
  • device identification
    • PCE/Proxy vs Node identification
    • Time source authentication / time validation
    • Note: RPL Root authentication is a chartered item
    • description of certificate contents
    • privacy aspects
  • slotframes to be used during join
    • how is this communicated in the (enhanced) beacon?
  • configuration aspects
    • allocation of slotframes after join
    • network statistics
    • neighbor reports
    • etc
  • authorization aspects + lifecycle (key management, trust management)
    • how to distinguish a proxy/PCE from an end node
    • security considerations: what prevents a node from transmitting when it is not its turn (two parts: jamming, successfully communicating outside of assigned schedule, see below)
    • can a node successfully communicate with a peer at a time when not supposed to, may be tied to link layer security, or will it be policed by receiver?
  • security architecture and fit of e.g. join protocol and provisioning into this
  • posture Maintenance (SACM related work)

Minutes

  • [07.08] [Michael] let's work on TOC first. Look at Etherpad.
    • [All] collaborate on TOC through Etherpad

      The resulting TOC is copy-pasted above

    • [Rene] let's not forget a discussion about the resulting security obtained
    • [Max] would that be the same as the regular "security considerations" section in an I-D*
    • [Rene] different, lists what security you receive
    • [Max] ok
    • [Rene] difference between security properties and requirements
    • [Michael] OK, let's add it
    • [Rene] what is the goal?
    • [Michael] goal is join protocol to have exchange of schedule, optionally involving a PCE
    • [Rene] we need a sections which highlights interaction with 4e standard.
    • [Michael] this document will become part of architecture, so probably not needed?
    • [Rene] disagree, will need to contains elements such as what we put in the EB, what cells are used during joining, etc
    • [Rene] afraid we create a protocol disconnected from MAC. We need to consider the details.
    • [Michael] if we have running code by independent people, then document is done?
    • [Subir] clarification question: what should we add to the TOC? security architecture?
    • [Rene] main concern is that we force TLS without details. We need details in a document. For example: how do you define a schedule that joining mote can talk with neighbor. Maybe not question to other, but we need that to come up with a solution. I'm fine with bullet points, but maybe we should discuss issues one-by-one.
    • [Michael] other missing pieces?
    • [Pascal] about architecture, do you want to see flows, e.g. 6LoWPAN/RPL flows? Would make easier or more complex?
    • [Max] missing point: how is the PCE domain identified. Because we have identified the question of how a joining node identifies the network
    • [Michael] also added description of exact certificate contents
    • [Max] sure
    • [Subir] uoes it make sense to add sub-model of thread model.
    • [Michael] what about under security model
    • [Subir] agree
    • [Michael] Pascal, can you comment on SACM section?
    • [Pascal] idea behind SACM is maintaining something within a device such as the level of a database, or core certificate being used, level of software. For embedded devices, time will pass and root cert will have to be update. We need to discuss the life of the device, including the maintenance that will need to be done. Nancy can help here.
    • [Michael] let's do a round table: more information to put in TOC?
    • [Michael] what about authorization aspects?
    • [Rene] outcome is that the new device gets a schedule pushed to it. During the join process, the node will use slots and frames, we need to understand which ones.
    • [Jonathan] that would be part of the EB.
    • [Max] what prevents a node from transmitting during a timeslot that's not being transmitted to them? does authorization cover that?
    • [Michael] AFAICT, there is nothing that prevents a node from transmitting whenever it wants. I can imagine someone winning a benchmark test by doing this in a bad way.
    • [Jonathan] broken down in two parts:
      • can I successfully communicate with a neighbor (the security considerations for this case are related to link-layer keying)
      • can I transmit whenever I want. The underlying 4e mechanisms assumes underlying MAC has a schedule
    • [Michael] if we have per-node link pair keying, nodes could police who they receive from
    • [Michael] lets write the policing point down
    • [Michael] anything else?

      No updates from call, [Michael] saves copy.

    • [Subir] Pascal added a points about root authentication. Should that be under device identification?
    • [Pascal] in terms of flow, it will be the same flow, will need to be merged into TOC. That is part of the charter.
    • [Pascal] suggestion about presentation, will need to leave. Thomas, can you make the recording?
    • [Thomas] starts local recording
  • [07.40] WirelessHART joining flows ([Jonathan])
    • [Jonathan]
      • I tried to capture WirelessHART "security handshake". WirelessHART uses a well-known key at the link layer for "beacons". Note that they are, strictly speaking, a HART MAC layer frame type, not same format as IEEE802.15.4e EB.
      • a device that's already in the network beacons the presence of the network. A joining node hears that and gets information about time base in network, current ASN (used as frame counter in L2 security), information on slotframe and timeslot it can use to send/receive to/from the proxy.
      • New nodes encrypt a "join request" packets that contains HART-specific information and the devices it has heard (short address and some signal level info), also a hop rank information which is received from the beacon (used by the joining device to pick a proxy device). This joining information is encrypted. Destination is always the manager. Uses incrementing counter as nonce when securing joining message (counter never supposed to roll back). Message does not contain any routing information, proxy routes it on behalf of joining mote, and sends it to the manager
      • manager sends back a runtime key, the starting nonce, a manager secure session, the device's short address. WirelessHART does not use legacy IEEE802.15.4 association procedure to assign 16-bit addresses.
      • at that point, the device has completed the security handshake. The manager switches to the assigned sessions for additional configuration: transport sessions, links to neighbor nodes, routing information, and network grooming and maintenance tasks. It the session that was configured.
      • mote ends up with 2 end-to-end sessions: one to the manager, one to the gateway. The gateway is the data sink for the network. The underlying WirelessHART frame is laid on top of 15.4. THe IEEE802.15.4 frame is unencrypted and un-authenticated, WirelessHART wraps a CCM* security model on top.
    • [Thomas] questions?
    • [Michael] the join request/response is proxied, I understand. What about the addition configuration information, does it go through the proxy as well?
    • [Jonathan] It's the end-to-end transport session that encrypts that information. For the most part, that sessions is sent though the proxy first. The device gets its initial security handshake through the proxy, then initial configuration through the proxy, then additional configuration through a number of neighbors. You are correct: additional information is an end-to-end secured message between joining device and PCE. Proxy only does routing for the first steps.
    • [Michael] So the proxy doesn't know that the joining node is sending a join request?
    • [Jonathan] in general, this is true. But the proxy could know that it's a join request because it is coming through links that are advertised through its enhanced beacon. Also, joining device uses its long address until its short one is configured by manager. That being said, the proxy can be agnostic and just forward the information to the manager.
    • [Michael] suggest to change arrow in step 4. All arrows in/out of proxy are the same, in the last step, the arrow could go straight from PCE to joining mote.
    • [Jonathan] in step 2&3 routing might be a little different. This is a first draft, any opportunity for clarification welcome.
    • [Michael] is the joining node aware of the address of the PCE?
    • [Jonathan] in WirelessHART, PCE has well-known address. At the network layer, the joining devices addresses its packets directly to the PCE. This might be different for 6TiSCH.
    • [Subir] About beacon authentication through WKK. Are the join request/response authenticated with the same key?
    • [Jonathan] in WirelessHART, there are two elements:
      • link-layer authentication
      • end-to-end authentication and encryption.
    • [Jonathan] Frames are authenticated at L2. Different keys for end-to-end authentication/encryption.
    • [Max] L2 authentication of the EB, what key is used?
    • [Jonathan] A WKK written in standard.
    • [Max] So not real L2 authentication?
    • [Jonathan] It does goes through the MIC authentication process on the device, allows some level of protection against receiving other traffic from other networks.
    • [Max] probably not a security check, then?
    • [Michael] the rational is to prevent interaction with other non-WirelessHART technologies. Make sure that this traffic would not distract.
    • [Jonathan] Agreed. As an example, in the early days, ZigBee did not use link-layer authentication, which caused demos to break when in same radio space as WirelessHART networks.
    • [Max] so technical value, but no real security
    • [Jonathan] Agreed
    • [Max] we are hence using the term authentication but protocol stability, not security
    • [Jonathan] Agreed
    • [Subir] About the PSK with manager and gateway, are those different keys?
    • [Jonathan] About end-to-end in WirelessHART, the PCE and the joining nodes share a PSK. WirelessHART specification does not indicate how this gets configured. Example include OOB, configuration during commissioning. This key is used to encrypt the end-to-end join message. In the join response, the PCE sets session keys for subsequent communication.
    • [Jonathan] May contrast with what we would do with 6TiSCH.
    • [Subir] When PSK configured at manufacturing, is there a lifetime associated?
    • [Jonathan] typically devices can come pre-configured with key specific to a vendor. Devices should have a mechanism to update those PSKs. This process is not touch-less.
  • [Thomas] we are over time.
  • [Michael] good spot to stop, let's resume with slide 3 ("Wireless HART-like PK Flow") next week.

Updated