Great summary Tero, thank you. Can you say more about the reasoning behind "Disallow short addresses in Nonce generation" ?
ksjp On Thu, Apr 2, 2015 at 3:36 PM, Tero Kivinen <[email protected]> wrote: > While I was doing the latest recirculation ballot for 802.15.4rev, I > noticed something that can affect 6tisch, my comment and proposed > resolution is: > > My Comment: > > The TSCH pan formation should include not explaining that > beacons can be secured, but if they are encrypted new devices > cannot see the IEs and cannot join the network at all. > > Proposed Change: > > Add note: “TSCH beacons cannot be encrypted, they can only be > authenticated. This is because if the beacons are encrypted, > then the TSCH Synchronization IE used to transmit ASN to > joining devices will be encrypted. The joining (or devices who > has lost synchronization with network) need to know the ASN > before they can decrypt the beacon frame, thus they cannot > decrypt the beacons and cannot join the network using > encrypted beacons..” > > I.e. this will affect the question whether the beacons can be > encrypted with default key, which was one of the suggestions for the > 6tisch drafts. > > This is something that is unchanged since 802.15.4-2011 and > 802.15.4e-2012, i.e. the TSCH ASN has been carried in the Payload IEs, > and Payload IEs are encrypted if security level >= 4. And to be able > to decrypt the payload, you need to know ASN, which you cannot see as > it is in encrypted part... > > The reason for this email is that people pointed me that there has > been discussion about what changes there has been in the revision that > would affect 6tisch and this is the latest one I found (just adding > text stating the fact that has been true already before). > > There is also changes that might affect implementations, and those > changes are fixing security issues: > > * Disallow short addresses in Nonce generation > > * Removal of encrypt only mode (this caused easy way to attack > TSCH mode, i.e. attacker could pick any encrypted and > authenticated frame from the air, remove the MIC, change the > security level in header to be encrypt only, then modify the > packet at will, and then send it to final destination, which > would then decrypt and receive the frame without noticing > anything, this was not problem for non-TSCH mode, as > security level was used to generate Nonce). > > * Adding ability to filter whether MAC acts on information > elements. The 802.15.4e didn't add any method of saying > whether we should process information elements we receive in > the frame. I.e. the implicit default was that they were all > processed by MAC. > > * Fixes in the inbound security processing to clearly allow > unsecured and secured frames to be processed at the same > time. > > * Fixes in the inbound and outbound security processing for > TSCH saying that we do not keep normal 32-bit FrameCounter > when using TSCH mode, 802.15.4e didn't modify anything in > inbound or outbound security porcedures, meaning that > outbound processing rules still kept incrementing 32-bit > macFrameCounter for each outgoinf frame, and stopping at > counter error when it reached max value, even when it is not > used at all in TSCH mode. Also in the inbound rules it did > still got the frame counter from frame (not there in TSCH) > and compared it against previous value etc... > > * Defined how new frames added in 802.15.4e are actually > encrypted and MACed, the 802.15.4e did not modify the table > 53 listing private and open payloads, thus it was not clear > how those are encrypted etc. > > * Changed the MAC command identifier to be encrypted for frame > versions 0b10. MAC command fames with Frame versions 0b10 > can have payload IEs, and those are encrypted. The MAC > command identifier is after Payload IEs, and it would be in > clear, then the device would need to first n-bytes of the > frame (n is unknown, before the frame is decrypted, because > payload IEs have termination IE at the end), then get next > byte as is, i.e. without decrypting it, and then decrypt > rest of the frame. When polled from the 4e implementors they > said they do nto do that, but they will encrypt and decrypt > the MAC command identifier too for frame version 0b10. This > also caused changes to the inbound state machine as now we > cannot run filters based on the MAC command identifier for > MAC command frames before we decrypt the frame. > > * Most likely still something more that I have forgotten... > And of course some changes which do not affect TSCH, or > which do not affect old devices (like adding new > secFrameCounterPerKey property for key). > > Ps. I have been too busy to really follow the 6tisch mailing list, but > perhaps I need to find time to do it. I did read the "removing the 'e' > thread" in the archives, and I think the correct thing would be to > refer to the 802.15.4 without any year or specific list of amendments. > -- > [email protected] > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
