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

Tero Kivinen <> Thu, 11 July 2019 22:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0544B12016B; Thu, 11 Jul 2019 15:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.419
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hRveSqs2U5iq; Thu, 11 Jul 2019 15:43:11 -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 3E7BC120159; Thu, 11 Jul 2019 15:43:11 -0700 (PDT)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTPS id x6BMh1rR001752 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jul 2019 01:43:01 +0300 (EEST)
Received: (from kivinen@localhost) by (8.15.2/8.14.8/Submit) id x6BMh1lw021352; Fri, 12 Jul 2019 01:43:01 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Fri, 12 Jul 2019 01:43:01 +0300
From: Tero Kivinen <>
To: "Pascal Thubert (pthubert)" <>,, "" <>, "" <>, Michael Richardson <>, "" <>, Thomas Watteyne <>, David Mandelberg <>
In-Reply-To: <>
References: <> <> <> <> <>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 19 min
X-Total-Time: 18 min
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: Thu, 11 Jul 2019 22:43:13 -0000

Tero Kivinen writes:
> I am now back from my eclipse trip, so I will try to answer some of
> 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

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

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