Re: [6tisch] differential security for CoAP resources

[Mališa Vučinić <[e-mail]>]

Thomas,

> On 07 May 2015, at 06:45, Thomas Watteyne <[e-mail]> 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