Re: [Gen-art] [6tisch] Review of draft-ietf-6tisch-minimal-17

[Tero Kivinen <[e-mail]>]

Kristofer PISTER writes:
> Tero - you bring up a good point that after all of the discussion of
> this issue we have still not done a good job explaining it, since
> it's clear that there are still misunderstandings.

Clearly. 

> The text in section 4.6 says "This specification assumes the
> existence of two cryptographic keys." That is incorrect, and should
> be changed.  I propose "This specification assumes the existence of
> one protocol identifier, P1, and one cryptographic key K2.  P1
> provides no security."

I do not undestand why you want to throw away the protection K1 can
provide?

If you have two cryptographic keys, K1 and K2, they both will provide
protection against different types of attack. K1 makes sure that
no outsider who does not know K1 can create fake EBs. This means that
sleeping nodes waking up and wanting to resync themself to the
network, which has not changed its K1 during the nodes sleep, can do
so by just seeing K1 protected EB.

It also means that there is at least some protection for the devices
already in the network against malicious EBs which could try to change
the network parameters of the network.

If K1 is not secret, then both of these protections are lost.

K2 is used to provide confidentiality and authenticity of the other
messages than EBs.

There is actually no reason why K1 and K2 needs to be separate, but
both of them needs be secret and unique.

> Let me go over the reasoning behind having P1.  Any implementation
> of 6TiSCH has one of
> three choices for message integrity on the EBs:
> 1) use no message integrity
> 2) use a well-known protocol identifiier, with no security value
> 3) use a secret key

And only option 3 makes any sense if any security is needed. If you
are willing to run network without any security you can then go with
option 1 and 2, but don't use them if you want security. 

> There is ample evidence that sending 15.4 frames without message
> integrity is problematic, so we'd prefer not to do option 1.

I think most of that evidence is based on the 802.15.4 frames and not
802.15.4-2015 EB frames with TSCH related IEs.

Yes, getting random garbage looking like 11-21 byte beacon frame with
valid checksum is going to happen every now and then.

Having random garbage with length 48 bytes to match EB with acceptable
TSCH related IEs is much more improbable.

As joining process is only very small amount of the use of the
network, we should not try to optimize the performance during joining
process, and sacrifice the security of the rest of the network use
time.

After the joining process is done, the node knows K1, and then it can
get much better protection against random garbage.

> Option 2 provides no security, but it does provide message
> integrity, and it provides some level of confidence that the sender
> of the frame is using the same version of the protocol that the
> receiver is using.

Yes, it does provide that for the joining process, but sacrifices the
security of the rest of the time, i.e., after the node has joined the
network.

Also option 2 only causes issues for the nodes trying to join the
network. I.e., they might try to join network they think are there,
because they see random garbage that looks like valid EB. So what.
They waste a bit of resources there, but if they see valid EB they can
pick that. Also easy solution to that is to wait for two valid EBs
from the same coordinator before trying to join. I.e., when node sees
first EB, they will know where the next EB can be, so they can jump to
that channel to listen for it and so on on until it finds second copy
of the same EB. After that they can be sure that there is network
there.

They still do not know if that network is correct for them to join in,
but using option 2 does not provide that information either. It only
tells that there is some (or multiple) networks using same P1. And if
we put P1 in the RFC everybody will be using that same P1.

> Option 3 provides all of the benefits of option 2, plus some level
> of security.  It is a fine option, but it assumes the existence of a
> pre-distributed cryptographic key K1, which is a non-starter.

No, it does require pre-distributed cryptographic K1.

It requires clients to join the network without knowing K1, and after
they have joined the network they will learn the K1 and K2, and after
that they can start using K1 and K2 to secure the traffic in the
network.

The 802.15.4 do provide a way for nodes to parse EBs and join the
networks WITHOUT knowing the key used to protect the EB.

Also even if you do know K1, you still cannot use that to protect the
first EB. The first EB contains the ASN, which is needed to validate
the EB, and before the ASN can be read from the IE contained in the
EB, the EB frame needs to be authenticated, which is not possible as
the ASN is not known... I.e., chicken and egg problem.

Because of this the 802.15.4 do allow EBs to be passed higher layer
even if their security processing failed (either because of not
knowing the key to protect it, or not knowing the ASN used to
calculate Nonce). So the higher layer can then take the ASN out from
there, configure that to the MAC layer, and send some unprotected
joining messages to the coordinator, asking to join the network, and
the coordinators are using the SecExempt flag to allow those joining
nodes to bypass the security checks for the incoming traffic for those
joining messages so those messages can be processed in clear tetx even
when everything else is mandated to be protected.

So to repeat this one more time:

Using known K1 or P1 or whatever it is called, is BAD idea, and it is
better to use unique K1, which is distributed to the network at the
same time as K2 is generated for the network nodes. 
-- 
[e-mail]