Dear All: The goal of minimal is not to be our security architecture, what we want is a minimal text that we expect to authenticate the IEs and the RPL control messages and we expect that L2 security will do that for us.
Tomorrow, it would be good to be able to conclude on the security section of minimal. > I think that your text captures consensus. That's exactly the sort of answer we need on this thread. I understand that you will not be there at that time in the agenda but that your vote is OK. Shepherd hat on, a note is well taken. Thanks Michael! Pascal > -----Original Message----- > From: 6tisch [mailto:[email protected]] On Behalf Of Michael Richardson > Sent: mardi 21 avril 2015 23:35 > To: [email protected] > Subject: Re: [6tisch] security text on minimal > > > Xavier Vilajosana <[email protected]> wrote: > > 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 > > 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. > > Just so that you know, html markup does not survive IETF lists (by intention. > See > homerswebpage.com... so your "red" doesn't survive. > > I think that we agreed that the K1 key was of no cryptographic value. > {I saw a danger in the suggestion that K1 could be the same as K2, as an > implementor might assume this to always be the case.} > > I think that your text captures consensus. > > > -- > Michael Richardson <[email protected]>, Sandelman Software Works -= > IPv6 IoT consulting =- > > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
