Re: [6tisch] I-D Action: draft-ietf-6tisch-minimal-security-07.txt

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ć <malisa.vucinic@inria.fr>
Date: Tuesday, 23 October 2018 at 16:07
To: Göran Selander <goran.selander@ericsson.com>, Xavi Vilajosana Guillen <xvilajosana@uoc.edu>, Tero Kivinen <kivinen@iki.fi>, Jim Schaad <ietf@augustcellars.com>, Tengfei Chang <tengfei.chang@inria.fr>, Klaus Hartke <klaus.hartke@ericsson.com>, William Vignat <wvignat@zii.aero>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>
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 <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> 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
6tisch@ietf.org<mailto:6tisch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tisch