> Also if the K1 is well-known then it will NOT provide the "logical
> segregation of distinct networks".
Tero, we've been over this many times. A well-known K1 does not provide
any security, but it does in fact provide segregation of distinct networks.
Specifically, if we use "6tischRFCxxxx-15" as K1, it segregates 6tisch
networks
that use that standard from all of the other networks that don't.
The world is filled with 802.15.4 networks. The vast majority of them
do not
abide by any protocol defined by the IEEE or the IETF. They send
whatever bytes
they want as PDU without regard to the 1,000 page documents that they
haven't
read. Or sometimes they use some of the structure and ignore the rest, so
filtering just based on EB structure is risky.
Using a well-known key to generate a MIC (that is calculated in hardware
essentially for free) doesn't give you any security, but it does tell
you with very
high probability that the EB you just heard is from the kind of network
you want
to join. It could be faked, it isn't secure, but with high probability
all of the bits
in the message are what the sender sent, and for good or ill, the sender
was trying
to send a 6tisch EB.
ksjp
On 4/21/2015 4:17 AM, Tero Kivinen wrote:
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).
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
