Hello authors of minimal security, Thanks for addressing my previous comments, here are some follow-up comments.
When reading through the latest version I realize that the following uniqueness requirements may have become too strict, see Section 4: “Each (6LBR) pledge MUST be provisioned with a unique PSK.” Tightening the “SHOULD” for unique PSKs in previous versions of the draft was definitely the right thing to do: Compromising one pledge must not lead to other pledges being compromised, let alone an entire network. We want each endpoint to have good quality keys for authentication and secure communication, and that the secret keys of one endpoint does not reveal any information about the secret keys of another endpoint. Now, the PSK in the Constrained Join protocol is used as the OSCORE Master Secret, from which the Sender/Recipient Contexts, including Sender/Recipient Keys, are derived. It is these keys, not the PSK, which are used for authentication and communication security in OSCORE, so they need to be unique and independent in each pledge. Since the Sender/Recipient Contexts are derived from the PSK and the pledge identifier using HKDF, the derived keys are expected to get these good properties as long as the input to HKDF is different for different endpoints. So, having unique PSKs is a sufficient condition. But having unique pledge identifiers is also sufficient, even if the same PSK is used: Pledges may be provisioned directly with the Sender/Recipient Context in a 1-touch fashion without access to the PSK, and can then run the Constrained Join protocol. In fact, this is a quite attractive deployment scheme: * The pledges do not need to implement HKDF or SHA-256. * The JRC need only one PSK for all pledges, and from this PSK and the unique pledge identifier the JRC can derive the relevant security context for that pledge, either just-in-time when needed (reduces storage), or once and for all on first contact with a pledge (reduces computation during message processing). Thus, requiring unique PSKs is a sufficient condition, but it is not necessary and it excludes this deployment option. Then again, formulating the uniqueness requirement in terms of PSK as is the case in -07 is much simpler than going into the Sender/Recipient Context of OSCORE, and less risk for implementation errors: Although it is fine to use the same PSK for deriving security contexts for all pledges, a common PSK MUST NOT be accessible to any pledge. Also, the draft is currently not going into the details of the Sender/Recipient Context but treats OSCORE as a black box (which is fine) - the “one-touch” assumption is essentially provisioning of PSK. So I expect nuancing this requirement: “Each (6LBR) pledge MUST be provisioned with a unique PSK.” would require quite a few reformulations, and I don’t insist on that. But even if you don’t do that, I propose that you do describe the deployment scheme sketched above, for example in an appendix, and explain in that section why this scheme is secure even though it is not complying with the requirements of the draft. Independently of that I think you should be clear in the text and in the security considerations what are the actual security requirements and that the requirement on PSK is one simple condition to achieve this. Related nits: Section 1: “The messages exchanged allow the JRC and the pledge to mutually authenticate, based on the PSK.” Section 10: “The PSK is used to set the OSCORE Master Secret during security context derivation and is important for mutual authentication of the (6LBR) pledge and the JRC.” As discussed above, mutual authentication is carried out with Sender/Recipient Contexts. Which in turn are derived from the PSK. But these sentences gives the impression that the PSK is actually used in the authentication protocol. Another nit: it is not very explicit that PSK must be secret. This may be obvious but would not hurt to write somewhere early in the text, for example replace “symmetric” with “secret” in Section 1: “It further assumes that the pledge and the JRC share a symmetric key, called PSK (pre-shared key). ” Best regards, Göran From: Mališa Vučinić <[email protected]> Date: Tuesday, 23 October 2018 at 16:07 To: Göran Selander <[email protected]>, Xavi Vilajosana Guillen <[email protected]>, Tero Kivinen <[email protected]>, Jim Schaad <[email protected]>, Tengfei Chang <[email protected]>, Klaus Hartke <[email protected]>, William Vignat <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-07.txt Dear WGLC reviewers, working group, We submitted a new version of minimal security incorporating the resolution of most of the issues raised during WGLC. There are two remaining issues that still need to be resolved, and I hope to publish these in an additional version after the draft submission cutoff period has passed. I will discuss the resolutions during the Bangkok meeting but please go ahead an take a look, and let me know if you are happy or not with the resolutions. List of issues with referenced changesets is available at: https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/issues?responsible=malishav Mališa On Tue, Oct 23, 2018 at 8:03 AM <[email protected]<mailto:[email protected]>> wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e WG of the IETF. Title : Minimal Security Framework for 6TiSCH Authors : Malisa Vucinic Jonathan Simon Kris Pister Michael Richardson Filename : draft-ietf-6tisch-minimal-security-07.txt Pages : 45 Date : 2018-10-22 Abstract: This document describes the minimal framework required for a new device, called "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) network. The framework requires that the pledge and the JRC (join registrar/coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures and configures the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6tisch-minimal-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-07 https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-minimal-security-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-minimal-security-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
