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

[Michael Richardson <[e-mail]>]

Göran Selander <[e-mail]> 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".

    > 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.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-