Subject: [core] About freshness and order of information in CoAP End-To-End Security

From: Aura Tuomas <[email-masked]>
Date: Thu, 7 Apr 2016 22:21:30 +0000

Reading "draft-hartke-core-e2e-security-reqs-00", I started to wonder about the freshness and reordering of sensor data and actuation confirmation. The examples in section "3.1.  One Request - One Response" seem quite simple compared to potential application requirements. 

https://tools.ietf.org/html/draft-hartke-core-e2e-security-reqs-00#section-3.1 

Example: Alarm status retrieval

* There are many kinds of freshness: Sometimes you just want to avoid replays, e.g. for counting events. Sometimes reordering of data is not allowed, e.g. if you want the latest sensor status. Sometimes the data should come causally after another event, e.g. in nonce-based freshness mechanisms that bind the sensor data causally to a specific local clock interval at the receiver. Sometimes the data needs to be recent by the wall clock time, e.g. if you have loosely synchronized clocks. 

* In the alarm status example, it may not be necessary or sufficient for the status data to be "current". In fact, I don't think you ever need to link the answer to the individual alarm status request. Sometimes it is ok to have "recent" status information, in which case caching the at the proxy for a short period is ok. Sometimes you may not want to miss alarms that were raised and then dismissed, in which case the current status is not sufficient but you need the full history. 

Example: Actuation confirmation

* Some actuation may have unique identity, e.g. admit animal number 12345 through the turnstile, and need to be confirmed individually. However, that is not necessarily the case. Some actuation is cumulative, e.g. admit one person though turnstile. Some actions are idempotent, e.g. close the door, and one confirmation may be sufficient. 

* Some actuations need to be strictly ordered, e.g. open and close the door. Some can be reordered, e.g. close door A and close door B. This could possibly be discussed in terms of causal order (the vector clocks mentioned in the ACE WG list) and how much of that order needs to be preserved in the actuation and in confirmations. 

Perhaps some of the above comments are beside the point of the draft, but it looks to me that the concepts of freshness and ordering in object or multi-hop security are more difficult to define and address than in secure end-to-end connections where data on the wire is linearly ordered in each direction.

Tuomas

---

From: Göran Selander <[email-masked]>
Date: Fri, 8 Apr 2016 07:37:23 +0000

Hi Thomas,

Thanks for comments, inline

On 2016-04-07 19:21, "core on behalf of Aura Tuomas"
<[email-masked] on behalf of [email-masked]> wrote:

>Reading "draft-hartke-core-e2e-security-reqs-00", I started to wonder
>about the freshness and reordering of sensor data and actuation
>confirmation. The examples in section "3.1.  One Request - One Response"
>seem quite simple compared to potential application requirements.
>
>* There are many kinds of freshness: Sometimes you just want to avoid
>replays, e.g. for counting events. Sometimes reordering of data is not
>allowed, e.g. if you want the latest sensor status. Sometimes the data
>should come causally after another event, e.g. in nonce-based freshness
>mechanisms that bind the sensor data causally to a specific local clock
>interval at the receiver. Sometimes the data needs to be recent by the
>wall clock time, e.g. if you have loosely synchronized clocks.
>
>* In the alarm status example, it may not be necessary or sufficient for
>the status data to be "current". In fact, I don't think you ever need to
>link the answer to the individual alarm status request. Sometimes it is
>ok to have "recent" status information, in which case caching the at the
>proxy for a short period is ok. Sometimes you may not want to miss alarms
>that were raised and then dismissed, in which case the current status is
>not sufficient but you need the full history.

It is true that different applications have different types of freshness
requirements. It is also true that for devices that can maintain
time synchronisation it may be sufficient to verify a “recent”
state (although there is always a concern that the clocks may)

As you noted, with quickly transitioning states status requests provides
very limited information, better measure a different status parameter,
e.g. whose value reflects an alarm that needs to be reset by authorised
personnel. And in that case, when time synchronisation can’t be
guaranteed, a challenge-response protocol provides one way to get some
certainty of a relevant status parameter.

>* Some actuation may have unique identity, e.g. admit animal number 12345
>through the turnstile, and need to be confirmed individually. However,
>that is not necessarily the case. Some actuation is cumulative, e.g.
>admit one person though turnstile. Some actions are idempotent, e.g.
>close the door, and one confirmation may be sufficient.
>
>* Some actuations need to be strictly ordered, e.g. open and close the
>door. Some can be reordered, e.g. close door A and close door B. This
>could possibly be discussed in terms of causal order (the vector clocks
>mentioned in the ACE WG list) and how much of that order needs to be
>preserved in the actuation and in confirmations.

Also very interesting examples illustrating the wide variety of
application settings. Again, depending on use case the

> 
>
>Perhaps some of the above comments are beside the point of the draft, but
>it looks to me that the concepts of freshness and ordering in object or
>multi-hop security are more difficult to define and address than in
>secure end-to-end connections where data on the wire is linearly ordered
>in each direction.

Yes there are certainly challenges here. Is your proposal that we provide
more details to the examples where the scenarios are applicable?

Göran

>
>Tuomas
>
>_______________________________________________
>core mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/core

---

From: Göran Selander <[email-masked]>
Date: Fri, 8 Apr 2016 08:27:27 +0000

Hi again Tuomas,

It seems I missed to complete some sentences. Here are the missing gaps:

About time as freshness: there is always the concern that the devices
should be synchronised but for some reason are not, unless you constantly
synchronise.

About actuator applications: also here there are different ways for a
security solution to support the client to infer some aspect of freshness:
integrity protection of some time parameter, and challenge-response based
are both useful in different settings.

As I see the e2e security work we should describe a set of relevant
scenarios that illustrates the basic constructs needed, develop those and
then allow applications to build solutions using them. And as your
examples illustrate, the latter may be a challenge, but is IMHO out of
scope for this work.

Do you see any specific requirements, or requirement sets that are missing
in this respect?

Again, thanks for good comments.

Göran

On 2016-04-08 04:37, "Göran Selander" <[email-masked]> wrote:

>>https://tools.ietf.org/html/draft-hartke-core-e2e-security-reqs-00#sectio
>>n
>>-3.1 
>>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 8 Apr 2016 10:32:35 -0300

When I look at this my first thought is that some of this is not a security
issue but a content issue.

How many of these same problems do you have if you do not have security as
part of the scenario you are looking at.  I don't know that security is
necessarily the right place to be doing enforcement of freshness. It makes
sense for it to deal with issues of security not issues of protocol.

I.e. I think that freshness is quite possibly something that should be
addressed in the payload and not in the security wrapper.

Jim

> -----Original Message-----
> From: core [mailto:[email-masked]] On Behalf Of Aura Tuomas
> Sent: Thursday, April 07, 2016 7:22 PM
> To: [email-masked]
> Subject: [core] About freshness and order of information in CoAP
End-To-End
> Security
about the
> freshness and reordering of sensor data and actuation confirmation. The
> examples in section "3.1.  One Request - One Response" seem quite simple
> compared to potential application requirements.
> 
>
https://tools.ietf.org/html/draft-hartke-core-e2e-security-reqs-00#section-3
.1
> * There are many kinds of freshness: Sometimes you just want to avoid
replays,
> e.g. for counting events. Sometimes reordering of data is not allowed,
e.g. if
> you want the latest sensor status. Sometimes the data should come causally
> after another event, e.g. in nonce-based freshness mechanisms that bind
the
> sensor data causally to a specific local clock interval at the receiver.
Sometimes
> the data needs to be recent by the wall clock time, e.g. if you have
loosely
> synchronized clocks.
the
> status data to be "current". In fact, I don't think you ever need to link
the answer
> to the individual alarm status request. Sometimes it is ok to have
"recent" status
> information, in which case caching the at the proxy for a short period is
ok.
> Sometimes you may not want to miss alarms that were raised and then
> dismissed, in which case the current status is not sufficient but you need
the full
> history.
that is
> not necessarily the case. Some actuation is cumulative, e.g. admit one
person
> though turnstile. Some actions are idempotent, e.g. close the door, and
one
> confirmation may be sufficient.
> 
door.
> Some can be reordered, e.g. close door A and close door B. This could
possibly
> be discussed in terms of causal order (the vector clocks mentioned in the
ACE
> WG list) and how much of that order needs to be preserved in the actuation
and
> in confirmations.
it
> looks to me that the concepts of freshness and ordering in object or
multi-hop
> security are more difficult to define and address than in secure
end-to-end
> connections where data on the wire is linearly ordered in each direction.
> 
> Tuomas
>