Subject: [Ace] '2%' use-cases for object security

From: Malisa VUCINIC <[email-masked]>
Date: Thu, 23 Jul 2015 20:08:57 +0200

Hello Olaf,

Just wanted to follow up on the discussion we had during the WG meeting yesterday.

Arguing that a solution purely based on DTLS is an approach for 'future' bothers me very much. If that were the case, we wouldn't be having nightmares in deploying CDNs, making people share the same private key on multiple machines, or create fake certificates to get (D)TLS 'working' in scenarios that span from point-to-point request-response.

To get back to the constrained world, I believe you concur with the fact that most of the existing WSN deployments either have a gateway with application level processing or gateway running a CoAP proxy. It seems this is going to stay there for a while. Other people may have input here as well. You seemed to be implying that we should not care about that too much?

The '2 %' use-cases you indicated for object security may be comprised of:

- IoT devices talking to the Cloud, where from secured readings may be forwarded and decrypted/verified end-to-end;

- any sort of group communication;

- CDNs with secured IoT data;

- payments using NFC or similar technology involving intermittent connectivity;

- pub/sub brokers and communication over a proxy.

Unfortunately, I don't have data to support your claim that some of these examples really do correspond to the 2%. If you do, it would be great if you could share.

Regards,

Mališa

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 24 Jul 2015 10:00:38 +0200

Hi Malisa,

I believe the underlying issue raised here is the following:

Every solution makes assumptions about what use case they care about
most. This can, for example, be seen from the focus on symmetric key
cryptography and a Kerberos-alike communication pattern in some
solutions while there are somewhat different approaches presented in
other documents.

It appears that there is not a single solution that covers all the use
case and this raises challenges. Of course, the authors of every
solution think that their work covers the relevant use cases.

The use case discussion should have informed our solution work to a
certain extend but maybe it didn't quite do as much as we had hoped.

I was wondering whether you could take a brief look at the use cases to
see whether your scenarios are covered there and, if others in the group
agree, then we will have to take those into account.

In the physical access control use case Erik presented, which happens to
use Bluetooth Smart, we also don't see how DTLS makes sense between the
client (smart phone) and the resource server (door lock).

Ciao
Hannes

On 07/23/2015 08:08 PM, Malisa VUCINIC wrote:
> Arguing that a solution purely based on DTLS is an approach for ‘future’
> bothers me very much. If that were the case, we wouldn’t be having
> nightmares in deploying CDNs, making people share the same private key
> on multiple machines, or create fake certificates to get (D)TLS
> ‘working' in scenarios that span from point-to-point request-response.
> 
>  
> 
> To get back to the constrained world, I believe you concur with the fact
> that most of the existing WSN deployments either have a gateway with
> application level processing or gateway running a CoAP proxy. It seems
> this is going to stay there for a while. Other people may have input
> here as well. You seemed to be implying that we should not care about
> that too much?
> 
>  
> 
> The ‘2 %' use-cases you indicated for object security may be comprised of:
> 
> - IoT devices talking to the Cloud, where from secured readings may be
> forwarded and decrypted/verified end-to-end;
> 
> Unfortunately, I don’t have data to support your claim that some of
> these examples really do correspond to the 2%. If you do, it would be
> great if you could share.
> 
>  
> 
> Regards,
> 
> Mališa
> 
>  
> 
> 
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 24 Jul 2015 10:08:39 +0200

Malisa, Olaf,

despite my earlier response I encourage Olaf to explain what he meant
during the presentation!

Ciao
Hannes

---

From: Malisa VUCINIC <[email-masked]>
Date: Tue, 28 Jul 2015 10:15:44 +0200

Hi Hannes,

The scenarios I mentioned seem to be covered by the Smart Metering use case (U5.5 and U5.8). The text in U5.8 seems a bit convoluted though so I would like to clarify if 'multiple nodes' should say 'multiple application layer hops' or similar, as the term 'node' implies a link layer hop which I don't think we care about in this WG.  Also, 'messages between endpoints' should IMO be rephrased to stress the fact that this may include a sensor reading. 

As per the group communication scenario, U4.8 implies the use of a multicast protocol which voiced some concerns during the meeting so I suppose it should be rephrased to account for generic group communication. Also, U4.8 only implies the actuation so it might be useful to precise that we can also have a single sensor reading accessed by several devices.

I would also suggest to extend Section 3.4 in order to stress how important proxies are in energy-constrained environments. As sensors sleep >99.9% of the time, we certainly do not want to expose them to every client out there that is interested in accessing a reading. Proxies (or application layer gateways) are thus a natural candidate to hide the constrained part and provide the client(s) with up-to-date readings.

Regards,
Mališa

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: vendredi 24 juillet 2015 10:01
To: Malisa VUCINIC; [email-masked]
Cc: [email-masked]
Subject: Re: [Ace] '2%' use-cases for object security

I was wondering whether you could take a brief look at the use cases to see whether your scenarios are covered there and, if others in the group agree, then we will have to take those into account.

---

From: Robert Cragie <[email-masked]>
Date: Tue, 28 Jul 2015 10:24:52 +0100

One of the issues as I see it is defining what we mean by "endpoint". The
term does have a specific meaning in CoAP but is often used rather
abstractly in these sort of conversations. The term "end-to-end" also has
similar issues. Intermediaries can be involved at all layers and for
different purposes and if the requirement is for encryption and/or
integrity protection of data then the whole picture obviously has to be
considered, so regarding the comment about "node" vs. "application layer
hop", both probably need to be considered. It is likely due to the presence
of those multiple intermediaries at multiple layers that protection has to
occur "high up" in the layers, using, for example, object security. This
occurs in the smart metering use case; consumption data from a gas meter
often has to be encrypted and integrity protected at the gas meter (the
origin) and decrypted and verified at the supplier's head end (MDM) system
(the target). It can take a convoluted path through different protocols and
proxies to get from origin to target and if DTLS is used, it is likely to
be one part of the overall picture.

Regarding the use cases in general - I would really like to see them be
just use cases, without any second guessing regarding topologies, protocols
etc. For example, and to Mališa's point, U4.8 should not really mention
"multicast protocol".

Robert

On 28 July 2015 at 09:15, Malisa VUCINIC <[email-masked]> wrote:

> Hi Hannes,
>
> The scenarios I mentioned seem to be covered by the Smart Metering use
> case (U5.5 and U5.8). The text in U5.8 seems a bit convoluted though so I
> would like to clarify if 'multiple nodes' should say 'multiple application
> layer hops' or similar, as the term 'node' implies a link layer hop which I
> don't think we care about in this WG.  Also, 'messages between endpoints'
> should IMO be rephrased to stress the fact that this may include a sensor
> reading.
>
> As per the group communication scenario, U4.8 implies the use of a
> multicast protocol which voiced some concerns during the meeting so I
> suppose it should be rephrased to account for generic group communication.
> Also, U4.8 only implies the actuation so it might be useful to precise that
> we can also have a single sensor reading accessed by several devices.
>
> I would also suggest to extend Section 3.4 in order to stress how
> important proxies are in energy-constrained environments. As sensors sleep
> >99.9% of the time, we certainly do not want to expose them to every client
> out there that is interested in accessing a reading. Proxies (or
> application layer gateways) are thus a natural candidate to hide the
> constrained part and provide the client(s) with up-to-date readings.
>
> Regards,
> Mališa
>