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

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

Hello Tero,

My understanding of this attack that you describe is that the attacker:

(1) can force the joined node to drop out of the network
(2) can force the pledge (ex. joined node) to select it as JP

(1) can be relaxed by assuming that the joined node can for any reason drop out of network. Another way to do this would be the selective jamming attack as discussed in draft-tiloca-6tisch-robust-scheduling. So this holds.

For (2), my understanding is that we have consensus that the protection is the existing mechanism specified in RFC8180 making the pledge wait for MAX_EB_DELAY before selecting a JP in order to have at least NUM_NEIGHBOURS_TO_WAIT distinct JP candidates, with legitimate ones advertising a value of ASN that is higher than that replayed by the attacker. What seems missing is a note in the minimal-security draft that the pledge MUST remain listening on the initial channel after receiving the first EB, in order not to enable the attacker to desync it from the network.

Did I get that wrong?

Mališa

> On 12 Jul 2019, at 00:43, Tero Kivinen <[e-mail]> wrote:
> 
> Tero Kivinen writes:
>> I am now back from my eclipse trip, so I will try to answer some of
>> these emails appeared while I was on vacation. 
> 
> And, now when I was thinking this more, I think there is actually
> bigger issue, as the first step of joining is done in clear, without
> any protection, so attacker does can simply act as man in the middle
> and convert ASNs as it feels like on the second run.
> 
> I.e., attacker first allows JN to join network normally and stores all
> packets JN sends and the associated ASN. When it finds packet with ASN
> z it wants to attack it forces JN to drop out of network (note, this
> packet it wants to attack can be much later, it does not have to be
> any of the first frames).
> 
> Then it sends a beacon with ASN of x, where x is close to the ASN of
> packet it wants to attack. JN then packet out to JRC with ASN of x +
> n1, the attacker can ack it, and then take that packet and replay that
> to the JRC at ASN of y (where x != y, and y > x). When JRC sends reply
> packet at y + m, the attacker can reply it back to JN with ASN x + n2
> and JN will accept it. Now JN has properly rejoined the network (both
> JN and JRC have authenticated themselves) and JN has keys K1, but
> thinks ASN is x instead of y. Next packet it sends will be encrypted
> with K1 and with ASN of x + n3. If x + n3 happens to be the ASN
> of z the attacker gets two frames encrypted with same key k1 and nonce
> generated from ASN z. If first try goes wrong it can allow JN to
> replay until x + n3 > z, and then it can start over again and adjust
> the starting value of x so it is better guess of how long JN will take
> when sending frames out... 
> 
> So I do not think we can do anything in the JN <-> JRC protocol to
> protect against this, the only real way to protect against this, is to
> send L2 authenticated (but not encrypted) frame after authentication
> phase from the JN to JRC containing random cookie, and require that
> JRC to echo it back to JN in similar authenticated but not encrypted
> frame.
> 
> I.e., make sure the joining process is (I leave out acks in this
> picture):
> 
> JN				JRC
> --				---
> security level 0
> joining request ->
> 
> 				<-- security level 0
> 				    joining reply
> 
> take L2 key K1 in use
> security level 1-3
> cookie request ->
> 
> 				<-- security level 1-3
> 				    cookie reply with same
> 				    cookie than in request.
> 
> And after this the JN is ready to start sending encrypted frames. 
> -- 
> [e-mail]
> 
> -- 
> MailScanner believes this is threat-free - www.ucg.ac.me
>