One document matched: draft-ietf-ace-usecases-03.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.22 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY SELF "[RFC-XXXX]">
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-ietf-ace-usecases-03" category="info">

  <front>
    <title abbrev="ACE use cases">ACE use cases</title>

    <author initials="L." surname="Seitz" fullname="Ludwig Seitz" role="editor">
      <organization>SICS Swedish ICT AB</organization>
      <address>
        <postal>
          <street>Scheelevägen 17</street>
          <city>Lund</city>
          <code>223 70</code>
          <country>Sweden</country>
        </postal>
        <email>ludwig@sics.se</email>
      </address>
    </author>
    <author initials="S." surname="Gerdes" fullname="Stefanie Gerdes" role="editor">
      <organization>Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63906</phone>
        <email>gerdes@tzi.org</email>
      </address>
    </author>
    <author initials="G." surname="Selander" fullname="Göran Selander">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Farögatan 6</street>
          <city>Kista</city>
          <code>164 80</code>
          <country>Sweden</country>
        </postal>
        <email>goran.selander@ericsson.com</email>
      </address>
    </author>
    <author initials="M." surname="Mani" fullname="Mehdi Mani">
      <organization>Itron</organization>
      <address>
        <postal>
          <street>52, rue Camille Desmoulins</street>
          <city>Issy-les-Moulineaux</city>
          <code>92130</code>
          <country>France</country>
        </postal>
        <email>Mehdi.Mani@itron.com</email>
      </address>
    </author>
    <author initials="S." surname="Kumar" fullname="Sandeep S. Kumar">
      <organization>Philips Research</organization>
      <address>
        <postal>
          <street>High Tech Campus</street>
          <city>Eindhoven</city>
          <code>5656 AA</code>
          <country>The Netherlands</country>
        </postal>
        <email>sandeep.kumar@philips.com</email>
      </address>
    </author>

    <date year="2015" month="March" day="09"/>

    <area>Applications</area>
    <workgroup>ACE Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>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.</t>

<t>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.</t>

<t>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.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>Constrained devices <xref target="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.</t>

<t>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.</t>

<t>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.</t>

<t>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).</t>

<t>Where specific detail is necessary it is assumed that the devices communicate
using CoAP <xref target="RFC7252"/>, although most conclusions are generic.</t>

<section anchor="terminology" title="Terminology">

<t>Readers are required to be familiar with the terms defined in
<xref target="RFC7228"/>.  In addition, this document uses the following terminology:</t>

</section>
</section>
<section anchor="use-cases" title="Use Cases">

<t>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.</t>

<t>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.</t>

<section anchor="container_monitoring" title="Container monitoring">

<t>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.</t>

<t>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.</t>

<t>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.</t>

<t>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).</t>

<section anchor="bananas-for-munich" title="Bananas for Munich">

<t>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.</t>

<t>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.</t>

<t>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.</t>

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

<t>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.</t>

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

</section>
<section anchor="authorization-problems-summary" title="Authorization Problems Summary">

<t><list style="symbols">
  <t>U1.1 Fruit vendors, transloading personnel and container owners want
to grant different authorizations for their resources and/or
endpoints to different parties.</t>
  <t>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.</t>
  <t>U1.3 The container owner requires the integrity of the sensor data
that is used for climate control.</t>
  <t>U1.4 The fruit vendor requires the confidentiality of the sensor
data that pertains the state of the goods.</t>
  <t>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.</t>
  <t>U1.6 The fruit vendor requires the confidentiality of the data that
is used to locate the goods.</t>
  <t>U1.7 The fruit vendor requires the integrity of the data that is
used to locate the goods.</t>
  <t>U1.8 The transloading personnel requires the integrity of the data
that is used to locate the goods.</t>
  <t>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.</t>
  <t>U1.10 The fruit vendor, container owner and transloading company
want to grant temporary access permissions to a party.</t>
  <t>U1.11 Messages between client and resource server might need to be
forwarded over multiple hops.</t>
  <t>U1.12 The constrained devices might not always be able to reach the
Internet.</t>
</list></t>

</section>
</section>
<section anchor="home_automation" title="Home Automation">

<t>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 manageable remotely. 
Such devices might control for example heating, ventilation, lighting, home
entertainment or home security.</t>

<t>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).</t>

<t>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.</t>

<section anchor="controlling-the-smart-home-infrastructure" title="Controlling the Smart Home Infrastructure">

<t>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.</t>

<t>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.</t>

<t>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.</t>

</section>
<section anchor="seamless-authorization" title="Seamless Authorization">

<t>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.</t>

</section>
<section anchor="remotely-letting-in-a-visitor" title="Remotely letting in a visitor">

<t>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.</t>

<t>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.</t>

<t>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.</t>

</section>
<section anchor="authorization-problems-summary-1" title="Authorization Problems Summary">

<t><list style="symbols">
  <t>U2.1 A home owner (Alice and Bob in the example above) wants to
  spontaneously provision authorization means to visitors.</t>
  <t>U2.2 A home owner wants to spontaneously change the home’s access control 
  policies.</t>
  <t>U2.3 A home owner wants to apply different access rights for different users.</t>
  <t>U2.4 The home owners want to grant temporary access permissions to
 a party.</t>
  <t>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).</t>
  <t>U2.6 The home owner wants to be able to configure authorization
policies remotely.</t>
  <t>U2.7 Authorized Users want to be able to obtain access with little effort.</t>
  <t>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.</t>
  <t>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.</t>
  <t>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.</t>
</list></t>

</section>
</section>
<section anchor="eHealth" title="Personal Health Monitoring">

<t>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.</t>

<t>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. </t>

<t>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.</t>

<section anchor="john-and-the-heart-rate-monitor" title="John and the heart rate monitor">

<t>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).</t>

<t>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.</t>

<t>John can configure additional persons that get notified in an emergency, for
example his daughter Jill.  Furthermore the device stores data on John’s heart 
rate, which can later be accessed by a physician to assess the condition
of John’s heart.</t>

<t>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.</t>

<t>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.</t>

<t>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.</t>

</section>
<section anchor="authorization-problems-summary-2" title="Authorization Problems Summary">

<t><list style="symbols">
  <t>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.</t>
  <t>U3.2 The wearer of an eHealth device wants to selectively allow
different persons or groups access to medical data.</t>
  <t>U3.3 The Security measures could affect battery lifetime of the
device and changing the battery is very inconvenient.</t>
  <t>U3.4 Devices are often used with default access control settings.</t>
  <t>U3.5 Wearers of eHealth devices are often not trained in computer
use, and especially computer security.</t>
  <t>U3.6 Security mechanisms themselves could provide opportunities for
denial of service attacks on the device.</t>
  <t>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.</t>
</list></t>

</section>
</section>
<section anchor="building_automation" title="Building Automation">

<t>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.</t>

<t>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.</t>

<t>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.</t>

<section anchor="device-lifecycle" title="Device Lifecycle">

<section anchor="installation-and-commissioning" title="Installation and Commissioning">

<t>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.</t>

<t>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. </t>

<t>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.</t>

<t>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. </t>

</section>
<section anchor="operational" title="Operational">

<t>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. </t>

<t>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.</t>

<t>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.</t>

<t>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.</t>

<t>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.</t>

</section>
<section anchor="maintenance" title="Maintenance">

<t>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.</t>

<t>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. </t>

</section>
<section anchor="decommissioning" title="Decommissioning">

<t>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.</t>

<t>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. </t>

</section>
</section>
<section anchor="authorization-problems-summary-3" title="Authorization Problems Summary">

<t><list style="symbols">
  <t>U4.1 The building owner and the companies want to be able to add new
devices to their administrative domain (commissioning).</t>
  <t>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).</t>
  <t>U4.3 The building owner and the companies want to be able to remove
a device from their administrative domain (decomissioning).</t>
  <t>U4.4 The building owner and the companies want to be able to
delegate selected administration tasks for their devices to others.</t>
  <t>U4.5 The building owner and the companies want to be able to define
context-based authorization rules.</t>
  <t>U4.6 The building owner and the companies want to be able to revoke
granted permissions and delegations.</t>
  <t>U4.7 The building owner and the companies want to allow authorized
entities to send data to their endpoints (default deny).</t>
  <t>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.</t>
  <t>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.</t>
</list></t>

</section>
</section>
<section anchor="smart_metering" title="Smart Metering">

<t>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.</t>

<t>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.</t>

<t>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.</t>

<section anchor="drive-by-metering" title="Drive-by metering">

<t>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 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.</t>

</section>
<section anchor="meshed-topology" title="Meshed Topology">

<t>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.</t>

</section>
<section anchor="advanced-metering-infrastructure" title="Advanced Metering Infrastructure">

<t>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.</t>

<t>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:</t>

<t><list style="symbols">
  <t>Head-End System (HES) which is hardware and software that receives the 
stream of meter data and exposes an interface to the MDM.</t>
  <t>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.</t>
</list></t>

<t>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 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”.</t>

</section>
<section anchor="authorization-problems-summary-4" title="Authorization Problems Summary">

<t><list style="symbols">
  <t>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.</t>
  <t>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.	</t>
  <t>U5.3  The utility company wants to control which entities are allowed to 
  read data on their endpoints and protect such data in transfer.</t>
  <t>U5.4  The devices may have intermittent Internet connectivity.</t>
  <t>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.</t>
  <t>U5.6  When authorization policies are updated it is impossible, or at least
  very inefficient to contact all affected endpoints directly.</t>
  <t>U5.7 Messages between endpoints may need to be stored
  and forwarded over multiple nodes.</t>
</list></t>

</section>
</section>
<section anchor="sports_and_entertainment" title="Sports and Entertainment">

<t>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.</t>

<t>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).</t>

<t>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.</t>

<section anchor="dynamically-connecting-smart-sports-equipment" title="Dynamically Connecting Smart Sports Equipment">

<t>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.</t>

<t>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.</t>

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

</section>
<section anchor="authorization-problems-summary-5" title="Authorization Problems Summary">

<t><list style="symbols">
  <t>U6.1 Sports equipment owners want to be able to grant access rights
dynamically when needed.</t>
  <t>U6.2 Sports equipment owners want the configuration of access rights 
to work with very little effort.</t>
  <t>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.</t>
  <t>U6.4 Sports equipment owners to protect the confidentiality of their
data for privacy reasons.</t>
  <t>U6.5 Devices might not have an Internet connection at the time of
access.</t>
</list></t>

</section>
</section>
<section anchor="ICS" title="Industrial Control Systems">

<t>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.</t>

<t>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.</t>

<section anchor="oil-platform-control" title="Oil Platform Control">

<t>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.</t>

<t>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.</t>

<t>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.</t>

<t>The owner of the platform also wants to collect auditing information for 
liability reasons.</t>

</section>
<section anchor="authorization-problems-summary-6" title="Authorization Problems Summary">

<t><list style="symbols">
  <t>U7.1 The operator of the platform wants to ensure the
confidentiality of sensor data and the integrity of actuator data.</t>
  <t>U7.2 The operator wants to ensure that data coming from sensors and
commands sent to actuators are authentic.</t>
  <t>U7.3 Some devices do not have direct Internet connection.</t>
  <t>U7.4 Some devices have wired connection while others use wireless.</t>
  <t>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.</t>
</list></t>

</section>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>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.</t>

<t>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.</t>

<t>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.</t>

<section anchor="attacks" title="Attacks">

<t>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.</t>

<t>Because of the expected large number of devices and their
ubiquity, constrained devices increase the danger from Pervasive
Monitoring <xref target="RFC7258"/> attacks.</t>

<t>As some of the use cases indicate, constrained devices may be
installed in hostile environments where they are physically accessible
(see <xref target="smart_metering"/>).  Protection from physical attacks is not in
the scope of ACE, but should be kept in mind by developers of
authorization solutions.</t>

<t>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) <xref target="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 <xref target="eHealth"/>).  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:</t>

<t><list style="symbols">
  <t>Battery usage</t>
  <t>Number of message exchanges required by security measures</t>
  <t>Size of data that is transmitted (e.g. authentication and access
control data)</t>
  <t>Size of code required to run the protocol</t>
  <t>Size of RAM memory and stack required to run the protocol</t>
</list></t>

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

<t><!-- * Interoperability (U1.1, U2.5, U4.6) --></t>

<t><!-- 	Rationale: Resource Owners may interact with Clients from various -->
  <!-- 	manufacturers and vice-versa.  For the overall system to function  -->
  <!-- 	correctly the authentication and access control mechanisms need to  -->
  <!-- 	work consistently.  This is best achieved by standardization.  --></t>

<!-- ## Authentication Problems -->

<!--   * Standardized provisioning of authentication means to Clients and Resource  -->
<!-- 	Servers (U2.1, U4.1, U4.7) -->
<!--       - Remote provisioning might be needed -->

<!--   * Remote revocation of authentication means (U4.9, U5.4)  -->

</section>
<section anchor="configuration-of-access-permissions" title="Configuration of Access Permissions">

<t><list style="symbols">
  <t>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.</t>
  <t>A single resource might have different access rights for different
requesting entities (all use cases).  <vspace blankLines='1'/>
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.</t>
</list></t>

<!-- (U1.1, U1.2, U2.3, U3.1, U3.2, U3.3, U5.2) -->

<t><list style="symbols">
  <t>A device might host several resources where each resource has its
own access control policy (all use cases).</t>
  <t>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. <xref target="home_automation"/>, <xref target="eHealth"/>, <xref target="building_automation"/>).
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.</t>
</list></t>

<!-- (U2.4, U3.1, U4.2) -->

</section>
<section anchor="design-considerations-for-authorization-solutions" title="Design Considerations for Authorization Solutions">

<t><list style="symbols">
  <t>Devices need to be enabled to enforce authorization
policies without human intervention at the time of the access
request (see e.g. <xref target="container_monitoring"/>, <xref target="home_automation"/>,
<xref target="building_automation"/>, <xref target="smart_metering"/>).</t>
  <t>Authorization solutions need to consider that constrained devices
might not have internet access at the time of the access request
(see e.g. <xref target="container_monitoring"/>, <xref target="eHealth"/>, <xref target="smart_metering"/>,
<xref target="sports_and_entertainment"/>).</t>
</list></t>

<!-- (U4.5) -->

<t><list style="symbols">
  <t>It should be possible to update access control policies without
manually re-provisioning individual devices (see
e.g. <xref target="home_automation"/>, <xref target="eHealth"/>, <xref target="smart_metering"/>,
<xref target="sports_and_entertainment"/>).  <vspace blankLines='1'/>
Rationale: Peers can change rapidly which makes manual
re-provisioning unreasonably expensive.</t>
  <t>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. <xref target="smart_metering"/>).</t>
</list></t>

<!-- (U2.2, U4.7, U4.8, U5.4) -->

<t><list style="symbols">
  <t>It must be possible to dynamically revoke authorizations (see
e.g. <xref target="building_automation"/>).</t>
  <t>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 <xref target="attacks"/>).</t>
  <t>Secure default settings are needed for the initial state of the
authentication and authorization protocols (all use cases).  <vspace blankLines='1'/>
Rationale: Many attacks exploit insecure default settings, and
experience shows that default settings are frequently left unchanged
by the end users.</t>
  <t>Access to resources on other devices should only be permitted if a
rule exists that explicitly allows this access (default deny) (see
e.g. <xref target="building_automation"/>).</t>
  <t>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
<xref target="home_automation"/>, <xref target="eHealth"/>, <xref target="sports_and_entertainment"/>).</t>
</list></t>

</section>
<section anchor="proxies" title="Proxies">

<t>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 <xref target="smart_metering"/>).</t>

</section>
</section>
<section anchor="privacy-considerations" title="Privacy Considerations">

<t>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.</t>

<t>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.</t>

<t>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 <xref target="eHealth"/>). </t>

<t>The personal health monitoring use case (see <xref target="eHealth"/>) 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 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.</t>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>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 Pötsch 
and Koojana Kuladinithi for their input on the container monitoring use case.</t>

<t>Ludwig Seitz and Göran Selander worked on this document as part of EIT-ICT Labs
activity PST-14056.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document has no IANA actions.</t>

<!-- Local Variables: -->
<!-- coding: utf-8 -->
<!-- End: -->

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference anchor='RFC7228'>

<front>
<title>Terminology for Constrained-Node Networks</title>
<author initials='C.' surname='Bormann' fullname='C. Bormann'>
<organization /></author>
<author initials='M.' surname='Ersue' fullname='M. Ersue'>
<organization /></author>
<author initials='A.' surname='Keranen' fullname='A. Keranen'>
<organization /></author>
<date year='2014' month='May' />
<abstract>
<t>The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks.  This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.</t></abstract></front>

<seriesInfo name='RFC' value='7228' />
<format type='TXT' octets='37635' target='http://www.rfc-editor.org/rfc/rfc7228.txt' />
</reference>



<reference anchor='RFC7252'>

<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'>
<organization /></author>
<author initials='K.' surname='Hartke' fullname='K. Hartke'>
<organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'>
<organization /></author>
<date year='2014' month='June' />
<abstract>
<t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t><t> CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t></abstract></front>

<seriesInfo name='RFC' value='7252' />
<format type='TXT' octets='258789' target='http://www.rfc-editor.org/rfc/rfc7252.txt' />
</reference>



<reference anchor='RFC6347'>

<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<author initials='N.' surname='Modadugu' fullname='N. Modadugu'>
<organization /></author>
<date year='2012' month='January' />
<abstract>
<t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='6347' />
<format type='TXT' octets='73546' target='http://www.rfc-editor.org/rfc/rfc6347.txt' />
</reference>


<reference anchor="Jedermann14" >
  <front>
    <title>Communication techniques and challenges for wireless food quality monitoring</title>
    <author initials="R." surname="Jedermann" fullname="Reiner Jedermann">
      <organization></organization>
    </author>
    <author initials="T." surname="Pötsch" fullname="Thomas Pötsch">
      <organization></organization>
    </author>
    <author initials="C." surname="LLoyd" fullname="Chanaka Lloyd">
      <organization></organization>
    </author>
    <date year="2014" month="May"/>
  </front>
  <seriesInfo name="Philosophical Transactions of the Royal Society A" value="Mathematical, Physical and Engineering Sciences"/>
</reference>




<reference anchor='RFC7258'>

<front>
<title>Pervasive Monitoring Is an Attack</title>
<author initials='S.' surname='Farrell' fullname='S. Farrell'>
<organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'>
<organization /></author>
<date year='2014' month='May' />
<abstract>
<t>Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t></abstract></front>

<seriesInfo name='BCP' value='188' />
<seriesInfo name='RFC' value='7258' />
<format type='TXT' octets='13396' target='http://www.rfc-editor.org/rfc/rfc7258.txt' />
</reference>




    </references>



  </back>
</rfc>