Once again I will repeat an old story… We went to a Zigbee demo with our pre-WirelessHART product, which uses MICs to authenticate both the equivalent of Beacons (called advertisements in WH) and data traffic.
The Zigbee networks fell apart in our presence, while we operated fine. The reason why was that the Zigbee networks did not use MICs, and were interpreting some of our data traffic as coordinator realignment frames, causing their nodes to change channel. No protocol owns the airwaves - any protocol that does not anticipate random frames arriving that look like valid instructions, and taking at least minimal steps to avoid this problem (i.e. authenticating frames with SOME key), is poorly designed. -- Jonathan Simon On May 7, 2015, at 2:20 PM, Tero Kivinen <[email protected]> wrote: > Thomas Watteyne writes: >> I believe Tero refers to the idea developed >> in >> http://cp.mcafee.com/d/k-Kr3xAq4zqb3adSmn64jtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsSYCeg8cfLZvDDHLnKeWZOWqr1EVV5VB4QsIecYJt6OaaJTD-l3PWApmU6CQjqpK_8K6zBdCUVMQsFCXCOsVHkiP9RGvjFvdTw0e0X3rAVkIjbAaJMJZ0lbVKY01dKnKOr1vF6y0QJKjBiNcQKCy0o9OmmB0yq85pgAHFVJcQsCYp_2gnpF >> draft-struik-6tisch-security-considerations-01#section-1.1 in which >> a JN hears an authenticated EB, tries to authenticate it, which >> fails as it does not have the key, but still reads the payload of >> the packet (sent in the clear, since the EB is not encrypted). >> [personally, I'm not a fan of this approach] > > Yes. But this idea is actually part of 802.15.4. It was already > described in 802.15.4-2011 section 5.1.2.1.2 "Active and passive > channel scan". > > If a protected beacon frame is received, i.e., the Security > Enabled field is set to one, the device shall attempt to > unsecure the beacon frame using the unsecuring process > described in 7.2.3. > > The security-related elements of the PAN descriptor > corresponding to the beacon, as defined in Table 17, shall be > set to the corresponding parameters returned by the unsecuring > process. The SecurityStatus element of the PAN descriptor > shall be set to SUCCESS if the status from the unsecuring > process is SUCCESS and set to one of the other status codes > indicating an error in the security processing otherwise. > > The information from the unsecured frame shall be recorded in > the PAN descriptor even if the status from the unsecuring > process indicated an error > >> Qin correctly points out that the CRC will provide (weak) protection >> against transmission errors. > > This is assumed to be acceptable for non-secured traffic. The MIC is > not mandatory and I have not really seen people saying that we need to > make MIC mandatory to provide protection against transmission errors > in any other places that when protecting EBs with well-known keys... > -- > [email protected] > > _______________________________________________ > 6tisch mailing list > [email protected] > http://cp.mcafee.com/d/5fHCMUg6zqb3adSmn64jtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsSYCeg8cfLZvDDHLnKeWZOWqr1EVV5VB4QsIecYJt6OaaJTD-l3PWApmU6CQPqpK_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcSVelb4OV2Hsbvg5i-rL00jrBXICMnWhEwdbrAVkIjdbFEw62sBBFg8Cy1mk9aWurjd79JVtRsxA_
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
