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

From: "Kepeng Li" <[email-masked]>
Date: Thu, 03 Sep 2015 07:54:19 +0800

Hi all,

We would like to start a second WGLC on draft-ietf-ace-usecases-05.
https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/

This will be a 2-week last call, so it will end on Friday, September 18.

Please send comments to the list.

Thanks!

Ciao
Hannes & Kepeng

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 3 Sep 2015 04:28:54 +0000

Looks good.  Thanks to the authors for addressing all the comments that I had given them.  I don't have any further comments.  Therefore, I support progressing the draft.

Best Regards,

Akbar

From: Ace [mailto:[email-masked]] On Behalf Of Kepeng Li
Sent: Wednesday, September 02, 2015 7:54 PM
To: [email-masked]
Subject: [Ace] Second WGLC for draft-ietf-ace-usecases-05

Hi all,

Thanks!

Ciao
Hannes & Kepeng

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 15 Sep 2015 13:43:15 -0700

The document look reasonable for progression.

Comments

Section 2.1 - paragraph 4 - is the last sentence supposed to be a new
paragraph or is there just a return problem on the line. 

(I would suggest looking where the markdown is producing vspace elements and
fix all of those locations.)

Section 2.1.2 - U1.1 - I do not see anything that requires 'transloading
personnel' grant authorizations.  May want to remove this.

Section 2.7.2 - U7.5 - You might want to add that the failure to execute an
authorized command is also an issue, so knowing if a command has or has not
been executed is significant.

s/BMLS/BLMS/

jim

From: Ace [mailto:[email-masked]] On Behalf Of Kepeng Li
Sent: Wednesday, September 02, 2015 4:54 PM
To: [email-masked]
Subject: [Ace] Second WGLC for draft-ietf-ace-usecases-05

Hi all,

 <https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/>
https://datatracker.ietf.org/doc/draft-ietf-ace-usecases/

Thanks!

Ciao

Hannes & Kepeng

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 16 Sep 2015 08:42:45 +0200

On 2015-09-15 22:43, Jim Schaad wrote:
> Section 2.1 – paragraph 4 – is the last sentence supposed to be a new
> (I would suggest looking where the markdown is producing vspace elements
> and fix all of those locations.)
>
> Section 2.1.2 – U1.1 – I do not see anything that requires ‘transloading
> personnel’ grant authorizations.  May want to remove this.
>
> Section 2.7.2 – U7.5 – You might want to add that the failure to execute
> an authorized command is also an issue, so knowing if a command has or
> has not been executed is significant.
>
> s/BMLS/BLMS/
>
> jim
>

Thanks Jim,

we'll fix these as soon as we have collected all the comments from the WGLC.

/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: Sean Turner <[email-masked]>
Date: Wed, 30 Sep 2015 16:04:36 -0400

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?

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?

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

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?

The rest of these are all editorial so I suggested changes OLD/NEW and r/old/new:

0) abstract/s1:

OLD:
 
  This document comprises a collection of representative use cases for
  the application of authentication and authorization in constrained
  environments.

Maybe:

  This document includes a collection of representative use cases for
  authentication and authorization for constrained environments.

1) s1:

OLD:
 
  However, due to the devices’ limitations, commonly used
  security protocols are not always easily applicable.  As the devices
  are expected to be integrated in all aspects of everyday life, the
  application of adequate security mechanisms is required to prevent
  attackers from gaining control over data or functions important to
  our lives.

NEW:

  However, deploying common security protocols can sometimes be difficult
  because of device limitations.  Regardless, adequate security mechanisms
  are required to protect these constrained devices, which are expected to be
  integrated in all aspects of everyday life, from attackers wishing to gain control
  over its data or functions.

2) s1:

OLD:

  We assume that the communication between the devices is based on the
  Representational State Transfer (REST) architectural style,

NEW:

  We assume that the devices communicate based on the
  Representational State Transfer (REST) architectural style,

3) s1: r/intervention (M2M)/intervention, i.e. machine-to-machine (M2M).

4) s1.1 ends with "In addition, this document uses the following terminology:” but there’s nothing listed.  If there’s no additional terminology just remove that sentence :)  I do think it’s important to keep the first sentence.

5) s2: Minor word tweaking:

OLD:
  
  This section lists use cases involving constrained devices with
  certain authorization problems to be solved.  Each use case first
  presents a general description of the application area, then one or
  more specific use cases, and finally a summary of the authorization-
  related problems users need to be solved.

NEW:
 
  This section includes the use cases; each use case first
  presents a general description of the application environment, then one or
  more specific use cases, and finally a summary of the authorization-
  related problems to be solved.

6) s2.1:

OLD:

  The use of such sensor systems makes
  it possible to continuously track and transmit specific
  characteristics such as temperature, humidity and
  gas content during the transportation and storage
  of goods.

NEW:
  
  Sensor systems make it possible to continuously track and transmit
  characteristics such as temperature, humidity and gas content while
  goods are transported and stored.

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.

8) s2.1:

OLD:
 
  During the shipment to their destination the goods often pass stops
  where they are transloaded to other means of transportation, e.g.
  from ship transport to road transport.

NEW:

  While in transit goods often pass stops where they are transloaded to other
  means of transportation, e.g. from ship transport to road transport.

9) s2.1:

OLD:

  The transportation and storage of perishable goods is especially
  challenging since they have to be stored at a constant temperature
  and with proper ventilation.  Additionally, it is very important for
  the vendors to be informed about irregularities in the temperature
  and ventilation of fruits to avoid the delivery of decomposed fruits
  to their customers.  Real-time information on the state of the goods
  is needed for the transporter in order to prioritize goods that will
  expire soon. Furthermore the vendor also wants this type of information
  in real-time, in order to be able to react when goods are spoiled and to be
  able to still fulfill delivery obligations.
 
  The need for a constant monitoring of perishable goods has led to
  projects such as The Intelligent Container
  (http://www.intelligentcontainer.com).

NEW:

  Perishable goods need to be stored at a constant temperature
  and with proper ventilation.  Real-time information on the state
  of the goods is needed by both the transporter and the vendor.
  Transporters want to prioritize goods that will expire soon.  Vendors
  want to react when goods are spoiled to continue to fulfill delivery
  obligations.

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

10) s2.1.1: r/ready for selling/ready to be sold

11) s2.2: Not sure we need the marketing bit:

OLD:
 
  Automation of the home has the potential to become a big future
  market for the Internet of Things.  One function of a home automation
  system can be to connect devices in a house to the Internet and thus
  make them accessible and manageable remotely.  Such devices might
  control for example heating, ventilation, lighting, home
  entertainment or home security.

NEW:

  One application of the Internet of Things is home automation systems.
  A home automation system can connect household devices that control,
  for example, heating, ventilation, lighting, home entertainment, and home
  security to the Internet making them remotely accessible and manageable.

12) s2.2.1: (nice that they’re married but probably don’t need that bit of info): r/Alice and her husband Bob/Alice and Bob

13) s2.3: Again I don’t think we need the marketing and I’m not sure I’d lead with it so maybe move this bit to the end of s2.3.

OLD:

  The use of wearable health monitoring technology is expected to grow
  strongly, as a multitude of novel devices are developed and marketed.
  The need for open industry standards to ensure interoperability
  between products has lead to initiatives such as Continua Alliance
  (continuaalliance.org) and Personal Connected Health Alliance
  (pchalliance.org). 

NEW:

  There is a plethora of wearable health monitoring technology and
  the need for open industry standards to ensure interoperability
  between products has lead to initiatives such as Continua Alliance
  (continuaalliance.org) and Personal Connected Health Alliance
  (pchalliance.org). 

14)  s2.3:  Need to introduce "eHealth device” earlier, e.g. is the same as such as, and the phrase “in charge of the user” is awkward.  How about:

OLD:

  Personal health devices are typically battery
  driven, and located physically on, or in, the user.  They monitor
  some bodily function, such as e.g. temperature, blood pressure, or
  pulse.  They are connected to the Internet through an intermediary
  base-station, using wireless technologies.  Through this connection
  they report the monitored data to some entity, which may either be
  the user herself, or some medical personnel in charge of the user.

NEW:

  Personal health devices, i.e. eHealth devices, are typically battery
  driven and located physically on or in the user to monitor bodily functions,
  such as temperature, blood pressure, or pulse rate.  These devices connect
  to the Internet through an intermediary base-station, using wireless
  technologies and through this connection they report the monitored data
  to some entity, which may either be the user or a medical caregiver.

15) s2.3.1: r/includes some authentication mechanism/ 
includes an authentication mechanism

16) s2.3.1: r/messing up/altering

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

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.

19) s2.4.2: r/they make take/they may take

20) s2.4.3: r/public authorities/public safety authorities

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

22) s2.5.3: r/and more accurate and billing/and more accurate billing  ?

23) s2.6: Could probably remove the parenthetical from the 2nd para - I mean I’d like security for free too but it’s not very realistic and I’m sure there there’s going to be something the user is going to have to do even if it’s just “pairing” them by clicking an accept pairing button.

24) s2.6: I think what you’re trying to say is that continuos monitoring allows an authorized user to create behavior and movement profiles, which is the point of the device after all, and that unless properly “secured” an attacker can do the same.  Might I humbly suggest:

OLD:

   The continuous monitoring of data might however enable an attacker to
   create behavioral or movement profiles.

NEW:

   Continuously monitoring allows authorized users to create behavioral
   or movement profiles, which depends on the devices intended use, and
   unauthorized access to the collected data would allow an attacker to
   create the same profiles.

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

26) s2.7: r/this kind of systems are/these kind of systems are

27) s2.7: (to totally freak people out): r/power/nuclear power

*) (no action required) BTW - I think the last sentence in s2.7 generally applies to this whole document.

28) s3: r/application areas/environments

29) s3:

OLD:

  The appeal of these
  devices is that they are small and inexpensive.  That makes it easy
  to integrate them into many aspects of everyday life.  Therefore such
  devices will see vast amounts of valuable data passing through and
  might even be in control of important functions.  These assets need
  to be protected from unauthorized access.  Even seemingly innocuous
  data and functions should be protected due to possible effects of
  aggregation: By collecting data or functions from several sources,
  attackers might be able to gain insights or a level of control not
  immediately obvious from each of these sources on its own.

NEW:

  These devices are small and inexpensive and this makes it easy
  to integrate them into many aspects of everyday life.  With access to
  vast amounts of valuable data and possibly control of important
  functions these devices need to be protected from unauthorized
  access.  Protecting seemingly innocuous data and functions will
  lessen the possible effects of aggregation; attackers collecting data
  or functions from several sources can gain insights or a level of
  control not immediately obvious to each of these sources on its own.

30) s3: r/Once an attacker gained control/Once an attacker gains control

31) s3.1: It’s not in scope for ACE or the draft, but it’s more important here that it’s out of scope for the draft:  r/of ACE,/,

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:

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

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.

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 

37) (no action required) s4: I’ll await Hannes re-write ;)

Cheers,

spt