Hi Jim, Thanks a million for going through the document. Regarding the problem you outline where the pledge first joins to JRC1 and then later to JRC2, this would correspond to the change of ownership of the pledge, without going through the trouble of re-provisioning the pledge with a new PSK/security context. While this use case is not ideal to solve with PSKs as JRC2 would then need to fully trust JRC1, do you think it would be sufficient to require in such a case that apart from the PSK, the JRC1 would need to communicate to JRC2 the full state of the security context, including JRC1’s sequence number (ie all mutable parameters)? JRC2 would then simply continue with the next seqno, avoiding reuse.
Regarding your minor issue, could you check if the text in Section 8.1.1 covers what you had in mind? https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-06#section-8..1 Mališa On Fri, 29 Jun 2018 at 21:08, Jim Schaad <i...@augustcellars.com> wrote: > I think I have found a security problem with the document as it currently > stands. I also have a minor request. > > Minor Request: > I think it might be advisable to explicitly state that the derived context, > or at least the last partial IV used is stored in non-volatile storage > after > use. (Could just do an update to value + n when you approach that limit.) > > Major Problem: > > I believe that there is a problem in that there is a designed re-use of > partial IV values. > > 1. A pledge completes a join operation with JRC1. There are no problems > here as the partial IV is correctly changed. This uses a number of partial > IVs from pledge space. > > 2. JRC1 performs a number of parameter updates. This uses a number of > partial IV values from the JRC1 side. > > 3. JRC1 disappears for some reason leaving no traces behind. > > 4. The pledge is then told to do a second join and it attaches to JRC2. > Since the pledge keeps the partial IV value there are no problems. > > 5. JRC2 performs a parameter update. Since JRC2 does not know how many > messages were sent from JRC1, it does not know what to set the partial IV > to > and thus would reuse IV values. > > I believe that this could be addressed as follows: > > 1. The pledge keeps track of the last partial IV from a JRC > 2. When a pledge does a join, it sends that value to the JRC so that the > JRC knows where to start generating messages. > > Jim > > >
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
