RFC 7744

Use Cases for Authentication and Authorization in Constrained Environments

📅 published January 2016, from ietf

RFC 7744: Use Cases for Authentication and Authorization in Constrained Environments 🎀

okay so bestie, here's the vibe check on this one ✨ It's an Informational doc from January 2016, so it's not a Standards Track spec. It's a collection of use cases that the IETF published on purpose. The editors are L. Seitz (SICS Swedish ICT AB) and S. Gerdes (Universitaet Bremen TZI), both listed as Ed., plus G. Selander (Ericsson), M. Mani (Itron), and S. Kumar (Philips Research). It's part of the ISSN 2070-1721 series. There's no Obsoletes or Updates line in the header, so nothing gets replaced or changed by it 💅

Abstract

Constrained devices are nodes with limited processing power, storage space, and transmission capacities. 🔋 In a lot of cases these devices have no user interface, and they're often meant to talk to each other without a human involved at all 🤖

This document is a bunch of representative use cases for authentication and authorization in constrained environments. The goal is to spot the authorization problems that pop up over a device's whole life cycle, and to give you a guideline for building a complete authentication and authorization solution for this kind of scenario 🧚

When specifics matter, the devices are assumed to use the Constrained Application Protocol (CoAP) as their communication protocol. But most of the conclusions apply more broadly 🌈

Status of This Memo

This document is not an Internet Standards Track specification. It's 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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, see Section 2 of RFC 5741 🫶

For info about the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7744 📚

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) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document. Code Components extracted from this document must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 📜

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

1. Introduction ✨

Constrained devices [RFC7228] are nodes with limited processing power, storage space, and transmission capacities. These devices are often battery-powered, and in lots of cases they don't have user interfaces 🔋

Constrained devices benefit from being hooked up with Internet protocols. But putting common security protocols on them can be tricky because of device or network limitations. Even so, adequate security mechanisms are required to protect these constrained devices from attackers who want control over the device's data or functions. And these devices are supposed to be part of everyday life in every way 🏠🔐

This document is a collection of representative use cases for applying authentication and authorization in constrained environments. The use cases aim to identify the authorization problems that come up during a constrained device's life cycle. Note that this document does not try to collect every possible use case 🙈

We assume the devices communicate using the Representational State Transfer (REST) architectural style. So a device acts as a server offering resources, like sensor data and actuators. Clients can access those resources, sometimes with no human intervention (M2M). In some situations, the communication goes through intermediaries, like gateways and proxies 🌸

When specific detail is needed, the devices are assumed to communicate using CoAP [RFC7252], though most of the conclusions are generic 🦋

1.1. Terminology

Readers are required to be familiar with the terms defined in [RFC7228] 📖

2. Use Cases 💅

This section has the use cases. Each use case first gives 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 to list the relevant authorization problems, not to provide an exhaustive list. It might not be possible to address all of the listed problems with a single solution, and there might be conflicting goals within or among some requirements 🧩

There are lots of reasons for assigning a function (client or server) to a device. The function may even change over time. For example, the device that starts a conversation is temporarily given the role of client, but it could act as a server in another context. How a device's function is defined in a given use case is out of scope for this document. Just know there might be a reason for each setting, and endpoints might even have different functions at different times 👑

2.1. Container Monitoring 🦋

Sensors that can communicate environmental data wirelessly open up totally new application areas. Sensor systems make it possible to continuously track and transmit things like temperature, humidity, and gas content while goods are being transported and stored 🍓

Sensors in this scenario have to be associated with the right pallet of the respective container. Both the sensors and the goods belong to specific customers 🎀

While in transit, goods often stop at places where they get 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 so they can keep fulfilling delivery obligations 😭

The Intelligent Container http://www.intelligentcontainer.com is an example project that explores solutions for continuously monitoring perishable goods. It's giving innovation 🧚✨

2.1.1. Bananas for Munich 🍌

Okay bestie, picture this: a fruit vendor grows bananas in Costa Rica for the German market 🇩🇪 They tell a transport company to ship everything by boat to Rotterdam. Trucks pick the bananas up there and haul them to a ripening facility. Then a Munich supermarket chain buys the ripe bananas from the vendor and drives them from the ripening facility to its individual stores in its own company trucks 🚚💨

The fruit vendor's quality team wants the product to be 🔥, so they stick sensors on the banana boxes 📦 The goods get monitored the whole time, through shipping and ripening, and any weird sensor readings get logged (U1.2). The sensor data also controls the climate inside the cargo containers (U1.1, U1.5, U1.7), so the sensors have to talk to the climate-control system. One wrong sensor reading means the wrong temperature, and then the bananas are toast 😭 So the integrity of the sensor data must be assured (U1.2, U1.3). Boxes inside one container usually belong to the same owner, but neighboring containers can hold goods and sensors from different owners (U1.1).

The staff who transload the goods need to find the ones meant for a specific customer (U1.1, U1.6, U1.7). But the vendor doesn't want other companies seeing sensor info about how the goods are doing, so confidentiality has to be locked down (U1.4). That means transloading staff can only access logistic information (U1.1), and they can only touch the data for the length of the transloading (U1.8).

Fruit is super watery, and that messes with radio waves 💦 so nodes often can't talk to each other directly [Jedermann14]. Messages get forwarded over multiple hops instead (U1.9). The sensors also can't always reach the Internet during the trip (U1.10), so they may need to go through relay stations owned by the transport company to reach endpoints on the Internet.

At the ripening facility, the bananas hang out until they're ready to sell. The box sensors run the ventilation and keep track of how ripe the bananas are. Ripe bananas have to be spotted and sold before they spoil (U1.2, U1.8).

The supermarket chain takes ownership of the banana boxes once the bananas have ripened and are ready to leave the facility 🎉

2.1.2. Authorization Problems Summary 📋

  • U1.1: Fruit vendors and container owners want to hand out different permissions for their resources and/or endpoints to different parties. 🔑
  • U1.2: The fruit vendor needs the integrity and authenticity of the sensor data about the state of the goods, both for climate control and to make sure the monitoring records are legit. ✅
  • U1.3: The container owner needs the integrity and authenticity of the sensor data used for climate control. 🌡️
  • U1.4: The fruit vendor needs the sensor data about the state of the goods kept confidential, plus the location data, so competitors can't launch targeted attacks. 🕵️
  • U1.5: The fruit vendor might need different protection for different types of data on the same endpoint, like sensor data versus logistics data. 🗂️
  • U1.6: The fruit vendor and the transloading personnel need the authenticity and integrity of the data used to locate the goods, so the goods get treated and delivered correctly. 📍
  • U1.7: The container owner and the fruit vendor might not be around when access happens, and they can't step in by hand to approve the authorization. 😴
  • U1.8: The fruit vendor, container owner, and transloading company want to hand out temporary access, so nobody keeps permanent access after they stop being involved with the bananas. ⏳
  • U1.9: The fruit vendor, container owner, and transloading company want their security goals met even when messages have to hop across multiple nodes. 🦘
  • U1.10: The constrained devices might not always reach the Internet, but they still have to enforce the authorization policies of their principals. 📡
  • U1.11: Fruit vendors and container owners want to be able to revoke authorization from a malfunctioning sensor. 🚫

2.2. Home Automation 🏡

One application of the Internet of Things is home automation. A system like this connects household devices that control things like heating, ventilation, lighting, home entertainment, and home security to the Internet, so you can reach and manage them remotely 📱✨

The system has to handle a bunch of regular users (inhabitants, close friends, cleaning staff) along with a mixed bag of users who keep changing (visitors, repairmen, delivery folks) 👥

Most users aren't trained in security (or even in using computers), so the configuration must use secure defaults, and the interface must be really easy for total novices to use 🫶

2.2.1. Controlling the Smart Home Infrastructure 🎛️

Alice and Bob own a flat full of home automation gadgets like HVAC and shutter control. They also have a motion sensor in the hallway that turns on the light bulbs there (U2.5).

Alice and Bob can control the shutters and the temperature in each room from wall-mounted touch panels or from an Internet-connected device (like a smartphone). Both of them have full-time jobs, so they want to change settings remotely, like cranking up the heat on a cold day when they're getting home early (U2.5).

The couple doesn't want anyone in radio range of their devices (neighbors, for example) to control them without permission 🙅‍♀️ They also don't want burglars to figure out their daily routines by eavesdropping on the network (U2.8).

2.2.2. Seamless Authorization ✨

Alice buys a new light bulb for the hallway and adds it to the home network, which means making its resources known to the other devices on the network. Alice makes sure the new bulb and her other devices learn the authorization policies for it. Bob isn't home, but Alice wants him to control the new device from his own devices (like his smartphone) without any extra admin work (U2.7). So she sets up the configurations for that (U2.9, U2.10).

2.2.3. Remotely Letting in a Visitor 🚪

Alice and Bob have set up their home with connected door locks and an alarm system covering the door and windows. The couple can run this system remotely.

Alice and Bob invited Alice's parents over for dinner, but they're stuck in traffic and can't get home in time. Alice's parents are on the subway and will arrive right on time 🚇 Alice calls her parents and offers to let them in remotely, so they can relax while they wait (U2.1, U2.6). Then she sets up temporary permissions that let them open the door and shut off the alarm (U2.2). She wants these permissions to expire that same evening, because she doesn't love the idea of her parents wandering into the house whenever they feel like it (U2.3, U2.4).

When Alice's parents show up, they use their smartphone to talk to the door-lock and alarm system (U2.5, U2.9). The permissions Alice gave them only allow limited access to the house (like opening the door and turning on the lights). Other stuff, like checking the surveillance camera footage, is off-limits for them (U2.3).

Alice and Bob also hand out similarly limited permissions to cleaners, repairmen, or their nanny (U2.3). 🧹

2.2.4. Selling the House 💸

Alice is starting a new job, so Alice and Bob have to move. They decide to sell the house and hand over control of all the automated services to the new owners (U2.11). Before that happens, they want to wipe privacy-sensitive data from the logs of the automated systems. The new owner, though, wants to keep some historical data, like how the heating system has been behaving (U2.12). When ownership of the house transfers, the new owners also want to make sure that any permissions the previous owners gave out for access to the house or its connected devices are no longer valid. That's true even when device management has its own permissions, separate from house access (U2.13). 🔐

2.2.5. Authorization Problems Summary 📝

  • U2.1: A home owner (Alice and Bob in the example above) wants to spontaneously hand out authorization means to visitors. 🎟️
  • U2.2: A home owner wants to spontaneously change the home's access control policies. 🔄
  • U2.3: A home owner wants to apply different access rights to different users, including other inhabitants. 👨‍👩‍👧
  • U2.4: The home owners want to grant access permissions to someone for a specific time frame. ⏰
  • U2.5: The smart home devices need to securely communicate with different control devices (like 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 get access with very little effort. 💅
  • U2.8: The owners of the automated home want to stop unauthorized entities from deducing behavioral profiles from the devices on the home network. 🕵️‍♀️
  • U2.9: Usability matters a lot in this scenario, because the authorization tasks across the device's life cycle (commissioning, operation, maintenance, and decommissioning) probably have to be done by home owners who usually know very little about security. 🧠
  • U2.10: Home owners want their devices to fulfill their purpose seamlessly (and in some cases even without being noticed), so the authorization admin effort has to be kept to 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 sanitize the logs of the automated systems when they transfer ownership, without deleting important operational data. 🧽
  • U2.13: When ownership transfers, the new owner wants to make sure that access rights created by the previous owner are no longer valid. 🔒

2.3. Personal Health Monitoring 💖

okay so personal health monitoring devices (aka eHealth devices) are usually battery-driven and sit physically on or in the user 🩺 to keep an eye on some bodily function, like temperature, blood pressure, or pulse rate. they usually connect to the internet through an intermediary base station using wireless tech, and then they report the monitored data to some entity, which could be the user or a medical caregiver 🫶

medical data has always been considered super sensitive 😭, so it needs good protection against unauthorized disclosure. the tricky part is that there's a frequent, conflicting requirement: medical personnel need to be able to get emergency access even when no specific access rights exist 🚑. so secure audit logs get even more important in these scenarios 🔍

users usually aren't trained in security (or even computer use, periodt), so the configuration must use secure default settings, and the interface must be well adapted to novice users 💅. parts of the system must also operate with minimal maintenance. especially frequent battery changes are unacceptable 🔋

there's a plethora of wearable health monitoring tech, and the need for open industry standards so products can work together has led to initiatives like the Continua Alliance (http://continuaalliance.org) and the Personal Connected Health Alliance (http://www.pchalliance.org) 🌈

2.3.1. John and the Heart Rate Monitor

okay meet John 🧡. John has a heart condition that can result in sudden cardiac arrests, which is lowkey scary. so he uses a device called "HeartGuard" that monitors his heart rate and his location (U3.7). if he has a cardiac arrest, it automatically sends an alarm to an emergency service and transmits John's current location (U3.1). the device either has long-range connectivity itself (e.g., via GSM), or it uses some intermediary, nearby device (e.g., John's smartphone) to send that alarm. to keep John safe, the device is expected to be in constant operation (U3.3, U3.6) ✨

the device includes an authentication mechanism so other people who get physical access to it can't act as the owner and mess with the access control and security settings (U3.8) 🔐

John can configure a list of people who get notified in an emergency, for example his daughter Jill 👧. the device also stores data on John's heart rate, which a physician can later access to assess the condition of John's heart (U3.2) 🩷

BUT John is a privacy-conscious queen 👑 and is worried that Jill might use HeartGuard to monitor his location even when there's no emergency. he also doesn't want his health insurance to get access to the HeartGuard data, or even to know that he's 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 is comfortable with modern tech and can operate it reasonably well, but he's not trained in computer security. so he needs an interface for configuring the HeartGuard security that is easy to understand and use (U3.5) 🫠. if John doesn't understand what a setting means, he tends to leave it alone, assuming the manufacturer already set the device to secure settings (U3.4) 🙈

Note: monitoring some state parameter (e.g., an alarm button) and the position of a person also fits really well into a nursing service context 🏥. this is especially useful for people with dementia, where relatives or caregivers need to be notified of the person's whereabouts under certain conditions. in that case, it's not the patient who decides about access.

2.3.2. Authorization Problems Summary

okay, the big list of authorization problems for this section 📝

  • 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 🛡️
  • 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, like shopping malls or office buildings, are nowadays equipped more and more with semi-automatic components to boost the overall living quality and save energy where possible ⚡. this includes things like heating, ventilation and air conditioning (HVAC), as well as illumination and security systems such as fire alarms. these components are 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. so a company must be able to control the lighting and HVAC system of its own part of the building, and it must not have access to control rooms that belong to other companies 🚪

some parts of the building automation system, like 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 🔧

installing building automation components often starts even before the construction work is finished. lighting is one of the first components to go into new buildings 💡. a lighting plan made by a lighting designer gives the info about the kind of lighting devices (luminaires, sensors, and switches) to install, along with their expected behavior. electricians then do the physical installation of the correct lighting devices at the right locations, based on the lighting plan. they make sure the electrical wiring follows local regulations and that lighting devices (which may come from multiple manufacturers) are properly connected to the electrical power supply ⚡. after 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 configures the lights as prescribed in the lighting plan 📋. this includes, for example, grouping so light points react together, more or less synchronously (U4.8), and defining lighting scenes for particular areas of the building 🎬. commissioning is often done in phases, by one or more commissioners, on different floors. at this stage, the building lighting network may be split into different network islands with no connectivity between them, because the IT infrastructure isn't there yet 🏝️

after this, other building components, like HVAC and security systems, are similarly installed by electricians and later commissioned by their respective domain professionals. similar grouping configurations (U4.8) are needed so that, e.g., HVAC equipment is controlled by the closest temperature sensor 🌡️

for the building IT systems, Ethernet wiring is first laid out in the building according to the IT plan. the IT network is often commissioned after construction is finished, to avoid damaging sensitive networking and computing equipment 🧯. an IT engineer does the commissioning, adding switches (wired and/or wireless), IP routers, and computing devices. direct Internet connectivity for all installed and commissioned devices in the building only becomes 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 then joined together, without any further involvement of domain specialists like lighting or HVAC commissioners 🧩

2.4.1.2. Operational ⚙️

the building automation system is now finally ready, and operational access is handed over to the facility management company of the building (U4.2) 🎉. the facility manager is responsible for monitoring and making sure 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 make them 🛠️

different parts of the building are rented out to different companies for office space. the tenants get access to the automated HVAC, lighting, and physical access control systems deployed in the building 🔑. the occupants' safety is also handled by automated systems, like a fire-alarm system that gets triggered by several smoke detectors spread across the building 🚒

Company A's staff moves into the newly furnished office space 📦. most lighting is controlled by presence sensors, which control the lighting of a specific group of lights based on the authorization rules in the BLMS. employees are also allowed to manually override the lighting brightness and color in their offices, using the switches or handheld controllers. such changes are only allowed 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 it was 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 🔧✨

Okay so bestie, Company A's staff are lowkey going insane because the lights keep switching off when they're just quietly working at their computers 💀. Company A tells the facility manager to make the delay before lights switch off longer 🙈. The facility manager can either change the new values straight in the BLMS or, if the field devices need more changes, hire commissioning Company C to do it (U4.4) 💅.

Company C gets the okay from the facility-management company to talk to the BLMS 🫶. The commissioner's tool gets permission from the BLMS to send a config change to every lighting device in Company A's offices so the delay before they switch off goes up 🦋.

Then the facility-management company wants to update the firmware on the lighting devices to squash some software bugs 🐛. Before accepting the new firmware, each device checks that the facility-management company is actually allowed to do this update (U4.13) 🔥.

Now here's the tea 🍵: a network-diagnostic tool in the BLMS notices that a luminaire in one of Company A's offices is no longer connected to the network 😭. The BLMS alerts the facility manager to swap it out. The facility manager replaces the broken luminaire and tells the BLMS the identity (e.g., the Media Access Control (MAC) address) of the new device 🎀. Then the BLMS authorizes the new device in the system and seamlessly moves all the permissions from the old broken device over to the replacement 👑 (U4.12). Iconic, honestly ✨.

2.4.1.4. Recommissioning 🌸

Okay so a vacant area of the building just got leased to Company A 🏢. Before moving into their new office, Company A wants to swap the lighting for more energy efficient luminaires with better light quality 💡. They hire an installation and commissioning Company C to redo the illumination. Company C has to plug the new lighting devices, which might come from multiple manufacturers, into the existing lighting setup of the building, which includes presence sensors, switches, controllers, etc. 🧚 (U4.1).

Company C gets the okay from the facility-management company to talk to the existing BLMS (U4.4). To avoid bugging the other people in the building, Company C only gets permission to do the commissioning during non-office hours, and only to change the configuration on devices that belong to Company A's space (U4.5) 🌙. Before any existing devices get removed, all the security and config stuff that belongs to the domain gets deleted and the devices are reset to factory state (U4.3) 🧹. This means these devices can be reused at other installations or in other parts of the same building without messing up future operations ♻️. After the new lighting devices are installed (wired up), the commissioner adds them into Company A's lighting domain 🦋.

Once the devices are in the right domain, the commissioner authorizes the interaction rules between the new lighting devices and the existing ones, 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 rules may be context based, like the time of day (office or non-office hours) or the location of the handheld lighting controller, etc. (U4.5) 🌈.

2.4.1.5. Decommissioning 🗑️

Company A has noticed that the handheld controllers are always getting misplaced and are hard to find when people need them 😩. So most of the time, staff just use the existing wall switches for manual control. Company A decides it would be better to fully remove the handheld controllers and asks Company C to decommission them from the lighting system (U4.4) 💅.

Company C gets the okay from the facility-management company to talk to the BLMS again 🫶. The commissioner now deletes any rules that let handheld controllers control the lighting (U4.3, U4.6) ❌. Also, the commissioner tells the BLMS to push these new rules out so that cached rules on the end devices don't get used 🔐. Any cryptographic key material belonging to the site on the handheld controllers is removed too, and they're set back to factory state (U4.3) 🧼.

2.4.2. Public Safety 🚨

Okay so as part of the building safety code, the fire department requires the building to have sensors that pick up the level of smoke, heat, etc., when a fire breaks out 🔥. These sensors send their readings to a back-end server, which uses them to map safe areas and unsafe areas within a building, and possibly the structural integrity of the building, before firefighters are allowed to go in 👩‍🚒. Sensors may also be used to track where people and animals are moving around inside the building 🐾. This lets people who are stuck in the building get guided to safer areas and lets the system suggest possible actions they can take (e.g., using a client application on their phones or giving loudspeaker directions) to get them to safety 📱. In some cases, other organizations like the police, ambulance, and federal organizations are also involved, so the coordination of tasks between all these entities has to happen 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 with an electric kettle ☕. After she switches it on, she goes outside to chat with a colleague until the water boils. Unfortunately, her kettle malfunctions, which causes overheating and a smoldering fire in the kettle's plastic case 😱.

The smoke from the kettle sets off the fire alarm 🚨. Alarm sirens throughout the building switch on at the same time (using a group communication scheme) to alert the staff of both companies (U4.8) 📢. The ventilation system for the whole building also gets shut off to stop the smoke from spreading and to cut off the oxygen feeding the fire 🌬️. The smoke can't 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 gets notified of the fire automatically and shows up really fast 🚒. They automatically get access to all parts of the building according to an emergency authorization policy (U4.4, U4.5) 🔑. After they inspect the damage and put out the smoldering fire, a firefighter resets the fire alarm, because only the fire department is authorized to do that (U4.4, U4.11) 👑.

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. 🔏

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 have networking capability so they can be managed remotely 🌐. Such systems are used for commercial, industrial, and residential customers and need a certain level of security, so providers don't lose money, the distribution system doesn't get vulnerable, and customers' services don't get disrupted 🛡️.

The smart metering equipment for gas and water solutions runs on batteries, so communication should be used sparingly to save battery 🔋. Because of that, these meters sleep most of the time and only wake up every minute/hour to check for incoming instructions 😴. They also wake up a few times a day (based on their configuration) to upload their measured metering data 📤.

There are different networking topologies for smart metering solutions 🕸️. Depending on the 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 for collecting gas and water meter data 🚗💨.

Various stakeholders have a claim on the metering data 🙋‍♀️. Utility companies need the data for accounting, the metering equipment may be run by a third-party service operator who needs to maintain it, and the equipment sits in the consumers' premises, measuring their consumption, which raises privacy questions 🔐.

2.5.1. Drive-By Metering

okay so picture this 🚗💨 a service operator sells smart metering setups and related services to a bunch of utility companies. one of those utility companies is a water provider that supplies a few residential complexes in a city 💧. the smart meters live inside each customer's home, measuring water use so the utility can send bills. they can even shut the water off if the bills stop getting paid (U5.1, U5.3) 🙅‍♀️. the meters talk by sending and receiving data with a base station (U5.2).

the city has several base stations scattered around to collect all that metering data. the problem is the denser urban areas, where the base stations would need to sit super close to the meters. that means a LOT of base stations, and this pricier gear would be way more exposed to tampering or sabotage 😬. so the service operator picked a different move: drive around with a mobile base station and let the meters connect to it at regular intervals to grab their readings 🚙🎀 (U5.4, U5.6, U5.8). iconic, honestly.

2.5.2. Meshed Topology

this one is giving network-of-friends energy 🕸️🫶. in another deployment, the water meters are installed in a building that already has power meters. those power meters are mains powered, so they don't have to follow the same strict power saving rules. the water meters can use the power meters as proxies to get better connectivity ✨. the catch is that the security measures on the water meters have to keep working even when traffic goes through these middlemen (U5.9) 🔐.

2.5.3. Advanced Metering Infrastructure

so a utility company is upgrading its old distribution network with advanced meters and new communication systems. this whole setup is called an Advanced Metering Infrastructure (AMI) 🌈⚡. AMI is a system that measures, collects, and analyzes usage, and talks to metering devices like electricity, gas, heat, and water meters. it does this over different communication media, either on request (on-demand) or on predefined schedules 📅.

the perks are huge 🤩. consumers can control their own utility consumption (U5.2, U5.7), save money with new tariff models from utility companies, and get more accurate and timely billing 💸. BUT 😤 the end consumers do NOT want random unauthorized people getting into this data. plus, super fine-grained consumption measurements can raise privacy concerns, because they could let someone build a behavioral profile of the household (U5.5, U5.10) 👀.

the technical solution is built on levels of data aggregation. you've got smart meters at the consumer premises on one end and the Meter Data Management (MDM) system at the utility company on the other (U5.9) 🗂️. end-to-end connectivity isn't always doable, for reasons of efficiency and cost. so metering data gets stored and aggregated in various intermediate devices before it's forwarded to the utility company, where the MDM can access it 📦. those intermediate devices may be run by a third-party service operator acting on behalf of the utility company (U5.7).

one job of the service operator is making sure meter readings happen and get delivered in a regular, timely way ⏰. an example Service Level Agreement between the service operator and the utility company says at least 95% of the meters have readings recorded during the last 72 hours 💯.

2.5.4. Authorization Problems Summary

  • U5.1: the devices sit in hostile environments where attackers can physically reach them, including dishonest customers 😒. the service operator and the utility company want to make sure an attacker can't use data from a captured device to attack the rest of their infrastructure 🛡️.
  • U5.2: the utility company wants control over which entities can send data to, and read data from, their endpoints 🔑.
  • U5.3: the utility company wants to make sure the data stored on their endpoints hasn't been tampered with 🧾.
  • U5.4: the utility company wants to protect data transfers to and from their endpoints 🔒.
  • U5.5: consumers want to see their own usage information AND keep others from getting in 🙅‍♀️💜.
  • U5.6: the devices might have on-and-off Internet connectivity, but they still need to enforce their principals' authorization policies 📶.
  • U5.7: neither the service operator nor the utility company is always around when access happens, so they can't step in manually to approve it 🙈.
  • U5.8: when authorization policies get updated, contacting every affected endpoint directly is impossible, or at least super inefficient 🥴.
  • U5.9: authorization and authentication have to keep working even when messages between endpoints get stored and forwarded across several nodes 🔁.
  • U5.10: consumers may not want the service operator, the utility company, or anyone else to see fine-grained consumption data that would allow building behavioral profiles 🫣.

2.6. Sports and Entertainment

leisure time is where small, lightweight constrained devices really shine 🏃‍♀️✨. sensors and actuators can be built into fitness gear, games, and even clothes 👕. people can carry their devices around with them all the time 🎒.

usability matters SO much here 💅. users will often want to spontaneously hook their devices up to other people's devices. so setting access permissions has to be simple and fast, and shouldn't take much effort at the moment access happens ⚡.

constant monitoring lets authorized users build behavioral or movement profiles that match how the devices are meant to be used 🏅. and if an attacker gets unauthorized access to that collected data, they can build the very same profiles 😱. aggregating the data can also seriously amp up the impact on users' privacy 🔍.

2.6.1. Dynamically Connecting Smart Sports Equipment

Jody is an enthusiastic runner 🏃‍♀️🌸. to track her training progress, she has smart running shoes that measure the pressure at different points under her feet. they count her steps, spot irregularities in her stride, and help her improve her posture and running style 👟. one sunny afternoon she heads to the Finnbahn track near her home to work out 🌞. there she meets her friend Lynn, who shows off 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 a configured training program 💪. the girls realize the watch can connect with Jody's shoes and display the info the shoes provide 🤯.

Jody asks Lynn if she can try the watch and borrow it for the afternoon. Lynn says yes, BUT she doesn't want Jody to access her training plan (U6.4) 🙅‍♀️. so Lynn sets the watch's access policies so Jody's shoes can use the display and measuring features but can NOT 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 set up access rights for devices belonging to Lynn a while back (U6.3) 🪄. Jody also wants the watch to report data back to her fitness account while she has it, so she lets it access her account temporarily 📲.

after an hour, Jody gives the watch back, and both girls end the connection between their devices 🤝💖.

2.6.2. Authorization Problems Summary

  • U6.1: sports equipment owners want to be able to grant access rights dynamically, whenever they need to ⚡.
  • U6.2: sports equipment owners want setting up access rights to take very little effort 🙌.
  • U6.3: sports equipment owners want to preconfigure access policies that grant certain permissions to endpoints with certain attributes (for example, endpoints belonging to a certain user). and they want this to need no extra setup effort at the moment of access 🧚.
  • U6.4: sports equipment owners want to keep their data confidential for privacy reasons 🤫💜.

2.7. Industrial Control Systems

industrial control systems (ICS), and especially supervisory control and data acquisition (SCADA) systems, use a whole bunch of sensors and actuators to monitor and control industrial processes in the physical world 🏭⚙️. example processes include manufacturing, power generation, and refining raw materials 🔥.

ever since the Stuxnet worm, everyone has realized how vulnerable these kinds of systems are, especially when they're connected to the Internet [Karnouskos11] 😬💀. it's even worse because lots of ICS control critical public infrastructure, like nuclear power, water treatment, or traffic control 🚦. still, connecting these systems to the Internet can bring big economic advantages IF proper security measures are in place (U7.5) 🔐✨.

2.7.1. Oil Platform Control

an oil platform runs an industrial control system to monitor data and control equipment 🛢️. the system gathers and processes data from a LOT of sensors and controls actuators, like valves and switches, to steer the oil extraction process on the platform 🎛️. raw data, alarms, reports, and other info are available to operators too, and they can step in with manual commands 🕹️. many sensors are wired straight to the controlling units, BUT the operator is slowly swapping those for wireless ones, since that makes maintenance easier (U7.4) 📡.

some of the controlling units are connected to the Internet so people can administer them remotely 🖥️. flying a technician out to the platform is expensive and inconvenient, after all (U7.3) ✈️🙃.

the operator's main interest is making sure control messages and sensor readings keep their integrity (U7.1) 🧩. sometimes access needs to be restricted. for example, the operator wants wireless actuators to accept commands ONLY from authorized control units (U7.2) 🛑.

the platform owner also wants to collect auditing information for liability reasons (U7.1) 📋.

different access levels apply, for example for regular operators, maintenance technicians, and auditors of the platform (U7.6) 👑.

2.7.2. Authorization Problems Summary

  • U7.1: the platform operator wants to keep sensor and actuator data both intact and confidential 🔒.
  • U7.2: the operator wants to make sure data coming from sensors, and commands sent to actuators, are authentic ✅.
  • U7.3: some devices don't have a direct Internet connection, but they still need to enforce current authorization policies 📶.
  • U7.4: devices need to authenticate the controlling units, especially the ones using a wireless connection 📡🔐.
  • U7.5: running unauthorized commands, or failing to run an authorized command, in an ICS can cause serious financial damage and threaten the availability of critical infrastructure services 🚨. so 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 (for example, operator vs. auditor) 👩‍💼🎀.

3. Security Considerations 🔐

okay so the use cases in this doc show that constrained devices are EVERYWHERE 🌸 They're tiny and cheap, so they sneak into basically every part of everyday life. But they hold tons of valuable data and can sometimes control important stuff, so they need real protection from unauthorized access 🔒 Even "boring" data needs protecting, because of aggregation. An attacker who collects bits from several sources can end up with insights or control that none of those sources would give them alone 👀

It's not just the device's own data at risk, either 💀 A compromised device can be used as a way into the rest of the network, and then it can attack other devices too. Because of their limited capabilities, constrained devices are basically the weakest link in the network, which makes them a very attractive target 🎯

This section sums up the security problems from the use cases above and gives guidelines for designing authentication and authorization protocols in constrained RESTful environments ✨

3.1. Attacks ⚔️

This document lists the security problems that users of constrained devices want solved. A deeper analysis of attack scenarios is out of scope here. Still, there are attacks that solution developers absolutely have to think about 🧠

Because there will be a huge number of these devices and they're everywhere, constrained devices make Pervasive Monitoring [RFC7258] attacks scarier 😱 Solution Designers should keep this in mind when designing their security solution and build in protection against this kind of attack. Specifically, messages with sensitive data that go over unprotected channels should be encrypted if possible 🔐

Attacks that alter data in transit (for example, to pull off fraud) are already handled by many web security protocols, like TLS or IPsec 🫶 Developers still need to consider these attacks and make sure their protection measures actually fit a constrained environment.

As some of the use cases show, constrained devices may be installed in hostile environments where people can physically reach them (see Section 2.5) 🙈 Protection from physical attacks is not in scope for this document, but developers of authorization solutions should keep it in mind.

Denial-of-service (DoS) attacks threaten the availability of the services a device provides, and constrained devices are especially vulnerable to these because of their limitations 📉 An attacker can cause a temporary failure in a service, or a permanent one if the battery gets drained, just 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 about the following limitations in every part of the authorization solution:

  • Battery usage 🔋
  • Number of required message exchanges
  • Size of data that is transmitted (e.g., authentication and access control data)
  • Size of code required to run the protocols
  • Size of RAM memory and stack required to run the protocols
  • 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 🗝️

  • The access control policies need to be enforced (all use cases): the information needed to implement the access control policies needs to be provided to the device that enforces the authorization, and applied to every incoming request 📬
  • A single resource might have different access rights for different requesting entities (all use cases).

Rationale: sometimes different types of users need different access rights, instead of a simple yes-or-no approach where every authenticated user gets the same permissions 💅

  • A device might host several resources, and each resource can have its own access control policy (all use cases) 🎀
  • The device that makes the policy decisions should be able to evaluate context-based permissions, like location or time of access (see Sections 2.2, 2.3, and 2.4) 📍 Access may depend on local conditions, for example 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 🧩

  • 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) 🤖
  • 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) 📵
  • 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 really fast, which makes manual re-provisioning unreasonably expensive 💸

  • 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) 🌊
  • It must be possible to dynamically revoke authorizations (see Section 2.4 for example) 🚫
  • 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) 🫠
  • 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 end users frequently leave default settings unchanged 🙃

  • 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) 🚪
  • Usability is important for all use cases 🌈 Configuring authorization policies, as well as 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 who are typically not trained in security (see Sections 2.2, 2.3, and 2.6) 🧁
  • 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 🎯

3.4. Proxies 🔀

In some cases, 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 this document focuses on either collect data from the physical world through sensors, or affect their surroundings through actuators 🌍 The data they collect and process can often be linked to individuals 🧍‍♀️ Sensor data may be collected and distributed at regular intervals, so a significant amount of information about a person can be gathered and fed into learning algorithms as part of big data analysis, then used in automated decision making 🤯

Privacy protection for individuals matters a lot, to make sure that only authorized entities get access to collected data or can trigger actions, to get consent before data is shared, and to handle the other privacy-related threats outlined in RFC 6973 💜

RFC 6973 was written as guidance for engineers designing technical solutions. For a short description of the deployment-related aspects of privacy, plus further references relevant to the Internet of Things sector, 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, <http://rsta.royalsocietypublishing.org/content/372/2017/20130304.short>. 🍓

[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, <http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6120048>. 💥

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>. 🧾

[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>. 🧚

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>. 🌸

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 ✨

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

That's the whole RFC, bestie! 🌈👑

📦 where this page comes from