Re: [Ace] Next step for use case document

[Likepeng <[e-mail]>]

Hi Goran,

Thanks for the input.

My understanding of the " secure store and forward " use case is mainly about "object security", right?

We discussed "object security" during IESG evaluation, and I remember the conclusion is, this should be in scope:
http://www.ietf.org/mail-archive/web/ace/current/msg00619.html

> The utility company wants to verify stored and forwarded metering data with
> respect to authenticity, integrity and replay.

About the authenticity, integrity and replay, they seem to be quite general and not specific to "store and forward" use case.

Maybe it is better to go to a little bit more detail. 

For example, about integrity, we can say, distribution entity (e.g. Data Collection unit) may read the data, and must not modify the data.

> The utility company wants to configure utility meters securely: The devices
> should be able to verify that a configuration request is authorized, authentic,
> integrity and replay protected.

About configuration, I expect this should be out of scope and should be done by out-of-band mechanisms. 

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: Göran Selander [mailto:[e-mail]]
> 发送时间: 2014年9月29日 21:08
> 收件人: Likepeng; Hannes Tschofenig; [e-mail]
> 主题: Re: [Ace] Next step for use case document
> 
> Dear WG chairs and all,
> 
> Please find below some further suggestions for content of the use case
> document. Apologies for the lengthy mail.
> 
> I propose that some use case in the draft should highlight the need for a
> solution that supports secure store and forward. Here are a set of use cases
> supporting this, the first one is based on interviews with people working with
> utilities. The others use cases show that this is not an isolated example. (There
> is no need to include all use cases in the draft.)
> 
> Utility data collection
> - - -
> A utility company is updating its old utility distribution network with advanced
> meters and new communication systems, known as an Advanced Metering
> Infrastructure (AMI).  AMI refers to a system that measures, collects and
> analyzes usage, and interacts with metering devices such as electricity meters,
> gas meters, heat meters, and water meters, through various communication
> media either on request (on-demand) or on pre-defined schedules.  Based
> on this technology, new services make it possible for consumers to control
> their utility consumption and reduce costs by supporting new tariff models
> from utility companies, and more accurate and timely billing.
> 
> The technical solution is based on levels of data aggregation between ³smart
> meters² located at the consumer premises and the Meter Data Management
> (MDM) system located at the utility company.  Two possible intermediate
> levels are:
> 
> - Head-End System (HES) which is hardware and software that receives the
> stream of meter data and exposes an interface to the MDM.
> 
> - Data Collection (DC) units located in a local network communicating with a
> number of smart meters and with a backhaul interface communicating with
> the HES, e.g. using cellular communication.
> 
> For reasons of efficiency and cost end-to-end connectivity is not always
> feasible, so metering data is stored in batches in DC for some time before being
> forwarded to the HES, and in turn accessed by the MDM.  The HES and the
> DC units may be operated by a third party service operator on behalf of the
> utility company.  One responsibility of the service operator is to make sure
> that meter readings are performed and delivered to the HES.  An example of
> a Service Level Agreement between the service operator and the utility
> company is e.g.  "at least 95 % of the meters have readings recorded during
> the last 72 hours².
> 
> 
> Security properties
> 
> The utility company wants to verify stored and forwarded metering data with
> respect to authenticity, integrity and replay.
> 
> The utility company wants to configure utility meters securely: The devices
> should be able to verify that a configuration request is authorized, authentic,
> integrity and replay protected.
> 
> The utility company wants to be in control of access to plain text metering data.
> Other parties may be allowed access but at the discretion of the utility
> company. E.g. the service operator needs access during test or error cases, or
> for calibrating units on replacement. In particular, it should be possible to
> confidentiality protect the metering data between smart meter and the utility
> company's network.
> 
> (There are also other desirable security properties, the ambition here is not to
> be exhaustive but to highlight the need for end-to-end authorised access. )
> 
> 
> 
> Actually, the drive-by metering use case (section 2.5.1) may require a similar
> functionality:
> 
> 
> Drive-by metering data collection
> - - -
> The meters communicate with a vehicle-attached base station, which drives by
> and collects meter readings. The drive-by service could potentially be operated
> by a third party collecting meter readings on behalf of one or multiple utility
> companies, and should not have access to plain text meter readings, or not be
> able to change the readings. Also in this case it may be cost-efficient to upload
> the readings from the vehicle once the car returns to the 3rd party premises,
> e.g. over WLAN. This means that the readings need to be stored and later
> forwarded, and should be protected end-to-end between smart meter and
> Meter-Data Management system in the respective utility company network
> analogously to the previous use case.
> 
> 
> There are other examples where it may be impossible or infeasible to support
> end-to-end connectivity, e.g. in networks with sleepy devices, in which case a
> publish-subscribe paradigm may be more natural.  Here we pick another
> application of publish-subscribe:
> 
> Information Centric Networking (ICN)
> - - -
> ICN is a paradigm for data access, changing focus from current host-centric
> network to an information-centric network.  In a host-centric network, the
> basic idea is to create secure connections to hosts of trusted providers of data.
> In an information-centric network, on the other hand, it is acceptable that any
> source (cache) should be equally usable.  This requires some mechanism for
> making each information item trustworthy by itself, which can be achieved for
> example by signing data.
> In this case a consumer of an information object could prove its authenticity by
> verifying the digital signature.  Applying ICN to the IoT setting, sensor
> readings could be protected and stored in arbitrary content nodes, not
> necessarily only in origin servers; device configuration updates could be
> protected and stored in proxies, not necessarily only in dedicated
> configuration servers.
> 
> Similar security properties apply as in the previous cases.
> 
> 
> 
> Göran
> 
> 
> 
> From:  Likepeng <[e-mail]>
> Date:  Wednesday 24 September 2014 09:06
> To:  "[e-mail]" <[e-mail]>
> Subject:  [Ace] Next step for use case document
> 
> 
> >Thanks all for the feedbacks to the use case document:
> >http://datatracker.ietf.org/doc/draft-seitz-ace-usecases/
> >
> >Hannes and I went through the feedbacks in the mailing list.
> >
> >
> >In summary, we feel that there is no consensus to adopt the current
> >version of this document.
> >
> >Considering that use case document is our charter item, and this is the
> >only viable candidate, our plan is to ask authors to update the draft
> >according to the received feedbacks so far and we will initiate another
> >call-for-adoption  for the new version.
> >
> >Also, kindly remind you to contribute your texts to the use case document.
> >
> >Thanks,
> >
> >Kind Regards
> >Kepeng & Hannes