* 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:
>> 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. 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 wouldargue 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 tosquare one. ksjp On 4/24/2015 5:24 AM, Tero Kivinen wrote:Kristofer PISTER writes: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...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._______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
