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

Tero Kivinen <kivinen@iki.fi> Wed, 10 July 2019 21:14 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3635912014E for <secdir@ietfa.amsl.com>; Wed, 10 Jul 2019 14:14:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.419
X-Spam-Level:
X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=unavailable 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 6cmR35HMit8u for <secdir@ietfa.amsl.com>; Wed, 10 Jul 2019 14:14:32 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F424120025 for <secdir@ietf.org>; Wed, 10 Jul 2019 14:14:31 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x6ALE53w025419 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jul 2019 00:14:05 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6ALE5Tf013629; Thu, 11 Jul 2019 00:14:05 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23846.21789.391089.209823@fireball.acr.fi>
Date: Thu, 11 Jul 2019 00:14:05 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: David Mandelberg <david@mandelberg.org>, Mališa Vučinić <malisav@ac.me>, Michael Richardson <mcr+ietf@sandelman.ca>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-6tisch-architecture.all@ietf.org" <draft-ietf-6tisch-architecture.all@ietf.org>
In-Reply-To: <MN2PR11MB3565575DA39BCA11E00233B5D8E30@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <MN2PR11MB3565575DA39BCA11E00233B5D8E30@MN2PR11MB3565.namprd11.prod.outlook.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 13 min
X-Total-Time: 12 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Q6hBGcsIKM9gk2hQteD1LM9qWFc>
Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2019 21:14:34 -0000

Pascal Thubert (pthubert) writes:
>    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
>    hopping.

Note, that attacker can pick time, and channel correctly so that it
will always match. I.e., if he wants to reply beacon with ASN=1235 and
that was sent on channel X, it simply needs to replay that same
ASN=1235 on channel X, regardless what current ASN and channel would
be for others in the network. It is actually beneficial for it to use
some offset, so JN will not accidently see any real messages...

Most likely JN will start listening beacons on channel X, then if does
not hear anything for some time, it moves to X+1 etc. Most likely it
will stay on channel X so long that it will hear beacon from there. So
attacker stores that beacon on channel X and the ASN is so that it is
assuming channel X for hopping.

Now if attacker retransmits this out on channel X immediately when it
assumes JN is listening, JN will pick it, and will then pick wrong
offset for channel hopping.

So, that sentence about Time and module to number of channels, is not
useful. 

>    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.

Sending ASNs in the mssage is almost impossible, as upper layer does
not have any idea what ASN will be used to send message out. It does
not know when the next slot to the JN will be, and it does not know
whether that slot will be free etc.

Because of this I think it is better to use some other method, i.e.,
if JN just generates random cookie and sends that to JP/JRC, and
JP/JRC will then echo that same cookie back then JN will know that
exchange is fresh, and if that was authenticated using L2 key K1, then
ASN was implictly verified also, as JP/JRC who do know correct ASN,
will drop the incoming frame as it will have wrong MIC because of
wrong nonce.
-- 
kivinen@iki.fi