Subject: [6tisch] EBs are only used in joining, not normal operation (Re: a little puzzle)

From: Kristofer PISTER <[email-masked]>
Date: Thu, 23 Apr 2015 09:52:42 -0700

Charlie is excited to hear more about option 4! :)

> Use MICs on EBs, with a secret key distributed during the joining
> process, and add vendor specific IE to identify the network.

This seems like a chicken and egg problem.  In order to get the secret key
for the EBs, you need to
go through the joining process...which starts with receiving an EB...

I think that the confusion here is in thinking that EBs are involved in
normal network operation.  They are not.
EBs are just used during joining, to get a new mote aware of the existence
of a network, so that it can go through
the joining process, and receive the secret keys that are used in normal
network operation.
Having Mallory forge EBs does NOT mess up the existing network.  No mote
which has joined the network
is listening to EBs.  EBs are not used in synchronization of motes that are
already in the network, or anything
else.  EBs are just used to initiate the join process, and nothing more.

Once motes are joined to a network, they use a randomly generated secret
key(s) K2.  They do not use EBs for anything.

ksjp

On Thu, Apr 23, 2015 at 6:48 AM, Tero Kivinen <[email-masked]> wrote:

> Kris Pister writes:
> > Alice and Bob make wireless temperature sensors that run a 6tisch stack.
> > Charlie owns a nationwide chain grocery store and is rolling out 6tisch
> > everywhere.
> > Zelda sells wireless toys that use 802.15.4e.
> > Mallory is always lurking.
> >
> > Charlie needs to decide if and how to use message integrity checks on
> > enhanced beacons.
> > He thinks that he has three options:
> > 1) don't use MICs on EBs.
> > 2) use MICs on EBs, with a secret key
> > 3) use MICs on EBs, with a well-known key
>
> But the best option is to use option 4
>
> 4) Use MICs on EBs, with a secret key distributed during the joining
>    process, and add vendor specific IE to identify the network.
>
> In this case the EBs are authenticated with MIC, but when the Alice
> and Bob's devices try to connect it they do not know the key, so they
> cannot verify the authentication information, but as the frames are
> not encrypted they can still see the vendor specfic IE, and check that
> it matches what they expect it to match.
>
> This way they will be able to filter out EBs which they want to hear.
> I.e. after finding the EB which has suitable IE they start joining
> process  to that network. During that joining process they will get
> the secret key used to protect the EBs and secret key used to protect
> the normal data traffic.
>
> After that they can use the draft-ietf-6tisch-minimal to talk to the
> network, and they can use it securely as they can now authenticate the
> IEs sent in the EBs, and they know Mallory cannot fake those, as
> Mallory does not know the secret key, so they do not need to do any
> other protocol.
>
> If they would be using the option 3, they cannot trust anything EBs
> have, thus they cannot use draft-ietf-6tisch-minimal at all, as
> Mallory could mess up the network very easily by just sending few EBs
> with wrong data in IEs.
>
> Also now as the Charlie has IE which is used to separate the networks
> from each other, when it makes new network used for its cashier
> machines, and it does not want to share the cashier machine keys with
> the temperature sensors it wants to use different keys, and it also
> wants to make sure that the temperature sensors do not needlessly try
> to join the other network, he can just use different content for that
> IE. Also as the those two networks use different secret keys, both
> networks can trust the data sent on their EBs. This EB secret key is
> different for every site, and might even be rekeyed every now and
> then.
>
> And yes, Mallory can still send fake EBs with same IE content, trying
> to trick the temperature sensors to join his network, but as the
> joining process authentication fails, the temperature sensors will not
> join his network, but try to find better network i.e the real network.
>
> > But if Charlie uses option 3, a well-known key, Mallory will be able to
> > spoof EBs.
> > Of course, if he uses no MIC at all, Mallory will also be able to spoof
> EBs.
>
> And if Mallory can spoof EBs he can easily mess up the network
> completely. This also means that devices cannot use
> draft-ietf-6tisch-minimal as they cannot trust anything that is sent
> in the EBs, so some other protocol is used to know even the shared
> slots used to talk to anybody.
>
> > What should Charlie do?
>
> Use option 4...
> --
> [email-masked]
>

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 24 Apr 2015 00:38:59 +0200

+1

I feel very unconfortable with the idea of receiving a packet for which
authentication fails, but nevertheless use the data inside it. I know that
you can read the 15.4 state machine to do this, but I just disagree with it
completely.

Option 4 involves a secret key for EBs which the joining node doesn't have,
but then trusts the EBs nevertheless, and then learns the key from the JCE
when it's already joined. I don't get why this offers any more security
than no MIC at all.

On Thu, Apr 23, 2015 at 6:52 PM, Kristofer PISTER <[email-masked]> wrote:

> is listening to EBs.  EBs are not used in synchronization of motes that
> are already in the network, or anything
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 24 Apr 2015 08:27:39 +0000

+1 as well.
I like the idea of K1 with the notion that the stack understands the granularity of security that it gets.
I understand from René that today, the upper layer code path may be the wrong one if there was crypto as opposed to in-the-clear.
I gather that there may be a need to specify something there so that the quality of the key is qualified for upper layers to proceed accordingly.
This being said:

If K1 is hardcoded in the standard, we are getting a standard compatibility check (an Ethertype of sorts) and a MIC
If the admin overrides K1 with a largely shared key within his admin domain, we are getting an administrative subnetting and a MIC
If the admin tightly controls the distribution of K1 to a few well–managed devices, we can encrypt the beacons and we are getting a rather protected network that leaks minimal information on its operation.

I’m reading that that if we encrypt the beacon, and the nonce containing the ASN is needed to decrypt, then we need to get the ASN some other way, or we need to leave some piece of the frame in the clear, which CCM* could do if that’s what we want to do. I’m not sure I have the full story there but that looks OK. Lots of flexibility there.

The alternate to K1 seems to be a new IE with a managed network ID + a MIC that cannot be verified until later in the process.
Pro of the alternate: absolute network identification as opposed to potential 10 ^MICsize error. Con: more bytes in the air, and no protection against transmission errors until the key is obtained.

As a human, I’m bad at fathoming very large numbers, but the chances that the K1 key that a device has matches a frame from the wrong network and then that the frame still looks good baffles me. And if that happens, probably the beginning of the join process will discover the mismatch anyway, so the ultra-rare occurrence would only delay the join, not screw up things. So the alternate does not look like a great competition to K1.

What am I missing?

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: vendredi 24 avril 2015 00:39
To: Kristofer PISTER
Cc: [email-masked]; Tero Kivinen
Subject: Re: [6tisch] EBs are only used in joining, not normal operation (Re: a little puzzle)

+1

I feel very unconfortable with the idea of receiving a packet for which authentication fails, but nevertheless use the data inside it. I know that you can read the 15.4 state machine to do this, but I just disagree with it completely.

Option 4 involves a secret key for EBs which the joining node doesn't have, but then trusts the EBs nevertheless, and then learns the key from the JCE when it's already joined. I don't get why this offers any more security than no MIC at all.

On Thu, Apr 23, 2015 at 6:52 PM, Kristofer PISTER <[email-masked]<mailto:[email-masked]>> wrote:
Charlie is excited to hear more about option 4! :)

> process, and add vendor specific IE to identify the network.

This seems like a chicken and egg problem.  In order to get the secret key for the EBs, you need to
go through the joining process...which starts with receiving an EB...

I think that the confusion here is in thinking that EBs are involved in normal network operation.  They are not.
EBs are just used during joining, to get a new mote aware of the existence of a network, so that it can go through
the joining process, and receive the secret keys that are used in normal network operation.
Having Mallory forge EBs does NOT mess up the existing network.  No mote which has joined the network
is listening to EBs.  EBs are not used in synchronization of motes that are already in the network, or anything
else.  EBs are just used to initiate the join process, and nothing more.

Once motes are joined to a network, they use a randomly generated secret key(s) K2.  They do not use EBs for anything.

ksjp

On Thu, Apr 23, 2015 at 6:48 AM, Tero Kivinen <[email-masked]<mailto:[email-masked]>> wrote:

> Of course, if he uses no MIC at all, Mallory will also be able to spoof EBs.

Use option 4...
--
[email-masked]<mailto:[email-masked]>

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 24 Apr 2015 15:24:43 +0300

Kristofer PISTER writes:
> This seems like a chicken and egg problem.  In order to get the
> secret key for the EBs, you need to go through the joining
> process...which starts with receiving an EB...

Yes, and the problem is what?

The EBs are MICed, but encrypted, which means that the device can
receive them and parse them.

During the active or passive scan when the device receives the secured
EB they will try to unsecure them, but even if they cannot, they will
store information from the EB, and they can still join the network:

>From 802.15.4-2011:

5.1.2.1.2 Active and passive channel scan

...
	The information from the unsecured frame shall be recorded in
	the PAN descriptor even if the status from the unsecuring
	process indicated an error
...

Only difference in the 802.15.4rev-DF5 is that it talks about the
"frame to be unsecured" instead of "usecured frame", as the security
processing will not set the "unsecured frame" if the security
processing failed. The "frame to be unsecured" is the input to the
security processing.

> I think that the confusion here is in thinking that EBs are involved
> in normal network operation.  They are not.

I have understood that draft-ietf-6tisch-minimal plans to use them
also in normal operation. I.e. if you do not want to have any
dedicated timeslots, and only want to keep track of the network, just
in case someone wants to talk to you, you listen the EBs and thats it.

Perhaps I am mistaken. 

> EBs are just used during joining, to get a new mote aware of the
> existence of a network, so that it can go through the joining
> process, and receive the secret keys that are used in normal network
> operation.

Thats one use of them. They are also needed when you need to rejoin
the network to know the ASN. And also during the normal operation they
are used to keep track of time, i.e. if you are using frame-based time
synchronization you can sync your time when you receive EBs from your
time parent. 

> Having Mallory forge EBs does NOT mess up the existing network. 

It will if he for example creates PAN ID conflit. On the other hand
currently he can do that even when he does not have proper keys, so
here protecting EBs will not help. 

> No mote which has joined the network is listening to EBs. 
> EBs are not used in synchronization of motes that are already in the
> network, or anything else.  EBs are just used to initiate the join
> process, and nothing more.

Which parts of the 802.15.4 specification is saying that? I have not
found any text claiming EBs in TSCH to be limited for only that. 

> Once motes are joined to a network, they use a randomly generated
> secret key (s) K2.  They do not use EBs for anything.

That will limit TSCH networks to be very small networks. I.e. you
cannot have network with tens of thousands mostly listen only sleeping
sensor nodes in slow polling mode.

Networks with more than 65534 nodes is completely out of question as
to be able to allocate schedule you need to have short address, and
there is only 65k of those.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 24 Apr 2015 15:27:15 +0300

Thomas Watteyne writes:
> I feel very unconfortable with the idea of receiving a packet for
> which authentication fails, but nevertheless use the data inside it.
> I know that you can read the 15.4 state machine to do this, but I
> just disagree with it completely.

This is explictly allowed in 802.15.4 just to allow joining secured
networks, and still allow EBs to be protected for those who are
already part of the network. 

> Option 4 involves a secret key for EBs which the joining node
> doesn't have, but then trusts the EBs nevertheless, and then learns
> the key from the JCE when it's already joined. I don't get why this
> offers any more security than no MIC at all.

For joining device it is exactly same as what option 1 and 3 are, i.e.
he cannot trust EBs as the sender of EB and joining device do not have
trust assocation with each other yet.

For nodes who are part of the network, it is same as option 2, i.e.
they know that only members of the network can fake EBs, and they can
trust them.
-- 
[email-masked]

---

From: Rene Struik <[email-masked]>
Date: Fri, 24 Apr 2015 09:47:56 -0400

Dear colleagues:

Yesterday late, I returned from a 2-week trip, so did not have the 
chance yet to go over all emails accumulated over that time. I hope to 
catch up on 6tisch matters in the next few days.

I did notice lots of emails surrounding 802.15.4 security (or 
perceptions thereof), but I do not entirely understand the background of 
these emails.

Since some emails seem to repeat similar discussions in December 2014 
(including confusions and misconceptions of 802.15.4 security), I would 
like to encourage everyone to read the draft
draft-struik-6tisch-security-architectural-considerations-01 (posted 
January 9, 2015). I wrote this draft partially in the hope that we would 
not have the very repeat of arguments we now seem to witness. So, I 
highly recommended reading that 3 1/2 months old draft and only bring up 
topics not already dealt with there.

Best regards,

Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Kris Pister <[email-masked]>
Date: Fri, 24 Apr 2015 10:58:16 -0700

> also in normal operation.

The text in minimal-06 reads
"EBs should not in general be used for synchronization."

In -07 we should certainly change that to caps.  I'm guessing that Tero 
would
argue that it should be MUST NOT instead of SHOULD NOT.  I would agree.

I note that draft-ietf-6tisch-tsch-06 generally describes this process well,
but does include one sentence which should be removed:
"Nodes can keep synchronization exclusively by exchanging EBs."
This either needs to be explicitly not allowed, or Charlie has to go 
back to
square one.

ksjp

---

From: Robert Cragie <[email-masked]>
Date: Mon, 27 Apr 2015 16:39:31 +0100

I agree this is mostly covered in 
draft-struik-6tisch-security-considerations. Where I think we have got to:

* The overhead of adding security to a beacon is minimal, so we may as 
well add it (i.e. forget option (1)).
* EBs are only used for joining and coarse synchronization (if any 
synchronization at all)
* It usually makes sense to add steering data to the beacon in addition 
to any security to assist joining devices
* Joining devices can still process a beacon secured with a key they do 
not possess but can only use the data as a hint

With regard to beacon security, of course it all comes down which key is 
used to process the beacon and what properties we expect of it.

a) If the key is very well-known (some default), then it offers little 
benefit over an unsecured beacon. This may be OK for Zelda and would 
potentially stop Alice and Bob's devices (expecting something other than 
a very well-known key) from steering to Zelda.

b) Charlie could use a reasonably well-known key, i.e. exclusive to 
Charlie but not intended to provide for any real security purposes other 
than purported identity and freely distributed. It may still be enough 
to generally steer Alice or Bob's sensors to the right network, 
especially used in conjunction with additional IEs which Charlie could 
add to the beacon to assist steering. Mallory can probably spoof such a 
beacon but it is assumed the subsequent authentication process will fail 
and Mallory will not be able to honeypot well. Alice and Bob will have 
to set this key in their devices.

c) Charlie could use a less well-known key, specific to, say, an 
installation. This would require some sort of out-of-band provisioning 
mechanism but would make steering much more precise. Mallory is unlikely 
to be able to spoof a beacon easily

This all comes down to how practical it is to pre-provision a key. In 
the very well-known/reasonably well-known case, it is likely to be done 
at the factory. In the less well-known case, it is likely to be done at 
a commissioning stage. This means that a joining device doesn't 
necessarily have to take the beacon at "face value" as expressed in 
draft-struik-6tisch-security-considerations; it depends how the key is 
provisioned.

Note also that even if a joining device does have a key, it doesn't know 
the frame counter (ASN) of the device emitting the beacon so it has to 
accept the first one it hears anyway. This could be Mallory replaying a 
beacon from a device the joiner can't actually hear so some malice is 
still possible.

Robert

On 24/04/2015 18:58, Kris Pister wrote:
> In -07 we should certainly change that to caps.  I'm guessing that 
> Tero would