Subject: [6tisch] 802.15.4 "change" that will affect 6TiSCH.

From: Tero Kivinen <[email-masked]>
Date: Fri, 3 Apr 2015 01:36:38 +0300

While I was doing the latest recirculation ballot for 802.15.4rev, I
noticed something that can affect 6tisch, my comment and proposed
resolution is:

My Comment:

	The TSCH pan formation should include not explaining that
	beacons can be secured, but if they are encrypted new devices
	cannot see the IEs and cannot join the network at all.

Proposed Change:

	Add note: “TSCH beacons cannot be encrypted, they can only be
	authenticated. This is because if the beacons are encrypted,
	then the TSCH Synchronization IE used to transmit ASN to
	joining devices will be encrypted. The joining (or devices who
	has lost synchronization with network) need to know the ASN
	before they can decrypt the beacon frame, thus they cannot
	decrypt the beacons and cannot join the network using
	encrypted beacons..”

I.e. this will affect the question whether the beacons can be
encrypted with default key, which was one of the suggestions for the
6tisch drafts.

This is something that is unchanged since 802.15.4-2011 and
802.15.4e-2012, i.e. the TSCH ASN has been carried in the Payload IEs,
and Payload IEs are encrypted if security level >= 4. And to be able
to decrypt the payload, you need to know ASN, which you cannot see as
it is in encrypted part...

The reason for this email is that people pointed me that there has
been discussion about what changes there has been in the revision that
would affect 6tisch and this is the latest one I found (just adding
text stating the fact that has been true already before).

There is also changes that might affect implementations, and those
changes are fixing security issues:

	* Disallow short addresses in Nonce generation
	
	* Removal of encrypt only mode (this caused easy way to attack
	  TSCH mode, i.e. attacker could pick any encrypted and
	  authenticated frame from the air, remove the MIC, change the
	  security level in header to be encrypt only, then modify the
	  packet at will, and then send it to final destination, which
	  would then decrypt and receive the frame without noticing
	  anything, this was not problem for non-TSCH mode, as
	  security level was used to generate Nonce).

	* Adding ability to filter whether MAC acts on information
          elements. The 802.15.4e didn't add any method of saying
          whether we should process information elements we receive in
          the frame. I.e. the implicit default was that they were all
          processed by MAC.

	* Fixes in the inbound security processing to clearly allow
          unsecured and secured frames to be processed at the same
          time.

	* Fixes in the inbound and outbound security processing for
          TSCH saying that we do not keep normal 32-bit FrameCounter
          when using TSCH mode, 802.15.4e didn't modify anything in
          inbound or outbound security porcedures, meaning that
          outbound processing rules still kept incrementing 32-bit
          macFrameCounter for each outgoinf frame, and stopping at
          counter error when it reached max value, even when it is not
          used at all in TSCH mode. Also in the inbound rules it did
          still got the frame counter from frame (not there in TSCH)
          and compared it against previous value etc...

	* Defined how new frames added in 802.15.4e are actually
          encrypted and MACed, the 802.15.4e did not modify the table
          53 listing private and open payloads, thus it was not clear
          how those are encrypted etc.

	* Changed the MAC command identifier to be encrypted for frame
          versions 0b10. MAC command fames with Frame versions 0b10
          can have payload IEs, and those are encrypted. The MAC
          command identifier is after Payload IEs, and it would be in
          clear, then the device would need to first n-bytes of the
          frame (n is unknown, before the frame is decrypted, because
          payload IEs have termination IE at the end), then get next
          byte as is, i.e. without decrypting it, and then decrypt
          rest of the frame. When polled from the 4e implementors they
          said they do nto do that, but they will encrypt and decrypt
          the MAC command identifier too for frame version 0b10. This
          also caused changes to the inbound state machine as now we
          cannot run filters based on the MAC command identifier for
          MAC command frames before we decrypt the frame.

	* Most likely still something more that I have forgotten...
          And of course some changes which do not affect TSCH, or
          which do not affect old devices (like adding new
          secFrameCounterPerKey property for key).

Ps. I have been too busy to really follow the 6tisch mailing list, but
perhaps I need to find time to do it. I did read the "removing the 'e'
thread" in the archives, and I think the correct thing would be to
refer to the 802.15.4 without any year or specific list of amendments. 
-- 
[email-masked]

---

From: Kristofer PISTER <[email-masked]>
Date: Fri, 3 Apr 2015 13:37:48 -0700

Great summary Tero, thank you.
Can you say more about the reasoning behind "Disallow short addresses in
Nonce generation" ?

ksjp

On Thu, Apr 2, 2015 at 3:36 PM, Tero Kivinen <[email-masked]> wrote:

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

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 4 Apr 2015 04:34:17 +0300

Kristofer PISTER writes:
> Can you say more about the reasoning behind "Disallow short
> addresses in Nonce generation" ?

Short addresses are not defined to be unique. The 802.15.4 says that
how short addresses are chosen is outside the scope of this standard.

I.e. it is completely valid for PAN coordinator to allocate duplicate
short addresses for different devices, if it feels things will still
work. I.e. if they are for example in such schedule that their
neighbors will know which one is which. Also PAN coordinator can
allocate duplicate short addresses to devices which are so far away
from each other that they cannot hear each other (or their neighbors).

In practice the PAN coordinator will not allocate duplicate short
addresses for the same PAN, but for example some other networks might
do that, for example when they derive short addresses from somewhere
else like from IP-address...

Also even if short addresses are unique within the PAN, they most
likely will not be unique across different PANs.

If you have cluster tree network like in figure figure 2 in
802.15.4-2011 you notice that there is multiple devices having same
short address in different PANs. The whole cluster tree network might
still use same TSCH schedule system and coordinated ASN and the same
keys, so different PAN coordinators for different clusters can talk to
neighbor clusters.

As the 7.3.2 of the 802.15.4e-2012 did not use PAN id along with short
address in the Source Address field, this could cause duplicate nonces
(i.e. two devices from different PANs using same short address sends
message using same ASN (on same channel on shared slot, or on
different channels). This means nonce is no longer unique, and that
will break the security.

There are much bigger problems if ASN is not used, i.e. when using
non-TSCH mode, and where normal frame counter is used. In that case
every single device starting with frame counter 0, and getting some
short address that has already ben used in the network will cause
nonce collision.

Also the 7.3.2 does not specify how the 16-bit short address is put in
to the Source Address field. One could assume source address is string
and put the short address as first 2 bytes of the source address, but
what values to put to rest of the source address field. They must be
same in both sender and receiver. Most likely it should be filled with
zeroes. On the other hand the macShortAddress is integer, so it cannot
be stored in the string directly wihtout endness problems (extended
address is string and it can be stored there without problems).

Section 7.3.1 defines integer representation format for the section
7.3, and it says that format of B.2 is used, and B.2.2 says integers
shall be represented as octect strings in most-significat-octet-first.
This means that if we encode short address 0x1234 as 16-bit integer,
and pad with zeros we get nonce value of

	12 34 00 00 00 00 00 00

On the other if we assume that source address field is 64-bit integer,
and we just store the 16-bit integer there then value will be:

	00 00 00 00 00 00 12 34

On the other hand if implementation uses the same format that was used
when sending the Source Address in MAC, then the value would be:

	34 12 00 00 00 00 00 00

So the text in 7.3.2 is unclear which format should be used, thus
causing interoperability issues.

Note, that all complient 802.15.4 devices must know the mapping from
the short address to extended address, so there is no reason why the
device cannot use the extended address in nonce. The security section
table 64 (of 802.15.4-2011) describing elements of the
DeviceDescriptor contains the mapping from short address to extended
address. Short address is optional in the DeviceDescriptor, but
extebded address is not optional, it must be there, and it is used in
incoming frame security procedure in 7.2.3.

So there is no reason to use short addresses in the nonce generation,
as it just causes security issues, and complient 802.15.4 devices must
already know the extended addresses of their neighbors so there is no
point of not using it. Frame addressing fields can of course use short
addresses, and extended address is only used internally in the nonce
generation regardless what was in the addressing fields, so there is
no expansion of the frame size when using extended addresses in the
nonce generation.

If you have network where the receiver do not know the mapping from
the short address to extended address for the sender when receiving
secured frame, then that is not complient with 802.15.4, and 6tisch do
not need to care about it...
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 4 Apr 2015 05:24:12 +0300

> how short addresses are chosen is outside the scope of this standard.
...
> and pad with zeros we get nonce value of

Of course forgot one big collision case too. I.e. if there is anybody
in the network having extended address of 12:34:00:00:00:00 (or
00:00:00:00:12:34 depending on how the short addresses are encoded in
source address field), this will also cause nonce collisions for short
address of 0x1234 when they send at the same time (i.e. use same ASN).

There would have also be ways to try to fix these issues in other
ways, by requiring that PAN coordinators must enforce that short
addresses are unique at all times, and that they must not allocate
short addresses for devices where they might overlap extended
addresses, and if node with extended address that might overlap with
some short address join the network, the device with that short
address must immediately be disassicated from the network, and of
course specify the encoding for the short address, and most likely
also add the PAN id to be used in combination with short address in
nonce generation etc. Even then the short addresses could only be used
when ASN is used, there is no way to use them securely when ASN is not
used.

All of this would have caused much bigger non-interoperable changes to
the implementations, and made the PAN coordinators work much harder,
so just removing the short addresses in the nonce generation was much
easier change, and most likely will cause much less actual changes in
implementations (== do the same you already do when not using TSCH
i.e. use the ExtAddress in DeviceDescriptor when calculating nonce).
-- 
[email-masked]

---

From: Kris Pister <[email-masked]>
Date: Tue, 07 Apr 2015 18:02:26 -0700

Tero - thanks for the detailed email.  Without getting caught up in the 
specific technical
details, let me see if you agree with this summary.
The IEEE makes very flexible standards.  This enables multiple different 
systems
standards (e.g. WirelessHART, ISA100, Zigbee-xyz, thread) to be built on 
a single IEEE standard
(e.g. 802.15.4-2006), and use it in very different, but still compliant, 
ways.

In particular, 15.4 might provide two knobs A and B with a wide range of 
settings.
A system standard might, after careful analysis, specify those knobs to 
be set
at values A1 and B1.

You have uncovered some combinations of security settings, A2 and B2, which
are not secure.  Your solution is to propose that we remove the knobs to 
prevent
people from setting them in insecure positions.
However, if A1 and B1 are not insecure, if in fact A1 and B1 have been 
reviewed by security
experts from integrators and end users and academia, then you can 
imagine that
people who have been shipping products set to A1 and B1 for almost a decade
will object to the proposed changes.  That's not specifically a concern 
for 6tisch, but
if A1 and B1 are both efficient and known to work, then it is 
potentially a concern for
6tisch.
If I follow your email below, it seems that you might be willing to 
consider short addresses
in nonces if certain things are explicitly specified (e.g. nonce 
construction), and certain
things are restricted (e.g. two nodes in the same network with the same 
short
address).  Is that correct?

ksjp

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 10 Apr 2015 15:27:43 +0300

Kris Pister writes:
> Tero - thanks for the detailed email. Without getting caught up in
> the specific technical details, let me see if you agree with this
> summary. The IEEE makes very flexible standards. This enables
> multiple different systems standards (e.g. WirelessHART, ISA100,
> Zigbee-xyz, thread) to be built on a single IEEE standard (e.g.
> 802.15.4-2006), and use it in very different, but still compliant,
> ways.

As someone described the 802.15.4 for me, it is toolbox containing all
kind of tools, and when you create a 802.15.4 network you pick the
tools suitable for you and use them. Which means most of the 802.15.4
networks do not talk to each other, as they selected different set of
tools (i.e. one picked TSCH another one picked something else).

> In particular, 15.4 might provide two knobs A and B with a wide
> range of settings. A system standard might, after careful analysis,
> specify those knobs to be set at values A1 and B1.
>
> You have uncovered some combinations of security settings, A2 and
> B2, which are not secure.

I have found out that setting A1 (short addresses in nonce) is
impossible to make secure when using with B2 (not using ASN in nonce
generation), and almost impossible when using B1 (when using ASN), and
thats why I think setting A1 needs to be removed, specially as using
option A2 (using extended address in nonce) does not cause any
problems, i.e. packet sizes stay exactly same, it does not consumer
more resources etc.

> Your solution is to propose that we remove the knobs to prevent

No, I am removing unsecure options, i.e. options that are almost
impossible to use securely. There might be combation of settings A1,
B1, C1 (make requirement that short addresses are unique inside one
PAN), D1 (enforce that same key cannot be used in different PANs), E1
(somehow make sure that extended addresses and short addresses do not
conflict when generating nonce, i.e. do not allocate such short
addresses for anybody), F1 (specify how the short address is actually
encoded in the nonce), G1 (somehow detect when device joins which has
extended address which conflicts with short address, and before
allowing that to join, kick the device using that short address out
from PAN) and H1 (whatever that might be, there are most likely still
more requirements) which MIGHT make option A1 almost secure, but even
then there is no guarantee that those settings are enough to make A1
secure.

> However, if A1 and B1 are not insecure, if in fact A1 and B1 have
> been reviewed by security experts from integrators and end users and
> academia, then you can imagine that people who have been shipping
> products set to A1 and B1 for almost a decade will object to the
> proposed changes.

When when there are lots of security people checking some protocol,
that does not mean they actually can find all the problems with it.
Sometimes the issues are obvious when they are pointed out, and there
would have been easy way to solve it originally if people would have
just noticed it.

Looking at how broken industry systems have been (i.e. all the
breakings attackers have done to different home automation systems,
factories, car computers etc) I do not put that much weight on
industry people actually finding security related protocol issues.
Most of the industry people are much more interested in getting the
product out than whether it is really secure or not.

Can you explain how some of those systems using short addresses in
nonce cope with the extended addresses colliding with the assigned
short addresses?

If their solution is "we do not care, as there never will be extended
address that could be interpreted as short address", then I want to
know how do the guarantee that? 

> That's not specifically a concern for 6tisch, but if A1 and B1 are
> both efficient and known to work, then it is potentially a concern
> for 6tisch. If I follow your email below, it seems that you might be
> willing to consider short addresses in nonces if certain things are
> explicitly specified (e.g. nonce construction), and certain things
> are restricted (e.g. two nodes in the same network with the same
> short address). Is that correct?

No. Those are first two steps, but they are not enough. For example
they do not solve the issue of collision between extended address and
short address in nonce. Also as there is no real benefit for using
short addresses in nonces, it just makes things unsecure, so it just
sounds like back door someone is specificially designing in to the
protocol.

Why do you want to keep unsecure option, that provides a way to break
security of 802.15.4 in standard?
-- 
[email-masked]

---

From: Kris Pister <[email-masked]>
Date: Fri, 10 Apr 2015 10:16:16 -0700

> security of 802.15.4 in standard?
Drat.  You have discovered my secret.  I'm an NSA plant trying to provide a
backdoor into future networks.  Please don't tell anyone...

The reality is that I'm trying to make sure that we have a secure MIC
that doesn't require that layer-2 neighbors know each others EUI-64.
All that they need to know is the two-byte short address.

Tero, it doesn't seem that we're that far apart.
 > I have found out that setting A1 (short addresses in nonce) is[...]
 > almost impossible [to make secure] when using B1 (when using ASN)

I'm encouraged by the word "almost".  I believe that smart people who
are used to creating standards and understand security will in fact be able
to make link-layer MIC generation secure using short addresses with ASN
in the nonce generation.
* We will specify exactly how short addresses are  zero-padded.  How 
could we
possibly do an interop if we didn't?
* Keys will be generated randomly.  If we are worried that 128 bit link 
keys will be
the same between two networks, then we have *much* bigger problems to
worry about than the possibility of nonce re-use.
* For layer-2 MIC nonce formation, only 2 byte addresses will be used.  
There
will never be a conflict between a 2 byte address and an extended address.

 >> Your solution is to propose that we remove the knobs [...]
 > No, I am removing unsecure options [...]
You are not removing unsecure options, you are removing a secure, 
efficient, proven
way to do link layer MICs.  You are worried about things that will never 
occur
in practice, because 6tisch will explicitly prevent them from happening.
You are trying to make a change that will require additional bytes to be 
sent in
configuration packets, with no security benefit.  I'm against sending 
bytes in
low power networks for no reason.

ksjp

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 11 Apr 2015 03:13:29 +0300

> All that they need to know is the two-byte short address.

The 802.15.4-2011 do require you to know your neighbors EUI-64
already. Even if you use short address in the nonce, you still need to
fill in the DeviceDescriptor and for your neighbors and for that you
need to know the extended address of it. You do not need to know the
short address, that can be left as 0xffff if you do not know it.

802.15.4-2011 7.2.3 step O uses that information. 

> Tero, it doesn't seem that we're that far apart.

It seems you are talking about some non-802.15.4 systems where you do
not know the neigbours extended addresses, but we are talking about
802.15.4-2011 here (and that requirement of knowing the neigbours
extended address was there already in 802.15.4-2006 and are still
there in 802.15.4rev).

> to make link-layer MIC generation secure using short addresses with ASN

That changing that would make quite a big changes to the nonce
processing for those short addresses, so old implementations would not
be compatible anymore. Also there might be some other cases where
short addresses in nonce might cause problems that I have not yet
found out. Extended addresses are by defination fine, as we know they
are defined to be unique (yes, in practice they might not be unique,
but for our case they are defined to be unique).

Short addresses might not be unique, and they overlap the same area
than what extended address, and there are no extra bits there to
indicate which address is short address and which is extended address.

We could allocate CID (or use the 802.15.4 CID) and define 32-bit
prefix to extended address that would indicate that rest of the
address is actually PAN id + short address.

> could we possibly do an interop if we didn't?

That was my first clue, that people who defined this didn't really
think this part of the 802.15.4e completely, and then I noticed other
problems with it (no PAN id, short address are not required to be
unique, overlapping with extended addresses etc).

> * Keys will be generated randomly. If we are worried that 128 bit
> link keys will be the same between two networks, then we have *much*
> bigger problems to worry about than the possibility of nonce re-use.

No. Keys are generated randomly, but they might also be shared between
the different PANs. I.e. if you use cluster tree network, the
different PANs are part of the same network, but they just use
different PAN coordinator, and PAN coordinators create a tree between
them. 

In that kind of network the device might actually move from one part
of the network to other, and it might be useful to share the same key
for the whole network.

There is no requirement in 802.15.4 that keys cannot be shared between
different PANs. Note, that if different TSCH PANs shared keys, they
also must share the ASN. If the TSCH PANs do not have synced ASN, then
they MUST NOT share keys.

It might be that nobody uses multiple PANs for TSCH, but it is not
forbidden in the 802.15.4 so we either need to make it work, or
explictly forbid it.

> will never be a conflict between a 2 byte address and an extended address.

The text does not say so.

802.15.4e says short addresses in nonces are used only and only if the
frame source addressing used short addresses. If the frame was sent
using 64-bit extended address, then nonce generation is using 64-bit
extend address.

Note, that nodes joining the network might not yet have a short
address, so they have to use extended address until they get the
address. Also orphaned device who have lost their short address, need
to use extended address to talk to the PAN coordinator to be able to
get new one.

As the text in 802.15.4e is written frames can use short or extended
address when generating nonce selected per frame

> efficient, proven way to do link layer MICs.

I have already pointed out it is not secure as defined in 802.15.4e.
Your claims have been that someone at somepoint must have checked it
out, and they must have said it is secure as it has been in use.

> You are worried about things that will never occur in practice,
> because 6tisch will explicitly prevent them from happening.

Where does 6tisch say we never ever use extended address as source
address of any frame?

This makes joining and network resync really hard... 

For example how do you send association response mac command frame,
when it is specified to have both source and destination addresses as
extended addresses? Same for disassociation notification command? Or
does the 6tisch use something completely different for those commands
during the joining phase. If so, what source address does they use in
that case because they do not yet have short address they can use.

In the draft-ietf-6tisch-tsch section 3.1 Network formation says that
"This might include a mechanism to assign a unique 16-bit address to a
node, and the management of initial keying material." which would
indicate that short address assignment is not mandatory.

Yes, I know that when devices are part of the schedule and have their
own dedicated links they must have short address, but not all nodes
need to have dedicated links, some devices can also use those shared
slots and in such case there is no reason why they could not use
extended addresses, or even be in state where they do not have short
address at all.

Note, that short address management inside the PAN gets quite
complicated when you cannot use extended address for any secured
frames. 

> You are trying to make a change that will require additional bytes
> to be sent in configuration packets, with no security benefit. I'm
> against sending bytes in low power networks for no reason.

Those bytes are already mandatory because 802.15.4-2006/-2011/-rev
sets this requirement that device must know the extended address of
the node sending him any secured frames.

I did assume that we were using the 802.15.4-2011 + 802.15.4e as a
baseline, but you are saying this is not true, but instead we use
something that is almost like 802.15.4, but not really?
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sat, 11 Apr 2015 19:37:22 -0400

> short address, that can be left as 0xffff if you do not know it.

So, you don't need to use the EUI-64, but you do need to have a mapping of
short-address to EUI-64.  How does such a mapping become known?

How can any of this work in the field today?

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

---

From: Kris Pister <[email-masked]>
Date: Sat, 11 Apr 2015 17:14:23 -0700

In HART, you join with EUI-64, and all transport sessions use that.
The network manager assigns and knows the mapping from two-byte
short address to EUI-64.

For the MIC at L2 your neighbors don't know or care what your real name is.
They just use the two byte (unique for this network) short address.

If the manager were to assign duplicate short addresses, then two or more
packets sent in the same ASN from the same short address would have the
same nonce and L2 MIC key, which is not good policy but leaks exactly 
nothing.
It seems like saying something along the lines of "don't use short 
addresses in
nonce construction if there is a chance that short addresses will be 
duplicated
with the same key" would be an appropriate warning to see in -2015.

ksjp

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 13 Apr 2015 14:31:39 +0300

Kris Pister writes:
> If the manager were to assign duplicate short addresses, then two or
> more packets sent in the same ASN from the same short address would
> have the same nonce and L2 MIC key, which is not good policy but
> leaks exactly nothing.

Wrong. It leaks the whole content of both packets.

I.e. if you xor the packets together that will competely remove the
encryption and then you have xor of two plain text packets. From there
it is usually very easy to find out what the both frames contain.

Lets say another frame is some kind of temperature measurement packet,
and other is the frame reconfiguring the door keypad with new pin
code, then knowing what temperature actually was at the time when the
packet was sent, you can reconstruct the temperature measurement
packet and xoring that to the frame will give you the pin code...

There was some product which transmitted the WLAN WPA2 password over
the 802.15.4 radio without encryption, so even if "fix" the problem by
turning 802.15.4 encryption on this attack would still leak the
password out...

> addresses in nonce construction if there is a chance that short
> addresses will be duplicated with the same key" would be an
> appropriate warning to see in -2015.

That is not enough. As I mentioned earlier you also need to make sure
there is no collisions between the short addresses and extended
addresses. You said that in 6tisch we only use short addresses, and
never use extended addresses for encrypted packets, but your text
would be meaningless if you cannot use extended address in those cases
where short addresses might get duplicated. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 13 Apr 2015 14:41:29 +0300

Michael Richardson writes:
> So, you don't need to use the EUI-64, but you do need to have a
> mapping of short-address to EUI-64.

Yes. Address formats in the frame can use any device addressing modes,
i.e. none, short or extended, and this is what is actually used when
the frame is sent. The incoming frame security processing will fetch
the DeviceDescriptor for the remote device using the addressing fields
in the frame. The DeviceDescriptor contains extended address of the
device, and also the short address if it is known. For non-TSCH cases
it also includes the FrameCounter, but for TSCH case we do not use
that for anything, as we use ASN as frame counter.

> How does such a mapping become known?

>From the same way you got the short address. When you want to talk to
somebody, you need to somehow know how to address him. Normally you go
to some service which returns you that information. I.e. you talk to
some service asking who is the temperature sensor in this network, and
you get reply back saying it is device with short address of 0x1234
and with extended address of 12-34-56-78-87-65-43-21.

Or you could separate service, where you can send the short address,
and get extended address back.

As you are normally talking with same neighbours all the time, this
means you "waste" these 8-bytes on the air only once, while you are
doing resource lookup.

I do not know what resource lookup method 6tisch is going to use, do
we have something defined for that already?

> How can any of this work in the field today?

I have no idea, as none of this is part of 802.15.4...
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Apr 2015 09:41:41 -0400

> The network manager assigns and knows the mapping from two-byte

I think you are using that the transport session is bound to the EUI-64, but
the hop-by-hop transmission (layer-2) uses two-byte addresses.  Otherwise, I can't
understand why the short address would even be assigned.

---

From: Kris Pister <[email-masked]>
Date: Mon, 13 Apr 2015 08:11:44 -0700

> the hop-by-hop transmission (layer-2) uses two-byte addresses.

that's correct.

ksjp

---

From: Kris Pister <[email-masked]>
Date: Mon, 13 Apr 2015 08:15:15 -0700

> Wrong. It leaks the whole content of both packets.

Tero - it's the L2 MIC that we're talking about.  The packets aren't 
encrypted at L2.
The entire contents of both packets is transmitted in the clear, by design.
End-to-end transport payloads SHOULD be encrypted (in my opinion),
but that's a different topic.

ksjp

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Apr 2015 13:59:51 -0400

> Tero - it's the L2 MIC that we're talking about.  The packets aren't

Isn't there also a NONCE in the L2 MIC?

    > but that's a different topic.

well, I don't think this is something we can assume for 6tisch, so we have
this very real problem in 6tisch.

---

From: Kris Pister <[email-masked]>
Date: Mon, 13 Apr 2015 11:28:26 -0700

> Isn't there also a NONCE in the L2 MIC?
Yes.  That's the nonce that I've been writing about.

 > this very real problem in 6tisch.
Hmm.  I guess this is where having a concrete plan laid out for security 
would
be helpful.  I've just been talking about L2 MIC nonce, and that 
anything beyond
that was a separate discussion.

For example, I have a network of dozens or hundreds of fixed nodes in a 
campus.
I have hundreds or thousands of mobile nodes wandering through. Using
Minimal, it's very convenient (and secure) for a mobile node with a 
unique 2B
short address to form and expect nonces using short addresses.  As it 
wanders,
it doesn't need to know or provide extended addresses.  Mobile nodes may not
have much memory, and not want to keep a large table of DeviceDesciptors.
Fixed devices sending enhanced beacons might not want to add their
extended address to every packet.

Fixed devices may have a much fancier schedule than the mobile devices 
which may
just use minimal.  Fixed devices may use OTF to schedule additional 
bandwidth.
OTF commands probably want to be encrypted, and a nonce will be involved.
Even here a unique 2B short address is not security risk.  If there is a 
risk of
non-uniqueness in the short address and duplicate keys on devices with the
same short address, then this is indeed a security hole.  My advice would be
that we design the 6tisch OTF security protocol so that
(shared short address) && (same OTF key) == 0
I believe that any rationally designed security protocol will enforce that.
Maybe the solution in this case is that
(short address) = 0
which is fine by me for 6tisch OTF security.  I just don't like it for 
L2 MIC
security because it's an unnecessary constraint that requires either 
more bytes
of payload or more packets exchanged.  In some cases this is not a big deal
as Tero has pointed out.  In other cases, it's a pain.

ksjp

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Mon, 13 Apr 2015 15:44:55 -0300

2015-04-13 15:28 GMT-03:00 Kris Pister <[email-masked]>:

> be helpful.  I've just been talking about L2 MIC nonce, and that anything
> beyond
> Minimal, it's very convenient (and secure) for a mobile node with a unique
> 2B
> Even here a unique 2B short address is not security risk.
>

I have a couple of questions regarding OTF security:
Since 6top manages 6top-6top communication between nodes to enable
OTF to negotiate bandwidth requests, I think there is no need to encrypt
OTF commands themselves (since OTF communicates directly with 6top
on the same node). I think that any message that uses the 6top-6top
communication
capability should be encrypted by 6top, including OTF.
Do we need to authenticate all the internal 6tisch modules apart from the
node
itself?

> If there is a risk of
> which is fine by me for 6tisch OTF security.  I just don't like it for L2
> MIC
> security because it's an unnecessary constraint that requires either more
> bytes
> Kris Pister <[email-masked]> <[email-masked]> wrote:
> Michael Richardson <[email-masked]> <[email-masked]>, Sandelman Software Works
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Apr 2015 13:16:23 +0300

> Tero - it's the L2 MIC that we're talking about.  The packets aren't 

Yes, they can be. There is security levels 5-7 in 802.15.4 that will
encrypt the frames.

Is this again one of the unspoken features of 6tisch that L2
encryption cannot be used? 

> but that's a different topic.

Which protocol are you talking about now? I do not think you are
talking about 6tisch in general.

Yes, in lots of cases there will be end-to-end encryption or
protection for the traffic, but I at least have also assumed that
there is also possibility for L2 MIC + encryption for the packets in
transit in 6tisch.

I do not want to rule L2 encryption out in 6tisch. In some cases it is
just enough for normal operations, and you do not need upper layer
end-to-end encryption as devices are talking to each other directly.
Also encrypting the management traffic, routing protocols etc has some
uses, just to protect against passive monitoring.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Apr 2015 14:18:49 +0300

> Yes.  That's the nonce that I've been writing about.

No, we have been talking about the onnce protecting the 802.15.4
security, that covers both the nonce used for L2 encryption and MIC.
The encryption is optional per frame basis, but the same nonce is used
for both in TSCH.

In non-TSCH modes the nonce also includes the security level, thus
nonce will be different if you have encrypt + MIC, or if you have only
MIC.

In TSCH the nonce is same for all security levels. 

> Hmm.  I guess this is where having a concrete plan laid out for
> security would be helpful.  I've just been talking about L2 MIC
> nonce, and that anything beyond that was a separate discussion.

I have never been talking about the L2 MIC nonce only, I have been
talking about the 802.15.4 nonce in general and that covers both MIC
and encrypt + MIC cases.

> For example, I have a network of dozens or hundreds of fixed nodes
> in a campus. I have hundreds or thousands of mobile nodes wandering
> through.  Using Minimal, it's very convenient (and secure) for a
  	    	  ^^^^^^^

What is that "Minimal"? Are you talking about the
draft-ietf-6tisch-minimal?

Btw, that document do recommend that you keep EUI64 of the neighbor in
the section 6.1 in the neighbor table.

It also has two keys, one for authentication of Enhanced Beacons, and
another for "authenticate and encrypt payload of DATA,
ACKNOWLEDGEMENT, and MAC COMMAND frame types and respective header
IEs".

> mobile node with a unique 2B short address to form and expect nonces
> using short addresses.  As it wanders, it doesn't need to know or
> provide extended addresses.  Mobile nodes may not have much memory,
> and not want to keep a large table of DeviceDesciptors.

But it can do end-to-end encryption on the application level? Which
protocol it is using for that?

I mean extended address is 8-bytes, and if you have hunderd fixed
devices in the network, that will be less than kilobyte even if you
store all of the devices. Of course it only needs to store
DeviceDesciptors for only those devices it is actually talking to,
i.e. its neighbors.

> extended address to every packet.

That would be a problem, as unless you know the nonce, you cannot
authenticate the frame. So better would be to use extended address for
the enhanced beacons.

> Fixed devices may have a much fancier schedule than the mobile
> devices which may just use minimal.  Fixed devices may use OTF to
> schedule additional bandwidth. OTF commands probably want to be
> encrypted, and a nonce will be involved.

So now you are suddenly again talking about L2 encryption, not only
MIC.

Btw, what is OTF command? It is not defined in the
draft-ietf-6tisch-terminology document.

Ah, most likely on-the-fly? As in draft-dujovne-6tisch-on-the-fly?

> Even here a unique 2B short address is not security risk. 

Why not? And you never use extended addresses, only short address? Not
even in the joining process?

> If there is a risk of non-uniqueness in the short address and
> duplicate keys on devices with the same short address, then this is
> indeed a security hole. 

What guarantees in your system that there will never be duplicate
short addresses? 

> My advice would be that we design the 6tisch OTF security protocol
> so that (shared short address) && (same OTF key) == 0

Hmm.. draft-dujovne-6tisch-on-the-fly do not define any keys, so I
have no idea what that text is supposed to say. Or is that just trying
to say that if you have duplicate short addresses they must have
different keys?

> I believe that any rationally designed security protocol will

Ensuring in the meshed environment that there never will be duplicate
short address when devices move around and sleep is not that easy
task. When you have given short address 0x1234 to device, when do you
know when you can reuse that short address?

If we are never going to reuse short addresses, that means we might
run out of them at one point, what do we do at that case?

> Maybe the solution in this case is that (short address) = 0 which is
> fine by me for 6tisch OTF security.  I just don't like it for L2 MIC
> more bytes of payload or more packets exchanged.  In some cases this
> is not a big deal as Tero has pointed out.  In other cases, it's a
> pain.

I do not think we should limit 6tisch so much on this level to say
that we cannot use L2 encryption, and we cannot use extended addresses
in any of the secured frames.

Those two are features which are there in 802.15.4 and there are
applications which would like to use those. For example if your setup
is so that you have tens of thousands of "listen" only devices, which
do not really transmit anything ever. In that case allocating short
addresses for each for them is just wasting resources. Those devices
could be some kind of sensors which initially join the network,
register themselves to some server, and then just wait for someone to
connect and ask their measurements. After the initial join they never
transmit anything unless asked first.

So, they are going to stay there for days without nobody ever
connecting them, just keeping track of EBs and time. When someone
wants to contant them and ask for information, that someone will
simply send a message to them on the TxRxS/EB slot using their
extended address. For them the L2 encryption might be enough for
protection, so they might be so simple that they cannot do any upper
layer security protocols.

If we say you cannot use extended address and L2 encryption in 6tisch
this kind of setups are out of question.
-- 
[email-masked]

---

From: Kris Pister <[email-masked]>
Date: Tue, 14 Apr 2015 09:11:07 -0700

Clearly we need to define a complete architecture document so that we can
agree what we're discussing.  Jonathan and I are working on one. Maybe Rene
or Michael or Tero or others have some parts done as well.  Once we have one
or more of those we can tear them apart and combine them constructively.

ksjp