Malisa Vucinic writes:
> > 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?
If you use 802.15.9 with IKEv2 (I use that as an example as I know it
best), and you use mutual EAP-AKA for IKEv2 authentication the
exchange would be as follows:
JN JA JCE/AAA
== == =======
IKE_SA_INIT ------>
<------ IKE_SA_INIT
IKE_AUTH ---------> (1)
EAP-Response/Identity --> (2)
<----- EAP-Request/AKA-Challenge
<---------- IKE_AUTH (3)
IKE_AUTH ---------> (4)
EAP-Response/AKA-Challenge --> (5)
<----- EAP-Success
<---------- IKE_AUTH (6)
After that exchange the JN and JA share key generated by IKEv2, and JN
has been authenticated using EAP-AKA, and the JN can trust that JA is
someone who can connect to JCE and that authenticates network for him.
(1) This message already contains the ID, so the EAP Identity request
and response messages are omitted.
(2) This EAP-Response/Identity is generated based on the IKEv2 ID
inside the IKE_AUTH, and it is transmitted using whatever protocol
that is there for JA to talk to JCE. The protocol could be RADIUS,
Diameter, or EAP over CoAP or whatever. This authentication needs to
be secured, so that nobody not in the network cannot do authentication
requests, but as JA is already part of the network and shares key with
JCE this should be easy.
(3) This IKE_AUTH contains the AKA-Challenge request received from
JCE.
(4) This IKE_AUTH contains the AKA-Challenge response generated by JN.
(5) JA takes the AKA-Challenge response from IKE_AUTH and forwards it
to the JCE. If JCE verifies the response, it will send EAP-Success
indicating that JN should be allowed to join.
(6) this IKE_AUTH will contain the EAP-Success, and it will finish
creating the keying material used between JN and JA. The JA will
already at that point know that JN is authenticated, so it can also
send all group shared keys inside that IKEv2 message to distribute
group keys to the JN.
After that the JN can start TSCH related joining process, i.e.
associate itself to the network to get short address, and allocate
required transmission slots. All this is already secured by either the
link key shared between JN and JA, or group key sent by the JA to the
JN after JN has been authenticated.
Instead of IKEv2, you can most likely use also other KMPs specified in
the 802.15.9 (802.1X, IKEv2, HIP, PANA, Dragonfly).
> How can JN and JA run a KMP when they don’t share any crypto
> material? Are you assuming certificates for mutual authentication
> here?
They could use certificates, but they can also use EAP or similar to
delegate the authentication step to the JCE, as explained above.
> > 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.
Only the JCE needs to keep track of that counter for everbody in the
network, and JCE already stores keying material and other information
about all possible JNs that might join, so adding 4-octet counter
there is not that big increase. Then all nodes need to store their own
counter and increment it every time they join the network.
> 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.
You also have to take in to account that some of the frames from JA to
JCE might need to be retransmitted, and you have to wait for links
between each nodes the frame might go through etc. If you know the
network topology completely, and know their retranmission counters,
you might estimate the number, but easier might be just to use
something like 30 seconds for it, and convert that to ASNs.
> An important point there is that JN must write the counter in
> non-volatile memory after each join re-try.
Yes. Usually nodes do not join the network that often. As the joining
process most likely will take several tens of seconds, you might need
to increment joining counter once per minute, but after few tens of
tries you should really give up and realize you are not
authenticated... Of course if you use for example EAP-AKA challenge
response style, then there is no point of having such counter, or
actually if you use KMP betwen the JN and JA, that will also protect
against replays (at least most of the KMPs will provide that feature).
--
[email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
