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

From: Mališa Vučinić <[email-masked]>
Date: Mon, 5 Nov 2018 10:23:36 +0100

Hi Jim,

Thanks! Nits are fixed, here are the relevant commits:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/3c13ce3106c00fca2e38cc732359e98039eac528

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/369c09fd04f785296917554a10797c6dba91e028

Mališa

On Sun, Oct 28, 2018 at 5:17 AM Jim Schaad <[email-masked]> wrote:

> Mališa,
>
>
>
> I am happy with the changes that were made to address my original comments.
>
>
>
> Here are a couple of nits you may want to address.
>
>
>
> jim
>
>
>
>    1. In section 2 use the updated reference to RFC 8174
>    2. In section 4 – You might want to make it explicit as one of the
>    item that the pledge identifier is provisioned.
>
>
>
> *From:* Mališa Vučinić <[email-masked]>
> *Sent:* Tuesday, October 23, 2018 7:07 AM
> *To:* Göran Selander <[email-masked]>; Xavi Vilajosana
> Guillen <[email-masked]>; Tero Kivinen <[email-masked]>; Jim Schaad <
> [email-masked]>; Tengfei Chang <[email-masked]>; Klaus
> Hartke <[email-masked]>; William Vignat <[email-masked]>
> *Cc:* [email-masked]
>
>
> *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-masked]> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Mališa Vučinić <[email-masked]>
Date: Mon, 5 Nov 2018 10:32:43 +0100

Hi Göran,

Thanks for the feedback and the proposal. I added Appendix B detailing this
deployment option:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/b93e8fa6152eb2bb10761264bcf8e47f861fd418

Let me know if the current text works for you.

Also, regarding the comment to explicitly mention OSCORE AEAD keys, here is
the relevant commit:

https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/commits/b50787232346e991d3384916a47faa4a49ed39ee

I have also resolved other pending issues on the document
- making use of the 0-length OSCORE Sender ID for the pledge
- use of CoAP CON messages to transport Join Request from pledge to JP and
NON messages from JP to JRC.

I will discuss these more in detail on Thursday.

The WIP document is at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/src/minimal-security-08/

Mališa

On Wed, Oct 31, 2018 at 10:37 PM Göran Selander <[email-masked]>
wrote:

> Hi Michael,
>
> Sorry for delayed response, this got hanging in my outbox.
>
> > 25 okt. 2018 kl. 19:52 skrev Michael Richardson <[email-masked]>:
> >
> >
> > Göran Selander <[email-masked]> wrote:
> >> 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.
> >
> > What I'm hearing is that Pledges may be provisioned (at the factory)
> with:
> >     SRContext = HKDF(PSK, PledgeIdentifier, other-stuff)
> >
> > while the JRC can be provisioned with:
> >      1) PSK
> >      2) list of valid PledgeIdentifiers
> >
> > What does not change is that:
> >     a) SRContext still must be kept a secret.
> >     b) SRcontext is still unique per-pledge (so can't be baked directly
> into firmware!)
> >
> > So this is easier for the JRC, but does not really change anything in
> the way
> > that Pledges have to be "touched".
> >
>
> Right, this was not a comment about changing one-touch, which is the basic
> assumption of minimal security. This was a note that other secrets can be
> provisioned in the same one-touch manner with certain benefits to pledge
> and JRC.
>
> >> 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
> >
> > I agree that putting it into an appendix would work.
> > A completely separate document might also a good idea. (An operational
> BCP)
> >
> > In particular, leaving it to another document might allow other things
> that
> > need to be baked in uniquely to be described.  I am thinking about a
> > connection to the hash-based signature work that the SUIT WG cares about.
>
> I think that having at least a paragraph in an appendix of this draft
> would be good as it also illustrates how the requirement on PSK uniqueness
> can be slightly eased.
>
> Thanks,
> Göran
>
>
>