Hi Tero, 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.
Robert On 18 May 2015 at 15:00, Tero Kivinen <[email protected]> wrote: > Robert Cragie writes: > > > EBs CANNOT be encrypted in TSCH. To be able to decrypt the EBs the > > > receiving node would need to know the ASN, but it cannot know it as > > > the ASN would be in the encrypted part of the EB. Because of this EBs > > > cannot be encrypted when using TSCH. > > > > > > This is fundamental property of the TSCH, it is not something we > > > choose not to do. > > <RCC>The ASN can be placed in the frame counter field in the aux. > > security header and frame counter suppression set to 0 so it can be done > > No it cannot. > > 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> 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> > > 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> > > > - 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> > > > Clearly frame counter suppression can be used if encryption is not used > > and the ASN used directly as he frame counter.</RCC> > > Clearly it would be against the "shall" in section 7.3.2 which says > that ASN shall be used regardless whether the auxiliary security > header has frame counter or not. > <RCC>I think it can be interpreted otherwise - see above</RCC> > > 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> > 2) There is no way to syncronize to the TSCH network if encrypted > beacons are used, as TSCH syncronization IE is payload IE, and it > would be encrypted, and for decryption you would need ASN, which > you do not have => encrypted beacons cannot be used. > > Again if the 802.15.4e would have been written differently then > encrypted beacons could have been used (i.e. if the ASN would always > be transmitted in the auxiliary security header in frame counter > field, or if the TSCH syncronization IE would have been header IE > etc). > <RCC>It does seem odd to me how it is written</RCC> > > > > We should most likely also explain that even when data integrity > > > service is provided for the EBs, the receiving devices are able to use > > > EBs while joining the network even when they do not know the key used > > > to protect the EBs. I.e. that 802.15.4 do have special rules that this > > > is allowed even when normally frames which you do not have key for are > > > dropped. > > <RCC>This is why it is important to distinguish the properties of adding > > integrity protection to the beacon using key K1 and dispel any notion of > > "security" using this key, unless it is strictly confidential and can be > > distributed in a secure manner, something clearly not mandated. Any > > integrity protected beacon processed by a node which does not have the > > key can only use the fields as a hint as it cannot authenticate the > > beacon and thus the data should be taken "with a pinch of salt" or, to > > use Rene's expression, "at face value"</RCC> > > Yes. On the other hand after it has K1 it can immediately verify the > parameters, and it can then pick correct network immediately and > mostly trust the information it provides. > <RCC>It depends entirely on the property of the key. If it is well-known, you can't trust anything and it is not much better than no security (it is basically a better CRC)</RCC> > It cannot trust that the information is not replays unless it knows > the ASN, but sending any frame and getting response back to it will > only work if the ASN was correct (provided that the response is > related to the request, i.e. it cannot be something that attacker has > also recorded from the last time). > > 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> -- > [email protected] >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
