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

Tero Kivinen <kivinen@iki.fi> Wed, 10 July 2019 21:01 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F904120025; Wed, 10 Jul 2019 14:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.419
X-Spam-Level:
X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AE0f2Q3c2HZ; Wed, 10 Jul 2019 14:01:40 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01AC4120147; Wed, 10 Jul 2019 14:01:39 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x6AL1P0e027682 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jul 2019 00:01:25 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6AL1PuI028215; Thu, 11 Jul 2019 00:01:25 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23846.21029.236657.158497@fireball.acr.fi>
Date: Thu, 11 Jul 2019 00:01:25 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: David Mandelberg <david@mandelberg.org>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-6tisch-architecture.all@ietf.org" <draft-ietf-6tisch-architecture.all@ietf.org>, Thomas Watteyne <thomas.watteyne@inria.fr>, Michael Richardson <mcr+ietf@sandelman.ca>, Mali�a Vu�ini� <malisav@ac.me>
In-Reply-To: <MN2PR11MB35655F77D328CD9B27029413D8E30@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <MN2PR11MB35651735463F27A247B4B0F0D8E00@MN2PR11MB3565.namprd11.prod.outlook.com> <23825.24715.882644.180316@fireball.acr.fi> <MN2PR11MB35655F77D328CD9B27029413D8E30@MN2PR11MB3565.namprd11.prod.outlook.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 53 min
X-Total-Time: 54 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/19pISsknOmwpDxu4jQ6uyp-pSiM>
Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2019 21:01:44 -0000

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?
-- 
kivinen@iki.fi