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

Mališa Vučinić <malisa.vucinic@inria.fr> Mon, 12 September 2022 13:44 UTC

Return-Path: <malisa.vucinic@inria.fr>
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 74BCFC14CF09 for <6tisch@ietfa.amsl.com>; Mon, 12 Sep 2022 06:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.103
X-Spam-Level:
X-Spam-Status: No, score=-7.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=inria.fr
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCjqGk_LGg-Q for <6tisch@ietfa.amsl.com>; Mon, 12 Sep 2022 06:44:13 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 3C51DC14F75F for <6tisch@ietf.org>; Mon, 12 Sep 2022 06:44:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=l77kUgnnH9v708l+tG8PKGbGAVS8a3zq/jsE4Ad19O4=; b=dG9Dc7vOszAxMnqmqeKDzVPFVPUc37CyAHupkg+ooexZTSDFgrKLMbUg wHEYOJ05qwpxvSK6z7RCepLZ9wmGgAaRAn0IMOjBhZO0MDDHCm036SNDP Y/K1l7MfB1uNj/nQx6FUURCcfFcFCeiWbx7BNbiMxInrb8eqE5M87t37X k=;
Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=malisa.vucinic@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr
X-IronPort-AV: E=Sophos; i="5.93,310,1654552800"; d="scan'208,217"; a="23484358"
Received: from wifi-pro-83-103.paris.inria.fr (HELO smtpclient.apple) ([128.93.83.103]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Sep 2022 15:44:10 +0200
From: Mališa Vučinić <malisa.vucinic@inria.fr>
Message-Id: <8F30D9EE-B8C8-422C-B66F-CF2B1A28B498@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D277F19F-292D-4833-8E72-BD15F6553B8B"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Mon, 12 Sep 2022 15:44:09 +0200
In-Reply-To: <YxxnXvHE3WnCt/UO@hephaistos.amsuess.com>
Cc: 6tisch@ietf.org, Michael Richardson <mcr@sandelman.ca>
To: Christian Amsüss <christian@amsuess.com>
References: <YUcakTFqibo5wEfe@hephaistos.amsuess.com> <102718.1632080924@dooku> <YUhQp3wQ6O3qXp6R@hephaistos.amsuess.com> <618FD3B4-2935-4D9E-9F96-B63454890B50@inria.fr> <YUhoXt7T8bLAU2gZ@hephaistos.amsuess.com> <E4FD542C-3751-4C15-8716-06F9C618C2F9@inria.fr> <YxxnXvHE3WnCt/UO@hephaistos.amsuess.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/wIwnineZAaoyESSHGJ9Xp-0YPsI>
Subject: Re: [6tisch] Extending CoJP (minimal-security) for non-6TiSCH 802.15.4 networks
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.39
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, 12 Sep 2022 13:44:18 -0000

Hi Christian,

> On 10 Sep 2022, at 12:30, Christian Amsüss <christian@amsuess.com> wrote:
> 
> * Do RFCs 9030/9031 allow that a device uses an explicit frame counter,
> which it increments in its own pace?

As mentioned, we’ve made every attempt to make RFC 9031 applicable to non-TSCH use cases, as well. Construction of the link-layer nonce is not mentioned in RFC 9031 and, as Tero notes, the procedure is defined by IEEE 802.15.4. That means that we can use RFC 9031 to distribute the keys with Key Usage set to the values from Table 6. The rekeying procedure also does not depend on the common notion of time that is specific to 6TiSCH/TSCH, so that also applies.

> 
>  * If yes, shouldn't there be more stern words in 9031 about allowing a
>    new key to be used with the same EUI-64 (considering that the device
>    may not get a short identifier)?

As Tero notes, this procedure is defined by IEEE 802.15.4 standard: Once a new key is provisioned to the device, the device resets its frame counter. 

> 
>    (Plus all concerns about the use of OSCORE Appendix B.2 or its
>    replacement KUDOS would be relaxed, because if a device can use its
>    own frame counter, it could use the same facilities to not lose its
>    OSCORE sender sequence number).

I would say that the text on the use of OSCORE Appendix B.2 in RFC 9031 still applies for non-TSCH use cases as 8.3.3. talks about a particular case when the JRC fails and looses the mutable security context parameters. JRC is not part of the mesh and we’ve never considered the JRC hosted at a constrained device. That means that the JRC does not follow 802.15.4 security procedures as it is likely using another Layer 2 technology.

Mališa