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

Tero Kivinen <kivinen@iki.fi> Mon, 24 June 2019 23:45 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 5FEEF12013E; Mon, 24 Jun 2019 16:45:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.42
X-Spam-Level:
X-Spam-Status: No, score=-3.42 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] 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 iYgdIIb2Bwpy; Mon, 24 Jun 2019 16:45:44 -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 3004B12007C; Mon, 24 Jun 2019 16:45:42 -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 x5ONjGM3013645 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Jun 2019 02:45:16 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x5ONjGjw021956; Tue, 25 Jun 2019 02:45:16 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23825.24715.882644.180316@fireball.acr.fi>
Date: Tue, 25 Jun 2019 02:45:15 +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: <MN2PR11MB35651735463F27A247B4B0F0D8E00@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <MN2PR11MB35651735463F27A247B4B0F0D8E00@MN2PR11MB3565.namprd11.prod.outlook.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 25 min
X-Total-Time: 24 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ShDlKrVzS5Hi09jmVQf1DZkBKsk>
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: Mon, 24 Jun 2019 23:45:48 -0000

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. 

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