[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-seitz-ace-usecases) 00 01 02 03 04 05 06 07 08 09 10 RFC 7744

ACE Working Group                                          L. Seitz, Ed.
Internet-Draft                                       SICS Swedish ICT AB
Intended status: Informational                            S. Gerdes, Ed.
Expires: September 10, 2015                      Universitaet Bremen TZI
                                                             G. Selander
                                                                Ericsson
                                                                 M. Mani
                                                                   Itron
                                                                S. Kumar
                                                        Philips Research
                                                          March 09, 2015


                             ACE use cases
                       draft-ietf-ace-usecases-03

Abstract

   Constrained devices are nodes with limited processing power, storage
   space and transmission capacities.  These devices in many cases do
   not provide user interfaces and are often intended to interact
   without human intervention.

   This document comprises a collection of representative use cases for
   the application of authentication and authorization in constrained
   environments.  These use cases aim at identifying authorization
   problems that arise during the lifecylce of a constrained device and
   are intended to provide a guideline for developing a comprehensive
   authentication and authorization solution for this class of
   scenarios.

   Where specific details are relevant, it is assumed that the devices
   use the Constrained Application Protocol (CoAP) as communication
   protocol, however most conclusions apply generally.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any




Seitz, et al.          Expires September 10, 2015               [Page 1]


Internet-Draft                ACE use cases                   March 2015


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 10, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Container monitoring  . . . . . . . . . . . . . . . . . .   4
       2.1.1.  Bananas for Munich  . . . . . . . . . . . . . . . . .   5
       2.1.2.  Authorization Problems Summary  . . . . . . . . . . .   6
     2.2.  Home Automation . . . . . . . . . . . . . . . . . . . . .   6
       2.2.1.  Controlling the Smart Home Infrastructure . . . . . .   7
       2.2.2.  Seamless Authorization  . . . . . . . . . . . . . . .   7
       2.2.3.  Remotely letting in a visitor . . . . . . . . . . . .   7
       2.2.4.  Authorization Problems Summary  . . . . . . . . . . .   8
     2.3.  Personal Health Monitoring  . . . . . . . . . . . . . . .   9
       2.3.1.  John and the heart rate monitor . . . . . . . . . . .   9
       2.3.2.  Authorization Problems Summary  . . . . . . . . . . .  10
     2.4.  Building Automation . . . . . . . . . . . . . . . . . . .  11
       2.4.1.  Device Lifecycle  . . . . . . . . . . . . . . . . . .  11
       2.4.2.  Authorization Problems Summary  . . . . . . . . . . .  13
     2.5.  Smart Metering  . . . . . . . . . . . . . . . . . . . . .  14
       2.5.1.  Drive-by metering . . . . . . . . . . . . . . . . . .  14
       2.5.2.  Meshed Topology . . . . . . . . . . . . . . . . . . .  15
       2.5.3.  Advanced Metering Infrastructure  . . . . . . . . . .  15
       2.5.4.  Authorization Problems Summary  . . . . . . . . . . .  16
     2.6.  Sports and Entertainment  . . . . . . . . . . . . . . . .  16
       2.6.1.  Dynamically Connecting Smart Sports Equipment . . . .  17
       2.6.2.  Authorization Problems Summary  . . . . . . . . . . .  17
     2.7.  Industrial Control Systems  . . . . . . . . . . . . . . .  18



Seitz, et al.          Expires September 10, 2015               [Page 2]


Internet-Draft                ACE use cases                   March 2015


       2.7.1.  Oil Platform Control  . . . . . . . . . . . . . . . .  18
       2.7.2.  Authorization Problems Summary  . . . . . . . . . . .  19
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     3.1.  Attacks . . . . . . . . . . . . . . . . . . . . . . . . .  19
     3.2.  Configuration of Access Permissions . . . . . . . . . . .  20
     3.3.  Design Considerations for Authorization Solutions . . . .  21
     3.4.  Proxies . . . . . . . . . . . . . . . . . . . . . . . . .  22
   4.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  22
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  23
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   Constrained devices [RFC7228] are nodes with limited processing
   power, storage space and transmission capacities.  These devices are
   often battery-powered and in many cases do not provide user
   interfaces.

   Constrained devices benefit from being interconnected using Internet
   protocols.  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.

   This document comprises a collection of representative use cases for
   the application of authentication and authorization in constrained
   environments.  These use cases aim at identifying authorization
   problems that arise during the lifecycle of a constrained device.
   Note that this document does not aim at collecting all possible use
   cases.

   We assume that the communication between the devices is based on the
   Representational State Transfer (REST) architectural style, i.e. a
   device acts as a server that offers resources such as sensor data and
   actuators.  The resources can be accessed by clients, sometimes
   without human intervention (M2M).  In some situations the
   communication will happen through intermediaries (e.g. gateways,
   proxies).

   Where specific detail is necessary it is assumed that the devices
   communicate using CoAP [RFC7252], although most conclusions are
   generic.





Seitz, et al.          Expires September 10, 2015               [Page 3]


Internet-Draft                ACE use cases                   March 2015


1.1.  Terminology

   Readers are required to be familiar with the terms defined in
   [RFC7228].  In addition, this document uses the following
   terminology:

2.  Use Cases

   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.

   There are various reasons for assigning a function (client or server)
   to a device, e.g. which device initiates the conversation, how do
   devices find each other, etc.  The definition of the function of a
   device in a certain use case is not in scope of this document.
   Readers should be aware that there might be reasons for each setting
   and that endpoints might even have different functions at different
   times.

2.1.  Container monitoring

   The ability of sensors to communicate environmental data wirelessly
   opens up new application areas.  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.

   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.

   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.

   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.  The need for a constant monitoring of perishable
   goods has led to projects such as The Intelligent Container
   (http://www.intelligentcontainer.com).




Seitz, et al.          Expires September 10, 2015               [Page 4]


Internet-Draft                ACE use cases                   March 2015


2.1.1.  Bananas for Munich

   A fruit vendor grows bananas in Costa Rica for the German market.  It
   instructs a transport company to deliver the goods via ship to
   Rotterdam where they are picked up by trucks and transported to a
   ripening facility.  A Munich supermarket chain buys ripened bananas
   from the fruit vendor and transports them from the ripening facility
   to the individual markets with their own company trucks.

   The fruit vendor's quality management wants to assure the quality of
   their products and thus equips the banana boxes with sensors.  The
   state of the goods is monitored consistently during shipment and
   ripening and abnormal sensor values are recorded.  Additionally, the
   sensor values are used to control the climate within the cargo
   containers.  The sensors therefore need to communicate with the
   climate control system.  Since a wrong sensor value leads to a wrong
   temperature and thus to spoiled goods, the integrity of the sensor
   data must be assured.  The banana boxes within a container will in
   most cases belong to the same owner.  Adjacent containers might
   contain goods and sensors of different owners.

   The personnel that transloads the goods must be able to locate the
   goods meant for a specific customer.  However the fruit vendor does
   not want to disclose sensor information pertaining to the condition
   of the goods to other companies and therefore wants to assure the
   confidentiality of this data.  Thus, the transloading personnel is
   only allowed to access logistic information.  Moreover, the
   transloading personnel is only allowed to access the data for the
   time of the transloading.

   Due to the high water content of the fruits, the propagation of radio
   waves is hindered, thus often inhibiting direct communication between
   nodes [Jedermann14].  Instead, messages are forwarded over multiple
   hops.  The sensors in the banana boxes cannot always reach the
   Internet during the journey.

   In the ripening facility bananas are stored until they are ready for
   selling.  The banana box sensors are used to control the ventilation
   system and to monitor the degree of ripeness of the bananas.  Ripe
   bananas need to be identified and sold before they spoil.

   The supermarket chain gains ownership of the banana boxes when the
   bananas have ripened and are ready to leave the ripening facility.








Seitz, et al.          Expires September 10, 2015               [Page 5]


Internet-Draft                ACE use cases                   March 2015


2.1.2.  Authorization Problems Summary

   o  U1.1 Fruit vendors, transloading personnel and container owners
      want to grant different authorizations for their resources and/or
      endpoints to different parties.

   o  U1.2 The fruit vendor requires the integrity of the sensor data
      that pertains the state of the goods for climate control and to
      ensure the quality of the monitored recordings.

   o  U1.3 The container owner requires the integrity of the sensor data
      that is used for climate control.

   o  U1.4 The fruit vendor requires the confidentiality of the sensor
      data that pertains the state of the goods.

   o  U1.5 The fruit vendor may have several types of data that may be
      controlled by the same endpoint, e.g., sensor data and the data
      used for logistics.

   o  U1.6 The fruit vendor requires the confidentiality of the data
      that is used to locate the goods.

   o  U1.7 The fruit vendor requires the integrity of the data that is
      used to locate the goods.

   o  U1.8 The transloading personnel requires the integrity of the data
      that is used to locate the goods.

   o  U1.9 The container owner and the fruit vendor may not be present
      at the time of access and cannot manually intervene in the
      authorization process.

   o  U1.10 The fruit vendor, container owner and transloading company
      want to grant temporary access permissions to a party.

   o  U1.11 Messages between client and resource server might need to be
      forwarded over multiple hops.

   o  U1.12 The constrained devices might not always be able to reach
      the Internet.

2.2.  Home Automation

   Automation of the home has the potential to become a big future
   market for the Internet of Things.  A home automation system connects
   devices in a house to the Internet and thus makes them accessible and




Seitz, et al.          Expires September 10, 2015               [Page 6]


Internet-Draft                ACE use cases                   March 2015


   manageable remotely.  Such devices might control for example heating,
   ventilation, lighting, home entertainment or home security.

   Such a system needs to accommodate a number of regular users
   (inhabitants, close friends, cleaning personnel) as well as a
   heterogeneous group of dynamically varying users (visitors,
   repairmen, delivery men).

   As the users are not typically trained in security (or even computer
   use), the configuration must use secure default settings, and the
   interface must be well adapted to novice users.

2.2.1.  Controlling the Smart Home Infrastructure

   Alice and her husband Bob own a flat which is equipped with home
   automation devices such as HVAC and shutter control, and they have a
   motion sensor in the corridor which controls the light bulbs there.

   Alice and Bob can control the shutters and the temperature in each
   room using either wall-mounted touch panels or an internet connected
   device (e.g. a smartphone).  Since Alice and Bob both have a full-
   time job, they want to be able to change settings remotely, e.g. turn
   up the heating on a cold day if they will be home earlier than
   expected.

   The couple does not want people in radio range of their devices, e.g.
   their neighbors, to be able to control them without authorization.
   Moreover, they don't want burglars to be able to deduce behavioral
   patterns from eavesdropping on the network.

2.2.2.  Seamless Authorization

   Alice buys a new light bulb for the corridor and integrates it into
   the home network, i.e. makes resources known to other devices in the
   network.  Alice makes sure that the new light bulb and her other
   devices in the network get to know the authorization policies for the
   new device.  Bob is not at home, but Alice wants him to be able to
   control the new device with his devices (e.g. his smartphone) without
   the need for additional administration effort.  She provides the
   necessary configurations for that.

2.2.3.  Remotely letting in a visitor

   Alice and Bob have equipped their home with automated connected door-
   locks and an alarm system at the door and the windows.  The couple
   can control this system remotely.





Seitz, et al.          Expires September 10, 2015               [Page 7]


Internet-Draft                ACE use cases                   March 2015


   Alice and Bob have invited Alice's parents over for dinner, but are
   stuck in traffic and cannot arrive in time, while Alice's parents who
   use the subway will arrive punctually.  Alice calls her parents and
   offers to let them in remotely, so they can make themselves
   comfortable while waiting.  Then Alice sets temporary permissions
   that allow them to open the door, and shut down the alarm.  She wants
   these permissions to be only valid for the evening since she does not
   like it if her parents are able to enter the house as they see fit.

   When Alice's parents arrive at Alice's and Bob's home, they use their
   smartphone to communicate with the door-lock and alarm system.

2.2.4.  Authorization Problems Summary

   o  U2.1 A home owner (Alice and Bob in the example above) wants to
      spontaneously provision authorization means to visitors.

   o  U2.2 A home owner wants to spontaneously change the home's access
      control policies.

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

   o  U2.4 The home owners want to grant temporary access permissions to
      a party.

   o  U2.5 The smart home devices need to be able to communicate with
      different control devices (e.g. wall-mounted touch panels,
      smartphones, electronic key fobs).

   o  U2.6 The home owner wants to be able to configure authorization
      policies remotely.

   o  U2.7 Authorized Users want to be able to obtain access with little
      effort.

   o  U2.8 The owners of the automated home want to prevent unauthorized
      entities from being able to deduce behavioral profiles from
      devices in the home network.

   o  U2.9 Usability is particularly important in this scenario since
      the necessary authorization related tasks in the lifecycle of the
      device (commissioning, operation, maintenance and decommissioning)
      likely need to be performed by the home owners who in most cases
      have little knowledge of security.






Seitz, et al.          Expires September 10, 2015               [Page 8]


Internet-Draft                ACE use cases                   March 2015


   o  U2.10 Home Owners want their devices to seamlessly (and in some
      cases even unnoticeably) fulfill their purpose.  The
      administration effort needs to be kept at a minimum.

2.3.  Personal Health Monitoring

   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).  Personal health devices are typically battery
   driven, and located physically on 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.

   Medical data has always been considered as very sensitive, and
   therefore requires good protection against unauthorized disclosure.
   A frequent, conflicting requirement is the capability for medical
   personnel to gain emergency access, even if no specific access rights
   exist.  As a result, the importance of secure audit logs increases in
   such scenarios.

   Since the users are not typically trained in security (or even
   computer use), the configuration must use secure default settings,
   and the interface must be well adapted to novice users.  Parts of the
   system must operate with minimal maintenance.  Especially frequent
   changes of battery are unacceptable.

2.3.1.  John and the heart rate monitor

   John has a heart condition, that can result in sudden cardiac
   arrests.  He therefore uses a device called HeartGuard that monitors
   his heart rate and his position.  In case of a cardiac arrest it
   automatically sends an alarm to an emergency service, transmitting
   John's current location.  This requires the device to be close to a
   wireless access point, in order to be able to get an Internet
   connection (e.g.  John's smartphone).

   The device includes some authentication mechanism, in order to
   prevent other persons who get physical access to it from acting as
   the owner and messing up the access control and security settings.

   John can configure additional persons that get notified in an
   emergency, for example his daughter Jill.  Furthermore the device



Seitz, et al.          Expires September 10, 2015               [Page 9]


Internet-Draft                ACE use cases                   March 2015


   stores data on John's heart rate, which can later be accessed by a
   physician to assess the condition of John's heart.

   However John is a privacy conscious person, and is worried that Jill
   might use HeartGuard to monitor his location while there is no
   emergency.  Furthermore he doesn't want his health insurance to get
   access to the HeartGuard data, or even to the fact that he is wearing
   a HeartGuard, since they might refuse to renew his insurance if they
   decided he was too big a risk for them.

   Finally John, while being comfortable with modern technology and able
   to operate it reasonably well, is not trained in computer security.
   He therefore needs an interface for the configuration of the
   HeartGuard security that is easy to understand and use.  If John does
   not understand the meaning of a setting, he tends to leave it alone,
   assuming that the manufacturer has initialized the device to secure
   settings.

   NOTE: Monitoring of some state parameter (e.g. an alarm button) and
   the position of a person also fits well into an elderly care service.
   This is particularly useful for people suffering from dementia, where
   the relatives or caregivers need to be notified of the whereabouts of
   the person under certain conditions.  In this case it is not the
   patient that decides about access.

2.3.2.  Authorization Problems Summary

   o  U3.1 The wearer of an eHealth device (John in the example above)
      wants to pre-configure special access rights in the context of an
      emergency.

   o  U3.2 The wearer of an eHealth device wants to selectively allow
      different persons or groups access to medical data.

   o  U3.3 The Security measures could affect battery lifetime of the
      device and changing the battery is very inconvenient.

   o  U3.4 Devices are often used with default access control settings.

   o  U3.5 Wearers of eHealth devices are often not trained in computer
      use, and especially computer security.

   o  U3.6 Security mechanisms themselves could provide opportunities
      for denial of service attacks on the device.

   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.



Seitz, et al.          Expires September 10, 2015              [Page 10]


Internet-Draft                ACE use cases                   March 2015


2.4.  Building Automation

   Buildings for commercial use such as shopping malls or office
   buildings nowadays are equipped increasingly with semi-automatic
   components to enhance the overall living quality and to save energy
   where possible.  This includes for example heating, ventilation and
   air condition (HVAC) as well as illumination and security systems
   such as fire alarms.

   Different areas of these buildings are often exclusively leased to
   different companies.  However they also share some of the common
   areas of the building.  Accordingly, a company must be able to
   control the light and HVAC system of its own part of the building and
   must not have access to control rooms that belong to other companies.

   Some parts of the building automation system such as entrance
   illumination and fire alarm systems are controlled either by all
   parties together or by a service company.

2.4.1.  Device Lifecycle

2.4.1.1.  Installation and Commissioning

   A building is hired out to different companies for office space.
   This building features various automated systems, such as a fire
   alarm system, which is triggered by several smoke detectors which are
   spread out across the building.  It also has automated HVAC, lighting
   and physical access control systems.

   A vacant area of the building has been recently leased to company A.
   Before moving into its new office, Company A wishes to replace the
   lighting with a more energy efficient and a better light quality
   luminaries.  They hire an installation and commissioning company C to
   redo the illumination.  Company C is instructed to integrate the new
   lighting devices, which may be from multiple manufacturers, into the
   existing lighting infrastructure of the building which includes
   presence sensors, switches, controllers etc.

   Company C gets the necessary authorization from the service company
   to interact with the existing Building and Lighting Management System
   (BLMS).  To prevent disturbance to other occupants of the building,
   Company C is provided authorization to perform the commissioning only
   during non-office hours and only to modify configuration on devices
   belonging to the domain of Company A's space.  After installation
   (wiring) of the new lighting devices, the commissioner adds the
   devices into the company A's lighting domain.





Seitz, et al.          Expires September 10, 2015              [Page 11]


Internet-Draft                ACE use cases                   March 2015


   Once the devices are in the correct domain, the commissioner
   authorizes the interaction rules between the new lighting devices and
   existing devices like presence sensors.  For this, the commissioner
   creates the authorization rules on the BLMS which define which lights
   form a group and which sensors/switches/controllers are allowed to
   control which groups.  These authorization rules may be context based
   like time of the day (office or non-office hours) or location of the
   handheld lighting controller etc.

2.4.1.2.  Operational

   Company A's staff move into the newly furnished office space.  Most
   lighting is controlled by presence sensors which control the lighting
   of specific group of lights based on the authorization rules in the
   BLMS.  Additionally employees are allowed to manually override the
   lighting brightness and color in their office by using the switches
   or handheld controllers.  Such changes are allowed only if the
   authorization rules exist in the BLMS.  For example lighting in the
   corridors may not be manually adjustable.

   At the end of the day, lighting is dimmed down or switched off if no
   occupancy is detected even if manually overridden during the day.

   On a later date company B also moves into the same building, and
   shares some of the common spaces with company A.  On a really hot day
   James who works for company A turns on the air condition in his
   office.  Lucy who works for company B wants to make tea using an
   electric kettle.  After she turned it on she goes outside to talk to
   a colleague until the water is boiling.  Unfortunately, her kettle
   has a malfunction which causes overheating and results in a
   smoldering fire of the kettle's plastic case.

   Due to the smoke coming from the kettle the fire alarm is triggered.
   Alarm sirens throughout the building are switched on simultaneously
   (using a broadcast or multicast) to alert the staff of both
   companies.  Additionally, the ventilation system of the whole
   building is closed off to prevent the smoke from spreading and to
   withdraw oxygen from the fire.  The smoke cannot get into James'
   office although he turned on his air condition because the fire alarm
   overrides the manual setting by sending commands (broadcast or
   multicast) to switch off all the air conditioning.

   The fire department is notified of the fire automatically and arrives
   within a short time.  After inspecting the damage and extinguishing
   the smoldering fire a fire fighter resets the fire alarm because only
   the fire department is authorized to do that.





Seitz, et al.          Expires September 10, 2015              [Page 12]


Internet-Draft                ACE use cases                   March 2015


2.4.1.3.  Maintenance

   Company A's staff are annoyed that the lights switch off too often in
   their rooms if they work silently in front of their computer.
   Company A notifies the commissioning Company C about the issue and
   asks them to increase the delay before lights switch off.

   Company C again gets the necessary authorization from the service
   company to interact with the BLMS.  The commissioner's tool gets the
   necessary authorization from BMLS to send a configuration change to
   all lighting devices in Company A's offices to increase their delay
   before they switch off.

2.4.1.4.  Decommissioning

   Company A has noticed that the handheld controllers are often
   misplaced and hard to find when needed.  So most of the time staff
   use the existing wall switches for manual control.  Company A decides
   it would be better to completely remove handheld controllers and asks
   Company C to decommission them from the lighting system.

   Company C again gets the necessary authorization from the service
   company to interact with the BLMS.  The commissioner now deletes any
   rules that allowed handheld controllers authorization to control the
   lighting.  Additionally the commissioner instructs the BLMS to push
   these new rules to prevent cached rules at the end devices from being
   used.

2.4.2.  Authorization Problems Summary

   o  U4.1 The building owner and the companies want to be able to add
      new devices to their administrative domain (commissioning).

   o  U4.2 The building owner and the companies want to be able to
      integrate a device that formerly belonged to a different
      administrative domain to their own administrative domain
      (handover).

   o  U4.3 The building owner and the companies want to be able to
      remove a device from their administrative domain (decomissioning).

   o  U4.4 The building owner and the companies want to be able to
      delegate selected administration tasks for their devices to
      others.

   o  U4.5 The building owner and the companies want to be able to
      define context-based authorization rules.




Seitz, et al.          Expires September 10, 2015              [Page 13]


Internet-Draft                ACE use cases                   March 2015


   o  U4.6 The building owner and the companies want to be able to
      revoke granted permissions and delegations.

   o  U4.7 The building owner and the companies want to allow authorized
      entities to send data to their endpoints (default deny).

   o  U4.8 The building owner and the companies want to be able to
      authorize a device to control several devices at the same time
      using a multicast protocol.

   o  U4.9 The companies want to be able to interconnect their own
      subsystems with those from a different operational domain while
      keeping the control over the authorizations (e.g. granting and
      revoking permissions) for their endpoints and devices.

2.5.  Smart Metering

   Automated measuring of customer consumption is an established
   technology for electricity, water, and gas providers.  Increasingly
   these systems also feature networking capability to allow for remote
   management.  Such systems are in use for commercial, industrial and
   residential customers and require a certain level of security, in
   order to avoid economic loss to the providers, vulnerability of the
   distribution system, as well as disruption of services for the
   customers.

   The smart metering equipment for gas and water solutions is battery
   driven and communication should be used sparingly due to battery
   consumption.  Therefore the types of meters sleep most of the time,
   and only wake up every minute/hour to check for incoming
   instructions.  Furthermore they wake up a few times a day (based on
   their configuration) to upload their measured metering data.

   Different networking topologies exist for smart metering solutions.
   Based on environment, regulatory rules and expected cost, one or a
   mixture of these topologies may be deployed to collect the metering
   information.  Drive-By metering is one of the most current solutions
   deployed for collection of gas and water meters.

2.5.1.  Drive-by metering

   A service operator offers smart metering infrastructures and related
   services to various utility companies.  Among these is a water
   provider, who in turn supplies several residential complexes in a
   city.  The smart meters are installed in the end customer's homes to
   measure water consumption and thus generate billing data for the
   utility company.  The meters do so by sending data to a base station.
   Several base stations are installed around the city to collect the



Seitz, et al.          Expires September 10, 2015              [Page 14]


Internet-Draft                ACE use cases                   March 2015


   metering data.  However in the denser urban areas, the base stations
   would have to be installed very close to the meters.  This would
   require a high number of base stations and expose this more expensive
   equipment to manipulation or sabotage.  The service operator has
   therefore chosen another approach, which is to drive around with a
   mobile base-station and let the meters connect to that in regular
   intervals in order to gather metering data.

2.5.2.  Meshed Topology

   In another deployment, the water meters are installed in a building
   that already has power meters installed, the latter are mains
   powered, and are therefore not subject to the same power saving
   restrictions.  The water meters can therefore use the power meters as
   proxies, in order to achieve better connectivity.  This requires the
   security measures on the water meters to work through intermediaries.

2.5.3.  Advanced Metering Infrastructure

   A utility company is updating its old utility distribution network
   with advanced meters and new communication systems, known as an
   Advanced Metering Infrastructure (AMI).  AMI refers to a system that
   measures, collects and analyzes usage, and interacts with metering
   devices such as electricity meters, gas meters, heat meters, and
   water meters, through various communication media either on request
   (on-demand) or on pre-defined schedules.  Based on this technology,
   new services make it possible for consumers to control their utility
   consumption and reduce costs by supporting new tariff models from
   utility companies, and more accurate and timely billing.

   The technical solution is based on levels of data aggregation between
   smart meters located at the consumer premises and the Meter Data
   Management (MDM) system located at the utility company.  Two possible
   intermediate levels are:

   o  Head-End System (HES) which is hardware and software that receives
      the stream of meter data and exposes an interface to the MDM.

   o  Data Collection (DC) units located in a local network
      communicating with a number of smart meters and with a backhaul
      interface communicating with the HES, e.g. using cellular
      communication.

   For reasons of efficiency and cost end-to-end connectivity is not
   always feasible, so metering data is stored in batches in DC for some
   time before being forwarded to the HES, and in turn accessed by the
   MDM.  The HES and the DC units may be operated by a third party
   service operator on behalf of the utility company.  One



Seitz, et al.          Expires September 10, 2015              [Page 15]


Internet-Draft                ACE use cases                   March 2015


   responsibility of the service operator is to make sure that meter
   readings are performed and delivered to the HES.  An example of a
   Service Level Agreement between the service operator and the utility
   company is e.g.  "at least 95 % of the meters have readings recorded
   during the last 72 hours".

2.5.4.  Authorization Problems Summary

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

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

   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.

   o  U5.4 The devices may have intermittent Internet connectivity.

   o  U5.5 Neither the service operator nor the utility company are
      always present at the time of access and cannot manually intervene
      in the authorization process.

   o  U5.6 When authorization policies are updated it is impossible, or
      at least very inefficient to contact all affected endpoints
      directly.

   o  U5.7 Messages between endpoints may need to be stored and
      forwarded over multiple nodes.

2.6.  Sports and Entertainment

   In the area of leisure time activities, applications can benefit from
   the small size and weight of constrained devices.  Sensors and
   actuators with various functionalities can be integrated into fitness
   equipment, games and even clothes.  Users can carry their devices
   around with them at all times.

   Usability is especially important in this area since users will often
   want to spontaneously interconnect their devices with others.
   Therefore the configuration of access permissions must be simple and
   fast and not require much effort at the time of access (preferably
   none at all).




Seitz, et al.          Expires September 10, 2015              [Page 16]


Internet-Draft                ACE use cases                   March 2015


   The required level of security will in most cases be low since
   security breaches will likely have less severe consequences.  The
   continuous monitoring of data might however enable an attacker to
   create behavioral or movement profiles.  Moreover, the aggregation of
   data can seriously increase the impact on the privacy of the users.

2.6.1.  Dynamically Connecting Smart Sports Equipment

   Jody is a an enthusiastic runner.  To keep track of her training
   progress, she has smart running shoes that measure the pressure at
   various points beneath her feet to count her steps, detect
   irregularities in her stride and help her to improve her posture and
   running style.  On a sunny afternoon, she goes to the Finnbahn track
   near her home to work out.  She meets her friend Lynn who shows her
   the smart fitness watch she bought a few days ago.  The watch can
   measure the wearer's pulse, show speed and distance, and keep track
   of the configured training program.  The girls detect that the watch
   can be connected with Jody's shoes and then can additionally display
   the information the shoes provide.

   Jody asks Lynn to let her try the watch and lend it to her for the
   afternoon.  Lynn agrees but doesn't want Jody to access her training
   plan.  She configures the access policies for the watch so that
   Jody's shoes are allowed to access the display and measuring features
   but cannot read or add training data.  Jody's shoes connect to Lynn's
   watch after only a press of a button because Jody already configured
   access rights for devices that belong to Lynn a while ago.

   After an hour, Jody gives the watch back and both girls terminate the
   connection between their devices.

2.6.2.  Authorization Problems Summary

   o  U6.1 Sports equipment owners want to be able to grant access
      rights dynamically when needed.

   o  U6.2 Sports equipment owners want the configuration of access
      rights to work with very little effort.

   o  U6.3 Sports equipment owners want to be able to preconfigure
      access policies that grant certain access permissions to endpoints
      with certain attributes (e.g. endpoints of a certain user) without
      additional configuration effort at the time of access.

   o  U6.4 Sports equipment owners to protect the confidentiality of
      their data for privacy reasons.





Seitz, et al.          Expires September 10, 2015              [Page 17]


Internet-Draft                ACE use cases                   March 2015


   o  U6.5 Devices might not have an Internet connection at the time of
      access.

2.7.  Industrial Control Systems

   Industrial control systems (ICS) and especially supervisory control
   and data acquisition systems (SCADA) use a multitude of sensors and
   actuators in order to monitor and control industrial processes in the
   physical world.  Example processes include manufacturing, power
   generation, and refining of raw materials.

   Since the advent of the Stuxnet worm it has become obvious to the
   general public how vulnerable this kind of systems are, especially
   when connected to the Internet.  The severity of these
   vulnerabilities are exacerbated by the fact that many ICS are used to
   control critical public infrastructure, such as power, water
   treatment of traffic control.  Nevertheless the economical advantages
   of connecting such systems to the Internet can be significant if
   appropriate security measures are put in place.

2.7.1.  Oil Platform Control

   An oil platform uses an industrial control system to monitor data and
   control equipment.  The purpose of this system is to gather and
   process data from a large number of sensors, and control actuators
   such as valves and switches to steer the oil extraction process on
   the platform.  Raw data, alarms, reports and other information are
   also available to the operators, who can intervene with manual
   commands.  Many of the sensors are connected to the controlling units
   by direct wire, but the operator is slowly replacing these units by
   wireless ones, since this makes maintenance easier.

   The controlling units are connected to the Internet, to allow for
   remote administration, since it is expensive and inconvenient to fly
   in a technician to the platform.

   The main interest of the operator is to ensure the integrity of
   control messages and sensor readings.  Access in some cases needs to
   be restricted, e.g. the operator wants wireless actuators only to
   accept commands by authorized control units.

   The owner of the platform also wants to collect auditing information
   for liability reasons.








Seitz, et al.          Expires September 10, 2015              [Page 18]


Internet-Draft                ACE use cases                   March 2015


2.7.2.  Authorization Problems Summary

   o  U7.1 The operator of the platform wants to ensure the
      confidentiality of sensor data and the integrity of actuator data.

   o  U7.2 The operator wants to ensure that data coming from sensors
      and commands sent to actuators are authentic.

   o  U7.3 Some devices do not have direct Internet connection.

   o  U7.4 Some devices have wired connection while others use wireless.

   o  U7.5 The execution of unauthorized commands in an ICS can lead to
      significant financial damage, and threaten the availability of
      critical infrastructure services.  Accordingly, the operator wants
      a security solution that provides a very high level of security.

3.  Security Considerations

   As the use cases listed in this document demonstrate, constrained
   devices are used in various application areas.  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, 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.

   Not only the data on the constrained devices themselves is
   threatened, the devices might also be abused as an intrusion point to
   infiltrate a network.  Once an attacker gained control over the
   device, it can be used to attack other devices as well.  Due to their
   limited capabilities, constrained devices appear as the weakest link
   in the network and hence pose an attractive target for attackers.

   This section summarizes the security problems highlighted by the use
   cases above and provides guidelines for the design of protocols for
   authentication and authorization in constrained RESTful environments.

3.1.  Attacks

   This document lists security problems that users of constrained
   devices want to solve.  Further analysis of attack scenarios is not
   in scope of the document.  However, there are attacks that must be
   considered by solution developers.





Seitz, et al.          Expires September 10, 2015              [Page 19]


Internet-Draft                ACE use cases                   March 2015


   Because of the expected large number of devices and their ubiquity,
   constrained devices increase the danger from Pervasive Monitoring
   [RFC7258] attacks.

   As some of the use cases indicate, constrained devices may be
   installed in hostile environments where they are physically
   accessible (see Section 2.5).  Protection from physical attacks is
   not in the scope of ACE, but should be kept in mind by developers of
   authorization solutions.

   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:

   o  Battery usage

   o  Number of message exchanges required by security measures

   o  Size of data that is transmitted (e.g. authentication and access
      control data)

   o  Size of code required to run the protocol

   o  Size of RAM memory and stack required to run the protocol

   Another category of attacks that needs to be considered by solution
   developers is session interception and hijacking.

3.2.  Configuration of Access Permissions

   o  The access control policies need to be enforced (all use cases):
      The information that is needed to implement the access control
      policies needs to be provided to the device that enforces the
      authorization and applied to every incoming request.

   o  A single resource might have different access rights for different
      requesting entities (all use cases).





Seitz, et al.          Expires September 10, 2015              [Page 20]


Internet-Draft                ACE use cases                   March 2015


      Rationale: In some cases different types of users need different
      access rights, as opposed to a binary approach where the same
      access permissions are granted to all authenticated users.

   o  A device might host several resources where each resource has its
      own access control policy (all use cases).

   o  The device that makes the policy decisions should be able to
      evaluate context-based permissions such as location or time of
      access (see e.g.  Section 2.2, Section 2.3, Section 2.4).  Access
      may depend on local conditions, e.g. access to health data in an
      emergency.  The device that makes the policy decisions should be
      able to take such conditions into account.

3.3.  Design Considerations for Authorization Solutions

   o  Devices need to be enabled to enforce authorization policies
      without human intervention at the time of the access request (see
      e.g.  Section 2.1, Section 2.2, Section 2.4, Section 2.5).

   o  Authorization solutions need to consider that constrained devices
      might not have internet access at the time of the access request
      (see e.g.  Section 2.1, Section 2.3, Section 2.5, Section 2.6).

   o  It should be possible to update access control policies without
      manually re-provisioning individual devices (see e.g.
      Section 2.2, Section 2.3, Section 2.5, Section 2.6).

      Rationale: Peers can change rapidly which makes manual re-
      provisioning unreasonably expensive.

   o  Authorization policies may be defined to apply to a large number
      of devices that might only have intermittent connectivity.
      Distributing policy updates to every device for every update might
      not be a feasible solution (see e.g.  Section 2.5).

   o  It must be possible to dynamically revoke authorizations (see e.g.
      Section 2.4).

   o  The authentication and access control protocol can put undue
      burden on the constrained system resources of a device
      participating in the protocol.  An authorization solutions must
      take the limitations of the constrained devices into account (all
      use cases, see also Section 3.1).

   o  Secure default settings are needed for the initial state of the
      authentication and authorization protocols (all use cases).




Seitz, et al.          Expires September 10, 2015              [Page 21]


Internet-Draft                ACE use cases                   March 2015


      Rationale: Many attacks exploit insecure default settings, and
      experience shows that default settings are frequently left
      unchanged by the end users.

   o  Access to resources on other devices should only be permitted if a
      rule exists that explicitly allows this access (default deny) (see
      e.g.  Section 2.4).

   o  Usability is important for all use cases.  The configuration of
      authorization policies as well as the gaining access to devices
      must be simple for the users of the devices.  Special care needs
      to be taken for home scenarios where access control policies have
      to be configured by users that are typically not trained in
      security (see Section 2.2, Section 2.3, Section 2.6).

3.4.  Proxies

   In some cases, the traffic between endpoints might go through
   intermediary nodes (e.g. proxies, gateways).  This might affect the
   function or the security model of authentication and access control
   protocols e.g. end-to-end security between endpoints with DTLS might
   not be possible (see Section 2.5).

4.  Privacy Considerations

   Many of the devices that are in focus of this document register data
   from the physical world (sensors) or affect processes in the physical
   world (actuators), which may involve data or processes belonging to
   individuals.  To make matters worse the sensor data may be recorded
   continuously thus allowing to gather significant information about an
   individual subject through the sensor readings.  Therefore privacy
   protection is especially important, and Authentication and Access
   control are important tools for this, since they make it possible to
   control who gets access to private data.

   Privacy protection can also be weighted in when evaluating the need
   for end-to-end confidentiality, since otherwise intermediary nodes
   will learn the content of potentially sensitive messages sent between
   endpoints and thereby threaten the privacy of the individual that may
   be subject of this data.

   In some cases, even the possession of a certain type of device can be
   confidential, e.g. individuals might not want to others to know that
   they are wearing a certain medical device (see Section 2.3).

   The personal health monitoring use case (see Section 2.3) indicates
   the need for secure audit logs which impose specific requirements on
   a solution.  Auditing is not in the scope of ACE.  However, if an



Seitz, et al.          Expires September 10, 2015              [Page 22]


Internet-Draft                ACE use cases                   March 2015


   authorization solution provides means for audit logs, it must
   consider the impact of logged data for the privacy of all parties
   involved.  Suitable measures for protecting and purging the logs must
   be taken during operation, maintenance and decommissioning of the
   device.

5.  Acknowledgments

   The authors would like to thank Olaf Bergmann, Sumit Singhal, John
   Mattson, Mohit Sethi, Carsten Bormann, Martin Murillo, Corinna
   Schmitt, Hannes Tschofenig, Erik Wahlstroem, and Andreas Backman for
   reviewing and/or contributing to the document.  Also, thanks to
   Markus Becker, Thomas Poetsch and Koojana Kuladinithi for their input
   on the container monitoring use case.

   Ludwig Seitz and Goeran Selander worked on this document as part of
   EIT-ICT Labs activity PST-14056.

6.  IANA Considerations

   This document has no IANA actions.

7.  Informative References

   [Jedermann14]
              Jedermann, R., Poetsch, T., and C. LLoyd, "Communication
              techniques and challenges for wireless food quality
              monitoring", Philosophical Transactions of the Royal
              Society A Mathematical, Physical and Engineering Sciences,
              May 2014.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228, May 2014.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, June 2014.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, May 2014.

Authors' Addresses







Seitz, et al.          Expires September 10, 2015              [Page 23]


Internet-Draft                ACE use cases                   March 2015


   Ludwig Seitz (editor)
   SICS Swedish ICT AB
   Scheelevaegen 17
   Lund  223 70
   Sweden

   Email: ludwig@sics.se


   Stefanie Gerdes (editor)
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  28359
   Germany

   Phone: +49-421-218-63906
   Email: gerdes@tzi.org


   Goeran Selander
   Ericsson
   Faroegatan 6
   Kista  164 80
   Sweden

   Email: goran.selander@ericsson.com


   Mehdi Mani
   Itron
   52, rue Camille Desmoulins
   Issy-les-Moulineaux  92130
   France

   Email: Mehdi.Mani@itron.com


   Sandeep S. Kumar
   Philips Research
   High Tech Campus
   Eindhoven  5656 AA
   The Netherlands

   Email: sandeep.kumar@philips.com







Seitz, et al.          Expires September 10, 2015              [Page 24]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/