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 <mailto: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 <mailto:malisa.vuci...@inria.fr> > Sent: Tuesday, July 17, 2018 1:22 PM To: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> > Cc: 6tisch@ietf.org <mailto: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 <mailto:i...@augustcellars.com> > wrote: From: Mališa Vučinić <malisa.vuci...@inria.fr <mailto:malisa.vuci...@inria.fr> > Sent: Friday, June 29, 2018 12:34 PM To: Jim Schaad <i...@augustcellars.com <mailto:i...@augustcellars.com> > Cc: 6tisch@ietf.org <mailto:6tisch@ietf.org> ; draft-ietf-6tisch-minimal-secur...@ietf.org <mailto: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 <mailto: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
