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

David Mandelberg <> Tue, 25 June 2019 00:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B25DE120221 for <>; Mon, 24 Jun 2019 17:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iAYoHlyJZTEH for <>; Mon, 24 Jun 2019 17:30:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37C611201F2 for <>; Mon, 24 Jun 2019 17:30:46 -0700 (PDT)
X_CMAE_Category: , ,
X-CNFS-Analysis: v=2.2 cv=aKGykv1m c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=dq6fvYVFJ5YA:10 a=bmmO2AaSJ7QA:10 a=i4AJ2F3t6UaJ7r-B2GQA:9 a=jsRDIoaMY1qESba-:21 a=4RfiEPLOIeMVhr81:21 a=q1x0MaV35-B7teMi:21 a=QEXdDO2ut3YA:10
X-CM-Score: 0
X-Scanned-by: Cloudmark Authority Engine
X-Authed-Username: ZHNlb21uQHJjbi5jb20=
Authentication-Results:; dkim=pass
Authentication-Results:; spf=softfail; sender-id=softfail
Authentication-Results:; sender-id=softfail
Authentication-Results:; auth=pass (LOGIN)
Received: from [] ([] by (envelope-from <>) (ecelerity r(Core: with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 2B/35-13517-43B611D5; Mon, 24 Jun 2019 20:30:44 -0400
Received: from [] (DD-WRT []) by (Postfix) with ESMTPSA id 28BA91C6033; Mon, 24 Jun 2019 20:30:43 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201903; t=1561422643; bh=QT9ECKM4HatKLifWDr9rUeOWW/+Kw3lFa+7Qwq3cCd8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=YsBsJNWl9sAOiUrGG9tlFLENWaDxPsnqx6Aft2wihSRdEzereQz1sUPPbAsq5dyGa yNXkcf22na2PabNezpUpYTF9euseTFa4YOj4Jpx9P9JuYxpbtmkyX5ZmKwjLZ9AR1/ cb98iCCKpDA/6N9qt3SBZUCJaQgpkN4FBF0e3u1Mhbq+hh0275kMpzhkwbpFt1oRWP XqHXg4VQvPCPZSmzly2mkU+yHV/oPZuih7oIELubCx+Da93ikAKAXAysiK4o+WkQAK cX/ClJ395WwGi+Lb4GVHJtLbvRKLk7MMwGx+0+FqYH9ZsDMVj7hIeSg0k6SNHwTxZV RtOzMiLzRVizg==
To: Tero Kivinen <>, "Pascal Thubert (pthubert)" <>
Cc: "" <>, "" <>, "" <>, Thomas Watteyne <>, Michael Richardson <>, Mališa Vučini ć <>
References: <> <> <>
From: David Mandelberg <>
Message-ID: <>
Date: Mon, 24 Jun 2019 20:30:40 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Jun 2019 00:30:50 -0000

On 6/24/19 7:45 PM, Tero Kivinen wrote:
> 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.

Is this discussion of nonce reuse in any relevant documents already, or 
is it something that should be added somewhere?

> 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.