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

David Mandelberg <david@mandelberg.org> Tue, 25 June 2019 00:30 UTC

Return-Path: <david@mandelberg.org>
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 B25DE120221 for <secdir@ietfa.amsl.com>; Mon, 24 Jun 2019 17:30:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.org
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 iAYoHlyJZTEH for <secdir@ietfa.amsl.com>; Mon, 24 Jun 2019 17:30:48 -0700 (PDT)
Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 37C611201F2 for <secdir@ietf.org>; 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: smtp03.rcn.cmh.synacor.com header.DKIM-Signature=@mandelberg.org; dkim=pass
Authentication-Results: smtp03.rcn.cmh.synacor.com smtp.mail=david@mandelberg.org; spf=softfail; sender-id=softfail
Authentication-Results: smtp03.rcn.cmh.synacor.com header.from=david@mandelberg.org; sender-id=softfail
Authentication-Results: smtp03.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN)
Received: from [209.6.43.168] ([209.6.43.168:57964] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from <david@mandelberg.org>) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 2B/35-13517-43B611D5; Mon, 24 Jun 2019 20:30:44 -0400
Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 28BA91C6033; Mon, 24 Jun 2019 20:30:43 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; 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 <kivinen@iki.fi>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: "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>
References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <MN2PR11MB35651735463F27A247B4B0F0D8E00@MN2PR11MB3565.namprd11.prod.outlook.com> <23825.24715.882644.180316@fireball.acr.fi>
From: David Mandelberg <david@mandelberg.org>
Message-ID: <5229f400-076c-80e3-e0dc-a7cf3998abed@mandelberg.org>
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: <23825.24715.882644.180316@fireball.acr.fi>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/pGTkSKeif3UiAvfXT1nupz3THMA>
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: 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.
>