Re: [6tisch] differential security for CoAP resources

Malisa,

The short answer is: I don't know yet :-)

There are obviously different approaches. To be most effective, the right
way to let people propose solutions as individual I-Ds, then have the WG
debate over pros/cons of each.

The requirements are summarized in Kris' e-mail.

Thomas

On Thu, May 7, 2015 at 8:46 PM, Mališa Vučinić <Malisa.Vucinic@imag.fr>
wrote:

> Thomas,
>
> On 07 May 2015, at 06:45, Thomas Watteyne <watteyne@eecs.berkeley.edu>
> wrote:
>
> For the distributed CoAPIE case,
> 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 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
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>