Xavier Vilajosana writes:
> Hi Rene, Michael and Jonathan,
>
> I am working on the text for the security section in the minimal draft. I
> included Rene's suggestion but I still have doubts as during the IETF meeting
> there was some discussion about it.
>
> the security section is composed of 2 paragraphs.
>
> As this document refers to the interaction between Layer 3 and Layer
> 2 protocols, this interaction MUST be secured by L2 security
> mechanisms as defined by [IEEE802154e]. Two security mechanisms are
> considered, authentication and encryption, authentication applies to
> the all packet content while encryption applies to header IEs and MAC
^^^^^^^^^^
Header IEs are not encrypted, they are only authenticated. Payload IEs
are encrypted and authenticated.
Most of the TSCH IEs are Payload IEs (or actually a Nested IEs inside
the MLME payload IE). These include TSCH Synchronization IE, TSCH
Slotframe and Link IE, and TSCH Timeslot IE. Those IEs are encrypted.
TSCH uses also one Header IE, i.e. Time Correction IE, and it is only
authenticated.
> payload. Key distribution is out of scope of this document, but
> examples include pre-configured keys at the nodes, shared keys among
> peers or well-known keys. Refer to the 6TiSCH architecture document
> [I-D.ietf-6tisch-architecture] for further details on key
> distribution and advanced security aspects.
>
> The present document assumes the existence of two cryptographic keys,
> which can be pre-configured. One of the keys (K1) is used to
> authenticate EBs. As defined in Section 4, EBs MUST be
> authenticated, with no payload encryption. This facilitates logical
> segregation of distinct networks. A second key (K2) is used to
> authenticate DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types and
> respective header IEs, with payload encryption. Depending on
> security policy, these keys could be the same (i.e., K1=K2).
>
> The second paragraph is what Rene proposed and had consensus on the ML. In
> red is my doubt that raises from the discussions during the WG meeting at the
> IETF in Dallas. I think that someone was opposing to the text indicating
> well-known keys.
I think well-known keys will just make security weaker, and completely
remove the security if K1=K2.
Also if the K1 is well-known then it will NOT provide the "logical
segregation of distinct networks".
Also if K1 is well known, then EBs do not have any protection, i.e.
anybody can generate fake EBs and mess up the network totally by
giving completely wrong schedule for everybody. If the K1 is something
that you get after you join the network, then you can verify that EBs
are sent by someone who is part of the network, thus you can trust
them bit more.
Also if well-known K1 and EBs are used for time syncronization, i.e.
keeping the ASN in sync after sleep, then nodes which wake up and
whole do know the well-known K1 and private K2, cannot trust the ASN
he gets from the EBs, as it might be faked, thus he cannot use K2 key
before rejoining the network. Otherwise the attacker might roll ASN
backwards during the sleep and cause the device to use same ASN twice
(== same nonce twice == encryption provided by the K2 key would be
broken).
--
[email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
