> On 07 Sep 2015, at 12:55, Tero Kivinen <[email protected]> wrote:
> 
> 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.

I think we all agree on this. Since JN and JA do not share any pre-existing 
crypto material, we rely on leap-of-faith for the initial exchange(s).


> 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.

I think we agree that only JCE can authenticate JN based on a PSK and that this 
ends up at JCE in any case. What do you mean by full joining exchanges? How 
many packets between JN <-> JA <-> JCE do you consider necessary, strictly from 
a security perspective?

> 
> 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.

How can JN and JA run a KMP when they don’t share any crypto material? Are you 
assuming certificates for mutual authentication here? 

> 
> 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. 

I am not sure the management of per-node, join-specific replay counters in a 
large network is simpler than comparing if ASN_received > ASN_now - window.
But since JCE may not necessarily know the topology, I agree that estimating 
the window size would add additional complexity, when PCE and JCE are not 
collocated.
An important point there is that JN must write the counter in non-volatile 
memory after each join re-try.

Regards,
Mališa
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to