Re: [secdir] Secdir review of draft-ietf-6tisch-minimal-19

Xavi Vilajosana Guillen <xvilajosana@uoc.edu> Fri, 10 February 2017 16:34 UTC

Return-Path: <xvilajosana@uoc.edu>
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 43D14129A31 for <secdir@ietfa.amsl.com>; Fri, 10 Feb 2017 08:34:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu
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 3Ap5b1yCXKh1 for <secdir@ietfa.amsl.com>; Fri, 10 Feb 2017 08:33:59 -0800 (PST)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CC1129A27 for <secdir@ietf.org>; Fri, 10 Feb 2017 08:33:59 -0800 (PST)
Received: by mail-it0-x232.google.com with SMTP id c7so36383478itd.1 for <secdir@ietf.org>; Fri, 10 Feb 2017 08:33:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r6B7N+eERckHYUZCEsV9FJVgCCcN1/pD5QJUZdGxLIA=; b=dFF0LkTYSFT9535ubvD4AAyFk86sP8wlCTDWUim3QbkxLklv96FMm8nNrhDUa+UJVE TG7m7wYKqxg6eiGkRhTBkHutVxzPX0ghQHioaC0qzxmDKl468KbgfejdbpJztoCgXMGx VIswvVDDfYny5PRt/SBP83B8bd1y8Uqz291T0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r6B7N+eERckHYUZCEsV9FJVgCCcN1/pD5QJUZdGxLIA=; b=uck7z4zNCO1owTaDR0e3R5E1+Qv2IKyJiwGwI8uKSflcX/8+7sZQLwIRpNBvwkyfqd 63xJryEfDJO/TaMEFkQGpP3y5DsRcPDw9yO/HYxkv0qMObaFNnfqJd7K6Wo8If5UV5Jv 1xoAKDnqX2z7AE+yyDBfP0NYDa8i0aoNXq0GXyDcE7unKXAYQqaEzR/yeYOeX5ijqZTi TWPPICcxj9ojp6tI+8afs1aNymiOiEElOkx6ib3VuwLJL9OD0W7JoSGiIoiSgnYebloW 2KFjGSNlr/eWPwLwH+bnrn6GJA/lhs++dl6fX+zr2B7/y1FNAOHdiHXGpmTJtcUGRd0Y hm5A==
X-Gm-Message-State: AMke39mZI1nIaeOxkaEhPUOphkaQRcVU7dSMqToyqd3W4UTmiSgEM3/WMA++2feQbO+pcNN6GO0k+5lX3i72BJpY
X-Received: by 10.36.6.199 with SMTP id 190mr9097849itv.79.1486744438648; Fri, 10 Feb 2017 08:33:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.46.13 with HTTP; Fri, 10 Feb 2017 08:33:58 -0800 (PST)
In-Reply-To: <1316481833.2081691.1486743383878.JavaMail.root@vilafranca.uoc.es>
References: <1316481833.2081691.1486743383878.JavaMail.root@vilafranca.uoc.es>
From: Xavi Vilajosana Guillen <xvilajosana@uoc.edu>
Date: Fri, 10 Feb 2017 17:33:58 +0100
Message-ID: <CAC9+vPjNLG5hxEMqf77+kEaBJqF89513RXopnsgK0r9mwyGYzg@mail.gmail.com>
To: Tero Kivinen <kivinen@iki.fi>
Content-Type: multipart/alternative; boundary=001a113f77e42352f505482faa4d
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/vLZs14bNs5pVtavOaovPPqwtnKk>
Cc: iesg@ietf.org, draft-ietf-6tisch-minimal.all@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-6tisch-minimal-19
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 10 Feb 2017 16:34:02 -0000

Dear Tero,

thanks for your detailed review. I will proceed with the revision in the
following days and provide a new version.

have a nice weekend,
Xavi

2017-02-10 17:15 GMT+01:00 Tero Kivinen <kivinen@iki.fi>fi>:

> 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.
>
> This is my rereview of this draft. My original review found quite a
> lot of issues, and most of them have already been taken care of. There
> are still some remaining issues.
>
> Summary of the review: There are Issues.
>
> --
>
> In section 4.6 the text
>
>       Key K1 is used to authenticate EBs.  As defined in Section 4.5.2,
>       EBs MUST be authenticated only (no encryption).
>
> is bit misleading, as while section 4.5.2 do define EBs it does not
> tell anything about the security of them.
>
> Perhaps rewrite that:
>
>       Key K1 is used to authenticate EBs. EBs MUST be authenticated
>       only (no encryption), and their contents is defined in the
>       Section 4.5.2.
>
> --
>
> In section 4.6 the text about secExempt is bit incorrect.
>
>       If neither key K1 nor key K2 is pre-configured, the JN uses the
>       secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process
>       EBs, and relies on the key distribution phase to learn K1 and K2.
>       Once K1 and K2 are learned, the secExempt mechanism MUST be
>       disabled and EBs properly authenticated using K1.
>
> The secExempt is needed both in the the joining node and the node
> receiving the frames from the joining node. The joining node usually
> do not use secExempt method, as it does not have keys, so it will not
> turn security processing of the 802.15.4 on until it has keys. So
> while still in joining process, it has security turned off and it can
> receive frames without security.
>
> The joining assistant (or was it proxy in new terminology) will then
> receive frames without security and when it receives them it should
> then configure the security layer or the 802.15.4 so that from that
> specific joining node the frames are allowed to come in without
> security. After the joining process is finished, those secExempt rules
> installed are removed.
>
> So the text should be written as:
>
>       If neither key K1 nor key K2 is pre-configured, the JN will will
>       accept EBs as defined in the Section 6.3.1.2 of the 802.15.4,
>       i.e., they are passed forward even "if the status of the
>       unsecuring process indicated an error". The JN will then run key
>       distribution phase to learn K1 and K2. During that process the
>       node JN is talking to, uses the secExempt mechanism (IEEE Std
>       802.15.4, Section 9.2.4) to process frames from JN. Once the key
>       distribution phase is done the node which has installed
>       secExempts for the JN MUST clear the exception rules installed.
>
> --
>
> In the section 8 there is text saying:
>
>       If both K1 and K2 are pre-provisioned, a joining node can
>       distinguish legitimate from fake EBs, and join the legitimate
>       network.  The fake EBs have no impact.
>
> This is incorrect, as just few paragraphs before it was noted, that
> "Fixed secrets will not remain secret.".
>
> Same applies also if only K1 is pre-provisioned. I.e., if K1 is
> pre-provisioned attacker can physically extract the key from one
> device, and then use that K1 to attack whole network by sending
> authenticated EBs. So in all cases attacker can most likely cause the
> joining node to initiate the joining process to the attacker. If
> joining process includes authentication and distributing K2 to joining
> node, then joining node will fail, and joining node will notice this.
>
> If both K1 and K2 are pre-provisioned and attacker extracted them from
> one of the nodes earlier, joining node will not notice the attack.
>
> --
>
> The text
>
>       If neither K1 nor K2 is pre-provisioned, a joining node uses the
>       secExempt mechanism (IEEE Std 802.15.4, Section 9.2.4) to process
>       all correctly-formatted EBs.  It therefore may mistake a fake EB
>       for a legitimate one and initiate a joining process to the
>       attacker. ...
>
> describes the secExempt system again, and does it again incorrectly,
> so it would be better to just remove secExempt parts from there, and
> leave them only in 4.6. I.e., change this to:
>
>       If neither K1 nor K2 is pre-provisioned, a joining node may
>       mistake a fake EB for a legitimate one and initiate a joining
>       process to the attacker. ...
>
> --
>
> Then we have text:
>
>    Once the joining process is over, the node that has joined can
>    authenticate EBs (it knows K1).  This means it can process their
>    contents and use EBs for synchronization.
>
> But if the K1 is pre-provisioned and we can then assume that attacker
> knows it, the attacker can then send authenticated fake EBs to the
> node even after that. So this section should analyze what those fake
> EBs can do. If we limit the minimal so that none of the parameters in
> the EBs can be changed during the lifetime of the network (i.e., the
> network timing, used channels, slotframe size will remain static etc),
> then the attacker cannot gain too much. It can still mess up the nodes
> trying to join the network as explained earlier.
>
> We do have the text in the section 1 saying:
>
>            When following this specification, the learned schedule is
>    the same for all nodes and does not change over time.
>
> which would indicate that all the parameters sent out in EB (except
> ASN and Join metrics), but do we have somewhere the text saying that
> nodes MUST ignore EBs which try to change the parameters?
>
> --
>
> The security consideration section is missing the text about the fact
> that TSCH does NOT provide replay protection for retransmitted frames.
> I.e., if node A transmits frame X and attacker messes up the ACK from
> the node B acking that frame, then the node A will retransmit that
> frame X again using new ASN. The 802.15.4 layer would normally ignore
> the retransmission as it has seen the frame counter before, but as
> TSCH uses ASN instead of frame counter, this protection is not
> available when using TSCH.
>
> This means that all upper layer protocols MUST be resistant to this
> kind of attacks, and they MUST have mechanims to prevent this.
>
> For example if the 6top sends ADD message saying "Allocate 3 new
> cells", there must be sequence number (SeqNum) and the 6top protocol
> needs to notice that if it gets two ADD message with same SeqNum it
> must ignore the replayed one.
>
> This might not be obvious to the users of the 6tisch, as 802.15.4 for
> example do provide protection against retransmissions done by link
> layer.
>
> --
>
> In section 8 (security consideration) there is text:
>
>    The MAC layer SHOULD keep track of anomalous events and report them
>    to a higher authority.  For example, EBs reporting low Join Metrics
>    for networks which can not be joined, as described above, may be a
>    sign of attack.
>
> I do not think we should put any requirements for the MAC layer in
> this document. Also in the 802.15.4 the Join Metrics etc processing is
> done by the higher layer, not by MAC. Perhaps change the "The MAC
> layer" to "The 6TiSCH layer".
>
> --
>
> >From my previous review:
>
> > 6)EDITORIAL ISSUE 4
> >
> > Same for other names (slotOffset == Timeslot, chOffset == Channel
> Offset).
> > Also the IEEE Std 802.15.4-2015 moved away from using link
> > Options as hex number (0x0f), and instead lists the separate bit-fields
> in it
> > (tx, rx, shared, timekeeping), as does the Appendix A.
> >
> > DISCUSSION
> >
> > Don’t see what change is requested here
>
> I was wondering why we are using two different terms for same things.
> I.e. figure 1 uses slotOffset and chOffset, but the appendix A uses
> the "Timeslot" and "Channel Offset" instead. Perhaps using "Channel
> Offset" for "chOffset" in whole document, and add "slotOffset" to the
> Append A.2 similarly than what was done for "(Cells)", i.e. change
>
>            Timeslot = 0x0000 (2B)
>
> to
>
>            Timeslot (slotOffset) = 0x0000 (2B)
>
> The second item is that the saying "link Option 0x0f" in figure 1 is
> incorrect, as Link Options is not numeric field anymore, it is
> bitfield having bits "TX Link", "RX Link", "Shared Link",
> "Timekeeping" and "Priority" as is already explained in section 4.2.
> The figure 1 still insist using 0x0f. I think it is better to change
> that to list individual flags, i.e. change
>
>    |                                |   (link Option 0x0f)         |   |
>
> in figure 1 to
>
>    |                                |   (Link Options: TX Link,    |   |
>    |                                |    RX Link, Shared Link,     |   |
>    |                                |    Timekeeping)              |   |
>
> Also the figure 1 has line:
>
>    |                                |   (LinkType    ADVERTISING)  |   |
>
> as part of the Number of scheduled cells and it has EB marked as "X".
> The LinkType is not transmitted over the wire at all, it is parameter
> given to the MLME-SET-LINK.request primitive in the 802.15.4 MAC. So
> claiming it being part of EB is misleading.
>
> Perhaps removing that LinkType from the figure 1, but add footnote
> that applies to the Number of scheduled cells saying that "This cell
> is also set to have LinkType of ADVERTISING)".
>
> --
>
> So this document is in much better shape now, but I still think there
> is issues that needs to be fixed before it can be approved.
> --
> kivinen@iki.fi
>



-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
xvilajosana@uoc.edu <usuari@uoc.edu>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
[image: Universitat Oberta de Catalunya]
­