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.
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.
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.
> - 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.
> 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.
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.
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).
> > 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.
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.
--
[email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
