Re: [Ace] Next step for use case document

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

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
>