Hi Pascal:
I once again completely lost track of the utterly confusing email chain
regarding the security section of the minimal draft.
With the risk of sounding like a stuck record: this topic had been
documented quite extensively in
draft-struik-6tisch-security-architectural-considerations-01 and I have
not seen any new technical argument being made on the list (to my
knowledge; it is very hard to absorb the entire sequence of emails).
The main crux of the argument that was brought up to me privately was
that using a "well-known" key could be used as mechanism for (very
crude) filtering of the very first enrollment message. {This is not
necessarily a new argument and was discussed as "network segregation" in
draft-struik-6tisch-security-architectural-considerations-01 (Section
1.2, #8.}
As already said, segmentation can be realized in many ways (having an
identifying string seems easiest). Besides, granularity at the level of
"6tisch-minimal15" does nothing to stop neighboring networks {including
those that may be poorly managed} to interfere with one's own network,
in case these both implement that spec (this was the toy store vs.
temperature sensor example, summarized below:
/Tanya's Toy Town buys a couple of crates full of wireless robot
toys. They all use 15.4e, although not well. Each one broadcasts an
EB every second, and it includes all of the //
//same IEs that Charlie's temperature sensors expect. So there are
400 correctly-formed 15.4e EBs per second arriving from the store
next door, and Charlie's sensors take //
//approximately six hours to join his network. /
While cryptographic keys indeed provide a mechanism for logically
partitioning the universe during operational use of a network, it is not
necessarily appropriate for filtering the very first enrollment message
(e.g., how does one know that the list below will be the correct one in
hindsight?). Network segregation is at least partially a policy setting
issue and should be dealt with as part of flexible device management.
Quick question, though: if one would indeed use a well-known key as
network segregation mechanism (where each device implementing
802.15.4e-2012/TSCH and the IETF minimal draft uses as key K1 in the
beacon a string that is a function of "6tisch-minimal15") and suppose
the security considerations in
draft-struik-6tisch-security-architectural-considerations-01 are
considered not of interest,
a) How would one identify this key, using 802.15.4-2011?
The only way to potentially make this work would be to use a 9-octet key
identifier field, where someone would reserve a universal EUI-64 that
could serve as globally unique "key source" for the key
"6tisch-minimal15". Who would this "someone" be? Currently, this is not
defined.
b) How would one store this key, using 802.15.4-2011?
The macKeyTable is supposed to contain cryptographic keys that can only
be written to this table, but not read (to prevent easy exposure of
supposedly secret keys). However, if one of those keys is a well-known
string, the behavioral semantics of I/O seems to be jeopardized.
Wouldn't it be much better to put these issues to rest by *not* mingling
crude network segregation with key management issues and, if one really
wants to use filtering, simply pick a "6tisch-minimal15" string and
include this into an unsecured frame as IE instead? {This would save a
9-octet key identifier, headaches to specify missing pieces, such as key
source, and security concerns re side effects}. This network
segregation requires only a small IE (use header IE (see 5.2.4.2)
unmanaged information element (5.2.4.21)), e.g., by picking the 2-octet
Header IE = 0x00 (length=0, unmanaged id=0x00, IE content = emptyst {to
keep with the spirit of minimal}.
Rene
On 5/8/2015 9:25 AM, Rene Struik wrote:
Hi Jonathan:
It is always great to recount anecdotal evidence. However, I fail to
see why this should necessarily apply to 6tisch.
The question is what constitutes a proper mechanism for network
segregation. This technical topic was discussed in Section 1.2, item
#8 of the draft
draft-struik-6tisch-security-architectural-considerations-01, where it
was suggested that this relates to filtering based on checking the
"language of well-formed frames" (see 2nd starred item in 1.2, #8). In
fact, some of the language in that section re IE header fields were
from Kris Pister (see acknowledgement in Section 3, p. 16).
Once again, may I suggest, as I did in my email of April 24, 2014,
9.47am EDT, to first read that draft and only bring up topics not
already dealt with there?
[excerpt email RS as of April 24, 2015, 9.47am EDT]
I did notice lots of emails surrounding 802.15.4 security (or
perceptions thereof), but I do not entirely understand the background
of these emails.
Since some emails seem to repeat similar discussions in December 2014
(including confusions and misconceptions of 802.15.4 security), I
would like to encourage everyone to read the draft
draft-struik-6tisch-security-architectural-considerations-01 (posted
January 9, 2015). I wrote this draft partially in the hope that we
would not have the very repeat of arguments we now seem to witness.
So, I highly recommended reading that 3 1/2 months old draft and only
bring up topics not already dealt with there.
Best regards,
Rene
On 5/7/2015 6:01 PM, Jonathan Simon wrote:
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.
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
--
email:[email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--
email: [email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
