Re: [6tisch] rekeying the 6TiSCH network

Benjamin Kaduk <kaduk@mit.edu> Thu, 22 August 2019 23:41 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81030120C7E for <6tisch@ietfa.amsl.com>; Thu, 22 Aug 2019 16:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 YZ_eIB6398tk for <6tisch@ietfa.amsl.com>; Thu, 22 Aug 2019 16:41:49 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9E1E8120180 for <6tisch@ietf.org>; Thu, 22 Aug 2019 16:41:49 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7MNfgLW018013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Aug 2019 19:41:44 -0400
Date: Thu, 22 Aug 2019 18:41:41 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Mališa Vučinić <malisa.vucinic@inria.fr>, Tero Kivinen <kivinen@iki.fi>, "6tisch@ietf.org" <6tisch@ietf.org>
Message-ID: <20190822234141.GV60855@kduck.mit.edu>
References: <MN2PR11MB356576EF7D90B7515043744DD8AB0@MN2PR11MB3565.namprd11.prod.outlook.com> <12588.1566331392@localhost> <MN2PR11MB356500E5F666044E0A04EC42D8AA0@MN2PR11MB3565.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <MN2PR11MB356500E5F666044E0A04EC42D8AA0@MN2PR11MB3565.namprd11.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/JQXme2IEuQddo_Gb_1i1kWZEiyc>
Subject: Re: [6tisch] rekeying the 6TiSCH network
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Aug 2019 23:41:54 -0000

On Wed, Aug 21, 2019 at 08:18:03AM +0000, Pascal Thubert (pthubert) wrote:
> Hello Michael
> 
> I agree that the details of how it is done in practice belong to minimal security.
> My expectation would be that we discuss times when it is appropriate to rekey, and what it takes to do that.
> 
> Out of my hat (but please come back with cases that I missed) I can see that:
>  
> - we need to rekey to expel undesired nodes.
> - we need to rekey if a short address is reassigned to avoid nonce-replay attacks with an ASN in the past
> - the ASN-based nonce never wraps in practice, but should we reset ASN -or allow it to go back in time - for whatever reason, we'd need to rekey as well.
> - based on Mirja's comment - seconded by Benjamin - minimal security should be a normative reference since it expands on the security considerations
> 
> I think it does not hurt to have a word on that in the architecture, even if more details are found in minimal security

That basically matches up with what I was thinking.
(And thanks to those who pointed out 802.15.9; I had forgotten that was an
option, albeit not necessarily a good one for all cases.)

-Ben