IETF Logo Mail Archive

Re: [6tisch] rekeying the 6TiSCH network

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 21 August 2019 08:18 UTC

Return-Path: <pthubert@cisco.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 731F6120122 for <6tisch@ietfa.amsl.com>; Wed, 21 Aug 2019 01:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MWKSIowg; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Gka5xqcJ
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 Rbvc2_BcfA3R for <6tisch@ietfa.amsl.com>; Wed, 21 Aug 2019 01:18:24 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B80912081F for <6tisch@ietf.org>; Wed, 21 Aug 2019 01:18:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3744; q=dns/txt; s=iport; t=1566375504; x=1567585104; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2petSevbddZt6sT+cDrIMVjY0pTOJuvQRroSLKC/PNA=; b=MWKSIowgpwKmRrzSopvEqhtreNdXUsdxC6tP+WPENOTj2SlRcBr/AnZs mIznUzmMEwUgAP9lCAQADi3dd8Dga89wlNPFbwmcHwUXRIlF6QvjKwHEe BNKpt4l9HLdL/XgWgYw6/MnGI8PBJCLwxvsYt8lJwyQiT+1t+D6NLer0n I=;
IronPort-PHdr: 9a23:f+DqyhCpDiJ1+VqDpnaxUyQJPHJ1sqjoPgMT9pssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHwQAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DRAQAN/lxd/5ldJa1lDg0BAQEBAwEBAQcDAQEBgWeBRVADgUIgBAsqCoQVg0cDintNgg+XZYFCgRADVAkBAQEMAQEtAgEBgUuCdAIXgj4jOBMCBQEBBAEBAwEGBG2FJwyFSgEBAQEDEhERDAEBOAsEAgEIEQEDAQEBAgImAgICMBUCBggBAQQBEggahGsDHQECn08CgTiIYXOBMoJ7AQEFhRkYghQJgQwohHSGdRiBQD+BV4JMPoQtGYMJMoImjB0SgmicQgkCgh2UVIIxhzCOZY1bgTaWWAIEAgQFAg4BAQWBZyGBWHAVgyeCQgwXg0+KGDtygSmMGgGBIAEB
X-IronPort-AV: E=Sophos;i="5.64,412,1559520000"; d="scan'208";a="311772302"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Aug 2019 08:18:23 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x7L8IM1P032739 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Aug 2019 08:18:22 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Aug 2019 03:18:22 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 21 Aug 2019 04:18:21 -0400
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 21 Aug 2019 03:18:21 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FJz8ZpnBgJdu02Yle2JOIQmsSZgHM5pUmujDbcSz7+duTJKcdJZvTMmvaj5KNa150x+XJQMLtgz2PyVAqrSHBmWAFzsRMIN0oEbYop+6XV3dUhAaKTdgi6AopPCssJbzDlAsYvV+Zy+aBxrNz5gQOKJd9OpY2QdZXs7WqlmgN1CxFVAlnfE6+1SPajg6jiv6wLPkPG5BNatNeOMzVb0B2M9hS+zlCOfahm1voxy0CFaXFN/uvBtH5I6ylhb901BrXhZ4z0j81SHgIdbTXQQJrF7MLd7LsfGzc4C0Lzz7YgdzogsyccJY74foLAfRMOkYb8yHeAdjD7Y76HLkZPem/w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2petSevbddZt6sT+cDrIMVjY0pTOJuvQRroSLKC/PNA=; b=oBduNpXImEletwdcH6heCyvqIlCRAp0QYVUkHuDTA5PfILmCxptsOKj72JcL9WSzr2zQNhCAHPWMG3+HjkLgGqeSkX46N79vHr5PIRw4qnj+lxLQ0ZS7vef6F0gHEPnXGDIr+MZ4JPlG2l0feGb7VZmx9ydQnG46w4ebz14PN3rzZlVVi4G55F5vXjhmTpR0xJcpPz054L6jSa+1PrMfzPQXcYuYMa8vAZIGRdF/4SdmUH+CF7zAwrk4fhGxpNtN3x85BDgtZBjyBZNCRjT1PUu45AFo7qYI1PNV7FUWl023+eeypIl8HkXVHo5RmaLURm2YwzhPFpFyR3HgU5tqWA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2petSevbddZt6sT+cDrIMVjY0pTOJuvQRroSLKC/PNA=; b=Gka5xqcJOGqNAe0w+XAOHu0CmiWV+D4/0P6FsxxEjKdCw/29uGhcbhKfFnCzZbTcBZ6ntegDQAcg4H6hat1iGqLHSHrlvBWu2G9x9U9pF0l9BpvOwTvCiIi/ya7cYb7W1Ytcq/ihGL+Fv3UjFfENFhjJiYAOz2CVXV41GjGUcgg=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3726.namprd11.prod.outlook.com (20.178.251.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2178.19; Wed, 21 Aug 2019 08:18:20 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::89cf:9d:8a75:266e%3]) with mapi id 15.20.2178.018; Wed, 21 Aug 2019 08:18:20 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Benjamin Kaduk <kaduk@mit.edu>, Mališa Vučinić <malisa.vucinic@inria.fr>, Tero Kivinen <kivinen@iki.fi>, "6tisch@ietf.org" <6tisch@ietf.org>
Thread-Topic: [6tisch] rekeying the 6TiSCH network
Thread-Index: AdVXckOY/3jnRzg5QPaDNBx+4YyLTAAIAfYAABkH/CA=
Date: Wed, 21 Aug 2019 08:18:03 +0000
Deferred-Delivery: Wed, 21 Aug 2019 08:17:48 +0000
Message-ID: <MN2PR11MB356500E5F666044E0A04EC42D8AA0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB356576EF7D90B7515043744DD8AB0@MN2PR11MB3565.namprd11.prod.outlook.com> <12588.1566331392@localhost>
In-Reply-To: <12588.1566331392@localhost>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [173.38.220.45]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4c5035fc-cd3c-4212-5c3d-08d726102093
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3726;
x-ms-traffictypediagnostic: MN2PR11MB3726:
x-microsoft-antispam-prvs: <MN2PR11MB3726DC73AC3DDAE739896FC4D8AA0@MN2PR11MB3726.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0136C1DDA4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(39860400002)(396003)(346002)(136003)(13464003)(199004)(189003)(99286004)(8676002)(186003)(66066001)(81166006)(53546011)(86362001)(55016002)(81156014)(6506007)(8936002)(2171002)(66446008)(2501003)(64756008)(66476007)(6116002)(66556008)(33656002)(76116006)(66946007)(7696005)(3846002)(486006)(76176011)(66574012)(7736002)(53936002)(316002)(14454004)(102836004)(6246003)(229853002)(110136005)(25786009)(2906002)(305945005)(9686003)(6436002)(476003)(52536014)(478600001)(6666004)(71200400001)(71190400001)(446003)(11346002)(14444005)(256004)(26005)(74316002)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3726; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: q3RGgEEX7UeXwzBZ4f8z7S4MpkHJwnG2Dd2iTeYw3h2tP71gl3JzF3hdywqg+usEo13JgrOwSgqcDgtS/TUzSJ6nqhgYEsq+eOt50cUYWPDOOtSp/LkNpkS8x5EAgTCYmu78eexGdcAt74RC/qE2ia3X7FkHPZolciZcMugj9r6uGewm+qIi1r+NOjSlWP+NZMfumXXXUzHGO2b2rzQEiPeSsxt3mk6aHR3H5wZfFeZG1d7VfUZMeTIhA0gYzt23lMEZ8Ai36JvCawbzHawqAHHHmZSd8mIvQDE6Hsj56KFwV7bTJDW1WgLSSL3yVQcie7rGkQtvsuFIWSPckCzKVGsm7fMxt0UvwJioA3Mdf9WyPe9GAy0IgY8lyXZHUDof8GuMOtsaaSBP+Mpc8EeEqxuigDWe2b5NFDDAdhQuk3E=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4c5035fc-cd3c-4212-5c3d-08d726102093
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2019 08:18:20.2086 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: DmbxnY2xHBy/ytqpEoyH/zxiW5jCwPrBI3ZtPNiMWXHl2EpoTCieCYeisbT4O4/36U0vsqyvuuNnSI8lWhLHag==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3726
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/8mY0CNDAJJUhxU-ua7JQIS5ef4E>
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: Wed, 21 Aug 2019 08:18:26 -0000

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

All the best,

Pascal

> -----Original Message-----
> From: 6tisch <6tisch-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: mardi 20 août 2019 22:03
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>; Benjamin Kaduk
> <kaduk@mit.edu>; =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?=
> <malisa.vucinic@inria.fr>; Tero Kivinen <kivinen@iki.fi>; 6tisch@ietf.org
> Subject: Re: [6tisch] rekeying the 6TiSCH network
> 
> 
> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>     > I'm looking for a consensus on how to address the following review
>     > comment on the 6TiSCH Architecture by Benjamin:
> 
>     >> It would be good to see some architectural discussion about key
>     >> management
>     >> for the link-layer keys.  (Given that 802.15.4 leaves key management
>     >> as out of
>     >> scope, it is clearly our problem.)  Thus far I don't even have a sense
>     >> for when it is
>     >> possible to rotate a network's keys.
> 
>     PT> I'll take that to a separate thread with Michael, Tero and Malisa. It
>     PT> is certainly possible to rotate keys. We had a draft about rekeying
>     PT> that went stale. We isolated cases where this is desirable in the
>     PT> discussion on the minimal security draft. I'm unclear how deep we
>     PT> need to go in this regards vs. what belongs to the minimal security
>     PT> specification.
> 
> 6tisch-minimal-security has a section 8.2 "Parameter Update Exchange"
> Maybe it should include "(and Rekey)"
> 
> We further have section 8.4.3.1 and 8.4.3.2 to explain how to use that to rekey
> the entire network.
> 
> I'm not sure what's in the Architecture document about this, but I'd rather that it
> just said less.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>

v2.23.0 | Report a Bug | By Email