I think that I have a solution that could be implemented at the cost of one additional round trip the first time the JRC wants to update the endpoint.
Jim From: Mališa Vučinić <[email protected]> Sent: Tuesday, July 17, 2018 1:22 PM To: Jim Schaad <[email protected]> Cc: [email protected] Subject: Re: Review draft-ietf-6tisch-minimal-security Hi Jim, It seems we have two use cases where this is relevant: 1) Change of ownership without reprovisioning the pledge (and using symmetric keys) 2) Failure of JRC Case (1): reuse of PIV can be avoided by mandating the exchange of OSCORE mutable parameters. Case (2): the context is lost and with it any hope to continue with the next PIV. I think that when JRC1 goes "boom", the network continues to operate, without even noticing as 6LBR is still operational. Then, we need to force all the nodes to rejoin and include PIV in the request, possibly by sending a command from the JRC2 to 6LBR of the network. But to send this command to 6LBR over OSCORE, JRC2 needs to use a PIV, which it doesn't know. At the moment, I don't see how we could trigger this network-wide rejoin securely, without relying on another communication channel... I will raise this during the 6TiSCH meeting tomorrow to request WG input on the best way to proceed. If you have a proposal, please let me know! Regarding the persistency issue: I suppose you refer to section https://tools.ietf.org/html/draft-ietf-core-object-security-13#section-7.5 , i.e. Section 7.5.1 of OSCORE-13, that states: To prevent reuse of Sender Sequence Numbers, an endpoint may perform the following procedure during normal operations: o Before using a Sender Sequence Number that is evenly divisible by K, where K is a positive integer, store the Sender Sequence Number in persistent memory. After boot, the endpoint initiates the Sender Sequence Number to the value stored in persistent memory + K. Storing to persistent memory can be costly. The value K gives a trade-off between the number of storage operations and efficient use of Sender Sequence Numbers. Currently, Section 8.1.1. of *draft-ietf-6tisch-minimal-security* states: Implementations MUST ensure that mutable OSCORE context parameters (Sender Sequence Number, Replay Window) are stored in persistent memory. A technique that prevents reuse of sequence numbers, detailed in Section 6.5.1 of [I-D.ietf-core-object-security], MUST be implemented. Each update of the OSCORE Replay Window MUST be written to persistent memory. In the text above, there is a typo: s/Section 6.5.1/Section 7.5.1 Let me know if I am missing something else to add regarding this. Mališa On Tue, Jul 10, 2018 at 3:20 PM Jim Schaad <[email protected] <mailto:[email protected]> > wrote: From: Mališa Vučinić <[email protected] <mailto:[email protected]> > Sent: Friday, June 29, 2018 12:34 PM To: Jim Schaad <[email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> ; [email protected] <mailto:[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
