Hi Michael, Sorry for delayed response, this got hanging in my outbox.
> 25 okt. 2018 kl. 19:52 skrev Michael Richardson <[email protected]>: > > > 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". > 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 _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
