Subject: Re: [6tisch] EBs are only used in joining, not normal operation (Re: a little puzzle)

From: Tero Kivinen <[email-masked]>
Date: Mon, 4 May 2015 15:57:22 +0300

Kris Pister writes:
>  >> I think that the confusion here is in thinking that EBs are involved
>  >> in normal network operation.  They are not.
> 
>  > I have understood that draft-ietf-6tisch-minimal plans to use them
>  > also in normal operation.
> 
> The text in minimal-06 reads
> "EBs should not in general be used for synchronization."
> 
> In -07 we should certainly change that to caps. I'm guessing that
> Tero would argue that it should be MUST NOT instead of SHOULD NOT. I
> would agree.

Actually no. I think EBs are actually very good and cheap way to keep
up in sync in network. The only thing required from them in that case
is that they have real key protecting them (i.e. no well-known keys).

The current minimal already says you can use pre-configured keys, or
key management protocols to create keys, so for those use cases the
EBs can use real keys, and in that case you can use them for
syncronization. 

Only problem with using EBs in time syncronization comes when someone
uses unsecured EBs or EBs "protected" using well-known keys. 

> I note that draft-ietf-6tisch-tsch-06 generally describes this
> process well, but does include one sentence which should be removed:
> "Nodes can keep synchronization exclusively by exchanging EBs." This
> either needs to be explicitly not allowed, or Charlie has to go back
> to square one.

In some networks using EBs is completely valid option.
-- 
[email-masked]

---

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

> is that they have real key protecting them (i.e. no well-known keys).

Now this *is* a real mistake, and provides a false sense of security.
If multiple vendors need to ship products that have a secret key in
firmware, that key will not remain secret for long.  If you depend on
it for security, that's a false sense of security.
If the key is generated randomly for each network, that's fine, but
then how do the new nodes join?  Either they get programmed with
the randomly generated key for the particular network that they want
to join (which is not an acceptable solution to most end users) or
they don't rely on a secret key during the joining phase.  Once through
the joining phase they get one or more L2 keys that are random and
secret for that network.  If you want to beacon with that key to maintain
sync, fine.  But don't think that your global EB PSK is going to remain
secret - it won't.

ksjp

---

From: "Timothy J. Salo" <[email-masked]>
Date: Mon, 04 May 2015 16:52:22 -0500

> ... If the key is generated randomly for each network, that's fine, but
> to join

OK, ...

> (which is not an acceptable solution to most end users)  ...

Why don't users find this acceptable?

It seems to me that vendors ought to provide tools that make this
configuration process painless.  Is the problems that vendors aren't
delivering tools that make this configuration simple and painless?
Or, do customers not want to have incoming products flow through a
common point or process?

It seems to me that some level of technical competence is necessary to
install or even replace these nodes, and that this level of technical
of competence ought to be adequate to pre-configure nodes (assuming
that adequate tools are available).  Of course, if these tools could
be used by field technicians, then incoming nodes wouldn't have to
flow through a common location or process.

Alternatively, this pre-configuration seems to be something that
vendors ought to provide, (as a service).  (Presumably, this would
stimulate the development of tools that would make the configuration
process simple and painless.)  Of course, it's not clear whether
distributors would want to provide this process.

Is there any technical reason that simple, reliable, end-user
configuration tools couldn't be developed that pre-configure
network-specific keys?

-tjs

---

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

> configuration tools couldn't be developed that pre-configure
Probably not, if the mechanism for doing such configuration (AKA 
provisioning) is standardized and made mandatory, so that such tooling 
is ubiquitous and ALWAYS works. For example, an LED is a poor 
photo-transistor, so hooking it up as a 3-terminal device could provide 
a way to get an optical signal into the device that is being provisioned 
for the network without adding any extra hardware to most devices. (Note 
that there is a patent on this specific reverse-LED-as-a-photodiode 
approach, by Matsushita if I recall correctly.) Privacy during the 
injection process can be achieved via a fiber-optic cable with boots on 
the ends, or by doing the provisioning in a closed windowless room. Any 
decent modern cellphone will likely be programmable enough to provide 
the requisite optical signaling.

That would be all well and good for an industry standard, such as 
WirelessHART (which itself mandates a different secure way to do that 
initial provisioning). But it's unlikely to be acceptable for something 
that purports to be a communication standard, since mandating a specific 
type of auxiliary provisioning channel is unlikely to be acceptable to 
the wider community.

-Tom
=====
On 2015.05.04 14:52, Timothy J. Salo wrote:
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

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

> it for security, that's a false sense of security.

Yes, thats why I am against well-known keys.

Keys in RFC == well-known keys.

Keys in firmware == well-known keys.

Pre-configured keys == keys configured during the deployment or
installation process to the devices using some out of band method.

Keys shared among peers == pairwise keys configured during the
deployment, or installation process to the devices using some out of
band method. Or they can also be created during the initial
bootstrapping process, i.e. when the device is first booted up, it
might create pairwise key with some entity in the network, store that
in stable storage and use that from that on.

Keys generated using KMP == keys created during the bootstrap
procedure using KMP. Those keys can either be network wide keys (K1,
K2) or they can be peerwise keys. 

> then how do the new nodes join?

What is the problem with joining?

The K1 is used to integrity protect the EB. The joining node is able
to parse EB even when it does not have the key, and can extract the
information need for joining from there.

The joining node will contact to the joining coordinator entity with
security level 0, i.e. no encryption, no mic, and JCE will do the
authentication and authorization of the JN using methods we are
talking here.

One of those methods could be that the JN uses 802.15.9 with suitable
KMP and created pairwise key between JN and JCE. This key is used for
the rest of the process.

As the security of well-known K1 == no security, it does not matter
whether the JN uses no security or whether it uses well-known K1.

> Either they get programmed with the randomly generated key for the
> particular network that they want to join (which is not an
> acceptable solution to most end users) or they don't rely on a
> secret key during the joining phase.

This is no different with well-know K1. With well-known K1 the JN do
not rely on secret key during the joining process. The joining process
needs to be such process that it works without relying on the security
of K1. 

> Once through the joining phase they get one or more L2 keys that are
> random and secret for that network.

Yes.

> If you want to beacon with that key to maintain sync, fine. But
> don't think that your global EB PSK is going to remain secret - it
> won't.

Depends what you mean by global EB PSK. If you mean randomly generated
K1 which is rekeyed every now and then, and distributed only to the
authenticated members of the network, then it will stay secret, unless
you have attackers inside your network. If they are part of your
network, then any network wide keys is unsafe.

I myself think that network wide keys are bad idea, but for EBs they
work well enough. For all other traffic you should use pairwise
keys... 
-- 
[email-masked]

---

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

> type of auxiliary provisioning channel is unlikely to be acceptable to 

Most commonly devices currently either automatically trust the first
network they connect to, and can receive initial configuration from
that network.

For example lots of wifi devices will create their own wifi-network
for configuration. I.e. you connect to this "config" network take http
connection to some ip-number in there, and then you get web page where
you can config the device. During that process you install admin key
and provide other network setup information. All this is stored on the
stable storage and after that the device boots up normally using the
stored network setup.

If you need to do that again (reprovision) you press some button or
something during the bootup and it will reset all configuration.

Another setup is that devices just boot up and join the first network
they can see, and then you can for example use some application in
your phone, which will search those devices from the network and allow
you to do the initial configuration for them.

Or the devices might come with a code that you use to log in the
vendors cloud service, and install the configuration there, and then
when the device boots up it always connects to that cloud service to
download the configuration.

The problem with wifi setups is that before you can do the last two
ways of configuration you need to get credentials for the network,
i.e. you need the wifi network key before you can connect to the net,
which is why the first setup might be there in addition to the last
two...

For IoT in home environments I would think the best option would be to
have raw public key on the device, and during the initial bootup the
device joins whoever is there, and tries to download configuration
from some server from there. During this process it authenticates
himself with that raw public key, and the server can then either
accept it directly or it can match it against the list of raw public
key fingerprints configured to it (i.e. they might have been printed
to the side of device in QR code, or they might be distributed using
email or some other electronic method).

During this initial provisioning the device cannot authenticate the
network, but network can authenticate the device. Once the initial
provisioning is done, the device stores the network authentication
information to the stable storage (for example the fingerprint of the
JCE) and after that for later bootstratps it can authenticate the
network too. 
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 May 2015 09:42:35 -0400

> delivering tools that make this configuration simple and painless?

Customers do not want to touch the devices with any tools.
That's the whole point of having an online enrollment or imprinting process.

If you can skip the joining process, then you don't need EBs at all.

--
]               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: Kris Pister <[email-masked]>
Date: Tue, 05 May 2015 09:16:46 -0700

> Customers do not want to touch the devices with any tools.

Indeed.  We had one customer who said flat out "the only tools that my 
installers
know how to use are a sledge hammer and a blowtorch."
We brainstormed ideas about having shock or temperature sensors in the 
devices
to initiate pairing:
1) install sensors and gateway
2) apply blowtorch to gateway and sensors within 10 seconds of each 
other to effect
security exchange and network binding

ksjp

---

From: Robert Cragie <[email-masked]>
Date: Tue, 05 May 2015 17:55:35 +0100

Hi Tero,

It is important to distinguish:

1) Authentication and authorization for network access
2) Authentication and authorization for application

The two often get mixed up and they shouldn't be.

More comments inline.

Robert

> network they connect to, and can receive initial configuration from
<RCC>
Initial configuration for what?

1) Operating correctly as a member of the network?
2) Operating as a functional device?

It is likely to get both but again they are quite distinct and the 
configuration data in each case may come from entirely difference 
sources. In the case of (1) it is likely to come from an authoritative 
device in the network sense (e.g. access point). In the case of (2), it 
could be from a cloud server.</RCC>
> stable storage and after that the device boots up normally using the
<RCC>You have to look at this as two separate networks where the first 
network is an out-of-band mechanism to pre-provision information for the 
second network. In this case, it is the first network we concentrate on 
wrt. in-band mechanisms for authentication and authorization</RCC>
> you to do the initial configuration for them.
<RCC>That isn't going to work unless any network in the vicinity somehow 
provides "guest" connectivity to a device which can configure it for the 
right network somehow. Not impossible but quite a complex commissioning 
model. Otherwise your phone must also be able to guest on the network 
the device has just joined. Then it has to find that network etc. etc. 
Then there is a second stage of jumping on to the right network.</RCC>
> download the configuration.
<RCC>This is likely application auth/authz as this doesn't really make 
sense for local network configuration unless we are talking about a AAA 
model.</RCC>
> which is why the first setup might be there in addition to the last
<RCC>Which comes back to distinguishing the two cases clearly.</RCC>
> email or some other electronic method).
<RCC>Are we talking auth/authz for network access or application here?</RCC>
> network, but network can authenticate the device.
<RCC>Probably only in a AAA model. A RPK (or self-signed cert.) cannot 
be implicitly trusted so it would have to be checked against a whitelist 
on a trusted server</RCC>
> Once the initial

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 May 2015 14:56:41 +0300

> 2) Authentication and authorization for application

Yep.

> The two often get mixed up and they shouldn't be.

On the other hand when you have IoT devices who create dedicated radio
network between them, which is only used by them, then those things
can also be same thing.

I.e. if you have temperature sensor talking to the temperature control
device, and those two devices are only one on the network, then the
fact that you are part of the network (i.e. network access
authentication and authorization) also provides application
authentication and authorization.

If you have general purpose network (6lowpan or wifi) then this is not
true. 

> could be from a cloud server.</RCC>

Yep. For here I have mostly been talking about the network access
configuration, but in some devices those configurations might be
combined. I do not think there is need to complicate things here with
the functional device configuration stuff. That is application level
settings, and we are specifying stuff that is way below that level.

> wrt. in-band mechanisms for authentication and authorization</RCC>

Yes. In this example the first network is out-of-band mechanism, and
should be outside the scope of drafts we specify here. It is one of
the methods to provide the initial netowkr access configuration to
devices. The security of that network might be provided by physical
means, i.e devices put in to the faraday cage, or the powerlevel of
network turned down to minimal level so that devices must be next to
each other.

So I disagree with you. I do not think we should concentrate on this
first network. I think it should stay outside the scope. We should
concentrate what happens after that, i.e. after the initial network
access information is already provided.

During this initial network access information provisioning phase, the
device might for example get its unique public/private key pair, or
certificate, or unique shared key used for the future authentication
steps. It might not get the K1 or K2 for the network, i.e. those might
still be generated / exchanged during the bootstrap phase while using
the authentication information given in that earlier step. 

> Then there is a second stage of jumping on to the right network.</RCC>

If you want to have new devices joining the network, you do need some
level of "guest" connectivity. How much these guests can do is
completely different thing. At minimal they should be able to talk to
the JCE so they cam authenticate and authorize themselves, and join
the network. The network might also provide more "guest" access.

This is very common in wifi networks. For example before you are able
to go to the initial login page for the network, you need to be able
to do certain things. For example you need to be able to send/receive
dhcp messages, you might need to have limited dns access. If the login
page is protected by the https, then you might need OCSP access etc.
This is something the network adminstrator needs to set up.

Anyways, I think we should concentrate on the network access
configuration case.
-- 
[email-masked]

---

From: Rene Struik <[email-masked]>
Date: Fri, 08 May 2015 10:02:05 -0400

Hi Kris:

I have trouble following the security discussion (which seems all over 
the place and largely a repeat of the 6tisch security mailing list 
discussion end of 2014). However, I do remember that you referred in one 
of your emails to w/HART and suggested that its security had been 
carefully reviewed by external experts. It would be great if this review 
would be available to the community at large. If this cannot be shared, 
I am willing to sign an NDA and review this under those terms. 
Admittedly, the latter does not directly help this group (since it would 
be a behind-closed-doors view)...

Best regards, Rene

On 4/24/2015 9:47 AM, Rene Struik wrote:
> Dear colleagues:
>
> Yesterday late, I returned from a 2-week trip, so did not have the 
> chance yet to go over all emails accumulated over that time. I hope to 
> catch up on 6tisch matters in the next few days.
>
> I did notice lots of emails surrounding 802.15.4 security (or 
> perceptions thereof), but I do not entirely understand the background 
> of these emails.
>
> Since some emails seem to repeat similar discussions in December 2014 
> (including confusions and misconceptions of 802.15.4 security), I 
> would like to encourage everyone to read the draft
> draft-struik-6tisch-security-architectural-considerations-01 (posted 
> January 9, 2015). I wrote this draft partially in the hope that we 
> would not have the very repeat of arguments we now seem to witness. 
> So, I highly recommended reading that 3 1/2 months old draft and only 
> bring up topics not already dealt with there.
>
> Best regards,
>
> Rene
>
> On 4/24/2015 8:24 AM, Tero Kivinen wrote:
>> Kristofer PISTER writes:
>>> Charlie is excited to hear more about option 4! :)
>>>
>>>> Use MICs on EBs, with a secret key distributed during the joining
>>>> process, and add vendor specific IE to identify the network.
>>> This seems like a chicken and egg problem.  In order to get the
>>> secret key for the EBs, you need to go through the joining
>>> process...which starts with receiving an EB...
>> Yes, and the problem is what?
>>
>> The EBs are MICed, but encrypted, which means that the device can
>> receive them and parse them.
>>
>> During the active or passive scan when the device receives the secured
>> EB they will try to unsecure them, but even if they cannot, they will
>> store information from the EB, and they can still join the network:
>>
>> >From 802.15.4-2011:
>>
>> 5.1.2.1.2 Active and passive channel scan
>>
>> ...
>>     The information from the unsecured frame shall be recorded in
>>     the PAN descriptor even if the status from the unsecuring
>>     process indicated an error
>> ...
>>
>>
>> Only difference in the 802.15.4rev-DF5 is that it talks about the
>> "frame to be unsecured" instead of "usecured frame", as the security
>> processing will not set the "unsecured frame" if the security
>> processing failed. The "frame to be unsecured" is the input to the
>> security processing.
>>
>> also in normal operation. I.e. if you do not want to have any
>> dedicated timeslots, and only want to keep track of the network, just
>> in case someone wants to talk to you, you listen the EBs and thats it.
>>
>> Perhaps I am mistaken.
>>
>>> EBs are just used during joining, to get a new mote aware of the
>>> existence of a network, so that it can go through the joining
>>> process, and receive the secret keys that are used in normal network
>>> operation.
>> Thats one use of them. They are also needed when you need to rejoin
>> the network to know the ASN. And also during the normal operation they
>> are used to keep track of time, i.e. if you are using frame-based time
>> synchronization you can sync your time when you receive EBs from your
>> time parent.
>>
>>> Having Mallory forge EBs does NOT mess up the existing network.
>> It will if he for example creates PAN ID conflit. On the other hand
>> currently he can do that even when he does not have proper keys, so
>> here protecting EBs will not help.
>>
>>> No mote which has joined the network is listening to EBs.
>>> EBs are not used in synchronization of motes that are already in the
>>> network, or anything else.  EBs are just used to initiate the join
>>> process, and nothing more.
>> Which parts of the 802.15.4 specification is saying that? I have not
>> found any text claiming EBs in TSCH to be limited for only that.
>>
>>> Once motes are joined to a network, they use a randomly generated
>>> secret key (s) K2.  They do not use EBs for anything.
>> That will limit TSCH networks to be very small networks. I.e. you
>> cannot have network with tens of thousands mostly listen only sleeping
>> sensor nodes in slow polling mode.
>>
>> Networks with more than 65534 nodes is completely out of question as
>> to be able to allocate schedule you need to have short address, and
>> there is only 65k of those.
>
>

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