Was: [6tisch] questions about draft-richardson-security-6top > On 13 May 2015, at 09:43, Michael Richardson <[email protected]> wrote: > > I think that you mis-understand the purpose of the join process. > It's not about joining the DODAG or the network, it's about joining the > local security domain. The energy harvesting node would run the join > process once, and would then get provisioned with a number of things. > Specifically: > S1) a locally relevant certificate and/or MSK (from the JCE) > S2) a set of paths and timeslots (from the PCE) > S3) some application specific set of things (e.g. a light switch > is told which light bulbs to control, or perhaps which multicast > groups to use to announce the switch changes if bulbs listen to > switches …)
Yes, I was definitely considering ‘joining the network’ as part of the join process. But how is provisioning S2 and S3 different from joining the network? One can consider that the local security domain has been joined by a node once S1 has been provisioned, no? And provisioning S2 and S3 is then something which we should not consider part of the join process? > Certainly, if you need security for 3, one could use a a TLS > session-resumption ticket for that state. My remark on the applicability of session-resumption for energy-harvested nodes was related to the problem that the end-to-end session state with JCE is not preserved if the energy-harvested node runs out of energy during for instance 12 hours of dark, as RAM may not be retained. Do you think writing TLS state to flash would be a good solution? I have doubts on this as: a) if node is off during those 12 hours, JCE’s heartbeat will recognize this and may terminate the session locally; b) I may not want to write to flash every time keys change, as flash operations are very expensive. > > But, there is no reason for this node to rerun the join process. > As Tero has pointed out, the node might need to stay awake long enough to > hear the ASN from the EB if it hasn't got a good clock. If everything is written in flash, I agree. The problem then remains if a node was off long enough that schedule/keys change. What mechanism does it use to recognize it has outdated information? > > I wonder how we can make this seperation of responsibility clearer. > If you understand what I'm saying, perhaps you can tell me how to avoid > this misunderstanding in the future? I am not yet clear if you consider L2 keys to be the output of the join process? To me, ‘joining local security domain' ends once S1 has been provisioned as it is a permanent credential from which various temporary keys can be derived. However, one can also simply use JCE to provision L2 keys, without local key derivation from MSK or certificate. In that sense, I see two phases here: Phase 1 whose output is a JN <-> JCE session and optionally MSK/locally significant certificate. Strictly, I think this is where one can consider that the JN has joined the local security domain. Phase 2 whose output are L2 keys, from JCE or locally derived. Does that make sense?
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
