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

[Mališa Vučinić <[e-mail]>]

Pascal, Tero,

The issue raised seems valid and going through minimal-security and the MSF draft it seems that some clarification is needed. We purposely avoided keeping the network notion of time at the JRC in order to facilitate deployments where JRC is outside of the local network and is managing multiple 6tisch networks. I do not believe we want to change that, as it would be quite challenging to require the synchronization of the JRC with each 6tisch network. 

Instead, as with traditional TSCH, the joined node can obtain its time information from its time source neighbor, i.e. RPL preferred parent, by triggering an exchange of link-layer frames with L2 security features enabled. The MSF draft already mandates that the first outgoing message from the joined node after joining is the 6P ADD message to its preferred parent, which consequently gets protected with L2 security. What needs to be specified clearly is that this first 6P exchange should not be encrypted but only authenticated at L2. Upon successful completion of the first 6P exchange with its time (routing) parent, the joined node obtains a negotiated cell and as a side effect proves freshness of the ASN used. 

What seems missing is some text in minimal-security adding guidance for other scheduling function and stressing this issue beyond the text in the last paragraph of Section 9 of draft-ietf-6tisch-minimal-security-11 that is rather vague.

Mališa

> On 25 Jun 2019, at 09:29, Pascal Thubert (pthubert) <[e-mail]> wrote:
> 
> 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.
>>> 
> 
> -- 
> MailScanner believes this is threat-free - www.ucg.ac.me
>