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
<[email protected]> 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ć <[email protected]> wrote:
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[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
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
