Robert Cragie writes: > Comments line. Basically, I don't think it is clearly written in > 802.15.4e and there seem to be a lot of assumptions made.
That I agree on... > On 18 May 2015 at 15:00, Tero Kivinen <[email protected]> wrote: > The 802.15.4e says clearly that ASN is used instead of Frame Counter > sent in the aux field when using TSCH mode: > > In TSCH mode, the Frame Counter shall be set to the global > frame counter value, i.e., the Absolute Slot Number as > described in 5.1.1.5.2, regardless of whether the frame > counter is carried in the auxiliary security header. > > <RCC>I don't think it is clear at all. This section is talking about the frame > counter used for the nonce. At the point this is use for synchronization, it > could easily be interpreted that the synchronizing device does not have a > value at all for ASN as it hasn't synchronized yet. Therefore it would be > quite legitimate to use a value in the frame counter field of the auxiliary > security header at this point</RCC> If we assume that node that is not part of the network yet, and wants to see encrypted EB, it needs to generate nonce using the ASN it does not know, and that text above clearly says that we never use Frame Counter to generate the Nonce, we always use ASN which we do not know... > I.e. sending Frame Counter in auxiliary security header does not have > any effect as it is always ignored. Because of this there is Frame > counter suppression bit in the security control field, and in TSCH it > is always set. > > <RCC>Where does it say this in the specification? I don't see it anywhere.</ > RCC> The frame counter is used for two uses in 802.15.4. One is nonce generation. When in TSCH mode the frame counter is never used for that. The another is replay protection in the inbound security filtering. It is true that 802.15.4e does not say that Frame counter is omitted when using TSCH mode, but when I asked that from the people they did say that frame counter is always supressed when using TSCH. I.e. this is my understanding of the issue based on the people who are using TSCH. If this is not true, then comment now, as we did add lots of text in the security section making frame counter processing to be skipped if TSCH mode is used, and also actually stating that frame counter suppression is used when TSCH mode is used. Using both frame counter and ASN would provide proper replay protection, that that would also mean that we would need to add extra 4 bytes to each frame, and we could not use frame counter supression. Note, that ASN cannot be used as replay protection as it does not protect against duplicate retransmissions. I.e. to provide full replay protection the TSCH would need to generate nonce using the ASN, and add the normal 4-octet frame counter to the frame and use that only for replay protection. > So even if you would set frame counter suppression bit to 0, the Frame > Counter value in the auxiliary security header shall be ignored, so it > does not matter what you put there. > > <RCC>I think it can be interpreted otherwise - see above</RCC> The text saying that Nonce is always generated using ASN regardless of whether the frame counter is carried is quite clear. I assume you are saying that when node receives encrypted EB frame, it could take the frame counter from security auxiliary frame, and then generate ASN from there, and then run the incoming frame security processing, and generate nonce from the newly generated ASN? This could be possible, but I do not think there is anything in the 802.15.4 that even hints that you should do that, but there is the text above which at least for my understanding forbids that. > > - surely that is the point of having a 5-octet frame counter available? > > I have no idea why they provided 5-octet frame counter option, as it > cannot be used for TSCH. If they meant that ASN could be sent in there > too, then they would not have needed ASN in the TSCH syncronization IE > at all. > > <RCC>It seems odd that ASN is in a payload IE which can of course be > encrypted. Why not put it in a header IE? In this way, it could be possible to > encrypt parts of the beacon. As it stands, this seems impossible if the > current assumptions about TSCH is true.</RCC> Yes. But I think it is too late to change that now. Also as people seem to be indicating that there is no use for EBs after the join process, and that might be the reason they didn't see reason to encrypt them. There is lots of hidden assumptions behind 802.15.4e which were not written down, thus it is hard to try to understand why it was designed as it designed. And again, I myself would think there would be valid reasons to encrypt and MIC EBs with proper key, but as far as my understanding of 802.15.4e is, it is not really possible to encrypt them as the specification is written now. > So as defined in the 802.15.4e: > > 1) when using TSCH ASN is always used in the nonce generation, thus > there is no point of transmitting frame counter in auxiliary > security header => there is no reason to ever turn Frame counter > suppression off for TSCH. > > <RCC>Again, a synchronizing device may not have a valid representation of ASN. > Something carried in a field is not a device's own ASN, it is a remote > device's ASN</RCC> There is only one ASN. It is by definition global absolute sequence number, thus there is no such notion of device's own ASN or remote device's ASN. There is only one ASN... > On the other hand we did notice during the Vancouver meeting that TSCH > does not really provide full replay protection. > > The reason is that normally replay protection is provided because the > Frame counter is increment for each frame and even if frame is > retransmitted it is always retransmitted with same frame counter. Now > the receiver will know if it has seen this frame before, and will drop > it if the frame counter is not new. > > With TSCH this does not work, as the frame counter is not used, but > ASN is used, thus the frame must be CCM* transformed again every time > it is retransmitteed, as the ASN has changed. Thus there is no way for > receiver to detect whether this is retransmission or not, the ASN is > always new. So if the ack is lost and sender retransmits the frame > then duplicate frames will be received by the other ends next higher > layer. > > Attacker can of course cause the acks to be lost, so it can cause > several duplicates to be passed to the next higher layer. So attackers > cannot replay old frames, but they can cause sender to resend their > frame multiple times, and cause those duplicate frames to be passed to > the next higher layer. > > <RCC>This seems completely wrong and conflicts with the clarifying text added > in section 5.1.6.4.3 in 802.15.4-2011. Retransmitted frames should use the > same frame counter. It is almost impossible to use a nonce based solely on > what is effectively implicit data at this level of granularity There almost > always needs to be some additional explicit data.</RCC> With TSCH we cannot use the same frame counter, as the frame counter must always match the current ASN. I.e. if I transmit frame with ASN 54, and do not get ACK back. My next slot I can use to retransmit that frame is ASN 67, I need to encrypt the frame again using the new ASN, as otherwise the receiving device cannot properly decrypt and authenticate it, as it WILL use current ASN 67 when generating nonce for decryption. The reason we noticed this issue with TSCH was that someone made comment for changing the text from 802.15.4rev from: When a frame with the Security Enabled field set to one is retransmitted, the frame shall be retransmitted without changes and without passing through the outgoing frame security procedure, as defined in 9.2.1. to such that it would say "... frame may be retransmitted ...". That comment was rejected, because that would break the replay protection, but then I realized while processing that comment that this case do have problem with TSCH, because in TSCH when we do retransmission we will transmit it using different ASN, and nonce needs to be generated again and encryption needs to be done again. So for the resolution for that is going to be changing that text to be: When not using TSCH mode, and a frame with the Security Enabled field set to one is retransmitted, the frame shall be transmitted without changes and without following the outgoing frame security procedure, as defined in 9.2.1. When using TSCH mode, and a frame with the Security Enabled field set to one is retransmitted, the frame shall follow the outgoing frame security procedure, as defined in 9.2.1. And then we add text to the CCM* nonce for TSCH mode saying: When TSCH mode is enabled, the nonce needs to be generated again for each retransmission, thus receiving device has no way of distinguishing whether the frame is retransmission or not from the ASN. So full replay protection in TSCH mode is not provided. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
