Michael, all, tl;dr: The relevant WIP commit is at https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/21ad042639b4617bf7a6993e9140a65d702680ef ..
I did quite a bit of work in the document, including some CBOR wizardry, and defined new parameters and IANA registries with the goal of homogenizing the join for 6LBR and regular nodes. For now, I added an optional "network prefix" parameter in the Join Response, carrying the IPv6 prefix of the network for the 6LBR. If there are some pitfalls with this that I forgot, we can remove it. Similarly, I also added the "network identifier" parameter in the Join Response, carrying PAN ID for the 6LBR. Regarding CBOR, the top-level types in Join Request and Join Response are now all maps, but I removed the use of COSE_Key and COSE_Keyset and defined our own structures in order to save bytes when transporting keys. Essentially, this means that we are flexible to add new parameters in the future in top-level Join Request and Join Response objects, but the inner objects are fully optimized and poorly extensible due to the use of arrays and uints. I also worked out a new key signaling mechanism using a "key usage" parameter, where a single uint value from the registry specifies the IEEE 802.15.4 security level to be used and the appropriate frame types the key can be used with. The mechanism is flexible in that it allows us to transport a key that is both K1 and K2, separate K1 and K2, different security levels for each, and we can also define new combinations of security levels/frame types in future. The solution only supports KeyIndex mode of IEEE 802.15.4. Supporting other modes required mimicking 15.4 security structures to configure the security module and would have required maps everywhere and extensive overhead. If you have any better idea how to add support for other keying modes of 802.15.4, let me know. Feedback is welcome, I am continuing with the work on the rekeying mechanism that we discussed. Mališa On Tue, Apr 24, 2018 at 11:06 PM Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Mališa Vučinić <malisa.vuci...@inria.fr> wrote: > mcr> I'd say that you always do this with any new key if you > mcr> have no keys. > mcr> I don't think we need a flag. > > mcr> In fact, even for the "0th key", you would start using it > mcr> as soon as you see > mcr> something that passes with that key, such as > mcr> authenticating the Beacon that > mcr> you used to find the Proxy in the first place.... > > > Authenticating a beacon that was received long time ago would require > > the pledge to store the beacon(s) for potentially an extensive > > period... I don't think we need to do that. > > No, I'm not suggesting one keeps it for along time. > > What I'm saying is that, just after getting the Join Response, a pledge > now has > some set of keys. It will have an authentication key. It could > immediately > authenticate the Beacon that it used to find the Proxy. That does a few > things: > > 1) validate the Beacon! > 2) since the key successfully validates the Beacon, it proves that the key > the > pledge got is a current key, and so the key would be marked as > activated. > > Of course, if the pledge doesn't have enough ram to keep the beacon > around, then > it shouldn't do that. It can validate the next beacon instead. > > > Essentially: > > - 6LBR: installs the new key, starts using it for outgoing traffic > > immediately, removing old keys, if any. > > > - joined node and pledge: installs the new key, keeps using the old > > keys for outgoing traffic until it receives incoming traffic secured > > with the new key, with all L2 security checks passed. In the special > > case of a pledge, there shouldn't be any outgoing traffic before it > > decrypts DIO(s) and selects a preferred parent. > > Exactly. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > > >
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
