Re: [6tisch] differential security for CoAP resources

Kris,

You're asking the right questions...

To keep 6TiSCH focused, we chose to "outsource" all centralized management
to CoMI/CoAP, and focus on the data model.
The assumption here is that everything you describe (for the centralized
case) is handled by CoAP's security mechanism.
The authorization aspect being currently handled by ACE.
Unfortunately, I haven't been following the ACE work closely.
Can anyone shine a light on whether ACE is handling all of Kris' concerns?

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
- the CoAPIE also encapsulates the DTLS record. Packet will be (much)
bigger, and neighbor-to-neighbor authentication would be needed.

Thomas

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

> Kris,
>
> Some comments inline.
>
> Regards,
> Mališa Vučinić
>
> On 06 May 2015, at 17:34, Kris Pister <ksjp@berkeley.edu> wrote:
>
> Mote M has a number of CoAP resources, including temperature and light
> sensors
> coap://M/S/T and /S/L
> as well as 6top resources such as slotframes and cells
> /6t/6/sf1 and /6t/4/c12_14      (I don't actually know the format).
>
> I might want to allow anyone (host A) on the internet to access the
> temperature, /S/T,
> but only a select few to access anything in /6t.  Maybe some with READ (L2
> neighbors, B),
> maybe only one with DELETE (e.g. the PCE, C).
>
> Today the assumption is that we will have a DTLS session to protect these
> resources.
> Some problems that I see:
> What is the mechanism that the mote uses to differentiate between A, B,
> and C?
> Let's assume that the hand-off between the DTLS module and the CoAP module
> tells CoAP if the packet was properly encrypted (vs. the hand-off from
> UDP).  My
> mote needs some sort of table that binds resources to security
> requirements.  That
> takes care of host A asking for temperature (OK) vs. slotframe info (not
> allowed if
> not protected with DTLS).
>
> But how does the mote differentiate between a READ and a DELETE from mote B
> or C?  Both will be encrypting their requests with DTLS.  Does the mote
> need a
> table of hosts, each with a list of resources, each resource with a 4 bit
> flag of
> permissions?
>
>
> If we want to avoid additional packet exchanges with JCE, I believe it is
> necessary to locally keep such a table. We could for instance optimize this
> with some sort of .htaccess for 6top.
>
> However, I am a bit skeptical of having DTLS sessions with both B and C,
> where B can be the set of all the radio neighbors of the mote. Consider
> that DTLS handshake exchanges 10+ packets and for instance in tinyDTLS
> implementation, each session occupies around 400B of RAM. This session
> overhead is certainly necessary with PCE and JCE but I am not sure if it’d
> be wise to do it for each radio neighbor.
>
>
> And what about OTF, where we will be sending CoAP packets as MLME IEs
> protected
> at layer2?
>
> I know that ACE is working on this, and I'm trying to understand the three
> competing
> solutions and their impact on 6TiSCH.  No matter what they do, it won't
> completely
> solve the OTF/coapIE problem.
>
>
> I agree - this is very specific to 6TiSCH and I don’t really see how we
> could leverage [1] / DTLS to differentiate OTF CoAP exchanges within the
> IEs. Outside of ACE, I noticed some work around COSE (CBOR Object Signing
> and Encryption) [2] that should provide an optimized cryptographic format
> which 6TiSCH could use at any layer (generic formats for encryption, MIC,
> signature). IEs carrying CoAP could therefore have the CoAP payload
> encrypted/authenticated/replay-protected with COSE and by managing
> different keys we could differentiate the access to different resources.
> [3] in fact specifies how a generic crypto format such as COSE could be
> used to also encrypt/authenticate parts of the CoAP header.
>
> [1] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-02
> [2] http://www.ietf.org/mail-archive/web/cose/current/maillist.html
> [3] https://tools.ietf.org/html/draft-selander-ace-object-security-01
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>