Pascal Thubert (pthubert) writes: > We disagree on this pass but you have my arguments and I have yours. > What's new is that we also disagree that this problem that minimal > should deal with.
What is this problem you are talking about here? > The problem has to do with a deployment decision that is made or not > made elsewhere, and that may or may not be allowed by the security > design. This does not yet tell me the problem you are now talking about. > If K1 is known to the joining node, even well-known, then the > deployment can adjust the MIC size to make undetected transmission > errors really-really rare. Yes, I agree that. On the other hand I do not think this is important for minimal. I would much rather use K1 to properly authenticate EBs AFTER the initial join process, which requires it not to be well-known. > Thus the conclusion of our discussion so far is: > - The poor frame error protection (FCS-only) is a generic problem > that is only present if the security design allows for K1 to be > unknown by the joining node. We are talking about few dozen frames DURING the initial bootstrap phase. You need really crappy network to get that many errors which pass the FCS, to cause the bootstrap to fail, and even then you need bad implementation of the parser who is parsing the frames to get messed up with those. If there is that crappy network, then most likely the network will not work at all, as most of the frames will be dropped by bad FCS. I.e. if you get 1 wrong bit every 1000 bits, that means that you have an have one error in most of your full length frames. To get another error to the same frame in such way that the FCS still matches will still not be very probable. Someone can probably calculate that. Your case of there being billions devices out there all time, is not really valid, as there will be only few hundred of those billion devices doing "the once in the lifetime joining process" at the same time (assuming 10 year lifetime of devices and joining process taking hundred seconds). We are not talking FCS protecting normal data traffic, we are talking about the FCS protecting the about 10-20 frames used during the bootstrapping phase. Actually the joining process running KMP or similar will of course validate all data sent inside KMP when doing authentication, so the the frames where errors can cause problem is the EBs. You need to get one EB received properly to be able to start joining the network. Even in EBs, most of the errors will cause the frame to be ignored (i.e. if there is anything wrong with the IE lengths or IE IDs etc then frame most likely will be ignored). Even if EBs had errors, and because of that joining process failed, that simply means we start the process from beginning, and try again. > - The case of an attacker that is willingly settings bits wrong in > EBs is present if the security design allows for K1 to be unknown > OR well-known by the joining node. Yes, for joining. But for rejoining after you have already been part of network, or cases where network is reconfigured etc, having a proper K1 will prevent attackers from doing nasty attacks, but using well-known K1 will not. > About your new points: > > > No, but it is much more likely to have the attacker flipping those > > bits intentionally to get worst possible effect, than them getting > > flipped randomly so that the FCS still matches. > > Why would he need to match the FCS? If the MIC is unknown then it > can send whatever it likes and then compute a CRC over it. For attacker yes, but for random bit errors the case is different. I.e. to get two random bit errors to same frame, so that FCS still matches, does not happen that often. The story about Zigbee and WireHART is completely different to that, as both devices of course did calculate proper FCS, thus Zigbee devices did properly receive the WireHART packets, and then got messed up when their implementation didn't know what to do with them. > > I.e. the implementations MUST be able to cope with EBs having > > worst possible values regardless wheter the EBs are protected by > > the well-known key or no key at all. > > Is that written in 802.15.4? No, that is general wisdom of writing code. I know this is new to some people writing code (especially in IoT space), but you really should validate stuff that you receive before you act on it... :-) > That is not an upper layer problem. Actually it is upper layers problem. I.e. when the device does scanning the MAC will simply pass beacons to the next higher layer and the next higher layer will then parse IE lists etc to check if the beacon is acceptable. I.e. this filtering is something we need to specify in 6tisch, as 802.15.4 does not provide that. > All that minimal should really have to say is that its security is > only as good as the L2 security will be because there is no > additional L3 security to protect, say, RPL. I.e if there is no L2 security because well-known key is used there is no security at all in minimal? > > And, yes the security considerations section of the minimal should > > explain what kind of attacks can be done by sending "bad" EBs, and > > how those issues can be solved. > > If we allow for well-known or unknown K1, yes, I agree that we need > that analysis for anything 6TiSCH, not minimal specifically. So writing that now is something we should get ongoing. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
