Yet again, this discussion is going round and round in circles.
EB protection
=============
Regarding protection of the EB, I would just like to get a clear statement
on the options and the implications. Here is my stab:
* EB unprotected
- No need to provision any key.
- All nodes can read the EB.
- No nodes can verify the EB.
* EB protected with MIC
- Shared Key needs to be provisioned for verification purposes.
- All nodes can read the EB.
- Nodes which have the shared key can verify the EB.
+ Trust in verification depends on how widely distributed the
shared key is.
+ Gamut from distributed globally to distributed to exactly two
parties.
* A key distributed globally has no security at all and there
can be no trust in the verification.
- There is however a minor benefit in an improved error
detection mechanism over the 2 octet CRC.
* A key distributed to exactly two parties has the highest
security and thus the highest trust in verification, assuming the key
distribution method is implicitly secure.
- Nodes which do not have the key cannot verify the EB and the EB must
be treated as unprotected.
If there is no security on the EB, at least we have a known starting point
and the question is whether the ability to spoof EBs is such a problem in
itself that some additional protection on the EBs is needed. If network
segregation is the aim, there are other ways to achieve this. Where it
starts to go wrong is the assumption that adding a MIC to the EB in itself
provides additional protection; it doesn't as it depends on how widely the
key is distributed. It has the *potential* to provide additional protection
but only where the scope of key distribution is sufficiently limited to be
able to effectively exclude the attacker from spoofing EBs. Moreover, if
the key distribution mechanism makes it difficult to pre-provision the
shared key, then everything falls back to the EB being unsecured.
The most important point is that protecting the EB with a MIC gives the
*potential* for a node to verify the EB. If the shared key *can* be
effectively distributed and the scope of distribution is strictly limited,
then it *will* be effective protection. Otherwise, it will not be.
802.15.4 security
=================
With regard to all the talk about 802.15.4 security, don't get me started
on the debacle which was 802.15.4-2011. There are so many areas where this
is so messed up it is now very difficult to figure out what makes sense and
what doesn't. I have been involved in implementations happily using what
was specified in 802.15.4-2006 and indeed will not use 802.15.4-2011 as it
is basically flawed in so many places. I sincerely hope this has been
properly cleaned up and sanity has returned to 802.15.4-2015 (2015
presumably). For example, relevant to the discussion, why was Key Source
modified to say it had to be PAN ID || Short Address in the 4 octet case?
What was the thinking going on there?
As for what Mališa alludes to regarding join-specific procedures, there are
indeed cases where this "on the fly" security material configuration does
need to be done. It is highly unlikely that the entire incoming security
procedure would be done in hardware due to the programmability of the
procedure. Even if it were, as Mališa points out, if you assume you cannot
do this "on the fly" configuration, the worse case is that one frame gets
dropped, the security material is configured then the next frame is
accepted.
With regard to the options, those pointed out below will all work.
Robert
On 27 May 2015 at 09:19, Malisa Vucinic <[email protected]> wrote:
> Tero,
>
> Could you see if this sums up our discussion.
>
> Reminder: K1 is used to authenticate BEACON frames (security levels
> MIC-32, MIC-64, and MIC-128);
> K2 used to authenticate + encrypt DATA (including broadcast), ACK, COMMAND
> frames (security levels ENC-MIC-32, ENC-MIC-64, and ENC-MIC-128).
>
> Option 1:
> K1, KeyIdMode 0b00 (implicit keying)
> K2, KeyIdMode 0b01 (Explicit Key Index)
>
> Pros: No extra overhead for K1; Flexible re-keying of K2.
> Cons: Difficult re-keying of K1; 1 byte signaling overhead for K2; Limits
> pairwise keying with KeyIdMode 0b00 in a later stage;
>
>
>
> Option 2:
> K1, KeyIdMode 0b01 (with 6tisch predefined Key Index)
> K2, KeyIdMode 0b01 (Explicit Key Index)
>
> Pros: Flexible re-keying for K1 and K2.
> Cons: 1 byte signaling overhead for K1 and K2; Potential collision of the
> 6tisch predefined Key Index with other networks using KeyIdMode 0b01, which
> would delay the join process.
>
>
>
> Options 3:
> K1, KeyIdMode 0b11 (explicit 8 byte Key Source field with a 6tisch
> pre-defined address)
> K2, KeyIdMode 0b01 (Explicit Key Index)
>
> Pros: Flexible re-keying for K2; Globally unique identification of 6tisch
> networks with K1.
> Cons: 9 byte signaling overhead for K1; 1 byte signaling overhead for K2.
>
> Regards,
> Mališa Vučinić
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
