Subject: Re: [Ace] Review of ACE Uses Cases draft (draft-ietf-ace-usecases-03)

From: Ludwig Seitz <[email-masked]>
Date: Tue, 02 Jun 2015 11:38:17 +0200

On 2015-05-29 23:07, Thomas Hardjono wrote:
>
> Hannes, Kepeng, Folks,
>
> As promised, here is a review of the use cases draft (draft-ietf-ace-usecases-03). I also checked against the stated goals of the ACE Charter.
>
> I apologize upfront if some of my comments may offend folks in the ACE WG. However, the field of Constrained Environments and Devices (IoT) is a
 >huge deal, so I believe getting the architecture/protocols right is an 
important contribution that IETF can make.

On a first glance I can not find anything offensive with your comments. 
Thank you for contributing this review.

>
> General comments:
>
> (a) On the positive side:
>
> - I think this is a pretty good and reasonable set of use-cases from the ACE WG. Congrats!
>
> - The majority of use-cases here have been written in a technology-agnostic manner, as they should. And so perhaps the draft doesn't really need to call out specific
> technologies/protocols like REST and CoAP (Section 1, Parag 4 & 5) since these are already called out in the ACE Charter. However, leaving these in is also ok and does
 > not detract from value of the use-cases draft.
>

As I answered to Samuel, I am planning to leave the reference to CoAP in 
the document. I gather from your comment that you are ok with that.

>
> (b) On the (somewhat) negative side:
>
> - IoT is the other side of the coin of Big Data.  This is particularly true for the Home Automation (Smart Home) scenarios.
 > The most valuable asset here is the *data* that these devices collect 
and report.
>
> - As such I was kind of surprise that there was no use-case covering the Home Personal Data Store (Home-PDS).
 > Many smart-home owners would potentially prefer the model where all 
their home-data (e.g. from AC, refrigerator, thermostat, etc)
 > gets collected into one data-store or container that they control 
(call it what you will: the home PC, the "home server", the
 > "home gateway", etc). In this way the home-owner then has 
owner-centric control over which data-sets get sent out of the home.

Since ACE responds to a need by CoRE, the focus of this document is more 
on constrained devices. The Home-PDS is not what we would call 
constrained and one can use regular security protocols to protect it. 
ACE mechanisms may apply to the smaller devices communicating with the 
Home-PDS. Do you think this warrants a specific description in the document?

> PS. If the ACE WG is open, I can write a short use-case on the Home-PDS.
>

I'll read your contribution ASAP.

>
> (c) Weak Privacy Considerations section (Sect 4):
>
> - The privacy consideration section (Sect 4) is weak IMHO. Perhaps a privacy expert should be invited to contribute better text to that section.
>

Could you elaborate on that? What aspects do you think are missing?

> - May I suggest the addition of some references in Sect 4 that indicate awareness of privacy issues around personal/home/health data:
>
> [ref#1] World Economic Forum, "Personal Data: The Emergence of a New Asset Class," 2011, available on http://www.weforum.org/reports/ personal-data-emergence-new-asset-class.
>
> [ref#2] Meglena Kuneva, European Consumer Commissioner, Keynote Speech, Roundtable on Online Data Collection, Targeting and Profiling, Brussels, 31 March 2009. Available at: http://europa.eu/rapid/press-release_SPEECH-09-156_en.htm
>

I do not think that these particular references would be helpful in this 
document. The awareness should be obvious by the text itself, if it 
isn't then the text needs to be improved. Throwing in web references 
that might become dead links by the time the document is published 
doesn't really make it better.

>
>
> Specific comments on certain lines on the draft:
>
> (d) Section 2, parag.2 :
>
>>>> The definition of the function of a
>>>> device in a certain use case is not
>>>> in scope of this document.
>
> This line seems redundant. I think a good use-case ("use-case scenario") should always be written in a high level and
> thus avoid defining functions to begin with.

If I recall correctly we have had request to do exactly that (define 
functions), therefore we felt it necessary to add this sentence.

>
> (e) Section 2.2, parag. 1:
>
>>>> A home automation system connects
>>>> devices in a house to the Internet
>>>> and thus makes them accessible and
>>>> manageable remotely.
>
> To the non-technical reader, this line seems to confine/limit the potential scope of Home Automation or the Smart Home.
> IoT in the home promises far more than provide remote accessibility and remote manageability to devices in the home.
>

I'll rewrite this sentence to clarify that remote access is only one of 
many functions.

>
> (f) Section 2.3.2:
>
>>>> o U3.7 The device provides a service
>>>> that can be fatal for the wearer if it fails.
>>>> Accordingly, the wearer wants a security
>>>> mechanism to provide a high level of security.
>
> I think I understand the intent of this line (related to U3.6), but the sentence could be improved.
 > More specifically, a device failing may have nothing to do with the 
level of security implemented in
 > the device. For example, a heart monitor may fail simply because it 
was a faulty device coming out of the factory.
>
> So perhaps something like:
>
> "The device provides a service that can be fatal for the wearer if it fails. Accordingly, the wearer wants the
 > device to have a high degree of resistance against attacks that may 
cause the device to fail to operate partially or completely".

Agree. I'll use your suggestion.

>
>
> (g) 2.5.3. Advanced Metering Infrastructure:
>
> - This subsection perhaps contains too much technical detail about the Head-End and the Data Collection Units. (Most home owners
> who have cable TV or cable modem don't know that there is a head end CMTS server that talks to their cable box).
> - I would suggest rewriting these two bullets into a softer explanation using the entities involved (home-owner, utility company, smart meter, etc).
>

I'll give it a try.

> (h) 2.5.4: U5.1
>
>>>> U5.1 Devices are installed in hostile
>>>> environments where they are physically
>>>> accessible by attackers. The service
>>>> operator and the utility company want
>>>> to make sure that an attacker cannot use a
>>>> captured device to attack other parts
>>>> of their infrastructure.
>
> - This bullet item does not sound like it is an authorization problem but rather a device-physical-security problem, caused by placing
 > the devices (e.g. smart meter) outside the house or premises. This 
problem could be remedied (e.g. in the future drive-by metering)
 > if in the smart-meter was placed inside the house (e.g. windows 
panel) or placed on high on the wall or the roof.

Actually this text was referring to the inside of the building as 
hostile environment. Some of the tenants can be expected to try and 
manipulate or sabotage metering devices in an attempt to avoid paying 
for their consumption, or just for the pure fun of vandalism (e.g if the 
device is on the roof, where the vandalism cannot be pinpointed on a 
specific person or household).

It is indeed also a physical security problem, but the intent here was 
to indicate that attacking one device physically should not lead to 
opportunities of attacking other devices remotely (e.g. by using 
captured credentials).

>
>
> (i) 2.5.4: U5.2
>
>>> U5.2 The utility company wants to restrict
>>> which entities are allowed to send data to
>>> their endpoints and to ensure the
>>> integrity of the data on their endpoints.
>
> This sentence is a bit confusing and needs fixing (maybe it was 2 sentences joined into one).
 > We know that the utility company wants both of these features 
(authorization to send data
 > with source-authentication; and integrity-protection of data/messages).
 > Perhaps rewriting this into separate lines would help.
>

I'll try to improve that sentence

>
> (j) 2.5.4: U5.2
>
>>>> o U5.3 The utility company wants to
>>>> control which entities are allowed to
>>>> read data on their endpoints and protect
>>>> such data in transfer.
>
> This sentence could also be improved as it seems to merge together two different needs (authorization
 > to read data once it arrives at the side of the utility company; and 
integrity-protection of data/messages in transit to the utility end-point).

Ok, I'll split that up

>
> (k) Section 3: Parag. 1
>
>>> Therefore, the devices will be entrusted with vast
>>> amounts of valuable data or even control functions,
>>> that need to be protected from unauthorized
>>> access. Moreover, the aggregation of data must be
>>> considered: attackers might not only collect
>>> data from a single device but from
>>> many devices, thus increasing the potential damage.
>
> - This paragraph does not read to be consistent.  Most IoT devices will have a limited storage resource, which is why they need to periodically
 > "dump" (somewhere) the data they have gathered so far. So over time 
an IoT device will see large amounts of raw data pass-through but an 
attacker
 > may not necessarily have access to all of this data.
>

A persistent attack would allow an attacker to see all this raw data 
passing through. Of course attacking the "Dump" would be more efficient, 
give equivalent protection measures, but I strongly suspect that 
currently the protection of the IoT devices is comparatively weak.

> - The second sentence is unclear. If an attacker can read data from large amounts of distributed IoT devices on an on-going basis,
 > that means they have successfully compromised these devices on an 
almost permanent basis which means the game is up).
> Perhaps that second line could be re-written/improved.
>

The sentence was written to motivate why protecting even seemingly 
innocuous functions and data on IoT devices is necessary. Perhaps the 
sentence does not quite drive that point home. I'll think about how to 
improve this, but I'll gladly accept suggestions.

Regards,

Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 3 Jun 2015 15:42:53 +0000

Hi Ludwig,

> -----Original Message-----
> From: Ludwig Seitz [mailto:[email-masked]]
> Sent: Tuesday, June 02, 2015 5:38 AM
> To: [email-masked]; Thomas Hardjono
> Subject: Re: [Ace] Review of ACE Uses Cases
> draft (draft-ietf-ace-usecases-03)
> 
> > - IoT is the other side of the coin of Big
> Data.  This is particularly true for the Home
> Automation (Smart Home) scenarios.
> > - As such I was kind of surprise that there
> was no use-case covering the Home Personal
> Data Store (Home-PDS).

I'm aware of some folks who want to create an "IoT Gateway" in the home. They categorize this as a constrained device. So it really depends on the definition of "constrained". We could rename Home-PDS as a "Home-Gateway".

Alternatively, I could collect all my home-data into my mobile phone.  Would this sound better?

/thomas/

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 03 Jun 2015 18:04:58 +0200

Thomas Hardjono wrote:
> the definition of "constrained".

Everything has constraints, so "constrained" on its own is not very well
defined.

That's why we wrote RFC 7228, which is trying to put the term on a
quantitative footing.

I would consider it not so likely that a home central will be designed
as a class-1 device.  Both class-2+ and Linux-level devices (as in the
Belkin WeMo switch) are conceivable, though, so there may still be some
constrainedness.

Grüße, Carsten

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 3 Jun 2015 16:24:13 +0000

Thanks Carsten,

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: Wednesday, June 03, 2015 12:05 PM
> To: Thomas Hardjono
> Cc: Ludwig Seitz; [email-masked]
> Everything has constraints, so "constrained"
> on its own is not very well defined.
>
> That's why we wrote RFC 7228, which is trying
> to put the term on a quantitative footing.
>
> I would consider it not so likely that a home
> central will be designed as a class-1 device.
> Both class-2+ and Linux-level devices (as in
> the Belkin WeMo switch) are conceivable,
> though, so there may still be some
> constrainedness.
>
> Grüße, Carsten

I'm ok if you want to drop the Home-PDS use case. I'll leave the ACE WG to decide.

/thomas/