Thanks Jim for working on this! When you have time, please drop us a line with the proposed solution.
Mališa On Wed, Jul 18, 2018 at 2:13 PM Jim Schaad <i...@augustcellars.com> wrote: > 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ć <malisa.vuci...@inria.fr> > *Sent:* Tuesday, July 17, 2018 1:22 PM > > > *To:* Jim Schaad <i...@augustcellars.com> > *Cc:* 6tisch@ietf.org > > *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 <i...@augustcellars.com> wrote: > > > > > > *From:* Mališa Vučinić <malisa.vuci...@inria.fr> > *Sent:* Friday, June 29, 2018 12:34 PM > *To:* Jim Schaad <i...@augustcellars.com> > *Cc:* 6tisch@ietf.org; draft-ietf-6tisch-minimal-secur...@ietf.org > *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 <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
