Göran Selander <[email protected]> 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 <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
