Subject: [Ace] AD review of draft-ietf-ace-usecases-05

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 23 Sep 2015 21:04:32 -0400

Hello,

Thanks for the quick turn around in an update after this WG last call.
I did my review a little early in hopes that we could progress this to
IETF last call soon.  The shepherd report will check all comments from
the WG last call as well, but we can start this in parallel.

ACE Use Case Draft review:

It seems the "Authorization problem summary" lists contain a mix of
desired capabilities/requirements and problems.  Is this the right
heading for this section?

Section 2.2.5
- new homeowner would want to control the list of all authorized users
at any given time to the house or connected devices (in the case where
device management may have separate permissions from house access).
At time of transfer of the house, they will want to make sure the
previous owners and any contractors no longer have access.

Nanny/cleaners/plumbers might have access to the house, but not to
configure or access the camera monitors.

Section 2.3 line 4
s/lead/led/
between products has lead to initiatives such as Continua Alliance

Section 2.5.4

- Wouldn't the user want access to the usage information, while
preventing "others" (might include neighbors or attackers - already
covered in U5.9) from accessing the system?  The consumer is not
included in the list is why I ask.

Section 2.6.1
Do such shoes exist?  The watch example is a common one in use today.

Section 2.6.2
Other sections are more explicit on problems, so shouldn't this
section list out that When Jody connects the watch to upload her data
to her fitness account, no other data is uploaded?

I'm not sure how realistic it is to have multiple profiles with access
rights on a sports watch.  Is this a feasible example?  Are there
watches that do this today or smart phone apps for running that allow
for multiple profiles?

Section 2.7.2
Are different levels of access required?  Is that an authorization
challenge that needs to be considered for let's say operators vs.
auditors of the platform?  I see you have that in section 3.2, but
should it be here too?

Section 3.1
Usage information in transit should also be protected.  In addition to
privacy, there could be opportunities for fraud.  In the case of
utilities, in some cases with renewable energy, money is given to the
home owner for generating x amount of energy on top of the usage being
covered.  With this, there are opportunities for fraud on usage as
well as with payment for generation.  I can explain more if needed on
this example.  There is no need to include my example, more that we
should consider this a security problem too because of the possibility
of fraud, not just privacy.

Thank you!
-- 

Best regards,
Kathleen

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 24 Sep 2015 09:42:28 +0200

Kathleen,

thank you for your review. I don't think the changes from 05 to 06 
affect you comments, so I'll just apply them to 06.

Comments inline

Regards,
Ludwig

> heading for this section?

We have tried to steer away from specific requirements in order to 
reduce the tendency towards requirements engineering.
It is clear that many of the problems could be easily reinterpreted as 
generic desired capabilities and generic requirements.

The point we are trying to make is this:

Various entities have requirements and desired capabilities in the 
different use cases, some of these lead to authorization problems 
involving constrained devices, which ACE has the ambition to solve. We 
tried to capture the latter in the sections called "Authorization 
problems summary".

I've no problem changing the section headers, as long as the indention 
of the document remains clear. I'm grateful for suggestions on how to 
proceed here.

> previous owners and any contractors no longer have access.

I guess this is best addressed by adding a sentence or two in section 
2.2.4 (which might lead to new points in 2.2.5).

> configure or access the camera monitors.
This is kind of similar to 2.2.3 (the visitor scenario), where someone 
is given restricted access. I think the cleanest solution would be to 
extend section 2.2.3 to avoid duplication.

> between products has lead to initiatives such as Continua Alliance
ok

> included in the list is why I ask.
Right, I'll formulate a point to cover this more clearly

> Do such shoes exist?  The watch example is a common one in use today.
No idea, Steffi?

> to her fitness account, no other data is uploaded?
We'll add that explicitly.

> watches that do this today or smart phone apps for running that allow
Not sure, Steffi you wrote that one, could you investigate?

> auditors of the platform?  I see you have that in section 3.2, but
Yes it should, I'll add such an item

> of fraud, not just privacy.
Just to make sure I get your point correctly: You are missing a 
paragraph on protection of information in transit in the security 
considerations?

My gut feeling is that it would fit in conjunction with the paragraph on 
pervasive monitoring, since there is some overlap in the protection 
measures.

-- 
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: Stefanie Gerdes <[email-masked]>
Date: Fri, 25 Sep 2015 11:30:36 +0200

Hi Kathleen,

Thank you for your review. Some comments regarding the Sports and
Entertainment use case inline.

> Do such shoes exist?  The watch example is a common one in use today.

Nike+ shoes have a wireless chip with a sensor [1]. There are two
different models of sensor enabled shoes, the normal nike+ shoe has a
pocket in the left shoe for a single sensor, the basketball shoe [2] is
equipped with several sensors that can be used to measure, e.g, jump
height and quickness. Other than Nike, there is e.g. runScribe [3] that
also has a sensor in one shoe. There are other approaches where sensors
are integrated in socks [4].

This is only one example for sensors in sportswear that are designed to
improve the training. Another example is sensors to improve the swing
or stroke [5].

> watches that do this today or smart phone apps for running that allow

The technology is still very new, so it is difficult to say in which
direction they will be heading. However, runScribe claims that their
product can be shared with family and friends and that it will be
possible to create different user profiles [6].

Is there something I can add to the section to address your questions?

Thanks,
Steffi

[1] https://secure-nikeplus.nike.com/plus/products/basketball
[2]
http://news.nike.com/news/nike-unveils-revolutionary-nike-experience-for-basketball-and-training-athletes
[3] http://www.runscribe.com/
[4] http://www.sensoriafitness.com/
[5] http://www.zepp.com/
[6] http://www.runscribe.com/faq/

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 25 Sep 2015 06:48:13 -0400

Thank you, Steffi.  It's helpful to know the use case is realistic.  I'll try to respond to the other responses today.  I'm at the MARNEW workshop.

Thank you,
Kathleen 

Sent from my iPhone

> On Sep 25, 2015, at 5:30 AM, Stefanie Gerdes <[email-masked]> wrote:
> 
> Hi Kathleen,
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 25 Sep 2015 09:05:40 -0400

Hello Ludwig,

Thanks for the quick response, a few comments inline.

On Thu, Sep 24, 2015 at 3:42 AM, Ludwig Seitz <[email-masked]> wrote:
> Kathleen,
>
> thank you for your review. I don't think the changes from 05 to 06 affect
> you comments, so I'll just apply them to 06.

Great, thanks,

> We have tried to steer away from specific requirements in order to reduce
> the tendency towards requirements engineering.
> Various entities have requirements and desired capabilities in the different
> use cases, some of these lead to authorization problems involving
> constrained devices, which ACE has the ambition to solve. We tried to
> capture the latter in the sections called "Authorization problems summary".
>
> I've no problem changing the section headers, as long as the indention of
> the document remains clear. I'm grateful for suggestions on how to proceed
> here.

Hmm, maybe if you read through them again with this comment in mind,
some editing that makes the purpose clear might be good.

> I guess this is best addressed by adding a sentence or two in section 2.2.4
> (which might lead to new points in 2.2.5).

Great, thanks.

> This is kind of similar to 2.2.3 (the visitor scenario), where someone is
> given restricted access. I think the cleanest solution would be to extend
> section 2.2.3 to avoid duplication.

That sounds good, thanks.

> Right, I'll formulate a point to cover this more clearly

Thanks.

>> Do such shoes exist?  The watch example is a common one in use today.

Steffi provided an answer, thanks!

> We'll add that explicitly.

Great, thanks.

> Not sure, Steffi you wrote that one, could you investigate?

Done, thanks.

> Yes it should, I'll add such an item

Great, thanks!

> Just to make sure I get your point correctly: You are missing a paragraph on
> protection of information in transit in the security considerations?

Yes, but specific to fraud, which normally involves active attacks.
It might be done passively, but to avoid detection, it most likely
involves active attacks that could alter data.  If the homeowner is
not aware of the fraud, then the attacker may be more successful for a
longer period of time - skimming money for example if a homeowner
generates renewable energy for instance.

> pervasive monitoring, since there is some overlap in the protection

I'd separate it out to make it clear that these are different attack
types with different consequences.

Thank you,
Kathleen

>
>
> --
> 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
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

-- 

Best regards,
Kathleen