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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 26 June 2019 12:22 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 2FAA2120142; Wed, 26 Jun 2019 05:22:53 -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=N42ydIPM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TnEo+Vxg
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 KTi-kA_j_YoN; Wed, 26 Jun 2019 05:22:51 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65521200FA; Wed, 26 Jun 2019 05:22:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5006; q=dns/txt; s=iport; t=1561551770; x=1562761370; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zI+Gvw21eFoCUkE0B6f+JiBtXaf1TVsRylLvsFIZzDg=; b=N42ydIPMQq4L/zaaO7xDo4H9JoRp+kHuEQliZk4o8RZYWR+9KwMQrFvi /CTfr8i6hMQ3tQci6B8vMHZkvjF7eA6p8URAEzJZCG9f3mCKFk7KI3Lsf r9NwrSCvrxytzJid+Q/lMz+jQ5TPGihc1CFt4sbo13id3QFrYXl/xuMip s=;
IronPort-PHdr: 9a23:8WsJ5RSztlnOaaoV22b6NIScstpsv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH15g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BMAQCXYhNd/5pdJa1lHAEBAQQBAQcEAQGBVgQBAQsBgUNQA4E/IAQLKAqHUgOOWoJblz2BQoEQA1QJAQEBDAEBLQIBAYFLgnUCgn0jNwYOAQMBAQQBAQIBBW2KNwyFSgEBAQMBEhUZAQE3AQ8CAQgSNDIXDgIEDgUIGoRrAw4PAQKaUAKBOIhfgW8zgnkBAQWFBRiCEQmBNAGJFIIsHReBQD+BEUaCTD6EEQESASGDOoImjimFS5YsCQKCFpQLgiqHEo4ZoHaDSwIEAgQFAg4BAQWBZiJncXAVgyeCQQwXg02KU3KBKYwJDRcHgQQBgSABAQ
X-IronPort-AV: E=Sophos;i="5.63,419,1557187200"; d="scan'208";a="580881943"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jun 2019 12:22:49 +0000
Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5QCMnkn026607 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Jun 2019 12:22:49 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 26 Jun 2019 07:22:49 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 26 Jun 2019 07:22:48 -0500
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 26 Jun 2019 07:22:48 -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=ONePemvYW89NAipsZxNIo2Nf4e2JEzB73EOr7ROupkU=; b=TnEo+VxgshNDTj33/xafKgDwCntr12bh7ZEv4CyirHRzJDNVHSA48rmxJj3Gauggy6IzNuMxrvD2vV+J8SbIWs35jeablk4lmmeI6xVMBuJ5Z8fxjaU4GB6pU21BAILcUa8T4tWB6k5fzTcSZOwV53LWwZXerxqss4NMspq6LrI=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3854.namprd11.prod.outlook.com (20.178.252.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Wed, 26 Jun 2019 12:22:47 +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.2008.017; Wed, 26 Jun 2019 12:22:47 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: David Mandelberg <david@mandelberg.org>, Mališa Vučinić <malisav@ac.me>, Tero Kivinen <kivinen@iki.fi>, "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/vDUhKasV4DggAAuGICAAVVrIA==
Date: Wed, 26 Jun 2019 12:22:21 +0000
Deferred-Delivery: Wed, 26 Jun 2019 12:22:00 +0000
Message-ID: <MN2PR11MB35650D17426E26F93E37DF32D8E20@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <MN2PR11MB3565575DA39BCA11E00233B5D8E30@MN2PR11MB3565.namprd11.prod.outlook.com> <30360.1561477509@localhost>
In-Reply-To: <30360.1561477509@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.49]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 336d7bf9-6f8b-4f5a-6ad4-08d6fa30ffbb
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3854;
x-ms-traffictypediagnostic: MN2PR11MB3854:
x-microsoft-antispam-prvs: <MN2PR11MB3854906AFB46F83B2845375CD8E20@MN2PR11MB3854.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 00808B16F3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(366004)(39860400002)(396003)(189003)(199004)(51444003)(7736002)(66066001)(256004)(99286004)(7696005)(305945005)(6506007)(76176011)(8936002)(8676002)(81156014)(81166006)(33656002)(561944003)(74316002)(25786009)(54906003)(316002)(6246003)(55016002)(11346002)(446003)(53936002)(68736007)(14454004)(71190400001)(478600001)(5660300002)(14444005)(3846002)(6116002)(9686003)(476003)(486006)(229853002)(6436002)(66446008)(66556008)(66476007)(2906002)(66946007)(86362001)(4326008)(186003)(26005)(6666004)(73956011)(52536014)(64756008)(76116006)(71200400001)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3854; 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: kYO8q+CN50Bhllk7ldbWcBwCeN3mW5WCy4Ze8j/bsta5/KUNMyANcjM2H/Kr7iycisYfk/9BnEyg/0YY/geh+S8l4wHn2mQus2YD28/NmW0LXeeW+OnB4856VpLwTjHVPgIsHVix1I5/u/XoB38wcowJGRNPJ2Tv2udaENnRVpqI5/Tv7IQYw2RvHd9uzKBrFOGEY2PNYAdQwI8uyYRLLK4awz8np81/oKyk1560ZmyVkqvdLrzNhCEqx3ZpoeHnQS61aNsMSJfJft/NPVIewvlx3aebOrU00bsfa32Hsy56EpFPBT04op/Ptu3IiBFGN3Iiz4AelTh01ubeLT9EpP1RweVh7G1eDfnZa+Iwa62en4lA6g149rPjsdT97YEyFe850cO0SwdIbZC+/xagtavGoWl5eDFSOUyBLkBIBhU=
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 336d7bf9-6f8b-4f5a-6ad4-08d6fa30ffbb
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 12:22:47.4731 (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: MN2PR11MB3854
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.28, xch-rcd-018.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/z9x4SQuSXdZ5Y2CKO4myW6S2Tm0>
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, 26 Jun 2019 12:22:53 -0000

Many thanks Michael

I'm unclear whether implementations actually have to check the ASN before responding and what actions they would take should that occur.
I guess we are in IEEE land at that point bit I understand that the IEEE did not specify a method to validate ASN. 

I incorporated your recommendations below, please see:
 
> 
> - 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.
> 
> + Even after the join process, when it does have the keys, it still
> + could not verify the freshness of the 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.

Done


> 
> 
>     >    This authentication steps must be such that they cannot be replayed
>     + by an attacker, and it must not depend on the 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

Fixed

>     - retransmit a previous message by destroying an ack. It results and
>     + retransmit a previous message by destroying an ack. If this results an
>     > upper layer protocol must provide a way to detect replayed messages and
>     > cope with them.
> 

Sorry I cannot parse the resulting sentence with your proposal.
My mistake was only and -> an but I'm sure that the sentence can be better written.
I changed to
"

    This authentication steps must be such that they cannot be replayed by an
    attacker, and it must not depend on the tentative ASN being valid. Note that
    IEEE std. 802.15.4 TSCH does not provide replay protection at all, and that 
    an ack may be lost, which can cause a legitimate node to retransmit a frame.
    Upper layer protocols must thus provide a way to detect duplicates 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.
> 
> I think that in this place, the note about rekeying the network must occur
> before running out of short addresses.
> 

Added
"
      assigns short addresses that were already given to this or other nodes with
+    the same keys. In other words, the network must be rekeyed before the JRC
+   runs out of short addresses.
"

>     >    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.
> 
> I think that we need to be explicit, not "for instance"
> 

Proposed new text:
"
    At that point, an additional step may be required to ensure that the ASN is
    correct. If the ASN is not guaranteed to be correct by other means, the
    pledge should 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.
"



> {please forgive me being behind on email. Summer cold and family
> responsabilities}

You're always helpful, Michael, how could one complain?

Many thanks

Pascal

> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>