Kris, Some comments inline.
Regards, Mališa Vučinić > On 06 May 2015, at 17:34, Kris Pister <[email protected]> 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 <https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-02> [2] http://www.ietf.org/mail-archive/web/cose/current/maillist.html <http://www.ietf.org/mail-archive/web/cose/current/maillist.html> [3] https://tools.ietf.org/html/draft-selander-ace-object-security-01 <https://tools.ietf.org/html/draft-selander-ace-object-security-01>
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
