Hello Tero: As I hinted, that thread was a response to a proposal by the authors to update the security section. http://www.ietf.org/mail-archive/web/6tisch/current/msg03440.html
The plan B we agreed upon, if we failed to reach a better argument, was to stick to the current text which according to René reached consensus. The security section as it stands is this: " 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 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 keys, which can be well-known by the network devices and/or pre-configured. One of the keys (K1) is used to authenticate EBs (all frame). As defined in Section 4 EBs MUST be authenticated but payload not encrypted. This prevents two independent networks to interfere or enable non-allowed nodes to join a particular network. A second key (K2) is used to authenticate and encrypt the payload of DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types and respective header IEs. " This is the text I'm asking you whether it is acceptable or not, and if not, what would be the minimal surgery that would make the text acceptable from your standpoint? Note that removing text may be easier than agreeing on well-known vs. not. Cheers, Pascal > -----Original Message----- > From: Tero Kivinen [mailto:[email protected]] > Sent: mardi 26 mai 2015 11:26 > To: Pascal Thubert (pthubert) > Cc: Michael Richardson; [email protected] > Subject: Re: [6tisch] Shipping minimal > > Pascal Thubert (pthubert) writes: > > We thought there was, including René. I think the problem came up with > > the proposal by Kris and that's what we have been discussing. > > This discussion has forked but the title remains; we want to ship > > minimal and the only road block is security. > > I think the minimal is missing other things too. For example it is missing the > mapping from the K1 and K2 to the actual KeyIdMode, KeySource, KeyIndex used > on the wire. > > > We want to say is that minimal does not use L3 security (e.g. the > > optional one in RPL), and that it needs proper L2 security for both > > L2 itself (e.g. for the join process) and for L3 PDUs within the LLN. > > But well-known keys do NOT provide proper L2 security. > > > Can you please verify where/if/how the current text is wrong and > > propose a fix? > > I have done that in my other emails, see for example: > > http://www.ietf.org/mail-archive/web/6tisch/current/msg03362.html > http://www.ietf.org/mail-archive/web/6tisch/current/msg03268.html > > And there were my comments to the replacement text too: > > http://www.ietf.org/mail-archive/web/6tisch/current/msg03475.html > -- > [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
