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 <goran.selan...@ericsson.com> wrote: > Hi Michael, > > Sorry for delayed response, this got hanging in my outbox. > > > 25 okt. 2018 kl. 19:52 skrev Michael Richardson <mcr+i...@sandelman.ca>: > > > > > > Göran Selander <goran.selan...@ericsson.com> 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 > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch >
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
