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

["Jim Schaad" <[e-mail]>]

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:[e-mail]] On Behalf Of Aura Tuomas
> Sent: Thursday, April 07, 2016 7:22 PM
> To: [e-mail]
> Subject: [core] About freshness and order of information in CoAP
End-To-End
> Security
> 
> 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
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core