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

[Mališa Vučinić <[e-mail]>]

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 <[e-mail]> 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).