[6tisch-security] some proposed changes to 6tisch-minimal-security

[Michael Richardson <[e-mail]>]

This makes it clear how the pledge should process the EB:

https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/commits/78b8e6455dc9500c7c0de43960f282ccb9529d24

+A pledge which receives only Enhanced Beacons containing Network ID extensions
+{{I-D.richardson-6tisch-join-enhanced-beacon}} with the initiate bit cleared, SHOULD NOT
+proceed with this protocol on that network.  The pledge SHOULD consider that it
+is in a network which manages join traffic, it SHOULD switch to {{I-D.ietf-6tisch-dtsecurity-secure-join}}.

This makes it clearer that certificates do not necessarily mean that it is a
zero-touch case: if they are locally relevant, then it's just a rejoin after a long sleep.

https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/commits/e283fd274ab2d4ee8e0d1a3467f27d4d1dc3963f

REQUIRED for RPKs and certificates.
+
+When using certificates, the process continues as described in {{I-D.selander-ace-cose-ecdhe}},
+but MAY result in no network key being returned.  In that case, the pledge enters a
+provisional situation where it provides access to an enrollment mechanism described in
+{{I-D.ietf-6tisch-dtsecurity-secure-join}}.
+
+If using a locally relevant certificate, the pledge will be able to validate the
+certificate of the JRC via a local trust anchor.  In that case, the JRC will
+return networks keys as in the PSK case.  This would typically be the case for
+a device which has slept so long that it no longer has valid network keys and must go through
+a partial join process again.


This makes it clearer that the mechanism is not limited to AES-CCM, but that
negotiation could occur via EDHOC:

https://bitbucket.org/mcr314/draft-ietf-6tisch-minimal-security/commits/627b2bff648ccb9ec47c59d0cd8d710d9b64742b

+The join request is typically authenticated/encrypted end-to-end using AES-CCM-16-64-128
+algorithm from {{I-D.ietf-cose-msg}} and a key derived from
 the shared secret from step 3.
 +This is described in detail in {{I-D.selander-ace-cose-ecdhe}}, which also provides for algorithm agility.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-