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

"Pascal Thubert (pthubert)" <> Tue, 25 June 2019 13:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B09F91200D8; Tue, 25 Jun 2019 06:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
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: (amavisd-new); dkim=pass (1024-bit key) header.b=UR4dNTWl; dkim=pass (1024-bit key) header.b=iBIRbCbE
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MEf6bUgJAisF; Tue, 25 Jun 2019 06:37:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0918712008F; Tue, 25 Jun 2019 06:37:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7440; q=dns/txt; s=iport; t=1561469826; x=1562679426; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RSuZY1J6lNofrJ7MEjB/jRJbo4tZH1nwbl0iZbOToD8=; b=UR4dNTWlVTUmhQM40Y1+XMvOdyo1hKexf32mSxEySl2yv0uKVQmeQyeF MPHj42MbopeV4vENBORAGtuKRnOLkT4YM2uAqPT5vSnGuTG4E1z7m/ZAg SOYzu4OkE+Z3emnNZUpOHnzeNFFIPb0iB7eGgMjf3xIkmJMl7v9mocPNv 4=;
IronPort-PHdr: 9a23:o9qqRxET8sKy0JpQVXhIWJ1GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNVcejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.63,416,1557187200"; d="scan'208";a="361772157"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jun 2019 13:37:04 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x5PDb4RT022702 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Jun 2019 13:37:04 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Jun 2019 08:37:03 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Jun 2019 09:37:02 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 25 Jun 2019 08:37:02 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RSuZY1J6lNofrJ7MEjB/jRJbo4tZH1nwbl0iZbOToD8=; b=iBIRbCbEpWWDNdOUGKMhT3diDk+3bbVRyhE8fmQNkzLeeyE/FlvKa5MXWwnslniwh0yXFxZcygATHHbKEOnZNcHS05u6y8VMoN8V8zLeaOf8FcVmf/5S4mw1J0RgGD3vj/2BFDW4HldXdkuNHKD6T2QvfmZsCWCWt+/PmAIpDWs=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Tue, 25 Jun 2019 13:37:01 +0000
Received: from ([fe80::1ce9:1582:146c:c50a]) by ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2008.017; Tue, 25 Jun 2019 13:37:01 +0000
From: "Pascal Thubert (pthubert)" <>
To: David Mandelberg <>, Mališa Vučinić <>, Tero Kivinen <>, Michael Richardson <>
CC: "" <>, "" <>, "" <>
Thread-Topic: secdir review of draft-ietf-6tisch-architecture-21
Thread-Index: AQHVKitVZAMqDsUZHEuS/CYS/vDUhKasV4Dg
Date: Tue, 25 Jun 2019 13:36:34 +0000
Deferred-Delivery: Tue, 25 Jun 2019 13:36:22 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5b1b7f4c-46f9-4fc9-1aa8-08d6f97233f4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3549;
x-ms-traffictypediagnostic: MN2PR11MB3549:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0079056367
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(136003)(39860400002)(396003)(376002)(189003)(199004)(13464003)(54906003)(7696005)(110136005)(46003)(316002)(68736007)(99286004)(478600001)(71190400001)(76176011)(71200400001)(52536014)(73956011)(486006)(76116006)(66446008)(256004)(66556008)(66476007)(14444005)(446003)(11346002)(64756008)(6666004)(14454004)(5024004)(33656002)(476003)(66946007)(53936002)(81166006)(86362001)(8676002)(6436002)(2906002)(81156014)(55016002)(6246003)(9686003)(8936002)(74316002)(305945005)(7736002)(5660300002)(229853002)(25786009)(186003)(53546011)(102836004)(4326008)(6506007)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3549;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 9xyGPLoWZ2CgUzQWnPermIdniD8rLHQ3d9R/OoDNvfIlerbnN6tlytedn6xmKhRQ/K6cbnnOI9BMQgeSxkrVCabCvfaAEoFHSYhr1OM/tHCK1vLgehJ83VsAVSW1yY2c9WVux91Kxru6YKVLrO/j+1nCKlSlOZjb5ISuWkrEaZG4H6kld6p4pN+JkNL5KVYbam5XiDIWKEeaujt3JczfBaVZ7MGwy1y1feeVChhMg+ItLQOPdbriO61Og1/Xx99ojU5qj/f7FiJ3IHO3JRs1tfdG7v+fb8dSRhKclcWO6BzdqRwaJ8RNUnoWHnNJJDVIu1k/PZKLQeCICGNZyhqt7BRfrTnigH4pYdpWxytawSm1A08y/PJio70DqmV67Ccs79rRaaUnk0GmPtfG/PGye8u7cctsgl3ff15Ed34XRzs=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b1b7f4c-46f9-4fc9-1aa8-08d6f97233f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2019 13:37:01.1358 (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-Transport-CrossTenantHeadersStamped: MN2PR11MB3549
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 Jun 2019 13:37:09 -0000

Ok so we went through a lot based on this ASN discussion.
I produced the following.
Michael, Malisa and Tero please confirm that it looks good / help me fix it : )

  The operation of 6TiSCH Tracks inherits its high level operation from
   DetNet and is subject to the observations in section 5 of
   [I-D.ietf-detnet-architecture].  As discussed there, measures must be
   taken to protect the time synchronization, and for 6TiSCH this
   includes ensuring that the Absolute Slot Number (ASN), which is used
   as ever incrementing counter for the computation of the Link-Layer
   security nonce, is not compromised, more below on this.  


   In a TSCH network as specified by IEEE Std. 802.15.4 [IEEE802154],
   the nonce that is used to secure Link-Layer exchanges includes an
   address of the source and the ASN.  The ASN itself is supposed to be
   distributed securely by other means.  If the ASN is compromised and a
   short address is reused, then a nonce-reuse attack becomes possible.

   With 6TiSCH, the pledge discovers a tentative ASN in beacons sent by
   nodes that have already joined the network.  As the pledge is not in
   possession of Link-Layer keys for the visited network, it cannot
   verify the message integrity code (MIC) authenticating the beacon.
   Even if it did have the keys, it still could not verify the beacon as
   it could be a replay by an attacker and thus could still announce an
   ASN that represents a time in the past.  That time would match a
   valid timeslot it if is correct modulo the number of channels used for

   After obtaining that tentative ASN, the pledge authenticates itself
   to the network using some mechanism outside of IEEE Std 802.15.4.
   With 6TiSCH, a Join Proxy (JP) helps the pledge for the join
   procedure by relaying the link-scope Join Request over the IP network
   to a Join Registrar/Coordinator (JRC) that can authenticate the
   pledge and validate that it is attached to the appropriate network.
   As a result of this exchange the pledge is in possession of a Link-
   Layer material including a key and a short address, and assuming that
   the ASN is correct, all traffic can be secured at the Link-Layer.

   This authentication steps must be such that they cannot be replayed
   by an attacker, and it must not depend on th tentative ASN being
   valid.  Note that IEEE std. 802.15.4 TSCH does not provide replay
   protection at all, and that for instance attacker can cause a
   legitimate node to retransmit a previous message by destroying an
   ack. It results and upper layer protocol must provide a way to detect
   replayed messages and cope with them.

   During the authentication the keying material that the pledge obtains
   from the JRC does NOT provide protection against spoofed ASN.  Once
   the pledge has obtained the keys to use in the network, it still
   needs to verify the ASN.  If the nonce used in the Layer-2 security
   derives from the extended (MAC-64) address, then replaying the ASN
   alone cannot enable a nonce-reuse attack unless the same node is
   attacked twice and loses all state in-between.  But if the nonce
   derives from the short address (e.g., assigned by the JRC) then the
   nonce-reuse attacks are possible, and the JRC must ensure that it
   never assigns short addresses that were already given to this or
   other nodes with the same keys.

   At that point, an additional step may be required to ensure that the
   ASN is correct.  For instance, the pledge could perform a first
   exchange with a peer node that is trusted and has already joined,
   e.g., its RPL time parent, and the message should not be encrypted
   but only authenticated at the Link-Layer.  The request from the
   pledge should contain a nonce with a random part that is not ASN, and
   the authenticated response should contain the current ASN and echo
   the nonce.


All the best,


> -----Original Message-----
> From: David Mandelberg <>
> Sent: lundi 24 juin 2019 03:22
> To:;;
> Subject: secdir review of draft-ietf-6tisch-architecture-21
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area directors.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
> The summary of the review is Ready with nits.
> The review deadline for this was really short, so I didn't have a chance to read
> this as closely as I would have liked. That said, from skimming the document
> and reading the sections that looked most interesting, it looks pretty good.
> The security considerations section covers what I expected it to. I have only
> one question/concern:
> Sections 4.2.1 and 4.3.4 talk about the security of joining a network, and time
> synchronization, respectively. Do any of the security mechanisms in 4.2.1 rely
> on having an accurate clock? (E.g., to distrust old/expired keys.) Is time
> synchronization done before the join process, and is there any way to exploit
> time synchronization in order to cause a node to join a malicious network?