Subject: Re: [Ace] draft-ietf-ace-usecases-03 WGLC review

From: Ludwig Seitz <[email-masked]>
Date: Tue, 02 Jun 2015 10:53:37 +0200

On 2015-04-11 18:26, Samuel Erdtman wrote:
> Hi,
>
> Thanks for writing a great document, first time I´m sending in review
> comments so I hope I´m doing it the right way.
>

Hello Samuel, thank you for your review. Sorry it took so long to react.

>
> = Abstract and Introduction
> Theses sections are mentioning a connections to CoAP for this document
> but there is very limited actual connections to CoAP that I can see when
> reading is it really needed to mention CoAP since it also says that most
> concepts are general.
>

Since ACE was created because a need expressed by CoRE, I think it 
doesn't hurt to mention CoAP, even if the relationship to this specific 
document is not very pronounced.

>
> = Missing use case?
> I see nothing about secure firmware update, could maybe be seen as
> pushing configuration but it would nice to have it spelled out somewhere.
>

I'm planning to add this in the Building Automation use case

>
> = General comment
> Are the Authorization Problems Summary sections cumulative i.e. if a
> problem has come up in a previous section it will not be mentioned again
> or are the sections autonomous?
> If sections are autonomous I thing at least
> * 2.3.  Personal Health Monitoring
> Also needs integrity protected data, possible confidentiality too.
>
The sections are autonomous, I will add integrity and confidentiality to 
the Personal Health Monitoring use case.

> = General comment about Authorization Problems Summary sections
> Big variation in explanation of why it is a requirement
> For example
> “U1.3 The container owner requires the integrity of the sensor data that
> is used for climate control.”
> Here it is explained, but not here
> “U1.7 The fruit vendor requires the integrity of the data that is used
> to locate the goods”
> It just describes the type of data that needs to be integrity protected
> and nothing about what. We could guess but in U1.3 we did not have to.
>
> It would be super nice if the use case text connected to the
> authorisation problems e.g.
> “Additionally, the sensor values are used to control the climate within
> the cargo containers.”
> could add a reference so that it looks like this
> “Additionally, the sensor values are used to control the climate within
> the cargo containers (U1.3).”
>

I will put in the references and try to improve the justifications, 
where necessary. However sometimes the specific location of the 
reference in the text is somewhat arbitrary, especially if the security 
problem is quite generic.

Let's see how it looks in the next update (coming soon).

>
>
> What is the differens between
> “U1.4 The fruit vendor requires the confidentiality of the sensor data
> that pertains the state of the goods.”
> and
> “U1.6 The fruit vendor requires the confidentiality of the data that is
> used to locate the goods.”
>

I agree, I'm planning to merged those

> Is there really a benefit of splitting U1.6 and U1.7

I agree. Merge here too

>
> 2.2.  Home Automation
> There is nothing about transferring ownership of the permeant parts of
> the automated home like air conditioning when selling the home. Further
> it might be important not to get historical data or it might be
> important to get historical data. e.g. for the heating system it might
> be good to know exactly  how the home behaves during cold periods
> however it might not be interesting to know what groseries that has been
> in the refrigerator.
>

I am planning to add a new section here

> 2.5.3.  Advanced Metering Infrastructure
> Can also feature remote power off, from what I know (I wrote a bit on
> security for smart meters after seeing a hack at Blackhat Europe last
> https://www.nexusgroup.com/en/blog/smart-meter-security-and-pki/)
>
I am going to add a sentence about power off.

>
> 2.6.1.  Dynamically Connecting Smart Sports Equipment
> Maybe the device, could report fitness data to Jody´s fitness account
> while borrowed. would require Jody to authorise the device to access
> here account for an hour.
>

Nice idea, here the constrained device would be the client towards a 
more powerful device. I'll add a paragraph about this case.

Regards,

Ludwig Seitz

-- 
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: Ludwig Seitz <[email-masked]>
Date: Tue, 02 Jun 2015 10:56:22 +0200

On 2015-04-14 03:55, Moore, Steve wrote:
> I apologize for chiming in so late on the WGLC, but I also don't think I
> have any comments that are show stoppers so to speak.
>

Helle Steve,

sorry for being even later in answering your comments. Thank you for 
reviewing the document.

> I agree that this is important, but I'm not really sure that the
> Authentication and Authorization part applies to it. (Although you could
> make the case that the firmware is another resource on the device maybe?)
>

I am planning to add a paragraph on this in the building automation use 
case. The device needs to make sure the update is authorized, so it is 
definitely in scope of this document.

>  > 2.2.  Home Automation
>  > There is nothing about transferring ownership of the permeant parts
> of the automated home like air conditioning when selling the home.
> Further it might be important not to get > historical data or it might
> be important to get historical data. e.g. for the heating system it
> might be good to know exactly  how the home behaves during cold periods
> however it might > not be interesting to know what groseries that has
> been in the refrigerator.
>
> This thought also crossed my mind it is touched upon with the
> re-provisioning that is mentioned in U4.2 under the building automation.
> Handing over the permanent parts of the house would probably be part of
> the authorization/authentication server for the house, but the
> historical data might be more of a feature of the home
> gateway/aggregation service (Or a cloud based home management system).
>

I'm planning to add a paragraph describing that scenario.

Regards,

Ludwig Seitz

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