It seems that this would trigger the exchange of: (1) 6 packets between JN and JA, (2) 4 packets between JA and JCE on a multi hop path.
Communication of (1) happens in the shared slot so collisions are likely. Communication of (2) happens over multiple hops so it affects the network. I am skeptical how this would look like in terms of delay for the initial formation of a large network and in your example bellow JA learns that JN is valid only in step (6) at the end of the exchange, when 4 packets have already traversed the whole network. In that sense, I don’t see any benefit from JA there, except that we can get rid of one packet, EAP identity request… Am I missing something? What do we loose in terms of security if JN simply uses its PSK to generate a MAC protected COSE object that can fit in one radio frame that JA forwards to JCE? We said that we can protect from replay either using ASN or a monotonic counter local to JN. In that case, it would suffice that JCE verifies the object and creates a new one that JN can accept, encapsulating whatever domain-specific keys are necessary… This would result in: (1) 2 packets between JN and JA, (2) 2 packets between JA and JCE on a multi hop path. This roughly reduces the latency by a factor of 3 for the most critical stochastic part, and by a factor of 2 for the deterministic part… I realize that we are not doing challenge-response there but I am not clear what do we really loose since JCE takes care of replay protection from a rogue JN, and JN can make sure that it does not use the PSK with the same IV more than once? Regards, Mališa > On 08 Sep 2015, at 13:03, Tero Kivinen <[email protected]> wrote: > > If you use 802.15.9 with IKEv2 (I use that as an example as I know it > best), and you use mutual EAP-AKA for IKEv2 authentication the > exchange would be as follows: > > > JN JA JCE/AAA > == == ======= > > IKE_SA_INIT ------> > > <------ IKE_SA_INIT > > IKE_AUTH ---------> (1) > > EAP-Response/Identity --> (2) > > <----- EAP-Request/AKA-Challenge > > <---------- IKE_AUTH (3) > > IKE_AUTH ---------> (4) > > EAP-Response/AKA-Challenge --> (5) > > <----- EAP-Success > > <---------- IKE_AUTH (6) > > After that exchange the JN and JA share key generated by IKEv2, and JN > has been authenticated using EAP-AKA, and the JN can trust that JA is > someone who can connect to JCE and that authenticates network for him. > > > (1) This message already contains the ID, so the EAP Identity request > and response messages are omitted. > > (2) This EAP-Response/Identity is generated based on the IKEv2 ID > inside the IKE_AUTH, and it is transmitted using whatever protocol > that is there for JA to talk to JCE. The protocol could be RADIUS, > Diameter, or EAP over CoAP or whatever. This authentication needs to > be secured, so that nobody not in the network cannot do authentication > requests, but as JA is already part of the network and shares key with > JCE this should be easy. > > (3) This IKE_AUTH contains the AKA-Challenge request received from > JCE. > > (4) This IKE_AUTH contains the AKA-Challenge response generated by JN. > > (5) JA takes the AKA-Challenge response from IKE_AUTH and forwards it > to the JCE. If JCE verifies the response, it will send EAP-Success > indicating that JN should be allowed to join. > > (6) this IKE_AUTH will contain the EAP-Success, and it will finish > creating the keying material used between JN and JA. The JA will > already at that point know that JN is authenticated, so it can also > send all group shared keys inside that IKEv2 message to distribute > group keys to the JN. > > After that the JN can start TSCH related joining process, i.e. > associate itself to the network to get short address, and allocate > required transmission slots. All this is already secured by either the > link key shared between JN and JA, or group key sent by the JA to the > JN after JN has been authenticated. > > Instead of IKEv2, you can most likely use also other KMPs specified in > the 802.15.9 (802.1X, IKEv2, HIP, PANA, Dragonfly).
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
