Subject: [6tisch-security] presentation and additional comment

From: Giuseppe Piro <[email-masked]>
Date: Thu, 22 Jan 2015 22:36:55 +0100

Dear all,

I've attached the presentation discussed in the today meeting. Feel
free to comment, once again, each single part.

I've noted that the description of fake_l2_key is a little bit
confused. The main idea is that we need (I believe) for that key in
order to pass correctly the Key Descriptor Lookup Procedure, thus
being able to go through the rest of the incoming security procedure
and receive (once the conditionally passed status is verified) the
unsecured packet.

Now, a key must be identified with a set of parameters, which are
stored into the KeyDescriptor. We can identify this KeyDescriptor in
an implicitly way, i.e., by using KeyIdMode = 0x00.

>From the standard, I've understood that:
- In the case KeyIDMode=0x00, device addressing mode = NO_ADDRESS, and
the frame is not the beacon:
     -- device PAN ID is set to  macPANId.
     -- the device address is set to  macCoordExtendedAddress. (of
         macCoordShortAddress = 0xfffe) or to macCoordShortAddress otherwise.
     --  If the device addressing mode, device PAN ID, and device
address match 0
          the DeviceAddrMode, DevicePANId, and DeviceAddress of a
          KeyIdLookupDescriptor, then the procedure returns with the
corresponding
          KeyDescriptor and passed status.

Hence, we can use KeyIdMode to identify the key associated to the
coordinator. In that case, the KeyDescriptor associated to the
fake_l2_key immediately after that the DeviceDescriptor of the
neighbour is created.

Now, with reference to the issue identified during the call, I believe
that if we store in the KeyDescriptor parameters associated to the
coordinator and identify it implicitly, the discussed procedure (with
workaround approaches) should still work.

Does it make sense ?

Thanks and regards,
Giuseppe

-- 
Giuseppe Piro, PhD
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [email-masked]
phone: +39 080 5963301
web: giuseppepiro.com

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 23 Jan 2015 14:21:31 +0200

> fake_l2_key immediately after that the DeviceDescriptor of the

KeyIdMode is set to be value of the Key Identifier Mode field of the
auxiliary security header, but only if it is present. This is done in
the step e of the 802.15.4-2011 section 7.2.3 (page 133).

The complete step e says:

     e) The device PAN ID shall be set to the Source PAN Identifier
	field, if it is present. If the PAN ID compression field is
	set to one, then the device PAN ID shall be set to the
	Destination PAN Identifier field. The device addressing mode
	shall be set according to the Source Addressing Mode field, as
	defined in Table 54. The device address shall be set to the
	Source Address, if present. The KeyIdMode shall be set to the
	Key Identifier Mode field, the KeyIndex shall be set to the
	Key Index field, if present, and the KeySource shall be set to
	the Key Source field, if present.

I.e. KeyIdMode is only set if Key Identifier Mode field is present.
For security level 0 frames Key Identifier Mode field is not present,
thus KeyIdMode is not set at all. Note, that this is not a programming
language, there is no default values for the KeyIdMode. Valid values
for it is 0-3 or unset...

Note, that step a for example explictly sets the security level to be
zero, for further processing, if it is not present in the frame (i.e.
Security Enabled field is not set). This clearly indicates that there
is no default value for local variables, otherwise the whole step a
could have been left out.

Also step c copies key identifier mode from the corresponding field of
the security control field of the auxiliary security header, but that
is again done only if the we have security enabled field set, thus in
case we have auxiliary security header.
	
> workaround approaches) should still work.

You are modifing the step 802.15.4-2011 step e, as you assume that
KeyIdMode is set to zero when it is not set. This is modification to
the standard.

> Does it make sense ?

Not really.

The incoming frame security procedure is not really the program that
you are running, or something that implementations are running
exactly. It is trying to describe operations that need to be done.

I think we all agree there is something that can be considered to be
bug in the state machine. On the other hand, I myself of course
interpreted the step f to be done only if we have use for
KeyDescriptor, i.e. if we are using the key. The KeyDescriptor is only
needed in step n, so it really should be moved to be done only after
all the DeviceDescriptor checks are done.

So much easier change to the state machine is to stay that step f is
only run if security level is non-zero (i.e. if we have KeyIdMode,
KeyIndex, KeySource etc set).

Or as we did in our first round in maintenance group where we changed
the step to be as follows (From P802.15.4-REVc-DF2):

     f) The procedure shall obtain the KeyDescriptor using the
	KeyDescriptor lookup procedure as described in 9.2.2 with
	using the KeyIdMode, KeyIndex, KeySource, device addressing
	mode, device PANID, and device address. If that procedure
	fails and the KeyIdMode was set in step e), the procedure
	shall return with a status of UNAVAILABLE_KEY.

(i.e. added "and the KeyIdMode was set in step e)")

That was minimal change to get it working, but in our current proposal
(still work in progress) we are going to split the non-secured and
secured frame processing to two different state machines, just to make
it easier to read (the process it describes is still same expect we
fixed bugs at the same time).

The current work in progress can be seen from my resolutions dcoument:

https://mentor.ieee.org/802.15/dcn/14/15-14-0704-02-0mag-lb97-resolutions-kivinen.pdf

starting at page 6. This will still be modified to include new
security checks for the Information Elements.

Note, that the 802.15.4-2011 + 802.15.4e-2012 security state machines
have other problems affecting 6tisch: The frame counter processing is
unconditional, i.e it does not get skipped when TSCH is used.

I.e. In the outgoing frame security procedure will increment frame
counter for each frame, and when it reaches 32-bit 0xffffffff the
procedure starts returning COUNTER_ERROR, even when the actual value
used in the Nonce (ASN) has not yet reached its maximum value.

Also incoming frame security procedure will also get the Frame Counter
Field from the frame to be unsecured (step L), but normally with TSCH
the frame counter field is omitted by setting Frame Counter Supression
field to one. Now the step M will check whether the frame counter is
less than the value in DeviceDescriptor, and it will increment it in
step Q and store it back to DeviceDescriptor. All this processing will
cause TSCH frames to fail in different ways, depending how the
implementation actually implemented this. If we use your "default to 0
when unset" way of doing things, then the step L will set frame
counter to 0 every time, and the first frame is processed ok, and the
FrameCounter in DeviceDescriptor will be set to 0x00000001 after that.
All future frames will fail as frame counter is still zero, but the
FrameCounter in the DeviceDescriptor is larger...

So this all should point out that there are bugs in the 802.15.4-2011
+ 802.15.4e-2012 security state machines, which means you cannot
implement them literally.

For implementations to skip the frame counter processing in the
incoming and outgoing state machines for TSCH, is something that I
would expect most implementations already do. I would also expect that
at least some implementations also ignore the fetching of
KeyDescriptor for security level 0 frames. There might also be
implementations where the KeyIdMode defaults to zero when it is not
set.

Without knowing what all implementations actually do, there is nothing
we can really do to ensure ability to use old implementations.

Your work-around is quite fine for some implementations, but I would
be really suprised if it would work with all implemenations. My
work-around (i.e. assume that step f is only run for secured frame) is
similar.

Because of this I think it would be better to allow IEEE to fix these
things, and not try to "invent" work-arounds in IETF for these
especially by trying to guess how implementations implement things. Of
course if you have gone through all implementations and know what they
do then proposing work-around would be very useful.

As I told earlier, the IEEE is already working to fix these issues,
and currently new revised version of the 802.15.4 is expected to be
available after summer or so.

I will send separate email about other problems in the 802.15.4e-2012
and 802.15.4-2011 standards when taking about the TSCH and Information
Elements. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 23 Jan 2015 15:18:26 +0200

Some other comments to the slides:

In slide 2 you have figure 35 of the 802.15.4-2011 frame format, but
when using TSCH you need ot use 802.15.4e-2012 frame format, which is
bit different (i.e. there is information elements there). Also the
same for Figure 36 (the IE present field is missing).

In slide 3 you have beacon frame format, but that is for non-enhanced
beacons, and TSCH always uses the enhanced beacons. See section
5.1.2.6 (page 24 of 802.15.4e) where says TSCH uses Enhanced Beacons,
so it can send IEs in there.

In slide 11 you says that SecurityLevel=0 and KeyIdMode=0x00, but that
is not possible. If SecurityLevel is zero, then KeyIdMode is not
present, meaning it will be unset not 0x00.

In slide 23 you say list important parameters, but the TSCH
information elements (TSCH Syncronization IE etc). Also note, that
these are payload IEs, meaning they are encrypted if we are using
SecurityLevel 7, thus joining node cannot get that information. If
those are really needed then we need to use SecurityLevel 3 intead of
7 for beacons. I think we need that IE for example to know the ASN,
and know when to send data to coordinator... 

In slide 28 you list that SrcAddrMode could be SHORT_ADDRESS, but as
this is device joining the network, it cannot have short address yet
(assigned by PAN coordinator), thus it must use EXTENDED_ADDRESS for
first frames...

In slide 29, as I commented in separate email there is no step e that
sets key id mode to 0x0. Step e will not set it, so it will stay
unset.

In silde 33, same thing, can only use EXTENDED_ADDRESS until gets
short address... 

In slide 36, we need to use both 802.15.4-2011 and 802.15.4e-2012, as
we are talking about TSCH, which is defined in 4e. Also fake key
solution might solve issues for some implementations, but it is
completely possible that implementations complient to standard will
not work with that work-around, or that they will work without that
work-around.
-- 
[email-masked]