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

[Tero Kivinen <[e-mail]>]

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]