Malisa Vucinic writes: > Option 3 would imply designing a minimal 6tisch solution to provision K2, > compatible with the existing 6tisch architecture and mechanisms (6top, > CoAPie). In short, we discussed a simple protocol where JCE keeps track of > JN-specific join counter used for replay detection, that JN advertizes in the > hello message including information like its EUI-64, random challenge for JCE, > all protected with PSK. The JCE sends K2 encrypted with PSK and transfers > that over the network to JN. Advantage of this direction would be minimized > traffic load (3 messages vs 11+) and possibly implementation requirements as > we can do this extending 6top and re-using CBOR implementation. A disadvantage > would be the fact that we are not using a standardized solution.
PSK only solution is not going to work, as it would require some kind of userinterface in all devices, which is used to change the PSK when it leaks out, or when the device is recomissioned to new environment. So I would rule all PSK ONLY solutions out of question. The solution needs to support at least some kind of raw public key or similar method to be scalable. Because of this I think the option 3 is not good idea, as we would need to define more complicated protocol than what you express, there and immediately when we start to go towards that path, it is better to start to use already existing real KMPs. In 802.15.9 we realized this, and our PAR explictly said that we will not create new KMP. We just use existing KMPs. > Option 1: EAP-based > ——————————— > Case 1.A: IKEv2 over 802.15.9 + EAP (e.g. -AKA) ( > http://mailarchive.ietf.org/arch/msg/6tisch/fPmwtSOL-v0FDNcU3sWwHAdeyTs) > - Traffic load: 6 messages between JN-JA, 4 messages between JA-JCE > - Implementation requirements: minimal IKEv2, 802.15.9, EAP-AKA > - Notes: JA takes active role during join, could be useful for DoS protection > with certificate-based authentication You can also run IKEv2 over 802.15.9 using raw public keys, which will simply be 4 messages between JN-JA, and then you do need to run some protocol between JA-JCE, where the JA sends the hash of public key + EUI-64 to the JCE, and JCE says whether that device should be allowed to connect (i.e. ACL check done on the JCE). Of course the ACL can also be distributed from tje JCE to the JAs, but if the ACL is large, it is better to do the check when the JN joins. This also protects the device association, and the IP address assignments, as all communcation betwee JN-JA is done over 802.15.4 frames, and no IP-address is needed yet. This would drop the traffic load to 4 message between JN-JA and 2 messages between JA-JCE. This would be my preferred way of solve this problem. > Case 1.B: EAP over PANA > - Traffic load: minimum 4 messages for PANA + [ 5 messages for EAP-AKA, 15+ > messages for EAP-TLS ] + 1 packet to provision K2 > - Implementation requirements: PANA, EAP method > - Notes: JA is a passive relay Good thing here is that it is reusing lots of existing protocols, bad thing is that you need lots of messages. Also I think you need to get IP-address before you can run PANA (unless you run PANA over 802.15.9), so that will add overhead and also consume resources. > Case 1.C. EAP-PSK over CoAP + DTLS (e.g. draft-marin-ace-wg-coap-eap-02) > - Traffic load: 10 messages between JN-JCE to establish a unique session key + > 11 messages for DTLS to establish a session with the established key + 1 > packet to provision K2 > - Implementation requirements: EAP-PSK, (DTLS) > - Notes: JA is a passive relay Same as 1.C. I.e. need IP-address, cannot protect IP-address assignment (and device association, if that is needed before getting IP-address), quite a lot of packets. Good thing again is that we reuse lots of things, and we can use different authentication methods (i.e. EAP-PSK is not something we should use in real world). > Case 1.D. EAP-PSK over CoAP + custom protection of CoAP header/payload with > the generated key > - Traffic load: 10 messages between JN-JCE to establish a unique session key + > 1 packet to provision K2 > - Implementation requirements: EAP-PSK, custom CoAP security extension > - Notes: JA is a passive relay Anything that we need to define here as security will be bad idea, i.e. designing KMP is not that easy. There are lots of pitfalls you might trip into, and I would recommend against specifying new KMP here. > Option 2: DTLS-based > ——————————— > Case 2.A: JN is a DTLS client > - Traffic load: 11 messages between JN-JCE + 1 packet to communicate K2 over > the established session > - Implementation requirements: (DTLS), relay application > - Notes: JA is a passive relay This would allow us to use any DTLS authentication methods, i.e. I tihnk we could use raw public keys etc. > Option 3: 6TiSCH-specific > ——————————— > Case 3.A: Explicit provisioning of K2 using 6top+CoAP, protected with JN’s PSK > (e.g. http://mailarchive.ietf.org/arch/msg/6tisch/Obm-_ehdAeGXKXOEwzpdeB5diq8) > - Traffic load: 3 messages between JN - JCE > - Implementation requirements: (CBOR) + COSE > - Notes: JA is a passive relay PSK only solution is not really acceptable, and we would need to provide something that supports something that can be used in real world. In lot of situations we do not want to give the PSK of the device to the all networks we might join into. I have used an example of key token earlier. If I have one key token in my keyring, and I want to use it to open different doors, like home, and office. I do not want to give the PSK from the key token to the office manager, as then if someone steals the PSK from the office, they will be able to open my home door. Also the office manager might not trust that my home server is so well protected that nobody can break in, thus they do not want to allow my PSK to be used to open office doors, as anybody breaking to my home server, will be able to open office doors. So we do need some public key based system, and specifying new KMP here is bad idea. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
