Kris Pister writes: > > Why do you want to keep unsecure option, that provides a way to break > > security of 802.15.4 in standard? > Drat. You have discovered my secret. I'm an NSA plant trying to provide a > backdoor into future networks. Please don't tell anyone... > > The reality is that I'm trying to make sure that we have a secure MIC > that doesn't require that layer-2 neighbors know each others EUI-64. > All that they need to know is the two-byte short address.
The 802.15.4-2011 do require you to know your neighbors EUI-64 already. Even if you use short address in the nonce, you still need to fill in the DeviceDescriptor and for your neighbors and for that you need to know the extended address of it. You do not need to know the short address, that can be left as 0xffff if you do not know it. 802.15.4-2011 7.2.3 step O uses that information. > Tero, it doesn't seem that we're that far apart. It seems you are talking about some non-802.15.4 systems where you do not know the neigbours extended addresses, but we are talking about 802.15.4-2011 here (and that requirement of knowing the neigbours extended address was there already in 802.15.4-2006 and are still there in 802.15.4rev). > > I have found out that setting A1 (short addresses in nonce) is[...] > > almost impossible [to make secure] when using B1 (when using ASN) > > I'm encouraged by the word "almost". I believe that smart people who > are used to creating standards and understand security will in fact be able > to make link-layer MIC generation secure using short addresses with ASN > in the nonce generation. That changing that would make quite a big changes to the nonce processing for those short addresses, so old implementations would not be compatible anymore. Also there might be some other cases where short addresses in nonce might cause problems that I have not yet found out. Extended addresses are by defination fine, as we know they are defined to be unique (yes, in practice they might not be unique, but for our case they are defined to be unique). Short addresses might not be unique, and they overlap the same area than what extended address, and there are no extra bits there to indicate which address is short address and which is extended address. We could allocate CID (or use the 802.15.4 CID) and define 32-bit prefix to extended address that would indicate that rest of the address is actually PAN id + short address. > * We will specify exactly how short addresses are zero-padded. How > could we possibly do an interop if we didn't? That was my first clue, that people who defined this didn't really think this part of the 802.15.4e completely, and then I noticed other problems with it (no PAN id, short address are not required to be unique, overlapping with extended addresses etc). > * Keys will be generated randomly. If we are worried that 128 bit > link keys will be the same between two networks, then we have *much* > bigger problems to worry about than the possibility of nonce re-use. No. Keys are generated randomly, but they might also be shared between the different PANs. I.e. if you use cluster tree network, the different PANs are part of the same network, but they just use different PAN coordinator, and PAN coordinators create a tree between them. In that kind of network the device might actually move from one part of the network to other, and it might be useful to share the same key for the whole network. There is no requirement in 802.15.4 that keys cannot be shared between different PANs. Note, that if different TSCH PANs shared keys, they also must share the ASN. If the TSCH PANs do not have synced ASN, then they MUST NOT share keys. It might be that nobody uses multiple PANs for TSCH, but it is not forbidden in the 802.15.4 so we either need to make it work, or explictly forbid it. > * For layer-2 MIC nonce formation, only 2 byte addresses will be used. > There > will never be a conflict between a 2 byte address and an extended address. The text does not say so. 802.15.4e says short addresses in nonces are used only and only if the frame source addressing used short addresses. If the frame was sent using 64-bit extended address, then nonce generation is using 64-bit extend address. Note, that nodes joining the network might not yet have a short address, so they have to use extended address until they get the address. Also orphaned device who have lost their short address, need to use extended address to talk to the PAN coordinator to be able to get new one. As the text in 802.15.4e is written frames can use short or extended address when generating nonce selected per frame > >> Your solution is to propose that we remove the knobs [...] > > No, I am removing unsecure options [...] > You are not removing unsecure options, you are removing a secure, > efficient, proven way to do link layer MICs. I have already pointed out it is not secure as defined in 802.15.4e. Your claims have been that someone at somepoint must have checked it out, and they must have said it is secure as it has been in use. > You are worried about things that will never occur in practice, > because 6tisch will explicitly prevent them from happening. Where does 6tisch say we never ever use extended address as source address of any frame? This makes joining and network resync really hard... For example how do you send association response mac command frame, when it is specified to have both source and destination addresses as extended addresses? Same for disassociation notification command? Or does the 6tisch use something completely different for those commands during the joining phase. If so, what source address does they use in that case because they do not yet have short address they can use. In the draft-ietf-6tisch-tsch section 3.1 Network formation says that "This might include a mechanism to assign a unique 16-bit address to a node, and the management of initial keying material." which would indicate that short address assignment is not mandatory. Yes, I know that when devices are part of the schedule and have their own dedicated links they must have short address, but not all nodes need to have dedicated links, some devices can also use those shared slots and in such case there is no reason why they could not use extended addresses, or even be in state where they do not have short address at all. Note, that short address management inside the PAN gets quite complicated when you cannot use extended address for any secured frames. > You are trying to make a change that will require additional bytes > to be sent in configuration packets, with no security benefit. I'm > against sending bytes in low power networks for no reason. Those bytes are already mandatory because 802.15.4-2006/-2011/-rev sets this requirement that device must know the extended address of the node sending him any secured frames. I did assume that we were using the 802.15.4-2011 + 802.15.4e as a baseline, but you are saying this is not true, but instead we use something that is almost like 802.15.4, but not really? -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
