Subject: [6tisch] Shipping minimal

From: Tero Kivinen <[email-masked]>
Date: Mon, 4 May 2015 14:28:40 +0300

Pascal Thubert (pthubert) writes:
> The only questions left are:
> 
> 1) should we provide a default value for K1 in the security section?

Do you actually mean that the draft would specify some preconfigured
key for K1? I hope not, as I am pretty much sure that would be really
bad idea.

I think it is bad idea for the security considerations section to
mention "well-known keys" at all in there. I would be much more happy
if the text would be changed to "Key distribution is out of scope of
this document, but examples include pre-configured keys at the nodes
or shared keys among peers.", i.e. removeal of the well-known keys
from the text completely.

Especially as we are talking about the security section.

Anyways it is unclear for me what is the use for this minimal.

The draft lists uses like:

 - Early interoperability testing
 - Network bootstrap before any schedule is installed
 - Fall-back mode in case that dynamic scheduling mechanisms fail or
   are not available

For early interoperability testing pre-configured keys works fine,
i.e. people doing interoperability testing can define the "well-known
key" they are going to be using in the testing. This is what we had in
early IPsec testing, i.e. we used keys like "0123456789abcdef" or
"makemetastygoat" as pre-shared key in interop testings.

For the fall-back mode it looks like the minimal and EBs would be used
for real production cases, not just bootstrapping, so the claims that
EB protection does not matter is not true. I myself think that minimal
could be used as only mechanism in certain types of environments, but
for those cases the real keys would be needed to protect EBs.

For bootstrapping I still think there is no benefit from using
well-known keys compared to having no security at all, and for no
security it would be clear that there is no security, there would be
no false sense of security. I.e. if EBs do not have any use in
security sense (which I do not really belive, I think they do have
security implications), then it would be same to not to protect them
at all.

Vendor specific IE to tell that this network is for this use would
provide much better multiplexing and network selection properties than
well-known keys used by everybody.

> 2) which IEEE document should the spec reference?
> 
> For 1) it was suggested that it would help interop if we did. So the proposal
> on the table is to add a well-known key as a default that can be modified at
> commissioning time.
> 
> For 2) the spec makes explicit references deep into 802.15.4e so the proposal
> on the table is to maintain the reference to 802.15.4e as it stands now.

I would update it to use 802.15.4 without year, or without reference
to the 4e. The 802.15.4 reference do include all amendments for it,
including 4e. This is same think that we do say that this uses TCP, we
do not say that it uses TCP as specified in RFC793, but not the
updates done in the RFC1122, 3168, 6093, 6528). For TCP we should use
STD0007 as the reference, and similarly we should use "IEEE Std
802.15.4" here.
-- 
[email-masked]

---

From: Kris Pister <[email-masked]>
Date: Mon, 04 May 2015 11:25:38 -0700

> there would be no false sense of security

Can we see a show of hands of all of the people on the list who think 
that there is
any sense of security from using a key that is published in an RFC? No?  
No one?

Good.  No one has a false sense of security.  We all know that using a 
well-known
key provides no security.

ksjp

---

From: Tom Phinney <[email-masked]>
Date: Mon, 04 May 2015 17:19:26 -0700

Kris,

I believe that the conclusion you reach below is fallacious, at least in 
its implications. We (on this list) now all know that using a well-known 
key provides no security. However, the issue is whether anyone who might 
attempt to use the IETF specification for "minimal" might erroneously 
conclude that use of a key DOES provide some sense of security.

The almost-interminable discussion that we on this list have already had 
on the subject makes clear that many people might make that mistake in 
judgment. It is for that reason that I sense that Tero and others want 
to eliminate the POTENTIAL for someone else to infer an unjustifiable 
sense of security, not that he is concerned that you or I or most others 
who are actively participating in this discussion would be so deluded.

-Tom
=====
On 2015.05.04 11:25, Kris Pister wrote:
> any sense of security from using a key that is published in an RFC? 
> No?  No one?
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 May 2015 14:07:26 +0300

Kris Pister writes:
> Can we see a show of hands of all of the people on the list who
> think that there is any sense of security from using a key that is
> published in an RFC? No? No one?

And ask that same question from normal users installing termostats or
other internet of things devices?

Or the application writer who do verify that yes the security level of
the incoming packet is 7 so it is encrypted and integrity protected,
but without bothering to check which key it was encrypted with?

Note, that the application writer most likely do not even know how the
keys are identified in the 802.15.4 link, thus he would not even know
what kind of checks to put to his application to be able to verify
that the packet actually had proper protection.

The MAC layer will not filter these out as we need to be able to
receive those frames during normal operations thus receiving data
frames used for device wanting to join with that key is completely
valid case.

How many people here will know how to from following information
"SecurityLevel, KeyIdMode, KeySource, KeyIndex" whether that key is K1
or K2?

So when you receive MCPS-DATA.indication those parameters should you
pass it to application or drop it?

And no, this is real question, can you tell me how do I separete the
K1 and K2 in the application level?

> well-known key provides no security.

Which is not mentioned at all in the draft.

The draft makes all kind of security claims and claims that all those
claims are true for all types of keys defined in there, i.e.
per-configured keys at nodes, shared keys among peers, or well-known
keys.

So there is already huge false sense of security present in the draft.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 May 2015 14:05:43 -0400

> other internet of things devices?

But, 6tisch (minimal) is not targetted at that kind of use.
It's targetted at industrial users that need deterministic work.
Minimal is further targetted at well... interop.

Let me put it differently: Bluetooth didn't specify a default key, and didn't
do enrollment for headsets sanely, and now the "K1" *and* "K2" keys are "0000"
We can't keep people from doing stupid things.  We need known K1 in order to
bootstrap to a KMP in order to set up K2.

If K1 has to be provisioned, then K2 will get set at the same time, and K1
and K2 will get set to "0000".

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 5 May 2015 18:22:58 +0000

I think it's a false assumption that just because K1 is pre-provisioned that K2 will be pre-provisioned as well -- there are many network success stories that utilize pre-provisioning of an endpoint-unique K1 to bootstrap other trust relationships.

R.

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, May 05, 2015 2:06 PM
To: [email-masked]
Subject: Re: [6tisch] Shipping minimal

Let me put it differently: Bluetooth didn't specify a default key, and didn't do enrollment for headsets sanely, and now the "K1" *and* "K2" keys are "0000"
We can't keep people from doing stupid things.  We need known K1 in order to bootstrap to a KMP in order to set up K2.

If K1 has to be provisioned, then K2 will get set at the same time, and K1 and K2 will get set to "0000".

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 May 2015 14:39:25 -0400

Turner, Randy <[email-masked]> wrote:
    > I think it's a false assumption that just because K1 is pre-provisioned
    > that K2 will be pre-provisioned as well -- there are many network
    > success stories that utilize pre-provisioning of an endpoint-unique K1
    > to bootstrap other trust relationships.

You didn't say what I said.,
I'm saying that if K1 has to be provisioned in the field, (not
pre-provisioned at manufacturer time), that one might as well provision K2 to
as well.

I wonder what you mean by "pre-provisioning" here, and if you can point at
the the success stories you mention.

---

From: "Turner, Randy" <[email-masked]>
Date: Tue, 5 May 2015 19:26:38 +0000

Yes, by pre-provisioned, I meant at any time prior to the device being deployed and operational - (what telcos sometimes call "fulfillment") - this means during manufacturing time or by a field service tech installing the device.  And I'm treating "K1" in an abstract sense, where K1 is essentially the idea of provisioning trust in the device prior to being in an online operational state.

Examples of this type of pre-provisioned trust are cable modems, some residential gateways that use TR-069,  and AMI endpoints just to name a few.

R.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, May 05, 2015 2:39 PM
To: [email-masked]
Cc: Turner, Randy
Subject: Re: [6tisch] Shipping minimal

You didn't say what I said.,
I'm saying that if K1 has to be provisioned in the field, (not pre-provisioned at manufacturer time), that one might as well provision K2 to as well.

I wonder what you mean by "pre-provisioning" here, and if you can point at the the success stories you mention.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 May 2015 23:58:01 +0300

> It's targetted at industrial users that need deterministic work.

I have always wondered for what this 6tisch is meant for, as everybody
seems to have different requirements. Some say, we cannot do
provisoning as nobody touches the devices before they are installed.
This is not true in industrial users, there they can do provisioning
before sending them to factory. There was complains that neighbour toy
store messes up networks for new devices, but for deterministic work
you do not care about the bootstarpping phase, as that is only one
time operation etc.

All of this of course makes discusissons about issues hard, as
everybody is talking about different things. 

> Minimal is further targetted at well... interop.

If it is only for interop, there is no point of publishing it as RFC
at all. If so then I do not care whether there is well-known key put
in to the internet-draft.

https://tools.ietf.org/html/draft-ietf-ipsec-internet-key-00

On the other hand I still think it is better to put that in the test
specification for the interop event.

> We can't keep people from doing stupid things.

Yes. On the other hand for most headsets you need to put them in
pairing mode before they initiate setup and I think they exchange some
kind of random keys during that phase that is then used later...

> We need known K1 in order to bootstrap to a KMP in order to set up
> K2.

No we dont.

The K1 can be completely random, and the joining node does not need to
know it.

I repeat:

	The K1 can be completely random and the joining node does not
	need to know it.

Only device who really needs to know the K1 is the device sending out
EBs, as he needs it to be able to calculate the MIC...

All other devices who know K1 are able to verify that EB is sent by
device who knows the key. Those who do not know the K1 cannot verify
the MIC, but they can still get all information in the EB.

The 802.15.4 standard mandates that devices joining the network must
be able to extract all information from beacons even if they do not
know the keys. And when using TSCH the beacon cannot be encrypted,
thus it has only MIC, meaning all information from it can be
extracted.

> and K1 and K2 will get set to "0000".

The K1 and K2 can both be generated by running KMP during the joining
process. The K1 will protect the EBs and every coordinator sending EBs
in the network should use the same key to provide data integrity for
EBs. If EBs are not used at all after the initial bootstrap phase
(which some people seem to say will happen), then this K1 protection
does not provide anything.

On the other hand on some networks I can see some real uses for EBs
also after the initial bootstrap, but those uses will require the EBs
to integrity protected for those devices who are already part of
network.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 May 2015 21:45:44 -0400

Turner, Randy <[email-masked]> wrote:
   > Yes, by pre-provisioned, I meant at any time prior to the device being
   > deployed and operational - (what telcos sometimes call "fulfillment") -
   > this means during manufacturing time or by a field service tech
   > installing the device.  And I'm treating "K1" in an abstract sense,
   > where K1 is essentially the idea of provisioning trust in the device
   > prior to being in an online operational state.

We are talking about K1 being set by the manufacturer, i.e. before
"fulfillment", and the device being shipping directly to the consumer without
touching any field service tech, etc.  That's what "zero touch" means.
Granted: minimal is not zero touch.

And K1 is not abstract, it's very definite, and it isn't abstraction for
providing trust into the device.  It's about getting minimally on the network
so that something more complex can occur.  That's *ALL*.

There is nothing more.  The rest is not part of minimal, but getting K1 right
in minimal matters to later work.

    > Examples of this type of pre-provisioned trust are cable modems, some
    > residential gateways that use TR-069,  and AMI endpoints just to name a
    > few.

On TR-069 devices (which, wearing the [email-masked] hat, I'm rather
familiar with), the operator *communicates* the intent to the device of which
network it should be connected to by... well..  plugging the cable in.
This seems a overly subtle point, but it's really important, because with
wireless, if there are multiple networks around, there is no such active
intent as plugging a cable in.

Further, the TR-069 trust model assumes that *all* cable operators are
equally trusted.  That is, I can take a cable modem from my house (Rogers
cable land), and bring it down to Atlanta (Comcast I think) and plug it in,
and the *cable modem* won't care.  Further, since the root CA in the cable
modem is provided by CableLabs, Comcast will be able to authenticate the
device *just fine* (They may not be willing to provide you service, that's a
different discussion).

The important point here is that *at no point* does the cable modem actually
authenticate that this is the correct cable operator.  Seriously.  If a truck
of cable modems on their way to Ottawa gets diverted to Atlanta, and Comcast
scans them, the vendor of the cable modems will never know.

The bulk of this work (at least from point of view) has/is moving from
6tisch-security design team to the ANIMA working group, btw.

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 6 May 2015 01:56:37 +0000

I agree that the mechanism for K1 is concrete, but the rationale behind
pre-provisioning (in whatever flavor its instantiated) is somewhat
abstract, since it¹s a concept with a numper of concrete mappings, per the
examples I earlier enumerated. I included cable modems and residential
gateways because they have pre-provisioned (some at manufacturing, some at
fulfillment) certificates or PSKs that allow bootstrapping of other trust
relationships.  802.1AR is another example (incidentally, 802.1AR was used
in an ANIMA presentation in Dallas).

I think if our requirements for zero-touch in 6tisch overlap significantly
with the goals of ANIMA, then it might make sense for ANIMA to handle
common bootstrap issues.

Some of what I¹m talking about is not exactly what I would call ³minimal²,
but the concept I¹m talking about still applies (with regard to the
pre-provisioning of K1).

Randy

On 5/5/15, 9:45 PM, "Michael Richardson" <[email-masked]> wrote:

>pre-provisioned at manufacturer time), that one might as well provision
>K2 to as well.
>
>    > I wonder what you mean by "pre-provisioning" here, and if you can
>point at the the success stories you mention.
>
>    >> Let me put it differently: Bluetooth didn't specify a default key,
>and didn't do enrollment for headsets sanely, and now the "K1" *and* "K2"
>keys are "0000"
>    >> We can't keep people from doing stupid things.  We need known K1
>in order to bootstrap to a KMP in order to set up K2.
>
>    >> If K1 has to be provisioned, then K2 will get set at the same
>time, and K1 and K2 will get set to "0000".
>
>    >> --
>    >> This e-mail (including any attachments) is confidential and may be
>legally privileged. If you are not an intended recipient or an authorized
>representative of an intended recipient, you are prohibited from using,
>copying or distributing the information in this e-mail or its
>attachments. If you have received this e-mail in error, please notify the
>sender immediately by return e-mail and delete all copies of this message
>and any attachments. Thank you.
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 May 2015 22:06:37 -0400

> before sending them to factory.

They *can*, but they don't want to... too much $$$$.
The contractors who install the devices haven't the skills, and the
subcontractors, are often not actually trusted.  This is actually in parts of
the industrial requirements for ROLL (RFC5673) and
was in draft-ietf-roll-rpl-industrial-applicability-02.. that lead to 6tisch.

    > There was complains that neighbour toy

Tom Phinney gave two examples from the refining situation.
The first part was that pieces of the refinery are often sold or leased to
competitors.  That means that the entire sensor network needs to go through a
new bootstrap without being disassembled, and needs to do this in the midst
of another network.

The toy store could well have two or three networks.
1) the control network for the building/mall.
2) the control network for the toy store itself.
3) the actual junk actually being sold in the toy store.

    > everybody is talking about different things.

True.

    > in to the internet-draft.

I don't know if it will have a life beyond the interop.

    > kind of random keys during that phase that is then used later...

I see your point.

    > EBs, as he needs it to be able to calculate the MIC...

So, really, we don't need to use K1 on the EBs at all, is your point.
Therefore there is no point in having EBs authenticated at all....

    > does not provide anything.

Agreed... which is why Kris argues for using it for something else.

    > to integrity protected for those devices who are already part of

Good... I'd like to hear more.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 May 2015 10:33:54 +0000

Hum...

But then, if the JN does not know K1, how can it validate the MIC? Do  we have another way to protect against transmission errors on EBs? 

Cheers,

Pascal

> Sent: mercredi 6 mai 2015 04:07
> To: [email-masked]
> subcontractors, are often not actually trusted.  This is actually in parts of the
> industrial requirements for ROLL (RFC5673) and was in draft-ietf-roll-rpl-
> industrial-applicability-02.. that lead to 6tisch.
> 
> new bootstrap without being disassembled, and needs to do this in the midst of
> another network.
>

---

From: Qin Wang <[email-masked]>
Date: Wed, 6 May 2015 14:41:02 +0000 (UTC)

Pascal,
The protection against transmission errors on EBs rely on the CRC in PSDU, right?
ThanksQin 

     On Wednesday, May 6, 2015 6:34 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:

 Hum...

Cheers,

Pascal

>    >> But, 6tisch (minimal) is not targetted at that kind of use.
>    >> It's targetted at industrial users that need deterministic work.
> 
>    > I have always wondered for what this 6tisch is meant for, as everybody
>    > seems to have different requirements. Some say, we cannot do
>    > provisoning as nobody touches the devices before they are installed.
>    > This is not true in industrial users, there they can do provisioning
>    > before sending them to factory.
> 
>    > There was complains that neighbour toy
>    > store messes up networks for new devices, but for deterministic work
>    > you do not care about the bootstarpping phase, as that is only one
>    > time operation etc.
> 
>    > All of this of course makes discusissons about issues hard, as
>    > everybody is talking about different things.
> 
> True.
> 
>    >> Minimal is further targetted at well... interop.
> 
>    > If it is only for interop, there is no point of publishing it as RFC
>    > at all. If so then I do not care whether there is well-known key put
>    > in to the internet-draft.
> 
>    >> Let me put it differently: Bluetooth didn't specify a default key, and didn't
>    >> do enrollment for headsets sanely, and now the "K1" *and* "K2" keys are
> "0000"
>    >> We can't keep people from doing stupid things.
> 
>    > Yes. On the other hand for most headsets you need to put them in
>    > pairing mode before they initiate setup and I think they exchange some
>    > kind of random keys during that phase that is then used later...
> 
> I see your point.
> 
>    > No we dont.
> 
>    > The K1 can be completely random, and the joining node does not need to
>    > know it.
> 
>    > I repeat:
> 
>    > The K1 can be completely random and the joining node does not
>    > need to know it.
> 
>    > Only device who really needs to know the K1 is the device sending out
>    > EBs, as he needs it to be able to calculate the MIC...
> 
>    >> If K1 has to be provisioned, then K2 will get set at the same time,
>    >> and K1 and K2 will get set to "0000".
> 
>    > The K1 and K2 can both be generated by running KMP during the joining
>    > process. The K1 will protect the EBs and every coordinator sending EBs
>    > in the network should use the same key to provide data integrity for
>    > EBs. If EBs are not used at all after the initial bootstrap phase
>    > (which some people seem to say will happen), then this K1 protection
>    > does not provide anything.
> 
>    > On the other hand on some networks I can see some real uses for EBs
>    > also after the initial bootstrap, but those uses will require the EBs
>    > to integrity protected for those devices who are already part of
>    > network.
>

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 7 May 2015 15:12:56 +0200

Pascal,

I believe Tero refers to the idea developed in
https://tools.ietf.org/html/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]

Qin correctly points out that the CRC will provide (weak) protection
against transmission errors. You are right that an additional MIC
strengthens that protection.

All, please correct/amend what I have wrong.

Thomas

On Wed, May 6, 2015 at 4:41 PM, Qin Wang <[email-masked]> wrote:

> Thanks
> Qin
> But then, if the JN does not know K1, how can it validate the MIC? Do  we
> have another way to protect against transmission errors on EBs?
>
> Cheers,
>
> Pascal
>
>
> and didn't
> >    >> do enrollment for headsets sanely, and now the "K1" *and* "K2"
> keys are
> > "0000"

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 May 2015 16:23:53 +0300

Pascal Thubert (pthubert) writes:
> But then, if the JN does not know K1, how can it validate the MIC?

It does not need to validate it. MIC is security feature, it is not
meant to be used to protect against transmission erros, even when it
will also detect those.

Your comment would be about the same as saying: The IPsec/AH provides
the 96-bit ICV, and if the other end does know the key (or we do not
use the AH at all), how it can know that it received the TCP packet
properly.

> Do we have another way to protect against transmission errors on
> EBs?

Yes. Same as we normally use for non-secured frames. The level of
protection provided depends on the PHY used. It might either be
2-octet FCS, or it might be 4-octet FCS, or it might be some kind of
forward error correction code (FEC) etc.

None of these feaures are disabled when we enable the security. I.e
when we receive the the secured frames we first check the FCS, if that
is right, then we go through the filterin rules to see if is for us,
and if it is meant for us, only then we do security processing. For
the beacons received during active/passive scanning there is special
case that even if the security processing fails, we still use the
contents of the beacon, for other cases if the security processing
fails, we drop the frame (of course the 802.15.4e does not say whether
you still process the IEs included in the frame).
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 May 2015 14:42:29 -0400

Thomas Watteyne <[email-masked]> wrote:
    > which a JN hears an authenticated EB, tries to authenticate it, which

I am in favour of this approach for networks that need the EB in order
to operate correctly over time.  I had assumed such a thing for some time.

I have been told that this is not a requirement for *minimal*

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 8 May 2015 00:20:06 +0300

Thomas Watteyne writes:
> I believe Tero refers to the idea developed
> in https://tools.ietf.org/html/
> 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).

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

> 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-masked]

---

From: Jonathan Simon <[email-masked]>
Date: Thu, 7 May 2015 15:01:30 -0700

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-masked]> wrote:

>> in http://cp.mcafee.com/d/k-Kr3xAq4zqb3adSmn64jtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsSYCeg8cfLZvDDHLnKeWZOWqr1EVV5VB4QsIecYJt6OaaJTD-l3PWApmU6CQjqpK_8K6zBdCUVMQsFCXCOsVHkiP9RGvjFvdTw0e0X3rAVkIjbAaJMJZ0lbVKY01dKnKOr1vF6y0QJKjBiNcQKCy0o9OmmB0yq85pgAHFVJcQsCYp_2gnpF
> http://cp.mcafee.com/d/5fHCMUg6zqb3adSmn64jtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsSYCeg8cfLZvDDHLnKeWZOWqr1EVV5VB4QsIecYJt6OaaJTD-l3PWApmU6CQPqpK_8K6zBdCUVMQsFCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcSVelb4OV2Hsbvg5i-rL00jrBXICMnWhEwdbrAVkIjdbFEw62sBBFg8Cy1mk9aWurjd79JVtRsxA_

---

From: Rene Struik <[email-masked]>
Date: Fri, 08 May 2015 09:25:51 -0400

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

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 11 May 2015 06:48:36 +0000

I respectfully disagree Tero:

The fact that the MIC provides a protection against transmission errors cannot be ignored. 2 octets CRC is really weak. Consequences of undetected errors can be anything. CRC errors have blocked transcontinental lines in the past, and there is no bug fix for them. You have to change the protocol when you do things wrong. I have seen that happen.

When we have billions of devices, that will be millions of networks, that's thousands of undetected EB transmission errors every whatever period makes sense.
Do we have an analysis of what any combination of bits that are wrong in a beacon may cause when undetected?

We want  a better CRC but we have short frames. We do want to benefit from side effects even if that means imperfections on architecture. An example of that is at a different layer that the UDP checksum can be elided in 6LoWPAN if there is a MIC in the packet that provides better protection (RFC 6282).

Cheers,

Pascal

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: jeudi 7 mai 2015 15:24
> To: Pascal Thubert (pthubert)
> Cc: Michael Richardson; [email-masked]
> It does not need to validate it. MIC is security feature, it is not meant to be used
> to protect against transmission erros, even when it will also detect those.
> 
> Your comment would be about the same as saying: The IPsec/AH provides the
> 96-bit ICV, and if the other end does know the key (or we do not use the AH at
> all), how it can know that it received the TCP packet properly.
> 
> > Do we have another way to protect against transmission errors on EBs?
> 
> Yes. Same as we normally use for non-secured frames. The level of protection
> provided depends on the PHY used. It might either be 2-octet FCS, or it might be
> 4-octet FCS, or it might be some kind of forward error correction code (FEC) etc.
> 
> None of these feaures are disabled when we enable the security. I.e when we
> receive the the secured frames we first check the FCS, if that is right, then we go
> through the filterin rules to see if is for us, and if it is meant for us, only then we
> do security processing. For the beacons received during active/passive scanning
> there is special case that even if the security processing fails, we still use the
> contents of the beacon, for other cases if the security processing fails, we drop
> the frame (of course the 802.15.4e does not say whether you still process the
> IEs included in the frame).
> --
> [email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 May 2015 07:44:22 +0300

Pascal Thubert (pthubert) writes:
> The fact that the MIC provides a protection against transmission
> errors cannot be ignored. 2 octets CRC is really weak. Consequences
> of undetected errors can be anything. CRC errors have blocked
> transcontinental lines in the past, and there is no bug fix for
> them. You have to change the protocol when you do things wrong. I
> have seen that happen.

If you think it is too short, then you can select PHY that supports
better error correction properties. 

Yes, MIC do provide better protection, but I doubt you really claim
that 802.15.4 cannot be used at all without security as it only uses
2-octet CRC?

If that is really true, then perhaps the 802.15.4 should make security
mandatory... 

> When we have billions of devices, that will be millions of networks,
> that's thousands of undetected EB transmission errors every whatever
> period makes sense.

Yes, and the issue will be what? When EBs are only used during the
bootstrap process, then we are only interested in the few tens of
seconds time window for the lifetime of the device. I.e. the joining
node needs to receive ONE (1) EB properly before it can start joining
the network.

If this really is that big issue then implementations might keep on
doing passive scan for longer and wait until they get for example 2-3
identical EBs from the same coordinator, and only after that try to
join that network. This is something they can already do without any
changes in any of the other nodes in the network. This will lengthen
the initial passive scan from 10 seconds to 30 seconds.

And if the EBs are used after that then proper K1 key will be needed,
and that will protect them.

> Do we have an analysis of what any combination of bits that are
> wrong in a beacon may cause when undetected?

No, but it is much more likely to have the attacker flipping those
bits intentionally to get worst possible effect, than them getting
flipped randomly so that the FCS still matches.

I.e. the implementations MUST be able to cope with EBs having worst
possible values regardless wheter the EBs are protected by the
well-known key or no key at all.

And, yes the security considerations section of the minimal should
explain what kind of attacks can be done by sending "bad" EBs, and how
those issues can be solved.
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 12 May 2015 09:25:02 +0000

Hello Tero:

We disagree on this pass but you have my arguments and I have yours. What's new is that we also disagree that this problem that minimal should deal with. 

The problem has to do with a deployment decision that is made or not made elsewhere, and that may or may not be allowed by the security design.

If K1 is known to the joining node, even well-known, then the deployment can adjust the MIC size to make undetected transmission errors really-really rare.

Thus the conclusion of our discussion so far is:
- The poor frame error protection (FCS-only) is a generic problem that is only present if the security design allows for K1 to be unknown by the joining node.
- The case of an attacker that is willingly settings bits wrong in EBs is present if the security design allows for K1 to be unknown OR well-known by the joining node.

About your new points:

> No, but it is much more likely to have the attacker flipping those bits
> intentionally to get worst possible effect, than them getting flipped randomly so
> that the FCS still matches.

Why would he need to match the FCS? If the MIC is unknown then it can send whatever it likes and then compute a CRC over it.

> I.e. the implementations MUST be able to cope with EBs having worst possible
> values regardless wheter the EBs are protected by the well-known key or no key
> at all.

Is that written in 802.15.4? That is not an upper layer problem. All that minimal should really have to say is that its security is only as good as the L2 security will be because there is no additional L3 security to protect, say, RPL.

> And, yes the security considerations section of the minimal should explain what
> kind of attacks can be done by sending "bad" EBs, and how those issues can be
> solved.

If we allow for well-known or unknown K1, yes, I agree that we need that analysis for anything 6TiSCH, not minimal specifically.

Cheers,

Pascal

> Sent: mardi 12 mai 2015 06:44
> Cc: Qin Wang ([email-masked]); Michael Richardson; [email-masked]
> > errors cannot be ignored. 2 octets CRC is really weak. Consequences of
> > undetected errors can be anything. CRC errors have blocked
> > transcontinental lines in the past, and there is no bug fix for them.
> > You have to change the protocol when you do things wrong. I have seen
> > that happen.
> 
> If you think it is too short, then you can select PHY that supports better error
> correction properties.
> 
> Yes, MIC do provide better protection, but I doubt you really claim that 802.15.4
> cannot be used at all without security as it only uses 2-octet CRC?
> 
> Yes, and the issue will be what? When EBs are only used during the bootstrap
> process, then we are only interested in the few tens of seconds time window for
> the lifetime of the device. I.e. the joining node needs to receive ONE (1) EB
> properly before it can start joining the network.
> 
> If this really is that big issue then implementations might keep on doing passive
> scan for longer and wait until they get for example 2-3 identical EBs from the
> same coordinator, and only after that try to join that network. This is something
> they can already do without any changes in any of the other nodes in the
> network. This will lengthen the initial passive scan from 10 seconds to 30
> seconds.
> 
> And if the EBs are used after that then proper K1 key will be needed, and that
> will protect them.
> 
> No, but it is much more likely to have the attacker flipping those bits
> intentionally to get worst possible effect, than them getting flipped randomly so
> that the FCS still matches.
> 
> I.e. the implementations MUST be able to cope with EBs having worst possible
> values regardless wheter the EBs are protected by the well-known key or no key
> at all.
> 
> And, yes the security considerations section of the minimal should explain what
> kind of attacks can be done by sending "bad" EBs, and how those issues can be
> solved.
> --
> [email-masked]

---

From: Qin Wang <[email-masked]>
Date: Tue, 12 May 2015 20:41:41 +0000 (UTC)

Hi Pascal,
I'm confusing about what kinds of EB errors you want to detect. I think you mentioned two kinds of errors:(1) Transmission error(2) Wrong EB from some attacker.
Maybe there is third type of error?
I think everybody agree that CRC (or FCS) is used to detect (1), but can not detect (2).I'm not sure what is the contribution from well-known key based MIC to detect (1). But I do think the well-known key based MIC can not detect (2), because the attacker can also make a legal MIC over a wrong EB with the well-known key.
Do I miss something?
ThanksQin

     On Tuesday, May 12, 2015 5:25 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:

 Hello Tero:

Cheers,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 13 May 2015 07:54:23 +0000

Hi Qin:

We are saying the same thing. No third type of error.

I’m interested specifically of the value of a well-known key MIC that will perform a Message Integrity Check on top of what FCS does.

A 2-octet CRC has a chance out of 64K to miss an error that involves more than one bit transmission error. That is low. Very low in fact.

It is really a residue from a past that ended up being no worries as long as there is an additional digital hash like a UDP checksum or a security signature in the frame/packet.
The EB does not carry a layer 3 or 4 checksum. The MIC is the only coverage beyond FCS. I’m not happy to drop that unless a careful study has been done on the impact of random bit errors in an EB…

Cheers,

Pascal

From: Qin Wang [mailto:[email-masked]]
Sent: mardi 12 mai 2015 22:42
To: Pascal Thubert (pthubert); Tero Kivinen
Cc: Michael Richardson; [email-masked]
Subject: Re: [6tisch] Shipping minimal

Hi Pascal,

I'm confusing about what kinds of EB errors you want to detect. I think you mentioned two kinds of errors:
(1) Transmission error
(2) Wrong EB from some attacker.

I think everybody agree that CRC (or FCS) is used to detect (1), but can not detect (2).
I'm not sure what is the contribution from well-known key based MIC to detect (1). But I do think the well-known key based MIC can not detect (2), because the attacker can also make a legal MIC over a wrong EB with the well-known key.

Do I miss something?

Thanks
Qin

On Tuesday, May 12, 2015 5:25 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Tero:

Cheers,

Pascal

> From: Tero Kivinen [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Qin Wang ([email-masked]<mailto:[email-masked]>); Michael Richardson; [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 May 2015 18:38:25 +0300

Pascal Thubert (pthubert) writes:
> We disagree on this pass but you have my arguments and I have yours.
> What's new is that we also disagree that this problem that minimal
> should deal with.  

What is this problem you are talking about here?

> The problem has to do with a deployment decision that is made or not
> made elsewhere, and that may or may not be allowed by the security
> design.

This does not yet tell me the problem you are now talking about. 

> If K1 is known to the joining node, even well-known, then the
> deployment can adjust the MIC size to make undetected transmission
> errors really-really rare.

Yes, I agree that. On the other hand I do not think this is important
for minimal. I would much rather use K1 to properly authenticate EBs
AFTER the initial join process, which requires it not to be
well-known.

> - The poor frame error protection (FCS-only) is a generic problem
> that is only present if the security design allows for K1 to be
> unknown by the joining node. 

We are talking about few dozen frames DURING the initial bootstrap
phase. You need really crappy network to get that many errors which
pass the FCS, to cause the bootstrap to fail, and even then you need
bad implementation of the parser who is parsing the frames to get
messed up with those. If there is that crappy network, then most
likely the network will not work at all, as most of the frames will be
dropped by bad FCS.

I.e. if you get 1 wrong bit every 1000 bits, that means that you have
an have one error in most of your full length frames. To get another
error to the same frame in such way that the FCS still matches will
still not be very probable. Someone can probably calculate that.

Your case of there being billions devices out there all time, is not
really valid, as there will be only few hundred of those billion
devices doing "the once in the lifetime joining process" at the same
time (assuming 10 year lifetime of devices and joining process taking
hundred seconds).

We are not talking FCS protecting normal data traffic, we are talking
about the FCS protecting the about 10-20 frames used during the
bootstrapping phase. Actually the joining process running KMP or
similar will of course validate all data sent inside KMP when doing
authentication, so the the frames where errors can cause problem is
the EBs. You need to get one EB received properly to be able to start
joining the network. Even in EBs, most of the errors will cause the
frame to be ignored (i.e. if there is anything wrong with the IE
lengths or IE IDs etc then frame most likely will be ignored).

Even if EBs had errors, and because of that joining process failed,
that simply means we start the process from beginning, and try again.

> - The case of an attacker that is willingly settings bits wrong in
>   EBs is present if the security design allows for K1 to be unknown
>   OR well-known by the joining node. 

Yes, for joining. But for rejoining after you have already been part
of network, or cases where network is reconfigured etc, having a
proper K1 will prevent attackers from doing nasty attacks, but using
well-known K1 will not.

> Why would he need to match the FCS? If the MIC is unknown then it
> can send whatever it likes and then compute a CRC over it.

For attacker yes, but for random bit errors the case is different.
I.e. to get two random bit errors to same frame, so that FCS still
matches, does not happen that often.

The story about Zigbee and WireHART is completely different to that,
as both devices of course did calculate proper FCS, thus Zigbee
devices did properly receive the WireHART packets, and then got messed
up when their implementation didn't know what to do with them.

> > I.e. the implementations MUST be able to cope with EBs having
> > worst possible values regardless wheter the EBs are protected by
> > the well-known key or no key at all.
> 
> Is that written in 802.15.4?

No, that is general wisdom of writing code. I know this is new to some
people writing code (especially in IoT space), but you really should
validate stuff that you receive before you act on it... :-)

> That is not an upper layer problem.

Actually it is upper layers problem. I.e. when the device does
scanning the MAC will simply pass beacons to the next higher layer and
the next higher layer will then parse IE lists etc to check if the
beacon is acceptable. I.e. this filtering is something we need to
specify in 6tisch, as 802.15.4 does not provide that.

> All that minimal should really have to say is that its security is
> only as good as the L2 security will be because there is no
> additional L3 security to protect, say, RPL.

I.e if there is no L2 security because well-known key is used there is
no security at all in minimal?

> > explain what kind of attacks can be done by sending "bad" EBs, and
> > how those issues can be solved.
> 
> If we allow for well-known or unknown K1, yes, I agree that we need
> that analysis for anything 6TiSCH, not minimal specifically.

So writing that now is something we should get ongoing. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 May 2015 19:39:51 +0300

Pascal Thubert (pthubert) writes:
> I’m interested specifically of the value of a well-known key MIC
> that will perform a Message Integrity Check on top of what FCS does.
> 
> A 2-octet CRC has a chance out of 64K to miss an error that involves
> more than one bit transmission error. That is low. Very low in fact.

But that errornous frame needs to hit to EB, and it also needs to be
something that still parses properly by the upper layer, and the error
needs to be something that actually affects something. As we have not
analyzed what wrong values in different fields in EB can cause, we
cannot really say what it could cause.

> It is really a residue from a past that ended up being no worries as long as
> there is an additional digital hash like a UDP checksum or a security
> signature in the frame/packet.

UDP 16-bit one's complement checksum is much weaker than 16-bit FCS we
use in here. Also most bit errors in the EB will cause the frame to be
dropped also. 

> The EB does not carry a layer 3 or 4 checksum. The MIC is the only
> coverage beyond FCS. I’m not happy to drop that unless a careful
> study has been done on the impact of random bit errors in an EB…

For each field in EBs:

MHR.Frame Control field:

	Most bit errors here will cause frame to be ignored (wrong
	version, wrong frame type, wrong bits on or off (frame
	pending, ar, ie present), wrong security enabled field, wrong
	addressing modes).

MHR.Sequence number:

	No problem. Not used during joining.

MHR.Addressing fields:

	Wrong coordinator address / PAN ID => join will fail
	immediately when device cannot connect coordinator. Will move
	to next EB.

MHR.Auxiliary security header.Security Control:

	If Key Identifier Mode or Frame Counter Suppression fields
	have wrong vales the length of the Auxiliary security header
	do not match, which will cause either some IEs to be ignored
	(because they were consumed as part of Auxiliary security
	header) or having extra junk in IE list. Both of those will
	cause the frame parsing to fail.

MHR.Frame Counter:

	Not present in TSCH, but if Frame Counter suppression is not
	on, this will consume 4 bytes from the IE list, thus causing
	IE list parsing to fail.

MHR.Auxiliary security header.Key Identifier

	Not used during the joining process, as we do not have key. If
	KeyIdMode in Security Control Field is wrong this will either
	consume extra bytes or add junk to IE list, which will cause
	IE parsing to fail. 

MHR.Header IEs:

	If the Header IE Termination 1 IE is not there the rest of IEs
	are parsed as Header IEs which will cause the IE frame parsing
	to fail.

MHR.Payload IEs:

	If the first IE is not MLME nested payload IE the rest of the
	IEs will be parsed incorrectly thus IE frame parsing will
	fail.

MHR.Payload IE.TSCH Syncronization IE:

	If ASN is wrong frames sent after this will most likely have
	wrong channel hopping number, meaning wrong channel. Also all
	frames sent with security will be silently ignored by
	recipient. Most likely the coordinator will not hear the
	frames sent by the joining node, thus joining node will give
	up and try next EB. This might get fixed up automatically when
	the device is joining the network and hears next EB.

	If Joining priority is wrong the device might join some other
	device which is not optimal. This should still work.

MHR.Payload IE.TSCH TimeSlot IE:

	If the Timeslot ID is not 0, then the joining node most likely
	will not know the proper parameters for the network as it has
	only Timeslot ID 0 configured. If full parameters are given
	then the timing of the network settings are wrong. Some of
	those do cause so that no communications is possible (sender
	sending at wrong time, wrong timeslot duration), and some of
	those can cause the network to get messed up (i.e. sender
	thinking the ack wait time is differnet or something like
	that). Some invalid values do not affect anything. If no
	communications is possible then joining node will move to next
	EB. If communications is possible, values here might get fixed
	when it receives new EB with correct values.

MHR.Payload IE.Hopping timing IE:

	Ups, I do not think this should be here at all, Instead of
	this there should be Channel Hopping IE. I got confused as the
	bitbucket example had short MLME nested IE with id of 0x1d which is
	Hopping Timing IE instead of long MLME nested IE with ID of
	0x9.

MHR.Payload IE.Channel Hopping IE:

	If the Hopping Sequence ID is wrong then the hopping sequence
	is wrong, thus no communications is possible, thus joining
	node will give up and move to next EB.

MHR.Payload IE.Slotframe and Link IE:

	If Number of Slotframe is wrong then the IE length do not
	match, and parsing will fail.

	If the Slotframe handle is wrong it does not cause problems as
	it is not really used. This might get fixed when next EB is
	received.

	If the Slotframe size is wrong then the device is sending on
	the wrong time, and coordinator might not listen to him, but
	he will cause collisions with other traffic. In the end
	communications will fail and as he cannot hear EBs as he is
	waiting them on wrong time, he will timeout and give up
	joining and move to next EB.

	If the Number of Links is wrong, the IE length do not match,
	and parsing will fail.

	If the Timeslot or Channel Offset are wrong the communications
	will fail as device is sending/receiving on wrong channel or
	at wrong time. He cannot hear EBs, thus will timeout and give
	up joining process and move to next EB.

	If link bits are wrong joining node does not have any suitable
	link to send data to coordinator, thus cannot communicate and
	needs to ignore this EB and move to next.

MHR.Payload IE.Payload IE Termination:

	If this is wrong it will parsed as wrong IE, and most likely
	IE parsing will fail.

So in most cases there is no real security problems, provided that the
next higher layer parses the IEs properly and verifies the lengths
etc. Also if any of the IEs are missing the EB will not have enough
information to be usable, thus it will get ignored.

Next the question is, which of these parameters can be changed while
the TSCH network is up. I think anything in the TSCH TimeSlot IE or
Channel Hopping IE cannot be changed while the network is running so
they might be ignored on EBs (on the other hand nothing in the 15.4
says that this is required). TSCH Syncronization IE should most likely
be ignored after the device has successfully syncronized with the
network.

But the Slotframe and Link IE is something that can be updated
dynamically and coordinator can add/remove or modify links. I.e every
node in the network is supposed to keep track of those and if attacker
sends Slotframe and Link IE changing the Slotframe size from 101 to
102 this will cause the whole network to be messed up...

In section 6.3.6 TSCH PAN formation of 802.15.4-D00 (5.1.2.6 in
802.15.4e) there is text which says:

	After joining, the device may receive additional slotframes
	and links from a higher layer management entity or peer as
	required by the application, or the device may be instructed
	to remove slotframes and links obtained from the Enhanced
	Beacon.

Or just changing the share dslot timeslot or channel offset to wrong
will also cause devices to loose EBs, or removing all the shared
slotframes.

So this is at least something that is needed also during the
production use of the network, and which would really require that EBs
are properly protected. Or we need to explictly forbid changing those
in 6tisch unless K1 is proper key.

On the other hand this does not affect joining process, as if those
are wrong joining will simply fail, and joining node moves to next EB.
-- 
[email-masked]

---

From: Rene Struik <[email-masked]>
Date: Thu, 21 May 2015 22:29:57 -0400

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.
>
> segregation. This technical topic was discussed in Section 1.2, item 
> #8 of the draft 
> fact, some of the language in that section re IE header fields were 
> from Kris Pister (see acknowledgement in Section 3, p. 16).
>
> perceptions thereof), but I do not entirely understand the background 
> of these emails.
>
> (including confusions and misconceptions of 802.15.4 security), I 
> would like to encourage everyone to read the draft
> 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
>
>
> email:[email-masked]  | Skype: rstruik

---

From: Kris Pister <[email-masked]>
Date: Fri, 22 May 2015 09:08:48 -0700

[ 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.
>
> draft-struik-6tisch-security-architectural-considerations-01 and I 
> have not seen any new technical argument being made on the list (to my 
> necessarily a new argument and was discussed as "network segregation" 
> in draft-struik-6tisch-security-architectural-considerations-01 
> (Section 1.2, #8.}
>
> 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:
>
>     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 //
> 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.
>
> 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.
> 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
>
>
>> 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).
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 May 2015 16:29:24 +0000

Hi Tero:

The thing we (seem to) disagree upon is whether this is minimal's problem. 

I think it's everybody's problem and minimal inherits from it like everyone else and should not be the place where the security behavior is specified. I do agree, though, that it's good that we propose a minimal and simple set up for the purpose of interop tests.

Like I said, I think that minimal should say that it depends on MAC layer packets to be secured appropriately to protect MAC operations and to guarantee authenticity of L3 content, but does not need specify how that happens.

And because MAC layer packets are secured, RPL does not need to be so section 10 of RPL can be omitted by implementations.

But because we do not seem to reach consensus on new text, I think along René's recommendation to fall back on the original text that reached consensus, suggesting a key "6tisch-minimal15"  (string format + Hexa) to serve as K1 for the interop test.

Do we have consensus on this?

Pascal

> Sent: lundi 18 mai 2015 17:38
> Yes, I agree that. On the other hand I do not think this is important for minimal. I
> would much rather use K1 to properly authenticate EBs AFTER the initial join
> process, which requires it not to be well-known.
> 
> > - The poor frame error protection (FCS-only) is a generic problem that
> > is only present if the security design allows for K1 to be unknown by
> > the joining node.
> 
> We are talking about few dozen frames DURING the initial bootstrap phase. You
> need really crappy network to get that many errors which pass the FCS, to cause
> the bootstrap to fail, and even then you need bad implementation of the parser
> who is parsing the frames to get messed up with those. If there is that crappy
> network, then most likely the network will not work at all, as most of the frames
> will be dropped by bad FCS.
> 
> I.e. if you get 1 wrong bit every 1000 bits, that means that you have an have one
> error in most of your full length frames. To get another error to the same frame
> in such way that the FCS still matches will still not be very probable. Someone
> can probably calculate that.
> 
> Your case of there being billions devices out there all time, is not really valid, as
> there will be only few hundred of those billion devices doing "the once in the
> lifetime joining process" at the same time (assuming 10 year lifetime of devices
> and joining process taking hundred seconds).
> 
> We are not talking FCS protecting normal data traffic, we are talking about the
> FCS protecting the about 10-20 frames used during the bootstrapping phase.
> Actually the joining process running KMP or similar will of course validate all
> data sent inside KMP when doing authentication, so the the frames where errors
> can cause problem is the EBs. You need to get one EB received properly to be
> able to start joining the network. Even in EBs, most of the errors will cause the
> frame to be ignored (i.e. if there is anything wrong with the IE lengths or IE IDs
> etc then frame most likely will be ignored).
> 
> Even if EBs had errors, and because of that joining process failed, that simply
> means we start the process from beginning, and try again.
> 
> Yes, for joining. But for rejoining after you have already been part of network,
> or cases where network is reconfigured etc, having a proper K1 will prevent
> attackers from doing nasty attacks, but using well-known K1 will not.
> 
> > About your new points:
> >
> > Why would he need to match the FCS? If the MIC is unknown then it can
> > send whatever it likes and then compute a CRC over it.
> 
> I.e. to get two random bit errors to same frame, so that FCS still matches, does
> not happen that often.
> 
> The story about Zigbee and WireHART is completely different to that, as both
> devices of course did calculate proper FCS, thus Zigbee devices did properly
> receive the WireHART packets, and then got messed up when their
> implementation didn't know what to do with them.
> 
> No, that is general wisdom of writing code. I know this is new to some people
> writing code (especially in IoT space), but you really should validate stuff that
> you receive before you act on it... :-)
> 
> Actually it is upper layers problem. I.e. when the device does scanning the MAC
> will simply pass beacons to the next higher layer and the next higher layer will
> then parse IE lists etc to check if the beacon is acceptable. I.e. this filtering is
> something we need to specify in 6tisch, as 802.15.4 does not provide that.
> 
> > only as good as the L2 security will be because there is no additional
> > L3 security to protect, say, RPL.
> 
> I.e if there is no L2 security because well-known key is used there is no security
> at all in minimal?
>

---

From: Rene Struik <[email-masked]>
Date: Fri, 22 May 2015 12:45:00 -0400

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,
> 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
> 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
>> 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).
>>
>>     toys. They all use 15.4e,  although not well.  Each one
>>     broadcasts an EB every second, and it includes all of the //
>>> 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).
>>>
>>> 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
>>> 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
>>>
>>>

---

From: Kris Pister <[email-masked]>
Date: Fri, 22 May 2015 10:36:19 -0700

> 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."
>
> labels/colors all "6tisch-minimal15" with one brush, this sounds 
> "crude" to me....]
>
> Rene
>
>> of a macKeyTable gets implemented in software and hardware in a lot 
>> of different
>>> 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:
>>>
>>> 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.
>>>
>>> beacon a string that is a function of "6tisch-minimal15") and 
>>> suppose the security considerations in 
>>> 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.
>>>
>>> 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
>>>
>>>
>>>> It is always great to recount anecdotal evidence. However, I fail 
>>>> to see why this should necessarily apply to 6tisch.
>>>>
>>>> segregation. This technical topic was discussed in Section 1.2, 
>>>> item #8 of the draft 
>>>> 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
>>>>
>>>>

---

From: Rene Struik <[email-masked]>
Date: Fri, 22 May 2015 14:11:29 -0400

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:
> Implementers write state machines.  When mote is in state "JOIN-0", 
> load hardware
>>> [ So far we have fake keys and crude segmentation.  I'm going to 
>>> have to start naming
>>> installed you'd have a pristine key for holy segmentation and 
>>> joining for the
>>> production network.
>>>
>>> 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.
>>> need a 9B header to define this - it's just what the software does 
>>> to be compliant
>>>> 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
>>>>     are 400 correctly-formed  15.4e EBs per second arriving from
>>>>     the store next door, and Charlie's sensors take //
>>>> 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.
>>>>
>>>> 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 
>>>> 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.
>>>> 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
>>>>
>>>>
>>>>> 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).
>>>>>

---

From: Kris Pister <[email-masked]>
Date: Fri, 22 May 2015 11:36:04 -0700

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.
>
> 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
>
>> > key "6tisch-minimal15" via another mechanism in 802.15.4, that 
>> would be great.
>>
>>> 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 
>>> instantiate a default key "6tisch-minimal15" via another mechanism 
>>> in 802.15.4, that would be great.
>>>
>>>> 2) If you have an out-of-band configuration step, then set it to 
>>>> the particular
>>>>> 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).
>>>>>
>>>>>     //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 //
>>>>> Quick question, though: if one would indeed use a well-known key 
>>>>> as network segregation mechanism (where each device implementing 
>>>>> is a well-known string, the behavioral semantics of I/O seems to 
>>>>> be jeopardized.
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>> 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?
>>>>>>
>>>>>> (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
>>>>>>
>>>>>>

---

From: Rene Struik <[email-masked]>
Date: Fri, 22 May 2015 15:21:17 -0400

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:
> I believe that you will be able to do this in a fully 
> 802.15.4-compliant way.
>
> ksjp
>
>> 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.
>>
>>>>> followed by join?  I wasn't sure), then you might have one fake 
>>>>> key for crude
>>>>> of a macKeyTable gets implemented in software and hardware in a 
>>>>> lot of different
>>>>>> 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).
>>>>>>
>>>>>> (very crude) filtering of the very first enrollment message. 
>>>>>> {This is not necessarily a new argument and was discussed as 
>>>>>> "network segregation" in 
>>>>>> 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:
>>>>>>
>>>>>> least partially a policy setting issue and should be dealt with 
>>>>>> as part of flexible device management.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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, 
>>>>>>> It is always great to recount anecdotal evidence. However, I 
>>>>>>> fail to see why this should necessarily apply to 6tisch.
>>>>>>>
>>>>>>> re IE header fields were from Kris Pister (see acknowledgement 
>>>>>>> in Section 3, p. 16).
>>>>>>>

---

From: Kris Pister <[email-masked]>
Date: Fri, 22 May 2015 16:15:18 -0700

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:
> 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.
>
> b) it saves (net) 6 octets in the enhanced beacon frame, with 
> following breakdown:
> 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.
>
>>> 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.
>>>
>>>>> I just wanted to focus on one remark in your email: "You don't 
>>>>> to be compliant with a higher-layer standard."
>>>>>
>>>>>> 3) if you have a two-phase join process (Michael - are you 
>>>>>> calling this imprint
>>>>>> 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
>>>>>>> I once again completely lost track of the utterly confusing 
>>>>>>> email chain regarding the security section of the minimal draft.
>>>>>>>
>>>>>>> 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 
>>>>>>>     robot toys. They all use 15.4e,  although not well.  Each
>>>>>>>     one broadcasts an EB every second, and it includes all of the //
>>>>>>> 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.
>>>>>>>
>>>>>>> the beacon a string that is a function of "6tisch-minimal15") 
>>>>>>> and suppose the security considerations in 
>>>>>>> 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.
>>>>>>>> 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
>>>>>>>> months old draft and only bring up topics not already dealt 
>>>>>>>> with there.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Rene
>>>>>>>>
>>>>>>>>

---

From: Rene Struik <[email-masked]>
Date: Fri, 22 May 2015 23:54:42 -0400

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:
> If I generate a secure random 128 bit number to use as K1, and I 
> program that number
>> 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.
>>
>>     --- saves 8 octets in the auxiliary security header (1 octet vs. 
>> 9 octets for key identifier fields);
>> (using frame-based synchronization [assuming beaconing device as 
>> clock tower parent]).
>> 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
>>
>>
>>>> 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.
>>>>
>>>>> Implementers write state machines.  When mote is in state 
>>>>> "JOIN-0", load hardware
>>>>>> does to be compliant with a higher-layer standard."
>>>>>>
>>>>>> instantiate a default key "6tisch-minimal15" via another 
>>>>>> mechanism in 802.15.4, that would be great.
>>>>>>
>>>>>>> any ideas that I may have to contribute.  I have some thoughts 
>>>>>>> on naive networking,
>>>>>>> Whatever value you choose for K1, you will need to store it.  
>>>>>>> The abstraction
>>>>>>> is for a given chip and stack, that's the one you use for 
>>>>>>> storing K1, whatever it's value.
>>>>>>>> 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).
>>>>>>>>
>>>>>>>> managed} to interfere with one's own network, in case these 
>>>>>>>> both implement that spec (this was the toy store vs. 
>>>>>>>>     there are 400 correctly-formed  15.4e EBs per second
>>>>>>>>     arriving from the store next door, and Charlie's sensors
>>>>>>>>     take //
>>>>>>>> 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 
>>>>>>>> are considered not of interest,
>>>>>>>> source" for the key "6tisch-minimal15". Who would this 
>>>>>>>> "someone" be? Currently, this is not defined.
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>> 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 
>>>>>>>>> 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).
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>

---

From: Kris Pister <[email-masked]>
Date: Sun, 24 May 2015 09:37:26 -0700

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
>
>> I'm pretty sure that there *is* a way.  I'm pretty sure that I can 
>> set Key Identifier Mode to 00,
>>> 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
>>>
>>>
>>>>> 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
>>>>>
>>>>>>>> 2) If you have an out-of-band configuration step, then set it 
>>>>>>>> to the particular
>>>>>>>>> the list (to my knowledge; it is very hard to absorb the 
>>>>>>>>> entire sequence of emails).
>>>>>>>>>
>>>>>>>>> enrollment message. {This is not necessarily a new argument 
>>>>>>>>> and was discussed as "network segregation" in 
>>>>>>>>> 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 
>>>>>>>>> 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 
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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 
>>>>>>>>>> 802.15.4 security), I would like to encourage everyone to 
>>>>>>>>>> read the draft

---

From: Malisa Vucinic <[email-masked]>
Date: Sun, 24 May 2015 15:52:35 -0700

Rene, Kris, Tero,

I tried to do a little exercise and here is the flow with implicit, pre-shared keys I see as standard compliant. Please correct me if I have misunderstood something.

Step 0 - JN instantiates:

SecurityLevelDescriptor_EB = {FrameType = BEACON, CommandFrameIdentifier = undefined, SecurityMinimum = MIC_32, DeviceOverrideSecurityMinimum = FALSE, AllowedSecurityLevel = {MIC_32, MIC_64, MIC_128} }

Step 1 - JN receives a frame (EB) from JA. JN parses the header and learns that it is an EB, JA’s addressing mode which is SHORT/EXTENDED, address SHORT_ADDRESS_JA/EXTENDED_ADDRESS_JA, PAN_ID_JA, ASN. JN knows that the join process is ongoing so it invokes a join-specific routine *before* checking steps from the incoming frame security procedure (Sec. 7.2.3). The join-specific routine instantiates: 

KeyIDLookupDescriptor_JA = { keyIDMode = IMPLICIT, KeySource = undefined, KeyIndex = undefined, DeviceAddrMode = SHORT/EXTENDED, DeviceAddress = SHORT_ADDRESS_JA/EXTENDED_ADDRESS_JA }

KeyUsageDescriptor_K1 = { FrameType = BEACON, CommandFrameIdentifier = undefined }

KeyDescriptor_K1 = { KeyIDLookupList = KeyIDLookupDescriptor_JA, , KeyUsageList = KeyUsageDescriptor_K1, Key = K1 }

DeviceDescriptor_JA = { PANId = PAN_ID_JA, Address = ShortAddress or ExtAddress depending on JA’s addressing mode, FrameCounter = ASN, Exempt = False } 

Step 3 - JN checks steps from 7.2.3, i.e. the incoming frame security procedure. During the steps from 7.2.3, JN invokes KeyLookup Procedure from 7.2.2 with device PAN ID = PAN_ID_JA, device addressing mode = JA’s addressing mode, device address = SHORT_ADDRESS_JA/EXTENDED_ADDRESS_JA, KeyIdMode = IMPLICIT, KeyIndex = undefined, KeySource = undefined. In terms of the logic flow, procedure in 7.2.2 ends up in a.4 and a.5. 

On the JA side, JA needs to follow the outgoing security procedure in 7.2.1 to secure EBs. I am not clear if macCoordExtendedAddress attribute is still valid in TSCH which seems to be necessary for the Key Lookup procedure to pass with beacons. JA would need to instantiate: 

KeyIDLookupDescriptor_K1 = { keyIDMode = IMPLICIT, DeviceAddrMode = NO_ADDRESS, DeviceAddress = macCoordExtendedAddress (JA's extended address) }

KeyUsageDescriptor_K1 = { FrameType = BEACON, CommandFrameIdentifier = undefined }

KeyDescriptor_K1 = { KeyIDLookupList = KeyIDLookupDescriptor_K1, , KeyUsageList = KeyUsageDescriptor_K1, Key = K1 }

Regards,
Mališa Vučinić

> On 24 May 2015, at 09:37, Kris Pister <[email-masked]> wrote:
> 
> 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
> How the macKeyTable is populated is not described.  In particular, we know that
> The information contained in an EB is sufficient to allow a JN receiving that EB
>> 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
>> 
>>> 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

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 May 2015 13:34:51 +0300

Kris Pister writes:
> 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.

You need to specify how that K1 will be identified in the frames. For
the 802.15.4 the keys in the frames are identified using the
combination of KeyIdMode, KeySource and KeyIndex. KeyIdMode 0b00 is
not used for group keys, it is for pairwise keys between peers.

KeyIdMode 0b01 uses only KeyIndex to identify key, and it assumes
everybody in the network already have predefined macDefaultKeySource
that is used to identify to the owner of the key. This is not really
usable for the joining, as the joining device does not know the
macDefaultKeySource or if everybody is using default macDefaultSource
(all ff's) then this does not separate networks using different
well-known keys.

KeyIdMode 0b10 uses KeySource consisting of PAN ID and short address, in
addition to the KeyIndex. As the PAN ID is unknown before we start
joining the network, the joining device cannot configure the Key to
the MAC before it knows the PAN ID, and then we would need some kind
of definition in the minimal draft saying that short address of xxxx
is allocated for this etc.

What Rene was saying that for something that really works is to use
KeyIde Mode 0b11 which uses 64-bit extended address as KeySource, in
addition to the KeyIndex. And in this mode we would specify the 64-bit
extended address that would be used for this well know key. This will
mean you will use 9 octet KeySource field.

If bootstrapping phase, or provisioning step is used, those KeyIdMode,
KeySource and KeyIndex associated with the ky can be distributed at
that point.

If we do not ues the 9 octet header, then what shall we use for
KeyIdMode, KeySource and KeyIndex when using the well-known K1 key?
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 May 2015 14:12:06 +0300

Pascal Thubert (pthubert) writes:
> But because we do not seem to reach consensus on new text, I think
> along René's recommendation to fall back on the original text that
> reached consensus, suggesting a key "6tisch-minimal15"  (string
> format + Hexa) to serve as K1 for the interop test. 
> 

I do not really think we had consensus on that text either, as the
reason why this discussion started was because there was complains
about that text. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 May 2015 14:34:21 +0300

Kris Pister writes:
> 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?

For that you can use KeyIdMode 0b01 with one octet KeySource
consisting the KeyIndex you distributed along the K1.

I.e. you say that there is group key using KeyIdMode 0b01 identified
with KeyIndex xx having key K1 during the bootstrap, and then you can
use that key to protect joining.

> 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 .

No. The KeyIdMode 0b00 is not meant for group keys. It is meant to be
used for pairwise keys between peers. I.e. where the keys can be known
because the source and destination addresses of the peers are known.

To be able to use it you need to already know the macPanId and the
macCoordExtendedAddress. Before you join the network you do not know
those, so you cannot really fill in the information.

The bigger problem is that there is only one such key between pairs,
i.e. there is no way to have K1 and K2 both using KeyIdMode 0b00.

> Perhaps Tero can tell us if this is still true in -2015.

This is still mostly unchanged in 2015. We did change it a bit, mostly
because 802.15.4e added ability to have PAN ID Compression modes where
we do not have any PAN ID in the mac header, even when we are not
using DeviceAddressingMode of NONE, and the KeyDescriptor lookup
procedure assumed that we always have device PAN ID.

We also cleaned up the macDefaultKeySource from the KeyIdMode 0b01. It
was comparing PIB constant with non-existing field in the mac header
i.e. there is no point of comparining the PIB macDefaultKeySource
value to the KeySource field of the mac header, as the KeySource field
is empty when using KeyIdMode 0b01.

Anyways, for minimal I think we could use KeyIdMode 0b01, but that
requires us to use some kind of bootstrap case where we distribute
which KeyIndex is used for K1 and K2. Note, that KeyIndex changes
every time you rekey the group keys in the network.

If you want uniquely identify the well-known keys, then you really
need to use KeyIdMode 0b11 with well-known extended-address and
KeyIndex associated to K1 as Rene described.

Of course this 9-octet KeySource field provides a way to identify
proper network to join in much cleaner way than checking MIC with
well-known keys... I.e. if the EB has proper KeySource identifying our
well known extended address of our network this will cleanly separate
multiple different networks from each other.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 May 2015 15:38:01 +0300

Malisa Vucinic writes:
> I tried to do a little exercise and here is the flow with implicit,
> pre-shared keys I see as standard compliant. Please correct me if I
> have misunderstood something. 
> 
> SecurityLevelDescriptor_EB = {FrameType = BEACON,
> CommandFrameIdentifier = undefined, SecurityMinimum = MIC_32,
> DeviceOverrideSecurityMinimum = FALSE, AllowedSecurityLevel =
> {MIC_32, MIC_64, MIC_128} } 

As you have specified the AllowedSecurityLevel there is no point of
listing SecurityMinimum. SecurityMinimum is only used if
AllowedSecurityLevel is empty.

> Step 1 - JN receives a frame (EB) from JA. JN parses the header and
> learns that it is an EB, JA’s addressing mode which is
> SHORT/EXTENDED, address SHORT_ADDRESS_JA/EXTENDED_ADDRESS_JA,
> PAN_ID_JA, ASN. JN knows that the join process is ongoing so it
> invokes a join-specific routine *before* checking steps from the
> incoming frame security procedure (Sec. 7.2.3). The join-specific
> routine instantiates:

You cannot really do that. MAC will run the filttering rules for the
frame, and then continue to the incoming frame security procedure and
only after that willit pass the frame forward.

In normal case it would discard the frame as the security processing
fails, but because this is doing active/passive scanning now it will
still store the information about the beacon even when the incoming
frame security processing failed.

I.e you will be able to see the EB even when the security processing
failed, but you will not be able to get the well-known keys in place
for the first EB so it would be checked by the MAC.

Lets assume you could run this process inside the MAC, and check the
rest of the stuff here.

> KeyIDLookupDescriptor_JA = { keyIDMode = IMPLICIT, KeySource =
> undefined, KeyIndex = undefined, DeviceAddrMode = SHORT/EXTENDED,
> DeviceAddress = SHORT_ADDRESS_JA/EXTENDED_ADDRESS_JA }

I assume KeyIdMode = IMPLICIT means KeyIdMode = 0b00? There is no
IMPLICIT in 802.15.4 or 802.15.4e.

If you use KeyIdMode of 0b00 you would also need to set the
DevicePANId.

> KeyDescriptor_K1 = { KeyIDLookupList = KeyIDLookupDescriptor_JA, ,
> KeyUsageList = KeyUsageDescriptor_K1, Key = K1 }

In this you also need to fill in the DeviceDescriptorHandleList which
will point to the DeviceDescriptor of the other end. For that you need
to know the PANId and ExtAddress of the other end, and you may also
fill in the ShortAddress if you know it.

To be able to fill those values in, the beacon needs to be sent out
using the extended address of the coordinator.

I.e. if the beacons used Extended addresses then you can fill all this
information in, but as there can be only one KeyIdMode 0b00 key
between pairs, this means you cannot use KeyIdMode 0b00 for K2, so for
that you need to use something else.

Also this will limit the usability of pairwise keys, as they would
normally use KeyIdMode 0b00, i.e. later when device wants to create
pairwise key between the coordinator and device, they could not fill
it in as there is already this K1 key in place (and if you remove the
K1 key before installing the pairwise key, you would get security
errors for each EB the device is trying to process after that point).

> DeviceDescriptor_JA = { PANId = PAN_ID_JA, Address = ShortAddress or
> ExtAddress depending on JA’s addressing mode, FrameCounter = ASN,
> Exempt = False }

For DeviceDescriptor you must fill in the ExtAddress, and PANId. They
are not optional regardless of the JA's addressing mode. The
ShortAddress can be left out (or filled up with 0xfffe if device is
only using extended address, or 0xffff if it is unknown).

Note, that you do not know ASN at this point. This is way before the
Payload IEs are parsed, so you cannot get the ASN from the TSCH
Synchronization IE. On the other hand it does not matter really, as
the FrameCounter is not used for Nonce generation, ASN is used
directly.

> Step 3 - JN checks steps from 7.2.3, i.e. the incoming frame
> security procedure. During the steps from 7.2.3, JN invokes
> KeyLookup Procedure from 7.2.2 with device PAN ID = PAN_ID_JA,
> device addressing mode = JA’s addressing mode, device address =
> SHORT_ADDRESS_JA/EXTENDED_ADDRESS_JA, KeyIdMode = IMPLICIT, KeyIndex
> = undefined, KeySource = undefined. In terms of the logic flow,
> procedure in 7.2.2 ends up in a.4 and a.5.

Yes.

> On the JA side, JA needs to follow the outgoing security procedure
> in 7.2.1 to secure EBs. I am not clear if macCoordExtendedAddress
> attribute is still valid in TSCH which seems to be necessary for the
> Key Lookup procedure to pass with beacons.

Yes, for KeyIdMode 0b00 with beacons, the macCoordExtendedAddress is
always used. 

> JA would need to
> instantiate:  
> 
> KeyIDLookupDescriptor_K1 = { keyIDMode = IMPLICIT, DeviceAddrMode =
> NO_ADDRESS, DeviceAddress = macCoordExtendedAddress (JA's extended
> address) }

Yes.

> KeyDescriptor_K1 = { KeyIDLookupList = KeyIDLookupDescriptor_K1, ,
> KeyUsageList = KeyUsageDescriptor_K1, Key = K1 } 

Yep. 

Now you of course have the problem how to identify the K2 key for the
network... You cannot use KeyIdMode 0b00, as you can only have one of
them.

I think it would be better to define so that when JA sends EBs out it
configures its EBs as follows:

It always sends them out using extended address as a source address,
thus fills in secKeyIdLookupDescriptor for K1 with following values (I
am using the 2015 naming, as they are bit clearer than 2011 versions,
and I will leave undefined values out, or values which are not
releveant for this dicussion):

secKeyIdLookupDescriptor(K1)
	secKeyIdMode = 0b01
	secKeyIndex = 0b42 (value defined in minimal draft, or
		      	   negotiated during bootstrap process).

secKeyDescriptor(K1)
	secKeyUsageList = { (secFrameType = beacon) }
	secKey = <K2 key>

For K2 it will use separate KeyIndex.

When it sends beacon out it will send it having extended address as
SourceAddressingMode and using Extended address in its Source Address.
The Source PAN Identifier are filled in as normally.

The JN will fill in the security tables as followS:

secKeyIdLookupDescriptor(K1)
	secKeyIdMode = 0b01
	secKeyIndex = 0b42 (value defined in minimal draft, or
		      	   negotiated during bootstrap process).

secKeyDescriptor(K1)
	secKeyUsageList = { (secFrameType = beacon) }
	secKey = <K1 key>

When it starts joining process the first EB is received, but cannot be
verified by the MAC as the secDeviceDescriptor is not filled in and
ASN is not known.

When during the scanning it finds EB it could accept, it can take the
ASN from TSCH Synchronization IE, configure it to the MAC (how it will
set that properly to MAC is bit difficult, as setting the macASN by
the upper layer might not work, as we might already be on the next
timeslot by the time upper layer manages to set the ASN).

Then it would also create secDeviceDescriptor for the coordinator
sending beacons:

secDeviceDescriptor(coordinator)
	secPanId = <pan id from EB frame>
	secShortAddress = 0xffff (== unknown)
	secExtAddress = <extended address from EB frame>
	secExempt = FALSE

Now, if the ASN is right, it will be able to authenticate the next EB
that comes in (or if it has ability to push old received EB back to
mac for security check after filling in the tables).

The K2 would use same KeyIdMode 0b01 but with different KeyIndex. The
bad thing here is that devices would try to do this for all possible
networks using KeyIdMode 0b01 and same KeyIndex, thus this will not
provide full network separation...
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 25 May 2015 13:05:43 +0000

Hum:

We thought there was, including René. I think the problem came up with the proposal by Kris and that's what we have been discussing.
This discussion has forked but the title remains; we want to ship minimal and the only road block is security. 

We want to say is that minimal does not use L3 security (e.g. the optional one in RPL), and that it needs proper L2 security for both L2 itself (e.g. for the join process) and for L3 PDUs within the LLN.

Can you please verify where/if/how the current text is wrong and propose a fix?

Cheers,

Pascal

> Sent: lundi 25 mai 2015 13:12
> > reached consensus, suggesting a key "6tisch-minimal15"  (string format
> > + Hexa) to serve as K1 for the interop test.
> >
> I do not really think we had consensus on that text either, as the reason why this
> discussion started was because there was complains about that text.
> --
> [email-masked]

---

From: Malisa Vucinic <[email-masked]>
Date: Mon, 25 May 2015 17:42:30 -0700

> On 25 May 2015, at 05:38, Tero Kivinen <[email-masked]> wrote:
> 

Right, so in the worst case the join-specific routine can be invoked after we have discarded one EB and for the subsequent one everything should be in place. Otherwise, one will have an upper-layer callback within MAC, as this part of the spec is usually implemented in software i.e. firmware, that invokes the join-specific routine and prepares everything for the first received EB. Would that be non standard compliant? :)

> network... You cannot use KeyIdMode 0b00, as you can only have one of

Well, consider that beacons can also be sent with short Destination Addressing Mode and 0xffff Destination Address field. Given that KeyDescriptor Lookup in case of KeyIdMode 0b00 (implicit) differentiates among different keys based on device address, PAN and addressing mode, you could use the short broadcast address (0xffff) to instantiate the KeyDescriptor, no? Each EB would be secured using the KeyDescriptor that corresponds to the 0xffff address. The question then is if there is a way to differentiate between DATA broadcast frames and beacons for K1 during the outgoing security procedure. Since the incoming procedure checks the key usage policy (7.2.7) I don’t see a problem on the receiving side. 

> 	secKeyUsageList = { (secFrameType = beacon) }

I believe you mean <K1 key>. 

> The K2 would use same KeyIdMode 0b01 but with different KeyIndex.

KeyIdMode 0b01 for both K1 and K2 is more flexible but I am not sure if this is necessary for minimal. Otherwise, we can consider using K1 with KeyIdMode 0b01 (one extra byte for Key Index) and K2 with KeyIdMode 0b00 (implicit, no extra bytes).

> The
> provide full network separation…

Device will try to authenticate the EB (whichever EB the implementation-specifics allow it to authenticate) with K1 it has preinstalled. Wrong network and this will fail, no? 

Regards,
Mališa Vučinić

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 26 May 2015 12:26:02 +0300

Pascal Thubert (pthubert) writes:
> We thought there was, including René. I think the problem came up
> with the proposal by Kris and that's what we have been discussing. 
> This discussion has forked but the title remains; we want to ship
> minimal and the only road block is security.  

I think the minimal is missing other things too. For example it is
missing the mapping from the K1 and K2 to the actual KeyIdMode,
KeySource, KeyIndex used on the wire.

> We want to say is that minimal does not use L3 security (e.g. the
> optional one in RPL), and that it needs proper L2 security for both
> L2 itself (e.g. for the join process) and for L3 PDUs within the
> LLN.

But well-known keys do NOT provide proper L2 security. 

> Can you please verify where/if/how the current text is wrong and

I have done that in my other emails, see for example:

http://www.ietf.org/mail-archive/web/6tisch/current/msg03362.html
http://www.ietf.org/mail-archive/web/6tisch/current/msg03268.html

And there were my comments to the replacement text too:

http://www.ietf.org/mail-archive/web/6tisch/current/msg03475.html
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 May 2015 09:43:32 +0000

Our disagreement exactly, Tero.

I do not think minimal is the place to define what proper security is. This is use case dependent. 
If we are confident that 802.15.4 can be secured at layer-2, I'm all set. We need to indicate that it is so and let people use it.

If we want to define how that is done per use case, that's a Pandora box that I do not want to open with this draft.

Cheers,

Pascal

> Sent: mardi 26 mai 2015 11:26
> > We thought there was, including René. I think the problem came up with
> > the proposal by Kris and that's what we have been discussing.
> I think the minimal is missing other things too. For example it is missing the
> mapping from the K1 and K2 to the actual KeyIdMode, KeySource, KeyIndex used
> on the wire.
> 
> > L2 itself (e.g. for the join process) and for L3 PDUs within the LLN.
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 26 May 2015 13:20:16 +0300

Malisa Vucinic writes:
> Right, so in the worst case the join-specific routine can be invoked
> after we have discarded one EB and for the subsequent one everything
> should be in place. Otherwise, one will have an upper-layer callback
> within MAC, as this part of the spec is usually implemented in
> software i.e. firmware, that invokes the join-specific routine and
> prepares everything for the first received EB. Would that be non
> standard compliant? :) 

Such implementation might not be against standard, but to get some
existing implementation to do that, might be really hard.

Of course if your implementation does everything on software, then you
can do that, but if you have hardware doing the security processing
for frames, it might be really hard to be able to hook into that. 

> Well, consider that beacons can also be sent with short Destination
> Addressing Mode and 0xffff Destination Address field.

We are talking about source addresses here, not destination. Source
address should not be broadcast...

And KeyIdMode 0b00 cannot be used with broadcast addresses for
non-beacon frames. See the note at the end of KeyDescriptor lookup
procedure which says:

	NOTE—For broadcast frames, the KeyDescriptor lookup procedure
	will result in Status set to FAILED if implicit key
	identification is used. Hence, explicit key identification
	should be used for broadcast frames.

> Given that KeyDescriptor Lookup in case of KeyIdMode 0b00 (implicit)
> differentiates among different keys based on device address, PAN and
> addressing mode, you could use the short broadcast address (0xffff)
> to instantiate the KeyDescriptor, no?

The keys are identified by the source address. Destination address
does not matter when finding the key (of course it will matter who
will actually do the incoming frame security procedure, i.e. which
device receives the frame).

It is possible in the sending end to have multiple KeyIdMode 0b00 keys
for different addresses. but for receiving end will just use the
source address of the frame to find the key. So if the device A has
KeyIdMode 0b00 key for coordinator B the device A will find the same
key always for same address.

> Each EB would be secured using the KeyDescriptor that corresponds to
> the 0xffff address. The question then is if there is a way to
> differentiate between DATA broadcast frames and beacons for K1
> during the outgoing security procedure. Since the incoming procedure
> checks the key usage policy (7.2.7) I don’t see a problem on the
> receiving side.

Key Usage Policy is done after we have found the key. It does not
affect the key lookup. I.e. the incoming frame security policy will
find the key using the KeyDescriptor lookup procedure, and then it
will later check whether that key was ok to be used for those frames.

Yes.
> KeyIdMode 0b01 for both K1 and K2 is more flexible but I am not sure
> if this is necessary for minimal.

I think it is mandatory if you want to use two different keys. 

> Otherwise, we can consider using K1 with KeyIdMode 0b01 (one extra
> byte for Key Index) and K2 with KeyIdMode 0b00 (implicit, no extra
> bytes).

That is fine as long as K2 key is never used with broadcast keys...
KeyIdMode is not supposed be used with broadcast keys (or actually any
group keys).

Also this makes it impossible for K2 to be rekeyed. With KeyIdMode
0b01 you can rekey by installing new key with new index, and
distribute the new key to all devices. When that is done, you can
switch the network to use new key, and then remove the old key.

With KeyIdMode 0b00 this is not possible, as there you need to do this
atomically for the whole network. 

> > The bad thing here is that devices would try to do this for all
> > possible networks using KeyIdMode 0b01 and same KeyIndex, thus
> > this will not provide full network separation…
> 
> Device will try to authenticate the EB (whichever EB the
> implementation-specifics allow it to authenticate) with K1 it has
> preinstalled. Wrong network and this will fail, no?  

Yes, but people were concerned that we try to connect to wrong
networks, and if you need to wait for EB, install keys etc, wait for
next EB, and then notice that the network is wrong, this is quite slow
process...

Having random KeyIndex for minimal would provide additional filter
when selecting network, but it is weaker than what can be done with
well-known extended address in KeySource or vendor specific IE
containing network id in EB... 
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 May 2015 13:51:15 +0000

Hello Tero:

As I hinted, that thread was a response to a proposal by the authors to update the security section.
http://www.ietf.org/mail-archive/web/6tisch/current/msg03440.html 

The plan B we agreed upon, if we failed to reach a better argument, was to stick to the current text which according to René reached consensus.

The security section as it stands is this:
"

   As this document refers to the interaction between Layer 3 and Layer
   2 protocols, this interaction MUST be secured by L2 security
   mechanisms as defined by [IEEE802154e].  Two security mechanisms are
   considered, authentication and encryption, authentication applies to
   the all packet content while encryption applies to header IEs and MAC
   payload.  Key distribution is out of scope of this document, but
   examples include pre-configured keys at the nodes, shared keys among
   peers or well-known keys.  Refer to the 6TiSCH architecture document
   [I-D.ietf-6tisch-architecture] for further details on key
   distribution and advanced security aspects. 

   The present document assumes the existence of two keys, which can be
   well-known by the network devices and/or pre-configured.  One of the
   keys (K1) is used to authenticate EBs (all frame).  As defined in
   Section 4 EBs MUST be authenticated but payload not encrypted.  This
   prevents two independent networks to interfere or enable non-allowed
   nodes to join a particular network.  A second key (K2) is used to
   authenticate and encrypt the payload of DATA, ACKNOWLEDGEMENT, MAC
   COMMAND frame types and respective header IEs.

"

This is the text I'm asking you whether it is acceptable or not, and if not, what would be the minimal surgery that would make the text acceptable from your standpoint?

Note that removing text may be easier than agreeing on well-known vs. not.

Cheers,

Pascal

---

From: Tom Phinney <[email-masked]>
Date: Tue, 26 May 2015 07:07:21 -0700

>     should be used for broadcast frames.
Unless this apparent requirement appears in the normative text of the 
quoted IEEE 802.15.4 standard, and not just in this putatively 
informative (i.e., not normative) note, then it is not actually relevant 
to conformance to IEEE 802.15.4.

This example demonstrates precisely why ISO and IEC are adamant that 
NOTEs be written in such a way that no reader can presume them to be 
adding to the requirements of the containing standard. Notes ARE 
strictly informative.

===

---

From: Pat Kinney <[email-masked]>
Date: Tue, 26 May 2015 09:51:53 -0500

Tom:
This standard is correctly written, please note that the excerpt has a footnote [12] that states what you stated.

In this case, the note is indeed informative, giving the reader insight as to why implicit key identification should not be used for broadcast frames, however their use is not prohibited.

NOTE—For broadcast frames, the KeyDescriptor lookup procedure will result in Status set to FAILED if implicit key
identification is used. Hence, explicit key identification should be used for broadcast frames.12

12 Notes in text, tables, and figures are given for information only and do not contain requirements needed to implement the standard.

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked]

On 26, May2015, at 9:07, Tom Phinney <[email-masked]> wrote:

>    should be used for broadcast frames.
Unless this apparent requirement appears in the normative text of the quoted IEEE 802.15.4 standard, and not just in this putatively informative (i.e., not normative) note, then it is not actually relevant to conformance to IEEE 802.15.4.

This example demonstrates precisely why ISO and IEC are adamant that NOTEs be written in such a way that no reader can presume them to be adding to the requirements of the containing standard. Notes ARE strictly informative.

===

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 27 May 2015 01:15:49 +0300

Pascal Thubert (pthubert) writes:
> If we are confident that 802.15.4 can be secured at layer-2, I'm all
> set. We need to indicate that it is so and let people use it. 

But you still want to include well-known key in the draft for testing
purposes, even when you know that you need to agree on couple of dozen
other things before you can interoperate with two implementations.

And I am sure it can be done unsafely. I am not sure there are that
many people in the world who know how it can be done so it is actually
secure.

I have real fear about the security of 802.15.4 networks in general,
the more I look at the things left out in the specification, i.e.
things that implementors need to decide, the more I found subtle ways
to cause security issues if the vendor implementing things do not know
what they are doing.

> If we want to define how that is done per use case, that's a Pandora
> box that I do not want to open with this draft. 

The Pandora's box is already open, it is called 802.15.4. To be able
to use that box safely you need to know how it works very well, and
understand minute details in the security processing of it. I think it
would be worth of effort to document that in the IETF, i.e. how to
make 6tisch secure. IEEE 802.15.4 cannot do that, as there are so many
environments that needs to be considered, and they need to support
everything, even the broken stuff from the past. In the 6tisch we
could profile the 802.15.4 TSCH in such way, that we take secure
subset of it, and define how it is used securely. We can do it now as
there is no 6tisch networks yet out, so we do not need to care about
backward compatibility that much. We do need to care that 6tisch can
be implemented with current hardware, so we cannot really extend or
modify it, but we can profile it and say we use it in this way.
-- 
[email-masked]

---

From: Malisa Vucinic <[email-masked]>
Date: Wed, 27 May 2015 01:19:40 -0700

Tero,

Could you see if this sums up our discussion.

Reminder: K1 is used to authenticate BEACON frames (security levels MIC-32, MIC-64, and MIC-128); 
K2 used to authenticate + encrypt DATA (including broadcast), ACK, COMMAND frames (security levels ENC-MIC-32, ENC-MIC-64, and ENC-MIC-128).

Option 1:
K1, KeyIdMode 0b00 (implicit keying)
K2, KeyIdMode 0b01 (Explicit Key Index)

Pros: No extra overhead for K1; Flexible re-keying of K2.
Cons: Difficult re-keying of K1; 1 byte signaling overhead for K2; Limits pairwise keying with KeyIdMode 0b00 in a later stage;

Option 2:
K1, KeyIdMode 0b01 (with 6tisch predefined Key Index)
K2, KeyIdMode 0b01 (Explicit Key Index)

Pros: Flexible re-keying for K1 and K2.
Cons: 1 byte signaling overhead for K1 and K2; Potential collision of the 6tisch predefined Key Index with other networks using KeyIdMode 0b01, which would delay the join process. 

Options 3:
K1, KeyIdMode 0b11 (explicit 8 byte Key Source field with a 6tisch pre-defined address)
K2, KeyIdMode 0b01 (Explicit Key Index)

Pros: Flexible re-keying for K2; Globally unique identification of 6tisch networks with K1.
Cons: 9 byte signaling overhead for K1; 1 byte signaling overhead for K2.

Regards,
Mališa Vučinić

---

From: Robert Cragie <[email-masked]>
Date: Wed, 27 May 2015 11:04:00 +0100

Yet again, this discussion is going round and round in circles.

EB protection
=============

Regarding protection of the EB, I would just like to get a clear statement
on the options and the implications. Here is my stab:

* EB unprotected
    - No need to provision any key.
    - All nodes can read the EB.
    - No nodes can verify the EB.

* EB protected with MIC
    - Shared Key needs to be provisioned for verification purposes.
    - All nodes can read the EB.
    - Nodes which have the shared key can verify the EB.
        + Trust in verification depends on how widely distributed the
shared key is.
        + Gamut from distributed globally to distributed to exactly two
parties.
            * A key distributed globally has no security at all and there
can be no trust in the verification.
                - There is however a minor benefit in an improved error
detection mechanism over the 2 octet CRC.
            * A key distributed to exactly two parties has the highest
security and thus the highest trust in verification, assuming the key
distribution method is implicitly secure.
    - Nodes which do not have the key cannot verify the EB and the EB must
be treated as unprotected.

If there is no security on the EB, at least we have a known starting point
and the question is whether the ability to spoof EBs is such a problem in
itself that some additional protection on the EBs is needed. If network
segregation is the aim, there are other ways to achieve this. Where it
starts to go wrong is the assumption that adding a MIC to the EB in itself
provides additional protection; it doesn't as it depends on how widely the
key is distributed. It has the *potential* to provide additional protection
but only where the scope of key distribution is sufficiently limited to be
able to effectively exclude the attacker from spoofing EBs. Moreover, if
the key distribution mechanism makes it difficult to pre-provision the
shared key, then everything falls back to the EB being unsecured.

The most important point is that protecting the EB with a MIC gives the
*potential* for a node to verify the EB. If the shared key *can* be
effectively distributed and the scope of distribution is strictly limited,
then it *will* be effective protection. Otherwise, it will not be.

802.15.4 security
=================

With regard to all the talk about 802.15.4 security, don't get me started
on the debacle which was 802.15.4-2011. There are so many areas where this
is so messed up it is now very difficult to figure out what makes sense and
what doesn't. I have been involved in implementations happily using what
was specified in 802.15.4-2006 and indeed will not use 802.15.4-2011 as it
is basically flawed in so many places. I sincerely hope this has been
properly cleaned up and sanity has returned to 802.15.4-2015 (2015
presumably). For example, relevant to the discussion, why was Key Source
modified to say it had to be PAN ID || Short Address in the 4 octet case?
What was the thinking going on there?

As for what Mališa alludes to regarding join-specific procedures, there are
indeed cases where this "on the fly" security material configuration does
need to be done. It is highly unlikely that the entire incoming security
procedure would be done in hardware due to the programmability of the
procedure. Even if it were, as Mališa points out, if you assume you cannot
do this "on the fly" configuration, the worse case is that one frame gets
dropped, the security material is configured then the next frame is
accepted.

With regard to the options, those pointed out below will all work.

Robert

On 27 May 2015 at 09:19, Malisa Vucinic <[email-masked]> wrote:

> K2 used to authenticate + encrypt DATA (including broadcast), ACK, COMMAND
> frames (security levels ENC-MIC-32, ENC-MIC-64, and ENC-MIC-128).
>
> Option 1:
> Cons: Difficult re-keying of K1; 1 byte signaling overhead for K2; Limits
> pairwise keying with KeyIdMode 0b00 in a later stage;
>
>
>
> Option 2:
> Cons: 1 byte signaling overhead for K1 and K2; Potential collision of the
> 6tisch predefined Key Index with other networks using KeyIdMode 0b01, which
> would delay the join process.
>
>
>
> Options 3:

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 28 May 2015 00:52:17 +0300

> Could you see if this sums up our discussion.

Yes, good summary.

-- 
[email-masked]