Hi Malisa: Thanks a lot of for this analysis. I would like to make some clarifications regarding the option 1.C/D. related with draft-marin-ace-wg-coap-eap-02 and other aspects.
1) EAP-PSK is just an example in our draft (maybe it is not clear in the current version so we will try to clarify it). So saying EAP-PSK over CoAP is not accurate. It is just EAP over CoAP. You can use any EAP method you want. In fact the usage of EAP is to give flexibility for the authentication mechanism. Moreover it opens the door to scalability. 2) The establishment of DTLS is required if you want to protect CoAP messages (e.g. for other services) after the EAP authentication happens. In fact EAP over CoAP goes through unprotected port. The question is: do you need to protect CoAP messages after the bootstrapping happens? If yes any solution will require to DTLS unless you protect the CoAP messages at application level (like option 1.D) or if the link-layer is protected with the keys generated after EAP authentication. Having said that I have some additional comments inline. > El 22 oct 2015, a las 14:55, Malisa Vucinic <malisa.vuci...@imag.fr> escribió: > > Dear all, > > Here is an attempt to summarize the recent discussions regarding the problem > of 6tisch join and provisioning of K2 to JN. See bellow. Implementation > components that can be reused are enclosed in the parentheses. Traffic load > is expressed as the number of messages, rather than number of exchanges, as > this better reflects the nature of the link we will be using: a single shared > communication slot carrying ~100 bytes of data (cf. > draft-ietf-6tisch-minimal). > > It seems there are three main directions the WG can take: 1) EAP over foo; 2) > DTLS; 3) 6tisch-specific solution. > > Option 1 seems the most extensible and generic but I dislike the fact that > there would be a lot of join-specific code. We are already having > difficulties fitting the stack into certain IoT MCUs due to the flash > constraints and having 2-3 protocol implementations that are used only once > certainly does not help. Cases 1.C and 1.D that seem to require less > join-specific code have either prohibitively large traffic load (1.C) or rely > on session security that is not standardized, in which case a 6tisch-specific > solution with 4x improvement factor in traffic would IMO be a better option. Here you can find a study about the usage of PANA in constrained devices (in particular, Contiki OS). http://www.mdpi.com/1424-8220/13/11/14888 We are doing same study related with EAP over CoAP, with implementations we have of our service for Contiki OS and mbed. In fact, EAP over CoAP was born precisely for your comment ("having 2-3 protocol implementations that are used only once certainly does not help”). EAP over CoAP re-use source code related with CoAP (that is assumed to be used for other purposes as well) and it only adds EAP, which is not too complex. > > Option 2 leverages the DTLS implementation that is in any case mandated by > CoAP so it does not necessitate much additional implementation effort, Thus, we assume in this option we have CoAP anyway, right?. Then, EAP over CoAP assumes that you can built an authentication/bootstrapping service based on CoAP. > other than the JA relay application. Another advantage here is that one can > pass from PSK to certificate-based authentication transparently. This advantage is also possible in EAP-based solutions for, precisely, the usage of EAP. > The traffic load remains a significant concern. See > http://arxiv.org/pdf/1507.05810 for some figures on duration of DTLS PSK > handshake with *dedicated* cells (e.g. ~5 seconds per hop per JN with > 101-long slotframe, and this is in the *best* case tripled with many nodes > joining and slotted Aloha behavior). This is a great paper indeed. That is why I think it might be worthy considering protection at application level (maybe OSCOAP) > > 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. Sorry for not knowing the details of this option, but I understand that JN is authenticated with the PSK, right?. > > It would be useful if we could discuss some of these aspects tomorrow during > the call. Also, it would be great if people with benchmarks on join duration > without any security would post these to the list. > > Regards, > Mališa So some final comments to your analysis… below... > > 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 > > 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 Btw, Zigbee IP already uses this option. > > 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 > > 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 In 1.C/D the idea of using CoAP in EAP over CoAP is to re-use source code and providing shorter messages to transport EAP. As I said, adding DTLS is necessary if you want to protect further CoAP messages after the bootstrapping unless you want to use protection at CoAP level (e.g. OSCOAP) or link-layer protection that is bootstrapped after the EAP authentication. Btw, I am thinking that a little re-design of EAP over CoAP service with a proper EAP method could allow to generate a fresh pre-shared key in less messages. Nevertheless, this is just a preliminary thought that needs to be discussed of course. > > 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 And considering protection at application level to avoid DTLS? > > 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 I still need to check more carefully this link (the flow is difficult to read) but if we assume that a PSK is used as credential for the JN there are several handshake protocols in the literature (e.g. AKEP2, HIP-DEX,...) that may be adapted for this case. In any case, somehow that is not “bootstrapping" to me because it is just assuming you configure “manually” a PSK and run the handshake protocol. Although I might be wrong. Let’s talk tomorrow in the call if time is available. Best Regards and thank you again! > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > 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: r...@um.es ------------------------------------------------------- _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
