ACE Working Group L. Seitz
Internet-Draft SICS Swedish ICT AB
Intended status: Informational S. Gerdes
Expires: August 14, 2014 Universitaet Bremen TZI
G. Selander
Ericsson
February 10, 2014
ACE use cases
draft-seitz-ace-usecases-00
Abstract
This document presents use cases for authentication and access
control in scenarios involving constrained RESTful devices. Where
specific details are relevant, it is assumed that the devices use
CoAP as communication protocol, however most conclusions apply
generally.
A number of security requirements are derived from the use cases,
which are intended as a guideline for developing a comprehensive
authentication and access control approach for this class of
scenarios.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 14, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Seitz, et al. Expires August 14, 2014 [Page 1]
Internet-Draft ACE use cases February 2014
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Container monitoring . . . . . . . . . . . . . . . . . . . 4
2.1.1. Bananas for Munich . . . . . . . . . . . . . . . . . . 4
2.1.2. Requirements . . . . . . . . . . . . . . . . . . . . . 5
2.2. Home Automation . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Remotely letting in a visitor . . . . . . . . . . . . 5
2.2.2. Requirements . . . . . . . . . . . . . . . . . . . . . 6
2.3. Personal Health Monitoring . . . . . . . . . . . . . . . . 6
2.3.1. John and the heart rate monitor . . . . . . . . . . . 7
2.3.2. Requirements . . . . . . . . . . . . . . . . . . . . . 8
2.4. Building Automation . . . . . . . . . . . . . . . . . . . 8
2.4.1. Fire Alarm . . . . . . . . . . . . . . . . . . . . . . 8
2.4.2. Requirements . . . . . . . . . . . . . . . . . . . . . 9
2.5. Industrial Control Systems . . . . . . . . . . . . . . . . 10
2.5.1. Water treatment plant . . . . . . . . . . . . . . . . 10
2.5.2. Requirements . . . . . . . . . . . . . . . . . . . . . 11
3. Requirements From The Use Cases . . . . . . . . . . . . . . . 12
3.1. General Security Requirements . . . . . . . . . . . . . . 12
3.2. Authentication Requirements . . . . . . . . . . . . . . . 13
3.3. Access Control Requirements . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Informative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Seitz, et al. Expires August 14, 2014 [Page 2]
Internet-Draft ACE use cases February 2014
1. Introduction
This document presents use cases in an attempt to analyze the
authentication and access control requirements in an Internet of
Things setting. This setting features constrained devices
[I-D.ietf-lwig-terminology] communicating over the Internet. Some of
these devices may have very low capacity in terms of memory and
processing power, and may additionally be limited by the fact that
they run on battery power.
These devices offer resources such as sensor data and actuators,
which are accessed by clients, that may be users or other devices.
In some situations the communication will happen through
intermediaries (e.g. gateways, proxies).
Where specific detail is necessary it is assumed that the devices
communicate using the CoAP protocol [I-D.ietf-core-coap], although
most conclusions are generic. Currently CoAP proposes to use DTLS
[RFC6347] for authentication, and access control lists on the
devices, that specify which clients may initiate a DTLS connection.
One goal of this document is to point out use cases where this
approach is not satisfactory.
1.1. Terminology
Resource Server (RS): The constrained device which hosts resources
the Client wants to access.
Client (C): A device which wants to access a resource on the Resource
Server.
This could also be a constrained device.
Resource Owner (RO): The subject who owns the resource and controls
its access permissions.
Seitz, et al. Expires August 14, 2014 [Page 3]
Internet-Draft ACE use cases February 2014
2. Use Cases
This section lists use cases involving constrained devices with
security requirements. Each use case first presents a general
description of the application area, then one or more specific use
cases, and finally the resulting requirements. We assume that basic
security requirements such as e.g. communication security and mutual
authentication, apply for all of these scenarios.
2.1. Container monitoring
The ability of sensors to communicate environmental data wirelessly
opens up new application areas. The use of such sensor systems makes
it possible to transmit specific characteristics such as temperature,
humidity and gas content during transportation and storage of goods.
The proper handling of the sensors in this scenario is not easy to
accomplish. They have to be associated to the appropriate pallet of
the respective container. Moreover, the goods and the corresponding
sensors belong to specific customers.
During the shipment to their destination the goods often pass stops
where they are transloaded to other means of transportation, e.g.
from ship transport to road transport.
2.1.1. Bananas for Munich
A Munich supermarket chain buys bananas from a Costa Rican fruit
vendor. It instructs a transport company to deliver the goods via
ship to Rotterdam where they are picked up by their own company
trucks.
The supermarket's quality management wants to assure the quality of
their products and thus uses the fruit vendor's service of equipping
the bananas with sensors. The state of the goods is monitored
consistently during the shipment and abnormal sensor values are
recorded. Additionally, the sensor values are used to control the
climate within the cargo containers.
The personnel of the transport company and the supermarket's delivery
service has to be able to locate the proper goods and match them to
the corresponding customer. The state of the cargo must not be
disclosed to them, however.
When the goods arrive at the supermarket in Munich, their state is
checked.
If no anomalies occurred during the transport, the bananas are
admitted for sale.
Seitz, et al. Expires August 14, 2014 [Page 4]
Internet-Draft ACE use cases February 2014
2.1.2. Requirements
o U1.1 The supermarket chain must be able to allow the transport
company and the delivery service to access the position data on
the monitoring devices. Other state information must not be
accessible.
o U1.2 The climate regulation system in the containers must be able
to access the monitoring devices' state information to regulate
the climate accordingly, without manual intervention of the
resource owner.
o U1.3 The supermarket chain must be able to allow the supermarket's
quality management to access the recorded state information on the
monitoring devices.
o U1.4 The supermarket chain does not want other companies to be
able to read sensor information so there should be some access
control for the monitoring devices' state information.
2.2. Home Automation
Automation of the home, housework or household activity is propagated
as a future market for the Internet of Things. A home automation
system integrates electrical devices in a house with each other, such
as heating, ventilation, lighting, home entertainment and home
security.
Such a system needs to accommodate a number of regular users
(inhabitants, close friends, cleaning personnel) as well as a
heterogeneous group of dynamically varying users (visitors,
repairmen, delivery men).
The security required by the systems integrated in a automated home
varies, however it is clear that the security system controlling e.g.
the doors, alarms, and other critical systems needs to be at least as
secure as for a comparable unautomated home.
As the users are not typically trained in security (or even computer
use), the configuration must use secure default settings, and the
interface must be well adapted to novice users.
2.2.1. Remotely letting in a visitor
Jane is the owner of an automated home, that allows her to remotely
control all electrical devices through a web interface or mobile
application. To allow for centralized management of all devices, new
devices need to be able to communicate with both the web interface
Seitz, et al. Expires August 14, 2014 [Page 5]
Internet-Draft ACE use cases February 2014
and the mobile application using a standardized, secure protocol.
Jane has invited over her acquaintance Jeffrey for dinner, but is
stuck in traffic and can not arrive in time, while Jeffrey who uses
the subway arrives punctually. Jane calls Jeffrey and offers him to
let him in remotely, so he can make himself comfortable and use
Jane's home entertainment system.
Jeffrey downloads an application that lets him communicate with
Jane's home, and Jane set permissions for Jeffery that let's him open
the door, and shut down the alarm using that application. She also
gives Jeffrey access to lighting and HVAC and limited access to the
home entertainment system, allowing Jeffrey to all services except
those that are pay-per-use or those that Jane has marked as private.
2.2.2. Requirements
o U2.1 Jane needs to be able to spontaneously provision
authentication means to Jeffrey
o U2.2 Jane must be able to spontaneously change the access control
policies
o U2.3 Jane needs to be able to apply different rights for different
devices and users
o U2.4 Jane must be able to apply local conditions (presence, time)
to authorizations, and the device (e.g. the door) needs to be able
to verify these conditions
o U2.5 The security mechanisms of the different devices in Jane's
home need to be able to communicate with different control devices
(e.g. Jeffrey's mobile phone)
o U2.6 The access control configuration of Jane's home needs to be
secure by default
o U2.7 It must be easy for Jane to edit the access control policies
for her home, even remotely
2.3. Personal Health Monitoring
The use of wearable health monitoring technology is expected to grow
strongly, as a multitude of novel devices are developed and marketed.
These 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
Seitz, et al. Expires August 14, 2014 [Page 6]
Internet-Draft ACE use cases February 2014
technologies. Through this connection they report the monitored data
to some entity, which may either be the user herself, or some medical
personnel in charge of the user.
Medical data has always been considered as very sensitive, and
therefore requires good protection against unauthorized disclosure.
A frequent, conflicting requirement is the capability for medical
personnel to gain emergency access, even if no specific access rights
exist. As a result, the importance of secure audit logs increases in
such scenarios.
Since the users are not typically trained in security (or even
computer use), the configuration must use secure default settings,
and the interface must be well adapted to novice users. Also the
system must require very little maintenance, so e.g. frequent changes
of battery are unacceptable.
2.3.1. John and the heart rate monitor
John has a heart condition, that can result in sudden cardiac
arrests. He therefore uses a device called HeartGuard that monitors
his heart rate and his position. In case of a cardiac arrest it
automatically sends an alarm to an emergency service, transmitting
John's current location. The device also functions as a implanted
cardioverter defibrilator, i.e. it can deliver a shock in order to
try and normalize Johns heart rate.
The device includes some smart logic, with which it identifies its
owner John and allows him to configure the device's settings,
including access control.
This prevents situation where someone else wearing that device can
act as the owner and mess up the access control and security
settings.
John can configure additional persons that get notified in an
emergency, for example his daughter Jill. Furthermore the device
stores data on John's heart rate, which can later be accessed by a
physician to assess the condition of John's heart.
However John is a rather private 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, since they might refuse to renew his
insurance if they decided he was too big a risk for them.
Seitz, et al. Expires August 14, 2014 [Page 7]
Internet-Draft ACE use cases February 2014
2.3.2. Requirements
o U3.1 John must be able to selectively allow different persons or
groups to access the position data on condition that there is an
emergency.
o U3.2 John must be able to selectively allow different persons or
groups to access the heart rate data.
o U3.3 John must be able to block access to specific persons or
groups, if he mistrusts them.
o U3.4 The security measures must not affect the device's battery
lifetime significantly
o U3.5 The device must have secure access control settings by
default
o U3.6 The device's access control settings must be easy to
configure
o U3.7 The device's authentication and access control mechanisms
must not open new avenues for denial of service attacks
2.4. Building Automation
Buildings for commercial use such as shopping malls or office
buildings nowadays are equipped increasingly with semi-automatic
components to enhance the overall living quality and save energy
where possible. This includes for example heating, ventilation and
air condition (HVAC) as well as illumination and fire alarm systems.
These buildings are often used by more than one company who share
some parts of the building while other areas are used by each of them
exclusively. 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 rooms that belong to other companies.
Some parts of the building automation system such as entrance
illumination and fire alarm systems are controlled either by all
parties together or by a service company.
2.4.1. Fire Alarm
The Companies A and B share an office building which is equipped with
a fire alarm system. It is triggered by several smoke detectors
which are spread out across the building.
Seitz, et al. Expires August 14, 2014 [Page 8]
Internet-Draft ACE use cases February 2014
It is a really hot day and James who works for company A turns on the
air condition in his office. Lucy who works for company B wants to
make tea using an electric kettle. After she turned it on she goes
outside to talk to a colleague until the water is boiling.
Unfortunately, her kettle has a malfunction which causes overheating
and results in a smoldering fire of the kettle's plastic case.
Due to the smoke coming from the kettle the fire alarm is triggered.
Alarm sirens throughout the building are notified and 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.
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.
2.4.2. Requirements
o U4.1 Different subsystems of the building must be able
interoperate with each other, e.g. the ventilation with the fire
alarm. The affected devices might be produced by different
vendors and might be operated by different service providers.
o U4.2 Only the smoke detectors must be able to trigger an alarm.
o U4.3 Only the fire department must be able to reset the fire
alarm.
o U4.4 James must be able to control the air conditioning in his
office.
o U4.5 The emergency system must be able to automatically close off
the ventilation system, without manual intervention of the
resource owner.
o U4.6 During fire alarm, the personnel must not be allowed to
regulate the climate control.
o U4.7 Since physically accessing the devices in the building is
very work intensive and thus expensive (there are many devices,
and some are in places that are hard to access), the security
measures should not affect battery lifetime significantly and not
require direct physical interaction with individual devices.
Seitz, et al. Expires August 14, 2014 [Page 9]
Internet-Draft ACE use cases February 2014
2.5. Industrial Control Systems
Industrial control systems (ICS) and especially supervisory control
and data acquisition systems (SCADA) use a multitude of sensors and
actuators in order to monitor and control industrial processes in the
physical world. Example processes include manufacturing, power
generation, and refining of raw materials.
Since the advent of the Stuxnet worm it has become obvious to the
general public how vulnerable this kind of systems are, especially
when connected to the Internet. The severity of these
vulnerabilities are exacerbated by the fact that many ICS are used to
control critical public infrastructure, such as power, water
treatment of traffic control.
Nevertheless the economical advantages of connecting such systems to
the Internet can be significant if appropriate security measures are
put in place.
2.5.1. Water treatment plant
The communal water treatment plant of a mid-sized city is controlled
by a networked ICS. Spread across the city are numerous nodes,
sensors (e.g. pollution meters, pressure indicators) and actuators
(e.g. valves, pumps) communicating via a wireless network. Since the
range of the network is limited, many nodes communicate through
intermediary proxies that relay communications to the administration
clients of the ICS.
Jenny is a technician whose job it is to monitor the plant and take
appropriate measure, if abnormal conditions are detected (e.g. if
water pollution is detected, or the pressure in a pump reaches
critical levels).
Jenny uses an observation mechanism on certain critical resources
that sends her automatic notifications in case of some unexpected
state change.
If Jenny needs to go on sick-leave spontaneously, the service company
sends a replacement worker from a pool of available, qualified
persons. The security administrators give the replacement
appropriate access rights to the system, without sharing Jenny's
credentials (e.g. her password, access card, or private key) with
him, furthermore this delegation does not require updates of the
access control information on the devices.
Joshuah is a young, computer savvy kid with too much time at his
hands. He spends time wardriving and stumbles upon the wireless
network, used by the plant's sensors and actuators. Joshuah tries to
interact with the devices on this network and manages to stall a
Seitz, et al. Expires August 14, 2014 [Page 10]
Internet-Draft ACE use cases February 2014
valve controlling water flow to a part of the city, by overloading
its controller with fake requests for secure connections. Jenny
quickly discovers the attack and is able to take appropriate measures
to prevent damage to the value and restore normal service conditions.
2.5.2. Requirements
o U5.1 The authentication and access control measures must cope with
the presence of intermediary proxies between the Resource Server
and the Client.
o U5.2 Since most of the processing capacity of the nodes and the
network load capacity must go towards production tasks, the
security measures must use minimal resources, both on the network
and on the nodes.
o U5.3 Since replacement workers can spontaneously jump in for
Jenny, the system needs to be able to handle authentication and
access control updates without re-provisioning each node
individually.
o U5.4 After a replacement worker has finished taking care of the
system, the corresponding access control and authentication means
need to be revoked, without re-provisioning each node
individually.
o U5.5 The authentication and access control mechanisms must not
introduce additional avenues for denial of service attacks.
Seitz, et al. Expires August 14, 2014 [Page 11]
Internet-Draft ACE use cases February 2014
3. Requirements From The Use Cases
This section lists requirements derived from the use cases above.
Note that not every single requirement applies to every Resource
Server, however protocols should allow for all of these requirements
to be fulfilled.
3.1. General Security Requirements
The following requirements refer to general security measures that
are affected by the design of authentication and access control
protocols.
o Protect the Resource Server against denial of service (U3.7, U5.5)
* Minimize the number of protocol steps that an attacker can
induce a Resource Server to perform without proper
authentication and access control.
* Note well that for constrained devices this includes attacks
that aim to drain the battery of the target.
o Authentication and access control measures must work when traffic
from the Client to the Resource Server goes through intermediary
nodes. (U5.1)
Rationale: In many deployments, there will be gateways, proxies,
firewalls etc. between a Client and a Resource Server. This means
that e.g. DTLS client authentication can not be used to
authenticate the Client.
o Minimize resource usage for authentication and access control on
the constrained device(s) (U3.4, U4.7, U5.2)
* Minimize battery usage
+ Minimize message exchanges required by security measures
+ Minimize the size of authentication and access control data
that is transmitted
+ Minimize the size of required software libraries
+ Minimize memory and stack usage on the devices
o Require secure default settings (U1.4, U2.6, U3.5)
Rationale: Many attacks exploit insecure default settings, and
Seitz, et al. Expires August 14, 2014 [Page 12]
Internet-Draft ACE use cases February 2014
experience shows that default settings are frequently left
unchanged by the end users. Therefore the security protocols for
constrained devices should require secure modes of use by default.
o Interoperability (U1.1, U2.5, U4.1)
Rationale: Resource Owners may interact with Clients from various
manufacturers and vice-versa. In order to function correctly the
authentication and access control mechanisms need to work
together.
This is best achieved by standardization.
o Usability (U2.7, U3.6)
* Keep response times reasonable
* Make authentication and access control transparent for human
users where possible
* Make the administration of authentication and access control as
simple as possible
3.2. Authentication Requirements
o Standardized provisioning of authentication means to Clients and
Resource Servers (U2.1, U5.3)
* Allow for remote provisioning as an option
o Enable remote revocation of authentication means (U5.4)
3.3. Access Control Requirements
o Enforce the access control policies of the Resource Owner (all use
cases)
* Provision access control policies set by the Resource Owner to
the Policy Decision Point [RFC2904] (which may be on the
Resource Server or on another trusted entity).
* Apply the access control policies to incoming requests (this
may be done by the Resource Server or by another trusted
entity).
o Apply different rights for different requesting entities (U1.1,
U1.2, U2.3, U3.1, U3.2, U3.3, U4.2, U4.3, U4.4, U4.5)
Rationale: In some cases different types of users require
Seitz, et al. Expires August 14, 2014 [Page 13]
Internet-Draft ACE use cases February 2014
different access rights, as opposed to all-or-nothing access
control.
o Allow for fine-grained access control (U1.1, U1.2, U3.1, U3.2,
U4.2, U4.3, U4.4, U4.5) Resource Servers can host several
resources, and a resource (e.g. an actuator) can have different
settings. In some cases access rights need to be different at
this level of granularity.
o Enable checking of local conditions (U2.4, U3.1, U4.6) Access may
depend on local conditions e.g. access to health data in an
emergency. The Policy Decision Point must be able to take such
conditions into account.
o Enable policy updates without re-provisioning individual devices
(U2.2, U4.7, U5.3, U5.4)
Rationale: Clients can change rapidly and re-provisioning might be
prohibitively expensive.
o Do not require manual intervention of the Resource Owner in the
access control process (U1.2, U3.1, U4.5).
Rationale: Manually approving access requests, while being a
common solution in web access control, does not scale well in an
M2M scenario.
Seitz, et al. Expires August 14, 2014 [Page 14]
Internet-Draft ACE use cases February 2014
4. Security Considerations
This document lists security requirements for constrained devices,
motivated by specific use cases. Therefore the whole document deals
with security considerations.
Seitz, et al. Expires August 14, 2014 [Page 15]
Internet-Draft ACE use cases February 2014
5. Acknowledgments
The authors would like to thank Olaf Bergmann, Sumit Singhal, John
Mattson, and Mohit Sethi for reviewing and contributing to the
document. Also, thanks to Markus Becker for his input on the
container monitoring use case.
Seitz, et al. Expires August 14, 2014 [Page 16]
Internet-Draft ACE use cases February 2014
6. IANA Considerations
This document has no IANA actions.
Seitz, et al. Expires August 14, 2014 [Page 17]
Internet-Draft ACE use cases February 2014
7. Informative References
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013.
[I-D.ietf-lwig-terminology]
Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained Node Networks", draft-ietf-lwig-terminology-06
(work in progress), December 2013.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
D. Spence, "AAA Authorization Framework", RFC 2904,
August 2000.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
Seitz, et al. Expires August 14, 2014 [Page 18]
Internet-Draft ACE use cases February 2014
Authors' Addresses
Ludwig Seitz
SICS Swedish ICT AB
Scheelevaegen 17
Lund 22370
Sweden
Email: ludwig@sics.se
Stefanie Gerdes
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63906
Email: gerdes@tzi.org
Goeran Selander
Ericsson
Faroegatan 6
Kista 16480
Sweden
Email: goran.selander@ericsson.com
Seitz, et al. Expires August 14, 2014 [Page 19]