Subject: [6tisch] differential security for CoAP resources

From: Kris Pister <[email-masked]>
Date: Wed, 06 May 2015 17:34:34 -0700

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?
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.

Thoughts?

ksjp

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 7 May 2015 00:29:40 -0700

Kris,

Some comments inline. 

Regards,
Mališa Vučinić

> On 06 May 2015, at 17:34, Kris Pister <[email-masked]> wrote:
> 
> Mote M has a number of CoAP resources, including temperature and light sensors
> coap://M/S/T and /S/L
> 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),
> Today the assumption is that we will have a DTLS session to protect these resources.
> What is the mechanism that the mote uses to differentiate between A, B, and C?
> 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
> 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

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>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 7 May 2015 16:42:14 +0300

Kris Pister writes:
> 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).

I think the DTLS to CoAP interface needs to also provide the
authenticated identity of the other end, and also provide channel
bindings i.e. make sure that the security properties of all packets
remain same after the device has checked them.

I.e. if device starts some operation that requires multiple UDP
packets, then someone needs to make sure that all of those UDP packets
have same security, and are from same authenticated identity. 

> 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).

Yes.

> 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?

That is not enough. It needs to have table of resources, and ACLs who
are allowed to do operations on them (using some kind of stable
identity for the other end) and what operations are allowed for each
peer. For each peer it also needs to know the authentication
information that the peer uses to authenticate himself in DTLS.

The stable identity cannot be short address, or IP-address as both of
those can change. Some kind of stable IPv6 address would be possible
(derived from the public key of the device), and perhaps even
extended-address of the device (it is supposed to be unique).
-- 
[email-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 7 May 2015 15:45:59 +0200

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-masked]>
wrote:

> 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.
>
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Qin Wang <[email-masked]>
Date: Thu, 7 May 2015 15:36:21 +0000 (UTC)

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-masked]> 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-masked]> wrote:

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

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

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 7 May 2015 18:24:32 +0200

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

On Thursday, May 7, 2015, Qin Wang <[email-masked]> 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 <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>
> Kris,
>
> 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:
> On Thu, May 7, 2015 at 9:29 AM, Mališa Vučinić <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> Kris,
>
> Some comments inline.
>
> Regards,
> Mališa Vučinić
>
> On 06 May 2015, at 17:34, Kris Pister <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Qin Wang <[email-masked]>
Date: Thu, 7 May 2015 17:48:40 +0000 (UTC)

Thomas,
I didn't closely take look the work of ACE. But from the ACE charter, I think you are right, ACE is trying to address the issue. 
One further question: I wonder if it is necessary to describe the access control information in 6tisch interface, i.e. YANG model. Otherwise, how C and S can establish a authorization access to resources even with ACE.
ThanksQin 

     On Friday, May 8, 2015 12:24 AM, Thomas Watteyne <[email-masked]> wrote:

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

 Kris,

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 07 May 2015 20:02:37 +0200

I need to catch up on the details of this thread, but indeed, ACE is
chartered to do authorization.  What exactly you need in terms of
granularity may be application specific, so at some point the ball may
be played back to 6tisch to identify the specific information required.

A strawman for such an authorization information format is in

	http://tools.ietf.org/html/draft-bormann-core-ace-aif-02

With the example:

   [["/s/light", 1], ["/a/led", 5], ["/dtls", 2]]

This is essentially a list of pairs of paths and permission bits.
(The spec for is in CDDL, not in YANG, but should transfer easily:)

   authorization-info = [* authorization]
   authorization = [
     path: tstr,
     permissions: uint .bits methods,
   ]
   methods = &(
     GET: 0
     POST: 1
     PUT: 2
     DELETE: 3
     PATCH: 4
   )

Grüße, Carsten

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 7 May 2015 11:46:34 -0700

Thomas,

> On 07 May 2015, at 06:45, Thomas Watteyne <[email-masked]> wrote:
> 
> For the distributed CoAPIE case, https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00 <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

Even if you consider CoAPIE security to be protected by different L2 keys, you need to take care of actual CoAP resource access i.e. difference between nodes that can READ and DELETE a 6top resource from Kris’ mail. Assuming the mote possesses a table/ACL locally, you would essentially be doing some sort of implicit CoAP authorization using L2 keys. The problem is that higher access granularity at CoAP resource level would then translate to more complex L2 key distribution schemes, which could be considered a layer violation.  

> - the CoAPIE also encapsulates the DTLS record. Packet will be (much) bigger, and neighbor-to-neighbor authentication would be needed.

If I am reading https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00 <https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00> correctly, CoAPIE’s payload at L2 is directly a CoAP message - the rest of the protocol stack is not included. Do you consider including the full protocol stack in the IE in order to get DTLS working?

Mališa

---

From: Qin Wang <[email-masked]>
Date: Thu, 7 May 2015 20:34:48 +0000 (UTC)

Hi Carsten,
My understanding about the model is: a URI is associated with a set of access permission. Correct?
If we want that different Client has different access permission to a resource, e.g. node A is allowed to GET/PUT /6t/cellList in node C, but node B is only allowed to GET /6t/cellList in node C, how should we express it?
ThanksQin  

     On Friday, May 8, 2015 2:03 AM, Carsten Bormann <[email-masked]> wrote:

With the example:

Grüße, Carsten

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 8 May 2015 01:00:23 +0200

Malisa,

The short answer is: I don't know yet :-)

There are obviously different approaches. To be most effective, the right
way to let people propose solutions as individual I-Ds, then have the WG
debate over pros/cons of each.

The requirements are summarized in Kris' e-mail.

Thomas

On Thu, May 7, 2015 at 8:46 PM, Mališa Vučinić <[email-masked]>
wrote:

> Even if you consider CoAPIE security to be protected by different L2 keys,
> you need to take care of actual CoAP resource access i.e. difference
> between nodes that can READ and DELETE a 6top resource from Kris’ mail.
> Assuming the mote possesses a table/ACL locally, you would essentially be
> doing some sort of implicit CoAP authorization using L2 keys. The problem
> is that higher access granularity at CoAP resource level would then
> translate to more complex L2 key distribution schemes, which could be
> considered a layer violation.
>
> If I am reading
> https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00 correctly,
> CoAPIE’s payload at L2 is directly a CoAP message - the rest of the
> protocol stack is not included. Do you consider including the full protocol
> stack in the IE in order to get DTLS working?
>
> Mališa
>
>