[6tisch] Benjamin Kaduk's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

[Tero Kivinen <[e-mail]>]

Benjamin Kaduk via Datatracker writes:
> I think we may need to say more about how a JP knows that "secExempt" is
> in effect (see comment in Section 5), since that affects a critical
> piece of the security posture of the network.

secExempt process comes from the 802.15.4 and is not that well
described even there how it is used, only what it does.

The basic idea is that upper layer (application) can set secExempt
flag to true for each device it wants to allow bypassing security
checks in the MAC.

Normally the MAC will do security filtering, i.e., check that each
frame received must have at least security level of n and so on, but
this secExempt allows option for upper layer to temporarely skip those
checks for the incoming frames for certain device.

I.e., when the joining node sends first unencrypted and
unauthenticated frame to JP, the JP will notice that it does not match
the policy, thus it will drop the frame and call upper layer using
MLME-COMM-STATUS.indication telling that it received frame from device
having address of aa:bb:...:ff with security level of 0, and this
frame was not accepted because it violated the security processing
rules in MAC.

Then the upper layer can go and install secDeviceDescriptor for the
device having address of aa:bb:...:ff with secExempt flag set to TRUE,
so next time the device sends frame this frame will be exempted for
the security processing and frame is passed to the upper layer.

The upper layer will then check the frame and process it. In this case
it will forward request to JRC. The secExempt flag for the device is
kept true until the device has successfully joined the network, and
then upper layer can go and turn the secExempt flag off, as there is
no longer need to receive frames from the node that violate security
policy.

In many implementations all of this security filtering / policy
checking is actually done in the upper layer, not in the MAC, thus
they most likely will not even implement secExempt as such, but they
just know that all joining traffic are exemptions to the normal
security policy requiring frame authentication and optionally
encryption.

The 802.15.4 description is conceptual API meaning it tells which kind
of features you would need to provide features used, but the actual
implementation can be very different from one device to another.

The concept described in the 802.15.4 is that you want to have ability
to say do not accept frames that are not protected with suitable
security level, but in addition to that you need to have a way to
exempt those checks in certain cases, like when you are joining the
network. 

> Finally, can we discuss whether a 32-bit MIC is the most appropriate
> default for the key usage?  I lack the domain background to know how
> much impact there is in going to an ENC-MIC64 or ENC-MIC128 scheme.

The max frame length is 127 octets, the MAC header is typically around
23 octets, and with MIC length of 4-octets that leaves 100 octets for
the actual payload. 64-bit MIC would reduce that down to 96 octets,
meaning 4% less than MIC-32.

Because the "default" algorithm comes from the fact that integer value
0 in key_usage of the Link_Layer_Key can be omitted (making
Link_Layer_Key structure one octet shorter), it is meaningful to make
the default key usage similarly to value that provides the maximum
saving of octets.

I.e., if you are so short on octets that you want to save the one
octet from the Link_Layer_Key you are most likely going to use minimal
length for MIC keys too...

I would expect that quite common usage will be combination of
6TiSCH-K1-MIC32 and 6TiSCH-K2-ENC-MIC64, i.e., 32-bit MICs for EB, and
64-bit (or even 128-bit) MICs for data etc.

Also when using only one key the MIC length must be same for each
frame types (the security proofs of 802.15.4 do not apply any more if
same key is used with different MIC lengths when using TSCH mode), so
thats why you need two keys when you want to have short MICs in EBs,
and longer MICs in other frames.

In EBs (Enhanced beacons) you want to use short MIC, as the MIC there
does not really serve that much of purpose. The EB contents is mostly
static (ASN and join metrics will be updated but other information is
same), it is not going to change after the network is set up. This
means that nodes who already have key do not have any use for the data
in EB. Those who need that data to be able to join the network, do not
have they to verify the EB... And as there is lots of EBs sent out by
nodes in the network, you really want to save octets from them...

>    o  Optionally, a network identifier.  The network identifier
>       identifies the 6TiSCH network.  The network identifier MUST be
>       carried within Enhanced Beacon (EB) frames.  Typically, the 16-bit
> 
> Isn't this an inherent property of EBs and not a new requirement for
> minimal-security?  If so, the MUST may not be needed, in favor of
> descriptive language.

I think 802.15.4 do allow sending Enhanced Beacons without PAN ID at
all, i.e. the Source Address could be extended address of the
coordinator, the Destination address could be broadcast address with
extended address format, and the PAN ID Compression could be set to 1,
in which case both Source and Destination PAN ID fields would be
omitted.

This text here explicitly says you cannot use such frame even when it
would be allowed by 802.15.4. On the other hand RFC8180 already says
that EBs use Destination Address of 0xffff, and PAN ID Compression is
set, which means Source PAN ID is Not Present, and Destination PAN ID
will be there to contain the network identifier...

> Section 4.1
> 
>    using the cells contained in the EB.  The pledge can hear multiple
>    EBs; the selection of which EB to use is out of the scope for this
>    document, and is discussed in [RFC7554].  Implementers should make
> 
> nit: This reads as a statement of fact, as if it will universally be
> true that the pledge can hear multiple EBs.  I can suggest a specific
> rewording if you want, though there should be several possibilities.

As all non-leaf nodes do send EBs, I think it is very common to hear
multiple EBs. I think it is rare case where you set up 6TSCH network
and you can only hear exactly one other node...

TSCH and 6TSCH is meant for managed networks where someone plans and
sets up the network properly, so normally adminstrator would try to
plan for outages, and provide multiple routes for reliability...
> 
> Section 5
> 
>    When sending frames during the join process, the pledge sends
>    unencrypted and unauthenticated frames.  The JP accepts these
>    unsecured frames for the duration of the join process.  This behavior
>    may be implemented by setting the "secExempt" attribute in the IEEE
>    Std 802.15.4 security configuration tables.  How the JP learns
>    whether the join process is ongoing is out of scope of this
>    specification.
> 
> This seems like a very important piece of information (whether the join
> process is ongoing, i.e., whether to accept and process unauthenticated
> frames).  Is it discussed in 802.15.4 or somewhere else?

802.15.4 provides ways of doing it, but does not tell how they are
used. SecExempt is the way of doing it, but how secExempt is used is
up to the upper layer == this document.
-- 
[e-mail]