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 <nore...@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).
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
