[6tisch-security] wirelessHART/6tisch join process

[Michael Richardson <[e-mail]>]

Jonathan Simon <[e-mail]> wrote:
    > * One or more devices are sending beacons to advertise the presence of
    > the network. In WirelessHART, this frame is unencrypted, but
    > authenticated with a well known key.  The beacon contains the current
    > ASN, which the joining device uses to synchronize its clock.

I think that this step won't change at all.
draft-piro-6tisch-security-issues-01 calls this a Partial and Hybrid Secure
Network.

    > * Once the joining node has heard a beacon, it continues listening for
    > additional beacons for a short specified timeout.

You don't explain this part, but one assumes one does this in order to:
  1) perhaps obtain a better (louder) beacon.
  2) in order to hear the correct (non-malicious beacon) as well.

We also need to listen for an RA during some slotted-Aloha period,
which the beacon(s) would tell us about.

    > * The joining node encrypts a frame containing some HART specific
    > content, including a list of beaconing neighbors it heard in the
    > previous steps. The size of the payload is ~ 60 bytes.  The packet is
    > routed by a "proxy" node - the joining parent. The frame is
    > authenticated using the well-known key, and encrypted using a shared
    > symmetric key known only by the node and the manager.

The name for this message is the ND+ARO... That's how things map.
And the ND+ARO is "routed by a proxy node", exactly the same.
The frame is authenticated using a public key rather than a well known
symmetric key.  The message is probably not encrypted.

What is the purpose of including the list of beaconing neighbours?

    > * The manager responds with a frame containing the run-time link-layer
    > key, the node's new short address (this takes the place of PAN
    > coordinator association), and a unicast session key and starting nonce
    > for the manager. This frame is encrypted with the symmetric key. The
    > payload is ~ 60 bytes, and is routed to the proxy for delivery to the
    > joining node - the proxy uses the link-layer well known key on the
    > frame.

ND+ARO reply, but possibly not including all of this information.
My understanding is that in the WirelessHart case, that the format of this
frame is in the same sensor/acutator format as application layer traffic.

In the 6tisch situation, this is where we would like to insteed start
the DTLS/CoAP session.  Ideally, we'd like like it to be end-to-end, but the
node is not completely on the network, and so it might still require a
proxy.  That *could* be trivially in the form an IPIP header, or it could
more complex.

    > * At this point the joining node transitions to using the run-time
    > link-layer key for all link-layer frames, and the manager unicast
    > session for end-to-end manager traffic. This ends the initial security
    > handshake.

Agreed --- one can imagine that the node might remove the JOIN key from its
MAC, and replaces it with the run-time key, and that might even involve
resetting that chip or something.

    > * Over a number of additional frames, the manager assigns additional
    > sessions, including broadcast sessions, and a unicast session to the
    > Gateway (sink for all data traffic), and additional communications
    > resources, routing information, etc.  There is no explicit transition
    > from joining to joined - the mote transitions when certain key frames
    > are received.

This is akin to the 6top schedule distribution.

    > * Note that a WirelessHART link-layer frame contains and additional
    > frame type byte and a 4-byte link-layer MIC, on top of the unsecured
    > 15.4 frame.  A network frame contains an additional 16-40 bytes of
    > addressing, routing, security and other information.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


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