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

From: Jim Schaad <[email-masked]>
Date: Fri, 29 Jun 2018 12:06:38 -0700

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

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 29 Jun 2018 21:34:00 +0200

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.

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

Mališa