idnits 2.17.1 draft-ietf-ace-usecases-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 09, 2015) is 3328 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 (~~), 1 warning (==), 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: September 10, 2015 Universitaet Bremen TZI 6 G. Selander 7 Ericsson 8 M. Mani 9 Itron 10 S. Kumar 11 Philips Research 12 March 09, 2015 14 ACE use cases 15 draft-ietf-ace-usecases-03 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 authorization 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 September 10, 2015. 53 Copyright Notice 55 Copyright (c) 2015 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 . . . . . . . . . . . 6 76 2.2. Home Automation . . . . . . . . . . . . . . . . . . . . . 6 77 2.2.1. Controlling the Smart Home Infrastructure . . . . . . 7 78 2.2.2. Seamless Authorization . . . . . . . . . . . . . . . 7 79 2.2.3. Remotely letting in a visitor . . . . . . . . . . . . 7 80 2.2.4. Authorization Problems Summary . . . . . . . . . . . 8 81 2.3. Personal Health Monitoring . . . . . . . . . . . . . . . 9 82 2.3.1. John and the heart rate monitor . . . . . . . . . . . 9 83 2.3.2. Authorization Problems Summary . . . . . . . . . . . 10 84 2.4. Building Automation . . . . . . . . . . . . . . . . . . . 11 85 2.4.1. Device Lifecycle . . . . . . . . . . . . . . . . . . 11 86 2.4.2. Authorization Problems Summary . . . . . . . . . . . 13 87 2.5. Smart Metering . . . . . . . . . . . . . . . . . . . . . 14 88 2.5.1. Drive-by metering . . . . . . . . . . . . . . . . . . 14 89 2.5.2. Meshed Topology . . . . . . . . . . . . . . . . . . . 15 90 2.5.3. Advanced Metering Infrastructure . . . . . . . . . . 15 91 2.5.4. Authorization Problems Summary . . . . . . . . . . . 16 92 2.6. Sports and Entertainment . . . . . . . . . . . . . . . . 16 93 2.6.1. Dynamically Connecting Smart Sports Equipment . . . . 17 94 2.6.2. Authorization Problems Summary . . . . . . . . . . . 17 95 2.7. Industrial Control Systems . . . . . . . . . . . . . . . 18 96 2.7.1. Oil Platform Control . . . . . . . . . . . . . . . . 18 97 2.7.2. Authorization Problems Summary . . . . . . . . . . . 19 98 3. Security Considerations . . . . . . . . . . . . . . . . . . . 19 99 3.1. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 3.2. Configuration of Access Permissions . . . . . . . . . . . 20 101 3.3. Design Considerations for Authorization Solutions . . . . 21 102 3.4. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 104 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 105 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 106 7. Informative References . . . . . . . . . . . . . . . . . . . 23 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. 128 Note that this document does not aim at collecting all possible use 129 cases. 131 We assume that the communication between the devices is based on the 132 Representational State Transfer (REST) architectural style, i.e. a 133 device acts as a server that offers resources such as sensor data and 134 actuators. The resources can be accessed by clients, sometimes 135 without human intervention (M2M). In some situations the 136 communication will happen through intermediaries (e.g. gateways, 137 proxies). 139 Where specific detail is necessary it is assumed that the devices 140 communicate using CoAP [RFC7252], although most conclusions are 141 generic. 143 1.1. Terminology 145 Readers are required to be familiar with the terms defined in 146 [RFC7228]. In addition, this document uses the following 147 terminology: 149 2. Use Cases 151 This section lists use cases involving constrained devices with 152 certain authorization problems to be solved. Each use case first 153 presents a general description of the application area, then one or 154 more specific use cases, and finally a summary of the authorization- 155 related problems users need to be solved. 157 There are various reasons for assigning a function (client or server) 158 to a device, e.g. which device initiates the conversation, how do 159 devices find each other, etc. The definition of the function of a 160 device in a certain use case is not in scope of this document. 161 Readers should be aware that there might be reasons for each setting 162 and that endpoints might even have different functions at different 163 times. 165 2.1. Container monitoring 167 The ability of sensors to communicate environmental data wirelessly 168 opens up new application areas. The use of such sensor systems makes 169 it possible to continuously track and transmit specific 170 characteristics such as temperature, humidity and gas content during 171 the transportation and storage of goods. 173 The proper handling of the sensors in this scenario is not easy to 174 accomplish. They have to be associated to the appropriate pallet of 175 the respective container. Moreover, the goods and the corresponding 176 sensors belong to specific customers. 178 During the shipment to their destination the goods often pass stops 179 where they are transloaded to other means of transportation, e.g. 180 from ship transport to road transport. 182 The transportation and storage of perishable goods is especially 183 challenging since they have to be stored at a constant temperature 184 and with proper ventilation. Additionally, it is very important for 185 the vendors to be informed about irregularities in the temperature 186 and ventilation of fruits to avoid the delivery of decomposed fruits 187 to their customers. The need for a constant monitoring of perishable 188 goods has led to projects such as The Intelligent Container 189 (http://www.intelligentcontainer.com). 191 2.1.1. Bananas for Munich 193 A fruit vendor grows bananas in Costa Rica for the German market. It 194 instructs a transport company to deliver the goods via ship to 195 Rotterdam where they are picked up by trucks and transported to a 196 ripening facility. A Munich supermarket chain buys ripened bananas 197 from the fruit vendor and transports them from the ripening facility 198 to the individual markets with their own company trucks. 200 The fruit vendor's quality management wants to assure the quality of 201 their products and thus equips the banana boxes with sensors. The 202 state of the goods is monitored consistently during shipment and 203 ripening and abnormal sensor values are recorded. Additionally, the 204 sensor values are used to control the climate within the cargo 205 containers. The sensors therefore need to communicate with the 206 climate control system. Since a wrong sensor value leads to a wrong 207 temperature and thus to spoiled goods, the integrity of the sensor 208 data must be assured. The banana boxes within a container will in 209 most cases belong to the same owner. Adjacent containers might 210 contain goods and sensors of different owners. 212 The personnel that transloads the goods must be able to locate the 213 goods meant for a specific customer. However the fruit vendor does 214 not want to disclose sensor information pertaining to the condition 215 of the goods to other companies and therefore wants to assure the 216 confidentiality of this data. Thus, the transloading personnel is 217 only allowed to access logistic information. Moreover, the 218 transloading personnel is only allowed to access the data for the 219 time of the transloading. 221 Due to the high water content of the fruits, the propagation of radio 222 waves is hindered, thus often inhibiting direct communication between 223 nodes [Jedermann14]. Instead, messages are forwarded over multiple 224 hops. The sensors in the banana boxes cannot always reach the 225 Internet during the journey. 227 In the ripening facility bananas are stored until they are ready for 228 selling. The banana box sensors are used to control the ventilation 229 system and to monitor the degree of ripeness of the bananas. Ripe 230 bananas need to be identified and sold before they spoil. 232 The supermarket chain gains ownership of the banana boxes when the 233 bananas have ripened and are ready to leave the ripening facility. 235 2.1.2. Authorization Problems Summary 237 o U1.1 Fruit vendors, transloading personnel and container owners 238 want to grant different authorizations for their resources and/or 239 endpoints to different parties. 241 o U1.2 The fruit vendor requires the integrity of the sensor data 242 that pertains the state of the goods for climate control and to 243 ensure the quality of the monitored recordings. 245 o U1.3 The container owner requires the integrity of the sensor data 246 that is used for climate control. 248 o U1.4 The fruit vendor requires the confidentiality of the sensor 249 data that pertains the state of the goods. 251 o U1.5 The fruit vendor may have several types of data that may be 252 controlled by the same endpoint, e.g., sensor data and the data 253 used for logistics. 255 o U1.6 The fruit vendor requires the confidentiality of the data 256 that is used to locate the goods. 258 o U1.7 The fruit vendor requires the integrity of the data that is 259 used to locate the goods. 261 o U1.8 The transloading personnel requires the integrity of the data 262 that is used to locate the goods. 264 o U1.9 The container owner and the fruit vendor may not be present 265 at the time of access and cannot manually intervene in the 266 authorization process. 268 o U1.10 The fruit vendor, container owner and transloading company 269 want to grant temporary access permissions to a party. 271 o U1.11 Messages between client and resource server might need to be 272 forwarded over multiple hops. 274 o U1.12 The constrained devices might not always be able to reach 275 the Internet. 277 2.2. Home Automation 279 Automation of the home has the potential to become a big future 280 market for the Internet of Things. A home automation system connects 281 devices in a house to the Internet and thus makes them accessible and 282 manageable remotely. Such devices might control for example heating, 283 ventilation, lighting, home entertainment or home security. 285 Such a system needs to accommodate a number of regular users 286 (inhabitants, close friends, cleaning personnel) as well as a 287 heterogeneous group of dynamically varying users (visitors, 288 repairmen, delivery men). 290 As the users are not typically trained in security (or even computer 291 use), the configuration must use secure default settings, and the 292 interface must be well adapted to novice users. 294 2.2.1. Controlling the Smart Home Infrastructure 296 Alice and her husband Bob own a flat which is equipped with home 297 automation devices such as HVAC and shutter control, and they have a 298 motion sensor in the corridor which controls the light bulbs there. 300 Alice and Bob can control the shutters and the temperature in each 301 room using either wall-mounted touch panels or an internet connected 302 device (e.g. a smartphone). Since Alice and Bob both have a full- 303 time job, they want to be able to change settings remotely, e.g. turn 304 up the heating on a cold day if they will be home earlier than 305 expected. 307 The couple does not want people in radio range of their devices, e.g. 308 their neighbors, to be able to control them without authorization. 309 Moreover, they don't want burglars to be able to deduce behavioral 310 patterns from eavesdropping on the network. 312 2.2.2. Seamless Authorization 314 Alice buys a new light bulb for the corridor and integrates it into 315 the home network, i.e. makes resources known to other devices in the 316 network. Alice makes sure that the new light bulb and her other 317 devices in the network get to know the authorization policies for the 318 new device. Bob is not at home, but Alice wants him to be able to 319 control the new device with his devices (e.g. his smartphone) without 320 the need for additional administration effort. She provides the 321 necessary configurations for that. 323 2.2.3. Remotely letting in a visitor 325 Alice and Bob have equipped their home with automated connected door- 326 locks and an alarm system at the door and the windows. The couple 327 can control this system remotely. 329 Alice and Bob have invited Alice's parents over for dinner, but are 330 stuck in traffic and cannot arrive in time, while Alice's parents who 331 use the subway will arrive punctually. Alice calls her parents and 332 offers to let them in remotely, so they can make themselves 333 comfortable while waiting. Then Alice sets temporary permissions 334 that allow them to open the door, and shut down the alarm. She wants 335 these permissions to be only valid for the evening since she does not 336 like it if her parents are able to enter the house as they see fit. 338 When Alice's parents arrive at Alice's and Bob's home, they use their 339 smartphone to communicate with the door-lock and alarm system. 341 2.2.4. Authorization Problems Summary 343 o U2.1 A home owner (Alice and Bob in the example above) wants to 344 spontaneously provision authorization means to visitors. 346 o U2.2 A home owner wants to spontaneously change the home's access 347 control policies. 349 o U2.3 A home owner wants to apply different access rights for 350 different users. 352 o U2.4 The home owners want to grant temporary access permissions to 353 a party. 355 o U2.5 The smart home devices need to be able to communicate with 356 different control devices (e.g. wall-mounted touch panels, 357 smartphones, electronic key fobs). 359 o U2.6 The home owner wants to be able to configure authorization 360 policies remotely. 362 o U2.7 Authorized Users want to be able to obtain access with little 363 effort. 365 o U2.8 The owners of the automated home want to prevent unauthorized 366 entities from being able to deduce behavioral profiles from 367 devices in the home network. 369 o U2.9 Usability is particularly important in this scenario since 370 the necessary authorization related tasks in the lifecycle of the 371 device (commissioning, operation, maintenance and decommissioning) 372 likely need to be performed by the home owners who in most cases 373 have little knowledge of security. 375 o U2.10 Home Owners want their devices to seamlessly (and in some 376 cases even unnoticeably) fulfill their purpose. The 377 administration effort needs to be kept at a minimum. 379 2.3. Personal Health Monitoring 381 The use of wearable health monitoring technology is expected to grow 382 strongly, as a multitude of novel devices are developed and marketed. 383 The need for open industry standards to ensure interoperability 384 between products has lead to initiatives such as Continua Alliance 385 (continuaalliance.org) and Personal Connected Health Alliance 386 (pchalliance.org). Personal health devices are typically battery 387 driven, and located physically on the user. They monitor some bodily 388 function, such as e.g. temperature, blood pressure, or pulse. They 389 are connected to the Internet through an intermediary base-station, 390 using wireless technologies. Through this connection they report the 391 monitored data to some entity, which may either be the user herself, 392 or some medical personnel in charge of the user. 394 Medical data has always been considered as very sensitive, and 395 therefore requires good protection against unauthorized disclosure. 396 A frequent, conflicting requirement is the capability for medical 397 personnel to gain emergency access, even if no specific access rights 398 exist. As a result, the importance of secure audit logs increases in 399 such scenarios. 401 Since the users are not typically trained in security (or even 402 computer use), the configuration must use secure default settings, 403 and the interface must be well adapted to novice users. Parts of the 404 system must operate with minimal maintenance. Especially frequent 405 changes of battery are unacceptable. 407 2.3.1. John and the heart rate monitor 409 John has a heart condition, that can result in sudden cardiac 410 arrests. He therefore uses a device called HeartGuard that monitors 411 his heart rate and his position. In case of a cardiac arrest it 412 automatically sends an alarm to an emergency service, transmitting 413 John's current location. This requires the device to be close to a 414 wireless access point, in order to be able to get an Internet 415 connection (e.g. John's smartphone). 417 The device includes some authentication mechanism, in order to 418 prevent other persons who get physical access to it from acting as 419 the owner and messing up the access control and security settings. 421 John can configure additional persons that get notified in an 422 emergency, for example his daughter Jill. Furthermore the device 423 stores data on John's heart rate, which can later be accessed by a 424 physician to assess the condition of John's heart. 426 However John is a privacy conscious person, and is worried that Jill 427 might use HeartGuard to monitor his location while there is no 428 emergency. Furthermore he doesn't want his health insurance to get 429 access to the HeartGuard data, or even to the fact that he is wearing 430 a HeartGuard, since they might refuse to renew his insurance if they 431 decided he was too big a risk for them. 433 Finally John, while being comfortable with modern technology and able 434 to operate it reasonably well, is not trained in computer security. 435 He therefore needs an interface for the configuration of the 436 HeartGuard security that is easy to understand and use. If John does 437 not understand the meaning of a setting, he tends to leave it alone, 438 assuming that the manufacturer has initialized the device to secure 439 settings. 441 NOTE: Monitoring of some state parameter (e.g. an alarm button) and 442 the position of a person also fits well into an elderly care service. 443 This is particularly useful for people suffering from dementia, where 444 the relatives or caregivers need to be notified of the whereabouts of 445 the person under certain conditions. In this case it is not the 446 patient that decides about access. 448 2.3.2. Authorization Problems Summary 450 o U3.1 The wearer of an eHealth device (John in the example above) 451 wants to pre-configure special access rights in the context of an 452 emergency. 454 o U3.2 The wearer of an eHealth device wants to selectively allow 455 different persons or groups access to medical data. 457 o U3.3 The Security measures could affect battery lifetime of the 458 device and changing the battery is very inconvenient. 460 o U3.4 Devices are often used with default access control settings. 462 o U3.5 Wearers of eHealth devices are often not trained in computer 463 use, and especially computer security. 465 o U3.6 Security mechanisms themselves could provide opportunities 466 for denial of service attacks on the device. 468 o U3.7 The device provides a service that can be fatal for the 469 wearer if it fails. Accordingly, the wearer wants a security 470 mechanism to provide a high level of security. 472 2.4. Building Automation 474 Buildings for commercial use such as shopping malls or office 475 buildings nowadays are equipped increasingly with semi-automatic 476 components to enhance the overall living quality and to save energy 477 where possible. This includes for example heating, ventilation and 478 air condition (HVAC) as well as illumination and security systems 479 such as fire alarms. 481 Different areas of these buildings are often exclusively leased to 482 different companies. However they also share some of the common 483 areas of the building. Accordingly, a company must be able to 484 control the light and HVAC system of its own part of the building and 485 must not have access to control rooms that belong to other companies. 487 Some parts of the building automation system such as entrance 488 illumination and fire alarm systems are controlled either by all 489 parties together or by a service company. 491 2.4.1. Device Lifecycle 493 2.4.1.1. Installation and Commissioning 495 A building is hired out to different companies for office space. 496 This building features various automated systems, such as a fire 497 alarm system, which is triggered by several smoke detectors which are 498 spread out across the building. It also has automated HVAC, lighting 499 and physical access control systems. 501 A vacant area of the building has been recently leased to company A. 502 Before moving into its new office, Company A wishes to replace the 503 lighting with a more energy efficient and a better light quality 504 luminaries. They hire an installation and commissioning company C to 505 redo the illumination. Company C is instructed to integrate the new 506 lighting devices, which may be from multiple manufacturers, into the 507 existing lighting infrastructure of the building which includes 508 presence sensors, switches, controllers etc. 510 Company C gets the necessary authorization from the service company 511 to interact with the existing Building and Lighting Management System 512 (BLMS). To prevent disturbance to other occupants of the building, 513 Company C is provided authorization to perform the commissioning only 514 during non-office hours and only to modify configuration on devices 515 belonging to the domain of Company A's space. After installation 516 (wiring) of the new lighting devices, the commissioner adds the 517 devices into the company A's lighting domain. 519 Once the devices are in the correct domain, the commissioner 520 authorizes the interaction rules between the new lighting devices and 521 existing devices like presence sensors. For this, the commissioner 522 creates the authorization rules on the BLMS which define which lights 523 form a group and which sensors/switches/controllers are allowed to 524 control which groups. These authorization rules may be context based 525 like time of the day (office or non-office hours) or location of the 526 handheld lighting controller etc. 528 2.4.1.2. Operational 530 Company A's staff move into the newly furnished office space. Most 531 lighting is controlled by presence sensors which control the lighting 532 of specific group of lights based on the authorization rules in the 533 BLMS. Additionally employees are allowed to manually override the 534 lighting brightness and color in their office by using the switches 535 or handheld controllers. Such changes are allowed only if the 536 authorization rules exist in the BLMS. For example lighting in the 537 corridors may not be manually adjustable. 539 At the end of the day, lighting is dimmed down or switched off if no 540 occupancy is detected even if manually overridden during the day. 542 On a later date company B also moves into the same building, and 543 shares some of the common spaces with company A. On a really hot day 544 James who works for company A turns on the air condition in his 545 office. Lucy who works for company B wants to make tea using an 546 electric kettle. After she turned it on she goes outside to talk to 547 a colleague until the water is boiling. Unfortunately, her kettle 548 has a malfunction which causes overheating and results in a 549 smoldering fire of the kettle's plastic case. 551 Due to the smoke coming from the kettle the fire alarm is triggered. 552 Alarm sirens throughout the building are switched on simultaneously 553 (using a broadcast or multicast) to alert the staff of both 554 companies. Additionally, the ventilation system of the whole 555 building is closed off to prevent the smoke from spreading and to 556 withdraw oxygen from the fire. The smoke cannot get into James' 557 office although he turned on his air condition because the fire alarm 558 overrides the manual setting by sending commands (broadcast or 559 multicast) to switch off all the air conditioning. 561 The fire department is notified of the fire automatically and arrives 562 within a short time. After inspecting the damage and extinguishing 563 the smoldering fire a fire fighter resets the fire alarm because only 564 the fire department is authorized to do that. 566 2.4.1.3. Maintenance 568 Company A's staff are annoyed that the lights switch off too often in 569 their rooms if they work silently in front of their computer. 570 Company A notifies the commissioning Company C about the issue and 571 asks them to increase the delay before lights switch off. 573 Company C again gets the necessary authorization from the service 574 company to interact with the BLMS. The commissioner's tool gets the 575 necessary authorization from BMLS to send a configuration change to 576 all lighting devices in Company A's offices to increase their delay 577 before they switch off. 579 2.4.1.4. Decommissioning 581 Company A has noticed that the handheld controllers are often 582 misplaced and hard to find when needed. So most of the time staff 583 use the existing wall switches for manual control. Company A decides 584 it would be better to completely remove handheld controllers and asks 585 Company C to decommission them from the lighting system. 587 Company C again gets the necessary authorization from the service 588 company to interact with the BLMS. The commissioner now deletes any 589 rules that allowed handheld controllers authorization to control the 590 lighting. Additionally the commissioner instructs the BLMS to push 591 these new rules to prevent cached rules at the end devices from being 592 used. 594 2.4.2. Authorization Problems Summary 596 o U4.1 The building owner and the companies want to be able to add 597 new devices to their administrative domain (commissioning). 599 o U4.2 The building owner and the companies want to be able to 600 integrate a device that formerly belonged to a different 601 administrative domain to their own administrative domain 602 (handover). 604 o U4.3 The building owner and the companies want to be able to 605 remove a device from their administrative domain (decomissioning). 607 o U4.4 The building owner and the companies want to be able to 608 delegate selected administration tasks for their devices to 609 others. 611 o U4.5 The building owner and the companies want to be able to 612 define context-based authorization rules. 614 o U4.6 The building owner and the companies want to be able to 615 revoke granted permissions and delegations. 617 o U4.7 The building owner and the companies want to allow authorized 618 entities to send data to their endpoints (default deny). 620 o U4.8 The building owner and the companies want to be able to 621 authorize a device to control several devices at the same time 622 using a multicast protocol. 624 o U4.9 The companies want to be able to interconnect their own 625 subsystems with those from a different operational domain while 626 keeping the control over the authorizations (e.g. granting and 627 revoking permissions) for their endpoints and devices. 629 2.5. Smart Metering 631 Automated measuring of customer consumption is an established 632 technology for electricity, water, and gas providers. Increasingly 633 these systems also feature networking capability to allow for remote 634 management. Such systems are in use for commercial, industrial and 635 residential customers and require a certain level of security, in 636 order to avoid economic loss to the providers, vulnerability of the 637 distribution system, as well as disruption of services for the 638 customers. 640 The smart metering equipment for gas and water solutions is battery 641 driven and communication should be used sparingly due to battery 642 consumption. Therefore the types of meters sleep most of the time, 643 and only wake up every minute/hour to check for incoming 644 instructions. Furthermore they wake up a few times a day (based on 645 their configuration) to upload their measured metering data. 647 Different networking topologies exist for smart metering solutions. 648 Based on environment, regulatory rules and expected cost, one or a 649 mixture of these topologies may be deployed to collect the metering 650 information. Drive-By metering is one of the most current solutions 651 deployed for collection of gas and water meters. 653 2.5.1. Drive-by metering 655 A service operator offers smart metering infrastructures and related 656 services to various utility companies. Among these is a water 657 provider, who in turn supplies several residential complexes in a 658 city. The smart meters are installed in the end customer's homes to 659 measure water consumption and thus generate billing data for the 660 utility company. The meters do so by sending data to a base station. 661 Several base stations are installed around the city to collect the 662 metering data. However in the denser urban areas, the base stations 663 would have to be installed very close to the meters. This would 664 require a high number of base stations and expose this more expensive 665 equipment to manipulation or sabotage. The service operator has 666 therefore chosen another approach, which is to drive around with a 667 mobile base-station and let the meters connect to that in regular 668 intervals in order to gather metering data. 670 2.5.2. Meshed Topology 672 In another deployment, the water meters are installed in a building 673 that already has power meters installed, the latter are mains 674 powered, and are therefore not subject to the same power saving 675 restrictions. The water meters can therefore use the power meters as 676 proxies, in order to achieve better connectivity. This requires the 677 security measures on the water meters to work through intermediaries. 679 2.5.3. Advanced Metering Infrastructure 681 A utility company is updating its old utility distribution network 682 with advanced meters and new communication systems, known as an 683 Advanced Metering Infrastructure (AMI). AMI refers to a system that 684 measures, collects and analyzes usage, and interacts with metering 685 devices such as electricity meters, gas meters, heat meters, and 686 water meters, through various communication media either on request 687 (on-demand) or on pre-defined schedules. Based on this technology, 688 new services make it possible for consumers to control their utility 689 consumption and reduce costs by supporting new tariff models from 690 utility companies, and more accurate and timely billing. 692 The technical solution is based on levels of data aggregation between 693 smart meters located at the consumer premises and the Meter Data 694 Management (MDM) system located at the utility company. Two possible 695 intermediate levels are: 697 o Head-End System (HES) which is hardware and software that receives 698 the stream of meter data and exposes an interface to the MDM. 700 o Data Collection (DC) units located in a local network 701 communicating with a number of smart meters and with a backhaul 702 interface communicating with the HES, e.g. using cellular 703 communication. 705 For reasons of efficiency and cost end-to-end connectivity is not 706 always feasible, so metering data is stored in batches in DC for some 707 time before being forwarded to the HES, and in turn accessed by the 708 MDM. The HES and the DC units may be operated by a third party 709 service operator on behalf of the utility company. One 710 responsibility of the service operator is to make sure that meter 711 readings are performed and delivered to the HES. An example of a 712 Service Level Agreement between the service operator and the utility 713 company is e.g. "at least 95 % of the meters have readings recorded 714 during the last 72 hours". 716 2.5.4. Authorization Problems Summary 718 o U5.1 Devices are installed in hostile environments where they are 719 physically accessible by attackers. The service operator and the 720 utility company want to make sure that an attacker cannot use a 721 captured device to attack other parts of their infrastructure. 723 o U5.2 The utility company wants to restrict which entities are 724 allowed to send data to their endpoints and to ensure the 725 integrity of the data on their endpoints. 727 o U5.3 The utility company wants to control which entities are 728 allowed to read data on their endpoints and protect such data in 729 transfer. 731 o U5.4 The devices may have intermittent Internet connectivity. 733 o U5.5 Neither the service operator nor the utility company are 734 always present at the time of access and cannot manually intervene 735 in the authorization process. 737 o U5.6 When authorization policies are updated it is impossible, or 738 at least very inefficient to contact all affected endpoints 739 directly. 741 o U5.7 Messages between endpoints may need to be stored and 742 forwarded over multiple nodes. 744 2.6. Sports and Entertainment 746 In the area of leisure time activities, applications can benefit from 747 the small size and weight of constrained devices. Sensors and 748 actuators with various functionalities can be integrated into fitness 749 equipment, games and even clothes. Users can carry their devices 750 around with them at all times. 752 Usability is especially important in this area since users will often 753 want to spontaneously interconnect their devices with others. 754 Therefore the configuration of access permissions must be simple and 755 fast and not require much effort at the time of access (preferably 756 none at all). 758 The required level of security will in most cases be low since 759 security breaches will likely have less severe consequences. The 760 continuous monitoring of data might however enable an attacker to 761 create behavioral or movement profiles. Moreover, the aggregation of 762 data can seriously increase the impact on the privacy of the users. 764 2.6.1. Dynamically Connecting Smart Sports Equipment 766 Jody is a an enthusiastic runner. To keep track of her training 767 progress, she has smart running shoes that measure the pressure at 768 various points beneath her feet to count her steps, detect 769 irregularities in her stride and help her to improve her posture and 770 running style. On a sunny afternoon, she goes to the Finnbahn track 771 near her home to work out. She meets her friend Lynn who shows her 772 the smart fitness watch she bought a few days ago. The watch can 773 measure the wearer's pulse, show speed and distance, and keep track 774 of the configured training program. The girls detect that the watch 775 can be connected with Jody's shoes and then can additionally display 776 the information the shoes provide. 778 Jody asks Lynn to let her try the watch and lend it to her for the 779 afternoon. Lynn agrees but doesn't want Jody to access her training 780 plan. She configures the access policies for the watch so that 781 Jody's shoes are allowed to access the display and measuring features 782 but cannot read or add training data. Jody's shoes connect to Lynn's 783 watch after only a press of a button because Jody already configured 784 access rights for devices that belong to Lynn a while ago. 786 After an hour, Jody gives the watch back and both girls terminate the 787 connection between their devices. 789 2.6.2. Authorization Problems Summary 791 o U6.1 Sports equipment owners want to be able to grant access 792 rights dynamically when needed. 794 o U6.2 Sports equipment owners want the configuration of access 795 rights to work with very little effort. 797 o U6.3 Sports equipment owners want to be able to preconfigure 798 access policies that grant certain access permissions to endpoints 799 with certain attributes (e.g. endpoints of a certain user) without 800 additional configuration effort at the time of access. 802 o U6.4 Sports equipment owners to protect the confidentiality of 803 their data for privacy reasons. 805 o U6.5 Devices might not have an Internet connection at the time of 806 access. 808 2.7. Industrial Control Systems 810 Industrial control systems (ICS) and especially supervisory control 811 and data acquisition systems (SCADA) use a multitude of sensors and 812 actuators in order to monitor and control industrial processes in the 813 physical world. Example processes include manufacturing, power 814 generation, and refining of raw materials. 816 Since the advent of the Stuxnet worm it has become obvious to the 817 general public how vulnerable this kind of systems are, especially 818 when connected to the Internet. The severity of these 819 vulnerabilities are exacerbated by the fact that many ICS are used to 820 control critical public infrastructure, such as power, water 821 treatment of traffic control. Nevertheless the economical advantages 822 of connecting such systems to the Internet can be significant if 823 appropriate security measures are put in place. 825 2.7.1. Oil Platform Control 827 An oil platform uses an industrial control system to monitor data and 828 control equipment. The purpose of this system is to gather and 829 process data from a large number of sensors, and control actuators 830 such as valves and switches to steer the oil extraction process on 831 the platform. Raw data, alarms, reports and other information are 832 also available to the operators, who can intervene with manual 833 commands. Many of the sensors are connected to the controlling units 834 by direct wire, but the operator is slowly replacing these units by 835 wireless ones, since this makes maintenance easier. 837 The controlling units are connected to the Internet, to allow for 838 remote administration, since it is expensive and inconvenient to fly 839 in a technician to the platform. 841 The main interest of the operator is to ensure the integrity of 842 control messages and sensor readings. Access in some cases needs to 843 be restricted, e.g. the operator wants wireless actuators only to 844 accept commands by authorized control units. 846 The owner of the platform also wants to collect auditing information 847 for liability reasons. 849 2.7.2. Authorization Problems Summary 851 o U7.1 The operator of the platform wants to ensure the 852 confidentiality of sensor data and the integrity of actuator data. 854 o U7.2 The operator wants to ensure that data coming from sensors 855 and commands sent to actuators are authentic. 857 o U7.3 Some devices do not have direct Internet connection. 859 o U7.4 Some devices have wired connection while others use wireless. 861 o U7.5 The execution of unauthorized commands in an ICS can lead to 862 significant financial damage, and threaten the availability of 863 critical infrastructure services. Accordingly, the operator wants 864 a security solution that provides a very high level of security. 866 3. Security Considerations 868 As the use cases listed in this document demonstrate, constrained 869 devices are used in various application areas. The appeal of these 870 devices is that they are small and inexpensive. That makes it easy 871 to integrate them into many aspects of everyday life. Therefore, the 872 devices will be entrusted with vast amounts of valuable data or even 873 control functions, that need to be protected from unauthorized 874 access. Moreover, the aggregation of data must be considered: 875 attackers might not only collect data from a single device but from 876 many devices, thus increasing the potential damage. 878 Not only the data on the constrained devices themselves is 879 threatened, the devices might also be abused as an intrusion point to 880 infiltrate a network. Once an attacker gained control over the 881 device, it can be used to attack other devices as well. Due to their 882 limited capabilities, constrained devices appear as the weakest link 883 in the network and hence pose an attractive target for attackers. 885 This section summarizes the security problems highlighted by the use 886 cases above and provides guidelines for the design of protocols for 887 authentication and authorization in constrained RESTful environments. 889 3.1. Attacks 891 This document lists security problems that users of constrained 892 devices want to solve. Further analysis of attack scenarios is not 893 in scope of the document. However, there are attacks that must be 894 considered by solution developers. 896 Because of the expected large number of devices and their ubiquity, 897 constrained devices increase the danger from Pervasive Monitoring 898 [RFC7258] attacks. 900 As some of the use cases indicate, constrained devices may be 901 installed in hostile environments where they are physically 902 accessible (see Section 2.5). Protection from physical attacks is 903 not in the scope of ACE, but should be kept in mind by developers of 904 authorization solutions. 906 Denial of service (DoS) attacks threaten the availability of services 907 a device provides. E.g., an attacker can induce a device to perform 908 steps of a heavy weight security protocol (e.g. Datagram Transport 909 Layer Security (DTLS) [RFC6347]) before authentication and 910 authorization can be verified, thus exhausting the device's system 911 resources. This leads to a temporary or - e.g. if the batteries are 912 drained - permanent failure of the service. For some services of 913 constrained devices, availability is especially important (see 914 Section 2.3). Because of their limitations, constrained devices are 915 especially vulnerable to denial of service attacks. Solution 916 designers must be particularly careful to consider these limitations 917 in every part of the protocol. This includes: 919 o Battery usage 921 o Number of message exchanges required by security measures 923 o Size of data that is transmitted (e.g. authentication and access 924 control data) 926 o Size of code required to run the protocol 928 o Size of RAM memory and stack required to run the protocol 930 Another category of attacks that needs to be considered by solution 931 developers is session interception and hijacking. 933 3.2. Configuration of Access Permissions 935 o The access control policies need to be enforced (all use cases): 936 The information that is needed to implement the access control 937 policies needs to be provided to the device that enforces the 938 authorization and applied to every incoming request. 940 o A single resource might have different access rights for different 941 requesting entities (all use cases). 943 Rationale: In some cases different types of users need different 944 access rights, as opposed to a binary approach where the same 945 access permissions are granted to all authenticated users. 947 o A device might host several resources where each resource has its 948 own access control policy (all use cases). 950 o The device that makes the policy decisions should be able to 951 evaluate context-based permissions such as location or time of 952 access (see e.g. Section 2.2, Section 2.3, Section 2.4). Access 953 may depend on local conditions, e.g. access to health data in an 954 emergency. The device that makes the policy decisions should be 955 able to take such conditions into account. 957 3.3. Design Considerations for Authorization Solutions 959 o Devices need to be enabled to enforce authorization policies 960 without human intervention at the time of the access request (see 961 e.g. Section 2.1, Section 2.2, Section 2.4, Section 2.5). 963 o Authorization solutions need to consider that constrained devices 964 might not have internet access at the time of the access request 965 (see e.g. Section 2.1, Section 2.3, Section 2.5, Section 2.6). 967 o It should be possible to update access control policies without 968 manually re-provisioning individual devices (see e.g. 969 Section 2.2, Section 2.3, Section 2.5, Section 2.6). 971 Rationale: Peers can change rapidly which makes manual re- 972 provisioning unreasonably expensive. 974 o Authorization policies may be defined to apply to a large number 975 of devices that might only have intermittent connectivity. 976 Distributing policy updates to every device for every update might 977 not be a feasible solution (see e.g. Section 2.5). 979 o It must be possible to dynamically revoke authorizations (see e.g. 980 Section 2.4). 982 o The authentication and access control protocol can put undue 983 burden on the constrained system resources of a device 984 participating in the protocol. An authorization solutions must 985 take the limitations of the constrained devices into account (all 986 use cases, see also Section 3.1). 988 o Secure default settings are needed for the initial state of the 989 authentication and authorization protocols (all use cases). 991 Rationale: Many attacks exploit insecure default settings, and 992 experience shows that default settings are frequently left 993 unchanged by the end users. 995 o Access to resources on other devices should only be permitted if a 996 rule exists that explicitly allows this access (default deny) (see 997 e.g. Section 2.4). 999 o Usability is important for all use cases. The configuration of 1000 authorization policies as well as the gaining access to devices 1001 must be simple for the users of the devices. Special care needs 1002 to be taken for home scenarios where access control policies have 1003 to be configured by users that are typically not trained in 1004 security (see Section 2.2, Section 2.3, Section 2.6). 1006 3.4. Proxies 1008 In some cases, the traffic between endpoints might go through 1009 intermediary nodes (e.g. proxies, gateways). This might affect the 1010 function or the security model of authentication and access control 1011 protocols e.g. end-to-end security between endpoints with DTLS might 1012 not be possible (see Section 2.5). 1014 4. Privacy Considerations 1016 Many of the devices that are in focus of this document register data 1017 from the physical world (sensors) or affect processes in the physical 1018 world (actuators), which may involve data or processes belonging to 1019 individuals. To make matters worse the sensor data may be recorded 1020 continuously thus allowing to gather significant information about an 1021 individual subject through the sensor readings. Therefore privacy 1022 protection is especially important, and Authentication and Access 1023 control are important tools for this, since they make it possible to 1024 control who gets access to private data. 1026 Privacy protection can also be weighted in when evaluating the need 1027 for end-to-end confidentiality, since otherwise intermediary nodes 1028 will learn the content of potentially sensitive messages sent between 1029 endpoints and thereby threaten the privacy of the individual that may 1030 be subject of this data. 1032 In some cases, even the possession of a certain type of device can be 1033 confidential, e.g. individuals might not want to others to know that 1034 they are wearing a certain medical device (see Section 2.3). 1036 The personal health monitoring use case (see Section 2.3) indicates 1037 the need for secure audit logs which impose specific requirements on 1038 a solution. Auditing is not in the scope of ACE. However, if an 1039 authorization solution provides means for audit logs, it must 1040 consider the impact of logged data for the privacy of all parties 1041 involved. Suitable measures for protecting and purging the logs must 1042 be taken during operation, maintenance and decommissioning of the 1043 device. 1045 5. Acknowledgments 1047 The authors would like to thank Olaf Bergmann, Sumit Singhal, John 1048 Mattson, Mohit Sethi, Carsten Bormann, Martin Murillo, Corinna 1049 Schmitt, Hannes Tschofenig, Erik Wahlstroem, and Andreas Backman for 1050 reviewing and/or contributing to the document. Also, thanks to 1051 Markus Becker, Thomas Poetsch and Koojana Kuladinithi for their input 1052 on the container monitoring use case. 1054 Ludwig Seitz and Goeran Selander worked on this document as part of 1055 EIT-ICT Labs activity PST-14056. 1057 6. IANA Considerations 1059 This document has no IANA actions. 1061 7. Informative References 1063 [Jedermann14] 1064 Jedermann, R., Poetsch, T., and C. LLoyd, "Communication 1065 techniques and challenges for wireless food quality 1066 monitoring", Philosophical Transactions of the Royal 1067 Society A Mathematical, Physical and Engineering Sciences, 1068 May 2014. 1070 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1071 Security Version 1.2", RFC 6347, January 2012. 1073 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1074 Constrained-Node Networks", RFC 7228, May 2014. 1076 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1077 Application Protocol (CoAP)", RFC 7252, June 2014. 1079 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1080 Attack", BCP 188, RFC 7258, May 2014. 1082 Authors' Addresses 1083 Ludwig Seitz (editor) 1084 SICS Swedish ICT AB 1085 Scheelevaegen 17 1086 Lund 223 70 1087 Sweden 1089 Email: ludwig@sics.se 1091 Stefanie Gerdes (editor) 1092 Universitaet Bremen TZI 1093 Postfach 330440 1094 Bremen 28359 1095 Germany 1097 Phone: +49-421-218-63906 1098 Email: gerdes@tzi.org 1100 Goeran Selander 1101 Ericsson 1102 Faroegatan 6 1103 Kista 164 80 1104 Sweden 1106 Email: goran.selander@ericsson.com 1108 Mehdi Mani 1109 Itron 1110 52, rue Camille Desmoulins 1111 Issy-les-Moulineaux 92130 1112 France 1114 Email: Mehdi.Mani@itron.com 1116 Sandeep S. Kumar 1117 Philips Research 1118 High Tech Campus 1119 Eindhoven 5656 AA 1120 The Netherlands 1122 Email: sandeep.kumar@philips.com