Re: [6tisch] Extending CoJP (minimal-security) for non-6TiSCH 802.15.4 networks

Christian Amsüss <christian@amsuess.com> Mon, 20 September 2021 10:54 UTC

Return-Path: <christian@amsuess.com>
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 7BCA63A0964 for <6tisch@ietfa.amsl.com>; Mon, 20 Sep 2021 03:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mTe7z1PPrwNF for <6tisch@ietfa.amsl.com>; Mon, 20 Sep 2021 03:54:27 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FBC3A0963 for <6tisch@ietf.org>; Mon, 20 Sep 2021 03:54:27 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7AFAA4168D; Mon, 20 Sep 2021 12:54:24 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 03D69D7; Mon, 20 Sep 2021 12:54:23 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:d6f8:77c2:2f6a:14e7]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id AB88A10A; Mon, 20 Sep 2021 12:54:22 +0200 (CEST)
Received: (nullmailer pid 354442 invoked by uid 1000); Mon, 20 Sep 2021 10:54:22 -0000
Date: Mon, 20 Sep 2021 12:54:22 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Mališa Vučinić <malisa.vucinic@inria.fr>
Cc: Michael Richardson <mcr@sandelman.ca>, 6tisch@ietf.org
Message-ID: <YUhoXt7T8bLAU2gZ@hephaistos.amsuess.com>
References: <YUcakTFqibo5wEfe@hephaistos.amsuess.com> <102718.1632080924@dooku> <YUhQp3wQ6O3qXp6R@hephaistos.amsuess.com> <618FD3B4-2935-4D9E-9F96-B63454890B50@inria.fr>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="DKBMpUOqhpZzMv/C"
Content-Disposition: inline
In-Reply-To: <618FD3B4-2935-4D9E-9F96-B63454890B50@inria.fr>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/NsZBMm-vPFnPVRsXx6bRVUZ5-mg>
Subject: Re: [6tisch] Extending CoJP (minimal-security) for non-6TiSCH 802.15.4 networks
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: Mon, 20 Sep 2021 10:54:33 -0000

On Mon, Sep 20, 2021 at 12:15:27PM +0200, Mališa Vučinić wrote:
> As you could probably see from RFC9031, we did make an attempt to
> separate TSCH-specific from generally-applicable text,

yes, thanks for that -- if that were not done, the endeavour would be a
lot harder.

> The use cases you mention are bound to 15.4 radios. Do you see this
> effort potentially useful for other low-power radio technologies?

I'm not sufficiently familiar with other technologies' security
mechanisms; I'm struggling enough with in-15.4 use.

I originally thought I'd just take a K1 and K2 and the existing key
usage table, but these are actually 6TiSCH specific. It'd be quite a
waste to repeat the 14 modes to say the same about any other MAC
(especially as using the K1/K2 separation probably makes sense there
too); maybe the other parameters can skew the semantics. ("If this
parameter is present, keys are used for 802.15.4 as in the given 6TiSCH-
key usage, but with the adaptations described in this document").

A non-802.15.4 network would certainly need new values there, I hope to
manage without to keep overhead low.

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom