[6tisch] FW: [secdir] secdir review of draft-ietf-6tisch-architecture-21

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]>
> Sent: mardi 25 juin 2019 02:31
> To: Tero Kivinen <[e-mail]>; Pascal Thubert (pthubert) 
> <[e-mail]>
> Cc: [e-mail]; [e-mail]; 
> [e-mail];
> Thomas Watteyne <[e-mail]>; Michael Richardson 
> <[e-mail]>; Mališa Vučinić <[e-mail]>
> 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.
> >