[6tisch-security] minutes from winter 2017 meetings

[Michael Richardson <[e-mail]>]

These are the minutes from the 6tisch-security design team conference calls
of 2017-01-17, 2017-01-31, and 2017-02-14.  We need every two weeks
at 1400UTC via webex.  Note that we will have additional meeting
on 2017-02-21, and then again on 2017-02-28.

Attendance:

2017-01-17:
    present: Michael Richardson, Tero Kivinen, Pascal Thubert,
             Thomas Watteyne, Mališa Vučinić

2017-01-31:
    present: Michael Richardson, Mališa Vučinić, Tero Kivinen

2017-02-14:
    present: Michael Richardson, Mališa Vučinić, Tero Kivinen

The 17th was the first meeting of 2017.  The table of contents of the two
documents were placed into the etherpad and common items were identified.
A plan was formulated to organize the zero-touch and one-touch documents.

Some details:
     1.  Introduction  <--- make this common, refer to each
     2.  Terminology . . . <-- make this in one document only. move all terms to terminology draft.
     3.1.  Step 1 - Enhanced Beacon  . . . . <-- common text

     1.  Introduction  . <--- make this common, refer to each
     1.1.  Terminology . <-- make this in one document only.
     1.2.  Credentials
       1.2.1.  One-Touch Assumptions . .<- move this to 6tisch-minimal.

       1.3.4.  Size of packets, number of fragments  . Phase one, and phase two results.

We worked on the terminology section, and made the following suggestions,
which were previously posted.  The suggestions were brought to the ANIMA
bootstrap design team, and that team agreed upon them:

   o  JN: Joining node - the device attempting to join a particular
      6TiSCH network.
      -> BECOMES pledge

   o  JCE: Join coordinating entity - central entity responsible for
      authentication and authorization of joining nodes.
      -> BECOMES Join Registrar and Coordinator

   o  JA: Join assistant - the device within radio range of the JN that
      generates Enhanced Beacons (EBs) and facilitates end-to-end
      communications between the JN and JCE.
      -> BECOMES Join Proxy

The new terminology is now:

pledge
:  the prospective device, which has the identity provided to
   at the factory.  Neither the device nor the network knows if the
   device yet knows if this device belongs with this network.

Joined Node
: the prospective device, after having completing the join process, often
  just called a Node.

Join Proxy (JP):
:  a stateless relay that provides connectivity between the pledge
   and the join registrar/coordinator.

Join Registrar/Coordinator (JRC):
:  central entity responsible for authentication and authorization of joining
   nodes.

We discussed some of the terms used in 802.15.10:
   "mesh root",
         802.15.10 definition is: "mesh root: Device in the layer 2 routing
            mesh with depth zero that manages the mesh."

We discussed the question about whether the Registrar and Coordinator always
co-located.  We did not come up with a conclusion.

In addition, a weekly document working session was agreed to among the authors.

At the 2017-01-31 meeting, we spent some time discussing the various options
for key modes and rekeying.  Tero Kivinen suggested the mechanism for
rekeying:  a new key would deployed by the JRC to all nodes.  It can do this
over an extended period of time.  When it thinks that it has reached as many
nodes as it can, then it starts using the new key.  Nodes, upon seeing a new
key in use on the receive side, switch to sending with the new key, and the
key change ripples through the mesh.

We also discussed pair-wise keying, and decided it was out-of-scope for
minimal.   We would use KEYIDMODE=1 keys only, which are identified by
a keyid.  There are 255 of these.  We later decided that we would pair
the multicast keys ("K1") as used by the Enhanced Beacons and the unicast
keys ("K2") used for regular traffic, in an odd/even fashion such that
two keys would also be provisioned, and whenever there was a switch, it
would switch both keys at the same time.

We discussed the question about if we could do the rekey operation via an
OBSERVE CoAP method, but we did not determine if OBSERVE is confirmable.

We noted that the JRC sets the short address for the node, so it knows how
to reach the node after it has joined, and thus it can easily reach out to
all the nodes.

We discussed if we should use a time-(ASN!)-based time to rekey or switch
keys, and concurred that we may not always be able to predict when a rekey is
needed (emergency rekeys due to node compromise for instance), or how long it
will take to reach all nodes to do the rekey, so we are better off not going
this direction.

A reason for the rekey optimization is to avoid redoing public key operations!

At the 2017-02-14 meeting, Michael and Mališa presented a FSM for
the pledge to join the network.  The diagram is at:
   http://www.sandelman.ca/SSW/ietf/6tisch/pledge-join-states_EB.svg

Some discussion that ensued involved the question of how long a pledge would
have to wait in order to hear the Enhanced Beacon.  We continue to have some
concern that without some attention to the parameters that it could take a
pledge minutes to hours to be on the right channel at the right time to hear
the EB.




--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-