draft-ietf-ace-usecases-07.txt   draft-ietf-ace-usecases-08.txt 
ACE Working Group L. Seitz, Ed. ACE Working Group L. Seitz, Ed.
Internet-Draft SICS Swedish ICT AB Internet-Draft SICS Swedish ICT AB
Intended status: Informational S. Gerdes, Ed. Intended status: Informational S. Gerdes, Ed.
Expires: April 4, 2016 Universitaet Bremen TZI Expires: April 9, 2016 Universitaet Bremen TZI
G. Selander G. Selander
Ericsson Ericsson
M. Mani M. Mani
Itron Itron
S. Kumar S. Kumar
Philips Research Philips Research
October 02, 2015 October 07, 2015
ACE use cases ACE use cases
draft-ietf-ace-usecases-07 draft-ietf-ace-usecases-08
Abstract Abstract
Constrained devices are nodes with limited processing power, storage Constrained devices are nodes with limited processing power, storage
space and transmission capacities. These devices in many cases do space and transmission capacities. These devices in many cases do
not provide user interfaces and are often intended to interact not provide user interfaces and are often intended to interact
without human intervention. without human intervention.
This document includes a collection of representative use cases for This document includes a collection of representative use cases for
authentication and authorization in constrained environments. These authentication and authorization in constrained environments. These
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 4, 2016. This Internet-Draft will expire on April 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Container monitoring . . . . . . . . . . . . . . . . . . 4 2.1. Container monitoring . . . . . . . . . . . . . . . . . . 4
2.1.1. Bananas for Munich . . . . . . . . . . . . . . . . . 5 2.1.1. Bananas for Munich . . . . . . . . . . . . . . . . . 5
2.1.2. Authorization Problems Summary . . . . . . . . . . . 6 2.1.2. Authorization Problems Summary . . . . . . . . . . . 6
2.2. Home Automation . . . . . . . . . . . . . . . . . . . . . 7 2.2. Home Automation . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Controlling the Smart Home Infrastructure . . . . . . 7 2.2.1. Controlling the Smart Home Infrastructure . . . . . . 7
2.2.2. Seamless Authorization . . . . . . . . . . . . . . . 7 2.2.2. Seamless Authorization . . . . . . . . . . . . . . . 7
2.2.3. Remotely letting in a visitor . . . . . . . . . . . . 7 2.2.3. Remotely letting in a visitor . . . . . . . . . . . . 8
2.2.4. Selling the house . . . . . . . . . . . . . . . . . . 8 2.2.4. Selling the house . . . . . . . . . . . . . . . . . . 8
2.2.5. Authorization Problems Summary . . . . . . . . . . . 8 2.2.5. Authorization Problems Summary . . . . . . . . . . . 8
2.3. Personal Health Monitoring . . . . . . . . . . . . . . . 9 2.3. Personal Health Monitoring . . . . . . . . . . . . . . . 9
2.3.1. John and the heart rate monitor . . . . . . . . . . . 10 2.3.1. John and the heart rate monitor . . . . . . . . . . . 10
2.3.2. Authorization Problems Summary . . . . . . . . . . . 11 2.3.2. Authorization Problems Summary . . . . . . . . . . . 11
2.4. Building Automation . . . . . . . . . . . . . . . . . . . 12 2.4. Building Automation . . . . . . . . . . . . . . . . . . . 12
2.4.1. Device Lifecycle . . . . . . . . . . . . . . . . . . 12 2.4.1. Device Lifecycle . . . . . . . . . . . . . . . . . . 12
2.4.2. Public Safety . . . . . . . . . . . . . . . . . . . . 14 2.4.2. Public Safety . . . . . . . . . . . . . . . . . . . . 16
2.4.3. Authorization Problems Summary . . . . . . . . . . . 15 2.4.3. Authorization Problems Summary . . . . . . . . . . . 17
2.5. Smart Metering . . . . . . . . . . . . . . . . . . . . . 16 2.5. Smart Metering . . . . . . . . . . . . . . . . . . . . . 18
2.5.1. Drive-by metering . . . . . . . . . . . . . . . . . . 16 2.5.1. Drive-by metering . . . . . . . . . . . . . . . . . . 18
2.5.2. Meshed Topology . . . . . . . . . . . . . . . . . . . 17 2.5.2. Meshed Topology . . . . . . . . . . . . . . . . . . . 19
2.5.3. Advanced Metering Infrastructure . . . . . . . . . . 17 2.5.3. Advanced Metering Infrastructure . . . . . . . . . . 19
2.5.4. Authorization Problems Summary . . . . . . . . . . . 18 2.5.4. Authorization Problems Summary . . . . . . . . . . . 20
2.6. Sports and Entertainment . . . . . . . . . . . . . . . . 18 2.6. Sports and Entertainment . . . . . . . . . . . . . . . . 20
2.6.1. Dynamically Connecting Smart Sports Equipment . . . . 19 2.6.1. Dynamically Connecting Smart Sports Equipment . . . . 21
2.6.2. Authorization Problems Summary . . . . . . . . . . . 19 2.6.2. Authorization Problems Summary . . . . . . . . . . . 21
2.7. Industrial Control Systems . . . . . . . . . . . . . . . 20 2.7. Industrial Control Systems . . . . . . . . . . . . . . . 22
2.7.1. Oil Platform Control . . . . . . . . . . . . . . . . 20 2.7.1. Oil Platform Control . . . . . . . . . . . . . . . . 22
2.7.2. Authorization Problems Summary . . . . . . . . . . . 21 2.7.2. Authorization Problems Summary . . . . . . . . . . . 23
3. Security Considerations . . . . . . . . . . . . . . . . . . . 21 3. Security Considerations . . . . . . . . . . . . . . . . . . . 23
3.1. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.1. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2. Configuration of Access Permissions . . . . . . . . . . . 23 3.2. Configuration of Access Permissions . . . . . . . . . . . 25
3.3. Authorization Considerations . . . . . . . . . . . . . . 23 3.3. Authorization Considerations . . . . . . . . . . . . . . 25
3.4. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 26
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7. Informative References . . . . . . . . . . . . . . . . . . . 26 7. Informative References . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Constrained devices [RFC7228] are nodes with limited processing Constrained devices [RFC7228] are nodes with limited processing
power, storage space and transmission capacities. These devices are power, storage space and transmission capacities. These devices are
often battery-powered and in many cases do not provide user often battery-powered and in many cases do not provide user
interfaces. interfaces.
Constrained devices benefit from being interconnected using Internet Constrained devices benefit from being interconnected using Internet
protocols. However, deploying common security protocols can protocols. However, deploying common security protocols can
skipping to change at page 3, line 38 skipping to change at page 3, line 38
aspects of everyday life, from attackers wishing to gain control over aspects of everyday life, from attackers wishing to gain control over
the device's data or functions. the device's data or functions.
This document comprises a collection of representative use cases for This document comprises a collection of representative use cases for
the application of authentication and authorization in constrained the application of authentication and authorization in constrained
environments. These use cases aim at identifying authorization environments. These use cases aim at identifying authorization
problems that arise during the lifecycle of a constrained device. problems that arise during the lifecycle of a constrained device.
Note that this document does not aim at collecting all possible use Note that this document does not aim at collecting all possible use
cases. cases.
We assume a scenario where one device acts as a server that offers We assume that the communication between the devices is based on the
resources such as sensor data and actuator settings. The resources Representational State Transfer (REST) architectural style, i.e. a
can be accessed by clients, sometimes without human intervention i.e. device acts as a server that offers resources such as sensor data and
machine-to-machine (M2M). actuators. The resources can be accessed by clients, sometimes
In some situations the communication will happen through without human intervention (M2M). In some situations the
intermediaries (e.g. gateways, proxies). communication will happen through intermediaries (e.g. gateways,
proxies).
Where specific detail is necessary it is assumed that the devices Where specific detail is necessary it is assumed that the devices
communicate using CoAP [RFC7252], although most conclusions are communicate using CoAP [RFC7252], although most conclusions are
generic. generic.
1.1. Terminology 1.1. Terminology
Readers are required to be familiar with the terms defined in Readers are required to be familiar with the terms defined in
[RFC7228]. [RFC7228].
2. Use Cases 2. Use Cases
This section includes the use cases; each use case first presents a This section includes the use cases; each use case first presents a
general description of the application environment, than one or more general description of the application environment, than one or more
specific use cases, and finally a summary of the authorization- specific use cases, and finally a summary of the authorization-
related problems to be solved. related problems to be solved.
skipping to change at page 9, line 51 skipping to change at page 10, line 5
longer valid. longer valid.
2.3. Personal Health Monitoring 2.3. Personal Health Monitoring
Personal health monitoring devices, i.e. eHealth devices, are Personal health monitoring devices, i.e. eHealth devices, are
typically battery driven and located physically on or in the user to typically battery driven and located physically on or in the user to
monitor some bodily function, such as temperature, blood pressure, or monitor some bodily function, such as temperature, blood pressure, or
pulse rate. These devices typically connect to the Internet through pulse rate. These devices typically connect to the Internet through
an intermediary base-station, using wireless technologies and through an intermediary base-station, using wireless technologies and through
this connection they report the monitored data to some entity, which this connection they report the monitored data to some entity, which
may either be the user, or a medical cargiver. may either be the user, or a medical caregiver.
Medical data has always been considered as very sensitive, and Medical data has always been considered as very sensitive, and
therefore requires good protection against unauthorized disclosure. therefore requires good protection against unauthorized disclosure.
A frequent, conflicting requirement is the capability for medical A frequent, conflicting requirement is the capability for medical
personnel to gain emergency access, even if no specific access rights personnel to gain emergency access, even if no specific access rights
exist. As a result, the importance of secure audit logs increases in exist. As a result, the importance of secure audit logs increases in
such scenarios. such scenarios.
Since the users are not typically trained in security (or even Since the users are not typically trained in security (or even
computer use), the configuration must use secure default settings, computer use), the configuration must use secure default settings,
skipping to change at page 10, line 32 skipping to change at page 10, line 34
(pchalliance.org). (pchalliance.org).
2.3.1. John and the heart rate monitor 2.3.1. John and the heart rate monitor
John has a heart condition, that can result in sudden cardiac John has a heart condition, that can result in sudden cardiac
arrests. He therefore uses a device called HeartGuard that monitors arrests. He therefore uses a device called HeartGuard that monitors
his heart rate and his location (U3.7). In case of a cardiac arrest his heart rate and his location (U3.7). In case of a cardiac arrest
it automatically sends an alarm to an emergency service, transmitting it automatically sends an alarm to an emergency service, transmitting
John's current location (U3.1). Either the device has long range John's current location (U3.1). Either the device has long range
connectivity itself (e.g. via GSM) or it uses some intermediary, connectivity itself (e.g. via GSM) or it uses some intermediary,
nearby device (e.g. John's smartphone) to transmit such an alarm. To nearby device (e.g. John's smartphone) to transmit such an alarm.
ensure Johns safety, the device is expected to be in constant To ensure Johns safety, the device is expected to be in constant
operation (U3.3, U3.6). operation (U3.3, U3.6).
The device includes an authentication mechanism, in order to prevent The device includes an authentication mechanism, in order to prevent
other persons who get physical access to it from acting as the owner other persons who get physical access to it from acting as the owner
and altering the access control and security settings (U3.8). and altering the access control and security settings (U3.8).
John can configure additional persons that get notified in an John can configure additional persons that get notified in an
emergency, for example his daughter Jill. Furthermore the device emergency, for example his daughter Jill. Furthermore the device
stores data on John's heart rate, which can later be accessed by a stores data on John's heart rate, which can later be accessed by a
physician to assess the condition of John's heart (U3.2). physician to assess the condition of John's heart (U3.2).
skipping to change at page 12, line 12 skipping to change at page 12, line 15
o U3.8 The wearer of an eHealth device requires the integrity and o U3.8 The wearer of an eHealth device requires the integrity and
confidentiality of the data measured by the device. confidentiality of the data measured by the device.
2.4. Building Automation 2.4. Building Automation
Buildings for commercial use such as shopping malls or office Buildings for commercial use such as shopping malls or office
buildings nowadays are equipped increasingly with semi-automatic buildings nowadays are equipped increasingly with semi-automatic
components to enhance the overall living quality and to save energy components to enhance the overall living quality and to save energy
where possible. This includes for example heating, ventilation and where possible. This includes for example heating, ventilation and
air condition (HVAC) as well as illumination and security systems air condition (HVAC) as well as illumination and security systems
such as fire alarms. such as fire alarms. These components are being increasingly managed
centrally in a Building and Lighting Management System (BLMS) by a
facility manager.
Different areas of these buildings are often exclusively leased to Different areas of these buildings are often exclusively leased to
different companies. However they also share some of the common different companies. However they also share some of the common
areas of the building. Accordingly, a company must be able to 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 control the lighting and HVAC system of its own part of the building
must not have access to control rooms that belong to other companies. and must not have access to control rooms that belong to other
companies.
Some parts of the building automation system such as entrance Some parts of the building automation system such as entrance
illumination and fire alarm systems are controlled either by all illumination and fire alarm systems are controlled either by all
parties together or by a service company. parties together or by a facility management company.
2.4.1. Device Lifecycle 2.4.1. Device Lifecycle
2.4.1.1. Installation and Commissioning 2.4.1.1. Installation and Commissioning
A building is hired out to different companies for office space. Installation of the building automation components often start even
This building features various automated systems, such as a fire before the construction work is completed. Lighting is one of the
first components to be installed in new buildings. A lighting plan
created by a lighting designer provides the necessary information
related to the kind of lighting devices (luminaires, sensors and
switches) to be installed along with their expected behavior. The
physical installation of the correct lighting devices at the right
locations are done by electricians based on the lighting plan. They
ensure that the electrical wiring is performed according to local
regulations and lighting devices which may be from multiple
manufacturers are connected to the electrical power supply properly.
After the installation, lighting can be used in a default out-of-box
mode for e.g. at full brightness when powered on. After this step
(or in parallel in a different section of the building), a lighting
commissioner adds the devices to the building domain (U4.1) and
performs the proper configuration of the lights as prescribed in the
lighting plan. This involves for example grouping to ensure that
light points react together, more or less synchronously (U4.8) and
defining lighting scenes for particular areas of the building. The
commissioning is often done in phases, either by one or more
commissioners, on different floors. The building lighting network at
this stage may be in different network islands with no connectivity
between them due to lack of the IT infrastructure.
After this, other building components like HVAC and security systems
are similarly installed by electricians and later commissioned by
their respective domain professionals. Similar configurations
related to grouping (U4.8) are required to ensure for e.g. HVAC
equipment are controlled by the closest temperature sensor.
For the building IT systems, the Ethernet wiring is initially laid
out in the building according to the IT plan. The IT network is
commissioned often after the construction is completed to avoid any
damage to sensitive networking and computing equipment. The
commissioning is performed by an IT engineer with additional switches
(wired and/or wireless), IP routers and computing devices. Direct
Internet connectivity for all installed/commissioned devices in the
building is only available at this point. The BLMS that monitors and
controls the various building automation components are only
connected to the field devices at this stage. The different network
islands (for lighting and HVAC) are also joined together without any
further involvement of domain specialist such as lighting or HVAC
commissioners.
2.4.1.2. Operational
The building automation systems is now finally ready and the
operational access is transferred to the facility management company
of the building (U4.2). The facility manager is responsible for
monitoring and ensuring that the building automation systems meets
the needs of the building occupants. If changes are needed, the
facility management company hires an external installation and
commissioning company to perform the changes.
Different parts of the building are rented out to different companies
for office space.
The tenants are provided access to use the automated HVAC, lighting
and physical access control systems deployed. The safety of the
occupants are also managed using automated systems, such as a fire
alarm system, which is triggered by several smoke detectors which are alarm system, which is triggered by several smoke detectors which are
spread out across the building. It also has automated HVAC, lighting spread out across the building.
and physical access control systems.
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 rooms 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 and associated building automation
components with company A (U4.2, U4.9).
2.4.1.3. Maintenance
Company A's staff are annoyed that the lighting switches off too
often in their rooms if they work silently in front of their
computer. Company A notifies the the facility manager of the
building to increase the delay before lights switch off. The
facility manager can either configure the new values directly in the
BLMS or if additional changes are needed on the field devices, hires
a commissioning Company C to perform the needed changes (U4.4).
Company C gets the necessary authorization from the facility
management company to interact with the BLMS. The commissioner's
tool gets the necessary authorization from BLMS to send a
configuration change to all lighting devices in Company A's offices
to increase their delay before they switch off.
At some point the facility management company wants to update the
firmware of lighting devices in order to eliminate software bugs.
Before accepting the new firmware, each device checks the
authorization of the facility management company to perform this
update.
A network diagnostic tool of the BLMS detects that a luminaire in one
of the Company A's office room is no longer connected to the network.
The BLMS alerts the facility manager to replace the luminaire. The
facility manager replaces the old broken luminaire and informs the
BLMS of the identity (for e.g. MAC address) of the newly added
device. The BLMS then authorizes the new device onto the system and
transfers seamlessly all the permissions of the previous broken
device to the replacement device (U4.12).
2.4.1.4. Recommissioning
A vacant area of the building has been recently leased to company A. 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 Before moving into its new office, Company A wishes to replace the
lighting with a more energy efficient and a better light quality lighting with a more energy efficient and a better light quality
luminaries. They hire an installation and commissioning company C to luminaries. They hire an installation and commissioning company C to
redo the illumination. Company C is instructed to integrate the new redo the illumination. Company C is instructed to integrate the new
lighting devices, which may be from multiple manufacturers, into the lighting devices, which may be from multiple manufacturers, into the
existing lighting infrastructure of the building which includes existing lighting infrastructure of the building which includes
presence sensors, switches, controllers etc (U4.1). presence sensors, switches, controllers etc (U4.1).
Company C gets the necessary authorization from the service company Company C gets the necessary authorization from the facility
to interact with the existing Building and Lighting Management System management company to interact with the existing BLMS (U4.4). To
(BLMS) (U4.4). To prevent disturbance to other occupants of the prevent disturbance to other occupants of the building, Company C is
building, Company C is provided authorization to perform the provided authorization to perform the commissioning only during non-
commissioning only during non-office hours and only to modify office hours and only to modify configuration on devices belonging to
configuration on devices belonging to the domain of Company A's space the domain of Company A's space (U4.5). Before removing existing
(U4.5). After installation (wiring) of the new lighting devices, the devices, all security and configuration material that belongs to the
commissioner adds the devices into the company A's lighting domain. domain are deleted and the devices are set back to factory state
(U4.3). This ensures that these devices may be reused at other
installations or in other parts of the same building without
affecting future operations. After installation (wiring) of the new
lighting devices, the commissioner adds the devices into the company
A's lighting domain.
Once the devices are in the correct domain, the commissioner Once the devices are in the correct domain, the commissioner
authorizes the interaction rules between the new lighting devices and authorizes the interaction rules between the new lighting devices and
existing devices like presence sensors (U4.7). For this, the existing devices like presence sensors (U4.7). For this, the
commissioner creates the authorization rules on the BLMS which define commissioner creates the authorization rules on the BLMS which define
which lights form a group and which sensors/switches/controllers are which lights form a group and which sensors/switches/controllers are
allowed to control which groups (U4.8). These authorization rules allowed to control which groups (U4.8). These authorization rules
may be context based like time of the day (office or non-office may be context based like time of the day (office or non-office
hours) or location of the handheld lighting controller etc (U4.5). hours) or location of the handheld lighting controller etc (U4.5).
2.4.1.2. Operational 2.4.1.5. Decommissioning
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 (U4.2, U4.9).
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 (U4.4).
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 BLMS to send a configuration change to
all lighting devices in Company A's offices to increase their delay
before they switch off.
At some point the service company wants to update the firmware of
lighting devices in order to eliminate software bugs. Before
accepting the new firmware, each device checks the authorization of
the service company to perform this update.
2.4.1.4. Decommissioning
Company A has noticed that the handheld controllers are often Company A has noticed that the handheld controllers are often
misplaced and hard to find when needed. So most of the time staff misplaced and hard to find when needed. So most of the time staff
use the existing wall switches for manual control. Company A decides use the existing wall switches for manual control. Company A decides
it would be better to completely remove handheld controllers and asks it would be better to completely remove handheld controllers and asks
Company C to decommission them from the lighting system (U4.4). Company C to decommission them from the lighting system (U4.4).
Company C again gets the necessary authorization from the service Company C again gets the necessary authorization from the facility
company to interact with the BLMS. The commissioner now deletes any management company to interact with the BLMS. The commissioner now
rules that allowed handheld controllers authorization to control the deletes any rules that allowed handheld controllers authorization to
lighting (U4.3, U4.6). Additionally the commissioner instructs the control the lighting (U4.3, U4.6). Additionally the commissioner
BLMS to push these new rules to prevent cached rules at the end instructs the BLMS to push these new rules to prevent cached rules at
devices from being used. the end devices from being used. Any cryptographic key material
belonging to the site in the handheld controllers are also removed
and they are set to the factory state (U4.3).
2.4.2. Public Safety 2.4.2. Public Safety
The fire department requires that as part of the building safety The fire department requires that as part of the building safety
code, that the building have sensors that sense the level of smoke, code, that the building have sensors that sense the level of smoke,
heat, etc., when a fire breaks out. These sensors report metrics heat, etc., when a fire breaks out. These sensors report metrics
which are then used by a back-end server to map safe areas and un- which are then used by a back-end server to map safe areas and un-
safe areas within a building and also possibly the structural safe areas within a building and also possibly the structural
integrity of the building before fire-fighters may enter it. integrity of the building before fire-fighters may enter it.
Sensors may also be used to track where human/animal activity is Sensors may also be used to track where human/animal activity is
skipping to change at page 16, line 9 skipping to change at page 17, line 51
revoking permissions) for their endpoints and devices. revoking permissions) for their endpoints and devices.
o U4.10 The authorization mechanisms must be able to cope with o U4.10 The authorization mechanisms must be able to cope with
extremely time-sensitive operations which have to be carried out extremely time-sensitive operations which have to be carried out
in a quick manner. in a quick manner.
o U4.11 The building owner and the public safety authorities want to o U4.11 The building owner and the public safety authorities want to
be able to perform data origin authentication on messages sent and be able to perform data origin authentication on messages sent and
received by some of the systems in the building. received by some of the systems in the building.
o U4.12 The building owner should be allowed to replace an existing
device with a new device providing the same functionality within
their administrative domain. Access control from the replaced
device should then apply to these new devices seamlessly.
2.5. Smart Metering 2.5. Smart Metering
Automated measuring of customer consumption is an established Automated measuring of customer consumption is an established
technology for electricity, water, and gas providers. Increasingly technology for electricity, water, and gas providers. Increasingly
these systems also feature networking capability to allow for remote these systems also feature networking capability to allow for remote
management. Such systems are in use for commercial, industrial and management. Such systems are in use for commercial, industrial and
residential customers and require a certain level of security, in residential customers and require a certain level of security, in
order to avoid economic loss to the providers, vulnerability of the order to avoid economic loss to the providers, vulnerability of the
distribution system, as well as disruption of services for the distribution system, as well as disruption of services for the
customers. customers.
skipping to change at page 23, line 4 skipping to change at page 25, line 4
o Battery usage o Battery usage
o Number of required message exchanges o Number of required message exchanges
o Size of data that is transmitted (e.g. authentication and access o Size of data that is transmitted (e.g. authentication and access
control data) control data)
o Size of code required to run the protocols o Size of code required to run the protocols
o Size of RAM memory and stack required to run the protocols o Size of RAM memory and stack required to run the protocols
o Timers for transaction processing o Resources blocked by partially completed exchanges (e.g. while one
party is waiting for a transaction time to run out)
Solution developers also need to consider whether the session should Solution developers also need to consider whether the session should
be protected from information disclosure and tampering. be protected from information disclosure and tampering.
3.2. Configuration of Access Permissions 3.2. Configuration of Access Permissions
o The access control policies need to be enforced (all use cases): o The access control policies need to be enforced (all use cases):
The information that is needed to implement the access control The information that is needed to implement the access control
policies needs to be provided to the device that enforces the policies needs to be provided to the device that enforces the
authorization and applied to every incoming request. authorization and applied to every incoming request.
skipping to change at page 24, line 26 skipping to change at page 26, line 28
o Secure default settings are needed for the initial state of the o Secure default settings are needed for the initial state of the
authentication and authorization protocols (all use cases). authentication and authorization protocols (all use cases).
Rationale: Many attacks exploit insecure default settings, and Rationale: Many attacks exploit insecure default settings, and
experience shows that default settings are frequently left experience shows that default settings are frequently left
unchanged by the end users. unchanged by the end users.
o Access to resources on other devices should only be permitted if a o Access to resources on other devices should only be permitted if a
rule exists that explicitly allows this access (default deny) (see rule exists that explicitly allows this access (default deny) (see
e.g. Section 2.4). e.g. Section 2.4).
o Usability is important for all use cases. The configuration of o Usability is important for all use cases. The configuration of
authorization policies as well as the gaining access to devices authorization policies as well as the gaining access to devices
must be simple for the users of the devices. Special care needs must be simple for the users of the devices. Special care needs
to be taken for scenarios where access control policies have to be to be taken for scenarios where access control policies have to be
configured by users that are typically not trained in security configured by users that are typically not trained in security
(see Section 2.2, Section 2.3, Section 2.6). (see Section 2.2, Section 2.3, Section 2.6).
3.4. Proxies 3.4. Proxies
skipping to change at page 25, line 38 skipping to change at page 27, line 32
solution provides means for audit logs, it must consider the impact solution provides means for audit logs, it must consider the impact
of logged data for the privacy of all parties involved. Suitable of logged data for the privacy of all parties involved. Suitable
measures for protecting and purging the logs must be taken during measures for protecting and purging the logs must be taken during
operation, maintenance and decommissioning of the device. operation, maintenance and decommissioning of the device.
5. Acknowledgments 5. Acknowledgments
The authors would like to thank Olaf Bergmann, Sumit Singhal, John The authors would like to thank Olaf Bergmann, Sumit Singhal, John
Mattson, Mohit Sethi, Carsten Bormann, Martin Murillo, Corinna Mattson, Mohit Sethi, Carsten Bormann, Martin Murillo, Corinna
Schmitt, Hannes Tschofenig, Erik Wahlstroem, Andreas Baeckman, Samuel Schmitt, Hannes Tschofenig, Erik Wahlstroem, Andreas Baeckman, Samuel
Erdtman, Steve Moore, Thomas Hardjono, Kepeng Li and Jim Schaad for Erdtman, Steve Moore, Thomas Hardjono, Kepeng Li, Jim Schaad,
reviewing and/or contributing to the document. Also, thanks to Prashant Jhingran, Kathleen Moriarty, and Sean Turner for reviewing
Markus Becker, Thomas Poetsch and Koojana Kuladinithi for their input and/or contributing to the document. Also, thanks to Markus Becker,
on the container monitoring use case. Furthermore the authors thank Thomas Poetsch and Koojana Kuladinithi for their input on the
Akbar Rahman, Chonggang Wang, and Vinod Choyi who contributed the container monitoring use case. Furthermore the authors thank Akbar
public safety scenario in the building automation use case. Rahman, Chonggang Wang, Vinod Choyi, and Abhinav Somaraju who
contributed to the building automation use case.
Ludwig Seitz and Goeran Selander worked on this document as part of Ludwig Seitz and Goeran Selander worked on this document as part of
EIT-ICT Labs activity PST-14056. EIT-ICT Labs activity PST-14056.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. Informative References 7. Informative References
[Jedermann14] [Jedermann14]
Jedermann, R., Poetsch, T., and C. LLoyd, "Communication Jedermann, R., Poetsch, T., and C. LLoyd, "Communication
techniques and challenges for wireless food quality techniques and challenges for wireless food quality
monitoring", Philosophical Transactions of the Royal monitoring", Philosophical Transactions of the Royal
Society A Mathematical, Physical and Engineering Sciences, Society A Mathematical, Physical and Engineering Sciences,
May 2014. May 2014.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, DOI 10.17487/ Constrained-Node Networks", RFC 7228, DOI 10.17487/
RFC7228, May 2014, RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>. <http://www.rfc-editor.org/info/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
RFC7252, June 2014, RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <http://www.rfc-editor.org/info/rfc7252>.
 End of changes. 24 change blocks. 
108 lines changed or deleted 193 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/