From: Mališa Vučinić <[email protected]> Sent: Friday, June 29, 2018 12:34 PM To: Jim Schaad <[email protected]> Cc: [email protected]; [email protected] Subject: Re: Review draft-ietf-6tisch-minimal-security 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. [JLS] Yes that does avoid the issue. My worry is that JRC1 might go boom and that information is no longer available. Given that JRC2 would then be the same company, there is no problem with needing to re-provision from a trust point. But there may be from a security prospective of re-using IVs. 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 [JLS] No not really, it would be better covered by pointing to https://tools.ietf.org/html/draft-ietf-core-object-security-13#section-5.1 esp 5.1.1 where they give an algorithm for preventing the problem. Mališa On Fri, 29 Jun 2018 at 21:08, Jim Schaad <[email protected] <mailto:[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/6tisch
