Dear Tero, many thanks for your feedbacks: somethings are more clear now and other suggestions helped me to identify issues and/or solutions.
More comments below. On Mon, Sep 7, 2015 at 12:55 PM, Tero Kivinen <[email protected]> wrote: > Giuseppe Piro writes: > > Initial assumptions: > > - all nodes known K1. > > - each node shares a PSK with the JCE. It is used for authentication > purposes > ^^^^^ > I assume this means is unique PSK per JN with the JCE, right? > Yes > > > during the join process. > > - the join process is handled at the aplication layer through COAP. A > message > > is sent by the JN, forwarded by the JE and processed by the JCE. > ^^ > I assume this is JA? > > Yes > > - if the JN is authenticated by the JCE, the JCE sends the K2 (stored and > > encrypted with the aforementione PSK in a COAP message). > > - JN processes the received COAP message and installs K2. > > > > Main open issues: > > - messages exchanged between JN and JA must be "protected". For the > moment we > > can assume to use K1. > > If K1 is known by all nodes, does not protect, or even "protect" the > exchanges. There is no benefit in security for using well known key > for joining. There is little benefit for using widely known group > shared key K1 in security. There is bit of security if you use group > shared key which is rekeyed every now and then. There is bit more > security if the group shared key is rekeyed every time anybody leaves > the group. > > I assume you put word protected in quotes to trying to indicate that > it offers less security than real key, but as it offers NO security > benefit, it is better not to claim that those messages are secured or > protected or "protected" in any way. > I agree with you. "protect" (protect with quotes) means that messages are encrypted and authenticated through CCM* primitives, even if the well-know key K1 is used (=no protection). For the moment this assumption is needed for reaching a preliminary configuration that may run on real devices and is fully compatible with IEEE 802.15.4e-2012. For what I've understood, this follows the same approach followed in the 6tisch-minimal. Please, correct me if I'm wrong. > > > - JA does not know JN; it does not have the corresponding Device > Descriptor > > for JN; it must implemnet a procedure for understanding if the join > message > > should be forwarded or not (protection against DoS ? ). > > It could use 802.15.9 and create pairwise key between JA and JN using > authentication that is forwarded to the JCE. In that case only the > authentication requests and replies needs to be forwarded, not full > joining exchanges. > > This does not really protect against DoS, as if you do not know who > the other end is, and you have not authenticated, there is not really > that much you can do. You can blacklist the address after first fail, > but attacker can use different address for each attack, you can rate > limit the requests, but that will cause DoS anyways, as legitimate > devices cannot now join anymore etc. > > If you do KMP between JN ja JA, then at least the attack is localized, > and load is distributed. I.e. JN and JA does about same amount of > work, but rest of the network and JCE does much less work, than if all > joining messages are always forwarded to the JCE. > > I agree. A local authentication (i.e., between JN and JA) could isolate the attack. I've already highlighted this aspect during the previous con call. > > - the format of join packets should be defined. Input from COSE. The > first > > packet sent by JN should also contain the ASN (of course, also this > field is > > protected by the PSK). This should avoid replay attacks. > > With ASN you need to define the timing constraints, i.e. how old ASNs > you are willing to accept? It might take quite a few ASNs before the > message from JN reaches JCE. Actually simple counter might be easier, > as you can simply assume that valid JN always increments the counter > before trying to join, so if you see same (or smaller) counter later, > you know it is replay. > Totally agree. > > > - definition of mechanisms for installing K2 in JN. > > 802.15.9? > > > - the distribution of link layer keys is another problem. Two > possibilities: > > centralized (JCE distribute keys) or distributed (KMP). SHould we define > > procedures/message formats for both of them ? > > 802.15.9? > > > Possible extensions: > > - substitute PSK with certificates . > > 802.15.9... > Yes, ok. 802.15.9 is now on the list (... my list ...) of mechanisms to integrate in the join process. Giuseppe -- *Giuseppe Piro, PhD* Post Doc Researcher DEI, Politecnico di Bari via Orabona 4 - 70125 (Bari), Italy. email: [email protected] phone: +39 080 5963301 web: telematics.poliba.it/piro
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
