Hi Tero: Some comment inline.
> El 26 oct 2015, a las 13:04, Tero Kivinen <[email protected]> escribió: > > 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. I guess HIP-DEX could be also used alternatively. In any case, how does the JCE know the JN is actually there? Because, in the end, the JCE does not authenticate the JN. This has been discussed in the past ("peer consent”). In my opinion, the JCE should be in charge of first-hand authenticating the JN. > > 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. My understanding is that IKEv2 was designed to be transported on top of UDP. Thus, if IKEv2 can be transported in IEEE 802.15.9, similarly PANA or CoAP could be transported as well. In the case of CoAP, even there is some study with coapie. In case of PANA, there was some proposal about it. Btw, in Zigbee IP they already use PANA and the link-local IPv6 address in the JN, as far as I remember. PANA has also a "PANA relay" (RFC 6345) defined for the JA. > >> 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. As commented above, transporting CoAP in IEs could be a possibility. > 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). Agreed. As I mentioned in a previous e-mail, the usage of EAP-PSK is not mandatory in CoAP-EAP. Any EAP method can be used. https://mailarchive.ietf.org/arch/msg/6tisch/CxWuc_56Q8PmFx38xvCHfs9FzpY In fact, as I stated the number of exchanges can be reduced with a proper EAP method and some optimizations in the original EAP over CoAP draft. > >> 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. I do not think this is referring to a new key management protocol (there is no protocol exchanges) but only a way to protect CoAP messages at application level with some key material obtained from the EAP authentication. For example, OSCOAP could be an example (https://tools.ietf.org/html/draft-selander-ace-object-security-03) > >> 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. The usage of EAP would also provide all the flexibility in term of authentication method. That was the main motivation of the EAP design. Best Regards. > >> 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 ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email protected] ------------------------------------------------------- _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
