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 =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
