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

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Mar 2017 17:46:36 -0500

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Mališa Vučinić <[email-masked]>
Date: Fri, 10 Mar 2017 13:10:49 +0100

> On 09 Mar 2017, at 23:46, Michael Richardson <[email-masked]> wrote:
> 
> 

Sounds good. What happens in the case when the EB does not contain Network ID extensions. Should we just default to minimal?

> +a partial join process again.

I am confused here. A node that sleeps so long that it no longer has valid network keys can just repeat the Simple Join Protocol, i.e. the join request/response exchange. It does not need to perform a new EDHOC handshake because we can assume that the session key with JRC is still valid, no? 

> +This is described in detail in {{I-D.selander-ace-cose-ecdhe}}, which also provides for algorithm agility.

Good catch for crypto agility. Will you make a pull request with these changes so that I can integrate them before publishing -02? 

Mališa

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Mar 2017 11:39:41 -0500

Mališa Vučinić <[email-masked]> wrote:
    >> +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}}.

    > Sounds good. What happens in the case when the EB does not contain
    > Network ID extensions. Should we just default to minimal?

If it doesn't have that ID, then there probably isn't a Join Proxy available
on that network.  As minimal-security does not have another way to find the
Join Proxy, a pledge should ignore that EB.

    >> +{{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.

    > I am confused here. A node that sleeps so long that it no longer has
    > valid network keys can just repeat the Simple Join Protocol, i.e. the
    > join request/response exchange. It does not need to perform a new EDHOC
    > handshake because we can assume that the session key with JRC is still
    > valid, no?

It could try such a thing, yes, I agree.

It might also have moved enough that it can no longer speak to the same JRC.
The JRC might have restarted, etc.  The point is that if you have locally
verifiable certificates, then you can use them.  I don't know how OSCOAP
is going to securely signal when the secrets are no longer available.

    >> This makes it clearer that the mechanism is not limited to AES-CCM,
    >> but that negotiation could occur via EDHOC:
    >>
    >> +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.

    > Good catch for crypto agility. Will you make a pull request with these
    > changes so that I can integrate them before publishing -02?

done.