--- 1/draft-ietf-ace-usecases-00.txt 2015-01-13 05:14:35.892661655 -0800 +++ 2/draft-ietf-ace-usecases-01.txt 2015-01-13 05:14:35.944662895 -0800 @@ -1,25 +1,25 @@ ACE Working Group L. Seitz, Ed. Internet-Draft SICS Swedish ICT AB Intended status: Informational S. Gerdes, Ed. -Expires: June 5, 2015 Universitaet Bremen TZI +Expires: July 17, 2015 Universitaet Bremen TZI G. Selander Ericsson M. Mani Itron S. Kumar Philips Research - December 02, 2014 + January 13, 2015 ACE use cases - draft-ietf-ace-usecases-00 + draft-ietf-ace-usecases-01 Abstract Constrained devices are nodes with limited processing power, storage space and transmission capacities. These devices in many cases do not provide user interfaces and are often intended to interact without human intervention. This document comprises a collection of representative use cases for the application of authentication and authorization in constrained @@ -41,76 +41,76 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 5, 2015. + This Internet-Draft will expire on July 17, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + Copyright (c) 2015 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Container monitoring . . . . . . . . . . . . . . . . . . 4 2.1.1. Bananas for Munich . . . . . . . . . . . . . . . . . 5 - 2.1.2. Authorization Problems Summary . . . . . . . . . . . 5 + 2.1.2. Authorization Problems Summary . . . . . . . . . . . 6 2.2. Home Automation . . . . . . . . . . . . . . . . . . . . . 6 - 2.2.1. Controlling the Smart Home Infrastructure . . . . . . 6 + 2.2.1. Controlling the Smart Home Infrastructure . . . . . . 7 2.2.2. Seamless Authorization . . . . . . . . . . . . . . . 7 2.2.3. Remotely letting in a visitor . . . . . . . . . . . . 7 - 2.2.4. Authorization Problems Summary . . . . . . . . . . . 7 + 2.2.4. Authorization Problems Summary . . . . . . . . . . . 8 2.3. Personal Health Monitoring . . . . . . . . . . . . . . . 8 2.3.1. John and the heart rate monitor . . . . . . . . . . . 9 2.3.2. Authorization Problems Summary . . . . . . . . . . . 10 - 2.4. Building Automation . . . . . . . . . . . . . . . . . . . 10 + 2.4. Building Automation . . . . . . . . . . . . . . . . . . . 11 2.4.1. Device Lifecycle . . . . . . . . . . . . . . . . . . 11 2.4.2. Authorization Problems Summary . . . . . . . . . . . 13 - 2.5. Smart Metering . . . . . . . . . . . . . . . . . . . . . 13 + 2.5. Smart Metering . . . . . . . . . . . . . . . . . . . . . 14 2.5.1. Drive-by metering . . . . . . . . . . . . . . . . . . 14 - 2.5.2. Meshed Topology . . . . . . . . . . . . . . . . . . . 14 - 2.5.3. Advanced Metering Infrastructure . . . . . . . . . . 14 - 2.5.4. Authorization Problems Summary . . . . . . . . . . . 15 + 2.5.2. Meshed Topology . . . . . . . . . . . . . . . . . . . 15 + 2.5.3. Advanced Metering Infrastructure . . . . . . . . . . 15 + 2.5.4. Authorization Problems Summary . . . . . . . . . . . 16 2.6. Sports and Entertainment . . . . . . . . . . . . . . . . 16 - 2.6.1. Dynamically Connecting Smart Sports Equipment . . . . 16 + 2.6.1. Dynamically Connecting Smart Sports Equipment . . . . 17 2.6.2. Authorization Problems Summary . . . . . . . . . . . 17 2.7. Industrial Control Systems . . . . . . . . . . . . . . . 17 - 2.7.1. Oil Platform Control . . . . . . . . . . . . . . . . 17 + 2.7.1. Oil Platform Control . . . . . . . . . . . . . . . . 18 2.7.2. Authorization Problems Summary . . . . . . . . . . . 18 - 3. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 3. Security Considerations . . . . . . . . . . . . . . . . . . . 19 3.1. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Configuration of Access Permissions . . . . . . . . . . . 20 - 3.3. Design Considerations for Authorization Solutions . . . . 20 - 3.4. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 - 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 7. Informative References . . . . . . . . . . . . . . . . . . . 22 + 3.3. Design Considerations for Authorization Solutions . . . . 21 + 3.4. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 + 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 + 7. Informative References . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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 @@ -118,60 +118,73 @@ security protocols are not always easily applicable. As the devices are expected to be integrated in all aspects of everyday life, the application of adequate security mechanisms is required to prevent attackers from gaining control over data or functions important to our lives. 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 lifecycle 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 - Resource Server (RS): The constrained device which hosts resources - the Client wants to access. + Readers are required to be familiar with the terms defined in + [RFC7228]. In addition, this document uses the following + terminology: - Client (C): A device which wants to access a resource on the Resource - Server. - This could also be a constrained device. + Resource: An item of interest. - Resource Owner (RO): The subject who owns the resource and controls - its access permissions. + Resource Server: The device which hosts resources the Client wants to + access. Resource Servers might be constrained devices. + + Client: A device which wants to access a resource on the Resource + Server. This could also be a constrained device. + + Resource Owner: The subject who owns the resource and controls its + access permissions. + + Device Owner: The subject who owns a certain device and controls its + access permissions. + + Principal: A subject who is either a resource owner or a device owner + or both. 2. Use Cases This section lists use cases involving constrained devices with certain authorization problems to be solved. Each use case first presents a general description of the application area, then one or more specific use cases, and finally a summary of the authorization- - related problems device owners need to be solved. + related problems principals need to be solved. - There are various reasons for assigning a function (client or - resource server) to a device, e.g. which device initiates the - conversation, how do devices find each other, etc. 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 devices might even have different functions - at different times. + There are various reasons for assigning a function (client or server) + to a device, e.g. which device initiates the conversation, how do + devices find each other, etc. 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 devices 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. The use of such sensor systems makes it possible to continuously track and transmit specific characteristics such as temperature, humidity and gas content during the transportation and storage of goods. The proper handling of the sensors in this scenario is not easy to @@ -191,179 +204,187 @@ to their customers. The need for a constant monitoring of perishable goods has led to projects such as The Intelligent Container (http:// www.intelligentcontainer.com). 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 with their own company - trucks. + from the fruit vendor and transports them from the ripening facility + to the individual markets with their own company trucks. The fruit vendor's quality management wants to assure the quality of their products and thus equips the banana boxes with sensors. The state of the goods is monitored consistently during shipment and ripening and abnormal sensor values are recorded. Additionally, the sensor values are used to control the climate within the cargo - containers. Since a wrong sensor value leads to a wrong temperature - and thus to spoiled goods, the integrity of the sensor data must be - assured. - - 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. Those relaying nodes might belong to different owners. The - sensors in the banana boxes cannot always reach the internet during - the journey. + containers. The sensors therefore need to communicate with the + climate control system. Since a wrong sensor value leads to a wrong + temperature and thus to spoiled goods, the integrity of the sensor + data must be assured. The banana boxes within a container will in + most cases belong to the same principal. Adjacent containers might + contain goods and sensors of different principals. The personnel that transloads the goods must be able to locate the goods meant for a specific customer. 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. + confidentiality of this data. Thus, the transloading personnel is + only allowed to access logistic information. Moreover, the + transloading personnel is only allowed to access the data for the + time of the transloading. - When the goods arrive at the supermarket in Munich, the supermarket - conducts its own quality check. If no anomalies occurred during the - transport, the bananas are admitted for sale. + 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. The sensors in the banana boxes cannot always reach the + Internet during the journey. -2.1.2. Authorization Problems Summary + In the ripening facility bananas are stored until they are ready for + selling. 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. - o U1.1 The device owner wants to grant different access rights to a - resource to different parties. + The supermarket chain gains ownership of the banana boxes when the + bananas have ripened and are ready to leave the ripening facility. - o U1.2 The device owner wants to control which devices are allowed - to present data to the device. +2.1.2. Authorization Problems Summary - o U1.3 The device owner wants to grant different access rights for + o U1.1 Principals such as the fruit vendor, the transloading + personnel or the container owners want to grant different access + rights for their resource to different parties and want to control + which devices are allowed to present data to their devices. + + o U1.2 Principals want to grant different access rights for different resources on a device. - o U1.4 The device owner requires the integrity of sensor data. + o U1.3 The principals require the integrity of sensor data. - o U1.5 The device owner requires the confidentiality of sensor data. + o U1.4 The principals require the confidentiality of sensor data. - o U1.6 The device owner is not always present at the time of access + o U1.5 The principals are not always present at the time of access and cannot manually intervene in the authorization process. - o U1.7 The device owner wants to grant temporary access permissions - to a party. + o U1.6 The principals want to grant temporary access permissions to + a party. - o U1.8 Messages between client and resource server might need to be + o U1.7 Messages between client and resource server might need to be forwarded over multiple hops. - o U1.9 The constrained device might not always be able to reach the - internet. + o U1.8 The constrained devices might not always be able to reach the + Internet. 2.2. Home Automation Automation of the home has the potential to become a big future market for the Internet of Things. A home automation system connects devices in a house to the Internet and thus makes them accessible and manageable remotely. Such devices might control for example heating, ventilation, lighting, home entertainment or home security. Such a system needs to accommodate a number of regular users (inhabitants, close friends, cleaning personnel) as well as a heterogeneous group of dynamically varying users (visitors, repairmen, delivery men). 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 - Jane and her husband George own a flat which is equipped with home + Alice and her husband Bob own a flat which is equipped with home automation devices such as HVAC and shutter control, and they have a motion sensor in the corridor which controls the light bulbs there. - Jane and George can control the shutters and the temperature in each - room using either wall-mounted touch panels or their smartphones. - Since Jane and George both have a full-time job, 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. + Alice and Bob can control the shutters and the temperature in each + room using either wall-mounted touch panels or with an internet + connected device (e.g. a smartphone). Since Alice and Bob both have + a full-time job, 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. 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. 2.2.2. Seamless Authorization - Jane buys a new light bulb for the corridor and integrates it into - the home network (how she does that is not in scope). George is not - at home, but Jane wants him to be able to control the new device with - his smart phone without the need for additional administration - effort. + 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. She provides the + necessary configurations for that. 2.2.3. Remotely letting in a visitor - Jane and George 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. - - Jane and George have invited Jane's parents over for dinner, but are - stuck in traffic and can not arrive in time, while Jane's parents who - use the subway will arrive punctually. Jane calls her parents and - offers to let them in remotely, so they can make themselves - comfortable while waiting. + 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. - Jane's parents download an application that lets them communicate - with Jane's door-lock and alarm system. Then Jane sets temporary - permissions that allow them to open the door, and shut down the alarm - when they arrive. + Alice and Bob have invited Alice's parents over for dinner, but are + stuck in traffic and can not arrive in time, while Alice's parents + who use the subway will arrive punctually. Alice calls her parents + and offers to let them in remotely, so they can make themselves + comfortable while waiting. Then Alice sets temporary permissions + that allow them to open the door, and shut down the alarm. 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. - The security system controlling the door-locks and alarm system needs - to be at least as secure as for a comparable unautomated home. + When Alice's parents arrive at Alice's and Bob's home, they use their + smartphone to communicate with the door-lock and alarm system. 2.2.4. Authorization Problems Summary - o U2.1 A home owner wants to spontaneously provision authorization - means to visitors. + o U2.1 A home owner (Alice and Bob in the example above) wants to + spontaneously provision authorization means to visitors. o U2.2 A home owner wants to spontaneously change the home's access control policies. o U2.3 A home owner wants to apply different access rights for different users. - o U2.4 A home owner wants to apply context-based conditions - (presence, time) to authorizations, and the devices need to be - able to verify these conditions. + o U2.4 The home owners want to grant temporary access permissions to + a party. o U2.5 The smart home devices need to be able to communicate with different control devices (e.g. wall-mounted touch panels, smartphones, electronic key fobs). - o U2.6 The access control configuration of the automated home needs - to be secure by default. + o U2.6 The home owner wants to be able to configure authorization + policies remotely. - o U2.7 The access control policies need to be easy to edit, even - remotely and it needs to be easy to get access with correct - authorization. + o U2.7 Authorized Users want to be able to obtain access with little + effort. - o U2.8 The owners of the automated home wants to prevent - eavesdroppers form being able to deduce behavioral profiles from - the home network. + o 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. o U2.9 Usability is particularly important in this scenario since - administrative tasks such as installation, configuration and - decommissioning of devices likely need to be performed by the home - owners who in most cases have little knowledge of security. + the necessary authorization related tasks in the lifecycle 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. o U2.10 Home Owners want their devices to seamlessly (and in some cases even unnoticeably) fulfill their purpose. The administration effort needs to be kept at a minimum. 2.3. Personal Health Monitoring - The use of wearable health monitoring technology is expected to grow strongly, as a multitude of novel devices are developed and marketed. The need for open industry standards to ensure interoperability between products has lead to initiatives such as Continua Alliance (continuaalliance.org) and Personal Connected Health Alliance (pchalliance.org). Personal health devices are typically battery driven, and located physically on the user. They monitor some bodily function, such as e.g. temperature, blood pressure, or pulse. They are connected to the Internet through an intermediary base-station, using wireless technologies. Through this connection they report the @@ -382,96 +403,93 @@ 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. 2.3.1. John and the heart rate monitor John has a heart condition, that can result in sudden cardiac arrests. He therefore uses a device called HeartGuard that monitors his heart rate and his position. In case of a cardiac arrest it automatically sends an alarm to an emergency service, transmitting - John's current location. The HeartGuard also broadcasts emergency - information in the neighborhood to notify doctors or people with - certain skills who have been enrolled in an emergency program, e.g. - people who got training in heart and lung rescue. For doctors, - medical information or diagnosis can be provided with the - notification to improve immediate treatment. + John's current location. This requires the device to be close to a + wireless access point, in order to be able to get an Internet + connection (e.g. John's smartphone). - The device includes some smart logic, with which it identifies its - owner John and allows him to configure the device's settings, - including access control. - This prevents situation where someone else wearing that device can - act as the owner and mess up the access control and security - settings. + The device includes some authentication mechanism, in order to + prevent other persons who get physical access to it from acting as + the owner and messing up the access control and security settings. John can configure additional persons that get notified in an emergency, for example his daughter Jill. Furthermore the device stores data on John's heart rate, which can later be accessed by a physician to assess the condition of John's heart. - However John is a rather private person, and is worried that Jill + However John is a privacy conscious person, and is worried that Jill might use HeartGuard to monitor his location while there is no emergency. Furthermore he doesn't want his health insurance to get access to the HeartGuard data, 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 big a risk for them. + Finally John, while being comfortable with modern technology and able + to operate it reasonably well, is not trained in computer security. + He therefore need an interface for the configuration of the + HeartGuard security that is easy to understand and use. If John does + not understand the meaning of some setting, he tends to leave it + alone, assuming that the manufacturer has initialized the device to + secure settings. + NOTE: Monitoring of some state parameter (e.g. an alarm button) and the position of a person also fits well into an elderly care service. 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 this case it is not the patient that decides about access. 2.3.2. Authorization Problems Summary - o U3.1 A device owner wants to pre-configure access rights to - specific data for persons or groups, in the context of an - emergency. - - o U3.2 A device owner wants to selectively allow different persons - or groups to access medical data. + o U3.1 A principal, such as the owner of a health monitoring device, + wants to pre-configure access rights to specific data for persons + or groups, in the context of an emergency. - o U3.3 A device owner wants to block access to specific persons in - an otherwise allowed group (e.g. doctors in an emergency), if he - mistrusts them. + o U3.2 A principal wants to selectively allow different persons or + groups to access medical data. - o U3.4 The security measures could affect battery lifetime of the + o U3.3 The security measures could affect battery lifetime of the devices and should changes of battery are highly inconvenient. - o U3.5 Devices are often used with default access control settings. + o U3.4 Devices are often used with default access control settings. - o U3.6 Device users are often not trained in computer use and + o U3.5 Principals are often not trained in computer use and especially computer security. - o U3.7 Security mechanisms themselves could provide opportunities + o U3.6 Security mechanisms themselves could provide opportunities for denial of service attacks on the device. - o U3.8 The device provides a service that can be fatal for the - device owner if it fails. Accordingly, the device owner wants a + o U3.7 The device provides a service that can be fatal for the + principal if it fails. Accordingly, the principal wants a security mechanism to provide a high level of security. 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. 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 light and HVAC - system of its own part of the building and must not have access to - control rooms that belong to other companies. + areas of the building. Accordingly, a company must be able to + control the light and HVAC system of its own part of the building and + 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 service company. 2.4.1. Device Lifecycle 2.4.1.1. Installation and Commissioning A building is hired out to different companies for office space. @@ -525,27 +543,27 @@ shares some of the common spaces with company A. On a really hot day James who works for company A turns on the air condition in his office. Lucy who works for company B wants to make tea using an electric kettle. After she turned it on she goes outside to talk to a colleague until the water is boiling. Unfortunately, her kettle has a malfunction which causes overheating and results in a smoldering fire of the kettle's plastic case. Due to the smoke coming from the kettle the fire alarm is triggered. Alarm sirens throughout the building are switched on simultaneously - (using a broadcastor multicast) to alert the staff of both companies. - Additionally, the ventilation system of the whole building is closed - off to prevent the smoke from spreading and to withdraw oxygen from - the fire. The smoke cannot get into James' office although he turned - on his air condition because the fire alarm overrides the manual - setting by sending commands (broadcast or multicast) to switch off - all the air conditioning. + (using a broadcast or multicast) to alert the staff of both + companies. Additionally, the ventilation system of the whole + building is closed off to prevent the smoke from spreading and to + withdraw oxygen from the fire. The smoke cannot get into James' + office although he turned on his air condition because the fire alarm + overrides the manual setting by sending commands (broadcast or + multicast) to switch off all the air conditioning. The fire department is notified of the fire automatically and arrives within a short time. After inspecting the damage and extinguishing the smoldering fire a fire fighter resets the fire alarm because only the fire department is authorized to do that. 2.4.1.3. Maintenance Company A's staff are annoyed that the lights switch off too often in their rooms if they work silently in front of their computer. @@ -568,47 +586,47 @@ Company C again gets the necessary authorization from the service company to interact with the BLMS. The commissioner now deletes any rules that allowed handheld controllers authorization to control the lighting. Additionally the commissioner instructs the BLMS to push these new rules to prevent cached rules at the end devices from being used. 2.4.2. Authorization Problems Summary - o U4.1 Device owners want to be able to add a new device to their + o U4.1 Principals want to be able to add a new device to their administrative domain (commissioning). - o U4.2 Device owners want to be able to integrate a device that + o U4.2 Principals want to be able to integrate a device that formerly belonged to a different administrative domain to their own administrative domain (handover). - o U4.3 Device owner want to be able to remove a device from their + o U4.3 Principal want to be able to remove a device from their administrative domain (decomissioning). - o U4.4 Device owners want to be able to delegate selected + o U4.4 Principals want to be able to delegate selected administration tasks for their devices to others. o U4.5 The device owner wants to be able to define context-based Authorization rules. o U4.6 The device owner wants to be able to revoke granted permissions and delegations. o U4.7 The device owner wants to allow only authorized access to device resources (default deny). o U4.8 The device owner wants to be able to authorize a device to control several devices at the same time using a multicast protocol. - o U4.9 Device owners want to be able to interconnect their own + o U4.9 Principals 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 devices. 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 @@ -689,63 +707,62 @@ service operator on behalf of the utility company. One responsibility of the service operator is to make sure that meter readings are performed and delivered to the HES. An example of a Service Level Agreement between the service operator and the utility company is e.g. "at least 95 % of the meters have readings recorded during the last 72 hours". 2.5.4. Authorization Problems Summary o U5.1 Devices are installed in hostile environments where they are - physically accessible by attackers. Device owners want to make - sure that an attacker cannot use a captured device to attack other + physically accessible by attackers. Principals want to make sure + that an attacker cannot use a captured device to attack other parts of their infrastructure. - o U5.2 Device owners want to restrict which entities are allowed to + o U5.2 Principals want to restrict which entities are allowed to write data to the devices and thus ensure the integrity of the data on their devices. - o U5.3 The device owner wants to control which entities are allowed - to read data on the devices and protect such data in transfer. + o U5.3 The principal wants to control which entities are allowed to + read data on the devices and protect such data in transfer. o U5.4 The devices may have intermittent Internet connectivity. - o U5.5 The device owner is not always present at the time of access - and cannot manually intervene in the authorization process. + o U5.5 The principal is not always present at the time of access and + cannot manually intervene in the authorization process. o U5.6 When authorization policies are updated it is impossible, or at least very inefficient to contact all affected devices directly. o U5.7 Messages between a client and the device may need to be stored and forwarded over multiple nodes. 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 functionalities can be integrated into fitness - equipment, games and even clothes. Owners can carry their devices - around with them at all times. + equipment, games and even clothes. Principals can carry their + devices around with them at all times. - Usability is especially important in this area since owners will + Usability is especially important in this area since principals 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 (preferably none at all). The required level of security will in most cases be low since security breaches will likely have less severe consequences. The continuous monitoring of data might however enable an attacker to create behavioral or movement profiles. Moreover, the aggregation of - data can seriously increase the impact on the privacy of device - owners. + data can seriously increase the impact on the privacy of principals. 2.6.1. Dynamically Connecting Smart Sports Equipment Jody is a 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 @@ -760,33 +777,33 @@ Jody's shoes are allowed to access the display and measuring features but cannot read or add training data. Jody's shoes connect to Lynn's watch after only a press of a button because Jody already configured access rights for devices that belong to Lynn a while ago. After an hour, Jody gives the watch back and both girls terminate the connection between their devices. 2.6.2. Authorization Problems Summary - o U6.1 The owner of a device wants to be able to grant access rights + o U6.1 The principal wants to be able to grant access rights dynamically when needed. - o U6.2 The owner wants the configuration of access rights to work - with very little effort. + o U6.2 The principle wants the configuration of access rights to + work with very little effort. - o U6.3 The device owner wants to be able to preconfigure access + o U6.3 The principal wants to be able to preconfigure access policies that grant certain access permissions to devices with certain attributes (e.g. devices of a certain user) without additional configuration effort at the time of access. - o U6.4 Device owners wants to protect the confidentiality of their - data for privacy reasons. + o U6.4 Principals wants to protect the confidentiality of their data + for privacy reasons. o U6.5 Devices might not have an Internet connection at the time of access. 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 @@ -796,22 +813,22 @@ general public how vulnerable this kind of systems are, especially when connected to the Internet. The severity of these vulnerabilities are exacerbated by the fact that many ICS are used to control critical public infrastructure, such as power, water treatment of traffic control. Nevertheless the economical advantages of connecting such systems to the Internet can be significant if appropriate security measures are put in place. 2.7.1. Oil Platform Control - An oil platform uses an industrical control system to monitor data - and control equipment. The purpose of this system is to gather and + 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. The controlling units are connected to the Internet, to allow for remote administration, since it is expensive and inconvenient to fly @@ -821,33 +838,33 @@ control messages and sensor readings. The access to some resources needs to be restricted to certain clients, e.g. the operator wants wireless actuators only to accept commands by authorized control units. The owner of the platform also wants to collect auditing information for liability reasons. 2.7.2. Authorization Problems Summary - o U7.1 The device owner wants to ensure that only authorized clients + o U7.1 The principal wants to ensure that only authorized clients can read data from sensors and sent commands to actuators. - o U7.2 The device owner wants to ensure that data coming from - sensors and commands sent to actuators are authentic. + o U7.2 The principal wants to ensure that data coming from sensors + and commands sent to actuators are authentic. o U7.3 Some devices do not have direct Internet connection. o U7.4 Some devices have wired connection while other use wireless. o U7.5 The execution of unauthorized commands in an ICS can lead to significant financial damage, and threaten the availability of - critical infrastructure services. Accordingly, the device owner + critical infrastructure services. Accordingly, the principal wants a security solution that provides a very high level of security. 3. Security Considerations As the use cases listed in this document demonstrate, constrained devices are used in various application areas. The appeal of these devices is that they are small and inexpensive. That makes it easy to integrate them into many aspects of everyday life. Therefore, the devices will be entrusted with vast amounts of valuable data or even @@ -864,21 +880,21 @@ 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 and hence 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 owners of constrained + This document lists security problems that principals 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. As some of the use cases indicate, constrained devices may be installed in hostile environments where they are physically @@ -907,62 +924,62 @@ o Size of code required to run the protocol o Size of RAM memory and stack required to run the protocol Another category of attacks that needs to be considered by solution developers is session interception and hijacking. 3.2. Configuration of Access Permissions - o The access control policies of the Resource Owner need to be - enforced (all use cases): The access control policies set by the - Resource Owner need to be provisioned to the device that enforces - the authorization and applied to every incoming request. + o The access control policies of the principals need to be enforced + (all use cases): The access control policies set by the Principals + need to be provisioned 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 e.g. Section 2.2, Section 2.3, Section 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. Design Considerations for Authorization Solutions - o Devices need to be enabled to enforce the owner's authorization - policies without the owner's intervention at the time of the - access request (see e.g. Section 2.1, Section 2.2, Section 2.4, - Section 2.5). + o Devices need to be enabled to enforce the principal's + authorization policies without the principal's intervention at the + time of the access request (see e.g. Section 2.1, Section 2.2, + Section 2.4, Section 2.5). o Authorization solutions need to consider that constrained devices might not have internet access at the time of the access request (see e.g. Section 2.1, Section 2.3, Section 2.5, Section 2.6). o It should be possible to update access control policies without manually re-provisioning individual devices (see e.g. Section 2.2, Section 2.3, Section 2.5, Section 2.6). Rationale: Peers can change rapidly which makes manual re- provisioning unreasonably expensive. - o Owners might define authorization policies for a large number of - devices that might only have intermittent connectivity. + o Principals might define authorization policies for 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. o It must be possible to dynamically revoke authorizations (see e.g. Section 2.4). o The authentication and access control protocol can put undue burden on the constrained resources of a device participating in the protocol. An authorization solutions must take the limitations of the constrained devices into account (see also @@ -993,43 +1010,43 @@ access control protocols e.g. end-to-end security between Client and Resource Server with DTLS might not be possible (see Section 2.5). 4. Privacy Considerations Many of the devices that are in focus of this document register data from the physical world (sensors) or affect processes in the physical world (actuators), which may involve data or processes belonging to individuals. To make matters worse the sensor data may be recorded continuously thus allowing to gather significant information about an - individual subject to the sensor readings. Therefore privacy + individual subject through the sensor readings. Therefore privacy protection is especially important, and Authentication and Access control are important tools for this, since they make it possible to control who gets access to private data. Privacy protection can also be weighted in when evaluating the need for end-to-end confidentiality, since otherwise intermediary nodes will learn the content of potentially sensitive messages sent between a client and a resource server and thereby endanger the privacy of the individual that may be subject of this data. In some cases, even the possession of a certain type of device can be - confidential, e.g. owners might not want to others to know that they - are wearing a certain medical device (see Section 2.3). + confidential, e.g. principals might not want to others to know that + they are wearing a certain medical device (see Section 2.3). The personal health monitoring use case (see Section 2.3) indicates the need for secure audit logs which impose specific requirements on a solution. Auditing is not in the scope of ACE. However, if an authorization solution provides means for audit logs, it must - consider the impact of logged data for the privacy of the owner and - other parties involved. - Suitable measures for protecting and purging the logs must be taken - during operation, maintenance and decommissioning of the device. + consider the impact of logged data for the privacy of the principal + and other parties involved. Suitable measures for protecting and + purging the logs must be taken during operation, maintenance and + decommissioning of the device. 5. 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, and Andreas Backman 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.