Hello Malisa: I went through the security section of minimal-security and found that the text below would be useful there to. Alt a pointer to the security section of the architecture would do once I incorporate some of the below. (Though I thought it did at a time) minimal-security does not indicate that the JRC should be aware of the network ASN to enable the protection that Tero is discussing below, does it?
All the best, Pascal > -----Original Message----- > From: David Mandelberg <[email protected]> > Sent: mardi 25 juin 2019 02:31 > To: Tero Kivinen <[email protected]>; Pascal Thubert (pthubert) > <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; > Thomas Watteyne <[email protected]>; Michael Richardson > <[email protected]>; Mališa Vučinić <[email protected]> > Subject: Re: [secdir] secdir review of > draft-ietf-6tisch-architecture-21 > > > > On 6/24/19 7:45 PM, Tero Kivinen wrote: > > Pascal Thubert (pthubert) writes: > >> Hello David: > >> > >> Many thanks for your review. I do hope that you found it interesting. > >> > >>> Sections 4.2.1 and 4.3.4 talk about the security of joining a > >>> network, and time synchronization, respectively. Do any of the > >>> security mechanisms in 4.2.1 rely on having an accurate clock? > >>> (E.g., to distrust old/expired keys.) Is time synchronization done > >>> before the join process, and is there any way to exploit time > >>> synchronization in order to cause a node to join a malicious > >>> network? > >> > >> This is really a MAC layer question for IEEE. I'm cc'ing Thomas who > >> was one of the inventors of TSCH, as well as Michael and Malisa who > >> led the join process study. > >> > >> Time synchronization (date): > >> -------------------------------------- > >> For all I know, the time sync is about giving a epoch time from > >> which an Absolute Slot Number (ASN, expressed in slot duration > >> e.g., > >> 10ms) is derived. ASN plays a key role as it is used in NONCE. An > >> attack that one could think of would be to fool the new node into > >> thinking that ASN is earlier. This could happen before the keys are > >> exchanged, or if an authorized peer is compromised. For the former, > >> I'll defer to the others to answer fully how we protect the new > >> comer. For the latter, 6TiSCH provides an additional protection > >> since we derive time from a RPL parent. RPL has its own > >> protections, some of them in the standard itself, some of them in > >> zerotrust papers that need publishing. > > > > In normal TSCH in 802.15.4 the joining node will listen to beacons > > sent by the nodes already part of the network, and they will find > > out the ASN from there. As they do not yet have keys for the network > > they cannot verify the message integrity code authenticating the > > beacon, and even if they did have the keys, they still cannot verify > > it as it could be replay by attacker. > > > > After they find out the ASN, they need to authenticate themself to > > the network using some mechanism outside the 802.15.4. This > > authentication step must be such that it cannot be replayed by > > attacker, i.e., they must not trust ASN giving them any protection. > > > > Note, that in general 802.15.4 TSCH DOES NOT provide replay > > protection at all. I.e., attacker can cause legimite node to > > retransmit its previous message by destroying ack, and upper layer > > protocol must provide way to detect replays and cope with them. > > > > During the authentication the JRC needs to provide the keying > > material to the joining node, but that does NOT provide protection > > against spoofed ASN. After the node has actual keys used in the > > network it still needs to verify the ASN by sending some message to > > JRC using authentication and verify that JRC replies to that. > > > > If this 2nd step is omitted attacker do following attack: > > > > Joining node (JN) attacker JRC > > <- beacon for ASN=23 <- beacon for ASN=44 > > See beacon > > from attacker, > > assume ASN=23. > > > > Auth->JRC > > (no security) Check authentication > > Return keys > > keys->JN > > > > Receive keys > > send first > > frame using > > keys using ASN=23-> > > > > > > Now, if JN is using extended address to generate nonce, the nonce > > will be different for all other nonces ever used, even the ASN is > > faked, and has been used before. On the other hand if JN also > > receives short address assignment from the JRC, JRC needs to make > > sure that short address has not been assigned to anybody else > > before, as if it was used by someone else, and frame sent by JN is > > encrypted, then attacker will now have two packets with same ASN, > > and short address, meaning same nonce, and it can now decrypt packets. > > Is this discussion of nonce reuse in any relevant documents already, > or is it something that should be added somewhere? > > > Note, that attacker might be able to replay valid ACKs for the frame > > sent by the JN, provided that the JRC (or whoever JN sent the > > message > > to) happened to ack message using the same ASN attacker faked for JN. > > > > If JN sends message to JRC which only JRC can reply, and uses wrong > > ASN, the JRC will not be able to decrypt/validate that frame because > > of wrong ASN in nonce, and will drop it silently, so if JN uses > > wrong ASN it might be getting ACKs, but it will not get any real > > reply frames back from real participants in the network. After it > > will not receive confirmation from JRC that it has proper keys and > > ASN, it knows something went wrong. > > > > > >> Time synthonization (precise tic, hourless) > >> -------------------------------------------------------- > >> This is the process whereby a node corrects its tic to realign with > >> the parent. ASN is not changed but the drift of crystals is > >> compensated. An attacker could try to inject a sense of time that > >> it slightly shifted to the point that the node lose sync with the > >> rest of the network (the guard time is like an event horizon). Then > >> again, RPL provides an additional protection on top of the MAC provisions. > > > > Those time syncronization IEs are also protected by MAC level > > authentication, so attackers who do not know the keys cannot > > generate them. Attackers who do know keys can do whatever they like > > anyways... > > > > Btw, I will be leaving for vacation tomorrow, so I might not be able > > to reply any messages related to this until I get back end of next > > week. > > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
