Yes, 7.2.3 describes the incoming frame security procedure, which
references the
7.2.2 keyDescriptor lookup procedure. 7.2.2 says that if the KeyIdMode
is 0x00,
then a.4 and a.5 say to find the keyDescriptor in the macKeyTable which
has the
same PAN ID and source device address.
How the macKeyTable is populated is not described. In particular, we
know that
in many cases keyDescriptors will be added during network operation.
The information contained in an EB is sufficient to allow a JN receiving
that EB
to create a deviceDescriptor and keyDescriptor entry for the JA, including
the PAN ID, JA address, and all other information necessary to
perform the procedure described in 7.2.3 in a standard-compliant way.
Again, I'm confident that we can be compliant and use a key K1 with
keyIdMode 00 and no extra header bytes.
ksjp
On 5/22/2015 8:54 PM, Rene Struik wrote:
Hi Kris:
The appropriate clause in 802.15.4-2011 is clause 7.2.3 (which
describes the normative behavior of the incoming security frame
processing procedure), which includes the mechanism by which key
look-up takes place.
Rene
On 5/22/2015 7:15 PM, Kris Pister wrote:
Rene - just to make sure that I understand you, you are saying that:
If I generate a secure random 128 bit number to use as K1, and I
program that number
into five motes sitting on my desktop, there is no standard-compliant
way that those
motes can use K1 to protect MAC frames without using a 9-octet key
identifier?
I'm pretty sure that there *is* a way. I'm pretty sure that I can
set Key Identifier Mode to 00,
and have 0 additional bytes in the security header, and determine the
key implicitly
("use K1!"), as described in 7.4.1.2 of 802.15.4-2011 .
Perhaps Tero can tell us if this is still true in -2015.
ksjp
On 5/22/2015 12:21 PM, Rene Struik wrote:
Hi Kris:
I tried to do this for the key "6tisch-minimal", but could not come
up with something else than using a 9-octet key identifier and the
need to define a key source and allocate a universal EUI-64. Hence,
my question. BTW - I am not trying to be difficult here and simply
ask how one could instantiate the 802.15.4-2011 and 802.15.4e-2012
specs so as to do what seems to be an approach you would favor.
I do know how one should be able to do this with a 2-octet header
information element that seems to have the following properties:
a) it realizes crude network segregation (at granularity
"6tisch-minimal") you aim for as well;
b) it saves (net) 6 octets in the enhanced beacon frame, with
following breakdown:
--- saves 8 octets in the auxiliary security header (1 octet vs.
9 octets for key identifier fields);
--- costs 2 octets by including a 2-octet header information
element (unmanaged header IE), with format 0x0000 {indicaing
"6tisch-minimal");
--- {this assumes EBs to be protected with a key}
c) it allows devices already in the network to synch their clock
(using frame-based synchronization [assuming beaconing device as
clock tower parent]).
d) it allows us not to have to worry about side effect of incoming
frame security processing.
If all devices already have a pre-shared *cryptographic* key (that
somehow got provisioned via out of band means and distributed only
to devices that should be in the same network), they can still use
the approach above, but do not need to include the 2-octet header IE
as network segregation identifier. BTW - I did address an
alternative mechanism to implement the "6tisch-minimal" network
segregation issue, with metrics as above, not the strictly different
problem of trying to pre-provision a pre-shared key via a work bench
type approach.
Does this make sense?
Best regards, Rene
On 5/22/2015 2:36 PM, Kris Pister wrote:
Maybe you could describe to us how it should work for a simple protocol
running in a simple network with a single pre-shared key.
I believe that you will be able to do this without a 9 byte
security header.
I believe that you will be able to do this in a fully
802.15.4-compliant way.
ksjp
On 5/22/2015 11:11 AM, Rene Struik wrote:
Hi Kris:
The incoming frame security processing procedure in 802.15.4-2011
(or in 802.15.4e-2012) does not have as input parameters any state
along the lines of "JOIN-0", etc. Moreover, the procedure for
looking up keys in 802.15.4 does not allow to do whatever one
wishes to do: the word "implicit" only refers to having no
explicitly coded key source field in the auxiliary security header.
Hence, my earlier question to you to describe in detail how one
should instantiate the 802.15.4 spec to arrive at the behavior you
suggested.
What you describe below seems something that may look somewhat
like 802.15.4 ("is based on"), but certainly does *not* comply
with the specification (to my knowledge this holds no matter
whether one compares to 802.15.4-2003, 802.15.4-2006,
802.15.4-2011, or 802.15.4e-2012).
Best regards, Rene
On 5/22/2015 1:36 PM, Kris Pister wrote:
> I do not understand this, so if you could describe how one can
instantiate a default
> key "6tisch-minimal15" via another mechanism in 802.15.4, that
would be great.
I believe that setting the Key Identified Mode field = 00 implies
that
Key is determined implicitly from the
originator and recipient(s) of the frame,
as indicated in the frame header.
Implementers write state machines. When mote is in state
"JOIN-0", load hardware
register RX-MIC-KEY with value K1, set RX-Channel= ...., etc.
ksjp
On 5/22/2015 9:45 AM, Rene Struik wrote:
Hi Kris:
I just wanted to focus on one remark in your email: "You don't
need a 9B header to define this - it's just what the software
does to be compliant with a higher-layer standard."
I do not understand this, so if you could describe how one can
instantiate a default key "6tisch-minimal15" via another
mechanism in 802.15.4, that would be great.
[BTW (I can't resist) - I am not a native speaker, but if one
labels/colors all "6tisch-minimal15" with one brush, this sounds
"crude" to me....]
Rene
On 5/22/2015 12:08 PM, Kris Pister wrote:
[ So far we have fake keys and crude segmentation. I'm going to
have to start naming
any ideas that I may have to contribute. I have some thoughts
on naive networking,
pathetic PKI, and ridiculous routing... :) ]
Key K1 can be whatever you want.
0) If you're doing an interop event, maybe set it to something
well known.
1) If you have a small company and you aren't worried about
people finding
it and publishing it on the internet, set it to some global
secret value [I
don't see how this would work in practice, but maybe...]
2) If you have an out-of-band configuration step, then set it
to the particular
high-entropy cryptographic value for the network that you want
the mote
to join.
3) if you have a two-phase join process (Michael - are you
calling this imprint
followed by join? I wasn't sure), then you might have one fake
key for crude
segmentation initially, and then once the production network
credentials are
installed you'd have a pristine key for holy segmentation and
joining for the
production network.
One feature of this approach is that the mechanism is exactly the
same for each choice above. The software and state machine is
the same,
it's the policy that changes according to what the higher-layer
standard
chooses to do.
Whatever value you choose for K1, you will need to store it.
The abstraction
of a macKeyTable gets implemented in software and hardware in a
lot of different
ways. The details are not standardized. Whatever the
implementation interface
is for a given chip and stack, that's the one you use for
storing K1, whatever it's value.
The software can also be written (and is written for many
shipping products)
so that when a mote is trying to synchronize it uses K1 to
process EBs. You don't
need a 9B header to define this - it's just what the software
does to be compliant
with a higher-layer standard.
ksjp
On 5/21/2015 7:29 PM, Rene Struik wrote:
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
_______________________________________________
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
--
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
