Malisa Vucinic writes: > With certificates, I agree with you that *if* JA could authenticate > the JN before forwarding the message, it would reduce the risk but > still wouldn’t completely eliminate it, as JN needs to be authorized > by JCE to join. The details would depend on the exact forwarding > mechanism and if/how we decide to use COSE…
Note, that using IKEv2 and 802.15.9, it would be possible to use multiple authenticatiom rounds (rfc 4739), i.e. where the JN first authenticates himself to the JA by using for example certificates generated by manufacturerer. Before this step the JA will be configured with all CAs for all manufacturers who can connect. After this step JA will know that JA is device which is created by one of the allowed manufacturers, and if that manufacturer certificate includes the 64-bit extended address, JA will know that JN has that extended address. Then on step 2 it can use multiple authentication to forward the authentication and authorization to the JCE using suitable EAP method or similar. This will solve the problem that attacker cannot just change it address to do another attack agains JCE, the JA has already verified that the manufacturer certificate was used in authentication before it even connects JCE, and if that authentication or authrozation fails, it can blacklist that extended address to protect himself against further attacks from that JA. This is one of the reasons I think we need to use proper external key management protocol, as they have these features already standardized, and we just need to pick and choose which of those features we want to use. In one environment this would not be needed, on other environment it might be very important. If we just start rolling our own KMP then we end up some thing that might work with some setups, but might miss features we need for another setup, and to add that feature would require us to extended the protocol taking few years... -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
