idnits 2.17.00 (12 Aug 2021) /tmp/idnits42071/draft-ietf-ace-usecases-10.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 (October 23, 2015) is 2395 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: April 25, 2016 Universitaet Bremen TZI 6 G. Selander 7 Ericsson 8 M. Mani 9 Itron 10 S. Kumar 11 Philips Research 12 October 23, 2015 14 Use Cases for Authentication and Authorization in Constrained 15 Environments 16 draft-ietf-ace-usecases-10 18 Abstract 20 Constrained devices are nodes with limited processing power, storage 21 space and transmission capacities. These devices in many cases do 22 not provide user interfaces and are often intended to interact 23 without human intervention. 25 This document includes a collection of representative use cases for 26 authentication and authorization in constrained environments. These 27 use cases aim at identifying authorization problems that arise during 28 the lifecycle of a constrained device and are intended to provide a 29 guideline for developing a comprehensive authentication and 30 authorization solution for this class of 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 April 25, 2016. 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 . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . 8 80 2.2.4. Selling the house . . . . . . . . . . . . . . . . . . 8 81 2.2.5. Authorization Problems Summary . . . . . . . . . . . 8 82 2.3. Personal Health Monitoring . . . . . . . . . . . . . . . 9 83 2.3.1. John and the heart rate monitor . . . . . . . . . . . 10 84 2.3.2. Authorization Problems Summary . . . . . . . . . . . 11 85 2.4. Building Automation . . . . . . . . . . . . . . . . . . . 12 86 2.4.1. Device Lifecycle . . . . . . . . . . . . . . . . . . 12 87 2.4.2. Public Safety . . . . . . . . . . . . . . . . . . . . 16 88 2.4.3. Authorization Problems Summary . . . . . . . . . . . 16 89 2.5. Smart Metering . . . . . . . . . . . . . . . . . . . . . 18 90 2.5.1. Drive-by metering . . . . . . . . . . . . . . . . . . 18 91 2.5.2. Meshed Topology . . . . . . . . . . . . . . . . . . . 19 92 2.5.3. Advanced Metering Infrastructure . . . . . . . . . . 19 93 2.5.4. Authorization Problems Summary . . . . . . . . . . . 19 95 2.6. Sports and Entertainment . . . . . . . . . . . . . . . . 20 96 2.6.1. Dynamically Connecting Smart Sports Equipment . . . . 21 97 2.6.2. Authorization Problems Summary . . . . . . . . . . . 21 98 2.7. Industrial Control Systems . . . . . . . . . . . . . . . 22 99 2.7.1. Oil Platform Control . . . . . . . . . . . . . . . . 22 100 2.7.2. Authorization Problems Summary . . . . . . . . . . . 23 101 3. Security Considerations . . . . . . . . . . . . . . . . . . . 23 102 3.1. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 3.2. Configuration of Access Permissions . . . . . . . . . . . 25 104 3.3. Authorization Considerations . . . . . . . . . . . . . . 25 105 3.4. Proxies . . . . . . . . . . . . . . . . . . . . . . . . . 26 106 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 107 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 108 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 109 7. Informative References . . . . . . . . . . . . . . . . . . . 27 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 112 1. Introduction 114 Constrained devices [RFC7228] are nodes with limited processing 115 power, storage space and transmission capacities. These devices are 116 often battery-powered and in many cases do not provide user 117 interfaces. 119 Constrained devices benefit from being interconnected using Internet 120 protocols. However, deploying common security protocols can 121 sometimes be difficult because of device or network limitations. 122 Regardless, adequate security mechanisms are required to protect 123 these constrained devices, which are expected to be integrated in all 124 aspects of everyday life, from attackers wishing to gain control over 125 the device's data or functions. 127 This document comprises a collection of representative use cases for 128 the application of authentication and authorization in constrained 129 environments. These use cases aim at identifying authorization 130 problems that arise during the lifecycle of a constrained device. 131 Note that this document does not aim at collecting all possible use 132 cases. 134 We assume that the communication between the devices is based on the 135 Representational State Transfer (REST) architectural style, i.e. a 136 device acts as a server that offers resources such as sensor data and 137 actuators. The resources can be accessed by clients, sometimes 138 without human intervention (M2M). In some situations the 139 communication will happen through intermediaries (e.g. gateways, 140 proxies). 142 Where specific detail is necessary it is assumed that the devices 143 communicate using CoAP [RFC7252], although most conclusions are 144 generic. 146 1.1. Terminology 148 Readers are required to be familiar with the terms defined in 149 [RFC7228]. 151 2. Use Cases 153 This section includes the use cases; each use case first presents a 154 general description of the application environment, than one or more 155 specific use cases, and finally a summary of the authorization- 156 related problems to be solved. The document aims at listing the 157 relevant authorization problems and not to provide an exhaustive 158 list. It might not be possible to address all of the listed problems 159 with a single solution; There might be conflicting goals within or 160 among some requirements. 162 There are various reasons for assigning a function (client or server) 163 to a device, e.g. which device initiates the conversation, how do 164 devices find each other, etc. The definition of the function of a 165 device in a certain use case is not in scope of this document. 166 Readers should be aware that there might be reasons for each setting 167 and that endpoints might even have different functions at different 168 times. 170 2.1. Container monitoring 172 The ability of sensors to communicate environmental data wirelessly 173 opens up new application areas. Sensor systems make it possible to 174 continuously track and transmit characteristics such as temperature, 175 humidity and gas content while goods are transported and stored. 177 Sensors in this scenario have to be associated to the appropriate 178 pallet of the respective container. Sensors as well as the goods 179 belong to specific customers. 181 While in transit goods often pass stops where they are transloaded to 182 other means of transportation, e.g. from ship transport to road 183 transport. 185 Perishable goods need to be stored at constant temperature and with 186 proper ventilation. Real-time information on the state of the goods 187 is needed by both the transporter and the vendor. Transporters want 188 to prioritize good that will expire soon. Vendors want to react when 189 goods are spoiled to continue to fulfill delivery obligations. 191 The Intelligent Container (http://www.intelligentcontainer.com) is an 192 example project that explores solutions to continuously monitor 193 perishable goods. 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 from the ripening facility 202 to the individual markets with their own company 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 (U1.2). 208 Additionally, the sensor values are used to control the climate 209 within the cargo containers (U1.1, U1.5, U1.7). The sensors 210 therefore need to communicate with the climate control system. Since 211 a wrong sensor value leads to a wrong temperature and thus to spoiled 212 goods, the integrity of the sensor data must be assured (U1.2, U1.3). 213 The banana boxes within a container will in most cases belong to the 214 same owner. Adjacent containers might contain goods and sensors of 215 different owners (U1.1). 217 The personnel that transloads the goods must be able to locate the 218 goods meant for a specific customer (U1.1, U1.6, U1.7). However the 219 fruit vendor does not want to disclose sensor information pertaining 220 to the condition of the goods to other companies and therefore wants 221 to assure the confidentiality of this data (U1.4). Thus, the 222 transloading personnel is only allowed to access logistic information 223 (U1.1). Moreover, the transloading personnel is only allowed to 224 access the data for the time of the transloading (U1.8). 226 Due to the high water content of the fruits, the propagation of radio 227 waves is hindered, thus often inhibiting direct communication between 228 nodes [Jedermann14]. Instead, messages are forwarded over multiple 229 hops (U1.9). The sensors in the banana boxes cannot always reach the 230 Internet during the journey (U1.10). Sensors may need to use relay 231 stations owned by the transport company to connect to endpoints in 232 the Internet. 234 In the ripening facility bananas are stored until they are ready to 235 be sold. The banana box sensors are used to control the ventilation 236 system and to monitor the degree of ripeness of the bananas. Ripe 237 bananas need to be identified and sold before they spoil (U1.2, 238 U1.8). 240 The supermarket chain gains ownership of the banana boxes when the 241 bananas have ripened and are ready to leave the ripening facility. 243 2.1.2. Authorization Problems Summary 245 o U1.1 Fruit vendors and container owners want to grant different 246 authorizations for their resources and/or endpoints to different 247 parties. 249 o U1.2 The fruit vendor requires the integrity and authenticity of 250 the sensor data that pertains the state of the goods for climate 251 control and to ensure the quality of the monitored recordings. 253 o U1.3 The container owner requires the integrity and authenticity 254 of the sensor data that is used for climate control. 256 o U1.4 The fruit vendor requires the confidentiality of the sensor 257 data that pertains the state of the goods and the confidentiality 258 of location data, e.g., to protect them from targeted attacks from 259 competitors. 261 o U1.5 The fruit vendor may need different protection for several 262 different types of data on the same endpoint, e.g., sensor data 263 and the data used for logistics. 265 o U1.6 The fruit vendor and the transloading personnel require the 266 authenticity and integrity of the data that is used to locate the 267 goods, in order to ensure that the goods are correctly treated and 268 delivered. 270 o U1.7 The container owner and the fruit vendor may not be present 271 at the time of access and cannot manually intervene in the 272 authorization process. 274 o U1.8 The fruit vendor, container owner and transloading company 275 want to grant temporary access permissions to a party, in order to 276 avoid giving permanent access to parties that are no longer 277 involved in processing the bananas. 279 o U1.9 The fruit vendor, container owner and transloading company 280 want their security objectives to be achieved, even if the 281 messages between the endpoints need to be forwarded over multiple 282 hops. 284 o U1.10 The constrained devices might not always be able to reach 285 the Internet but still need to enact the authorization policies of 286 their principals. 288 o U1.11 Fruit vendors and container owners want to be able to revoke 289 authorization on a malfunctioning sensor. 291 2.2. Home Automation 293 One application of the Internet of Things is home automation systems. 294 Such a system can connect household devices that control, for example 295 heating, ventilation, lighting, home entertainment, and home security 296 to the Internet making them remotely accessible and manageable. 298 Such a system needs to accommodate a number of regular users 299 (inhabitants, close friends, cleaning personnel) as well as a 300 heterogeneous group of dynamically varying users (visitors, 301 repairmen, delivery men). 303 As the users are not typically trained in security (or even computer 304 use), the configuration must use secure default settings, and the 305 interface must be well adapted to novice users. 307 2.2.1. Controlling the Smart Home Infrastructure 309 Alice and Bob own a flat which is equipped with home automation 310 devices such as HVAC and shutter control, and they have a motion 311 sensor in the corridor which controls the light bulbs there (U2.5). 313 Alice and Bob can control the shutters and the temperature in each 314 room using either wall-mounted touch panels or an internet connected 315 device (e.g. a smartphone). Since Alice and Bob both have a full- 316 time job, they want to be able to change settings remotely, e.g. turn 317 up the heating on a cold day if they will be home earlier than 318 expected (U2.5). 320 The couple does not want people in radio range of their devices, e.g. 321 their neighbors, to be able to control them without authorization. 322 Moreover, they don't want burglars to be able to deduce behavioral 323 patterns from eavesdropping on the network (U2.8). 325 2.2.2. Seamless Authorization 327 Alice buys a new light bulb for the corridor and integrates it into 328 the home network, i.e. makes resources known to other devices in the 329 network. Alice makes sure that the new light bulb and her other 330 devices in the network get to know the authorization policies for the 331 new device. Bob is not at home, but Alice wants him to be able to 332 control the new device with his devices (e.g. his smartphone) without 333 the need for additional administration effort (U2.7). She provides 334 the necessary configurations for that (U2.9, U2.10). 336 2.2.3. Remotely letting in a visitor 338 Alice and Bob have equipped their home with automated connected door- 339 locks and an alarm system at the door and the windows. The couple 340 can control this system remotely. 342 Alice and Bob have invited Alice's parents over for dinner, but are 343 stuck in traffic and cannot arrive in time, while Alice's parents who 344 use the subway will arrive punctually. Alice calls her parents and 345 offers to let them in remotely, so they can make themselves 346 comfortable while waiting (U2.1, U2.6). Then Alice sets temporary 347 permissions that allow them to open the door, and shut down the alarm 348 (U2.2). She wants these permissions to be only valid for the evening 349 since she does not like it if her parents are able to enter the house 350 as they see fit (U2.3, U2.4). 352 When Alice's parents arrive at Alice's and Bob's home, they use their 353 smartphone to communicate with the door-lock and alarm system (U2.5, 354 U2.9). The permissions Alice issued to her parents only allow 355 limited access to the house (e.g. opening the door, turning on the 356 lights). Certain other functions, such as checking the footage from 357 the surveillance cameras is not accessible to them (U2.3). 359 Alice and Bob also issue similarly restricted permissions to e.g. 360 cleaners, repairmen or their nanny (U2.3). 362 2.2.4. Selling the house 364 Alice and Bob have to move because Alice is starting a new job. They 365 therefore decide to sell the house, and transfer control of all 366 automated services to the new owners (U2.11). Before doing that they 367 want to erase privacy relevant data from the logs of the automated 368 systems, while the new owner is interested to keep some historic data 369 e.g. pertaining to the behavior of the heating system (U2.12). At 370 the time of transfer of the house, the new owners also wants make 371 sure that permissions issued by the previous owners to access the 372 house or connected devices (in the case where device management may 373 have separate permissions from house access) are no longer valid 374 (U2.13). 376 2.2.5. Authorization Problems Summary 378 o U2.1 A home owner (Alice and Bob in the example above) wants to 379 spontaneously provision authorization means to visitors. 381 o U2.2 A home owner wants to spontaneously change the home's access 382 control policies. 384 o U2.3 A home owner wants to apply different access rights for 385 different users (including other inhabitants). 387 o U2.4 The home owners want to grant access permissions to a someone 388 during a specified time frame. 390 o U2.5 The smart home devices need to be able to securely 391 communicate with different control devices (e.g. wall-mounted 392 touch panels, smartphones, electronic key fobs, device gateways). 394 o U2.6 The home owner wants to be able to configure authorization 395 policies remotely. 397 o U2.7 Authorized Users want to be able to obtain access with little 398 effort. 400 o U2.8 The owners of the automated home want to prevent unauthorized 401 entities from being able to deduce behavioral profiles from 402 devices in the home network. 404 o U2.9 Usability is particularly important in this scenario since 405 the necessary authorization related tasks in the lifecycle of the 406 device (commissioning, operation, maintenance and decommissioning) 407 likely need to be performed by the home owners who in most cases 408 have little knowledge of security. 410 o U2.10 Home Owners want their devices to seamlessly (and in some 411 cases even unnoticeably) fulfill their purpose. Therefore the 412 authorization administration effort needs to be kept at a minimum. 414 o U2.11 Home Owners want to be able to transfer ownership of their 415 automated systems when they sell the house. 417 o U2.12 Home Owners want to be able to sanitize the logs of the 418 automated systems, when transferring ownership, without deleting 419 important operational data. 421 o U2.13 When a transfer of ownership occurs, the new owner wants to 422 make sure that access rights created by the previous owner are no 423 longer valid. 425 2.3. Personal Health Monitoring 427 Personal health monitoring devices, i.e. eHealth devices, are 428 typically battery driven and located physically on or in the user to 429 monitor some bodily function, such as temperature, blood pressure, or 430 pulse rate. These devices typically connect to the Internet through 431 an intermediary base-station, using wireless technologies and through 432 this connection they report the monitored data to some entity, which 433 may either be the user, or a medical caregiver. 435 Medical data has always been considered as very sensitive, and 436 therefore requires good protection against unauthorized disclosure. 437 A frequent, conflicting requirement is the capability for medical 438 personnel to gain emergency access, even if no specific access rights 439 exist. As a result, the importance of secure audit logs increases in 440 such scenarios. 442 Since the users are not typically trained in security (or even 443 computer use), the configuration must use secure default settings, 444 and the interface must be well adapted to novice users. Parts of the 445 system must operate with minimal maintenance. Especially frequent 446 changes of battery are unacceptable. 448 There is a plethora of wearable health monitoring technology and the 449 need for open industry standards to ensure interoperability between 450 products has lead to initiatives such as Continua Alliance 451 (continuaalliance.org) and Personal Connected Health Alliance 452 (pchalliance.org). 454 2.3.1. John and the heart rate monitor 456 John has a heart condition, that can result in sudden cardiac 457 arrests. He therefore uses a device called HeartGuard that monitors 458 his heart rate and his location (U3.7). In case of a cardiac arrest 459 it automatically sends an alarm to an emergency service, transmitting 460 John's current location (U3.1). Either the device has long range 461 connectivity itself (e.g. via GSM) or it uses some intermediary, 462 nearby device (e.g. John's smartphone) to transmit such an alarm. To 463 ensure Johns safety, the device is expected to be in constant 464 operation (U3.3, U3.6). 466 The device includes an authentication mechanism, in order to prevent 467 other persons who get physical access to it from acting as the owner 468 and altering the access control and security settings (U3.8). 470 John can configure additional persons that get notified in an 471 emergency, for example his daughter Jill. Furthermore the device 472 stores data on John's heart rate, which can later be accessed by a 473 physician to assess the condition of John's heart (U3.2). 475 However John is a privacy conscious person, and is worried that Jill 476 might use HeartGuard to monitor his location while there is no 477 emergency. Furthermore he doesn't want his health insurance to get 478 access to the HeartGuard data, or even to the fact that he is wearing 479 a HeartGuard, since they might refuse to renew his insurance if they 480 decided he was too big a risk for them (U3.8). 482 Finally John, while being comfortable with modern technology and able 483 to operate it reasonably well, is not trained in computer security. 484 He therefore needs an interface for the configuration of the 485 HeartGuard security that is easy to understand and use (U3.5). If 486 John does not understand the meaning of a setting, he tends to leave 487 it alone, assuming that the manufacturer has initialized the device 488 to secure settings (U3.4). 490 NOTE: Monitoring of some state parameter (e.g. an alarm button) and 491 the position of a person also fits well into an elderly care service. 492 This is particularly useful for people suffering from dementia, where 493 the relatives or caregivers need to be notified of the whereabouts of 494 the person under certain conditions. In this case it is not the 495 patient that decides about access. 497 2.3.2. Authorization Problems Summary 499 o U3.1 The wearer of an eHealth device (John in the example above) 500 wants to pre-configure special access rights in the context of an 501 emergency. 503 o U3.2 The wearer of an eHealth device wants to selectively allow 504 different persons or groups access to medical data. 506 o U3.3 Battery changes are very inconvenient and sometimes 507 impractical, so battery life impacts of the authorization 508 mechanisms need to be minimized. 510 o U3.4 Devices are often used with default access control settings 511 which might threaten the security objectives of the device's 512 users. 514 o U3.5 Wearers of eHealth devices are often not trained in computer 515 use, and especially computer security. 517 o U3.6 Security mechanisms themselves could provide opportunities 518 for denial of service attacks, especially on the constrained 519 devices. 521 o U3.7 The device provides a service that can be fatal for the 522 wearer if it fails. Accordingly, the wearer wants the device to 523 have a high degree of resistance against attacks that may cause 524 the device to fail to operate partially or completely. 526 o U3.8 The wearer of an eHealth device requires the integrity and 527 confidentiality of the data measured by the device. 529 2.4. Building Automation 531 Buildings for commercial use such as shopping malls or office 532 buildings nowadays are equipped increasingly with semi-automatic 533 components to enhance the overall living quality and to save energy 534 where possible. This includes for example heating, ventilation and 535 air condition (HVAC) as well as illumination and security systems 536 such as fire alarms. These components are being increasingly managed 537 centrally in a Building and Lighting Management System (BLMS) by a 538 facility manager. 540 Different areas of these buildings are often exclusively leased to 541 different companies. However they also share some of the common 542 areas of the building. Accordingly, a company must be able to 543 control the lighting and HVAC system of its own part of the building 544 and must not have access to control rooms that belong to other 545 companies. 547 Some parts of the building automation system such as entrance 548 illumination and fire alarm systems are controlled either by all 549 parties together or by a facility management company. 551 2.4.1. Device Lifecycle 553 2.4.1.1. Installation and Commissioning 555 Installation of the building automation components often start even 556 before the construction work is completed. Lighting is one of the 557 first components to be installed in new buildings. A lighting plan 558 created by a lighting designer provides the necessary information 559 related to the kind of lighting devices (luminaires, sensors and 560 switches) to be installed along with their expected behavior. The 561 physical installation of the correct lighting devices at the right 562 locations are done by electricians based on the lighting plan. They 563 ensure that the electrical wiring is performed according to local 564 regulations and lighting devices which may be from multiple 565 manufacturers are connected to the electrical power supply properly. 566 After the installation, lighting can be used in a default out-of-box 567 mode for e.g. at full brightness when powered on. After this step 568 (or in parallel in a different section of the building), a lighting 569 commissioner adds the devices to the building domain (U4.1) and 570 performs the proper configuration of the lights as prescribed in the 571 lighting plan. This involves for example grouping to ensure that 572 light points react together, more or less synchronously (U4.8) and 573 defining lighting scenes for particular areas of the building. The 574 commissioning is often done in phases, either by one or more 575 commissioners, on different floors. The building lighting network at 576 this stage may be in different network islands with no connectivity 577 between them due to lack of the IT infrastructure. 579 After this, other building components like HVAC and security systems 580 are similarly installed by electricians and later commissioned by 581 their respective domain professionals. Similar configurations 582 related to grouping (U4.8) are required to ensure for e.g. HVAC 583 equipment are controlled by the closest temperature sensor. 585 For the building IT systems, the Ethernet wiring is initially laid 586 out in the building according to the IT plan. The IT network is 587 commissioned often after the construction is completed to avoid any 588 damage to sensitive networking and computing equipment. The 589 commissioning is performed by an IT engineer with additional switches 590 (wired and/or wireless), IP routers and computing devices. Direct 591 Internet connectivity for all installed/commissioned devices in the 592 building is only available at this point. The BLMS that monitors and 593 controls the various building automation components are only 594 connected to the field devices at this stage. The different network 595 islands (for lighting and HVAC) are also joined together without any 596 further involvement of domain specialist such as lighting or HVAC 597 commissioners. 599 2.4.1.2. Operational 601 The building automation systems is now finally ready and the 602 operational access is transferred to the facility management company 603 of the building (U4.2). The facility manager is responsible for 604 monitoring and ensuring that the building automation systems meets 605 the needs of the building occupants. If changes are needed, the 606 facility management company hires an external installation and 607 commissioning company to perform the changes. 609 Different parts of the building are rented out to different companies 610 for office space. 611 The tenants are provided access to use the automated HVAC, lighting 612 and physical access control systems deployed. The safety of the 613 occupants are also managed using automated systems, such as a fire 614 alarm system, which is triggered by several smoke detectors which are 615 spread out across the building. 617 Company A's staff move into the newly furnished office space. Most 618 lighting is controlled by presence sensors which control the lighting 619 of specific group of lights based on the authorization rules in the 620 BLMS. Additionally employees are allowed to manually override the 621 lighting brightness and color in their office rooms by using the 622 switches or handheld controllers. Such changes are allowed only if 623 the authorization rules exist in the BLMS. For example lighting in 624 the corridors may not be manually adjustable. 626 At the end of the day, lighting is dimmed down or switched off if no 627 occupancy is detected even if manually overridden during the day. 629 On a later date company B also moves into the same building, and 630 shares some of the common spaces and associated building automation 631 components with company A (U4.2, U4.9). 633 2.4.1.3. Maintenance 635 Company A's staff are annoyed that the lighting switches off too 636 often in their rooms if they work silently in front of their 637 computer. Company A notifies the the facility manager of the 638 building to increase the delay before lights switch off. The 639 facility manager can either configure the new values directly in the 640 BLMS or if additional changes are needed on the field devices, hires 641 a commissioning Company C to perform the needed changes (U4.4). 643 Company C gets the necessary authorization from the facility 644 management company to interact with the BLMS. The commissioner's 645 tool gets the necessary authorization from BLMS to send a 646 configuration change to all lighting devices in Company A's offices 647 to increase their delay before they switch off. 649 At some point the facility management company wants to update the 650 firmware of lighting devices in order to eliminate software bugs. 651 Before accepting the new firmware, each device checks the 652 authorization of the facility management company to perform this 653 update (U4.13). 655 A network diagnostic tool of the BLMS detects that a luminaire in one 656 of the Company A's office room is no longer connected to the network. 657 The BLMS alerts the facility manager to replace the luminaire. The 658 facility manager replaces the old broken luminaire and informs the 659 BLMS of the identity (for e.g. MAC address) of the newly added 660 device. The BLMS then authorizes the new device onto the system and 661 transfers seamlessly all the permissions of the previous broken 662 device to the replacement device (U4.12). 664 2.4.1.4. Recommissioning 665 A vacant area of the building has been recently leased to company A. 666 Before moving into its new office, Company A wishes to replace the 667 lighting with a more energy efficient and a better light quality 668 luminaries. They hire an installation and commissioning company C to 669 redo the illumination. Company C is instructed to integrate the new 670 lighting devices, which may be from multiple manufacturers, into the 671 existing lighting infrastructure of the building which includes 672 presence sensors, switches, controllers etc (U4.1). 674 Company C gets the necessary authorization from the facility 675 management company to interact with the existing BLMS (U4.4). To 676 prevent disturbance to other occupants of the building, Company C is 677 provided authorization to perform the commissioning only during non- 678 office hours and only to modify configuration on devices belonging to 679 the domain of Company A's space (U4.5). Before removing existing 680 devices, all security and configuration material that belongs to the 681 domain are deleted and the devices are set back to factory state 682 (U4.3). This ensures that these devices may be reused at other 683 installations or in other parts of the same building without 684 affecting future operations. After installation (wiring) of the new 685 lighting devices, the commissioner adds the devices into the company 686 A's lighting domain. 688 Once the devices are in the correct domain, the commissioner 689 authorizes the interaction rules between the new lighting devices and 690 existing devices like presence sensors (U4.7). For this, the 691 commissioner creates the authorization rules on the BLMS which define 692 which lights form a group and which sensors/switches/controllers are 693 allowed to control which groups (U4.8). These authorization rules 694 may be context based like time of the day (office or non-office 695 hours) or location of the handheld lighting controller etc (U4.5). 697 2.4.1.5. Decommissioning 699 Company A has noticed that the handheld controllers are often 700 misplaced and hard to find when needed. So most of the time staff 701 use the existing wall switches for manual control. Company A decides 702 it would be better to completely remove handheld controllers and asks 703 Company C to decommission them from the lighting system (U4.4). 705 Company C again gets the necessary authorization from the facility 706 management company to interact with the BLMS. The commissioner now 707 deletes any rules that allowed handheld controllers authorization to 708 control the lighting (U4.3, U4.6). Additionally the commissioner 709 instructs the BLMS to push these new rules to prevent cached rules at 710 the end devices from being used. Any cryptographic key material 711 belonging to the site in the handheld controllers are also removed 712 and they are set to the factory state (U4.3). 714 2.4.2. Public Safety 716 The fire department requires that as part of the building safety 717 code, that the building have sensors that sense the level of smoke, 718 heat, etc., when a fire breaks out. These sensors report metrics 719 which are then used by a back-end server to map safe areas and un- 720 safe areas within a building and also possibly the structural 721 integrity of the building before fire-fighters may enter it. 722 Sensors may also be used to track where human/animal activity is 723 within the building. This will allow people stuck within the 724 building to be guided to safer areas and suggest possible actions 725 that they may take (e.g. using a client application on their phones, 726 or loudspeaker directions) in order to bring them to safety. In 727 certain cases, other organizations such as the Police, Ambulance, and 728 federal organizations are also involved and therefore the co- 729 ordination of tasks between the various entities have to be carried 730 out using efficient messaging and authorization mechanisms. 732 2.4.2.1. A fire breaks out 734 On a really hot day James who works for company A turns on the air 735 condition in his office. Lucy who works for company B wants to make 736 tea using an electric kettle. After she turned it on she goes 737 outside to talk to a colleague until the water is boiling. 738 Unfortunately, her kettle has a malfunction which causes overheating 739 and results in a smoldering fire of the kettle's plastic case. 741 Due to the smoke coming from the kettle the fire alarm is triggered. 742 Alarm sirens throughout the building are switched on simultaneously 743 (using a group communication scheme) to alert the staff of both 744 companies (U4.8). Additionally, the ventilation system of the whole 745 building is closed off to prevent the smoke from spreading and to 746 withdraw oxygen from the fire. The smoke cannot get into James' 747 office although he turned on his air condition because the fire alarm 748 overrides the manual setting by sending commands (using group 749 communication) to switch off all the air conditioning (U4.10). 751 The fire department is notified of the fire automatically and arrives 752 within a short time. They automatically get access to all parts of 753 the building according to an emergency authorization policy (U4.4, 754 U4.5). After inspecting the damage and extinguishing the smoldering 755 fire a fire fighter resets the fire alarm because only the fire 756 department is authorized to do that (U4.4, U4.11). 758 2.4.3. Authorization Problems Summary 759 o U4.1 During commissioning, the building owner or the companies add 760 new devices to their administrative domain. Access control should 761 then apply to these devices seamlessly. 763 o U4.2 During a handover, the building owner or the companies 764 integrate devices that formerly belonged to a different 765 administrative domain to their own administrative domain. Access 766 control of the old domain should then cease to apply, with access 767 control of the new domain taking over. 769 o U4.3 During decommissioning, the building owner or the companies 770 remove devices from their administrative domain. Access control 771 should cease to apply to these devices and relevant credentials 772 need to be erased from the devices. 774 o U4.4 The building owner and the companies want to be able to 775 delegate specific access rights for their devices to others. 777 o U4.5 The building owner and the companies want to be able to 778 define context-based authorization rules. 780 o U4.6 The building owner and the companies want to be able to 781 revoke granted permissions and delegations. 783 o U4.7 The building owner and the companies want to allow authorized 784 entities to send data to their endpoints (default deny). 786 o U4.8 The building owner and the companies want to be able to 787 authorize a device to control several devices at the same time 788 using a group communication scheme. 790 o U4.9 The companies want to be able to interconnect their own 791 subsystems with those from a different operational domain while 792 keeping the control over the authorizations (e.g. granting and 793 revoking permissions) for their endpoints and devices. 795 o U4.10 The authorization mechanisms must be able to cope with 796 extremely time-sensitive operations which have to be carried out 797 in a quick manner. 799 o U4.11 The building owner and the public safety authorities want to 800 be able to perform data origin authentication on messages sent and 801 received by some of the systems in the building. 803 o U4.12 The building owner should be allowed to replace an existing 804 device with a new device providing the same functionality within 805 their administrative domain. Access control from the replaced 806 device should then apply to these new devices seamlessly. 808 o U4.13 When software on a device is updated, this update needs to 809 be authenticated and authorized. 811 2.5. Smart Metering 813 Automated measuring of customer consumption is an established 814 technology for electricity, water, and gas providers. Increasingly 815 these systems also feature networking capability to allow for remote 816 management. Such systems are in use for commercial, industrial and 817 residential customers and require a certain level of security, in 818 order to avoid economic loss to the providers, vulnerability of the 819 distribution system, as well as disruption of services for the 820 customers. 822 The smart metering equipment for gas and water solutions is battery 823 driven and communication should be used sparingly due to battery 824 consumption. Therefore the types of meters sleep most of the time, 825 and only wake up every minute/hour to check for incoming 826 instructions. Furthermore they wake up a few times a day (based on 827 their configuration) to upload their measured metering data. 829 Different networking topologies exist for smart metering solutions. 830 Based on environment, regulatory rules and expected cost, one or a 831 mixture of these topologies may be deployed to collect the metering 832 information. Drive-By metering is one of the most current solutions 833 deployed for collection of gas and water meters. 835 Various stakeholders have a claim on the metering data. Utility 836 companies need the data for accounting, the metering equipment may be 837 operated by a third party Service Operator who needs to maintain it, 838 and the equipment is installed in the premises of the consumers, 839 measuring their consumption, which entails privacy questions. 841 2.5.1. Drive-by metering 843 A service operator offers smart metering infrastructures and related 844 services to various utility companies. Among these is a water 845 provider, who in turn supplies several residential complexes in a 846 city. The smart meters are installed in the end customer's homes to 847 measure water consumption and thus generate billing data for the 848 utility company, they can also be used to shut off the water if the 849 bills are not paid (U5.1, U5.3). The meters do so by sending and 850 receiving data to and from a base station (U5.2). Several base 851 stations are installed around the city to collect the metering data. 852 However in the denser urban areas, the base stations would have to be 853 installed very close to the meters. This would require a high number 854 of base stations and expose this more expensive equipment to 855 manipulation or sabotage. The service operator has therefore chosen 856 another approach, which is to drive around with a mobile base-station 857 and let the meters connect to that in regular intervals in order to 858 gather metering data (U5.4, U5.6, U5.8). 860 2.5.2. Meshed Topology 862 In another deployment, the water meters are installed in a building 863 that already has power meters installed, the latter are mains 864 powered, and are therefore not subject to the same power saving 865 restrictions. The water meters can therefore use the power meters as 866 proxies, in order to achieve better connectivity. This requires the 867 security measures on the water meters to work through intermediaries 868 (U5.9). 870 2.5.3. Advanced Metering Infrastructure 872 A utility company is updating its old utility distribution network 873 with advanced meters and new communication systems, known as an 874 Advanced Metering Infrastructure (AMI). AMI refers to a system that 875 measures, collects and analyzes usage, and interacts with metering 876 devices such as electricity meters, gas meters, heat meters, and 877 water meters, through various communication media either on request 878 (on-demand) or on pre-defined schedules. Based on this technology, 879 new services make it possible for consumers to control their utility 880 consumption (U5.2, U5.7) and reduce costs by supporting new tariff 881 models from utility companies, and more accurate and timely billing. 882 However the end-consumers do not want unauthorized persons to gain 883 access to this data. Furthermore, the fine-grained measurement of 884 consumption data may induce privacy concerns, since it may allow 885 others to create behavioral profiles (U5.5, U5.10). 887 The technical solution is based on levels of data aggregation between 888 smart meters located at the consumer premises and the Meter Data 889 Management (MDM) system located at the utility company (U5.9). For 890 reasons of efficiency and cost, end-to-end connectivity is not always 891 feasible, so metering data is stored and aggregated in various 892 intermediate devices before being forwarded to the utility company, 893 and in turn accessed by the MDM. The intermediate devices may be 894 operated by a third party service operator on behalf of the utility 895 company (U5.7). One responsibility of the service operator is to 896 make sure that meter readings are performed and delivered in a 897 regular, timely manner. An example of a Service Level Agreement 898 between the service operator and the utility company is e.g. "at 899 least 95 % of the meters have readings recorded during the last 72 900 hours". 902 2.5.4. Authorization Problems Summary 903 o U5.1 Devices are installed in hostile environments where they are 904 physically accessible by attackers (including dishonest 905 customers). The service operator and the utility company want to 906 make sure that an attacker cannot use data from a captured device 907 to attack other parts of their infrastructure. 909 o U5.2 The utility company wants to control which entities are 910 allowed to send data to, and read data from their endpoints. 912 o U5.3 The utility company wants to ensure the integrity of the data 913 stored on their endpoints. 915 o U5.4 The utility company wants to protect such data transfers to 916 and from their endpoints. 918 o U5.5 Consumers want to access their own usage information and also 919 prevent unauthorized access by others. 921 o U5.6 The devices may have intermittent Internet connectivity but 922 still need to enact the authorization policies of their 923 principals. 925 o U5.7 Neither the service operator nor the utility company are 926 always present at the time of access and cannot manually intervene 927 in the authorization process. 929 o U5.8 When authorization policies are updated it is impossible, or 930 at least very inefficient to contact all affected endpoints 931 directly. 933 o U5.9 Authorization and authentication must work even if messages 934 between endpoints are stored and forwarded over multiple nodes. 936 o U5.10 Consumers may not want the Service Operator, the Utility 937 company or others to have access to a fine-grained level of 938 consumption data that allows the creation of behavioral profiles. 940 2.6. Sports and Entertainment 942 In the area of leisure time activities, applications can benefit from 943 the small size and weight of constrained devices. Sensors and 944 actuators with various functions can be integrated into fitness 945 equipment, games and even clothes. Users can carry their devices 946 around with them at all times. 948 Usability is especially important in this area since users will often 949 want to spontaneously interconnect their devices with others. 950 Therefore the configuration of access permissions must be simple and 951 fast and not require much effort at the time of access. 953 Continuously monitoring allows authorized users to create behavioral 954 or movement profiles, which corresponds on the devices intended use, 955 and unauthorized access to the collected data would allow an attacker 956 to create the same profiles. 957 Moreover, the aggregation of data can seriously increase the impact 958 on the privacy of the users. 960 2.6.1. Dynamically Connecting Smart Sports Equipment 962 Jody is a an enthusiastic runner. To keep track of her training 963 progress, she has smart running shoes that measure the pressure at 964 various points beneath her feet to count her steps, detect 965 irregularities in her stride and help her to improve her posture and 966 running style. On a sunny afternoon, she goes to the Finnbahn track 967 near her home to work out. She meets her friend Lynn who shows her 968 the smart fitness watch she bought a few days ago. The watch can 969 measure the wearer's pulse, show speed and distance, and keep track 970 of the configured training program. The girls detect that the watch 971 can be connected with Jody's shoes and then can additionally display 972 the information the shoes provide. 974 Jody asks Lynn to let her try the watch and lend it to her for the 975 afternoon. Lynn agrees but doesn't want Jody to access her training 976 plan (U6.4). She configures the access policies for the watch so 977 that Jody's shoes are allowed to access the display and measuring 978 features but cannot read or add training data (U6.1, U6.2). Jody's 979 shoes connect to Lynn's watch after only a press of a button because 980 Jody already configured access rights for devices that belong to Lynn 981 a while ago (U6.3). Jody wants the device to report the data back to 982 her fitness account while she borrows it, so she allows it to access 983 her account temporarily. 985 After an hour, Jody gives the watch back and both girls terminate the 986 connection between their devices. 988 2.6.2. Authorization Problems Summary 990 o U6.1 Sports equipment owners want to be able to grant access 991 rights dynamically when needed. 993 o U6.2 Sports equipment owners want the configuration of access 994 rights to work with very little effort. 996 o U6.3 Sports equipment owners want to be able to pre-configure 997 access policies that grant certain access permissions to endpoints 998 with certain attributes (e.g. endpoints of a certain user) without 999 additional configuration effort at the time of access. 1001 o U6.4 Sports equipment owners want to protect the confidentiality 1002 of their data for privacy reasons. 1004 2.7. Industrial Control Systems 1006 Industrial control systems (ICS) and especially supervisory control 1007 and data acquisition systems (SCADA) use a multitude of sensors and 1008 actuators in order to monitor and control industrial processes in the 1009 physical world. Example processes include manufacturing, power 1010 generation, and refining of raw materials. 1012 Since the advent of the Stuxnet worm it has become obvious to the 1013 general public how vulnerable these kind of systems are, especially 1014 when connected to the Internet [Karnouskos11]. The severity of these 1015 vulnerabilities are exacerbated by the fact that many ICS are used to 1016 control critical public infrastructure, such as nuclear power, water 1017 treatment of traffic control. Nevertheless the economical advantages 1018 of connecting such systems to the Internet can be significant if 1019 appropriate security measures are put in place (U7.5). 1021 2.7.1. Oil Platform Control 1023 An oil platform uses an industrial control system to monitor data and 1024 control equipment. The purpose of this system is to gather and 1025 process data from a large number of sensors, and control actuators 1026 such as valves and switches to steer the oil extraction process on 1027 the platform. Raw data, alarms, reports and other information are 1028 also available to the operators, who can intervene with manual 1029 commands. Many of the sensors are connected to the controlling units 1030 by direct wire, but the operator is slowly replacing these units by 1031 wireless ones, since this makes maintenance easier (U7.4). 1033 Some of the controlling units are connected to the Internet, to allow 1034 for remote administration, since it is expensive and inconvenient to 1035 fly in a technician to the platform (U7.3). 1037 The main interest of the operator is to ensure the integrity of 1038 control messages and sensor readings (U7.1). Access in some cases 1039 needs to be restricted, e.g. the operator wants wireless actuators 1040 only to accept commands by authorized control units (U7.2). 1042 The owner of the platform also wants to collect auditing information 1043 for liability reasons (U7.1). 1045 Different levels of access apply e.g. for regular operators, vs. 1046 maintenance technician, vs. auditors of the platform (U7.6) 1048 2.7.2. Authorization Problems Summary 1050 o U7.1 The operator of the platform wants to ensure the integrity 1051 and confidentiality of sensor and actuator data. 1053 o U7.2 The operator wants to ensure that data coming from sensors 1054 and commands sent to actuators are authentic. 1056 o U7.3 Some devices do not have direct Internet connection, but 1057 still need to implement current authorization policies. 1059 o U7.4 Devices need to authenticate the controlling units, 1060 especially those using a wireless connection. 1062 o U7.5 The execution of unauthorized commands or the failure to 1063 execute an authorized command in an ICS can lead to significant 1064 financial damage, and threaten the availability of critical 1065 infrastructure services. Accordingly, the operator wants a 1066 authentication and authorization mechanisms that provide a very 1067 high level of security. 1069 o U7.6 Different users should have different levels of access to the 1070 control system (e.g. operator vs. auditor). 1072 3. Security Considerations 1074 As the use cases listed in this document demonstrate, constrained 1075 devices are used in various environments. These devices are small 1076 and inexpensive and this makes it easy to integrate them into many 1077 aspects of everyday life. With access to vast amounts of valuable 1078 data and possibly control of important functions these devices need 1079 to be protected from unauthorized access. Protecting seemingly 1080 innocuous data and functions will lessen the possible effects of 1081 aggregation; attackers collecting data or functions from several 1082 sources can gain insights or a level of control not immediately 1083 obvious from each of these sources on its own. 1085 Not only the data on the constrained devices themselves is 1086 threatened, the devices might also be abused as an intrusion point to 1087 infiltrate a network. Once an attacker gains control over the 1088 device, it can be used to attack other devices as well. Due to their 1089 limited capabilities, constrained devices appear as the weakest link 1090 in the network and hence pose an attractive target for attackers. 1092 This section summarizes the security problems highlighted by the use 1093 cases above and provides guidelines for the design of protocols for 1094 authentication and authorization in constrained RESTful environments. 1096 3.1. Attacks 1098 This document lists security problems that users of constrained 1099 devices want to solve. Further analysis of attack scenarios is not 1100 in scope of the document. However, there are attacks that must be 1101 considered by solution developers. 1103 Because of the expected large number of devices and their ubiquity, 1104 constrained devices increase the danger from Pervasive Monitoring 1105 [RFC7258] attacks. Solution Designers should consider this in the 1106 design of their security solution and provide for protection against 1107 this type of attack. In particular, messages containing sensitive 1108 data that are send over unprotected channels should be encrypted if 1109 possible. 1111 Attacks aimed at altering data in transit (e.g. to perpetrate fraud) 1112 are a problem that is addressed in many web security protocols such 1113 as TLS or IPSec. Developers need to consider this type of attacks, 1114 and make sure that the protection measures they implement are adapted 1115 to the constrained environment. 1117 As some of the use cases indicate, constrained devices may be 1118 installed in hostile environments where they are physically 1119 accessible (see Section 2.5). Protection from physical attacks is 1120 not in the scope of this document, but should be kept in mind by 1121 developers of authorization solutions. 1123 Denial of service (DoS) attacks threaten the availability of services 1124 a device provides and constrained devices are especially vulnerable 1125 to these types of attacks because of their limitations. Attackers 1126 can illicit a temporary or, if the battery is drained, permanent 1127 failure in a service simply by repeatedly flooding the device with 1128 connection attempts; for some services (see section Section 2.3), 1129 availability is especially important. Solution designers must be 1130 particularly careful to consider the following limitations in every 1131 part of the authorization solution: 1133 o Battery usage 1135 o Number of required message exchanges 1137 o Size of data that is transmitted (e.g. authentication and access 1138 control data) 1140 o Size of code required to run the protocols 1142 o Size of RAM memory and stack required to run the protocols 1144 o Resources blocked by partially completed exchanges (e.g. while one 1145 party is waiting for a transaction time to run out) 1147 Solution developers also need to consider whether the session should 1148 be protected from information disclosure and tampering. 1150 3.2. Configuration of Access Permissions 1152 o The access control policies need to be enforced (all use cases): 1153 The information that is needed to implement the access control 1154 policies needs to be provided to the device that enforces the 1155 authorization and applied to every incoming request. 1157 o A single resource might have different access rights for different 1158 requesting entities (all use cases). 1160 Rationale: In some cases different types of users need different 1161 access rights, as opposed to a binary approach where the same 1162 access permissions are granted to all authenticated users. 1164 o A device might host several resources where each resource has its 1165 own access control policy (all use cases). 1167 o The device that makes the policy decisions should be able to 1168 evaluate context-based permissions such as location or time of 1169 access (see Section 2.2, Section 2.3, Section 2.4). Access may 1170 depend on local conditions, e.g. access to health data in an 1171 emergency. The device that makes the policy decisions should be 1172 able to take such conditions into account. 1174 3.3. Authorization Considerations 1176 o Devices need to be enabled to enforce authorization policies 1177 without human intervention at the time of the access request (see 1178 Section 2.1, Section 2.2, Section 2.4, Section 2.5). 1180 o Authorization solutions need to consider that constrained devices 1181 might not have internet access at the time of the access request 1182 (see Section 2.1, Section 2.3, Section 2.5, Section 2.6). 1184 o It should be possible to update access control policies without 1185 manually re-provisioning individual devices (see Section 2.2, 1186 Section 2.3, Section 2.5, Section 2.6). 1188 Rationale: Peers can change rapidly which makes manual re- 1189 provisioning unreasonably expensive. 1191 o Authorization policies may be defined to apply to a large number 1192 of devices that might only have intermittent connectivity. 1193 Distributing policy updates to every device for every update might 1194 not be a feasible solution (see Section 2.5). 1196 o It must be possible to dynamically revoke authorizations (see e.g. 1197 Section 2.4). 1199 o The authentication and access control protocol can put undue 1200 burden on the constrained system resources of a device 1201 participating in the protocol. An authorization solutions must 1202 take the limitations of the constrained devices into account (all 1203 use cases, see also Section 3.1). 1205 o Secure default settings are needed for the initial state of the 1206 authentication and authorization protocols (all use cases). 1208 Rationale: Many attacks exploit insecure default settings, and 1209 experience shows that default settings are frequently left 1210 unchanged by the end users. 1212 o Access to resources on other devices should only be permitted if a 1213 rule exists that explicitly allows this access (default deny) (see 1214 e.g. Section 2.4). 1216 o Usability is important for all use cases. The configuration of 1217 authorization policies as well as the gaining access to devices 1218 must be simple for the users of the devices. Special care needs 1219 to be taken for scenarios where access control policies have to be 1220 configured by users that are typically not trained in security 1221 (see Section 2.2, Section 2.3, Section 2.6). 1223 o Software updates are an important operation for which correct 1224 authorization is crucial. Additionally authenticating the 1225 receiver of a software update is also important, for example to 1226 make sure that the update has been received by the intended 1227 device. 1229 3.4. Proxies 1231 In some cases, the traffic between endpoints might go through 1232 intermediary nodes (e.g. proxies, gateways). This might affect the 1233 function or the security model of authentication and access control 1234 protocols e.g. end-to-end security between endpoints with DTLS might 1235 not be possible (see Section 2.5). 1237 4. Privacy Considerations 1239 The constrained devices in focus of this document collect data from 1240 the physical world via sensors or affect their surrounding via 1241 actuators. The collected and processed data often can be associated 1242 with individuals. Since sensor data may be collected and distributed 1243 on a regular interval a significant amount of information about an 1244 individual can be collected and used as input to learning algorithms 1245 as part of big data analysis and used in an automated decision making 1246 process. 1248 Offering privacy protection for individuals is important to guarantee 1249 that only authorized entities are allowed to access collected data 1250 and to trigger actions, to obtain consent prior to the sharing of 1251 data, and to deal with other privacy-related threats outlined in RFC 1252 6973. 1254 RFC 6973 was written as guidance for engineers designing technical 1255 solutions. For a short description about the deployment-related 1256 aspects of privacy and further references relevant for the Internet 1257 of Things sector please read Section 7 of RFC 7452. 1259 5. Acknowledgments 1261 The authors would like to thank Olaf Bergmann, Sumit Singhal, John 1262 Mattson, Mohit Sethi, Carsten Bormann, Martin Murillo, Corinna 1263 Schmitt, Hannes Tschofenig, Erik Wahlstroem, Andreas Baeckman, Samuel 1264 Erdtman, Steve Moore, Thomas Hardjono, Kepeng Li, Jim Schaad, 1265 Prashant Jhingran, Kathleen Moriarty, and Sean Turner for reviewing 1266 and/or contributing to the document. Also, thanks to Markus Becker, 1267 Thomas Poetsch and Koojana Kuladinithi for their input on the 1268 container monitoring use case. Furthermore the authors thank Akbar 1269 Rahman, Chonggang Wang, Vinod Choyi, and Abhinav Somaraju who 1270 contributed to the building automation use case. 1272 Ludwig Seitz and Goeran Selander worked on this document as part of 1273 EIT-ICT Labs activity PST-14056. 1275 6. IANA Considerations 1277 This document has no IANA actions. 1279 7. Informative References 1281 [Jedermann14] 1282 Jedermann, R., Poetsch, T., and C. LLoyd, "Communication 1283 techniques and challenges for wireless food quality 1284 monitoring", Philosophical Transactions of the Royal 1285 Society A Mathematical, Physical and Engineering Sciences, 1286 May 2014. 1288 [Karnouskos11] 1289 Karnouskos, S., "Stuxnet Worm Impact on Industrial Cyber- 1290 Physical System Security", IECON 2011 - 37th Annual 1291 Conference on IEEE Industrial Electronics Society, pp. 1292 4490-4494 , November 2011. 1294 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1295 Constrained-Node Networks", RFC 7228, DOI 10.17487/ 1296 RFC7228, May 2014, 1297 . 1299 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1300 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 1301 RFC7252, June 2014, 1302 . 1304 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1305 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1306 2014, . 1308 Authors' Addresses 1310 Ludwig Seitz (editor) 1311 SICS Swedish ICT AB 1312 Scheelevaegen 17 1313 Lund 223 70 1314 Sweden 1316 Email: ludwig@sics.se 1318 Stefanie Gerdes (editor) 1319 Universitaet Bremen TZI 1320 Postfach 330440 1321 Bremen 28359 1322 Germany 1324 Phone: +49-421-218-63906 1325 Email: gerdes@tzi.org 1326 Goeran Selander 1327 Ericsson 1328 Faroegatan 6 1329 Kista 164 80 1330 Sweden 1332 Email: goran.selander@ericsson.com 1334 Mehdi Mani 1335 Itron 1336 52, rue Camille Desmoulins 1337 Issy-les-Moulineaux 92130 1338 France 1340 Email: Mehdi.Mani@itron.com 1342 Sandeep S. Kumar 1343 Philips Research 1344 High Tech Campus 1345 Eindhoven 5656 AA 1346 The Netherlands 1348 Email: sandeep.kumar@philips.com