Tero Kivinen <[email protected]> wrote: > It depends what your environment is. If the joining process is > happening only once when the network is set up, then running 10 > messages during that is not a problem. If it happens every time you > move from one room to another (i.e your remote controller joins the > 6tisch network in the room to control the lights), then doing it > quickly with 4 messages might be better.
The joining process runs once.
This is in the architecture document.
6tisch is not, btw, about remote controllers in a home, so it's important to
use reasonable use cases.
But, in that case, the remote control would have been provisioned with a
locally significant certificate (not RPK) which a 802.15.9 KMP could use
(with a 4 message exchange) to establish new per-peer pairwise (does 802.15.9
have a better word for that, btw?) keys.
(However, I don't know if I'd care to do per-peer pairwise keying for a
homenet: I'd might prefer a network-wide K2, and a protocol to rekey K2
weekly, or whenever my house guests leave.)
> that is how the authors of those parts of the 802.15.9 defined things.
> I.e. PANA does not really create dynamic link-keys and negotiate SAs
> between devices, nor it can do rekeys etc. Or that is at least what I
PANA is mostly just a container for EAP, and one can use some MSK parts to
secure the PANA channel.
> Bootstrapping is separate problems and I think we should more
> concentrate on the KMP issue. I.e. how do we get the pairwise keys
> between device A and B, and how do we distribute the group key using
> KeyIndex 0x02 and KeySource of 0xdcac000000000002 to joining device.
I agree. The problem is transitive trust and authorization during enrollment.
--
Michael Richardson
-on the road-
pgpmAFdMoJo3c.pgp
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
