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/