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

Tero Kivinen <kivinen@iki.fi> Tue, 25 June 2019 11:05 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 41E251205B5; Tue, 25 Jun 2019 04:05:19 -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 36OnLBfNttB3; Tue, 25 Jun 2019 04:05:16 -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 59BC01204ED; Tue, 25 Jun 2019 04:05:14 -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 x5PB4Ylh024389 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Jun 2019 14:04:34 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x5PB4X0H007415; Tue, 25 Jun 2019 14:04:33 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23825.65473.306890.930708@fireball.acr.fi>
Date: Tue, 25 Jun 2019 14:04:33 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: David Mandelberg <david@mandelberg.org>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "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: <5229f400-076c-80e3-e0dc-a7cf3998abed@mandelberg.org>
References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <MN2PR11MB35651735463F27A247B4B0F0D8E00@MN2PR11MB3565.namprd11.prod.outlook.com> <23825.24715.882644.180316@fireball.acr.fi> <5229f400-076c-80e3-e0dc-a7cf3998abed@mandelberg.org>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 2 min
X-Total-Time: 2 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/AE1u8LddOwmjTM4ntJhmPTw5gzI>
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 11:05:23 -0000

David Mandelberg writes:
> > 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?

All 802.15.4 documents assume that ASN is already distributed securely
to the nodes having keys. I.e., this attack is not considered by those
documents, as it is outside the scope of them...
-- 
kivinen@iki.fi