Subject: Re: [Ace] Second WGLC for draft-ietf-ace-usecases-05/6

From: Ludwig Seitz <[email-masked]>
Date: Thu, 1 Oct 2015 14:01:17 +0200

On 2015-09-30 22:04, Sean Turner wrote:
> I’m late with these so feel free to address these during IETF LC.
>
> Overall, I think this draft is good to go and is much better than an
> earlier version I reviewed.  First a couple of questions:
>
> 0) I’ve got two questions that I’d like to ask about the home
> automation case that I’m not sure would require changes (and since
> these are late I’ll leave that up to the chairs):
>
> 0.0) s2.2: There’s the concept of two owners and it seems to imply
> that they both have the same authorization level.  Do you envision a
> scenario where say Alice, who is a lawyer, has a smart lock on her
> closet to store her files and laptop after work that Bob can’t
> access?
Why bring lawyers into an otherwise pleasant scenario?

Joke aside:
No we haven't considered this kind of scenario. However I expect that 
would be subsumed by

    o  U2.3 A home owner wants to apply different access rights for
       different users.

where Bob would be "just" a user, who does not have full access to all 
systems in the house.

Now if Bob wants a similar closet for his stamps collection that Alice 
cannot access, I would expect that it would be hard to integrate that 
into a home automation system controlled by Alice ...

>
> 0.1) s2.2: The addition of the public safety use case also made me
> wonder, if there’s an idea to allow the fire brigade in when the
> house is on fire or to let the police in if Bob has activated his
> home alarm's panic button?
>
I guess that was implicitly assumed in section 2.4.2.1.
The fire department already has special access rights (namely turning 
off the fire alarm).

Perhaps a slight rewording of U4.4 to include other rights than just 
administrative tasks could resolve this?

> 1) One question about the building lighting use case:
>
> s2.4.1.3/s2.4.3: Should there be a requirement from maintenance about
> the device checking the authz before accepting the new firmware?  Is
> this addressed by U4.10 (if so might be good to add "(U4.10)" to the
> last para of s2.4.1.3)?

I wouldn't assume that uploading new firmware is a "extremely 
time-sensitive operation" so U4.10 is not the best item to cover this.

I think the reason why there is no explicit item for this one here is 
that the problem list was supposed to to be incremental.

>
> 2) One question about the sports and entertainment use case:
>
> s2.6: The “low” value judgement caught my attention because when I
> first read this use case I thought that one man’s entertainment event
> where everybody’s kit lights up when their team scores is another
> man’s dissent rally getting droned because their Guy Fawkes masks are
> chipped; I also thought that entertainment devices (e.g. gaming
> systems) are being used for “swatting” so entertainment != low.  But,
> then I read use case and I kind of agree that the as described use
> case might not need all that much security because the transmit range
> of the devices is likely quite small.  So could you just strike the
> 1st sentence and “however” from the second sentence and call it day?
>
I'm ok with that, Steffi do you agree?

>
> The rest of these are all editorial so I suggested changes OLD/NEW
> and r/old/new:
>
I'll look into these

/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: Ludwig Seitz <[email-masked]>
Date: Thu, 1 Oct 2015 16:21:59 +0200

Hello Sean,

thank you for your comments and the especially the detailed suggested 
updates you provided.

Some comments inline.

@Kathleen: One comment specifically relates to some text you suggested 
earlier, could you comment on this? (search for your name in the text).

Regards,

Ludwig

[...]

> 7) s2.1: I’m not sure why it’s necessary to include value judgements:
> “it’s not easy” and “especially challenging":
>
> OLD:
>
> The proper handling of the sensors in this scenario is not easy to
> accomplish.  They have to be associated to the appropriate pallet of
> the respective container.  Moreover, the goods and the corresponding
> sensors belong to specific customers.
>
> NEW:
>
> Sensors in this scenario have to be associated to the appropriate
> pallet of the respective container.  Sensors as well as the goods to
> specific customers.
>
I agree with the first part, however the second part of your suggestion
does not sound like a complete sentence to me. Perhaps if we add a
'belong' somewhere?

> The Intelligent Container (http://www.intelligentcontainer.com) is
> an example project that continuously monitors perishable goods.
>

This sounds like the project itself that is montioring the goods.
Perhaps rephrase this to "... project that explores solutions to
continuously monitor perishable goods."?

> 17) (no action required) s2.3.1: I figured “HeartGuard” had to
> trademarked because I hear about it all the time - nope it’s because
> we give “heartgard” to my dog to prevent roundworms, threadworms,
> etc. ;)
>

I actually made that name up to refer to the device with something
shorter that "the thing that measures John's heart rate".

> 18) s2.3.2 U.3: The impact of security on battery lifetimes is
> specially called out and maybe that’s appropriate given the document.
> But, isn’t the requirement really that non-health-related impacts on
> battery life be minimized to cut down on the amount of
> charging/replacing the battery?  I mean if the device is tweeting out
> it’s location and firing off a charge to keep my heart beating when
> the batter gets low I sure hope it stops tweeting and keeps on firing
> off signals to the heart.  Might I humbly suggest:
>

> U3.3 Battery changes are very inconvenient and sometimes impractical
> so battery life impacts need to be minimized.
>

The section is supposed to list specific authorization problems and I 
feel that aspect is lost with your proposal.

How about this:
U3.3 Battery changes are very inconvenient and sometimes impractical so 
battery life impact of the authorization mechanisms need to be minimized.

> 21) s2.5.1: r/end customer’s/customer’s
>

Doesn't that make it easier to misunderstand?

The utility companies are after all also customers of the service operator.

>
> 25) s2.6.1: (being pc today): r/girls/women

Steffi wrote that section, honestly!

> 32) s3.1: Without an example of what part of DTLS you’re talking
> about maybe we could generalize this a bit :)
>
> OLD:
>
> Denial of service (DoS) attacks threaten the availability of
> services a device provides.  E.g., an attacker can induce a device to
> perform steps of a heavy weight security protocol (e.g. Datagram
> Transport Layer Security (DTLS) [RFC6347]) before authentication and
> authorization can be verified, thus exhausting the device's system
> resources.  This leads to a temporary or - e.g. if the batteries are
> drained - permanent failure of the service.  For some services of
> constrained devices, availability is especially important (see
> Section 2.3).  Because of their limitations, constrained devices are
> especially vulnerable to denial of service attacks.  Solution
> designers must be particularly careful to consider these limitations
> in every part of the protocol.  This includes:
>
> NEW:
>
> Denial of service (DoS) attacks threaten the availability of
> services a device provides and constrained devices are especially
> vulnerable to these types of attacks because of their limitations.
> Attackers can illicit a temporary or if the battery is drained a
> permanent failure service simply by repeatedly flooding the device
> with connection attempts; for some services (see Section 2.3),
> availability is especially important. Solution designers must be
> particularly careful to consider the following limitations in every
> part of the protocol:
>
>

The focus shifts somewhat with your suggestion, what I tried to point 
out here was that especially the security protocols can offer a 
convenient avenue for DoS attacks.

Perhaps this change to your suggested change makes that clearer:

"Solution designers must be particularly careful to consider the 
following limitations in every part of the authorization solution."

33) s3.2: Add “Timers for transaction processing” I mean a simple
> attack is start transaction, wait[0], ...  wait[n], fail.
>

I assume you mean section 3.1 here not 3.2 right?

> 34) s3.2: The last paragraph, aren't we really worried about
> unauthorized disclosure and spoofing?  You can intercept as many
> encrypted sessions as you want and you can eavesdrop on as many
> sessions that don’t require confidentiality as you want.  I really
> think what you’re trying to say is that the sessions need to be
> appropriately protected:
>
> OLD:
>
> Another category of attacks that needs to be considered by solution
> developers is session interception and hijacking.
>
> NEW:
>
> Solution developers also need to consider whether the session should
> be protected from information disclosure and spoofing.
>

Same here you do mean 3.1 right? Also the part on session interception 
and hijacking was specifically requested by Kathleen. I'm not sure if 
your edit captures her intent.

> 35) s3.2 & s3.3) r/(see e.g./(see
>
> 36) s3.3: You’ve convinced me, we need to take care for almost all
> cases involving untrained humans (my mum included): r/home
> scenarios/scenarios
>

-- 
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: Kathleen Moriarty <[email-masked]>
Date: Thu, 1 Oct 2015 11:22:50 -0400

Thanks for addressing these additional comments quickly.  I've
tentatively put this on the 10/22 telechat so we can wrap it up before
the next meeting.  If a new version is ready today, I could put it on
the 10/15 instead.

I'll respond to the one comment inline, thanks for noting my previous
text request.

On Thu, Oct 1, 2015 at 10:21 AM, Ludwig Seitz <[email-masked]> wrote:
> The section is supposed to list specific authorization problems and I feel
> that aspect is lost with your proposal.
>
> How about this:
> The focus shifts somewhat with your suggestion, what I tried to point out
> here was that especially the security protocols can offer a convenient
> avenue for DoS attacks.
>
> "Solution designers must be particularly careful to consider the following
> limitations in every part of the authorization solution."
>
>
> Same here you do mean 3.1 right? Also the part on session interception and
> hijacking was specifically requested by Kathleen. I'm not sure if your edit
> captures her intent.

Information disclosure is the problem that is possible from both
session interception (passive) and hijacking.  Sessions could also be
altered, so that is not covered by the new text, but the terms are
better than what I had as they get to the problem as opposed to attack
types.  Spoofing is also more of an attack type.

How about:

 Solution developers also need to consider whether the session should
 be protected from information disclosure and tampering.

I think that covers active attacks and Sean's spoofing addition.
Sean, if you can think of a better term, please do suggest one or two.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Sean Turner <[email-masked]>
Date: Thu, 1 Oct 2015 12:15:09 -0400

> Why bring lawyers into an otherwise pleasant scenario?

My wife’s a lawyer so I’m always around one :)

> Joke aside:
> No we haven't considered this kind of scenario. However I expect that would be subsumed by
> 
> where Bob would be "just" a user, who does not have full access to all systems in the house.
> 
> Now if Bob wants a similar closet for his stamps collection that Alice cannot access, I would expect that it would be hard to integrate that into a home automation system controlled by Alice …

Okay sounds good.

> The fire department already has special access rights (namely turning off the fire alarm).
> 
> Perhaps a slight rewording of U4.4 to include other rights than just administrative tasks could resolve this?

That would work for me.

> I wouldn't assume that uploading new firmware is a "extremely time-sensitive operation" so U4.10 is not the best item to cover this.
> 
> I think the reason why there is no explicit item for this one here is that the problem list was supposed to to be incremental.

Okay that works for me.

spt

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Sean Turner <[email-masked]>
Date: Thu, 1 Oct 2015 12:23:37 -0400

Ludwig,

Embedding my replies in Kathleen’s to cut down on the emails.

spt

>> does not sound like a complete sentence to me. Perhaps if we add a

Yes: Sensors as well as the goods belong to specific customers.

>> continuously monitor perishable goods.”?

works for me

>> battery life impact of the authorization mechanisms need to be minimized.

Ah I see your point.  wfm

>> The utility companies are after all also customers of the service operator.

Yeah I guess that makes sense.

>> limitations in every part of the authorization solution.”

Yes bringing the focus back to the authz part makes it better.

>> I assume you mean section 3.1 here not 3.2 right?

drat yes I meant 3.1.

> Sean, if you can think of a better term, please do suggest one or two.

nah I think what you suggested works.