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

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Jul 2019 00:01:25 +0300

I am now back from my eclipse trip, so I will try to answer some of
these emails appeared while I was on vacation. 

Pascal Thubert (pthubert) writes:
> > 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
> 
> This is assuming that the attacker is not attacking the same device
> twice, isn't it?

True, and actually the easiest thing is to attack same JN again. This
example assumes that slotframe is 100 and there is one shared slot in
slotframe which is the first slot there, thus if asn % 100 then that
is shared slot, used for beacons, and joining messages etc.

JN    	  	   attacker    	     	JRC
--		   -------		---
					<-- beacon with ASN=1000, Src=JRC
                   save beacon
receive beacon
wait for shared next
slot, send joining
request

clear text
joining request
ASN=1100, Src=JN -->

					<-- Enh-Ack ASN=1100, Src=JRC

receive ack, wait
for reply

					<-- clear text joining reply ASN=1200,
					    Src=JRC
		   save joining reply

receive reply, JN 
has joined network,
receives L2 key K1,
starts using it.
sends Enh-Ack -->

JN starts some 
upper layer protocol
procedure having 
some secret information
proteced by L2 security
with K1, ASN=2200, Src=JN -->
     	 	   save message
					<-- Enh-Ack ASN=2200, Src=JRC
		   save copy of Enh-ack,
		   but destroy it so JN does not
		   get ack, thus JN will retranmits

JN waits for random
amount of shared slots
and then retransmits previous
packet with new ASN, i.e.,
encrypts packet again with K1,
ASN=2900, Src=Jn

		   save another copy with another ASN.
		   These are just to make attacker easier
		   later, as attacker might want to
		   have multiple copies with different
		   ASNs just in case JN does not happen to use
		   same ASN next time than it used last time.
		   
		   After enough copies of messages
		   attacker can kill JN from network
		   and cause it to reboot

JN reboots, starts over

JN listens beacons
		   <-- replays beacon
		       with ASN=1000,
		       Src=JRC, on channel X

		       		   	<-- beacon with ASN=9000,
		       		   	    Src=JRC, on channel Y,
		       		   	    where X and Y are not same
		       		   	    unless ASNs % channels
		       		   	    happen to match, attacker
		       		   	    can make them so that they
		       		   	    do not match, which means
		       		   	    JN will never hear any
		       		   	    real packets as it is
		       		   	    using wrong offset to
		       		   	    hopping sequnce.

clear text
joining request
this assumes this
is exactly same
request than last
time, i.e., the
persistent counter
in joining
request did not get
incremented on the failed
attempt to join, or
at least same reply is
acceptable to JN.
ASN=1100, Src=JN -->
			 
		   <-- attacker replies with Enh-Ack
		       ASN=1100, Src=JRC	

receive ack, wait
for reply
	   
		   <-- attacker replays
		       joining reply ASN=1200, Src=JRC

receive reply, JN 
has joined network,
receives L2 key K1,
starts using it.
sends Enh-Ack -->

JN starts some 
upper layer protocol
procedure having 
some secret information
proteced by L2 security
with K1, ASN=2200, Src=JN -->

     	 	   <-- attacker replays with stored
		       Enc-Ack with ASN=2200, Src=JN.
		       This is just to allow JN to go
		       forward.

JN sends next request
protected by L2 security
with K1, ASN=2900, Src=JN -->

     	 	   And now attacker got two
		   different messages encrypted with
		   same key K1, with same nonce (ASN=2900),
		   so it can just xor them together and
		   get xor of plain text packets, thus can
		   perhaps find out secret data from
		   one of the packets. If first ASN does
		   happen to match, it will wait for next
		   retransmission and at some point attacker
		   might see ASN with packet which it stored
		   earlier. If this does not happen, it will simply
		   cause JN to start over again, and repeat the
		   process.

> > 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.
> 
> That's unless new keys are given if the short address is reattributed, correct?

Yes, but as I shown above the attack also works while using extended
addresses, but then it works against the same node. 

> > 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.
> 
> Your mean that the faked ASN is only slightly in the future, so the
> attacker can repeat messages from the pledge after that delay?

No, the attacker can collect copies of Enh-Acks from the previous
packet exchanges between JRC and JN. Actually all the joining traffic
happens happens without L2 security, so attacker can simply send
normal non authenticated Enc-Acks back. Only place where the attacker
wants to replay saved encrypted Enc-Acks are the first real protocol
packet exachanges.

With short addresses this is can be easier, than with extended
addresses, but if short addresses are never reused with same key, then
that should block short address issues. This attack against same node
do require that JN will accept replayed reply from JRC, and I do not
think it will, if I remember there was counter in the oscore or
something, that  got incremented for every request, and JN would check
that it will not accept replayed replies. Or was it so that only JRC
checks for replays?
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Jul 2019 00:14:05 +0300

Pascal Thubert (pthubert) writes:
>    With 6TiSCH, the pledge discovers a tentative ASN in beacons sent by
>    nodes that have already joined the network.  As the pledge is not in
>    possession of Link-Layer keys for the visited network, it cannot
>    verify the message integrity code (MIC) authenticating the beacon.
>    Even if it did have the keys, it still could not verify the beacon as
>    it could be a replay by an attacker and thus could still announce an
>    ASN that represents a time in the past.  That time would match a
>    valid timeslot it if is correct modulo the number of channels used for
>    hopping.

Note, that attacker can pick time, and channel correctly so that it
will always match. I.e., if he wants to reply beacon with ASN=1235 and
that was sent on channel X, it simply needs to replay that same
ASN=1235 on channel X, regardless what current ASN and channel would
be for others in the network. It is actually beneficial for it to use
some offset, so JN will not accidently see any real messages...

Most likely JN will start listening beacons on channel X, then if does
not hear anything for some time, it moves to X+1 etc. Most likely it
will stay on channel X so long that it will hear beacon from there. So
attacker stores that beacon on channel X and the ASN is so that it is
assuming channel X for hopping.

Now if attacker retransmits this out on channel X immediately when it
assumes JN is listening, JN will pick it, and will then pick wrong
offset for channel hopping.

So, that sentence about Time and module to number of channels, is not
useful. 

>    After obtaining that tentative ASN, the pledge authenticates itself
>    to the network using some mechanism outside of IEEE Std 802.15.4.
>    With 6TiSCH, a Join Proxy (JP) helps the pledge for the join
>    procedure by relaying the link-scope Join Request over the IP network
>    to a Join Registrar/Coordinator (JRC) that can authenticate the
>    pledge and validate that it is attached to the appropriate network.
>    As a result of this exchange the pledge is in possession of a Link-
>    Layer material including a key and a short address, and assuming that
>    the ASN is correct, all traffic can be secured at the Link-Layer.
> 
>    This authentication steps must be such that they cannot be replayed
>    by an attacker, and it must not depend on th tentative ASN being
>    valid.  Note that IEEE std. 802.15.4 TSCH does not provide replay
>    protection at all, and that for instance attacker can cause a
>    legitimate node to retransmit a previous message by destroying an
>    ack. It results and upper layer protocol must provide a way to detect
>    replayed messages and cope with them.
> 
>    During the authentication the keying material that the pledge obtains
>    from the JRC does NOT provide protection against spoofed ASN.  Once
>    the pledge has obtained the keys to use in the network, it still
>    needs to verify the ASN.  If the nonce used in the Layer-2 security
>    derives from the extended (MAC-64) address, then replaying the ASN
>    alone cannot enable a nonce-reuse attack unless the same node is
>    attacked twice and loses all state in-between.  But if the nonce
>    derives from the short address (e.g., assigned by the JRC) then the
>    nonce-reuse attacks are possible, and the JRC must ensure that it
>    never assigns short addresses that were already given to this or
>    other nodes with the same keys.
> 
>    At that point, an additional step may be required to ensure that the
>    ASN is correct.  For instance, the pledge could perform a first
>    exchange with a peer node that is trusted and has already joined,
>    e.g., its RPL time parent, and the message should not be encrypted
>    but only authenticated at the Link-Layer.  The request from the
>    pledge should contain a nonce with a random part that is not ASN, and
>    the authenticated response should contain the current ASN and echo
>    the nonce.

Sending ASNs in the mssage is almost impossible, as upper layer does
not have any idea what ASN will be used to send message out. It does
not know when the next slot to the JN will be, and it does not know
whether that slot will be free etc.

Because of this I think it is better to use some other method, i.e.,
if JN just generates random cookie and sends that to JP/JRC, and
JP/JRC will then echo that same cookie back then JN will know that
exchange is fresh, and if that was authenticated using L2 key K1, then
ASN was implictly verified also, as JP/JRC who do know correct ASN,
will drop the incoming frame as it will have wrong MIC because of
wrong nonce.
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 11 Jul 2019 11:31:34 +0000

All good, Tero.

I think we are in perfect line. If you can find the time please have a look at https://tools.ietf.org/html/draft-ietf-6tisch-architecture-24#section-6 to make sure all is correct, I think it is.
At this point it is up to Malisa to add more details in the security section of minimal security and I trust that this thread helps.

All the best,

Pascal

> -----Original Message-----
> From: Tero Kivinen <[email-masked]>
> Sent: mercredi 10 juillet 2019 23:14
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: David Mandelberg <[email-masked]>; Mališa Vučinić
> <[email-masked]>; Michael Richardson <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]
> Subject: RE: secdir review of draft-ietf-6tisch-architecture-21
> 
> Note, that attacker can pick time, and channel correctly so that it will always
> match. I.e., if he wants to reply beacon with ASN=1235 and that was sent on
> channel X, it simply needs to replay that same
> ASN=1235 on channel X, regardless what current ASN and channel would be
> for others in the network. It is actually beneficial for it to use some offset, so
> JN will not accidently see any real messages...
> 
> Most likely JN will start listening beacons on channel X, then if does not hear
> anything for some time, it moves to X+1 etc. Most likely it will stay on channel
> X so long that it will hear beacon from there. So attacker stores that beacon
> on channel X and the ASN is so that it is assuming channel X for hopping.
> 
> assumes JN is listening, JN will pick it, and will then pick wrong offset for
> channel hopping.
> 
> Sending ASNs in the mssage is almost impossible, as upper layer does not
> have any idea what ASN will be used to send message out. It does not know
> when the next slot to the JN will be, and it does not know whether that slot
> will be free etc.
> 
> Because of this I think it is better to use some other method, i.e., if JN just
> generates random cookie and sends that to JP/JRC, and JP/JRC will then echo
> that same cookie back then JN will know that exchange is fresh, and if that
> was authenticated using L2 key K1, then ASN was implictly verified also, as
> JP/JRC who do know correct ASN, will drop the incoming frame as it will have
> wrong MIC because of wrong nonce.
> --
> [email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 12 Jul 2019 01:43:01 +0300

> 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. 
-- 
[email-masked]

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 12 Jul 2019 11:04:13 +0200

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 <[email-masked]> wrote:
> 
> Tero Kivinen writes:
> MailScanner believes this is threat-free - www.ucg.ac.me
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 14 Jul 2019 17:08:58 -0400

Tero Kivinen <[email-masked]> wrote:
    > Because of this I think it is better to use some other method, i.e., if
    > JN just generates random cookie and sends that to JP/JRC, and JP/JRC
    > will then echo that same cookie back then JN will know that exchange is
    > fresh, and if that was authenticated using L2 key K1, then ASN was
    > implictly verified also, as JP/JRC who do know correct ASN, will drop
    > the incoming frame as it will have wrong MIC because of wrong nonce.

I think that we can do this with a (unicast)DIS/DIO message which is worth
sending anyway.  We need to find a container for the nonce, but I think that
is easy.

I'm concerned about recovery when the JN has latched onto the wrong beacon.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sun, 14 Jul 2019 17:21:45 -0400

Tero Kivinen <[email-masked]> wrote:
    > 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...

I'm gonna have to draw this this to get it all, but I think that I see the
point.  If I understood correctly, the attacker can get the JN to be behind
in the ASN game such that it can now see a packet encrypted by the JP and JN
using the same ASN.  It does this by storing legitimate EBs, and replaying
them at a time such that the JN is offset, and the attacker relays the packets.

    > 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 think maybe somewhere here you mean JP rather than JRC, as the JN and
the JRC are not connected at L2, except via the JN.

    > I.e., make sure the joining process is (I leave out acks in this

"security level X" <--- this is an IEEE802.15.4 thing, not a new creation,
right?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Jul 2019 18:12:27 +0300

Mališa Vučinić writes:
> 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. 

Note, that JN cannot yet verify the EBs, and if you take the one with
largest ASN, that allows very easy way for attacker to cause DoS,
i.e., just send ASN of 0xffffff0000 which is very big, and all new
nodes will want to join that.

Also there is no way of knowing whether there is one or multiple TSCH
networks in the same place. One of them could be using ASN of
0x0000123456 and the other might be using 0x0087654321. We do want to
the node to be able to try both.... I do not think the node can really
pick the network based on the EBs properly, and whatever the node is
doing it mught make things worse and might open new attacks.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Jul 2019 18:19:59 +0300

> "security level X" <--- this is an IEEE802.15.4 thing, not a new creation,

Yes, i.e., Table 9-6 of 802.15.4-2015 section 9.4.1.1:

Security  Security       Security     Data	  Data	    MIC length
level 	  level field	 attributes   confiden-   authen-   (octets)
	  b2 b1 b0 	 	      tiality	  ticity
  0 	  000 		 None 	      OFF 	  NO	    0
  1 	  001 		 MIC-32       OFF 	  YES	    4
  2 	  010 		 MIC-64       OFF 	  YES 	    8
  3 	  011 		 MIC-128      OFF 	  YES 	    16
  4 	  100		 Reserved     Reserved	  Reserved  Reserved
  5 	  101 		 ENC-MIC-32   ON 	  YES 	    4
  6 	  110 		 ENC-MIC-64   ON 	  YES 	    8
  7 	  111 		 ENC-MIC-128  ON 	  YES 	    16

I.e., level 0 is no security, levels 1-3 are for authentication only
and levels 5-7 is authentication and encryption both. Level 4 used to
be encryption only, but that was removed in 2015 revision, as there is
huge security issues with it.
-- 
[email-masked]