Re: [Ace] Next step for use case document

[Likepeng <[e-mail]>]

> whether you a) want to emphasize what is specific to this
> use case or b) want to emphasize what is common between the use cases.
> Maybe we could delegate to the use case editors to come with a proposal how
> to present this?

My personal preference would be a), but let’s the editors to decide.

Kepeng (Individual)

> -----邮件原件-----
> 发件人: Göran Selander [mailto:[e-mail]]
> 发送时间: 2014年10月8日 20:42
> 收件人: Likepeng; Hannes Tschofenig; [e-mail]
> 主题: Re: [Ace] Next step for use case document
> 
> Hi Kepeng,
> 
> On 08/10/14 12:34, "Likepeng" <[e-mail]> wrote:
> 
> >Hi Goran,
> >
> >Thanks for the input.
> >
> >My understanding of the " secure store and forward " use case is mainly
> >about "object security", right?
> 
> Yes, object security is certainly one candidate solution.
> 
> >
> >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.
> 
> That is right. This formulation is stressing that they need to be valid also in
> "store and forward" use cases.
> 
> >
> >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.
> 
> I’m agree with what you write that the service operator/distribution entity
> must not modify data and may read the data during test or error cases. This is a
> consequence of the other security properties, so to me this is just a matter of
> presentation style; whether you a) want to emphasise what is specific to this
> use case or b) want to emphasise what is common between the use cases.
> Maybe we could delegate to the use case editors to come with a proposal how
> to present this?
> 
> >
> >> 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.
> 
> Maybe configuration is not the right word? This is about changing settings in
> the smart meter. I understand this as an analogue to the kind of
> (re-)commissioning and maintenance activity described in the BLMS use case
> (Section 2.4.1 of draft-seitz-ace-usecases-01), again, in the setting that there is
> not necessarily direct connectivity to the smart meter.
> 
> Best regards,
> Göran
> 
> >
> >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
> >