idnits 2.17.1 draft-ietf-ace-usecases-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 02, 2014) is 3431 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group L. Seitz, Ed. 3 Internet-Draft SICS Swedish ICT AB 4 Intended status: Informational S. Gerdes, Ed. 5 Expires: June 5, 2015 Universitaet Bremen TZI 6 G. Selander 7 Ericsson 8 M. Mani 9 Itron 10 S. Kumar 11 Philips Research 12 December 02, 2014 14 ACE use cases 15 draft-ietf-ace-usecases-00 17 Abstract 19 Constrained devices are nodes with limited processing power, storage 20 space and transmission capacities. These devices in many cases do 21 not provide user interfaces and are often intended to interact 22 without human intervention. 24 This document comprises a collection of representative use cases for 25 the application of authentication and authorization in constrained 26 environments. These use cases aim at identifying authorization 27 problems that arise during the lifecylce of a constrained device and 28 are intended to provide a guideline for developing a comprehensive 29 authentication and access control solution for this class of 30 scenarios. 32 Where specific details are relevant, it is assumed that the devices 33 use the Constrained Application Protocol (CoAP) as communication 34 protocol, however most conclusions apply generally. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on June 5, 2015. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1. Container monitoring . . . . . . . . . . . . . . . . . . 4 74 2.1.1. Bananas for Munich . . . . . . . . . . . . . . . . . 5 75 2.1.2. Authorization Problems Summary . . . . . . . . . . . 5 76 2.2. Home Automation . . . . . . . . . . . . . . . . . . . . . 6 77 2.2.1. Controlling the Smart Home Infrastructure . . . . . . 6 78 2.2.2. Seamless Authorization . . . . . . . . . . . . . . . 7 79 2.2.3. Remotely letting in a visitor . . . . . . . . . . . . 7 80 2.2.4. Authorization Problems Summary . . . . . . . . . . . 7 81 2.3. Personal Health Monitoring . . . . . . . . . . . . . . . 8 82 2.3.1. John and the heart rate monitor . . . . . . . . . . . 9 83 2.3.2. Authorization Problems Summary . . . . . . . . . . . 10 84 2.4. Building Automation . . . . . . . . . . . . . . . . . . . 10 85 2.4.1. Device Lifecycle . . . . . . . . . . . . . . . . . . 11 86 2.4.2. Authorization Problems Summary . . . . . . . . . . . 13 87 2.5. Smart Metering . . . . . . . . . . . . . . . . . . . . . 13 88 2.5.1. Drive-by metering . . . . . . . . . . . . . . . . . . 14 89 2.5.2. Meshed Topology . . . . . . . . . . . . . . . . . . . 14 90 2.5.3. Advanced Metering Infrastructure . . . . . . . . . . 14 91 2.5.4. Authorization Problems Summary . . . . . . . . . . . 15 92 2.6. Sports and Entertainment . . . . . . . . . . . . . . . . 16 93 2.6.1. Dynamically Connecting Smart Sports Equipment . . . . 16 94 2.6.2. Authorization Problems Summary . . . . . . . . . . . 17 95 2.7. Industrial Control Systems . . . . . . . . . . . . . . . 17 96 2.7.1. Oil Platform Control . . . . . . . . . . . . . . . . 17 97 2.7.2. Authorization Problems Summary . . . . . . . . . . . 18 98 3. Security Considerations . . . . . . . . . . . . . . . . . . . 18 99 3.1. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 3.2. Configuration of Access Permissions . . . . . . . . . . . 20 101 3.3. Design Considerations for Authorization Solutions . . . . 20 102 3.4. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 104 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 105 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 106 7. Informative References . . . . . . . . . . . . . . . . . . . 22 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 109 1. Introduction 111 Constrained devices [RFC7228] are nodes with limited processing 112 power, storage space and transmission capacities. These devices are 113 often battery-powered and in many cases do not provide user 114 interfaces. 116 Constrained devices benefit from being interconnected using Internet 117 protocols. However, due to the devices' limitations, commonly used 118 security protocols are not always easily applicable. As the devices 119 are expected to be integrated in all aspects of everyday life, the 120 application of adequate security mechanisms is required to prevent 121 attackers from gaining control over data or functions important to 122 our lives. 124 This document comprises a collection of representative use cases for 125 the application of authentication and authorization in constrained 126 environments. These use cases aim at identifying authorization 127 problems that arise during the lifecycle of a constrained device. 129 We assume that the communication between the devices is based on the 130 Representational State Transfer (REST) architectural style, i.e. a 131 device acts as a server that offers resources such as sensor data and 132 actuators. The resources can be accessed by clients, sometimes 133 without human intervention (M2M). In some situations the 134 communication will happen through intermediaries (e.g. gateways, 135 proxies). 137 Where specific detail is necessary it is assumed that the devices 138 communicate using CoAP [RFC7252], although most conclusions are 139 generic. 141 1.1. Terminology 143 Resource Server (RS): The constrained device which hosts resources 144 the Client wants to access. 146 Client (C): A device which wants to access a resource on the Resource 147 Server. 148 This could also be a constrained device. 150 Resource Owner (RO): The subject who owns the resource and controls 151 its access permissions. 153 2. Use Cases 155 This section lists use cases involving constrained devices with 156 certain authorization problems to be solved. Each use case first 157 presents a general description of the application area, then one or 158 more specific use cases, and finally a summary of the authorization- 159 related problems device owners need to be solved. 161 There are various reasons for assigning a function (client or 162 resource server) to a device, e.g. which device initiates the 163 conversation, how do devices find each other, etc. The definition of 164 the function of a device in a certain use case is not in scope of 165 this document. Readers should be aware that there might be reasons 166 for each setting and that devices might even have different functions 167 at different times. 169 2.1. Container monitoring 171 The ability of sensors to communicate environmental data wirelessly 172 opens up new application areas. The use of such sensor systems makes 173 it possible to continuously track and transmit specific 174 characteristics such as temperature, humidity and gas content during 175 the transportation and storage of goods. 177 The proper handling of the sensors in this scenario is not easy to 178 accomplish. They have to be associated to the appropriate pallet of 179 the respective container. Moreover, the goods and the corresponding 180 sensors belong to specific customers. 182 During the shipment to their destination the goods often pass stops 183 where they are transloaded to other means of transportation, e.g. 184 from ship transport to road transport. 186 The transportation and storage of perishable goods is especially 187 challenging since they have to be stored at a constant temperature 188 and with proper ventilation. Additionally, it is very important for 189 the vendors to be informed about irregularities in the temperature 190 and ventilation of fruits to avoid the delivery of decomposed fruits 191 to their customers. The need for a constant monitoring of perishable 192 goods has led to projects such as The Intelligent Container (http:// 193 www.intelligentcontainer.com). 195 2.1.1. Bananas for Munich 197 A fruit vendor grows bananas in Costa Rica for the German market. It 198 instructs a transport company to deliver the goods via ship to 199 Rotterdam where they are picked up by trucks and transported to a 200 ripening facility. A Munich supermarket chain buys ripened bananas 201 from the fruit vendor and transports them with their own company 202 trucks. 204 The fruit vendor's quality management wants to assure the quality of 205 their products and thus equips the banana boxes with sensors. The 206 state of the goods is monitored consistently during shipment and 207 ripening and abnormal sensor values are recorded. Additionally, the 208 sensor values are used to control the climate within the cargo 209 containers. Since a wrong sensor value leads to a wrong temperature 210 and thus to spoiled goods, the integrity of the sensor data must be 211 assured. 213 Due to the high water content of the fruits, the propagation of radio 214 waves is hindered, thus often inhibiting direct communication between 215 nodes [Jedermann14]. Instead, messages are forwarded over multiple 216 hops. Those relaying nodes might belong to different owners. The 217 sensors in the banana boxes cannot always reach the internet during 218 the journey. 220 The personnel that transloads the goods must be able to locate the 221 goods meant for a specific customer. However the fruit vendor does 222 not want to disclose sensor information pertaining to the condition 223 of the goods to other companies and therefore wants to assure the 224 confidentiality of this data. 226 When the goods arrive at the supermarket in Munich, the supermarket 227 conducts its own quality check. If no anomalies occurred during the 228 transport, the bananas are admitted for sale. 230 2.1.2. Authorization Problems Summary 232 o U1.1 The device owner wants to grant different access rights to a 233 resource to different parties. 235 o U1.2 The device owner wants to control which devices are allowed 236 to present data to the device. 238 o U1.3 The device owner wants to grant different access rights for 239 different resources on a device. 241 o U1.4 The device owner requires the integrity of sensor data. 243 o U1.5 The device owner requires the confidentiality of sensor data. 245 o U1.6 The device owner is not always present at the time of access 246 and cannot manually intervene in the authorization process. 248 o U1.7 The device owner wants to grant temporary access permissions 249 to a party. 251 o U1.8 Messages between client and resource server might need to be 252 forwarded over multiple hops. 254 o U1.9 The constrained device might not always be able to reach the 255 internet. 257 2.2. Home Automation 259 Automation of the home has the potential to become a big future 260 market for the Internet of Things. A home automation system connects 261 devices in a house to the Internet and thus makes them accessible and 262 manageable remotely. Such devices might control for example heating, 263 ventilation, lighting, home entertainment or home security. 265 Such a system needs to accommodate a number of regular users 266 (inhabitants, close friends, cleaning personnel) as well as a 267 heterogeneous group of dynamically varying users (visitors, 268 repairmen, delivery men). 270 As the users are not typically trained in security (or even computer 271 use), the configuration must use secure default settings, and the 272 interface must be well adapted to novice users. 274 2.2.1. Controlling the Smart Home Infrastructure 276 Jane and her husband George own a flat which is equipped with home 277 automation devices such as HVAC and shutter control, and they have a 278 motion sensor in the corridor which controls the light bulbs there. 280 Jane and George can control the shutters and the temperature in each 281 room using either wall-mounted touch panels or their smartphones. 282 Since Jane and George both have a full-time job, they want to be able 283 to change settings remotely, e.g. turn up the heating on a cold day 284 if they will be home earlier than expected. 286 The couple does not want people in radio range of their devices, e.g. 287 their neighbors, to be able to control them without authorization. 288 Moreover, they don't want burglars to be able to deduce behavioral 289 patterns from eavesdropping on the network. 291 2.2.2. Seamless Authorization 293 Jane buys a new light bulb for the corridor and integrates it into 294 the home network (how she does that is not in scope). George is not 295 at home, but Jane wants him to be able to control the new device with 296 his smart phone without the need for additional administration 297 effort. 299 2.2.3. Remotely letting in a visitor 301 Jane and George have equipped their home with automated connected 302 door-locks and an alarm system at the door and the windows. The 303 couple can control this system remotely. 305 Jane and George have invited Jane's parents over for dinner, but are 306 stuck in traffic and can not arrive in time, while Jane's parents who 307 use the subway will arrive punctually. Jane calls her parents and 308 offers to let them in remotely, so they can make themselves 309 comfortable while waiting. 311 Jane's parents download an application that lets them communicate 312 with Jane's door-lock and alarm system. Then Jane sets temporary 313 permissions that allow them to open the door, and shut down the alarm 314 when they arrive. 316 The security system controlling the door-locks and alarm system needs 317 to be at least as secure as for a comparable unautomated home. 319 2.2.4. Authorization Problems Summary 321 o U2.1 A home owner wants to spontaneously provision authorization 322 means to visitors. 324 o U2.2 A home owner wants to spontaneously change the home's access 325 control policies. 327 o U2.3 A home owner wants to apply different access rights for 328 different users. 330 o U2.4 A home owner wants to apply context-based conditions 331 (presence, time) to authorizations, and the devices need to be 332 able to verify these conditions. 334 o U2.5 The smart home devices need to be able to communicate with 335 different control devices (e.g. wall-mounted touch panels, 336 smartphones, electronic key fobs). 338 o U2.6 The access control configuration of the automated home needs 339 to be secure by default. 341 o U2.7 The access control policies need to be easy to edit, even 342 remotely and it needs to be easy to get access with correct 343 authorization. 345 o U2.8 The owners of the automated home wants to prevent 346 eavesdroppers form being able to deduce behavioral profiles from 347 the home network. 349 o U2.9 Usability is particularly important in this scenario since 350 administrative tasks such as installation, configuration and 351 decommissioning of devices likely need to be performed by the home 352 owners who in most cases have little knowledge of security. 354 o U2.10 Home Owners want their devices to seamlessly (and in some 355 cases even unnoticeably) fulfill their purpose. The 356 administration effort needs to be kept at a minimum. 358 2.3. Personal Health Monitoring 360 The use of wearable health monitoring technology is expected to grow 361 strongly, as a multitude of novel devices are developed and marketed. 362 The need for open industry standards to ensure interoperability 363 between products has lead to initiatives such as Continua Alliance 364 (continuaalliance.org) and Personal Connected Health Alliance 365 (pchalliance.org). Personal health devices are typically battery 366 driven, and located physically on the user. They monitor some bodily 367 function, such as e.g. temperature, blood pressure, or pulse. They 368 are connected to the Internet through an intermediary base-station, 369 using wireless technologies. Through this connection they report the 370 monitored data to some entity, which may either be the user herself, 371 or some medical personnel in charge of the user. 373 Medical data has always been considered as very sensitive, and 374 therefore requires good protection against unauthorized disclosure. 375 A frequent, conflicting requirement is the capability for medical 376 personnel to gain emergency access, even if no specific access rights 377 exist. As a result, the importance of secure audit logs increases in 378 such scenarios. 380 Since the users are not typically trained in security (or even 381 computer use), the configuration must use secure default settings, 382 and the interface must be well adapted to novice users. Parts of the 383 system must operate with minimal maintenance. Especially frequent 384 changes of battery are unacceptable. 386 2.3.1. John and the heart rate monitor 388 John has a heart condition, that can result in sudden cardiac 389 arrests. He therefore uses a device called HeartGuard that monitors 390 his heart rate and his position. In case of a cardiac arrest it 391 automatically sends an alarm to an emergency service, transmitting 392 John's current location. The HeartGuard also broadcasts emergency 393 information in the neighborhood to notify doctors or people with 394 certain skills who have been enrolled in an emergency program, e.g. 395 people who got training in heart and lung rescue. For doctors, 396 medical information or diagnosis can be provided with the 397 notification to improve immediate treatment. 399 The device includes some smart logic, with which it identifies its 400 owner John and allows him to configure the device's settings, 401 including access control. 402 This prevents situation where someone else wearing that device can 403 act as the owner and mess up the access control and security 404 settings. 406 John can configure additional persons that get notified in an 407 emergency, for example his daughter Jill. Furthermore the device 408 stores data on John's heart rate, which can later be accessed by a 409 physician to assess the condition of John's heart. 411 However John is a rather private person, and is worried that Jill 412 might use HeartGuard to monitor his location while there is no 413 emergency. Furthermore he doesn't want his health insurance to get 414 access to the HeartGuard data, or even to the fact that he is wearing 415 a HeartGuard, since they might refuse to renew his insurance if they 416 decided he was too big a risk for them. 418 NOTE: Monitoring of some state parameter (e.g. an alarm button) and 419 the position of a person also fits well into an elderly care service. 420 This is particularly useful for people suffering from dementia, where 421 the relatives or caregivers need to be notified of the whereabouts of 422 the person under certain conditions. In this case it is not the 423 patient that decides about access. 425 2.3.2. Authorization Problems Summary 427 o U3.1 A device owner wants to pre-configure access rights to 428 specific data for persons or groups, in the context of an 429 emergency. 431 o U3.2 A device owner wants to selectively allow different persons 432 or groups to access medical data. 434 o U3.3 A device owner wants to block access to specific persons in 435 an otherwise allowed group (e.g. doctors in an emergency), if he 436 mistrusts them. 438 o U3.4 The security measures could affect battery lifetime of the 439 devices and should changes of battery are highly inconvenient. 441 o U3.5 Devices are often used with default access control settings. 443 o U3.6 Device users are often not trained in computer use and 444 especially computer security. 446 o U3.7 Security mechanisms themselves could provide opportunities 447 for denial of service attacks on the device. 449 o U3.8 The device provides a service that can be fatal for the 450 device owner if it fails. Accordingly, the device owner wants a 451 security mechanism to provide a high level of security. 453 2.4. Building Automation 455 Buildings for commercial use such as shopping malls or office 456 buildings nowadays are equipped increasingly with semi-automatic 457 components to enhance the overall living quality and to save energy 458 where possible. This includes for example heating, ventilation and 459 air condition (HVAC) as well as illumination and security systems 460 such as fire alarms. 462 Different areas of these buildings are often exclusively leased to 463 different companies. However they also share some of the common 464 areas of the building. 465 Accordingly, a company must be able to control the light and HVAC 466 system of its own part of the building and must not have access to 467 control rooms that belong to other companies. 469 Some parts of the building automation system such as entrance 470 illumination and fire alarm systems are controlled either by all 471 parties together or by a service company. 473 2.4.1. Device Lifecycle 475 2.4.1.1. Installation and Commissioning 477 A building is hired out to different companies for office space. 478 This building features various automated systems, such as a fire 479 alarm system, which is triggered by several smoke detectors which are 480 spread out across the building. It also has automated HVAC, lighting 481 and physical access control systems. 483 A vacant area of the building has been recently leased to company A. 484 Before moving into its new office, Company A wishes to replace the 485 lighting with a more energy efficient and a better light quality 486 luminaries. They hire an installation and commissioning company C to 487 redo the illumination. Company C is instructed to integrate the new 488 lighting devices, which may be from multiple manufacturers, into the 489 existing lighting infrastructure of the building which includes 490 presence sensors, switches, controllers etc. 492 Company C gets the necessary authorization from the service company 493 to interact with the existing Building and Lighting Management System 494 (BLMS). To prevent disturbance to other occupants of the building, 495 Company C is provided authorization to perform the commissioning only 496 during non-office hours and only to modify configuration on devices 497 belonging to the domain of Company A's space. After installation 498 (wiring) of the new lighting devices, the commissioner adds the 499 devices into the company A's lighting domain. 501 Once the devices are in the correct domain, the commissioner 502 authorizes the interaction rules between the new lighting devices and 503 existing devices like presence sensors. For this, the commissioner 504 creates the authorization rules on the BLMS which define which lights 505 form a group and which sensors /switches/controllers are allowed to 506 control which groups. These authorization rules may be context based 507 like time of the day (office or non-office hours) or location of the 508 handheld lighting controller etc. 510 2.4.1.2. Operational 512 Company A's staff move into the newly furnished office space. Most 513 lighting is controlled by presence sensors which control the lighting 514 of specific group of lights based on the authorization rules in the 515 BLMS. Additionally employees are allowed to manually override the 516 lighting brightness and color in their office by using the switches 517 or handheld controllers. Such changes are allowed only if the 518 authorization rules exist in the BLMS. For example lighting in the 519 corridors may not be manually adjustable. 521 At the end of the day, lighting is dimmed down or switched off if no 522 occupancy is detected even if manually overridden during the day. 524 On a later date company B also moves into the same building, and 525 shares some of the common spaces with company A. On a really hot day 526 James who works for company A turns on the air condition in his 527 office. Lucy who works for company B wants to make tea using an 528 electric kettle. After she turned it on she goes outside to talk to 529 a colleague until the water is boiling. Unfortunately, her kettle 530 has a malfunction which causes overheating and results in a 531 smoldering fire of the kettle's plastic case. 533 Due to the smoke coming from the kettle the fire alarm is triggered. 534 Alarm sirens throughout the building are switched on simultaneously 535 (using a broadcastor multicast) to alert the staff of both companies. 536 Additionally, the ventilation system of the whole building is closed 537 off to prevent the smoke from spreading and to withdraw oxygen from 538 the fire. The smoke cannot get into James' office although he turned 539 on his air condition because the fire alarm overrides the manual 540 setting by sending commands (broadcast or multicast) to switch off 541 all the air conditioning. 543 The fire department is notified of the fire automatically and arrives 544 within a short time. After inspecting the damage and extinguishing 545 the smoldering fire a fire fighter resets the fire alarm because only 546 the fire department is authorized to do that. 548 2.4.1.3. Maintenance 550 Company A's staff are annoyed that the lights switch off too often in 551 their rooms if they work silently in front of their computer. 552 Company A notifies the commissioning Company C about the issue and 553 asks them to increase the delay before lights switch off. 555 Company C again gets the necessary authorization from the service 556 company to interact with the BLMS. The commissioner's tool gets the 557 necessary authorization from BMLS to send a configuration change to 558 all lighting devices in Company A's offices to increase their delay 559 before they switch off. 561 2.4.1.4. Decommissioning 563 Company A has noticed that the handheld controllers are often 564 misplaced and hard to find when needed. So most of the time staff 565 use the existing wall switches for manual control. Company A decides 566 it would be better to completely remove handheld controllers and asks 567 Company C to decommission them from the lighting system. 569 Company C again gets the necessary authorization from the service 570 company to interact with the BLMS. The commissioner now deletes any 571 rules that allowed handheld controllers authorization to control the 572 lighting. Additionally the commissioner instructs the BLMS to push 573 these new rules to prevent cached rules at the end devices from being 574 used. 576 2.4.2. Authorization Problems Summary 578 o U4.1 Device owners want to be able to add a new device to their 579 administrative domain (commissioning). 581 o U4.2 Device owners want to be able to integrate a device that 582 formerly belonged to a different administrative domain to their 583 own administrative domain (handover). 585 o U4.3 Device owner want to be able to remove a device from their 586 administrative domain (decomissioning). 588 o U4.4 Device owners want to be able to delegate selected 589 administration tasks for their devices to others. 591 o U4.5 The device owner wants to be able to define context-based 592 Authorization rules. 594 o U4.6 The device owner wants to be able to revoke granted 595 permissions and delegations. 597 o U4.7 The device owner wants to allow only authorized access to 598 device resources (default deny). 600 o U4.8 The device owner wants to be able to authorize a device to 601 control several devices at the same time using a multicast 602 protocol. 604 o U4.9 Device owners want to be able to interconnect their own 605 subsystems with those from a different operational domain while 606 keeping the control over the authorizations (e.g. granting and 607 revoking permissions) for their devices. 609 2.5. Smart Metering 611 Automated measuring of customer consumption is an established 612 technology for electricity, water, and gas providers. Increasingly 613 these systems also feature networking capability to allow for remote 614 management. Such systems are in use for commercial, industrial and 615 residential customers and require a certain level of security, in 616 order to avoid economic loss to the providers, vulnerability of the 617 distribution system, as well as disruption of services for the 618 customers. 620 The smart metering equipment for gas and water solutions is battery 621 driven and communication should be used sparingly due to battery 622 consumption. Therefore the types of meters sleep most of the time, 623 and only wake up every minute/hour to check for incoming 624 instructions. Furthermore they wake up a few times a day (based on 625 their configuration) to upload their measured metering data. 627 Different networking topologies exist for smart metering solutions. 628 Based on environment, regulatory rules and expected cost, one or a 629 mixture of these topologies may be deployed to collect the metering 630 information. Drive-By metering is one of the most current solutions 631 deployed for collection of gas and water meters. 633 2.5.1. Drive-by metering 635 A service operator offers smart metering infrastructures and related 636 services to various utility companies. Among these is a water 637 provider, who in turn supplies several residential complexes in a 638 city. The smart meters are installed in the end customer's homes to 639 measure water consumption and thus generate billing data for the 640 utility company. The meters do so by sending data to a base station. 641 Several base stations are installed around the city to collect the 642 metering data. However in the denser urban areas, the base stations 643 would have to be installed very close to the meters. This would 644 require a high number of base stations and expose this more expensive 645 equipment to manipulation or sabotage. The service operator has 646 therefore chosen another approach, which is to drive around with a 647 mobile base-station and let the meters connect to that in regular 648 intervals in order to gather metering data. 650 2.5.2. Meshed Topology 652 In another deployment, the water meters are installed in a building 653 that already has power meters installed, the latter are mains 654 powered, and are therefore not subject to the same power saving 655 restrictions. The water meters can therefore use the power meters as 656 proxies, in order to achieve better connectivity. This requires the 657 security measures on the water meters to work through intermediaries. 659 2.5.3. Advanced Metering Infrastructure 661 A utility company is updating its old utility distribution network 662 with advanced meters and new communication systems, known as an 663 Advanced Metering Infrastructure (AMI). AMI refers to a system that 664 measures, collects and analyzes usage, and interacts with metering 665 devices such as electricity meters, gas meters, heat meters, and 666 water meters, through various communication media either on request 667 (on-demand) or on pre-defined schedules. Based on this technology, 668 new services make it possible for consumers to control their utility 669 consumption and reduce costs by supporting new tariff models from 670 utility companies, and more accurate and timely billing. 672 The technical solution is based on levels of data aggregation between 673 smart meters located at the consumer premises and the Meter Data 674 Management (MDM) system located at the utility company. Two possible 675 intermediate levels are: 677 o Head-End System (HES) which is hardware and software that receives 678 the stream of meter data and exposes an interface to the MDM. 680 o Data Collection (DC) units located in a local network 681 communicating with a number of smart meters and with a backhaul 682 interface communicating with the HES, e.g. using cellular 683 communication. 685 For reasons of efficiency and cost end-to-end connectivity is not 686 always feasible, so metering data is stored in batches in DC for some 687 time before being forwarded to the HES, and in turn accessed by the 688 MDM. The HES and the DC units may be operated by a third party 689 service operator on behalf of the utility company. One 690 responsibility of the service operator is to make sure that meter 691 readings are performed and delivered to the HES. An example of a 692 Service Level Agreement between the service operator and the utility 693 company is e.g. "at least 95 % of the meters have readings recorded 694 during the last 72 hours". 696 2.5.4. Authorization Problems Summary 698 o U5.1 Devices are installed in hostile environments where they are 699 physically accessible by attackers. Device owners want to make 700 sure that an attacker cannot use a captured device to attack other 701 parts of their infrastructure. 703 o U5.2 Device owners want to restrict which entities are allowed to 704 write data to the devices and thus ensure the integrity of the 705 data on their devices. 707 o U5.3 The device owner wants to control which entities are allowed 708 to read data on the devices and protect such data in transfer. 710 o U5.4 The devices may have intermittent Internet connectivity. 712 o U5.5 The device owner is not always present at the time of access 713 and cannot manually intervene in the authorization process. 715 o U5.6 When authorization policies are updated it is impossible, or 716 at least very inefficient to contact all affected devices 717 directly. 719 o U5.7 Messages between a client and the device may need to be 720 stored and forwarded over multiple nodes. 722 2.6. Sports and Entertainment 724 In the area of leisure time activities, applications can benefit from 725 the small size and weight of constrained devices. Sensors and 726 actuators with various functionalities can be integrated into fitness 727 equipment, games and even clothes. Owners can carry their devices 728 around with them at all times. 730 Usability is especially important in this area since owners will 731 often want to spontaneously interconnect their devices with others. 732 Therefore the configuration of access permissions must be simple and 733 fast and not require much effort at the time of access (preferably 734 none at all). 736 The required level of security will in most cases be low since 737 security breaches will likely have less severe consequences. The 738 continuous monitoring of data might however enable an attacker to 739 create behavioral or movement profiles. Moreover, the aggregation of 740 data can seriously increase the impact on the privacy of device 741 owners. 743 2.6.1. Dynamically Connecting Smart Sports Equipment 745 Jody is a an enthusiastic runner. To keep track of her training 746 progress, she has smart running shoes that measure the pressure at 747 various points beneath her feet to count her steps, detect 748 irregularities in her stride and help her to improve her posture and 749 running style. On a sunny afternoon, she goes to the Finnbahn track 750 near her home to work out. She meets her friend Lynn who shows her 751 the smart fitness watch she bought a few days ago. The watch can 752 measure the wearer's pulse, show speed and distance, and keep track 753 of the configured training program. The girls detect that the watch 754 can be connected with Jody's shoes and then can additionally display 755 the information the shoes provide. 757 Jody asks Lynn to let her try the watch and lend it to her for the 758 afternoon. Lynn agrees but doesn't want Jody to access her training 759 plan. She configures the access policies for the watch so that 760 Jody's shoes are allowed to access the display and measuring features 761 but cannot read or add training data. Jody's shoes connect to Lynn's 762 watch after only a press of a button because Jody already configured 763 access rights for devices that belong to Lynn a while ago. 765 After an hour, Jody gives the watch back and both girls terminate the 766 connection between their devices. 768 2.6.2. Authorization Problems Summary 770 o U6.1 The owner of a device wants to be able to grant access rights 771 dynamically when needed. 773 o U6.2 The owner wants the configuration of access rights to work 774 with very little effort. 776 o U6.3 The device owner wants to be able to preconfigure access 777 policies that grant certain access permissions to devices with 778 certain attributes (e.g. devices of a certain user) without 779 additional configuration effort at the time of access. 781 o U6.4 Device owners wants to protect the confidentiality of their 782 data for privacy reasons. 784 o U6.5 Devices might not have an Internet connection at the time of 785 access. 787 2.7. Industrial Control Systems 789 Industrial control systems (ICS) and especially supervisory control 790 and data acquisition systems (SCADA) use a multitude of sensors and 791 actuators in order to monitor and control industrial processes in the 792 physical world. Example processes include manufacturing, power 793 generation, and refining of raw materials. 795 Since the advent of the Stuxnet worm it has become obvious to the 796 general public how vulnerable this kind of systems are, especially 797 when connected to the Internet. The severity of these 798 vulnerabilities are exacerbated by the fact that many ICS are used to 799 control critical public infrastructure, such as power, water 800 treatment of traffic control. Nevertheless the economical advantages 801 of connecting such systems to the Internet can be significant if 802 appropriate security measures are put in place. 804 2.7.1. Oil Platform Control 806 An oil platform uses an industrical control system to monitor data 807 and control equipment. The purpose of this system is to gather and 808 process data from a large number of sensors, and control actuators 809 such as valves and switches to steer the oil extraction process on 810 the platform. Raw data, alarms, reports and other information are 811 also available to the operators, who can intervene with manual 812 commands. Many of the sensors are connected to the controlling units 813 by direct wire, but the operator is slowly replacing these units by 814 wireless ones, since this makes maintenance easier. 816 The controlling units are connected to the Internet, to allow for 817 remote administration, since it is expensive and inconvenient to fly 818 in a technician to the platform. 820 The main interest of the operator is to ensure the integrity of 821 control messages and sensor readings. The access to some resources 822 needs to be restricted to certain clients, e.g. the operator wants 823 wireless actuators only to accept commands by authorized control 824 units. 826 The owner of the platform also wants to collect auditing information 827 for liability reasons. 829 2.7.2. Authorization Problems Summary 831 o U7.1 The device owner wants to ensure that only authorized clients 832 can read data from sensors and sent commands to actuators. 834 o U7.2 The device owner wants to ensure that data coming from 835 sensors and commands sent to actuators are authentic. 837 o U7.3 Some devices do not have direct Internet connection. 839 o U7.4 Some devices have wired connection while other use wireless. 841 o U7.5 The execution of unauthorized commands in an ICS can lead to 842 significant financial damage, and threaten the availability of 843 critical infrastructure services. Accordingly, the device owner 844 wants a security solution that provides a very high level of 845 security. 847 3. Security Considerations 849 As the use cases listed in this document demonstrate, constrained 850 devices are used in various application areas. The appeal of these 851 devices is that they are small and inexpensive. That makes it easy 852 to integrate them into many aspects of everyday life. Therefore, the 853 devices will be entrusted with vast amounts of valuable data or even 854 control functions, that need to be protected from unauthorized 855 access. 857 Moreover, the aggregation of data must be considered: attackers might 858 not only collect data from a single device but from many devices, 859 thus increasing the potential damage. 861 Not only the data on the constrained devices themselves is 862 threatened, the devices might also be abused as an intrusion point to 863 infiltrate a network. Once an attacker gained control over the 864 device, it can be used to attack other devices as well. Due to their 865 limited capabilities, constrained devices appear as the weakest link 866 in the network and hence pose an attractive target for attackers. 868 This section summarizes the security problems highlighted by the use 869 cases above and provides guidelines for the design of protocols for 870 authentication and authorization in constrained RESTful environments. 872 3.1. Attacks 874 This document lists security problems that owners of constrained 875 devices want to solve. Further analysis of attack scenarios is not 876 in scope of the document. However, there are attacks that must be 877 considered by solution developers. 879 Because of the expected large number of devices and their ubiquity, 880 constrained devices increase the danger from Pervasive Monitoring 881 [RFC7258] attacks. 883 As some of the use cases indicate, constrained devices may be 884 installed in hostile environments where they are physically 885 accessible (see Section 2.5). Protection from physical attacks is 886 not in the scope of ACE, but should be kept in mind by developers of 887 authorization solutions. 889 Denial of service (DoS) attacks threaten the availability of services 890 a device provides. E.g., an attacker can induce a device to perform 891 steps of a heavy weight security protocol (e.g. Datagram Transport 892 Layer Security (DTLS) [RFC6347]) before authentication and 893 authorization can be verified, thus exhausting the device's system 894 resources. This leads to a temporary or - e.g. if the batteries are 895 drained - permanent failure of the service. For some services of 896 constrained devices, availability is especially important (see 897 Section 2.3). Because of their limitations, constrained devices are 898 especially vulnerable to denial of service attacks. Solution 899 designers must be particularly careful to consider these limitations 900 in every part of the protocol. This includes: 902 o Battery usage 904 o Number of message exchanges required by security measures 905 o Size of data that is transmitted (e.g. authentication and access 906 control data) 908 o Size of code required to run the protocol 910 o Size of RAM memory and stack required to run the protocol 912 Another category of attacks that needs to be considered by solution 913 developers is session interception and hijacking. 915 3.2. Configuration of Access Permissions 917 o The access control policies of the Resource Owner need to be 918 enforced (all use cases): The access control policies set by the 919 Resource Owner need to be provisioned to the device that enforces 920 the authorization and applied to every incoming request. 922 o A single resource might have different access rights for different 923 requesting entities (all use cases). 925 Rationale: In some cases different types of users need different 926 access rights, as opposed to a binary approach where the same 927 access permissions are granted to all authenticated users. 929 o A device might host several resources where each resource has its 930 own access control policy (all use cases). 932 o The device that makes the policy decisions should be able to 933 evaluate context-based permissions such as location or time of 934 access (see e.g. Section 2.2, Section 2.3, Section 2.4). Access 935 may depend on local conditions, e.g. access to health data in an 936 emergency. The device that makes the policy decisions should be 937 able to take such conditions into account. 939 3.3. Design Considerations for Authorization Solutions 941 o Devices need to be enabled to enforce the owner's authorization 942 policies without the owner's intervention at the time of the 943 access request (see e.g. Section 2.1, Section 2.2, Section 2.4, 944 Section 2.5). 946 o Authorization solutions need to consider that constrained devices 947 might not have internet access at the time of the access request 948 (see e.g. Section 2.1, Section 2.3, Section 2.5, Section 2.6). 950 o It should be possible to update access control policies without 951 manually re-provisioning individual devices (see e.g. Section 2.2, 952 Section 2.3, Section 2.5, Section 2.6). 954 Rationale: Peers can change rapidly which makes manual re- 955 provisioning unreasonably expensive. 957 o Owners might define authorization policies for a large number of 958 devices that might only have intermittent connectivity. 959 Distributing policy updates to every device for every update might 960 not be a feasible solution. 962 o It must be possible to dynamically revoke authorizations (see e.g. 963 Section 2.4). 965 o The authentication and access control protocol can put undue 966 burden on the constrained resources of a device participating in 967 the protocol. An authorization solutions must take the 968 limitations of the constrained devices into account (see also 969 Section 3.1). 971 o Secure default settings are needed for the initial state of the 972 authentication and authorization protocols (all use cases). 974 Rationale: Many attacks exploit insecure default settings, and 975 experience shows that default settings are frequently left 976 unchanged by the end users. 978 o Access to resources on other devices should only be permitted if a 979 rule exists that explicitly allows this access (default deny). 981 o Usability is important for all use cases. The configuration of 982 authorization policies as well as the gaining access to devices 983 must be simple for the users of the devices. Special care needs 984 to be taken for home scenarios where access control policies have 985 to be configured by users that are typically not trained in 986 security (see Section 2.2, Section 2.6). 988 3.4. Proxies 990 In some cases, the traffic between Client and Resource Server might 991 go through intermediary nodes (e.g. proxies, gateways). This might 992 affect the function or the security model of authentication and 993 access control protocols e.g. end-to-end security between Client and 994 Resource Server with DTLS might not be possible (see Section 2.5). 996 4. Privacy Considerations 998 Many of the devices that are in focus of this document register data 999 from the physical world (sensors) or affect processes in the physical 1000 world (actuators), which may involve data or processes belonging to 1001 individuals. To make matters worse the sensor data may be recorded 1002 continuously thus allowing to gather significant information about an 1003 individual subject to the sensor readings. Therefore privacy 1004 protection is especially important, and Authentication and Access 1005 control are important tools for this, since they make it possible to 1006 control who gets access to private data. 1008 Privacy protection can also be weighted in when evaluating the need 1009 for end-to-end confidentiality, since otherwise intermediary nodes 1010 will learn the content of potentially sensitive messages sent between 1011 a client and a resource server and thereby endanger the privacy of 1012 the individual that may be subject of this data. 1014 In some cases, even the possession of a certain type of device can be 1015 confidential, e.g. owners might not want to others to know that they 1016 are wearing a certain medical device (see Section 2.3). 1018 The personal health monitoring use case (see Section 2.3) indicates 1019 the need for secure audit logs which impose specific requirements on 1020 a solution. Auditing is not in the scope of ACE. However, if an 1021 authorization solution provides means for audit logs, it must 1022 consider the impact of logged data for the privacy of the owner and 1023 other parties involved. 1024 Suitable measures for protecting and purging the logs must be taken 1025 during operation, maintenance and decommissioning of the device. 1027 5. Acknowledgments 1029 The authors would like to thank Olaf Bergmann, Sumit Singhal, John 1030 Mattson, Mohit Sethi, Carsten Bormann, Martin Murillo, Corinna 1031 Schmitt, Hannes Tschofenig, Erik Wahlstroem, and Andreas Backman for 1032 reviewing and/or contributing to the document. Also, thanks to 1033 Markus Becker, Thomas Poetsch and Koojana Kuladinithi for their input 1034 on the container monitoring use case. 1036 Ludwig Seitz and Goeran Selander worked on this document as part of 1037 EIT-ICT Labs activity PST-14056. 1039 6. IANA Considerations 1041 This document has no IANA actions. 1043 7. Informative References 1045 [Jedermann14] 1046 Jedermann, R., Poetsch, T., and C. LLoyd, "Communication 1047 techniques and challenges for wireless food quality 1048 monitoring", Philosophical Transactions of the Royal 1049 Society A Mathematical, Physical and Engineering Sciences, 1050 May 2014. 1052 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1053 Security Version 1.2", RFC 6347, January 2012. 1055 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1056 Constrained-Node Networks", RFC 7228, May 2014. 1058 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1059 Application Protocol (CoAP)", RFC 7252, June 2014. 1061 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1062 Attack", BCP 188, RFC 7258, May 2014. 1064 Authors' Addresses 1066 Ludwig Seitz (editor) 1067 SICS Swedish ICT AB 1068 Scheelevaegen 17 1069 Lund 223 70 1070 Sweden 1072 Email: ludwig@sics.se 1074 Stefanie Gerdes (editor) 1075 Universitaet Bremen TZI 1076 Postfach 330440 1077 Bremen 28359 1078 Germany 1080 Phone: +49-421-218-63906 1081 Email: gerdes@tzi.org 1083 Goeran Selander 1084 Ericsson 1085 Faroegatan 6 1086 Kista 164 80 1087 Sweden 1089 Email: goran.selander@ericsson.com 1090 Mehdi Mani 1091 Itron 1092 52, rue Camille Desmoulins 1093 Issy-les-Moulineaux 92130 1094 France 1096 Email: Mehdi.Mani@itron.com 1098 Sandeep S. Kumar 1099 Philips Research 1100 High Tech Campus 1101 Eindhoven 5656 AA 1102 The Netherlands 1104 Email: sandeep.kumar@philips.com