--- 1/draft-ietf-ace-usecases-05.txt 2015-09-23 04:15:32.391129153 -0700 +++ 2/draft-ietf-ace-usecases-06.txt 2015-09-23 04:15:32.455130718 -0700 @@ -1,37 +1,37 @@ ACE Working Group L. Seitz, Ed. Internet-Draft SICS Swedish ICT AB Intended status: Informational S. Gerdes, Ed. -Expires: March 4, 2016 Universitaet Bremen TZI +Expires: March 26, 2016 Universitaet Bremen TZI G. Selander Ericsson M. Mani Itron S. Kumar Philips Research - September 01, 2015 + September 23, 2015 ACE use cases - draft-ietf-ace-usecases-05 + draft-ietf-ace-usecases-06 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 environments. These use cases aim at identifying authorization - problems that arise during the lifecylce of a constrained device and + problems that arise during the lifecycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios. Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as communication protocol, however most conclusions apply generally. Status of This Memo @@ -41,21 +41,21 @@ 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 March 4, 2016. + This Internet-Draft will expire on March 26, 2016. Copyright Notice 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 @@ -72,49 +72,49 @@ 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Container monitoring . . . . . . . . . . . . . . . . . . 4 2.1.1. Bananas for Munich . . . . . . . . . . . . . . . . . 5 2.1.2. Authorization Problems Summary . . . . . . . . . . . 6 2.2. Home Automation . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. Controlling the Smart Home Infrastructure . . . . . . 7 2.2.2. Seamless Authorization . . . . . . . . . . . . . . . 8 2.2.3. Remotely letting in a visitor . . . . . . . . . . . . 8 2.2.4. Selling the house . . . . . . . . . . . . . . . . . . 8 2.2.5. Authorization Problems Summary . . . . . . . . . . . 8 - 2.3. Personal Health Monitoring . . . . . . . . . . . . . . . 10 + 2.3. Personal Health Monitoring . . . . . . . . . . . . . . . 9 2.3.1. John and the heart rate monitor . . . . . . . . . . . 10 2.3.2. Authorization Problems Summary . . . . . . . . . . . 11 - 2.4. Building Automation . . . . . . . . . . . . . . . . . . . 12 + 2.4. Building Automation . . . . . . . . . . . . . . . . . . . 11 2.4.1. Device Lifecycle . . . . . . . . . . . . . . . . . . 12 2.4.2. Public Safety . . . . . . . . . . . . . . . . . . . . 14 2.4.3. Authorization Problems Summary . . . . . . . . . . . 15 - 2.5. Smart Metering . . . . . . . . . . . . . . . . . . . . . 16 + 2.5. Smart Metering . . . . . . . . . . . . . . . . . . . . . 15 2.5.1. Drive-by metering . . . . . . . . . . . . . . . . . . 16 - 2.5.2. Meshed Topology . . . . . . . . . . . . . . . . . . . 17 + 2.5.2. Meshed Topology . . . . . . . . . . . . . . . . . . . 16 2.5.3. Advanced Metering Infrastructure . . . . . . . . . . 17 - 2.5.4. Authorization Problems Summary . . . . . . . . . . . 18 + 2.5.4. Authorization Problems Summary . . . . . . . . . . . 17 - 2.6. Sports and Entertainment . . . . . . . . . . . . . . . . 19 + 2.6. Sports and Entertainment . . . . . . . . . . . . . . . . 18 2.6.1. Dynamically Connecting Smart Sports Equipment . . . . 19 - 2.6.2. Authorization Problems Summary . . . . . . . . . . . 20 - 2.7. Industrial Control Systems . . . . . . . . . . . . . . . 20 - 2.7.1. Oil Platform Control . . . . . . . . . . . . . . . . 21 - 2.7.2. Authorization Problems Summary . . . . . . . . . . . 21 + 2.6.2. Authorization Problems Summary . . . . . . . . . . . 19 + 2.7. Industrial Control Systems . . . . . . . . . . . . . . . 19 + 2.7.1. Oil Platform Control . . . . . . . . . . . . . . . . 20 + 2.7.2. Authorization Problems Summary . . . . . . . . . . . 20 3. Security Considerations . . . . . . . . . . . . . . . . . . . 21 - 3.1. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 3.2. Configuration of Access Permissions . . . . . . . . . . . 23 + 3.1. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 3.2. Configuration of Access Permissions . . . . . . . . . . . 22 3.3. Authorization Considerations . . . . . . . . . . . . . . 23 3.4. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 - 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 + 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 + 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 - 7. Informative References . . . . . . . . . . . . . . . . . . . 26 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 + 7. Informative References . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction Constrained devices [RFC7228] are nodes with limited processing power, storage space and transmission capacities. These devices are often battery-powered and in many cases do not provide user interfaces. Constrained devices benefit from being interconnected using Internet protocols. However, due to the devices' limitations, commonly used @@ -182,24 +182,23 @@ where they are transloaded to other means of transportation, e.g. from ship transport to road transport. The transportation and storage of perishable goods is especially challenging since they have to be stored at a constant temperature and with proper ventilation. Additionally, it is very important for the vendors to be informed about irregularities in the temperature and ventilation of fruits to avoid the delivery of decomposed fruits to their customers. Real-time information on the state of the goods is needed for the transporter in order to prioritize goods that will - expire soon. - Furthermore the vendor also wants this type of information in real- - time, in order to be able to react when goods are spoiled and to be - able to still fulfill delivery obligations. + expire soon. Furthermore the vendor also wants this type of + information in real-time, in order to be able to react when goods are + spoiled and to be able to still fulfill delivery obligations. 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 @@ -241,23 +240,23 @@ 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 (U1.2, U1.8). The supermarket chain gains ownership of the banana boxes when the bananas have ripened and are ready to leave the ripening facility. 2.1.2. Authorization Problems Summary - o U1.1 Fruit vendors, transloading personnel and container owners - want to grant different authorizations for their resources and/or - endpoints to different parties. + o U1.1 Fruit vendors and container owners want to grant different + authorizations for their resources and/or endpoints to different + parties. o U1.2 The fruit vendor requires the integrity and authenticity of the sensor data that pertains the state of the goods for climate control and to ensure the quality of the monitored recordings. o U1.3 The container owner requires the integrity and authenticity of the sensor data that is used for climate control. o U1.4 The fruit vendor requires the confidentiality of the sensor data that pertains the state of the goods and the confidentiality @@ -379,21 +379,21 @@ control policies. o U2.3 A home owner wants to apply different access rights for different users. o U2.4 The home owners want to grant access permissions to a party for a specified time frame. 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). + smartphones, electronic key fobs, device gateways). o U2.6 The home owner wants to be able to configure authorization policies remotely. o U2.7 Authorized Users want to be able to obtain access with little effort. 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. @@ -442,24 +442,25 @@ 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 location (U3.7). In case of a cardiac arrest it automatically sends an alarm to an emergency service, transmitting - John's current location (U3.1). 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). To ensure Johns safety, the - device is expected to be in constant operation (U3.3, U3.6). + John's current location (U3.1). Either the device has long range + connectivity itself (e.g. via GSM) or it uses some intermediary, + nearby device (e.g. John's smartphone) to transmit such an alarm. To + ensure Johns safety, the device is expected to be in constant + operation (U3.3, U3.6). 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 (U3.8). 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 (U3.2). @@ -592,21 +594,21 @@ 2.4.1.3. Maintenance Company A's staff are annoyed that the lights switch off too often in their rooms if they work silently in front of their computer. Company A notifies the commissioning Company C about the issue and asks them to increase the delay before lights switch off (U4.4). Company C again gets the necessary authorization from the service company to interact with the BLMS. The commissioner's tool gets the - necessary authorization from BMLS to send a configuration change to + necessary authorization from BLMS to send a configuration change to all lighting devices in Company A's offices to increase their delay before they switch off. At some point the service company wants to update the firmware of lighting devices in order to eliminate software bugs. Before accepting the new firmware, each device checks the authorization of the service company to perform this update. 2.4.1.4. Decommissioning @@ -809,32 +810,34 @@ o U5.2 The utility company wants to control which entities are allowed to send data to, and read data from their endpoints. o U5.3 The utility company wants to ensure the integrity of the data stored on their endpoints. o U5.4 The utility company wants to protect such data transfers to and from their endpoints. - o U5.5 The devices may have intermittent Internet connectivity. + o U5.5 The devices may have intermittent Internet connectivity but + still need to enact the authorization policies of their + principals. o U5.6 Neither the service operator nor the utility company are always present at the time of access and cannot manually intervene in the authorization process. o U5.7 When authorization policies are updated it is impossible, or at least very inefficient to contact all affected endpoints directly. - o U5.8 Messages between endpoints may need to be stored and - forwarded over multiple nodes. + o U5.8 Authorization and authentication must work even if messages + between endpoints are stored and forwarded over multiple nodes. o U5.9 Consumers may not want the Service Operator, the Utility company or others to be able to have access to a fine-grained level of consumption data that allows the creation of behavioral profiles. 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 @@ -940,28 +943,32 @@ for liability reasons (U7.1). 2.7.2. Authorization Problems Summary o U7.1 The operator of the platform wants to ensure the integrity and confidentiality of sensor and actuator data. o U7.2 The operator 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.3 Some devices do not have direct Internet connection, but + still need to implement current authorization policies. - o U7.4 Some devices have wired connection while others use wireless. + o U7.4 Devices need to authenticate the controlling units, + especially those using a wireless connection. - 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 operator wants - a security solution that provides a very high level of security. + o U7.5 The execution of unauthorized commands or the failure to + execute an authorized command in an ICS can lead to significant + financial damage, and threaten the availability of critical + infrastructure services. Accordingly, the operator wants a + authentication and authorization mechanisms that provide 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 such devices will see vast amounts of valuable data passing through and might even be in control of important functions. These assets need to be protected from unauthorized access. Even seemingly innocuous