Subject: [6tisch-security] Minutes security discussion 02 June 2014

From: Thomas Watteyne <[email-masked]>
Date: Mon, 2 Jun 2014 14:24:59 -0700

All,

You will find the minutes of the last security discussion at
https://bitbucket.org/6tisch/meetings/wiki/140602_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 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

   - Webex recording (first half, TOC discussion)
   <https://cisco.webex.com/ciscosales/lsr.php?RCID=ecf63d701da3482b80841dd6c8285171>
    *[36min]*
   - Webex recording (second half, WirelessHART security)
   <https://cisco.webex.com/ciscosales/lsr.php?RCID=a29b09eed4b242da962cc6f9017404a0>
    *[22min]*

Slides

   - 140602_webex_sec.pdf
   <https://bitbucket.org/6tisch/meetings/src/master/140602_webex_sec/140602_webex_sec.pdf>:
   slides shared during the call

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.