Subject: Re: [Ace] Next step for use case document

From: Likepeng <[email-masked]>
Date: Wed, 8 Oct 2014 10:34:57 +0000

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:[email-masked]]
> 发送时间: 2014年9月29日 21:08
> 收件人: Likepeng; Hannes Tschofenig; [email-masked]
> 主题: 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 <[email-masked]>
> Date:  Wednesday 24 September 2014 09:06
> To:  "[email-masked]" <[email-masked]>
> 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

---

From: Göran Selander <[email-masked]>
Date: Wed, 8 Oct 2014 12:41:35 +0000

Hi Kepeng,

>about "object security", right?

Yes, object security is certainly one candidate solution.

>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.

>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?

>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

---

From: Likepeng <[email-masked]>
Date: Thu, 9 Oct 2014 01:01:55 +0000

> 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)

> 发送时间: 2014年10月8日 20:42
> >We discussed "object security" during IESG evaluation, and I remember
> >the conclusion is, this should be in scope:
> >> The utility company wants to verify stored and forwarded metering
> >>data with  respect to authenticity, integrity and replay.
> >
> That is right. This formulation is stressing that they need to be valid also in
> "store and forward" use cases.
> 
> >
> >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.
> >
> 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
> (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
> >
> >> -----邮件原件-----
> >> 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.
> >>
> >> 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. )
> >>
> >>
> >>
> >> 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:
> >>
> >> 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.
> >>
> >> >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.
> >> >

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 9 Oct 2014 10:48:15 +0000

Hi,

In secauth requirement draft, there is two requirements that I suggest to be considered by ACE however, If ACE does not want to work on them,  I will keep it in secauth.

Here is the link to secauth requirement draft.
https://tools.ietf.org/html/draft-rafiee-secauth-usecase-01 

   Scenario 2: Alice's wash machine technically has a problem. Its
   application was configured by the vendors? in a way to report this
   problem automatically to third party technical service (repair
   place). Both the technical service application and wash machine need
   to authenticate each other so that they can trust and exchange
   information. Since the application are usually implemented by the
   third party and there was not much effort to secure the
   communications between the device and the application, the security
   of them is a big concern.

Alice turned on the wash machine at home and then went to work. Alice
   can check the status of this wash machine using an application on her
   Smartphone remotely at company x. Wash machine doesn't support any
   certificates signed by a CA. Alice needs to be authenticated in the
   wash machine and wash machine needs to trust Alice to allow her
   control it remotely. Since the application are usually provided by
   third parties, the security of this communication is important and
   the first point of trust is really important.

Thanks,
Best,
Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 9 Oct 2014 10:50:27 +0000

Follow up:
Requirement -> use cases

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 10 Oct 2014 10:47:51 +0200

Hi Hosnieh,

Thank you for your suggestions. I am not sure if I completely understand
which part of your scenario you want us to integrate into the use cases
document. Some questions inline.

On 10/09/2014 12:48 PM, Hosnieh Rafiee wrote:
>    information.

Why does the washing machine contact the repair service and not Alice
herself? She would have to make an appointment with them anyway if the
machine is broken.

>  Since the application are usually implemented by the

Which authorization problem do you want to solve here? Please have a
look at section 2.2.1. in [1]. Do you want to address an authorization
problem that is not already covered here?

Thanks,
Steffi

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 10 Oct 2014 10:50:51 +0200

[1] https://tools.ietf.org/id/draft-seitz-ace-usecases-01.txt

On 10/10/2014 10:47 AM, Stefanie Gerdes wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
> 

-- 
Stefanie Gerdes			Tel: +49 421 218 63906
TZI Universität Bremen		E-Mail: [email-masked]
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany

---

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 10 Oct 2014 09:58:31 +0000

Hi Stefanie,

Thanks for your message. My responses inline

> 
> Thank you for your suggestions. I am not sure if I completely
> understand which part of your scenario you want us to integrate into
> the use cases document. Some questions inline.

Just these two use cases that I explicitly included in my message. Because Kathleen reviewed secauth requirement and one of her question about these use cases that it might be covered by ACE. 

> herself? She would have to make an appointment with them anyway if the

This is based on an article I read about "talking home devices and privacy and security concerns.  This article was based on researches of one of the owner of new smart wash machines who was concerned about the information sent back and forth by wash machine to x locations. In that article it also explained the ability of a smart wash machine that sends its problems to repair service centers automatically and explains the remaining concerns about the security of such applications since the producers only outsource them without much supervision on their security. 

The scenario which you explained is a bit different (only the end point is different) however, IMO, the security of that can be considered in a same way.  

> problem that is not already covered here?

I checked ACE use case section 2.2.1. It appears that the use case only considered authorization and not authentication. So it seems that it presumed the authentication of Jane have already done and Jane only needs to authorize Jeffery to access some resources.

I have a question for you. I haven't read the new version of OAuth documents but such authorization scenarios might already considered by Oauth. Maybe it is good to check with them if it wasn't done before. 

Thanks,
Best,
Hosnieh

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 13 Oct 2014 16:16:10 +0200

Hi Hosnieh,

the scenarios fall into the scope of ACE if at least the resource server
is constrained.

If the washing machine just talks to some cloud-based infrastructure
then that's not really of interest to ACE. If there is, however, a
technician standing next to the washing machine and wants to retrieve
information from the washing machine using his mobile phone or tablet
directly then the washing machine becomes the resource server.

To me it appears (from our earlier discussion about the scenarios) that
you envision some interaction with a server-side infrastructure. If
that's the case then you should be able to solve these use cases with
the already existing standards we have developed.

Ciao
Hannes

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 13 Oct 2014 15:17:13 +0000

Hi Hannes,

Thanks for your response. My responses inline...
> 
> the scenarios fall into the scope of ACE if at least the resource
> server is constrained.

I presumed that something like wash machine have constrained resources.

> directly then the washing machine becomes the resource server.

Ok, So, if I understand you correctly, if one end point is constrained devices and the other point is cloud infrastructure, this is not what ACE will work on and I can put it in secauth. 

> the already existing standards we have developed.

Yes true. But it appears that I have to revise the scope based on your comments and other offlist discussion.

Thanks, 
Best,
Hosnieh

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Oct 2014 18:03:31 +0200

On 13 Oct 2014, at 17:17, Hosnieh Rafiee <[email-masked]> wrote:

> Ok, So, if I understand you correctly, if one end point is constrained devices and the other point is cloud infrastructure, this is not what ACE will work on

If this is just about a secure connection between the constrained device and a less-constrained device, that is already covered by DTLS, so there is nothing to work on.

If the point is to have the less-constrained device become authorized to access resources on the constrained device, then we need something like ACE.

A more detailed introduction of what ACE is about is in draft-gerdes-ace-actors-01.txt

Grüße, Carsten

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 13 Oct 2014 16:16:49 +0000

Hi Carsten,

Thanks for your message. Please see my responses inline...

> > Ok, So, if I understand you correctly, if one end point is
> constrained devices and the other point is cloud infrastructure, this
> is not what ACE will work on
> 
> If this is just about a secure connection between the constrained
> device and a less-constrained device, that is already covered by DTLS,
> so there is nothing to work on.

To some extend true. Thanks for clarification. I will check DTLS again to see what they have and how they want to provide the authentication and authorization in virtualization environment, share the result with the mailinglist.

Besides the above mentioned scenarios, secauth plans to work on first point of trust for different use cases. Does ACE also work on this first point of trust? If so I will remove all use cases regarding constrained devices, if not I only change these particular use cases to only focus on providing first point of trust.

> If the point is to have the less-constrained device become authorized
> to access resources on the constrained device, then we need something
> like ACE.
> 

Thanks, will take a look.

Best,
Hosnieh