Re: [6tisch] differential security for CoAP resources

[Qin Wang <[e-mail]>]

To address Kris's question, I agree with Tero that there are two security elements involved, one is something like DTLS to secure the network access; another is ACL to guarantee right access to the database in devices.
ThanksQin  


     On Thursday, May 7, 2015 9:46 PM, Thomas Watteyne <[e-mail]> wrote:
   

 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ć <[e-mail]> wrote:

Kris,
Some comments inline. 
Regards,Mališa Vučinić

On 06 May 2015, at 17:34, Kris Pister <[e-mail]> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/6tisch




_______________________________________________
6tisch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6tisch