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

[Jonathan Simon <[e-mail]>]

Responses inline

> 
> 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.

JS - How the joining node trusts the beacon appears to be one of Rene’s questions.  A well-known key allows you to distinguish it from another protocol, but it doesn’t protect you against an attacker. One option is generating the key based on one of the preconfigured certs. 
> 
>> * 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.

JS - it’s to hear louder beacons, or beacons from devices closer to the manager (coordinator).
> 
>> * 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?

JS - WirelessHART is centrally managed, so the additional connnectivity information is there for mesh management.  There is a separate discovery process (analogous to ND) in the running network to gather the same information, but it is typically slow.  
> 
>> * 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://cp.mcafee.com/d/5fHCMUe6wUqdEInhjKMUqekjtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsSCwXH3Pb_nVWZPhPRXBQSn7-hjjujVqWtAkRrCzAtOEuvkzaT0QSyrhdTV5xdVYsyMCqejtPo0aCMgYZnotrsdKjBiNcLjXdNBcIn8lrxrW0GnPtU02rd79EVjhdCBJOsGm9BWvpKcFBziWq834E-vZa1sg1o9NOsGm9Cy0hHa1EwmzmTQErvKr1ZiF        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> _______________________________________________
> 6tisch-security mailing list
> [e-mail]
> http://cp.mcafee.com/d/1jWVIpdEInhjKMUqekjtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsSCwXH3Pb_nVWZPhPRXBQSn7-hjjujVqWtAkRrCzAtOEuvkzaT0QSyrhdTV5xdVYsyMCqejtPpesRG9pxjFvdTw0e2qKMM-l9OwXn79OFoCnFZCUOCmdKjBiNcLjXdNBcIn8lrxrW0GnPtU02rd79EVjhdCBJOsGm9BWvpKcFBziWq834E-vZa1sg1o9NOsGm9Cy0hHa1EwmzmTQErvKrU8X-yrFc