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

[Göran Selander <[e-mail]>]

Hi Thomas,

Thanks for comments, inline

On 2016-04-07 19:21, "core on behalf of Aura Tuomas"
<[e-mail] on behalf of [e-mail]> 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.
>
>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.

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.

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

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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/core