Hi Jim, Apologies for responding to your email only now due to my vacation in August.
I don't have any objection to your proposed solution and this indeed solves the issue without introducing an additional message in the protocol. I am slightly leaning towards the PIV being sent in the Bad Request error payload instead of within the Request-Tag option, simply to minimize the implementation effort. I will incorporate this in the next revision of the draft before Bangkok and validate with you. Thank you for doing a review, outlining an issue and proposing a solution! Mališa On Fri, Aug 3, 2018 at 10:28 PM Jim Schaad <i...@augustcellars.com> wrote: > As I remember we had a discussion about this during the creation of OSCORE > but the results did not make it into the final draft. > > > > There is never a problem for the second JOIN as the device will have both > the keys and the saved PIV to use so it will never do a reuse of the same > PIV assuming correct implementation. > > > > The first message from the JRC needs to be checked by the pledge to see if > there is a duplicate PIV used. If it finds a duplicate PIV used, and the > PIV is “grossly” below the PIV it is expecting. Then the pledge sends back > and an encrypted response to the JRC with the following properties: > > > > 1. The pledge uses its next PIV value (i.e. it will look like an > observe message to the JRC) and places it’s PIV into the message as the > partial IV. Doing so should not create any problems that I can think of. > As a new PIV is used there is no security leakage. > 2. The pledge sends a request-tag option as part of the response. The > value of the request-tag option contains a value greater or equal to the > next PIV from the JRC that it will allow. This value is an encrypted > option and thus not visible. > 3. The JRC can then resend the message to the pledge using the new PIV > (and optionally the request-tag option) to the pledge which should now > accept it. > > > > There are a number of different ways that the value could be send from the > pledge to the server. I suggested the request-tag option above, but you > could for example send “PIV=#” as the payload of a Bad Request error code > to the JRC. The only thing would be to define a single way to send this > information. > > > > The first message from the JRC would be subject to leakage of data as it > could be XORed with the first message from the original JRC and thus some > details extracted. I don’t know how much of this information ends up as > being public after a while anyway and thus leaking it would not be a huge > problem. Depending on value of the data, the JRC could generate new data > for the message to the pledge. > > > > Jim > > > > > > *From:* Mališa Vučinić <malisa.vuci...@inria.fr> > *Sent:* Wednesday, July 18, 2018 12:08 PM > > > *To:* Jim Schaad <i...@augustcellars.com> > *Cc:* 6tisch@ietf.org > *Subject:* Re: Review draft-ietf-6tisch-minimal-security > > > > 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 >
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch