Re: [6tisch] differential security for CoAP resources

[Thomas Watteyne <[e-mail]>]

Isn't that exactly authorization, for which (Half of) the A in ACE stands
for?

On Thursday, May 7, 2015, Qin Wang <[e-mail]> wrote:

> 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.
>
> Thanks
> Qin
>
>
>
>
>   On Thursday, May 7, 2015 9:46 PM, Thomas Watteyne <
> [e-mail]
> <javascript:_e(%7B%7D,'cvml','[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]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> wrote:
>
> Kris,
>
> Some comments inline.
>
> Regards,
> Mališa Vučinić
>
> On 06 May 2015, at 17:34, Kris Pister <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[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] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
> _______________________________________________
> 6tisch mailing list
> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>