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

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Wed, 30 Oct 2019 07:04:16 -0700

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.

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

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

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 31 Oct 2019 18:53:13 +0100

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 <[email-masked]> wrote:
> 

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.

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

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