From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7744.txt | 1683 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1683 insertions(+) create mode 100644 doc/rfc/rfc7744.txt (limited to 'doc/rfc/rfc7744.txt') diff --git a/doc/rfc/rfc7744.txt b/doc/rfc/rfc7744.txt new file mode 100644 index 0000000..65d2763 --- /dev/null +++ b/doc/rfc/rfc7744.txt @@ -0,0 +1,1683 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Seitz, Ed. +Request for Comments: 7744 SICS Swedish ICT AB +Category: Informational S. Gerdes, Ed. +ISSN: 2070-1721 Universitaet Bremen TZI + G. Selander + Ericsson + M. Mani + Itron + S. Kumar + Philips Research + January 2016 + + + Use Cases for Authentication and Authorization + in Constrained Environments + +Abstract + + Constrained devices are nodes with limited processing power, storage + space, and transmission capacities. In many cases, these devices do + not provide user interfaces, and they are often intended to interact + without human intervention. + + This document includes a collection of representative use cases for + authentication and authorization in constrained environments. These + use cases aim at identifying authorization problems that arise during + the life cycle of a constrained device and are intended to provide a + guideline for developing a comprehensive authentication and + authorization solution for this class of scenarios. + + Where specific details are relevant, it is assumed that the devices + use the Constrained Application Protocol (CoAP) as a communication + protocol. However, most conclusions apply generally. + + + + + + + + + + + + + + + + + + +Seitz, et al. Informational [Page 1] + +RFC 7744 ACE Use Cases January 2016 + + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7744. + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + +Seitz, et al. Informational [Page 2] + +RFC 7744 ACE Use Cases January 2016 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Terminology ................................................4 + 2. Use Cases .......................................................5 + 2.1. Container Monitoring .......................................5 + 2.1.1. Bananas for Munich ..................................6 + 2.1.2. Authorization Problems Summary ......................7 + 2.2. Home Automation ............................................8 + 2.2.1. Controlling the Smart Home Infrastructure ...........8 + 2.2.2. Seamless Authorization ..............................8 + 2.2.3. Remotely Letting in a Visitor .......................9 + 2.2.4. Selling the House ...................................9 + 2.2.5. Authorization Problems Summary ......................9 + 2.3. Personal Health Monitoring ................................10 + 2.3.1. John and the Heart Rate Monitor ....................11 + 2.3.2. Authorization Problems Summary .....................12 + 2.4. Building Automation .......................................13 + 2.4.1. Device Life Cycle ..................................13 + 2.4.1.1. Installation and Commissioning ............13 + 2.4.1.2. Operational ...............................14 + 2.4.1.3. Maintenance ...............................15 + 2.4.1.4. Recommissioning ...........................16 + 2.4.1.5. Decommissioning ...........................16 + 2.4.2. Public Safety ......................................17 + 2.4.2.1. A Fire Breaks Out .........................17 + 2.4.3. Authorization Problems Summary .....................18 + 2.5. Smart Metering ............................................19 + 2.5.1. Drive-By Metering ..................................19 + 2.5.2. Meshed Topology ....................................20 + 2.5.3. Advanced Metering Infrastructure ...................20 + 2.5.4. Authorization Problems Summary .....................21 + 2.6. Sports and Entertainment ..................................22 + 2.6.1. Dynamically Connecting Smart Sports Equipment ......22 + 2.6.2. Authorization Problems Summary .....................23 + 2.7. Industrial Control Systems ................................23 + 2.7.1. Oil Platform Control ...............................23 + 2.7.2. Authorization Problems Summary .....................24 + 3. Security Considerations ........................................24 + 3.1. Attacks ...................................................25 + 3.2. Configuration of Access Permissions .......................26 + 3.3. Authorization Considerations ..............................26 + 3.4. Proxies ...................................................28 + 4. Privacy Considerations .........................................28 + 5. Informative References .........................................28 + Acknowledgments ...................................................29 + Authors' Addresses ................................................30 + + + + +Seitz, et al. Informational [Page 3] + +RFC 7744 ACE Use Cases January 2016 + + +1. Introduction + + Constrained devices [RFC7228] are nodes with limited processing + power, storage space, and transmission capacities. These devices are + often battery-powered and in many cases do not provide user + interfaces. + + Constrained devices benefit from being interconnected using Internet + protocols. However, deploying common security protocols can + sometimes be difficult because of device or network limitations. + Regardless, adequate security mechanisms are required to protect + these constrained devices, which are expected to be integrated in all + aspects of everyday life, from attackers wishing to gain control over + the device's data or functions. + + This document comprises a collection of representative use cases for + the application of authentication and authorization in constrained + environments. These use cases aim at identifying authorization + problems that arise during the life cycle of a constrained device. + Note that this document does not aim at collecting all possible use + cases. + + We assume that the communication between the devices is based on the + Representational State Transfer (REST) architectural style, i.e., a + device acts as a server that offers resources such as sensor data and + actuators. The resources can be accessed by clients, sometimes + without human intervention (M2M). In some situations, the + communication will happen through intermediaries (e.g., gateways, + proxies). + + Where specific detail is necessary, it is assumed that the devices + communicate using CoAP [RFC7252], although most conclusions are + generic. + +1.1. Terminology + + Readers are required to be familiar with the terms defined in + [RFC7228]. + + + + + + + + + + + + + +Seitz, et al. Informational [Page 4] + +RFC 7744 ACE Use Cases January 2016 + + +2. Use Cases + + This section includes the use cases; each use case first presents a + general description of the application environment, then one or more + specific use cases, and finally a summary of the authorization- + related problems to be solved. The document aims at listing the + relevant authorization problems and not to provide an exhaustive + list. It might not be possible to address all of the listed problems + with a single solution; there might be conflicting goals within or + among some requirements. + + There are various reasons for assigning a function (client or server) + to a device. The function may even change over time; e.g., the + device that initiates a conversation is temporarily assigned the role + of client, but could act as a server in another context. The + definition of the function of a device in a certain use case is not + in scope of this document. Readers should be aware that there might + be reasons for each setting and that endpoints might even have + different functions at different times. + +2.1. Container Monitoring + + The ability of sensors to communicate environmental data wirelessly + opens up new application areas. Sensor systems make it possible to + continuously track and transmit characteristics such as temperature, + humidity, and gas content while goods are transported and stored. + + Sensors in this scenario have to be associated with the appropriate + pallet of the respective container. Sensors, as well as the goods, + belong to specific customers. + + While in transit, goods often pass stops where they are transloaded + to other means of transportation, e.g., from ship transport to road + transport. + + Perishable goods need to be stored at a constant temperature and with + proper ventilation. Real-time information on the state of the goods + is needed by both the transporter and the vendor. Transporters want + to prioritize goods that will expire soon. Vendors want to react + when goods are spoiled to continue to fulfill delivery obligations. + + The Intelligent Container is an + example project that explores solutions to continuously monitor + perishable goods. + + + + + + + +Seitz, et al. Informational [Page 5] + +RFC 7744 ACE Use Cases January 2016 + + +2.1.1. Bananas for Munich + + A fruit vendor grows bananas in Costa Rica for the German market. It + instructs a transport company to deliver the goods via ship to + Rotterdam where they are picked up by trucks and transported to a + ripening facility. A Munich supermarket chain buys ripened bananas + from the fruit vendor and transports them from the ripening facility + to the individual markets with their own company's trucks. + + The fruit vendor's quality management wants to assure the quality of + their products; thus, it equips the banana boxes with sensors. The + state of the goods is monitored consistently during shipment and + ripening, and abnormal sensor values are recorded (U1.2). + Additionally, the sensor values are used to control the climate + within the cargo containers (U1.1, U1.5, U1.7). Therefore, the + sensors need to communicate with the climate-control system. Since + an incorrect sensor value leads to a wrong temperature, and thus to + spoiled goods, the integrity of the sensor data must be assured + (U1.2, U1.3). The banana boxes within a container will, in most + cases, belong to the same owner. Adjacent containers might contain + goods and sensors of different owners (U1.1). + + The personnel that transloads the goods must be able to locate the + goods meant for a specific customer (U1.1, U1.6, U1.7). However, the + fruit vendor does not want to disclose sensor information pertaining + to the condition of the goods to other companies and therefore wants + to assure the confidentiality of this data (U1.4). Thus, the + transloading personnel is only allowed to access logistic information + (U1.1). Moreover, the transloading personnel is only allowed to + access the data for the time of the transloading (U1.8). + + Due to the high water content of the fruits, the propagation of radio + waves is hindered, thus often inhibiting direct communication between + nodes [Jedermann14]. Instead, messages are forwarded over multiple + hops (U1.9). The sensors in the banana boxes cannot always reach the + Internet during the journey (U1.10). Sensors may need to use relay + stations owned by the transport company to connect to endpoints on + the Internet. + + In the ripening facility bananas are stored until they are ready to + be sold. The banana box sensors are used to control the ventilation + system and to monitor the degree of ripeness of the bananas. Ripe + bananas need to be identified and sold before they spoil (U1.2, + U1.8). + + The supermarket chain gains ownership of the banana boxes when the + bananas have ripened and are ready to leave the ripening facility. + + + + +Seitz, et al. Informational [Page 6] + +RFC 7744 ACE Use Cases January 2016 + + +2.1.2. Authorization Problems Summary + + U1.1: Fruit vendors and container owners want to grant different + authorizations for their resources and/or endpoints to + different parties. + + U1.2: The fruit vendor requires the integrity and authenticity of + the sensor data that pertains to the state of the goods for + climate control and to ensure the quality of the monitored + recordings. + + U1.3: The container owner requires the integrity and authenticity + of the sensor data that is used for climate control. + + U1.4: The fruit vendor requires the confidentiality of the sensor + data that pertains the state of the goods and the + confidentiality of location data, e.g., to protect them from + targeted attacks from competitors. + + U1.5: The fruit vendor may need different protection for several + different types of data on the same endpoint, e.g., sensor + data and the data used for logistics. + + U1.6: The fruit vendor and the transloading personnel require the + authenticity and integrity of the data that is used to locate + the goods, in order to ensure that the goods are correctly + treated and delivered. + + U1.7: The container owner and the fruit vendor may not be present + at the time of access and cannot manually intervene in the + authorization process. + + U1.8: The fruit vendor, container owner, and transloading company + want to grant temporary access permissions to a party, in + order to avoid giving permanent access to parties that are no + longer involved in processing the bananas. + + U1.9: The fruit vendor, container owner, and transloading company + want their security objectives to be achieved, even if the + messages between the endpoints need to be forwarded over + multiple hops. + + U1.10: The constrained devices might not always be able to reach the + Internet but still need to enact the authorization policies + of their principals. + + U1.11: Fruit vendors and container owners want to be able to revoke + authorization on a malfunctioning sensor. + + + +Seitz, et al. Informational [Page 7] + +RFC 7744 ACE Use Cases January 2016 + + +2.2. Home Automation + + One application of the Internet of Things is home automation systems. + Such a system can connect household devices that control, for + example, heating, ventilation, lighting, home entertainment, and home + security to the Internet making them remotely accessible and + manageable. + + Such a system needs to accommodate a number of regular users + (inhabitants, close friends, cleaning personnel) as well as a + heterogeneous group of dynamically varying users (visitors, + repairmen, delivery men). + + As the users are not typically trained in security (or even computer + use), the configuration must use secure default settings, and the + interface must be well adapted to novice users. + +2.2.1. Controlling the Smart Home Infrastructure + + Alice and Bob own a flat that is equipped with home automation + devices such as HVAC and shutter control, and they have a motion + sensor in the corridor that controls the light bulbs there (U2.5). + + Alice and Bob can control the shutters and the temperature in each + room using either wall-mounted touch panels or an Internet connected + device (e.g., a smartphone). Since Alice and Bob both have full-time + jobs, they want to be able to change settings remotely, e.g., turn up + the heating on a cold day if they will be home earlier than expected + (U2.5). + + The couple does not want people in radio range of their devices, + e.g., their neighbors, to be able to control them without + authorization. Moreover, they don't want burglars to be able to + deduce behavioral patterns from eavesdropping on the network (U2.8). + +2.2.2. Seamless Authorization + + Alice buys a new light bulb for the corridor and integrates it into + the home network, i.e., makes resources known to other devices in the + network. Alice makes sure that the new light bulb and her other + devices in the network get to know the authorization policies for the + new device. Bob is not at home, but Alice wants him to be able to + control the new device with his devices (e.g., his smartphone) + without the need for additional administration effort (U2.7). She + provides the necessary configurations for that (U2.9, U2.10). + + + + + + +Seitz, et al. Informational [Page 8] + +RFC 7744 ACE Use Cases January 2016 + + +2.2.3. Remotely Letting in a Visitor + + Alice and Bob have equipped their home with automated connected door- + locks and an alarm system at the door and the windows. The couple + can control this system remotely. + + Alice and Bob have invited Alice's parents over for dinner, but are + stuck in traffic and cannot arrive in time; whereas Alice's parents + are using the subway and will arrive punctually. Alice calls her + parents and offers to let them in remotely, so they can make + themselves comfortable while waiting (U2.1, U2.6). Then, Alice sets + temporary permissions that allow them to open the door and shut down + the alarm (U2.2). She wants these permissions to be only valid for + the evening since she does not like it if her parents are able to + enter the house as they see fit (U2.3, U2.4). + + When Alice's parents arrive at Alice and Bob's home, they use their + smartphone to communicate with the door-lock and alarm system (U2.5, + U2.9). The permissions Alice issued to her parents only allow + limited access to the house (e.g., opening the door, turning on the + lights). Certain other functions, such as checking the footage from + the surveillance cameras, are not accessible to them (U2.3). + + Alice and Bob also issue similarly restricted permissions to e.g., + cleaners, repairmen, or their nanny (U2.3). + +2.2.4. Selling the House + + Alice and Bob have to move because Alice is starting a new job. They + therefore decide to sell the house and transfer control of all + automated services to the new owners (U2.11). Before doing so, they + want to erase privacy-relevant data from the logs of the automated + systems, while the new owner is interested to keep some historic data + e.g., pertaining to the behavior of the heating system (U2.12). At + the time of transfer of ownership of the house, the new owners also + want to make sure that permissions issued by the previous owners to + access the house or connected devices (in the case where device + management may have separate permissions from house access) are no + longer valid (U2.13). + +2.2.5. Authorization Problems Summary + + U2.1: A home owner (Alice and Bob in the example above) wants to + spontaneously provision authorization means to visitors. + + U2.2: A home owner wants to spontaneously change the home's access + control policies. + + + + +Seitz, et al. Informational [Page 9] + +RFC 7744 ACE Use Cases January 2016 + + + U2.3: A home owner wants to apply different access rights for + different users (including other inhabitants). + + U2.4: The home owners want to grant access permissions to someone + during a specified time frame. + + U2.5: The smart home devices need to be able to securely + communicate with different control devices (e.g., wall- + mounted touch panels, smartphones, electronic key fobs, and + device gateways). + + U2.6: The home owner wants to be able to configure authorization + policies remotely. + + U2.7: Authorized users want to be able to obtain access with little + effort. + + U2.8: The owners of the automated home want to prevent unauthorized + entities from being able to deduce behavioral profiles from + devices in the home network. + + U2.9: Usability is particularly important in this scenario since + the necessary authorization related tasks in the life cycle + of the device (commissioning, operation, maintenance, and + decommissioning) likely need to be performed by the home + owners who, in most cases, have little knowledge of security. + + U2.10: Home owners want their devices to seamlessly (and in some + cases even unnoticeably) fulfill their purpose. Therefore, + the authorization administration effort needs to be kept at a + minimum. + + U2.11: Home owners want to be able to transfer ownership of their + automated systems when they sell the house. + + U2.12: Home owners want to be able to sanitize the logs of the + automated systems when transferring ownership without + deleting important operational data. + + U2.13: When a transfer of ownership occurs, the new owner wants to + make sure that access rights created by the previous owner + are no longer valid. + +2.3. Personal Health Monitoring + + Personal health monitoring devices, i.e., eHealth devices, are + typically battery-driven and located physically on or in the user to + monitor some bodily function, such as temperature, blood pressure, or + + + +Seitz, et al. Informational [Page 10] + +RFC 7744 ACE Use Cases January 2016 + + + pulse rate. These devices typically connect to the Internet through + an intermediary base station, using wireless technologies and through + this connection they report the monitored data to some entity, which + may either be the user or a medical caregiver. + + Medical data has always been considered very sensitive, and therefore + requires good protection against unauthorized disclosure. A + frequent, conflicting requirement is the capability for medical + personnel to gain emergency access, even if no specific access rights + exist. As a result, the importance of secure audit logs increases in + such scenarios. + + Since the users are not typically trained in security (or even + computer use), the configuration must use secure default settings, + and the interface must be well adapted to novice users. Parts of the + system must operate with minimal maintenance. Especially frequent + changes of battery are unacceptable. + + There is a plethora of wearable health monitoring technology and the + need for open industry standards to ensure interoperability between + products has lead to initiatives such as Continua Alliance + and Personal Connected Health Alliance + . + +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 location (U3.7). In the event of a cardiac + arrest, it automatically sends an alarm to an emergency service, + transmitting John's current location (U3.1). Either the device has + long-range connectivity itself (e.g., via GSM) or it uses some + intermediary, nearby device (e.g., John's smartphone) to transmit + such an alarm. To ensure John's safety, the device is expected to be + in constant operation (U3.3, U3.6). + + The device includes an authentication mechanism to prevent other + persons who get physical access to it from acting as the owner and + altering the access control and security settings (U3.8). + + John can configure a list of people 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 (U3.2). + + However, John is a privacy-conscious person and is worried that Jill + might use HeartGuard to monitor his location even when there is no + emergency. Furthermore, he doesn't want his health insurance to get + + + +Seitz, et al. Informational [Page 11] + +RFC 7744 ACE Use Cases January 2016 + + + access to the HeartGuard data, or even to the fact that he is wearing + a HeartGuard, since they might refuse to renew his insurance if they + decided he was too great of a risk for them (U3.8). + + Finally, John, while being comfortable with modern technology and + able to operate it reasonably well, is not trained in computer + security. Therefore, he needs an interface for the configuration of + the HeartGuard security that is easy to understand and use (U3.5). + If John does not understand the meaning of a setting, he tends to + leave it alone, assuming that the manufacturer has initialized the + device to secure settings (U3.4). + + Note: Monitoring of some state parameter (e.g., an alarm button) and + the position of a person also fits well into a nursing service + context. This is particularly useful for people suffering from + dementia, where the relatives or caregivers need to be notified of + the whereabouts of the person under certain conditions. In that + case, it is not the patient that decides about access. + +2.3.2. Authorization Problems Summary + + U3.1: The wearer of an eHealth device (John in the example above) + wants to preconfigure special access rights in the context of + an emergency. + + U3.2: The wearer of an eHealth device wants to selectively allow + different persons or groups access to medical data. + + U3.3: Battery changes are very inconvenient and sometimes + impractical, so battery life impacts on the authorization + mechanisms need to be minimized. + + U3.4: Devices are often used with default access control settings + that might threaten the security objectives of the device's + users. + + U3.5: Wearers of eHealth devices are often not trained in computer + use, especially computer security. + + U3.6: Security mechanisms themselves could provide opportunities for + denial-of-service (DoS) attacks, especially on the constrained + devices. + + U3.7: The device provides a service that can be fatal for the wearer + if it fails. Accordingly, the wearer wants the device to have + a high degree of resistance against attacks that may cause the + device to fail to operate partially or completely. + + + + +Seitz, et al. Informational [Page 12] + +RFC 7744 ACE Use Cases January 2016 + + + U3.8: The wearer of an eHealth device requires the integrity and + confidentiality of the data measured by the device. + +2.4. Building Automation + + Buildings for commercial use such as shopping malls or office + buildings nowadays are equipped increasingly with semi-automatic + components to enhance the overall living quality and to save energy + where possible. This includes for example heating, ventilation and + air condition (HVAC) as well as illumination and security systems + such as fire alarms. 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 companies. However, they also share some of the common + areas of the building. Accordingly, a company must be able to + control the lighting and HVAC system of its own part of the building + and must not have access to control rooms that belong to other + companies. + + Some parts of the building automation system such as entrance + illumination and fire-alarm systems are controlled either by all + parties together or by a facility-management company. + +2.4.1. Device Life Cycle + +2.4.1.1. Installation and Commissioning + + Installation of the building automation components often start even + 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, 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 + + + +Seitz, et al. Informational [Page 13] + +RFC 7744 ACE Use Cases January 2016 + + + 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, + e.g., HVAC equipment is 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 + often commissioned 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 is 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 specialists, such as lighting or HVAC + commissioners. + +2.4.1.2. Operational + + The building automation system 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 system 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 is also managed using + automated systems, such as a fire-alarm system, which is triggered by + several smoke detectors that are spread out across the building. + + Company A's staff moves into the newly furnished office space. Most + lighting is controlled by presence sensors that control the lighting + of a 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 offices by using the switches + + + + +Seitz, et al. Informational [Page 14] + +RFC 7744 ACE Use Cases January 2016 + + + 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 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 is annoyed that the lighting switches off too often + in their rooms if they work silently in front of their computers. + Company A notifies 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, hire 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 the BLMS to send a + configuration change to all lighting devices in Company A's offices + to increase the 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 (U4.13). + + A network-diagnostic tool of the BLMS detects that a luminaire in one + of Company A's offices 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 (e.g., the Media Access Control (MAC) address) + of the newly added device. Then, the BLMS authorizes the new device + in the system and seamlessly transfers all the permissions of the + previous broken device to the replacement device (U4.12). + + + + + + + + + + +Seitz, et al. Informational [Page 15] + +RFC 7744 ACE Use Cases January 2016 + + +2.4.1.4. Recommissioning + + A vacant area of the building has recently been leased to Company A. + Before moving into its new office, Company A wishes to replace the + lighting with more energy efficient and better light quality + luminaries. They hire an installation and commissioning Company C to + redo the illumination. Company C is instructed to integrate the new + lighting devices, which may be from multiple manufacturers, into the + existing lighting infrastructure of the building, which includes + presence sensors, switches, controllers, etc. (U4.1). + + Company C gets the necessary authorization from the facility- + management company to interact with the existing BLMS (U4.4). To + prevent disturbance to other occupants of the building, Company C is + provided authorization to perform the commissioning only during non- + office hours and only to modify configuration on devices belonging to + the domain of Company A's space (U4.5). Before removing existing + devices, all security and configuration material that belongs to the + domain is 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 Company A's + lighting domain. + + Once the devices are in the correct domain, the commissioner + authorizes the interaction rules between the new lighting devices and + existing devices, like presence sensors (U4.7). For this, the + commissioner creates the authorization rules on the BLMS that define + which lights form a group and which sensors/switches/controllers are + allowed to control which groups (U4.8). These authorization rules + may be context based, like time of the day (office or non-office + hours) or location of the handheld lighting controller, etc. (U4.5). + +2.4.1.5. Decommissioning + + Company A has noticed that the handheld controllers are often + misplaced and hard to find when needed. So most of the time, staff + use the existing wall switches for manual control. Company A decides + it would be better to completely remove handheld controllers and asks + Company C to decommission them from the lighting system (U4.4). + + Company C again gets the necessary authorization from the facility- + management company to interact with the BLMS. The commissioner now + deletes any rules that allowed handheld controllers authorization to + control the lighting (U4.3, U4.6). Additionally, the commissioner + instructs the BLMS to push these new rules to prevent cached rules at + + + + +Seitz, et al. Informational [Page 16] + +RFC 7744 ACE Use Cases January 2016 + + + the end devices from being used. Any cryptographic key material + belonging to the site in the handheld controllers is also removed, + and they are set to the factory state (U4.3). + +2.4.2. Public Safety + + As part of the building safety code, the fire department requires + that the building have sensors that sense the level of smoke, heat, + etc., when a fire breaks out. These sensors report metrics that are + then used by a back-end server to map safe areas and unsafe areas + within a building and possibly the structural integrity of the + building before firefighters may enter it. + Sensors may also be used to track where human/animal activity is + within the building. This will allow people stuck in the building to + be guided to safer areas and allow the suggestion of possible actions + that they may take (e.g., using a client application on their phones + or giving loudspeaker directions) in order to bring them to safety. + In certain cases, other organizations such as the police, ambulance, + and federal organizations are also involved and therefore the co- + ordination of tasks between the various entities have to be carried + out using efficient messaging and authorization mechanisms. + +2.4.2.1. A Fire Breaks Out + + James, who works for Company A, turns on the air conditioning in his + office on a really hot day. Lucy, who works for Company B, wants to + make tea using an electric kettle. After she turns it on, she goes + outside to talk to a colleague until the water is boiling. + Unfortunately, her kettle has a malfunction that causes overheating + and results in a smoldering fire of the kettle's plastic case. + + Due to the smoke coming from the kettle, the fire alarm is triggered. + Alarm sirens throughout the building are switched on simultaneously + (using a group communication scheme) to alert the staff of both + companies (U4.8). 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, even though he turned on his air conditioning, because the + fire alarm overrides the manual setting by sending commands (using + group communication) to switch off all the air conditioning (U4.10). + + The fire department is notified of the fire automatically and arrives + within a short time. They automatically get access to all parts of + the building according to an emergency authorization policy (U4.4, + U4.5). After inspecting the damage and extinguishing the smoldering + fire, a firefighter resets the fire alarm because only the fire + department is authorized to do that (U4.4, U4.11). + + + + +Seitz, et al. Informational [Page 17] + +RFC 7744 ACE Use Cases January 2016 + + +2.4.3. Authorization Problems Summary + + U4.1: During commissioning, the building owner or the companies add + new devices to their administrative domain. Access control + should then apply to these devices seamlessly. + + U4.2: During a handover, the building owner or the companies + integrate devices that formerly belonged to a different + administrative domain to their own administrative domain. + Access control of the old domain should then cease to apply, + with access control of the new domain taking over. + + U4.3: During decommissioning, the building owner or the companies + remove devices from their administrative domain. Access + control should cease to apply to these devices and relevant + credentials need to be erased from the devices. + + U4.4: The building owner and the companies want to be able to + delegate specific access rights for their devices to others. + + U4.5: The building owner and the companies want to be able to + define context-based authorization rules. + + U4.6: The building owner and the companies want to be able to + revoke granted permissions and delegations. + + U4.7: The building owner and the companies want to allow authorized + entities to send data to their endpoints (default deny). + + U4.8: The building owner and the companies want to be able to + authorize a device to control several devices at the same + time using a group communication scheme. + + U4.9: The companies want to be able to interconnect their own + subsystems with those from a different operational domain + while keeping the control over the authorizations (e.g., + granting and revoking permissions) for their endpoints and + devices. + + U4.10: The authorization mechanisms must be able to cope with + extremely time-sensitive operations that have to be carried + out quickly. + + U4.11: The building owner and the public safety authorities want to + be able to perform data origin authentication on messages + sent and received by some of the systems in the building. + + + + + +Seitz, et al. Informational [Page 18] + +RFC 7744 ACE Use Cases January 2016 + + + 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. + + U4.13: When software on a device is updated, this update needs to be + authenticated and authorized. + +2.5. Smart Metering + + Automated measuring of customer consumption is an established + technology for electricity, water, and gas providers. Increasingly, + these systems also feature networking capability to allow for remote + management. Such systems are in use for commercial, industrial, and + residential customers and require a certain level of security, in + order to avoid economic loss to the providers, vulnerability of the + distribution system, as well as disruption of services for the + customers. + + The smart metering equipment for gas and water solutions is battery- + driven and communication should be used sparingly due to battery + consumption. Therefore, these types of meters sleep most of the + time, and only wake up every minute/hour to check for incoming + instructions. Furthermore, they wake up a few times a day (based on + their configuration) to upload their measured metering data. + + Different networking topologies exist for smart metering solutions. + Based on environment, regulatory rules, and expected cost, one or a + mixture of these topologies may be deployed to collect the metering + information. Drive-by metering is one of the most current solutions + deployed for collection of gas and water meters. + + Various stakeholders have a claim on the metering data. Utility + companies need the data for accounting, the metering equipment may be + operated by a third-party service operator who needs to maintain it, + and the equipment is installed in the premises of the consumers, + measuring their consumption, which entails privacy questions. + +2.5.1. Drive-By Metering + + A service operator offers smart metering infrastructures and related + services to various utility companies. Among these is a water + provider, who in turn supplies several residential complexes in a + city. The smart meters are installed in the end customer's homes to + measure water consumption and thus generate billing data for the + utility company. They can also be used to shut off the water if the + bills are not paid (U5.1, U5.3). The meters do this by sending and + + + +Seitz, et al. Informational [Page 19] + +RFC 7744 ACE Use Cases January 2016 + + + receiving data to and from a base station (U5.2). Several base + stations are installed around the city to collect the metering data. + However, in the denser urban areas, the base stations would have to + be installed very close to the meters. This would require a high + number of base stations and expose this more expensive equipment to + manipulation or sabotage. The service operator has therefore chosen + another approach, which is to drive around with a mobile base station + and let the meters connect to that in regular intervals in order to + gather metering data (U5.4, U5.6, U5.8). + +2.5.2. Meshed Topology + + In another deployment, the water meters are installed in a building + that already has power meters installed, the latter are mains + powered, and are therefore not subject to the same power saving + restrictions. The water meters can therefore use the power meters as + proxies, in order to achieve better connectivity. This requires the + security measures on the water meters to work through intermediaries + (U5.9). + +2.5.3. Advanced Metering Infrastructure + + A utility company is updating its old utility distribution network + with advanced meters and new communication systems, known as an + Advanced Metering Infrastructure (AMI). AMI refers to a system that + measures, collects, and analyzes usage, and interacts with metering + devices such as electricity meters, gas meters, heat meters, and + water meters, through various communication media either on request + (on-demand) or on predefined schedules. Based on this technology, + new services make it possible for consumers to control their utility + consumption (U5.2, U5.7) and reduce costs by supporting new tariff + models from utility companies, and more accurate and timely billing. + However, the end consumers do not want unauthorized persons to gain + access to this data. Furthermore, the fine-grained measurement of + consumption data may induce privacy concerns, since it may allow + others to create behavioral profiles (U5.5, U5.10). + + The technical solution is based on levels of data aggregation between + smart meters located at the consumer premises and the Meter Data + Management (MDM) system located at the utility company (U5.9). For + reasons of efficiency and cost, end-to-end connectivity is not always + feasible, so metering data is stored and aggregated in various + intermediate devices before being forwarded to the utility company, + and in turn accessed by the MDM. The intermediate devices may be + operated by a third-party service operator on behalf of the utility + company (U5.7). One responsibility of the service operator is to + make sure that meter readings are performed and delivered in a + regular, timely manner. An example of a Service Level Agreement + + + +Seitz, et al. Informational [Page 20] + +RFC 7744 ACE Use Cases January 2016 + + + between the service operator and the utility company is, for example, + at least 95% of the meters have readings recorded during the last 72 + hours. + +2.5.4. Authorization Problems Summary + + U5.1: Devices are installed in hostile environments where they are + physically accessible by attackers (including dishonest + customers). The service operator and the utility company + want to make sure that an attacker cannot use data from a + captured device to attack other parts of their + infrastructure. + + U5.2: The utility company wants to control which entities are + allowed to send data to, and read data from, their endpoints. + + U5.3: The utility company wants to ensure the integrity of the data + stored on their endpoints. + + U5.4: The utility company wants to protect such data transfers to + and from their endpoints. + + U5.5: Consumers want to access their own usage information and also + prevent unauthorized access by others. + + U5.6: The devices may have intermittent Internet connectivity but + still need to enact the authorization policies of their + principals. + + U5.7: Neither the service operator nor the utility company are + always present at the time of access and cannot manually + intervene in the authorization process. + + U5.8: When authorization policies are updated it is impossible, or + at least very inefficient to contact all affected endpoints + directly. + + U5.9: Authorization and authentication must work even if messages + between endpoints are stored and forwarded over multiple + nodes. + + U5.10: Consumers may not want the service operator, the utility + company or others to have access to a fine-grained level of + consumption data that allows the creation of behavioral + profiles. + + + + + + +Seitz, et al. Informational [Page 21] + +RFC 7744 ACE Use Cases January 2016 + + +2.6. Sports and Entertainment + + In the area of leisure-time activities, applications can benefit from + the small size and weight of constrained devices. Sensors and + actuators with various functions can be integrated into fitness + equipment, games, and even clothes. Users can carry their devices + around with them at all times. + + Usability is especially important in this area since users will often + want to spontaneously interconnect their devices with others. + Therefore, the configuration of access permissions must be simple and + fast and not require much effort at the time of access. + + Continuously monitoring allows authorized users to create behavioral + or movement profiles, that correspond to the devices' intended use, + and unauthorized access to the collected data would allow an attacker + to create the same profiles. + Moreover, the aggregation of data can seriously increase the impact + on the privacy of the users. + +2.6.1. Dynamically Connecting Smart Sports Equipment + + Jody is an enthusiastic runner. To keep track of her training + progress, she has smart running shoes that measure the pressure at + various points beneath her feet to count her steps, detect + irregularities in her stride, and help her to improve her posture and + running style. On a sunny afternoon, she goes to the Finnbahn track + near her home to work out. She meets her friend Lynn, who shows her + the smart fitness watch she bought a few days ago. The watch can + measure the wearer's pulse, show speed and distance, and keep track + of the configured training program. The girls realize that the watch + can be connected with Jody's shoes and can display the information + the shoes provide. + + Jody asks Lynn to let her try the watch and lend it to her for the + afternoon. Lynn agrees, but she doesn't want Jody to access her + training plan (U6.4). She configures the access policies for the + watch so that Jody's shoes are allowed to access the display and + measuring features but cannot read or add training data (U6.1, U6.2). + Jody's shoes connect to Lynn's watch at the press of a button, + because Jody already configured access rights for devices that belong + to Lynn a while ago (U6.3). Jody wants the device to report the data + back to her fitness account while she borrows it, so she allows it to + access her account temporarily. + + After an hour, Jody gives the watch back and both girls terminate the + connection between their devices. + + + + +Seitz, et al. Informational [Page 22] + +RFC 7744 ACE Use Cases January 2016 + + +2.6.2. Authorization Problems Summary + + U6.1: Sports equipment owners want to be able to grant access rights + dynamically when needed. + + U6.2: Sports equipment owners want the configuration of access + rights to work with very little effort. + + U6.3: Sports equipment owners want to be able to preconfigure access + policies that grant certain access permissions to endpoints + with certain attributes (e.g., endpoints of a certain user) + without additional configuration effort at the time of access. + + U6.4: Sports equipment owners want to protect the confidentiality of + their data for privacy reasons. + +2.7. Industrial Control Systems + + Industrial control systems (ICS) and especially supervisory control + and data acquisition systems (SCADA) use a multitude of sensors and + actuators in order to monitor and control industrial processes in the + physical world. Example processes include manufacturing, power + generation, and refining of raw materials. + + Since the advent of the Stuxnet worm, it has become obvious to the + general public how vulnerable these kind of systems are, especially + when connected to the Internet [Karnouskos11]. The severity of these + vulnerabilities are exacerbated by the fact that many ICS are used to + control critical public infrastructure, such as nuclear power, water + treatment, or traffic control. Nevertheless, the economical + advantages of connecting such systems to the Internet can be + significant if appropriate security measures are put in place (U7.5). + +2.7.1. Oil Platform Control + + An oil platform uses an industrial control system to monitor data and + control equipment. The purpose of this system is to gather and + process data from a large number of sensors and control actuators + such as valves and switches to steer the oil extraction process on + the platform. Raw data, alarms, reports, and other information are + also available to the operators, who can intervene with manual + commands. Many of the sensors are connected to the controlling units + by direct wire, but the operator is slowly replacing these units by + wireless ones, since this makes maintenance easier (U7.4). + + Some of the controlling units are connected to the Internet, to allow + for remote administration, since it is expensive and inconvenient to + fly in a technician to the platform (U7.3). + + + +Seitz, et al. Informational [Page 23] + +RFC 7744 ACE Use Cases January 2016 + + + The main interest of the operator is to ensure the integrity of + control messages and sensor readings (U7.1). Access in some cases + needs to be restricted, e.g., the operator wants wireless actuators + only to accept commands by authorized control units (U7.2). + + The owner of the platform also wants to collect auditing information + for liability reasons (U7.1). + + Different levels of access apply e.g., for regular operators vs. + maintenance technician vs. auditors of the platform (U7.6). + +2.7.2. Authorization Problems Summary + + U7.1: The operator of the platform wants to ensure the integrity and + confidentiality of sensor and actuator data. + + U7.2: The operator wants to ensure that data coming from sensors and + commands sent to actuators are authentic. + + U7.3: Some devices do not have direct Internet connection, but they + still need to implement current authorization policies. + + U7.4: Devices need to authenticate the controlling units, especially + those using a wireless connection. + + U7.5: The execution of unauthorized commands or the failure to + execute an authorized command in an ICS can lead to + significant financial damage and threaten the availability of + critical infrastructure services. Accordingly, the operator + wants authentication and authorization mechanisms that provide + a very high level of security. + + U7.6: Different users should have different levels of access to the + control system (e.g., operator vs. auditor). + +3. Security Considerations + + As the use cases listed in this document demonstrate, constrained + devices are used in various environments. These devices are small + and inexpensive and this makes it easy to integrate them into many + aspects of everyday life. With access to vast amounts of valuable + data and possible control of important functions, these devices need + to be protected from unauthorized access. Protecting seemingly + innocuous data and functions will lessen the possible effects of + aggregation; attackers collecting data or functions from several + sources can gain insights or a level of control not immediately + obvious from each of these sources on its own. + + + + +Seitz, et al. Informational [Page 24] + +RFC 7744 ACE Use Cases January 2016 + + + Not only the data on the constrained devices themselves is + threatened, the devices might also be abused as an intrusion point to + infiltrate a network. Once an attacker gains control over the + device, it can be used to attack other devices as well. Due to their + limited capabilities, constrained devices appear as the weakest link + in the network; hence, they pose an attractive target for attackers. + + This section summarizes the security problems highlighted by the use + cases above and provides guidelines for the design of protocols for + authentication and authorization in constrained RESTful environments. + +3.1. Attacks + + This document lists security problems that users of constrained + devices want to solve. Further analysis of attack scenarios is not + in scope of the document. However, there are attacks that must be + considered by solution developers. + + Because of the expected large number of devices and their ubiquity, + constrained devices increase the danger from Pervasive Monitoring + [RFC7258] attacks. Solution Designers should consider this in the + design of their security solution and provide for protection against + this type of attack. In particular, messages containing sensitive + data that are sent over unprotected channels should be encrypted if + possible. + + Attacks aimed at altering data in transit (e.g., to perpetrate fraud) + are a problem that is addressed in many web security protocols such + as TLS or IPsec. Developers need to consider these types of attacks, + and make sure that the protection measures they implement are adapted + to the constrained environment. + + As some of the use cases indicate, constrained devices may be + installed in hostile environments where they are physically + accessible (see Section 2.5). Protection from physical attacks is + not in the scope of this document, but it should be kept in mind by + developers of authorization solutions. + + Denial-of-service (DoS) attacks threaten the availability of services + a device provides and constrained devices are especially vulnerable + to these types of attacks because of their limitations. Attackers + can illicit a temporary or, if the battery is drained, permanent + failure in a service simply by repeatedly flooding the device with + connection attempts; for some services (see Section 2.3), + availability is especially important. Solution designers must be + particularly careful to consider the following limitations in every + part of the authorization solution: + + + + +Seitz, et al. Informational [Page 25] + +RFC 7744 ACE Use Cases January 2016 + + + o Battery usage + + o Number of required message exchanges + + o Size of data that is transmitted (e.g., authentication and access + control data) + + o Size of code required to run the protocols + + o Size of RAM memory and stack required to run the protocols + + 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 + be protected from information disclosure and tampering. + +3.2. Configuration of Access Permissions + + o The access control policies need to be enforced (all use cases): + The information that is needed to implement the access control + policies needs to be provided to the device that enforces the + authorization and applied to every incoming request. + + o A single resource might have different access rights for different + requesting entities (all use cases). + + Rationale: In some cases, different types of users need different + access rights, as opposed to a binary approach where the same + access permissions are granted to all authenticated users. + + o A device might host several resources where each resource has its + own access control policy (all use cases). + + o The device that makes the policy decisions should be able to + evaluate context-based permissions such as location or time of + access (see Sections 2.2, 2.3, and 2.4). Access may depend on + local conditions, e.g., access to health data in an emergency. + The device that makes the policy decisions should be able to take + such conditions into account. + +3.3. Authorization Considerations + + o Devices need to be enabled to enforce authorization policies + without human intervention at the time of the access request (see + Sections 2.1, 2.2, 2.4, and 2.5). + + + + + +Seitz, et al. Informational [Page 26] + +RFC 7744 ACE Use Cases January 2016 + + + o Authorization solutions need to consider that constrained devices + might not have Internet access at the time of the access request + (see Sections 2.1, 2.3, 2.5, and 2.6). + + o It should be possible to update access control policies without + manually re-provisioning individual devices (see Sections 2.2, + 2.3, 2.5, and 2.6). + + Rationale: Peers can change rapidly which makes manual + re-provisioning unreasonably expensive. + + o Authorization policies may be defined to apply to a large number + of devices that might only have intermittent connectivity. + Distributing policy updates to every device for every update might + not be a feasible solution (see Section 2.5). + + o It must be possible to dynamically revoke authorizations (see + Section 2.4 for example). + + o The authentication and access control protocol can put undue + burden on the constrained system resources of a device + participating in the protocol. An authorization solution must + take the limitations of the constrained devices into account (all + use cases, see also Section 3.1). + + o Secure default settings are needed for the initial state of the + authentication and authorization protocols (all use cases). + + Rationale: Many attacks exploit insecure default settings, and + experience shows that default settings are frequently left + unchanged by the end users. + + o Access to resources on other devices should only be permitted if a + rule exists that explicitly allows this access (default deny) (see + Section 2.4 for example). + + o Usability is important for all use cases. The configuration of + authorization policies as well as the gaining access to devices + must be simple for the users of the devices. Special care needs + to be taken for scenarios where access control policies have to be + configured by users that are typically not trained in security + (see Sections 2.2, 2.3, and 2.6). + + o Software updates are an important operation for which correct + authorization is crucial. Additionally, authenticating the + receiver of a software update is also important, for example, to + make sure that the update has been received by the intended + device. + + + +Seitz, et al. Informational [Page 27] + +RFC 7744 ACE Use Cases January 2016 + + +3.4. Proxies + + In some cases, the traffic between endpoints might go through + intermediary nodes (e.g., proxies, gateways). This might affect the + function or the security model of authentication and access control + protocols e.g., end-to-end security between endpoints with Datagram + Transport Layer Security (DTLS) might not be possible (see + Section 2.5). + +4. Privacy Considerations + + The constrained devices in focus of this document either collect data + from the physical world via sensors or affect their surroundings via + actuators. The collected and processed data often can be associated + with individuals. Since sensor data may be collected and distributed + on a regular interval, a significant amount of information about an + individual can be collected and used as input for learning algorithms + as part of big data analysis and used in an automated decision making + process. + + Offering privacy protection for individuals is important to guarantee + that only authorized entities are allowed to access collected data, + to trigger actions, to obtain consent prior to the sharing of data, + and to deal with other privacy-related threats outlined in RFC 6973. + + RFC 6973 was written as guidance for engineers designing technical + solutions. For a short description about the deployment-related + aspects of privacy and further references relevant for the Internet + of Things sector, please see Section 7 of RFC 7452. + +5. Informative References + + [Jedermann14] + Jedermann, R., Poetsch, T., and C. LLoyd, "Communication + techniques and challenges for wireless food quality + monitoring", Philosophical Transactions of the Royal + Society A Mathematical, Physical and Engineering Sciences, + May 2014, . + + [Karnouskos11] + Karnouskos, S., "Stuxnet Worm Impact on Industrial Cyber- + Physical System Security", IECON 2011 - 37th Annual + Conference on IEEE Industrial Electronics Society, pp. + 4490-4494 10.1109/econ.2011.612.0048, November 2011, + . + + + + +Seitz, et al. Informational [Page 28] + +RFC 7744 ACE Use Cases January 2016 + + + [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for + Constrained-Node Networks", RFC 7228, + DOI 10.17487/RFC7228, May 2014, + . + + [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained + Application Protocol (CoAP)", RFC 7252, + DOI 10.17487/RFC7252, June 2014, + . + + [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an + Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May + 2014, . + +Acknowledgments + + The authors would like to thank Olaf Bergmann, Sumit Singhal, John + Mattson, Mohit Sethi, Carsten Bormann, Martin Murillo, Corinna + Schmitt, Hannes Tschofenig, Erik Wahlstroem, Andreas Baeckman, Samuel + Erdtman, Steve Moore, Thomas Hardjono, Kepeng Li, Jim Schaad, + Prashant Jhingran, Kathleen Moriarty, and Sean Turner for reviewing + and/or contributing to the document. Also, thanks to Markus Becker, + Thomas Poetsch, and Koojana Kuladinithi for their input on the + container monitoring use case. Furthermore, the authors thank Akbar + 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 + EIT-ICT Labs activity PST-14056; and as part of the CelticPlus + project CyberWI, with funding from Vinnova. + + + + + + + + + + + + + + + + + + + + + +Seitz, et al. Informational [Page 29] + +RFC 7744 ACE Use Cases January 2016 + + +Authors' Addresses + + Ludwig Seitz (editor) + SICS Swedish ICT AB + Scheelevaegen 17 + Lund 223 70 + Sweden + + Email: ludwig@sics.se + + + Stefanie Gerdes (editor) + Universitaet Bremen TZI + Postfach 330440 + Bremen 28359 + Germany + + Phone: +49-421-218-63906 + Email: gerdes@tzi.org + + + Goeran Selander + Ericsson + Faroegatan 6 + Kista 164 80 + Sweden + + Email: goran.selander@ericsson.com + + + Mehdi Mani + Itron + 52, rue Camille Desmoulins + Issy-les-Moulineaux 92130 + France + + Email: Mehdi.Mani@itron.com + + + Sandeep S. Kumar + Philips Research + High Tech Campus + Eindhoven 5656 AA + The Netherlands + + Email: sandeep.kumar@philips.com + + + + + +Seitz, et al. Informational [Page 30] + -- cgit v1.2.3