Dear Tero, thanks for your comments. I will clarify that headers are only authenticated and payloads are both authenticated and encrypted. As for well-known keys, that was exactly the discussion at the meeting. My point is to remove it but I want to see everybody's opinion.
regards, Xavi 2015-04-21 13:17 GMT+02:00 Tero Kivinen <[email protected]>: > 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
