Subject: Re: [6tisch] 6tisch join requirements for 6top

From: Tero Kivinen <[email-masked]>
Date: Mon, 1 Dec 2014 15:10:26 +0200

Michael Richardson writes:
>     > Didn't 6LoWPAN add some multiplexer in the beginning of data, or do I
>     > remember wrong? 
> 
> Yes-ish, but it's only a few bits.

And because of that you add 20 extra bytes to beacon packet to solve
that situation.

>     > Note, that receiving peer needs to know the extended address of the
>     > sender in the 15.4 to be able to decrypt the packet, as the nonce
>     > generation depends on that. There is no way around that. 
> 
> When you say "extended address", do you mean 64-bit EUI?

Yes. In 802.15.4 the extended address is the full 64-bit EUI. The
short address is the 16-bit address assigned by the coordinator (and
that short address is associated with PANId). 

The 15.4 uses nonce for the AES-CCM in format of

+------------------------+------------------+--------------------+
| Octets: 8     	 |	 4	    |	    1            |
+------------------------+------------------+--------------------+
| Source Address	 |   Frame Counter  |  Security Level    |
+------------------------+------------------+--------------------+

for non-TSCH mode, and for TSCH mode it uses:

+------------------------+-------------+
| Octets: 8     	 |     5       |
+------------------------+-------------+
| Source Address	 |     ASN     |
+------------------------+-------------+

where the ASN is the absolute slot number. The Source Address is the
64-bit EUI, i.e. extended address of the sender.

The source address is fetched from the KeyDescriptor found using the
Key Identifier Mode, Key Source and Key Index.

So unless you know the extended address of the sender, you cannot
decrypt the packet, as you cannot calculate the Nonce for the AES-CCM
operation. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 1 Dec 2014 15:26:06 +0200

Michael Richardson writes:
> 
> Tero Kivinen <[email-masked]> wrote:
>     >> d) a network-wide "PSK", to be used with 802.15.9 mode IKEv2
>     >> (Shared key message integrity code. ditto about broadcast)
> 
>     > How the broadcast/multicast keys are keyed is not really defined in
>     > the 15.9, but it is left for the upper layer. I.e. 15.4 the keys are
>     > identified with the two attributes, Key Source and Key Index. The
>     > format of the Key Source depends on the Key Identifier Mode value.
>     > There are 4 different values for the Key Identifier Mode:
> 
> So, it's not enough to say "use 15.9" for key derivation, having provided
> locally significant certificates.  

Not really, as it would about the same as say use IPsec for protecting
the IP packets. It does not yet specify how the policy is set up and
which kind of configuration should be used in either ends. In 802.15.4
the problems are just bit lower than in IPsec, i.e. you need to define
what kind of keys you want to create, and how to identify those keys. 

> We also need a way to define a key for multicast operations, and I don't see
> a way to do this other than having the join process provision one.  

Who will own that multicast key, i.e. who decides when it is going to
be rekeyed? Who will give that key out to others? Do everybody have
direct connection to the owner of the key? Are there going to be
multiple senders for that key or just one?

What Key Identifier Mode you are planning to identify the key, what
KeySource and KeyIndex values etc?

You could for example specify that the pan coordinator "owns" the
multicast key, so he will take care of rekying etc, and the Key Source
field of the auxiliary security header specifies him.

For example using Key Identifier Mode 1 (everybody set their
macDefaultKeySource to match the extended address of the pan
coordinator) and specifying that Key Index 0x10-0x1f is used for this
multicast group (this would allow 16 groups so pan coordinator can
create new key, and every time he sees someone using old key, he can
send them new key, and ask them to delete old one).

Then on the actual frames the senders most likely would use full
extended address when sending packet to multicast group as source
address (so even those who do not know the senders short address can
get the packet), and use Key Identifier Mode 1 and the Key Source and
Key Index matching the pan coordinator to indicate they are using
multicast group key owned by pan coordinator.

Or something like that. There are other options available too, and you
need to think which one of those is best suited for your needs.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 01 Dec 2014 11:28:14 -0500

{can I subscribe Tero to the 6tisch-security mailing list?}

    > decrypt the packet, as you cannot calculate the Nonce for the AES-CCM

What I'm reading is that multicasted messages must always use extended
addresses if they are secured.   For other messages, if one has a node to node 
security, then one can map the 16-bit address to an extended address, and
create the nonce.  If one does not have node to node security, then the
receiving node might not have the mapping: does that mean one has to use
extended addressing whenever there is a single, network-wide key?

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 01 Dec 2014 11:35:52 -0500

> the IP packets. 

{for others, one of the failure cases for IETF, circa-y2000, as that
protocols had Security Considerations that said "Use IPsec", without
explaining *how* to use it}

    > It does not yet specify how the policy is set up and

So I am assuming that some of these details would go into the YANG model as
additional fields.  Some, such as what ciphers to use, we might initially
"default" to AES-CCM, assuming that if there an option, it's an upgrade, and
a new YANG model would include the bit to turn it on.

    > multiple senders for that key or just one?

1) There are multiple senders.
2) There is a mesh, and not all nodes have a direct connection to the root.
3) I imagine that the root (6LBR) has to own the key.

    > field of the auxiliary security header specifies him.

I don't think we have a specific pan coordinator in 6tisch.

    > send them new key, and ask them to delete old one).

I'm confused by why we would have to set the macDefaultKeySource to match the
pan coordinator.  Probably, I don't know what that field controls.

It would be nice if the pan coordinator could see all the transmissions, but
that won't be the case; the join coordinator will have to refresh the keys.

    > need to think which one of those is best suited for your needs.

I think that this is the right scenario.

-- 
]               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: Rene Struik <[email-masked]>
Date: Mon, 01 Dec 2014 11:43:53 -0500

Dear colleagues:

Most emails about speculated behavior of the 802.15.4 specification 
could have been avoided by actually reading the spec. So, what about we 
simply do this? What remains after this could then be bait for emails...

Relevant specs: 802.15.4e-2012 and 802.15.4-2011.

Best regards, Rene

On 12/1/2014 11:35 AM, Michael Richardson wrote:
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

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

---

From: <[email-masked]>
Date: Mon, 1 Dec 2014 23:49:35 +0000

There is some weakness if a device does not store a frame counter (i.e., ASN in TSCH) across a reboot.  There can be a replay attack by sending a copy of beacon fame sent in the past, letting the rebooted device to re-use the frame counter (until the device synch up with correct ASN).

Yoshihiro Ohba

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Sunday, November 30, 2014 1:20 AM
To: Kris Pister
Cc: [email-masked]
Subject: Re: [6tisch] 6tisch join requirements for 6top

Tero, all,

As the key is AES-CCM key that means that every single device needs to
store their frame counters to stable storage. This sets quite high
requirements for the devices. In theory they should also store the
frame counters for all the peers they are talking to, but I don't know
if any device does that. Usually they only store their own frame
counter to flash every now and then, and then on the restart they load
it from the flash, and add big enough counter to it to make sure that
it is unique.

IEEE802.15.4e-2012 TSCH [1], the ASN is used as the Frame Counter for security operations, so you don't have to store the frame counters to stable storage, right?

Thomas

[1] http://standards.ieee.org/getieee802/download/802.15.4e-2012.pdf

On Tue, Nov 25, 2014 at 2:51 PM, Kris Pister <[email-masked]<mailto:[email-masked]>> wrote:
No, when someone defines protocol B that is not compatible with protocol A then
they will pick a different well-known key.  That is the whole idea.

ksjp

On 11/25/2014 3:17 AM, Tero Kivinen wrote:
So when someone is running the protocol A and B both over the same
default well-known key then you still have the problem...

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Michael Richardson <[email-masked]>
Date: Mon, 01 Dec 2014 21:47:36 -0500

<[email-masked]> wrote:
    > There is some weakness if a device does not store a frame counter
    > (i.e., ASN in TSCH) across a reboot.  There can be a replay attack by
    > sending a copy of beacon fame sent in the past, letting the rebooted
    > device to re-use the frame counter (until the device synch up with
    > correct ASN). 

First, let's assume that the node has been removed from the network, and is
subject to a malicious beacon frame.  It can never catch up, I guess.  If the
attacker had a record of subsequent (encrypted) frames that were present, the
captured node would decrypt the traffic again.

At this point, if one controls the node sufficiently that one can read ram,
one could read the cleartext; but I would claim that in that case, one
already has the key, and just decrypt the captured traffic directly.

If we are talking about join traffic, it seems that already have the
encryption key, so one doesn't even need the node, or the beacon frame.

Is there another attack?

Now, assuming that we have both malicious and regular transmitters of the 
beacon.  Is there something else one can do?

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 1 Dec 2014 22:58:30 -0800

Yoshi,

There is some weakness if a device does not store a frame counter (i.e.,
> ASN in TSCH) across a reboot.  There can be a replay attack by sending a
> copy of beacon fame sent in the past, letting the rebooted device to re-use
> the frame counter (until the device synch up with correct ASN).

A mote reboot will rejoin the network. The network will have advanced in
time (i.e. the value of the ASN will have increased). When the node
re-joins the network, it will hear the (updated) ASN and start using that.
So a node doesn't need to store the ASN in non-volatile memory, since it
will not reuse the same value after a reboot.

Thomas

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Dec 2014 08:09:15 +0100

On 02 Dec 2014, at 07:58, Thomas Watteyne <[email-masked]> wrote:
> 
> When the node re-joins the network, it will hear the (updated) ASN and start using that.

Unless it actually "re-joins” an attacker.

Grüße, Carsten

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 1 Dec 2014 23:59:53 -0800

Absolutely, and that's why the node needs to authenticate the network.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 2 Dec 2014 12:54:23 +0200

Michael Richardson writes:
> What I'm reading is that multicasted messages must always use
> extended addresses if they are secured. For other messages, if one
> has a node to node security, then one can map the 16-bit address to
> an extended address, and create the nonce. If one does not have node
> to node security, then the receiving node might not have the
> mapping: does that mean one has to use extended addressing whenever
> there is a single, network-wide key?

Not completely true. If the network is set up so that everybody knows
the mapping from short address to extended address then you can also
use short address when sending packet. For example if you have one PAN
coordinator and everybody knows it because they associate to it first,
then you can use the PAN coordinators short address (or just set the
addressing mode to NONE, in which case no address information is sent
in the packet, and everybody assumes it was sent by the coordinator,
and as they know the coordinators short or extended address, they can
use that to map to the extended address of the sender (i.e.
coordinator in this case)).

All this different addressing models are quite complicated in the
15.4, and there are lots of different ways of doing this. If I have
understood correctly, then most of the networks just use subset of the
options, i.e. they decide that for example coordinator always uses
NONE addressing mode (except for beacons), and everybody knows the
extended address of the coordinator, so there is no need to send it in
frames when sending frames to or from coordinator.

Similarly instead of using the extended address of the owner of the
multicast key, they can also allocate one PAN Id and short address for
the owner. Then the coordinator just needs to be sure that it never
gives that short address to anybody, and the owner of the multicast
key needs to know he is the owner.

So there is lots of different options, and depending on the features
you want you can pick some of the options and use them. So firstly you
need to decide what features you want to have. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 2 Dec 2014 13:16:56 +0200

> a new YANG model would include the bit to turn it on.

In 15.4 there is only one cipher, i.e. AES-CCM*. There is 7 security
levels for it, but they just affect whether the payload is encrypted
and how long MIC (message integrity code) is added to the frame.

> 1) There are multiple senders.

Is there going to be multiple multicast keys also, or just one network
wide broadcast key. Do we need to support rekeying of the key, i.e. do
we want to exclude someone from the group and distribute the key only
to those we should be part of the new group. 

> 2) There is a mesh, and not all nodes have a direct connection to the root.

How is the mesh forwarding be done. Or is there any mesh forwarding,
i.e. can node X send frame to node Y, which is not in direct
communication range? If so how will it get forwarded. Is the
forwarding done on the upper layer, or so? When node X is sending
frame to node Y, does it uses node Y's address on the frame when
sending the frame out or what? 

> 3) I imagine that the root (6LBR) has to own the key.

With key you mean here what? Public key to authenticate the root, or
multicast key, or what?

> I don't think we have a specific pan coordinator in 6tisch.

Each 15.4 network has one PAN coordinator and can have multiple
coordinators. The first node creating the network will work as PAN
coordinator for the network.

I.e. if you have two 15.4 devices talking to each other, one of them
must be fully functional device (FFD) and act as PAN coordinator and
other one connects to it.

The PAN coordinator it the device who assigns the short addresses for
the devices, if you want to use them. 

> I'm confused by why we would have to set the macDefaultKeySource to
> match the pan coordinator. Probably, I don't know what that field
> controls.

The macDefaultKeySource is used instead of the KeySource in the frame,
when Key Identifier Mode 1 is used. I.e. it is used to compress the
KeySource field in the frame. Many setups use star topology and in
that case all communication is between the leaf node and the PAN
coordinator. When the device associates with the network it will know
the extended address of the PAN coordinator and then it can configure
macDefaultKeySource with that address. After that the PAN coordinator
can send packets out by simply omitting the whole source address field
(i.e. using source address mode of NONE, which means the whole source
address fields are left out), and it can also use Key Indentifier Mode
1 which means the KeySource field in the auxiliary security header is
just one byte of Key Index. The recipient will then know from these
that this frame is from PAN coordinator, and as they know the extended
address of the PAN coordinator, and it is configure in the
macDefaultKeySource PIB for them, then they process the frames.

On the other direction when sending packet to the PAN coordinator,
they can leave the destination address away (i.e. packet goes to PAN
coordinator), and they can use the same group key own by the PAN
coordinator (i.e Key Identifier Mode 1), and then they just include
their own extended address or short address in the source addressing
fields of the header.

So most of these complications in the 15.4 are because of saving bits
on the air... 

> that won't be the case; the join coordinator will have to refresh the keys.

So I assume your setup is that you have multiple coordinators, which
send out beacons and each device associates with one of those
coordinators, and the coordinators then talk the PAN coordinator using
some mechanism outside the scope of 15.4 to do the short address
assignment and group key management. 
-- 
[email-masked]

---

From: <[email-masked]>
Date: Tue, 2 Dec 2014 13:51:00 +0000

I don't assume that an attacker has sufficient control of the rebooted node.  If the rebooted node re-uses old frame counter values for the same key and send encrypted traffic, then it gives hints to the attacker about the encryption key, that is where weakness comes.

I think re-joining requires authentication (as Thomas mentioned) in which protected frame counter synchronization is performed, and that re-joining authentication should not be protected by MAC layer to avoid possible re-use of frame counter.

Yoshihiro Ohba

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, December 2, 2014 11:48 AM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [6tisch] 6tisch join requirements for 6top

    > device to re-use the frame counter (until the device synch up with

First, let's assume that the node has been removed from the network, and is subject to a malicious beacon frame.  It can never catch up, I guess.  If the attacker had a record of subsequent (encrypted) frames that were present, the captured node would decrypt the traffic again.

At this point, if one controls the node sufficiently that one can read ram, one could read the cleartext; but I would claim that in that case, one already has the key, and just decrypt the captured traffic directly.

If we are talking about join traffic, it seems that already have the encryption key, so one doesn't even need the node, or the beacon frame.

Is there another attack?

Now, assuming that we have both malicious and regular transmitters of the beacon.  Is there something else one can do?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Dec 2014 09:00:28 -0500

> Unless it actually "re-joins” an attacker.

So, we are talking about the *join* network not the production network here.
(Nodes that joined the production network would have production keys, and 
would only listen to beacons from other nodes on the "inside".)

Nodes that reboot having not yet joined the production network could very
well join an attacker's network.  This is understood regardless of using a
well known beacon key.  A node which is still in "join stage" might want to
be promiscuous about listening to beacons, and accepting ones with lower
ASN. There is definitely a heuristic here, and it is definitely possible for
a determined attacker who is proximate to the joining node to continuously
DoS the join process.

This conversation started with the assertions that using a well known beacon
key was either impossible, or required too many resources on the part of some
node (unclear to me be if join assistant or join node).

We discussed in some of the design team calls that a node that went through
the join process and discovered that "this wasn't the network it was looking
for" (as a result of failure to authenticate the JCE at the DTLS part of the
6top setup), would have to remember the extended address and/or PANID of the
networks tried so far, and try another one.  I don't think that this
discussion adequatedly made it into draft-richardson-6tisch-security-6top.

---

From: [email-masked]
Date: Wed, 3 Dec 2014 20:45:08 +0800 (GMT+08:00)

I just joined the group so do not have much confidence to offer anything. Could we check if WirelessHART or ISA100.11a faces the same problems and if they have resolved them? If so, could we adopt? Or maybe they are not relatable here?

> -----原始邮件-----
> 发件人: "Michael Richardson" <[email-masked]>
> 发送时间: 2014-12-02 22:00:28 (星期二)
> 收件人: "Carsten Bormann" <[email-masked]>
> 抄送: "Thomas Watteyne" <[email-masked]>, "Kris Pister" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> 主题: Re: [6tisch] 6tisch join requirements for 6top
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Dec 2014 12:53:28 -0500

[email-masked] wrote:
    > I just joined the group so do not have much confidence to offer
    > anything. Could we check if WirelessHART or ISA100.11a faces the same
    > problems and if they have resolved them? If so, could we adopt? Or
    > maybe they are not relatable here?

WirelessHART uses an installation specific key for the join network, which is
provisioned my the VAR/manufacturer. So it's one-touch, rather than
zero-touch, but may seem zero-touch to the installer.  The way which the
network security is configured via the application protocol has been
replicated.

I do not know if WirelessHART has one or two beacons.

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 19 Dec 2014 12:06:15 +0100

There is only a single type of beacon in WirelessHART