Re: [6tisch] Alvaro Retana's No Objection on draft-ietf-6tisch-minimal-security-13: (with COMMENT)

Mališa Vučinić <malisa.vucinic@inria.fr> Thu, 31 October 2019 17:53 UTC

Return-Path: <malisa.vucinic@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81CD120071; Thu, 31 Oct 2019 10:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 NJD7GbP_6tow; Thu, 31 Oct 2019 10:53:45 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6FE1200EC; Thu, 31 Oct 2019 10:53:38 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.68,252,1569276000"; d="scan'208,217";a="325272377"
Received: from wifi-pro-82-245.paris.inria.fr ([128.93.82.245]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2019 18:53:14 +0100
From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
Message-Id: <17DF05DD-0374-4F8D-8294-7F057BD09B9E@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A7DA8D75-CAFE-4B56-8DBC-13BE977B28C1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 31 Oct 2019 18:53:13 +0100
In-Reply-To: <157244425632.32464.13826694878494129690.idtracker@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-6tisch-minimal-security@ietf.org, Pascal Thubert <pthubert@cisco.com>, 6tisch-chairs <6tisch-chairs@ietf.org>, 6tisch@ietf.org
To: Alvaro Retana <aretana.ietf@gmail.com>
References: <157244425632.32464.13826694878494129690.idtracker@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/wgz6Ij0LFdKg-yAuyEDsWO0jv0A>
Subject: Re: [6tisch] Alvaro Retana's No Objection on draft-ietf-6tisch-minimal-security-13: (with COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Oct 2019 17:53:49 -0000

Dear Alvaro,

Many thanks for your review. I responded to your comments inline and you can find the proposed changes in the working version of the document at:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/408b01c51282aa2cf04407de2bf6fcf0a4628a95 <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/408b01c51282aa2cf04407de2bf6fcf0a4628a95>

Please let me know if these changes sufficiently respond to your comments.

Mališa

> On 30 Oct 2019, at 15:04, Alvaro Retana via Datatracker <noreply@ietf.org> wrote:
> 
> Alvaro Retana has entered the following ballot position for
> draft-ietf-6tisch-minimal-security-13: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I have a couple of important issues I want to bring up.  I don't think they
> raise to the level of a DISCUSS, but would like to talk about them before the
> document is published.
> 
> (1) What is the relationship between this document and rfc8180?  Both documents
> define "minimal" operation in a 6TiSCH network.  This document seems to build
> on rfc8180.  Should it formally Update it?  Should it also be a BCP?
> 
> One aspect that jumps at me is the fact that both documents declare key
> distribution/provisioning out of scope.  rfc8180 describes the behavior of a
> Joining Node (which I interpret to be the same as a pledge) "depending on which
> key(s) are pre-configured" (§4.6), but this document seems to assume only the
> case where the "pledge...initially...does not possess the link-layer key(s)" so
> that "during the join process, the pledge sends unencrypted and unauthenticated
> frames." (§5)  Leaving key distribution/provisioning out of scope is fine, but
> the assumptions of the operation are not congruent.  Given that rfc8180 is a
> BCP, then it seems that this document doesn't follow the Best Practices or
> maybe tries to update (?) them with this new minimal security framework.


I think that there is a confusion here around the type of keys used. Keys that RFC8180 mentions in Section 4.6 are link-layer keys that according to that document can be either pre-configured or “learned during a key distribution phase”. The minimal-security document defines that key distribution phase through the Constrained Join Protocol (CoJP) and accompanying framework. In that context, RFC8180 specifies a more general case allowing for out-of-band configuration of link-layer keys, with the minimal-security document defining how to obtain the link-layer keys when they are not pre-configured. The minimal-security document is consequently written on the assumption that “pledge…initially…does not possess the link-layer keys”, but is provisioned with a long-term pre-shared key (PSK), used for encryption and authenticity of CoJP messages transporting the link-layer keys.

The text in RFC8180 is still valid so I do not believe there is a need for minimal-security to update that document. I added the following in Section 3 attempting to clarify the difference between the PSK and K1/K2 keys from RFC8180.

NEW: Note that the PSK is different from the link-layer keys K1 and K2 specified in {{RFC8180}}. The PSK is a long-term secret used to protect the execution of the secure join protocol specified in this document whose one output are link-layer keys.

Please let me know if this clarifies.

> (2) Normative References
> 
> §1: "This document presumes a 6TiSCH network as described by [RFC7554] and
> [RFC8180]."  Why are these references not Normative?  If the content of this
> document is based on the descriptions in those RFCs, I believe they should be.
> 
> Also, IEEE802.15.4 seems to be important to understand in a 6TiSCH document.

Thanks for the comment, I moved RFC7554, RFC8180 and IEEE802.15.4 to normative references.

> (3) §5: The Normative keywords in this paragraph are out of place because the
> specification is already made in rfc8180.  IOW, there's no need to specify here
> what is already specified elsewhere.
> 
>   In an operational 6TiSCH network, all frames MUST use link-layer
>   frame security [RFC8180].  The IEEE Std 802.15.4 security attributes
>   MUST include frame authenticity, and MAY include frame
>   confidentiality (i.e. encryption).

As Barry Leiba proposed in another review, I resolved this comment by removing the normative keywords and simply re-stating the requirement from RFC8180.

NEW: In an operational 6TiSCH network, all frames use link-layer frame security {{RFC8180}}. The IEEE Std 802.15.4 security attributes include frame authenticity, and optionally frame confidentiality (i.e. encryption).