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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 11 July 2019 11:31 UTC

Return-Path: <pthubert@cisco.com>
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 426EE120099; Thu, 11 Jul 2019 04:31:51 -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=hh/lt3To; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=CUgEKWih
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 TE3e-Vji2dzg; Thu, 11 Jul 2019 04:31:48 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388F3120045; Thu, 11 Jul 2019 04:31:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5837; q=dns/txt; s=iport; t=1562844708; x=1564054308; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rGRU8WBEVt8I7NRy2AkepQIBJaNjB0mihEfvSSMO1NA=; b=hh/lt3To0qCSm0mN4/vnE6i9vmT0YcCW0iEVNRjtYNtG26+Lz3+85UnU YEp92NLnoUILNZmGw6/AGeek/5YT8Zljv0VkduheSnZbsw3cNRZQ2c2I7 11NqpCPeY58gs7gk9fyd7Wy1rqWOD2hCjqYpNEuj3zIonZoyh/hywR2ic E=;
IronPort-PHdr: =?us-ascii?q?9a23=3AIhQbHhSjIHpE2Hb6Zj4JkZuQ8tpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrBQCaHSdd/40NJK1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBZ4FEKScDalUgBAsoh2MDjkZMgg+XSoJSA1QJAQEBDAEBIwoCAQGEQAK?= =?us-ascii?q?CUyM4EwEDAQEEAQECAQVthTwMhUoBAQEBAxIuAQE3AQsEAgEIEQEDAQEvMhc?= =?us-ascii?q?GCAIEDgUIGoMBgWoDHQECDKERAoE4iGCCI4J5AQEFhQMYghIDBoE0iRaCLB0?= =?us-ascii?q?XgUA/gRFGgU5+PoJhAQECAYFggzqCJowPnkwJAoIZhliNS4IshyKOM5R0kAA?= =?us-ascii?q?CBAIEBQIOAQEFgWchgVhwFYMngkEMF4EDAQKCSIUUhT9ygSmMGSuCJQEB?=
X-IronPort-AV: E=Sophos;i="5.63,478,1557187200"; d="scan'208";a="373851864"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jul 2019 11:31:46 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x6BBVkMP022919 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Jul 2019 11:31:46 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 11 Jul 2019 06:31:45 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 11 Jul 2019 06:31:45 -0500
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 11 Jul 2019 06:31:45 -0500
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=NVWCRHaRJlhpQR1p2/jdyjFs8ewGghO+ya0w2FBmjbA=; b=CUgEKWih6AskKETLWgeKQwcglSViCV9Pc+hXCSF4of758qtHtM2TcOty80D1Mnv8AgeqpZ/hXTLrTqAOj9IocVwWhqEdom0ox/Sk9wTkyLggVL9O1NHQR4jlNZEvKznnmrw2YL0swnD+Edy8wRF08MWtKzz7iBfcb5ZPCzpozGI=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3901.namprd11.prod.outlook.com (10.255.180.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Thu, 11 Jul 2019 11:31:44 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2052.022; Thu, 11 Jul 2019 11:31:44 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Tero Kivinen <kivinen@iki.fi>
CC: David Mandelberg <david@mandelberg.org>, =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= <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>
Thread-Topic: secdir review of draft-ietf-6tisch-architecture-21
Thread-Index: AQHVKitVZAMqDsUZHEuS/CYS/vDUhKasV4DggBgc+ICAAO6ZoA==
Date: Thu, 11 Jul 2019 11:31:34 +0000
Deferred-Delivery: Thu, 11 Jul 2019 11:30:59 +0000
Message-ID: <MN2PR11MB3565F3A151A077299B41B89CD8F30@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <MN2PR11MB3565575DA39BCA11E00233B5D8E30@MN2PR11MB3565.namprd11.prod.outlook.com> <23846.21789.391089.209823@fireball.acr.fi>
In-Reply-To: <23846.21789.391089.209823@fireball.acr.fi>
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: [2001:420:c0c0:1002::1b3]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0d299f7b-427e-48b8-ace9-08d705f359ed
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3901;
x-ms-traffictypediagnostic: MN2PR11MB3901:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR11MB390187ED37A101CE0E7E5632D8F30@MN2PR11MB3901.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0095BCF226
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(396003)(39860400002)(136003)(366004)(189003)(199004)(13464003)(66446008)(64756008)(66556008)(66476007)(66946007)(55016002)(966005)(86362001)(478600001)(5660300002)(81166006)(316002)(76116006)(66574012)(46003)(11346002)(99286004)(6306002)(2906002)(476003)(8936002)(446003)(6246003)(9686003)(229853002)(6436002)(53936002)(186003)(4326008)(81156014)(6116002)(25786009)(102836004)(54906003)(6506007)(6666004)(33656002)(305945005)(74316002)(256004)(76176011)(5024004)(71190400001)(14444005)(53546011)(14454004)(52536014)(71200400001)(68736007)(6916009)(8676002)(7696005)(7736002)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3901; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: GCa/eVIIdG46t7zxGpQm/ugW5bvHQtPZ8PPiInSdCWIAtfaw2RVZMtmmDRlQslic2oEz4J7IJNxNSJVdZCgWAyt82PfmLEFcZL5yo3g75HMYqx5/JBp8NcQYwseFkR+B9H6SRDa/GsITcFNxs1MdFTlShkh1JrjAPp1dLX0bVn8oqU6PKUg2d/sRnW7JnB8Te91bKEt04GwpOgaT5sHGo2JrfAygEC5EL26JxKSVcyDaH3j1gOFmD2C5Gc8pGkxHoPDOlsk6n84AoeR71U61CtyRqG93+U/6dYENJzW88rqnDbBMYyxn1wRAMTKWewaKPbJhYVrA/8Z7PJL7fHqAarY3LVh8kZl9cL11XTUmuae6KJvFEGTlv+Bu+pgwvFJnhVzbQgZu3Sh20a9AbffxcHYAUksI0lfrcTp/nFLAVSM=
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0d299f7b-427e-48b8-ace9-08d705f359ed
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 11:31:43.8815 (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: pthubert@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3901
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ZS5Nsy6VefFP49bk3pY_yWdkKxk>
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: Thu, 11 Jul 2019 11:31:52 -0000

All good, Tero.

I think we are in perfect line. If you can find the time please have a look at https://tools.ietf.org/html/draft-ietf-6tisch-architecture-24#section-6 to make sure all is correct, I think it is.
At this point it is up to Malisa to add more details in the security section of minimal security and I trust that this thread helps.

All the best,

Pascal

> -----Original Message-----
> From: Tero Kivinen <kivinen@iki.fi>
> Sent: mercredi 10 juillet 2019 23:14
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: David Mandelberg <david@mandelberg.org>rg>; Mališa Vučinić
> <malisav@ac.me>me>; Michael Richardson <mcr+ietf@sandelman.ca>ca>;
> secdir@ietf.org; iesg@ietf.org; draft-ietf-6tisch-architecture.all@ietf.org
> Subject: RE: secdir review of draft-ietf-6tisch-architecture-21
> 
> 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