Re: [6tisch] Review draft-ietf-6tisch-minimal-security

[Mališa Vučinić <[e-mail]>]

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 <[e-mail]> 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ć <[e-mail]>
> *Sent:* Wednesday, July 18, 2018 12:08 PM
>
>
> *To:* Jim Schaad <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]> 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ć <[e-mail]>
> *Sent:* Tuesday, July 17, 2018 1:22 PM
>
>
> *To:* Jim Schaad <[e-mail]>
> *Cc:* [e-mail]
>
> *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 <[e-mail]> wrote:
>
>
>
>
>
> *From:* Mališa Vučinić <[e-mail]>
> *Sent:* Friday, June 29, 2018 12:34 PM
> *To:* Jim Schaad <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>