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

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

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" <[e-mail]> wrote:

>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#sectio
>>n
>>-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
>