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?
> 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?
> - 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.
> - 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.
> - 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.
> - 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...
--
[email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
