Thomas, > On 07 May 2015, at 06:45, Thomas Watteyne <[email protected]> wrote: > > For the distributed CoAPIE case, > https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00 > <https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00> doesn't focus > on security (it's a -00). IMO, there are two options: > - we consider CoAPIE security to be part of L2 security. That is, a > network-wide PSK, or neighbor-by-neighbor keys installed by the JCE
Even if you consider CoAPIE security to be protected by different L2 keys, you need to take care of actual CoAP resource access i.e. difference between nodes that can READ and DELETE a 6top resource from Kris’ mail. Assuming the mote possesses a table/ACL locally, you would essentially be doing some sort of implicit CoAP authorization using L2 keys. The problem is that higher access granularity at CoAP resource level would then translate to more complex L2 key distribution schemes, which could be considered a layer violation. > - the CoAPIE also encapsulates the DTLS record. Packet will be (much) bigger, > and neighbor-to-neighbor authentication would be needed. If I am reading https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00 <https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00> correctly, CoAPIE’s payload at L2 is directly a CoAP message - the rest of the protocol stack is not included. Do you consider including the full protocol stack in the IE in order to get DTLS working? Mališa
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
